I’m back… and very pleased with the way the key input API has shaken out.
When all was said and done we came up with slight variations of the same
thing and it took me a while to figure that out.
Anyway, the one last thing I would really like change is to comment out the
unicode field in SDL_keysym.
typedef struct SDL_keysym
{
SDL_scancode scancode; /< SDL physical key code - see
::SDL_scancode for details */
SDLKey sym; /< SDL virtual key code - see ::SDLKey for
details */
Uint16 mod; /< current key modifiers */
Uint32 unicode; /< OBSOLETE, use SDL_TextInputEvent
instead */
} SDL_keysym;
Leaving it in lets a lot of old program compile but doesn’t let them run. If
an SDL 1.2 program compiles without errors under 1.3 I believe it should run under 1.3. I would much rather find that a program does not compile
than have to try to figure out why it no longer runs. I also don’t think
that having SDL 1.3 send an error message to stderr or stdout is enough to
tell the programmer what is wrong. How many Windows programmers are likely
to see that output?
I’m back… and very pleased with the way the key input API has shaken
out. When all was said and done we came up with slight variations of
the same thing and it took me a while to figure that out.
Anyway, the one last thing I would really like change is to comment
out the unicode field in SDL_keysym.
typedef struct SDL_keysym
{
SDL_scancode scancode; /< SDL physical key code -
see ::SDL_scancode for details */
SDLKey sym; /< SDL virtual key code -
see ::SDLKey for details */
Uint16 mod; /< current key modifiers */
Uint32 unicode; /< OBSOLETE, use SDL_TextInputEvent
instead */
} SDL_keysym;
Leaving it in lets a lot of old program compile but doesn’t let them
run. If an SDL 1.2 program compiles without errors under 1.3 I believe
it should run under 1.3. I would much rather find that a program
does not compile than have to try to figure out why it no longer runs.
I also don’t think that having SDL 1.3 send an error message to stderr
or stdout is enough to tell the programmer what is wrong. How many
Windows programmers are likely to see that output?
Bob Pendleton
You are right, the compiler should already break the compilation instead
of having a non-working but compiling program. It’s always much easier
to find an error if the compiler already points you to the problem.
– AlbertAm Mittwoch, den 20.02.2008, 17:37 -0600 schrieb Bob Pendleton:
I think its a good idea to leave it out. After all, I thought the
whole point of 1.3 was to change some of the interfaces SDL exposes,
in doing so breaking binary compatibility for the greater good.On Wed, Feb 20, 2008 at 11:37 PM, Bob Pendleton wrote:
Leaving it in lets a lot of old program compile but doesn’t let them run. If
an SDL 1.2 program compiles without errors under 1.3 I believe it should run under 1.3. I would much rather find that a program does not compile
than have to try to figure out why it no longer runs. I also don’t think
that having SDL 1.3 send an error message to stderr or stdout is enough to
tell the programmer what is wrong. How many Windows programmers are likely
to see that output?
In my (humble) opinion, there should be no 1.2 compatibility mechanism
at all, or at least there should be some means to disable it if it
does exist. If I’m porting an SDL 1.2 app to 1.3, I don’t want to get
into the situation where I’m using some 1.2 features that may vanish in
the future. I think it would be more sane just to compile time break any
1.2 feature so that you’re forced to used the 1.3 API – a
clean break, so to speak.On Wed, 20 Feb 2008 17:37:01 -0600 Bob wrote:
Leaving it in lets a lot of old program compile but doesn’t let them
run. If an SDL 1.2 program compiles without errors under 1.3 I
believe it should run under 1.3.
Leaving it in lets a lot of old program compile but doesn’t let them
run. If an SDL 1.2 program compiles without errors under 1.3 I
believe it should run under 1.3.
In my (humble) opinion, there should be no 1.2 compatibility mechanism
at all, or at least there should be some means to disable it if it
does exist. If I’m porting an SDL 1.2 app to 1.3, I don’t want to get
into the situation where I’m using some 1.2 features that may vanish in
the future. I think it would be more sane just to compile time break any
1.2 feature so that you’re forced to used the 1.3 API – a
clean break, so to speak.
I agree with you. And, I know from experience that leaving out any
compatibility layer will make implementing and maintaining 1.3 easier. It
might even make it more reliable.
I agree with you. And, I know from experience that leaving out any
compatibility layer will make implementing and maintaining 1.3 easier. It
might even make it more reliable.
Personally if there is a way to that SDL 1.2 and 1.3/2.0 can
coexist in the standard locations, i do not need a comp. layer.
Anyway, the one last thing I would really like change is to comment out the
unicode field in SDL_keysym.
Leaving it in lets a lot of old program compile but doesn’t let them run.
Actually they do run if they use the SDL compatibility layer and use only
US input.
As to whether the compatiblity layer should exist, it’s been my experience
that many people will download it and try it out with their existing programs,
or they’ll just want to take their existing programs and want to use a few
additional features in the SDL 1.3 API.
I may make SDL_compat.h not included by default though, so you have to
take a step to enable that compatibility.
I have taken one step to explicitly break compatibility though, with the
SDL_GetKeyState() function. In SDL 1.2 it’s indexed by SDLK* constants,
but in SDL 1.3 it would crash if indexed by SDLK* constants, instead the
data should be indexed by SDL_SCANCODE* constants, and so I changed the
name of the function so (hopefully) people will read the documentation for
the new function.
See ya!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
I may make SDL_compat.h not included by default though, so you have to
take a step to enable that compatibility.
I would be happy even with just a means to disable its inclusion.
Whatever you end up doing, I think it’s quite important to make it
possible to deliberately break 1.2 compatibility.