Sdl 1.3

Hello !

Keyboard Support in SDL 1.3 :

When SDL 1.3 will be out, how is
keyboard support working then :

Will Shift-a report a different
thing, then a only ?
Will there still be an easy way to
ask for “Shift”, “Ctrl” and so on ?

CU

Will Shift-a report a different
thing, then a only ?

No, shift-a will return ‘a’ as the keysym.

Will there still be an easy way to
ask for “Shift”, “Ctrl” and so on ?

It will work the same way it does now. Watch for the keysyms if you
care about those, the unicode messages if you care about those, or poll
the key state if you’re doing that instead.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Hello !

Will Shift-a report a different
thing, then a only ?

No, shift-a will return ‘a’ as the keysym.

Will there still be an easy way to
ask for “Shift”, “Ctrl” and so on ?

It will work the same way it does now. Watch for the keysyms if you
care about those, the unicode messages if you care about those, or poll the
key state if you’re doing that instead.

For example a german and american keyboard,
will they report a different keysym for “z” ?

CU

Sam Lantinga wrote:

Will Shift-a report a different
thing, then a only ?

No, shift-a will return ‘a’ as the keysym.

BTW, I know you’ve decided that keysym should always be the unicode char the
key would return when pressed unshifted, but could you make a small
exception for the number keys between the Fx keys and the letter keys.

Reason beeing that a few keymaps require shift to produce numbers with those
keys and return a few uncommon letters if unshifted. And a lot of code
wrongly assume that those keys are present on a keyboard. Not sure if it’s
a good idea of course, maybe we should instead educate users about that
but …

Sam Lantinga wrote:

It will work the same way it does now.

I suppose you’re aware of the fact that the way it works now is
inconsistent between platforms?
(http://article.gmane.org/gmane.comp.lib.sdl/24697)

-Christian

BTW, I know you’ve decided that keysym should always be the unicode char the
key would return when pressed unshifted, but could you make a small
exception for the number keys between the Fx keys and the letter keys.

Reason beeing that a few keymaps require shift to produce numbers with those
keys and return a few uncommon letters if unshifted. And a lot of code
wrongly assume that those keys are present on a keyboard. Not sure if it’s
a good idea of course, maybe we should instead educate users about that
but …

Yeah, World of Warcraft actually makes that exception for French keyboards
as well. SDL can do the same, if we want to be nice. :slight_smile:

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Sam Lantinga wrote:

It will work the same way it does now.

I suppose you’re aware of the fact that the way it works now is
inconsistent between platforms?

Yep, that’s one of the things I hope to fix.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

For example a german and american keyboard,
will they report a different keysym for “z” ?

If by “z” you mean the key at the lower left next to the left-shift, then yes.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

It would be great if 1.3 could provide minimal directX support for opengl.
Just the basic drawing functions, alpha and z buffer.

Thats called opengl.On Thursday 16 February 2006 08:05, Chris Ball wrote:

It would be great if 1.3 could provide minimal directX support for
opengl. Just the basic drawing functions, alpha and z buffer.


Patrick “Diablo-D3” McFarland || @Patrick_McFarland
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids,
we’d all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." – Kristian Wilson, Nintendo,
Inc, 1989

Thats called opengl.

Too many PCs don’t support opengl, and some have a slow implementation.

(…and it seems like certain entities are deliberately trying to
destroy OpenGL. >:-( )

Anyway, the net result is that OpenGL is only a safe bet if you’re
targetting “power users” and hardcore gamers. Lots of "casual gamers"
are using hardware with useless on non-existant OpenGL support - or
they don’t have OpenGL drivers installed, which is effectively the
same thing, as they’re not going to do any "weird technical stuff"
just to make your game work.

What to do about it? Well, if you’re trying to make money, I don’t
think you can afford to ignore this issue.

Unfortunately, an OpenGL -> Direct3D wrapper is probably going to be
either a big job or pretty useless - or both, if it turns out wrong.
Anything serious, Free/Open Source we might use or base something on?
(I’ve seen a few wrappers that go the other way, but no thanks!
Windows is the one with the odd API, so Windows gets the wrapper,
IMNSHO.)

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 16 February 2006 19:09, Chris Ball wrote:

Thats called opengl.

Too many PCs don’t support opengl, and some have a slow
implementation.

Chris Ball wrote:

It would be great if 1.3 could provide minimal directX support for opengl.
Just the basic drawing functions, alpha and z buffer.

That kind of thing already exists, see for example :
http://www.scitechsoft.com/products/ent/gld_home.php

However, I don’t think it has anything to do with SDL. If you want to
use it, it replaces your opengl32.dll, which SDL in turns uses. SDL
doesn’t really care if opengl32.dll is just a wrapper around directx, or
a real OpenGL driver.

Stephane

Thats called opengl.

Too many PCs don’t support opengl, and some have a slow implementation.

That is not entirely correct. Many PCs do not have the hardware needed
to support a fast implementation of OpenGL and many that do have the
needed hardware do not have the drivers needed to provide fast OpenGL.

OTOH, the answer you got is the only answer I know of to the question
you asked. Is it possible that you were asking that SDL expose support
for depth buffers and so on with out requiring the use of OpenGL? That
is a very different question and is likely to get a different answer.

	Bob PendletonOn Thu, 2006-02-16 at 18:09 +0000, Chris Ball wrote:

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


±-------------------------------------+

Is it possible that you were asking that SDL expose support
for depth buffers and so on with out requiring the use of OpenGL?

What would be great is this: SDL’s drawing functions (I’m only somewhat
familiar with those) ported to opengl and directx, and a super-set of
functions added. How does that sound? That way SDL can provide some
immunity to changes in opengl/directx and allow programmers to
concentrate on their work instead of burying themselves in the endless
hell of long-winded platform-specific documentation.

The fancy functions don’t have to be supported. When I write cross-
platform code, I make a point not to use anything that is not likely to port,
to the tune of 90% of opengl. Draw lines and triangles only, gouraud or
texture, modulate and maybe highlight, z-buffer, no alpha buffer. I can do
nearly anything with that.

Chris

Is it possible that you were asking that SDL expose support
for depth buffers and so on with out requiring the use of OpenGL?

What would be great is this: SDL’s drawing functions (I’m only somewhat
familiar with those) ported to opengl and directx, and a super-set of
functions added. How does that sound? That way SDL can provide some
immunity to changes in opengl/directx and allow programmers to
concentrate on their work instead of burying themselves in the endless
hell of long-winded platform-specific documentation.

The fancy functions don’t have to be supported. When I write cross-
platform code, I make a point not to use anything that is not likely to port,
to the tune of 90% of opengl. Draw lines and triangles only, gouraud or
texture, modulate and maybe highlight, z-buffer, no alpha buffer. I can do
nearly anything with that.

This has been talked about, off and on, for a long time. It doesn’t
exist because nobody seems to want it badly enough to write it. I
believe that a fairly small set of graphics operations and buffer types
could be identified and supported to cover more than 90% of all
applications. But, like I said, nobody seems to want it enough to work
on it. In the long run, features get into SDL more because people vote
with their work than because a feature would be a good idea.

	Bob PendletonOn Sat, 2006-02-18 at 01:16 +0000, Chris Ball wrote:

Chris


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


±-------------------------------------+

Isn’t that Mesa?On Sat, 2006-02-18 at 14:43 -0600, Bob Pendleton wrote:

The fancy functions don’t have to be supported. When I write cross-
platform code, I make a point not to use anything that is not likely to port,
to the tune of 90% of opengl. Draw lines and triangles only, gouraud or
texture, modulate and maybe highlight, z-buffer, no alpha buffer. I can do
nearly anything with that.

This has been talked about, off and on, for a long time. It doesn’t
exist because nobody seems to want it badly enough to write it.


John Skaller
Felix, successor to C++: http://felix.sf.net

Theoretically, yes, and there is indeed a Direct3D driver. Don’t know
how mature it is, and I haven’t tried it. According to the README,
it’s using DirectX 6 only, so I would assume anything but the basic
features would result in s/w rendering fallback - but that’s probably
more than sufficient for most advanced 2D rendering, and basic 3D
stuff.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Sunday 19 February 2006 04:17, skaller wrote:

On Sat, 2006-02-18 at 14:43 -0600, Bob Pendleton wrote:

The fancy functions don’t have to be supported. When I write
cross-platform code, I make a point not to use anything that is
not likely to port,
to the tune of 90% of opengl. Draw lines and triangles only,
gouraud or texture, modulate and maybe highlight, z-buffer, no
alpha buffer. I can do nearly anything with that.

This has been talked about, off and on, for a long time. It
doesn’t exist because nobody seems to want it badly enough to
write it.

Isn’t that Mesa?

David Olofson wrote:>On Sunday 19 February 2006 04:17, skaller wrote:

On Sat, 2006-02-18 at 14:43 -0600, Bob Pendleton wrote:

The fancy functions don’t have to be supported. When I write
cross-platform code, I make a point not to use anything that is
not likely to port,
to the tune of 90% of opengl. Draw lines and triangles only,
gouraud or texture, modulate and maybe highlight, z-buffer, no
alpha buffer. I can do nearly anything with that.

This has been talked about, off and on, for a long time. It
doesn’t exist because nobody seems to want it badly enough to
write it.

Isn’t that Mesa?

Theoretically, yes, and there is indeed a Direct3D driver. Don’t know
how mature it is, and I haven’t tried it.

The Mesa DirectX driver doesn’t work any more because of internal API
changes. Resurecting it should not be too hard, and could make an
interesting project.
Also, Scitech’s GLDirect is based on this driver.

Stephane

The fancy functions don’t have to be supported. When I write cross-
platform code, I make a point not to use anything that is not likely to port,
to the tune of 90% of opengl. Draw lines and triangles only, gouraud or
texture, modulate and maybe highlight, z-buffer, no alpha buffer. I can do
nearly anything with that.

This has been talked about, off and on, for a long time. It doesn’t
exist because nobody seems to want it badly enough to write it.

Isn’t that Mesa?

Not really. Mesa is full blown OpenGL, not a subset. And, AFAIK, mesa
doesn’t currently include a driver for DirectX. There is a very old
version that works on top of a very old version of DirectX, and there is
a commercial package from
http://www.scitechsoft.com/products/ent/gld_home.php that implements
OpenGL on top of DirectX that is based on mesa.

IMHO there is a place for a fairly small subset of OpenGL/DirectX that
would be sufficient for 80 to 90 percent of applications. But, I am also
very much aware that over time there is strong pressure to turn a subset
set into a full grown, full feature, system. Then there is the fact that
no one seems to think it is a good enough idea to actually implement
it.

	Bob PendletonOn Sun, 2006-02-19 at 14:17 +1100, skaller wrote:

On Sat, 2006-02-18 at 14:43 -0600, Bob Pendleton wrote:


±-------------------------------------+