Well, I kinda suspected that. Anyway, I don’t know if there even are
any keyboards that can input characters beyond FFFF… there probably
aren’t.
These are usually composed characters. I don’t know of any IMEs that will
let you input them though. If you look at the UNICODE standard, you’ll see
that these are mostly dead languages.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Not really, the code is pretty deeply intertwined. You might want to
look at the source before you decide it is faster. Generally SDL has to
read an event queue to get the information it puts in the key vector.
Anyway, the cost is so small it doesn’t really affect game play even
with 4 players on one machine. OTOH, if you are only using one keyboard
then you will have problems with keys presses not being detected at all.
(I’m not sure what kind of reading input state you meant in second paragraph, probably messaging)
Well it’s the thing that’s very important to me, because having reliabe input system which won’t miss keypresses, even when 4 players use the same keyboard simultaneusly, is a must for my game. So when designing input class I thought that using events probably will be less accurate (to be honest, actually performance isn’t what I care about, so forget that argument from earlier post) then using key vectory, reasons:
Having only one PollEvent in main loop would couse key events to come far too late, especially with 4 players (1 event / 1 game loop). Also doing it way that it polls for events untill queue is empty, in hardcore situations (4 players pressing X keys each, where X belongs to [1, 4] ) could make the game stay still, polling endless keypressess (though now I think it’s problem only in my imagination, in real world SDL probably has some sort of max. events cap).
OTOH, when SDL_GetKeyState for key vector would be called appropriate number of times / second (ie. 100), in theory I shouldn’t bother with missing keypressess: humans are not robots so ability to press and relase key so fast that it would be left unnoticed by game running with 100 fps (which means you have 10 ms for doing this) IMHO is very unique :-]
There were also other reasons but I can’t recall them now. And yes, I know the ones I’ve written can’t be treated very seriously, in fact, the most important reason was that such system was propsed in Enginuity series on GameDev; I’ve seen there this system along with some pretty cool ideas, so I thought to myself: “that guy knows what he’s doing, I should give it a try”. It’s just that simple 
BTW: anybody knows is SDL_GetKeyState is supposed to properly and reliably read state of all keys, so ie. if I put huge book on keyboard which will couse more than 20 keys to be pressed, will all of them be properly read?
Additionaly, it would be great if anyone knows if key events could handle this situation properly? I remember from good old pascal days that some low level asm interrupt implementations allowed for max up to 4 keys being pressed/released at once, but it was many years ago, I wonder if hardware and software are now better in dealing with such cases.
Since the key vector shows you the state at the time you check it, it is
pretty easy to miss key presses and shift presses. People don’t press
them at the same time so you might get wrong results at times. The only
way around that problem is to use a form of input that doesn’t let you
miss key presses/releases.
Hmmm, another problem :-/
I’ll test if it happen and if it will prove to couse problems I’ll probably change input system for using events. Thx for making aware of this issue!
Koshmaar
They were overlooked. When I wrote the list of keysyms I didn’t have a polish
keyboard handy.
Just to clear things up: actually polish keyboards aren’t really different from standard english ones, typing ?,?,? etc. is accomplished by pressing a, e, c etc. and right alt, you just have to change OS settings.
Also, I thought that % is available on all types of standard 103 keyboards, not only polish ones shrugs 
I recently wrote the international keyboard handling for World of Warcraft,
and I finally figured out how to do it right, so SDL 1.3 is going to have a
completely revamped set of keysyms, which will include the lower ASCII set
unchanged, as keys on the keyboard.
Well, that’s great!
Koshmaar
They were overlooked. When I wrote the list of keysyms I didn’t have a polish
keyboard handy.
Just to clear things up: actually polish keyboards aren’t really different from standard english ones, typing ?,?,? etc. is accomplished by pressing a, e, c etc. and right alt, you just have to change OS settings.
Also, I thought that % is available on all types of standard 103 keyboards, not only polish ones shrugs
Yes, but only as shift-5 (see below)
I recently wrote the international keyboard handling for World of Warcraft,
and I finally figured out how to do it right, so SDL 1.3 is going to have a
completely revamped set of keysyms, which will include the lower ASCII set
unchanged, as keys on the keyboard.
Well, that’s great!
Well, yes, but that won’t solve your problem. The SDL keysyms only correspond
to unmodified keys on the keyboard. For example, the French keyboard
doesn’t actually have number keys. To get ‘1’ on a French keyboard, you
have to press shift and another key (I forget which), so you’ll never get a
keyboard event with SDLK_1 in it on a French keyboard. If you enable UNICODE
translation though, you’ll get an event with ‘1’ in the unicode field when the
appropriate key combination is pressed.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Bob Pendleton wrote:
By the way, I don’t know whether this has been discussed before, but
what is the rationale behind the unicode field of SDL_keysym only having
16 bits?Probably the same reason that rectangle sizes are only 16 bits. It was
enough when that code was written and if it had been more people would
have been upset about how horrible SDL is for wasting those unneeded 16
bits.Well, I kinda suspected that. Anyway, I don’t know if there even are
any keyboards that can input characters beyond FFFF… there probably
aren’t.
I don’t know about keyboards, but most operating systems have a way to
input asian language glyphs, and those go well beyond 0xFFFF. So, it may
be possible for SDL to encounter at 32 bit UNICODE value, but I don’t
know.
Bob PendletonOn Tue, 2004-11-30 at 04:28, Sebastian Beschke wrote:
On Mon, 2004-11-29 at 16:09, Sebastian Beschke wrote:
-Sebastian
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
Anyway, the cost is so small it doesn’t really affect game play even
with 4 players on one machine. OTOH, if you are only using one keyboard
then you will have problems with keys presses not being detected at all.Yes, many keyboards cannot handle even 3 keys pressed simultaneously,
depending on where they are on the keyboard. This is a hardware limitation,
due to the circuitry on the keyboard.To fully support 4 people playing on the same system, you’ll probably have
to support joystick input.Bob, as an FYI, I’d like to support multiple keyboards in SDL 1.3.
Yes master! And would you like me to look at all the 16 bit values while
I’m at it? Seriously, it looks like I will have time to do that.
Bob PendletonOn Tue, 2004-11-30 at 09:10, Sam Lantinga wrote:
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
Bob Pendleton wrote:
I don’t know about keyboards, but most operating systems have a way to
input asian language glyphs, and those go well beyond 0xFFFF. So, it may
be possible for SDL to encounter at 32 bit UNICODE value, but I don’t
know.
They do? At least the “CJK Unified Ideographs” for Chinese, Japanese and
Korean range from U4E00 to U9FAF. Don’t really know about other languages.
Not that it matters much.
BTW, I haven’t tried this, but has anyone done any experiments with SDL
and IME software? How well does it work?
Bob Pendleton
-Sebastian
Yes master! And would you like me to look at all the 16 bit values while
I’m at it?
Sure, that would be great.
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Koshmaar wrote:
Also, I thought that % is available on all types of standard 103 keyboards, not only polish ones shrugs
Japanese Keyboards (I’m told) don’t have a ~ key, as it’s replaced by a
key which signals the OS to switch from typing to changing the
characters, since they have so many characters which can sound the same.
Might be one of the other keys, too, though… I haven’t seen on e in
real life.
–Scott
PS: Oops, off topic, sorry.
Well, yes, but that won’t solve your problem. The SDL keysyms only correspond
to unmodified keys on the keyboard. For example, the French keyboard
doesn’t actually have number keys.
have to press shift and another key (I forget which), so you’ll never get a
keyboard event with SDLK_1 in it on a French keyboard. If you enable UNICODE
translation though, you’ll get an event with ‘1’ in the unicode field when the
appropriate key combination is pressed.
Well, that’s a really great argument for not using SDL_GetKeyState… it looks like eventually I’ll have to change it to event based input :-/ hmmm, at least it’s going to be more reliable (?) and probably slightly faster (??).
Anyway, major kudos to everyone for replying my mails! I’ve learned much and I’m going to share that knowledge in SDL’s Wiki project, so people won’t need to force open door anymore (at least in this subject).
Koshmaar
Bob Pendleton wrote:
I don’t know about keyboards, but most operating systems have a way to
input asian language glyphs, and those go well beyond 0xFFFF. So, it may
be possible for SDL to encounter at 32 bit UNICODE value, but I don’t
know.They do? At least the “CJK Unified Ideographs” for Chinese, Japanese and
Korean range from U4E00 to U9FAF. Don’t really know about other languages.
The “CJK Unified Ideographs Extension B” are in the 0x20000 to 0x2A6DF
range. That is over 42000 glyphs right there. Two thirds as big as all
the utf-16 characters.
Not that it matters much.
Unless you are trying to sell into the CJK market, where it matters more
every day.
BTW, I haven’t tried this, but has anyone done any experiments with SDL
and IME software? How well does it work?
I’d like to hear about that too.On Tue, 2004-11-30 at 11:28, Sebastian Beschke wrote:
Bob Pendleton-Sebastian
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
Bob Pendleton wrote:
Bob Pendleton wrote:
I don’t know about keyboards, but most operating systems have a way to
input asian language glyphs, and those go well beyond 0xFFFF. So, it may
be possible for SDL to encounter at 32 bit UNICODE value, but I don’t
know.They do? At least the “CJK Unified Ideographs” for Chinese, Japanese and
Korean range from U4E00 to U9FAF. Don’t really know about other languages.The “CJK Unified Ideographs Extension B” are in the 0x20000 to 0x2A6DF
range. That is over 42000 glyphs right there. Two thirds as big as all
the utf-16 characters.
OK, so I didn’t look that closely
Not that it matters much.
Unless you are trying to sell into the CJK market, where it matters more
every day.
What I meant was that my argument doesn’t matter because the unicode
field has to become 32-bit anyways (IMHO) 
-Sebastian> On Tue, 2004-11-30 at 11:28, Sebastian Beschke wrote: