SDL_ttf readstring?
Author
Hey, i was wondering how i would go about getting input from the user and printing the input, real time, on to the screen.
Im thinking use SDL's GetKeyState() function, then checking for each key and if it is pressed, add that key letter (or number) to a string, then printing that string to the screen every buffer flip.
i think this would be a bit expensive, as that is a bunch of keys to go through, backspacing, and combinations like shift+whatever..
any suggestions on a faster way of doing this, if any? it doesnt need to be anything real universal, it is just for typing in filenames for a map editor, so basically i would need numbers, letters, the _ character, and the . character. thanks for your help.
c
ps. SDL_ttf is what im using for text
use the event system rather that GetKeyState or whatever.
then use SDL_EnableUnicode(1) and the event datastructure will have the character code inside it.
That saves having to deal with shift and stuff, but you'd still ahve to deal with backspace and stuff.
then use SDL_EnableUnicode(1) and the event datastructure will have the character code inside it.
That saves having to deal with shift and stuff, but you'd still ahve to deal with backspace and stuff.
as c-junkie said, you can weed out un-ascii characters by modifying the code provided in the Handling Keyboard section of the SDL Documentation(example 2). this gives you the key pressed, and you just blit it to whatever surface you need using sdl_ttf. you'd probably need to modify it slightly - store the previous set of chars in an array to make sure the keys are't being held. the sdl docs also contain the list of ascii characters.
Just so you know, you can only use SDL_KEYDOWN messages to read unicode characters. If you try using SDL_Event.key.keysym.unicode in a SDL_KEYUP message, it won't work.
Here's the code you can use for inputting text
Note also that you shouldn't render text every single frame using the TTF_RenderText_*() functions. This is really expensive, even when using the lower render settings. The better thing to do is render the text onto an SDL surface, and then just blit that surface onto the main surface each frame until you need to update the text itself, at which point you can call TTF_RenderText_*() again.
Here's the code you can use for inputting text
int iUnicode = event.key.keysym.unicode;std::string strText = "existing text";// do we have a character key or a backspace key?if (((iUnicode > 31) || (iUnicode == '\b')) && (iUnicode < 128)) { // is this is a backspace keypress and there is stuff to delete? if ((iUnicode == '\b') && (strText.size())) { // delete the last character strText.erase(strText.size()-1, 1); } // some character key else if (iUnicode != '\b') { // add the character onto the string strText += iUnicode; }} Note also that you shouldn't render text every single frame using the TTF_RenderText_*() functions. This is really expensive, even when using the lower render settings. The better thing to do is render the text onto an SDL surface, and then just blit that surface onto the main surface each frame until you need to update the text itself, at which point you can call TTF_RenderText_*() again.
Quote:Original post by c-gibson-s
Im thinking use SDL's GetKeyState() function, then checking for each key and if it is pressed, add that key letter (or number) to a string, then printing that string to the screen every buffer flip.
i think this would be a bit expensive, as that is a bunch of keys to go through, backspacing, and combinations like shift+whatever..
'Expensive' usually means slow in terms of performance. In fact you'll probably find that letting you decide how to handle each individual keypress is about as high-performance as you're going to get as there's no overhead involved in processing the input unless you do it.
From a usability standpoint, whenever you are inputting text, you want some way to indicate to the user of the application that he is doing so.
Ways that I have typically done so in the past is to append a _ after the entered text, and perhaps flashing it(I have used SDL timers to do this).
Ways that I have typically done so in the past is to append a _ after the entered text, and perhaps flashing it(I have used SDL timers to do this).
Author
Right, to ressurect this..
I have been playing with this for a while now. So far, i havent been able to get it to work. I did what Gaiiden said and went ahead with unicode, and used the SDL_EnableUNICODE(1) thing or whatever...but i guess my limited (none actually) knowledge of unicode is getting me down here.
Here is the problem. It is actually getting to print stuff on the screen, but i am having an issue with it blitting the old text off before blitting the new text on. I keep getting these akward looking shapes and i guess unicode characters that are printing on the screen.
Maybe it has to do with the SDL_Rect not being wide enough? Or am i way off base here..
I have been playing with this for a while now. So far, i havent been able to get it to work. I did what Gaiiden said and went ahead with unicode, and used the SDL_EnableUNICODE(1) thing or whatever...but i guess my limited (none actually) knowledge of unicode is getting me down here.
Here is the problem. It is actually getting to print stuff on the screen, but i am having an issue with it blitting the old text off before blitting the new text on. I keep getting these akward looking shapes and i guess unicode characters that are printing on the screen.
Maybe it has to do with the SDL_Rect not being wide enough? Or am i way off base here..
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
