The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


I've tried to compile my game for SDL 1.3. I've found a couple things
namely:

- Deprecation of SDLK_* macros in favour of scancodes.
- SDL_PixelFormat changes.
- SDL_Mixer not working as expected.

SDLK_* macros have had some changes, notably both SDLK_FIRST and
SDLK_LAST have been removed (which I both use) and it seems like the
scancodes don't map to ASCII anymore. Is this definitive? Is there a
little howto or something on moving from SDL 1.2 keyboard system to SDL
1.3 keyboard system? This has got me a bit confused.

SDL_PixelFormat seems to be completely different. Will some
compatibility be added for 1.2's SDL_PixelFormat? or will there be a
rough "conversion" guide made to upgrade code to 1.3? I prefer the
former, because I've never been a big fan of preprocessor #ifs in the code.

Other then that it looks pretty solid, haven't really gotten around to
test more functionality though. It seems like I'll have to compile a
new SDL_Mixer for SDL 1.3 since that looks broken, but SDL_Image is
working ok.

Will try to run more regression tests and such when I can get it working
natively without ugly hacks (and start looking at the new API stuff).


Edgar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklfJpwACgkQolm4VNX3QTwZ6gCfaD9xMPRy8gqnuKOj8jPCHTly
tngAn0NetVETmgv5FevkHymC/AcLkTjD
=Sb9Q
-----END PGP SIGNATURE-----

The SDL 1.3 keyboard system has two sets of key codes. One set,
SDL_SCANCODE_*, is designed to represent the physical keys of the keyboard,
and is based on the USB HID standard. The other set, SDLK_*, is designed
to represent the unmodified keys in the current keyboard layout, and maps
to Unicode values printed on the keys. The non-printable keys have been
moved out of the Unicode code point space so as to avoid conflicts.

Which set you use is dependent upon the needs of your program.
What you probably want is the new SDL_GetKeyboardState() function,
which is indexed by scancodes.

It's important to note that the scancodes are not affected by keyboard
layout, so don't assume that SDL_SCANCODE_A means the letter 'a' on anything
but a US DVORAK keyboard layout.


The SDL_PixelFormat is now used just to describe the pixel format, and has
all the same fields it did for that (palette, BitsPerPixel, masks, etc.).
The blit modifiers (colorkey, per-surface alpha) are now stored in the
surfaces and can be accessed with the functions in SDL_surface.h


Yeah, try grabbing SDL_mixer from subversion. I think there was one minor
change that was needed for SDL 1.3.

Thanks for checking it out!

See ya,
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


I've managed to work out all the SDL_PixelFormat changes and various
changes, but am having issues with the SDLK_* changes.


First off, is there a way to disable key repeat? The only way seems to
be SDL_EnableKeyRepeat in SDL_compat.h and from looking at the code it
doesn't actually do anything.


Second, stuff like SDLK_BACKSPACE doesn't seem to map to '\b' anymore.
That also happens with other symbols, making it trickier to operate on.
This is especially distressing because for some reason isalnum seems to
segfault on non-ascii symbols from SDLK_* when it wouldn't back in SDL
1.2. It's pretty strange and I don't make heads and tails out of it.
It doesn't seem to segfault when "normal" characters are given and
valgrind reports:

==28493== Invalid read of size 2
==28493== at 0x46F731: toolkit_keyEvent (toolkit.c:2494)
==28493== by 0x46EEAA: toolkit_input (toolkit.c:2294)
==28493== by 0x42220A: input_handle (input.c:713)
==28493== by 0x430491: main (naev.c:254)
==28493== Address 0x8677f5f8 is not stack'd, malloc'd or (recently) free'd
==28493== Warning: set address range perms: large range 268402688 (noaccess)

I get no issues at all with valgrind and friends with SDL 1.2. The code
that segfaults is:

SDLKey key;
key = event->key.keysym.sym;
if ((key==SDLK_BACKSPACE) || isalnum(key)) { /* <-- segfault */
...

Attaching code to reproduce, it crashes here with latest trunk (x86-64
linux). I don't have much time to look into it, but might try (should
be studying for finals that start in under a week).


Third, I have mapped my capslock to escape (for VIM mainly), however it
seems SDL 1.3 doesn't read it as escape unlike in SDL 1.2. It does
however pick up my dvorak layout.


Everything else seems to work (haven't tried sound though yet). The
weird keyboard segfaults have prevented me from going much deeper.


Edgar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEUEARECAAYFAklf7NAACgkQolm4VNX3QTzawwCgsxSpSoiVstd2I+lX2g5qmnEB
El4AliLz0CgjdjuVIK1TqaTsCkaFwPo=
=BO7W
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdlcrash.c
Type: text/x-csrc
Size: 574 bytes
Desc: not available
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090103/18ca85df/attachment.c>

On Sat, Jan 3, 2009 at 5:55 PM, Edgar Simo <bobbens at gmail.com> wrote:

isalnum() segfault? what? really? that's a problem with your C
standard library, no doubt about it. (or it's *not* really
segfaulting, something else is.)

Your isalnum() function accepts an integer, not a pointer, right? So
there's no way this is a matter of it reading a whole string and
running off into uncharted territory??

What C std lib are you using?

--
http://codebad.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


You have the valgrind output and the code that triggers it here, I'm
almost certain it's some SDL weirdness as I usually use it and haven't
had any issue with anything else.

Anyway, version is 2.7-16 of libc6 (latest in Debian SID).
Implementation is:

int isalnum(int c);

You should try the sdlcrash.c and see what happens. I'm pretty confused
by the whole thing and should probably be sleeping and/or studying
instead of working on this .


Edgar

Donny Viszneki wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklf790ACgkQolm4VNX3QTzX0QCeJhKlbNEb1AL3GA2TtGb7hpoW
oYQAoIgr9mNN0CcpkH7sMiXh5MAYPT54
=keDP
-----END PGP SIGNATURE-----

On Sat, Jan 3, 2009 at 6:08 PM, Edgar Simo <bobbens at gmail.com> wrote:

Was it an attachment? I don't see any attachments in this thread... :(

--
http://codebad.com/

On Sat, Jan 3, 2009 at 6:38 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

Sorry, I see it now. I think my attachment paperclip icon is missing
for some reason


--
http://codebad.com/

Wow, a serious bug in libstdc... someone should report this:

donny at teamspace:~$ cc isalnum-crash.c -o isalnum-crash
donny at teamspace:~$ ./isalnum-crash
Segmentation fault
donny at teamspace:~$ cat isalnum-crash.c
int main (void) {
int n = isalnum(1073741864);
return 0;
}

As I said earlier, nothing to do with SDL at all! (Except maybe that
SDL is giving some really odd-ball keysyms)

--
http://codebad.com/

FWIW I've confirmed this with some people in #debian irc.oftc.net

On Sat, Jan 3, 2009 at 6:48 PM, Donny Viszneki <donny.viszneki at gmail.com> wrote:



--
http://codebad.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


Well before this got "offtopic" on the isalnum() bug in libc (I don't
generally assume libc is at fault). I'd like to show what I'm doing to
see how to port it to SDL 1.3, although I'm pretty sure it'll never
behave the same because of the other things I stated in my last "big" post.

What I do is use SDL_GetKeyName() and iterate from SDLK_FIRST to
SDLK_LAST (would be 0 to SDL_NUM_SCANCODES in 1.3) and stare all the
names in an array of each key (didn't have to strdup in 1.2, but it
seems 1.3 implies you should). Then when the user defines keys it just
runs through the table to see what he's defining (he defines in a Lua
conf using key names). It's also easy to look up the key name later
when displaying configuration. All this is to avoid defining keys with
their keysym and making life easier for the user (and more compatible
across layouts).

I understand that the goal for the ORing with (1<<30) on most keysyms is
to avoid collisions between scancodes and keysyms. I do not think this
is the best approach because it also seems to break compatibility that
SDLK had with the isalnum type functions since it had pretty nice
mapping to ascii with a few things poking out the edge (function keys,
etc...).

I understand I could just use scancodes, but then when a user (like me)
has mapped Escape to Capslock, it doesn't read it as Escape as wanted.
This seems to happen with 1.3 and the keysyms, but I'm considering it a
bug. You can set the behaviour with:
xmodmap -e 'clear lock'
xmodmap -e 'keycode 66 = Escape'
And then checking the keysym generated by the event. I'm attaching a
sample code to print keydown keysym names.

Also another thing I noticed. In 1.2 the characters are lower case:
"a", "b", etc... While in 1.3 the characters are upper case: "A", "B",
etc... Although it would be pretty trivial to run "toupper" on both
when matching keysym with name in my code.


Edgar


Donny Viszneki wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklggTkACgkQolm4VNX3QTx2cgCgx5eZlBm9V9RG4sVzUvOf5rCv
pkQAn2RYMyQuNFWCZrbuxbJ2FWA3Ho2O
=RruB
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdlkeystuff.c
Type: text/x-csrc
Size: 684 bytes
Desc: not available
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20090104/a8fcae9c/attachment.c>

I'm not sure the goal here. When the user presses a key, you can look
up the name of that key and store either the key or the name of the key
in your config. Are you trying to keep the same physical configuration
regardless of keyboard layout?

If you're trying to keep the same physical configuration, you can store
scancodes and use SDL_GetKeyFromScancode() and SDL_GetKeyFromScancode()
for displaying what's on the user's keyboard.

If you're trying to keep the same logical configuration, you can just
store keysyms and look up their names at runtime for display purposes.

Am I missing something?


Actually it's to avoid collisions between keysyms and keysyms. The keysyms
have been expanded to all possible characters printed on the keyboard, which
can (potentially) overlap any legitimate Unicode value.

The scancodes are completely separate and are based on the USB HID standard.


This is still the case, SDLK_* values still map to ascii with a few things
poking out the edge, they just poke out in a way that apparently breaks
isalnum().


This seems like it would be remapping of the keysyms (i.e. a logical
remapping, not a physical one.)
Does it show up that way on your system?

To put things into perspective, the SDL keysym corresponds to the X11 keysym,
and the SDL scancode corresponds to the X11 keycodes.

We could fix the few SDLK_* keysyms that actually correspond to ASCII values
(tab, escape, backspace, etc.) to use those values. I think that's probably
a good idea and I'll go ahead and do that.

See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


Sam Lantinga wrote:

Well the idea is to let the player define them easily, by name and not
by keysym. So you can write stuff like "shoot = 'space'" instead of
"shoot = 32". Of course a more fancy configurator could handle this.

The problem with the keysyms not being consecutive with no SDLK_LAST, is
that you can't feasible store a table of 2^32-1 names. In 1.2 they're
consecutive with SDLK_FIRST and SDLK_LAST, so it's easy to create the
lookup table to translate from keysym name to keysym.

Another possibility would be to create a function like SDL_GetKeyName()
like SDL_GetKeyFromName() and it would return the SDLKey that matches
the char* name.

Overall the idea is to be able to do conversions from name <-> keysym
both ways, while SDL only supports natively one way.


Well, I think as much of of the ascii as possible should be mapped to
the ascii positions, and then the rest could be expanded. I wouldn't
mind doing something like:

int my_isalpha( SDLKey k )
{
return ((k & 0xff) == k) ? isalpha(k) : 0;
}

It's just soo much uglier if it doesn't map though. I'm mainly speaking
about stuff like SDLK_BACKSPACE, SDLK_SPACE, etc...


This is my xev output:

KeyPress event, serial 34, synthetic NO, window 0x1800001,
root 0x7b, subw 0x0, time 1868946, (159,-94), root:(1259,712),
state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
XLookupString gives 1 bytes: (1b) "ape), same_screen YES,
XLookupString gives 1 bytes: (1b) "es: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0x1800001,
root 0x7b, subw 0x0, time 1871690, (159,-94), root:(1259,712),
state 0x0, keycode 66 (keysym 0xff1b, Escape), same_screen YES,
XKeysymToKeycode returns keycode: 9
XLookupString gives 1 bytes: (1b) "cape), same_screen YES,
XKeysymToKeycode returns keycode: 9
XLookupString gives 1 bytes: (1b)

As you can see, the keycode is different, but the keysym is the same.
and after the lookup it's the same. SDL 1.2 seems to get this fine, but
1.3 doesn't and must use the first keycode it gets.


Yes, that would be awesome.


On a side note, you haven't mentioned keyrepeat. It seems to be on
always. In 1.2 it was off by default and you had the option to enable
it, the function in SDL_Compat to disable keyrepeat seems to be empty.
Is it deprecated?


Other then that it looks pretty fluid and nice, going to try to see how
the rest of the stuff works (haven't poked SDL_mixer yet), and most
likely see if I can start using fancier stuff (especially like the
haptic subsystem).


Edgar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklg6wQACgkQolm4VNX3QTy6eACg0yYkrhbj5Fy3YewcUVTJ1Kli
CIEAoIfJIe4+8VXHdIcBOJf84FrjeqBC
=X537
-----END PGP SIGNATURE-----

No, this is still on the TODO list. The key repeat logic needs to be
moved to the SDL driver level, and hasn't been implemented yet.

See ya,
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


Ah ok, so it's good to know. The fragmentation of this thread has made
me ask it in my last post again, but you answered it here . Damn this
realtime emailing, need some sort of mutex.


Edgar

Sam Lantinga wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklg61wACgkQolm4VNX3QTxABQCgqjMHWm5UhT4HzBb7ztiUYffv
m6cAn0sdqDskKrB3B4QdzlIyjfWV1uqn
=rka+
-----END PGP SIGNATURE-----

That's not a bad idea, I'll add that to the TODO list.


Done! Revision 4345


Yeah, I hear the guy who did that is pretty awesome. ;)

See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

What is the output of checkkeys with the latest subversion?
(make clean; make install; cd test; ./configure; make checkkeys)

See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


Sam Lantinga wrote:

[bobbens at ghanima (~/src/SDL/test)] $ svn up
At revision 4347.
[bobbens at ghanima (~/src/SDL/test)] $ ./checkkeys
Sending text event
Unknown Key (scancode 41 = Escape) pressed modifiers: (none)
Text:
Unknown Key (scancode 41 = Escape) released modifiers: (none)
Sending text event
Key pressed : scancode 57 = CapsLock, keycode 0x40000039 = CapsLock
modifiers: CAPS
Text:
Key released: scancode 57 = CapsLock, keycode 0x40000039 = CapsLock
modifiers: CAPS


I pressed and released my "Esc" key and then the "Caps Lock" key, before
exitting checkkeys.


I always get the "Sending text event" stuff, but I'm just guessing
that's debug stuff builtin.


Edgar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklg9P4ACgkQolm4VNX3QTyFigCeN3ggEBebzdNseL073L8tukUB
ofsAnRFkDMykTtOnRT8SpjPd8n4wlaYn
=InmO
-----END PGP SIGNATURE-----

Okay, I see what's happening here. We're not expecting non-alphanumeric
keys to be remapped, so we're using the default mappings on X11. Can you
enter a bug in bugzilla for this?

Thanks!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


Sam Lantinga wrote:

Done! http://bugzilla.libsdl.org/show_bug.cgi?id=669 . Thanks,


Edgar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklhAAsACgkQolm4VNX3QTy3lQCcCXevTFB8cURt1fhwMGyIeJJR
SDwAoMZfBlza92TdZMgBTT+cmJKnpqIC
=ID6I
-----END PGP SIGNATURE-----

Fixed!

Key pressed : scancode 41 = Escape, keycode 0x0000001B = Escape
Key pressed : scancode 57 = CapsLock, keycode 0x0000001B = Escape

See ya!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,


Sam Lantinga wrote:


Sweet! Thanks a bunch!


Edgar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklhu08ACgkQolm4VNX3QTx9UwCfbt0MRgxnwRWhUfQ6+IE476Cp
gAIAn3ldrBRPV08spSCxdkKYiG2orDKh
=rBGe
-----END PGP SIGNATURE-----

You're welcome! `

-Sam Lantinga, Founder and President, Galaxy Gameworks LLC