Advertisement

SDL_TTF text entry?

Started by December 03, 2011 07:38 PM
6 comments, last by That One Guy 13 years ago
I'm in kind of a goofy scenario right now. Two things must be done before I can get back into working on this (Ultima-style) RPG I'm planning, and one of them is driving me loopy:
How might I go about allowing the player to enter text and /blit the text entered/ like a normal SDL_TTF surface? Must I really work this entire process out from scratch?
The simplest way I can invision doing it is by taking a keypress, adding it to my user_input variable, taking another and adding it to the next slot of the char array (if this is a bad idea in some way, let me know, but this isn't the question I'm asking) and continuing until the user presses 'enter' to finish. The way I'm asking about is probably impossible with plain SDL: Is it possible to simply take the input, adding it and blitting the surface with each keypress so that it enters (from the player's perspective) as simply as typing in a word processor? If not, I understand, I could go with my alternate plan (requiring a ROYALLY huge rewrite and replanning, but it is possible and I'd be willing if I had to do so). The first method I mentioned would have involved a separate if/else for each alphabetical key, and would result in tremendous tedium, but I can do that if need be, also. I'm probably horribly wrong about these methods and there might be a simpler way, so I'm asking: Could someone lend me a little advice, or a tutorial link/etc? Thanks to whomever can help! @_@;

EDIT: Just to be clear about this, I'm using C.
How is the word displayed right now? Is there a loop thats running constantly updating the screen and drawing the currecnt contents of user_input, or is it waiting for a keypress and then updating the screen? What type is user_input?
Advertisement
It isn't the display of the input which gives me the trouble, I really should have clarified this. It is more about how the input is received. I've been using something along these lines:
while(SDL_WaitEvent(&event)!=0){
switch(event.type){
case SDL_KEYDOWN:
if(event.key.keysym.sym == SDLK_a){
//does stuff
}

...I'm pretty sure I'll have to write a single function which can take input from every necessary key, unless there's a better way (I figured SDL might have a function which sorta simulates the input capability of an unix terminal, but I'm starting to guess that was wrong). As for displaying, I've not been doing it very intelligently. There /is/ a way to use or define an entire char array at once, right? If so, I should try that instead. I'm sure there is, but I can't remember... x_x;
The SDLK_ codes correspond to the ASCII codes. Check SDL/SDL_keysym.h in your include directory against ASCII Codes. You can just do
char letter=event.key.keysym.sym;

to get the letter as a char

There /is/ a way to use or define an entire char array at once, right?

Im not sure what you mean. What are you trying to do exactly?
Well, I was trying (unsuccessfully, obviously) to fill a generic input char array which could be used as various things like for character-naming or things said to an NPC. Basically it would have gone like this, if possible (doubt it is, now):

char input_thing[8];
//gets input
//assigns input to first available array 'slot'
//repeats until user hits 'enter'
//copies input_thing into character's name or uses it to get a response from an NPC


Basically, I was being stupid and making something more complicated than it needed to be for the sake of over-sorting, I think. It shouldn't be a problem after the information you've given me, though! :) Thanks!
Advertisement
From the SDL documentation:

And at last, never ever ever write your own custom ASCII conversion table. If you do that, you'll get angry non US users that will pester you to fix the keyboard handling for them, one for each keyboard layout existing in the world.
[/quote]

SDL provides for unicode translation on the keysym structure. This is the preferred way to build text input in SDL games.
Alrighty, then, I see that SDL's innate input was more flexible than I originally thought! I'll take some time to play about with it and see if I can get something working. :)

This topic is closed to new replies.

Advertisement