LoadLibrary analogous function?

[Jeff_Duncan]

Greetings,

In a project that I’m working on, we would find it beneficial to be able to
dynamically load and unload component modules in the way that Win32 calls
’LoadLibrary’/‘FreeLibrary’ would allow me to do. I’m already using SDL and
I was hoping I could use it to abstract this functionality away from the
platform level, but I don’t see any related functions.

Does SDL provide this functionality? Do operating systems other than
Windows provide this functionality, for that matter (if SDL does not have
it, but you know the appropriate Linux functions, I’d appreciate that, too).

Thanks,
– Jeff

[EvilTypeGuy]

Greetings,

In a project that I’m working on, we would find it beneficial to be able to
dynamically load and unload component modules in the way that Win32 calls
’LoadLibrary’/‘FreeLibrary’ would allow me to do. I’m already using SDL and
I was hoping I could use it to abstract this functionality away from the
platform level, but I don’t see any related functions.

Does SDL provide this functionality? Do operating systems other than
Windows provide this functionality, for that matter (if SDL does not have
it, but you know the appropriate Linux functions, I’d appreciate that, too).

I don’t think SDL provides that functionality, but under linux I believe you
would use dlopen() and dlclose() to open/close a dynamic library…On Mon, Aug 27, 2001 at 10:07:39AM -0400, Jeff Duncan wrote:

Thanks,
– Jeff

[Brian_Sea]

Does SDL provide this functionality? Do operating systems other than
Windows provide this functionality, for that matter (if SDL does not have
it, but you know the appropriate Linux functions, I’d appreciate that, too).

SDL by itself does not implement cross-platform DSO (Dynamic Shared
Objects), though it is planned for SDL 1.3. In the mean time, you do
have a few options.
1) Import code for PLib: plib.sourceforge.net (C++)
2) Use a C cross platform toolkit. GTK+ and NSPR come to mind.

The Linux equivelents are:
dlopen(), dlclose(), dlsym().

These work on most UNIX systems.

Hope this helps,
–sea>

Thanks,
– Jeff

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[Guido_Draheim]

Brian Sea wrote:

The Linux equivelents are:
dlopen(), dlclose(), dlsym().

These work on most UNIX systems.

the solaris dlfcn-api was adopted widely
and it is now part of the UNIX98 specs.

http://www.opengroup.org/onlinepubs/7908799/xsh/dlopen.html

the call-scheme is almost identical to what you expect from
the win32 LoadLibrary / GetFunctionAdress, it is so similar a
#def-macro will usually work. Many wrappers and liboject-
loaders use it as a baseline, including the libltdl approach
from libtool that covers all platforms - including win32 and
unix platforms before unix98.

http://www.gnu.org/software/libtool/manual.html#Using%20libltdl

cheers,
– guido Edel sei der Mensch, hilfreich und gut
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)

[Jeff_Duncan]

Thank you both - this is exactly the information I was looking for.

On a loosely related note, is there a timeline for SDL 1.3, yet?
– Jeff

“Brian Sea” wrote in message
news:mailman.998925005.28844.sdl at libsdl.org…

Does SDL provide this functionality? Do operating systems other than
Windows provide this functionality, for that matter (if SDL does not
have

it, but you know the appropriate Linux functions, I’d appreciate that,
too).>
SDL by itself does not implement cross-platform DSO (Dynamic Shared
Objects), though it is planned for SDL 1.3. In the mean time, you do
have a few options.

1. Import code for PLib: plib.sourceforge.net (C++)
2. Use a C cross platform toolkit. GTK+ and NSPR come to mind.

The Linux equivelents are:
dlopen(), dlclose(), dlsym().

These work on most UNIX systems.

Hope this helps,
–sea

Thanks,
– Jeff

---

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[Brian_Sea]

Thank you both - this is exactly the information I was looking for.

On a loosely related note, is there a timeline for SDL 1.3, yet?

To my knowledge the 1.3 API hasn’t even been finalized. So I would
say: not in the near future

–seaOn Mon, Aug 27, 2001 at 12:47:13PM -0400, Jeff Duncan wrote:

– Jeff

[Alexandre_Courbot]

Sorry if this already figures somewhere else, but where is the 1.3 API
supposed to be discussed? This list? I’m looking forward for it and
would be pleased to add my 2 cents, provided there is room for it.

Alex.On 27 Aug 2001 12:50:11 -0500, Brian Sea wrote:

On Mon, Aug 27, 2001 at 12:47:13PM -0400, Jeff Duncan wrote:

Thank you both - this is exactly the information I was looking for.

On a loosely related note, is there a timeline for SDL 1.3, yet?

To my knowledge the 1.3 API hasn’t even been finalized. So I would
say: not in the near future

[Lloyd_Dupont]

i beleive that SDL 1.3 would have it…
anyway the corresponding linux/POSIX functions are:
dlopen/dlsym/dlclose
equivalent to
LoadLibray/GetProcAddress/FreeLibrary

[Standa_Opichal]

Thank you both - this is exactly the information I was looking for.

On a loosely related note, is there a timeline for SDL 1.3, yet?

To my knowledge the 1.3 API hasn’t even been finalized. So I would
say: not in the near future

Sorry if this already figures somewhere else, but where is the 1.3 API
supposed to be discussed? This list? I’m looking forward for it and
would be pleased to add my 2 cents, provided there is room for it.

Yes, is there any other forum to discuss the API changes needed? I have
also some experiences with SDL (I’m writing an emulator) that should
change in the future.

regards

STanOn 27 Aug 2001, Alexandre Courbot wrote:

On 27 Aug 2001 12:50:11 -0500, Brian Sea wrote:

On Mon, Aug 27, 2001 at 12:47:13PM -0400, Jeff Duncan wrote:

[Teunis_Peters]

[clip]

Sorry if this already figures somewhere else, but where is the 1.3 API
supposed to be discussed? This list? I’m looking forward for it and
would be pleased to add my 2 cents, provided there is room for it.

Yes, is there any other forum to discuss the API changes needed? I have
also some experiences with SDL (I’m writing an emulator) that should
change in the future.

I’m going to guess that ideas are being taken down and once those who
designed the (1.2-) APIs have a concrete idea of what’s in mind, they’ll
open discussion. I’ve been looking forward to this for -ages-

I’m looking forward to “SDL preference” support myself - things like
preferred videodrivers, audio, and such. (my case: X -> FBcon -> svgalib;
I run all at some point or another, but svgalib is less stable for me than
FBcon and I don’t think this is true for others)
this is from a -much- older thread…

also I know that multihead / multiwindow support is intended and one is
curious of what form that would take… (I can think of a few ways but on
a multithreaded platform all of them look complicated)

Anyhow, all I can think of is keep coming up with ideas and thinking about
them, and when you’re solid of what form they should take post them onto
the list… even if there’s no answer, it’s probably being remembered in
planning. Just try to keep it within reason g…

G’day, eh?
- Teunis

PS: now to find a way to debug GNU/assembly videocode… printfs don’t
work silly grin…On Wed, 29 Aug 2001, Standa Opichal wrote:

[Standa_Opichal]

would be pleased to add my 2 cents, provided there is room for it.

Yes, is there any other forum to discuss the API changes needed? I have
also some experiences with SDL (I’m writing an emulator) that should
change in the future.

I’m going to guess that ideas are being taken down and once those who
designed the (1.2-) APIs have a concrete idea of what’s in mind, they’ll
open discussion. I’ve been looking forward to this for -ages-

Well, let’s drive it a bit

I’m looking forward to “SDL preference” support myself - things like
preferred videodrivers, audio, and such. (my case: X -> FBcon -> svgalib;
I run all at some point or another, but svgalib is less stable for me than
FBcon and I don’t think this is true for others)
this is from a -much- older thread…

Nice to have this.

also I know that multihead / multiwindow support is intended and one is
curious of what form that would take… (I can think of a few ways but on
a multithreaded platform all of them look complicated)

Yes, the thread safety is really missing here.

Anyhow, all I can think of is keep coming up with ideas and thinking about
them, and when you’re solid of what form they should take post them onto
the list… even if there’s no answer, it’s probably being remembered in
planning. Just try to keep it within reason g…

Well, can somebody confirm this?

I’d like to see the multidriver (portable) keykodes. The SDLK_ constants
should be the scancode ekvivalents immutable with driver/platform chages.
There should be other API to get the character code of the key pressed
(these are two differrent things). Now the SDLK_ returned changes e.g.
with keyboard layout which is not good e.g. for emulator or games.

The portable dynamic libs API is also needed for application extensibility
features not present within the basic binary distribution (e.g. native
drivers for emulators)

regards

STanOn Wed, 29 Aug 2001, winterlion wrote:

On Wed, 29 Aug 2001, Standa Opichal wrote:

[Alexandre_Courbot]

would be pleased to add my 2 cents, provided there is room for it.

Yes, is there any other forum to discuss the API changes needed? I have
also some experiences with SDL (I’m writing an emulator) that should
change in the future.

I’m going to guess that ideas are being taken down and once those who
designed the (1.2-) APIs have a concrete idea of what’s in mind, they’ll
open discussion. I’ve been looking forward to this for -ages-

One of the things that would be nice to have IMO would be the
possibility to apply colormasks to surfaces, for, say, quickly (provided
it can be hardware done) lighten/darken a surface or simulate weather
effects (dark orange/red mask on the screen for the evening, etc…).
Currently I can’t find a way to quickly do this, the two solutions I
found are:

• Process each pixel one by one (ouch!)
• Blit an entire surface with the desired color (with SDL_Fillrect) and
  alpha-blit this surface on the surface to apply the color mask. This has
  the advantage of using HW acceleration, but of course, if you use a
  transparent color, it will be proceeded too. And you have to use
  SDL_Fillrect each time you want to change the mask color.

Some function similar to blitting functions to apply a single color
mask/alpha on a surface (and allowing to process the transparent color
or this surface or not) would be quite handy. I think that quite a few
people have to do such a thing, and right now it’s quite hard to do it
fast with SDL.

Don’t know whether there already is a short specification of 1.3 - but I
guess this highly depends on the free time of the core developers.

Alex.On 29 Aug 2001 11:29:39 +0200, Standa Opichal wrote:

On Wed, 29 Aug 2001, winterlion wrote:

On Wed, 29 Aug 2001, Standa Opichal wrote:

[Teunis_Peters]

[clip]

also I know that multihead / multiwindow support is intended and one is
curious of what form that would take… (I can think of a few ways but on
a multithreaded platform all of them look complicated)

Yes, the thread safety is really missing here.

Actually SDL’s thread safety’s quite good - those areas where it’s
difficult -have- to be handled by the program using SDL. There’s some
funny areas (such as main thread only works with video et al) but that’s
due to software restrictions on many platforms and getting around it is
difficult.

I suspect that multiple window support is either going to require the same
complications or add a whole lot of new ones… and I’m wondering how
it’ll work under FBdev for instance g. (I use FB quite heavily, much in
preference to anything else really except when I have to work with OpenGL)

[clip]

I’d like to see the multidriver (portable) keykodes. The SDLK_ constants
should be the scancode ekvivalents immutable with driver/platform chages.
There should be other API to get the character code of the key pressed
(these are two differrent things). Now the SDLK_ returned changes e.g.
with keyboard layout which is not good e.g. for emulator or games.

May not be possible. Actually I suspect it isn’t… scancodes are
hardware-dependant and so are what keys present. It also somewhat varies
with language… and then there’s the weird keyboards like the main one I
use (Microsoft Natural Pro USB) which has about 19 extra keys and the
Chinese one I play with from time to time. (no extra keys but almost
every key lists 3-4 characters more than the standard). There’s the
European keyboards, which tend to occasionally move scancodes around, and
who can forget Dvorak?

What I’d -like- to see is full internationalization on what platforms
support it - so that eg. Japanese/Chinese/… data entry works. I’m not
holding my breath though so I’m trying to figure out how to implement it
myself. Most games won’t need this feature and since SDL is primarily
still targetted towards game devel…

But at least I’d like to see SDL capable of knowing what keyboard is
present (ref: SDL preferences support + maybe some local probes as most
OSs keep a record of hardware) (linux is a noteworthy exception for the
most part although X has the setting)

The portable dynamic libs API is also needed for application extensibility
features not present within the basic binary distribution (e.g. native
drivers for emulators)

AFAIK this is already written…
my thoughts on this one are simple though - if SDL didn’t itself need it,
why require SDL to have it? except SDL needs it so

I’d love to see audio recording capabilities (noone’s brought -those- up
amongst the SDL core folks IIRC) and full MIDI!!! (I work with both
(well not full MIDI - I just want to be able to get SDL events from my
MIDI keyboard

G’day, eh?
- TeunisOn Wed, 29 Aug 2001, Standa Opichal wrote:

On Wed, 29 Aug 2001, winterlion wrote:

[Sam_Hart]

What I’d -like- to see is full internationalization on what platforms
support it - so that eg. Japanese/Chinese/… data entry works. I’m not
holding my breath though so I’m trying to figure out how to implement it
myself. Most games won’t need this feature and since SDL is primarily
still targetted towards game devel…

I’ll admit that most SDL apps wont need this feature… but I feel that
enough of them do to make it important.

(Tux Typing, for example, /really/ needs this due to some
internationalization issues we’ve recently run into

I’d love to see audio recording capabilities

Yeah, you’re not alone

Actually, we were talking about this very thing for 1.3 a while ago (good
luck trying to find the original thread, cuz I can’t ;-). Sam Lantinga said
that he wanted to try to add this support.

Hopefully, that’s still the plan ;-)On Wednesday 29 August 2001 12:24pm, winterlion wrote:

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Tux4Kids: < http://www.geekcomix.com/tux4kids/ >

[Standa_Opichal]

[clip]

I’d like to see the multidriver (portable) keykodes. The SDLK_ constants
should be the scancode ekvivalents immutable with driver/platform chages.
There should be other API to get the character code of the key pressed
(these are two differrent things). Now the SDLK_ returned changes e.g.
with keyboard layout which is not good e.g. for emulator or games.

May not be possible. Actually I suspect it isn’t… scancodes are
hardware-dependant and so are what keys present. It also somewhat varies
with language… and then there’s the weird keyboards like the main one I
use (Microsoft Natural Pro USB) which has about 19 extra keys and the
Chinese one I play with from time to time. (no extra keys but almost
every key lists 3-4 characters more than the standard). There’s the
European keyboards, which tend to occasionally move scancodes around, and
who can forget Dvorak?

Well, Xes (X windows) does this pretty well, doesn’t they?
I think Xes does have “multikeyboard” scancodes. I think there should be
as many SDLK_ s as there exists particular keys on all keyboards. The
scancodes conversion should do the OS, doesn’t it? Another conversion does
Xes.
BTW: There was a thread a month ago where someone agreed with this
proposal.

But at least I’d like to see SDL capable of knowing what keyboard is
present (ref: SDL preferences support + maybe some local probes as most
OSs keep a record of hardware) (linux is a noteworthy exception for the
most part although X has the setting)

Well, this could be another additional feature.

The portable dynamic libs API is also needed for application extensibility
features not present within the basic binary distribution (e.g. native
drivers for emulators)

AFAIK this is already written…
my thoughts on this one are simple though - if SDL didn’t itself need it,
why require SDL to have it? except SDL needs it so

SDL doesn’t need it as well as audio recording capability.

(well not full MIDI - I just want to be able to get SDL events from my
MIDI keyboard

This might be nice as well.

regards

STanOn Wed, 29 Aug 2001, winterlion wrote:

[John_R_Hall]

[clip]

I’d like to see the multidriver (portable) keykodes. The SDLK_ constants
should be the scancode ekvivalents immutable with driver/platform
chages.
There should be other API to get the character code of the key pressed
(these are two differrent things). Now the SDLK_ returned changes e.g.
with keyboard layout which is not good e.g. for emulator or games.

May not be possible. Actually I suspect it isn’t… scancodes are
hardware-dependant and so are what keys present. It also somewhat varies
with language… and then there’s the weird keyboards like the main one
I
use (Microsoft Natural Pro USB) which has about 19 extra keys and the
Chinese one I play with from time to time. (no extra keys but almost
every key lists 3-4 characters more than the standard). There’s the
European keyboards, which tend to occasionally move scancodes around, and
who can forget Dvorak?

Well, Xes (X windows) does this pretty well, doesn’t they?
I think Xes does have “multikeyboard” scancodes. I think there should be
as many SDLK_ s as there exists particular keys on all keyboards. The
scancodes conversion should do the OS, doesn’t it? Another conversion does
Xes.
BTW: There was a thread a month ago where someone agreed with this
proposal.

For what it’s worth: There are several layers of keyboard code mapping.

kscan codes - physical scancodes reported by the keyboard to the
controller over the serial link. You never see these, but if you really
wanted to, you could get them if you knew where to look.
scancodes - somewhat system-dependent multi-byte codes reported by the
hardware to the OS.
keycodes - 8-bit codes reported by the kernel in raw or mediumraw modes.
High bit is press/release, lower 7 bits are the key number. This is where
keymaps come in. Note that the X Window System IGNORES keycodes entirely
and performs its own scancode processing. This is why console keymaps don’
t have any effect in X. There are also 8 bits of modifier flags, to handle
shift, alt, control, and various international keys.

If I recall correctly, the SDLK_ constants map to keycodes. SDL queries
the kernel for the meaning of keycodes to handle internationalization.

Chapter 8 of Programming Linux Games discusses this whole mess.

-JohnOn Wednesday, August 29, 2001, at 07:15 PM, Standa Opichal wrote:

On Wed, 29 Aug 2001, winterlion wrote:

–
John R. Hall | Overfull \brain has occurred while \learn is active
CS Student - Georgia Tech | Author - Programming Linux Games
Unsolicited commerical e-mail will be considered an act of war.

[Teunis_Peters]

[clip internationalization - taking this out of SDL list for now…]

I’d love to see audio recording capabilities

Yeah, you’re not alone

Actually, we were talking about this very thing for 1.3 a while ago (good
luck trying to find the original thread, cuz I can’t ;-). Sam Lantinga said
that he wanted to try to add this support.

Hopefully, that’s still the plan

All going well - as near as I can tell:
windows : SDL audio and record/windows do -not- mix… I think
this may be the easiest platform to support
BeOS: or maybe this will - I don’t know Be programming though
MacOS: from what I’ve seen fairly straightforeward too…
linux:
OSS: workable, no prob
ALSA: no idea
ESD: doesn’t do bidirectional… or it doesn’t work…
ARTSD: claims bidirectional, then halts on my machine ???
Unix/non-linux: usually as per OSS - straightforeward

If it weren’t for linux it’d be easy on all platforms… but linux is
probably going to require other features to be present at a guess.

My suggestion on API btw: (should look familiar

to SDL_AudioSpec add:
int recfreq; /* DSP frequency – samples per second /
Uint16 recformat; / Audio data format /
Uint8 recchannels; / Number of channels: 1 mono, 2 stereo /
Uint8 recsilence; / Audio buffer silence value (calculated) /
Uint16 recsamples; / Audio buffer size in samples /
Uint16 recpadding; / Necessary for some compile environments /
Uint32 recsize; / Audio buffer size in bytes (calculated) */
void (*recordcallback)(void *userdata, Uint8 stream, int len);
/ where stream contains the recorded audio */

extern DECLSPEC SDL_audiostatus SDL_GetAudioStatusRecording(void);
extern DECLSPEC void SDL_PauseAudioRecording(int pause_on);
extern DECLSPEC void SDL_LockAudioRecording(void);
extern DECLSPEC void SDL_UnlockAudioRecording(void);
/* as per SDL_… but for recording channel */

I’m not 100%… the problem is there’s multiple devices to record -from-, and
that also implies volume control. Now I’ll admit you could simplify it down
to default-source such as windows uses… at a guess linux would -definitely-
need preference support as it does -not- support "default audio record/play"
systems in the same way. (and not all cards are bidirectional, and some people
(like me for instance) have multiple soundcards and use multiple sound drivers.

but be aware that in many instances using SDL_Audio -and- trying to record
audio won’t work on most platforms.

G’day, eh?
- Teunis

PS: I got stuck with this when working on AV streaming… so it got put
on hold until I could figure a solution out. I still don’t have one.On Wed, 29 Aug 2001, Samuel Hart wrote:

On Wednesday 29 August 2001 12:24pm, winterlion wrote:

[Teunis_Peters]

[clip on odd scancodes]

Well, Xes (X windows) does this pretty well, doesn’t they?
I think Xes does have “multikeyboard” scancodes. I think there should be
as many SDLK_ s as there exists particular keys on all keyboards. The
scancodes conversion should do the OS, doesn’t it? Another conversion does
Xes.
BTW: There was a thread a month ago where someone agreed with this
proposal.

answer : not everyone uses Xwindows. Not even everyone who uses unix. I
certainly avoid it unless forced to otherwise and I’m interested in
implementing (or testing anyways) these features…

What’s “Xes” anyways?

[on SDL prefs] - again afaik this is a planned 1.3 feature

The portable dynamic libs API is also needed for application extensibility
features not present within the basic binary distribution (e.g. native
drivers for emulators)

AFAIK this is already written…
my thoughts on this one are simple though - if SDL didn’t itself need it,
why require SDL to have it? except SDL needs it so

SDL doesn’t need it as well as audio recording capability.

Again - SDL -needs- this apparently. Otherwise it wouldn’t matter to SDL.
I mean the current module system wouldn’t have calls if it wasn’t used
internally, right?
and on audiorecording: other message g… I still don’t view
audiorecording as vital to most people but I’m going to guess it’s need is
going to increase as people use it more. There are very few computers
with audio capability that can’t record… (even PS2 can although you’d
need a USB device to handle recording and write the driver yourself

(well not full MIDI - I just want to be able to get SDL events from my
MIDI keyboard

This might be nice as well.

So whoever commented on this before - WHERE IS IT???

G’day, eh?
- Teunis (hmm maybe I should be quiet for a couple of days about
this thread… it’s not like I’m a core developer… :)On Thu, 30 Aug 2001, Standa Opichal wrote:

[Joseph_Carter]

I’d love to see audio recording capabilities
[…]

Hopefully, that’s still the plan

All going well - as near as I can tell:
windows : SDL audio and record/windows do -not- mix… I think
this may be the easiest platform to support

It probably should be reasonably easy.

[…]

linux:
OSS: workable, no prob
ALSA: no idea
ALSA: no problem

  ESD: doesn't do bidirectional... or it doesn't work...
  ARTSD: claims bidirectional, then halts on my machine ???

	ESD: Not a chance, forget it.

My emu10k1 supports some very cool routing in the card… I can
essentially set up /dev/dsp1 for playback over headset and still use
/dev/dsp for (2 or 4 channel) sound through a pair of digital speakers.
It would generally be very cool to have voice communication for
multiplayer games. There are codecs which compress well enough to fit
alongside a game connection over a 33.6 modem. They sound like crap of
course, but for the military/shooter type games they end up sounding like
military radio in the middle of a fight. Suppose that’s one way to turn a
flaw into an advantage, eh?

Anyway, I’m sure I’m not the only person thinking this direction.On Thu, Aug 30, 2001 at 12:18:21AM -0700, winterlion wrote:

–
Joseph Carter Free software developer

it’s weird, when you go on a safari to Africa to catch a lion, you
find it alive and it charges, and then you kill it
when you go on a safari to South Bay to find a Palm Vx, you find
it dead and take it home and it charges after it arrives

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010830/55d91b28/attachment.pgp

[Standa_Opichal]

I think Xes does have “multikeyboard” scancodes. I think there should be
as many SDLK_ s as there exists particular keys on all keyboards. The
scancodes conversion should do the OS, doesn’t it? Another conversion does
Xes.
BTW: There was a thread a month ago where someone agreed with this
proposal.

For what it’s worth: There are several layers of keyboard code mapping.

kscan codes - physical scancodes reported by the keyboard to the
controller over the serial link. You never see these, but if you really
wanted to, you could get them if you knew where to look.
scancodes - somewhat system-dependent multi-byte codes reported by the
hardware to the OS.

Yes, sure.

keycodes - 8-bit codes reported by the kernel in raw or mediumraw modes.
High bit is press/release, lower 7 bits are the key number. This is where
keymaps come in.
Note that the X Window System IGNORES keycodes entirely and performs
its own scancode processing. This is why console keymaps don’t have
any effect in X. There are also 8 bits of modifier flags, to handle
shift, alt, control, and various international keys.

This is what we should handle independently. The problem I see with SDL is
that if I use setxkbmap in X Windows then I got differrent SDLK_ for the
same key as before using it. This implies that e.g. car simulator control
doesn’t have the control keys set correctly…
The character pressed is another thing than SDLK_ I think. The SDLKs
should become scancode alalogy (but driver/OS/platform independent). There
should be another API function returning the character typed, which should
be converted according to e.g. xkbmap or any other keyborad layout
setting.

If I recall correctly, the SDLK_ constants map to keycodes. SDL queries
the kernel for the meaning of keycodes to handle internationalization.

Well, I think there shoudn’t be the internacionalization feature for SDLK_
constants handling.

Chapter 8 of Programming Linux Games discusses this whole mess.

Good to know.

regards

STanOn Wed, 29 Aug 2001, John R. Hall wrote: