OpenGL Swap Method

SDL Development
1

Hi,

A problem with using OpenGL for 2D work is that the backbuffer is undefined after a buffer swap.

Either a blit from front to back occurs, or a page flip (buffers swapped), or a new back buffer is given to you from some arbitrary area of video RAM, and in general, you can’t tell what behaviour you’re getting (unlike 2D SDL, where you can tell).

For a lot of 2D GUI work, most of the screen remains static and at high resolutions it is just not practical to redraw the whole screen every frame even if you render the scene to textures and just tile them each frame (try this at 1280x1024). Plus, it’s a lot of extra work to maintain those textures.

There are 2 extensions that I know of that might be useful:

GLX_OML_swap_method for X11 and GL_WIN_swap_hint for Windows.

GLX_OML_swap_method allows you to request a specific swap behaviour when you create the GLXFBConfig: copy, swap or don’t care.

GL_WIN_swap_hint allows you to mark certain areas of the back buffer as changed, which can reduce the bandwidth to update the scene and, presumably (I haven’t tried) means that other areas are left untouched, giving you “copy” behaviour.

(You can also request the swap behaviour when the visual is created, but the MSDN documention for glAddSwapHintRectWIN says you should use this GL_WIN_swap_hint extension instead)

Both cases require work at the point the window is created, so they need to be done within the SDL library.

I think it would be a good idea to be able to pass something like SDL_OPENGL_COPY_BUFFERS or SDL_OPENGL_SWAP_BUFFERS to SDL_SetVideoMode, and have a way of querying the outcome.

If these extensions are widely supported, do others think it would be a good addition?

My i810 under Linux does not support GLX_OML_swap_method, but my Radeon 7500 does under Linux, and a friend’s NVidia 5200 does under Windows.

I had a cursory look through the results at http://shinh.skr.jp/sdlbench/showtestgl.cgi (great resource btw) and it seems that all Windows drivers support it, but only ATI drivers for Linux and I couldn’t find a MacOSX one that did.

[ Idea for Tsuyoshi Iguchi: maybe set up a query interface so people can enter the name of an extension and you could display the cards and operating systems combos that support it? (and as a percentage of the total on file :slight_smile: ]

I know from previous discussions re vsync that people aren’t happy implementing for something that might not be available (you should make your program run well regardless), but I would rather ask for the behaviour I want and then limit what is shown to the user if it isn’t available or allow the user to force a particular behaviour if it turns out it is occuring anyway (e.g. my i810 under windowed linux X11 does copy the buffer even though it doesn’t support the extension).

And if there is going to be an OpenGL backend for SDL, can anyone explain how this will be addressed there?

Apologies for the length of the post, but I think it is an interesting topic.

Regards,

Scott

2

Greetings!

I’m new here, but I’ve been programming in SDL for quite a while now.
To Sam Lantinga and all of the other developers: Great work! I’m even
actively promoting its use in my graphics classes, in place of GLUT.
This is to the extreme delight of most of my students, since they tend
to write games for their projects.

Recently I’ve been toying around with OpenGL and SDL on Linux (x86 and
Playstation 2). I’m currently experimenting with getting ps2gl and SDL
to work at the same time, with some success (mostly hindered by the
problem I’m about to discuss). And yes, I’m planning to submit a ps2gl
patch once I finally understand SDL’s internals. It’s about time I
contributed to open source in a l33t way. :wink:

However, while I was trying to get joystick and mouse input support to
work, I discovered that both joystick and mouse events seem to be
ignored if the video subsystem is not initialized.

To illustrate with code:

 SDL_Init(SDL_INIT_JOYSTICK);

 // initialize SDL_joystick structs

 SDL_JoystickEventState(SDL_ENABLE);
 do
 {
     if (SDL_PollEvent(&event))
     {
         if (event.type == SDL_JOYAXISMOTION)
             printf("Motion detected!\n");
     }
 }
 while (event.type != SDL_Quit);

The above code doesn’t seem to work, but if SDL_INIT_VIDEO is added to
the init list, the problem is fixed.

I’m guessing that it’s not related to windowing, because I experience
the same thing on the PS2 as I do on x86.

Is this behavior normal, or is this a bug (and if so, what’s causing
it)? I hope this is one of those fixable bugs because on the PS2 the
video subsystem cannot be initialized side-by-side with ps2gl without
wreaking havoc on the system. The other subsystems (like audio) seem to
work standalone, however.

I’m trying to get up to speed on the SDL library code so I can examine
the problem myself, but in the meantime it would be helpful if someone
here already knows where to look and maybe point me in the right
direction. :slight_smile:

On a related note, what’s the intended behavior of initializing the
video subsystem with OpenGL support (at least on x86)? Should it
disallow the user from performing any 2-D operations (blitting, etc.)?
If so, it would tremendously ease my pain once I get around to writing
the ps2gl wrapper.–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

3

A funny thing happened (to me, at least).

I just read the documentation extra-hard and saw that fine print where
it says that event handling is initialized with SDL_INIT_VIDEO.
(docs/html/event.html)

Sorry for making a fool of myself.

It’s still a problem for me, however, because that still means I can’t
get mouse and keyboard input under the PS2 if I’m also going to use ps2gl.

Just an idea: Would it be better if event handling were initialized in
a separate subsystem entirely? That way no 2-D hardware video stuff
needs to get initialized with event processing, in effect decoupling the
two. The immediate benefit is that events can still work on the PS2 and
I can have nice GL graphics. :slight_smile: This might also be useful for apps
without windows, since events are the preferred method of handling
joystick actions.–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

4

A funny thing happened (to me, at least).

I just read the documentation extra-hard and saw that fine print where
it says that event handling is initialized with SDL_INIT_VIDEO.
(docs/html/event.html)

Sorry for making a fool of myself.

It’s still a problem for me, however, because that still means I can’t
get mouse and keyboard input under the PS2 if I’m also going to use ps2gl.

Just an idea: Would it be better if event handling were initialized in
a separate subsystem entirely?

Not really, since on most OSes you can’t get input events until after
you have initialized a video device. Not to mention that to make that
change would cause all existing SDL programs to stop working. That
would seriously upset a very large number of people.

That way no 2-D hardware video stuff
needs to get initialized with event processing, in effect decoupling the
two.

No 2d hardware video stuff ever needs to be initialized when
initializing the video subsystem. At least not on platforms that
implement OpenGL because you have two choices, use the 2D API or use
OpenGL.

It would seem that what you want to do is modify the ps2 version of SDL
to support ps2gl the same way SDL supports OpenGL on other platforms.
Sounds like a nice project for someone that wants to learn the internals
of SDL.

The immediate benefit is that events can still work on the PS2 and
I can have nice GL graphics. :slight_smile:

And, like I said, mess up the rest of the world. Of course, you are free
to modify your own personal version of SDL to do anything you want.

This might also be useful for apps
without windows,

That is what the dummy display device is for.

since events are the preferred method of handling
joystick actions.

Which also is the preferred what to handle keyboard, mouse, and all
other types of events. In other words, I don’t see the point you are
trying to make here.

	Bob PendletonOn Sat, 2004-11-20 at 08:21, Eric Vidal wrote:

–
±-------------------------------------+

5

http://delphi3d.net/hardware/index.php is also a good reference site.
You can select an extension and see which card/drivers support it. For
example,
http://delphi3d.net/hardware/extsupport.php?extension=GL_WIN_swap_hintOn Sat, 2004-11-20 at 03:00, Scott Cooper wrote:

I had a cursory look through the results at
http://shinh.skr.jp/sdlbench/showtestgl.cgi (great resource btw) and
it seems that all Windows drivers support it, but only ATI drivers for
Linux and I couldn’t find a MacOSX one that did.

–
Petri Latvala

6

Just an idea: Would it be better if event handling were initialized in
a separate subsystem entirely? That way no 2-D hardware video stuff
needs to get initialized with event processing, in effect decoupling the
two.

Actual 2D initialization only happens in SDL_SetVideoMode().
Initializing the video driver simply checks to see which video drivers
are available, and gets a list of video modes, etc. You only ever set
a graphics mode or do anything that would require fiddling with the
hardware settings if the application requests it.

BTW, you don’t have to support any of the SDL 2D API in OpenGL mode. :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

7

Not really, since on most OSes you can’t get input events until after
you have initialized a video device. Not to mention that to make that

Why does it have to be the video device? AFAIK in Windows, events don’t
need to be associated to a video device; just to a window handle (which
may even be NULL at times). I don’t know how it works on unices, though.

change would cause all existing SDL programs to stop working. That
would seriously upset a very large number of people.

Oops, sorry about that, people. But it may be a good idea for new
versions of SDL, perhaps a new semantic in 1.3 (wow, will we ever get
there?) along with multiple windowing and others?

No 2d hardware video stuff ever needs to be initialized when
initializing the video subsystem. At least not on platforms that
implement OpenGL because you have two choices, use the 2D API or use
OpenGL.

In that case, I think there might be a problem with the PS2 version in
that it screws my video royally (even requiring a reboot) when I
initialize the video subsystem without actually using it. Maybe SDL
does something funky to the GS and the VPUs already before setting video
modes? (Can anyone give me a heads up on how SDL uses the PS2 hardware
currently? I’ll be looking into this more closely, but I would really
appreciate it if anyone can help me get up to speed. :))

It would seem that what you want to do is modify the ps2 version of SDL
to support ps2gl the same way SDL supports OpenGL on other platforms.

That’s exactly what I want to do. :slight_smile: I’ve been reading old posts in
this list and it seems like quite a few people have been waiting for
this for a long time. I’m just glad I’ve now got 7 PS2 linux kits lying
around in my cube… (cue beowulf cluster jokes)

since events are the preferred method of handling
joystick actions.

Which also is the preferred what to handle keyboard, mouse, and all
other types of events. In other words, I don’t see the point you are
trying to make here.

Sorry about that. I was just trying to say that maybe having a separate
subsystem for events would be a better way to go about doing things,
since it’s so ubiquitous and yet there doesn’t seem to be a good reason
to couple it with video, of all things.–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

8

Sam Lantinga wrote:

Actual 2D initialization only happens in SDL_SetVideoMode().
Initializing the video driver simply checks to see which video drivers
are available, and gets a list of video modes, etc. You only ever set

OK, so it is a PS2-specific problem then. Hmmm.

BTW, you don’t have to support any of the SDL 2D API in OpenGL mode. :slight_smile:

Great! Thanks, Sam!–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

9

Not really, since on most OSes you can’t get input events until after
you have initialized a video device. Not to mention that to make that

Why does it have to be the video device? AFAIK in Windows, events don’t
need to be associated to a video device; just to a window handle (which
may even be NULL at times). I don’t know how it works on unices, though.

The SDL video device is an abstraction that hides the details of how
video is done on a specific OS/Hardware combination. On Windows the
video device is, to the best of my knowledge, a window. You don’t
normally get input events without having a window to get them from. On
X11 based systems you get events through a connection to a display plus
a window. On both systems the windowing system seems to own most of the
input devices. OTOH, if you are using a low level hardware driver then
SDL gets input how ever it can, usually be directly accessing the input
devices through the OS.

I’ve just been looking at the top level input code for SDL and the low
level input code for Linux. There is different joystick code depending
on whether you are using Linux or one of the BSD unices. There is
different code for each OS that is supported.

change would cause all existing SDL programs to stop working. That
would seriously upset a very large number of people.

Oops, sorry about that, people. But it may be a good idea for new
versions of SDL, perhaps a new semantic in 1.3 (wow, will we ever get
there?) along with multiple windowing and others?

First off, a major semantic change like you are proposing would require
that the version number be bumped to 2.0. Secondly, why do you think
your needs are so important that it is worth breaking the semantics for
every other programmer who uses SDL? Thirdly, version 1.3 is being
worked on. I, personally, am spending every spare second I have working
on features for 1.3. Making changes to SDL is not a trivial process. Sam
is up to his eye balls with work. Between his day job, and being a new
father I am surprised you ever answers email.

No 2d hardware video stuff ever needs to be initialized when
initializing the video subsystem. At least not on platforms that
implement OpenGL because you have two choices, use the 2D API or use
OpenGL.

In that case, I think there might be a problem with the PS2 version in
that it screws my video royally (even requiring a reboot) when I
initialize the video subsystem without actually using it. Maybe SDL
does something funky to the GS and the VPUs already before setting video
modes? (Can anyone give me a heads up on how SDL uses the PS2 hardware
currently? I’ll be looking into this more closely, but I would really
appreciate it if anyone can help me get up to speed. :))

It would seem that what you want to do is modify the ps2 version of SDL
to support ps2gl the same way SDL supports OpenGL on other platforms.

That’s exactly what I want to do. :slight_smile: I’ve been reading old posts in
this list and it seems like quite a few people have been waiting for
this for a long time. I’m just glad I’ve now got 7 PS2 linux kits lying
around in my cube… (cue beowulf cluster jokes)

Sounds like a great project. Set up CVS, down load the code, and start
working.

since events are the preferred method of handling
joystick actions.

Which also is the preferred what to handle keyboard, mouse, and all
other types of events. In other words, I don’t see the point you are
trying to make here.

Sorry about that. I was just trying to say that maybe having a separate
subsystem for events would be a better way to go about doing things,
since it’s so ubiquitous and yet there doesn’t seem to be a good reason
to couple it with video, of all things.

Before you make statements like that you need to look at the code and
think about how many different systems are supported by SDL. You admit
that you don’t know anything about the majority of systems that are
supported and haven’t looked at the code, but you are willing to tell
people how it should have been done in the first place. Please look at
the code.

	Bob PendletonOn Mon, 2004-11-22 at 00:41, Eric Vidal wrote:

–
±-------------------------------------+

10

that the version number be bumped to 2.0. Secondly, why do you think
your needs are so important that it is worth breaking the semantics for

There’s a difference between “this is what I need” and “this may be a
better idea, why is it not done this way so future applications would be
cleaner?”.

I’ve already taken care of my needs, thank you. I skipped event
handling and got the gamepads to work by polling. And thanks for
suggesting the dummy video device; I’ve done a simple experiment and it
turns out joystick event handling still works. That in itself suggests
that event handling is NOT really tied to video as SDL’s handling of it
implies.

You assume that I’m posting to this list because I want some other
developer to work on my needs. I’m not like that – I get my stuff done
and I have a track record of modifying open source applications to my
internal needs, even back when I was in the professional software
industry. On top of that, I’ve been working with SDL (not modifying it
directly until now, but I’ve been using it in all of my class-related
work and teaching duties) and I’ve extolled its virtues to all of my
students.

I joined this list primarily because I want to start contributing to the
project that I’ve benefitted from, and have some intelligent discussions
on its architecture with other developers so that it will become a
better system. I didn’t expect to be flamed for asking a question which
is important in terms of SDL’s overall design (in the sense that it will
break stuff if ever it’s changed).

worked on. I, personally, am spending every spare second I have working
on features for 1.3. Making changes to SDL is not a trivial process. Sam

And I applaud you for that, but it’s bad for your health to assume that
just because you’re contributing a lot to the project means that
everyone else is just asking you to do stuff for them. Chill down, ok? :slight_smile:

I know it’s not a trivial process. I know that a change this big will
break a lot of applications. That’s why I’m posting suggestions to this
list and see different viewpoints on SDL’s design. I haven’t given you
a reason to flame me either – I just asked a question on why it’s done
like so, and that I don’t see why it has to be that way. I’m sorry it
ruffles your feathers. I mean, look, I’m willing to contribute a lot to
this project, so please don’t scare me away. :slight_smile:

is up to his eye balls with work. Between his day job, and being a new
father I am surprised you ever answers email.

Congrats to Sam, by the way. :slight_smile:

Sounds like a great project. Set up CVS, down load the code, and start
working.

I already did a week ago (well, actually I grabbed the latest snapshot
because for some reason CVS doesn’t want to go past my firewall). And
I’ve been working on it even before I first posted here.

Before you make statements like that you need to look at the code and
think about how many different systems are supported by SDL. You admit

Similarly, before you imply that I’m not looking at the code, you should
be a bit more considerate when you post. Not all of us can understand
other people’s code in lightspeed time. Or maybe that’s just me – I
admit I’m not a very good coder, but give me enough time and I can
actually do stuff. (Look, ma, no (win32) handles!)

And again, I’m not telling people how it should be done – I’m asking
people here why it’s done one way when it seems more logical (okay, at
least to me, just so to be very clear on that) in another way.–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

11

Eric Vidal wrote:

You assume that I’m posting to this list because I want some other
developer to work on my needs.

You’ll have to forgive Bob… He’s generally a really nice guy.
Lately, I think he must be pretty stressed – end of semestre, perhaps,
other stresses, who knows. Maybe even just REALLY tired of people
asking questions to things which seem completely obvious to him in his
mind. (I did recently, fwiw.)

Anyway, he’s been kind of harsh to folks lately. Please don’t think
he’s mean or anything. In fact, my experience has told me he’s very
nice to new users and such. I’m sure he’ll be better soon.

–Scott

PS: Ack! WAY off topic. So sorry for that, guys…

12

Eric Vidal wrote:

You assume that I’m posting to this list because I want some other
developer to work on my needs.

You’ll have to forgive Bob… He’s generally a really nice guy.
Lately, I think he must be pretty stressed – end of semestre, perhaps,
other stresses, who knows. Maybe even just REALLY tired of people
asking questions to things which seem completely obvious to him in his
mind. (I did recently, fwiw.)

Anyway, he’s been kind of harsh to folks lately. Please don’t think
he’s mean or anything. In fact, my experience has told me he’s very
nice to new users and such. I’m sure he’ll be better soon.

Thank you for this. I had no idea I was getting harsh with people. Yes,
I have been seriously stressed recently. I’m not going to go into
details. But, my semester is over. I teach half semester courses and not
enough people signed up for the second course so, I’m not teaching right
now.

	Bob PendletonOn Tue, 2004-11-23 at 03:57, Scott Harper wrote:

–Scott

PS: Ack! WAY off topic. So sorry for that, guys…

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+

13

that the version number be bumped to 2.0. Secondly, why do you think
your needs are so important that it is worth breaking the semantics for

There’s a difference between “this is what I need” and “this may be a
better idea, why is it not done this way so future applications would be
cleaner?”.

Yes there is. I apparently came to the wrong conclusion about what you
were asking for.

I’ve already taken care of my needs, thank you. I skipped event
handling and got the gamepads to work by polling. And thanks for
suggesting the dummy video device; I’ve done a simple experiment and it
turns out joystick event handling still works. That in itself suggests
that event handling is NOT really tied to video as SDL’s handling of it
implies.

Again, you need to look at the source code. The SDL joystick code is
factored out of the rest of the event code. It is built in such away
that you that it is possible to get joystick events even when you can’t
get any other type of events. I don’t know if it was designed that way,
it just works that way.

Joysticks are treated as a special case because they so often are a
special case. For example, if the X server is properly configured using
the X input extension all input devices are handled by the server and
they all come to your application over the connection to the server and
are all tied tightly to the video systems. You can not get them unless
you have a window. But, X servers are rarely configured to handle
joysticks correctly so they have to be handled by a polling loop.
Windows does things differently. But, generally the joysticks are either
tied closely to the video system, or they are not.

So, what do you do if you want to have a portable consistent way of
handling joystick input? You make it all look like events even though it
may be polled. It is easy to make a polling loop push events on an event
queue.

In other words what you did does not prove what you think it does. It
tells you something about the way joysticks are implemented on the
machine you are working on. Try to take a global view.

You assume that I’m posting to this list because I want some other
developer to work on my needs.

Yes, I did think that. I came to that conclusion from what I read in
your messages. You apologized in the message title and I apologize for
misunderstanding you.

I’m not like that – I get my stuff done
and I have a track record of modifying open source applications to my
internal needs, even back when I was in the professional software
industry. On top of that, I’ve been working with SDL (not modifying it
directly until now, but I’ve been using it in all of my class-related
work and teaching duties) and I’ve extolled its virtues to all of my
students.

I also use SDL in my teaching my game programming class. What do you
teach, and where?

I joined this list primarily because I want to start contributing to the
project that I’ve benefitted from, and have some intelligent discussions
on its architecture with other developers so that it will become a
better system.

Good.

I didn’t expect to be flamed for asking a question which
is important in terms of SDL’s overall design (in the sense that it will
break stuff if ever it’s changed).

I am surprised to hear that you consider what I said to be a flame.
Honestly, I doubt you have ever seen a flame. I am absolutely serious
about that.

worked on. I, personally, am spending every spare second I have working
on features for 1.3. Making changes to SDL is not a trivial process. Sam

And I applaud you for that, but it’s bad for your health to assume that
just because you’re contributing a lot to the project means that
everyone else is just asking you to do stuff for them.

I made no such assumption. I was challenging you to justify what you
wanted. I put it in realistic terms.

Chill down, ok? :slight_smile:

I just did half an hour of standing meditation plus some other Chi Kung
and some Tai Chi Chuan. I’m feeling very mellow right now. What do you
do to balance your life?

I know it’s not a trivial process. I know that a change this big will
break a lot of applications. That’s why I’m posting suggestions to this
list and see different viewpoints on SDL’s design. I haven’t given you
a reason to flame me either

Like I said, if you consider that a flame, you’ve never seen a flame.

– I just asked a question on why it’s done
like so, and that I don’t see why it has to be that way. I’m sorry it
ruffles your feathers.

Consider how many people tried to answer your questions. Why do you
think I spend time trying to answer peoples questions? Is it because I
like to be verbally abused for trying to point them at the correct
source of information?

I mean, look, I’m willing to contribute a lot to
this project, so please don’t scare me away. :slight_smile:

If I read it right you are in Australia? And I am in Texas. What can I
possibly do to scare you? You can contribute to this project, even
become the biggest and most important developer on it and completely
ignore me. You can put me in your kill file and never see an email from
me again. I can also be a developer and completely ignore you.

is up to his eye balls with work. Between his day job, and being a new
father I am surprised you ever answers email.

Congrats to Sam, by the way. :slight_smile:

Sounds like a great project. Set up CVS, down load the code, and start
working.

I already did a week ago (well, actually I grabbed the latest snapshot
because for some reason CVS doesn’t want to go past my firewall). And
I’ve been working on it even before I first posted here.

Good.

Before you make statements like that you need to look at the code and
think about how many different systems are supported by SDL. You admit

Similarly, before you imply that I’m not looking at the code, you should
be a bit more considerate when you post.

Grow a thicker skin. Seriously, I have no reason to abuse you. I have
done nothing that I consider to be abusive. The level of push back you
have received is trivial compared to a real design review or even a
water cooler technical discussion.

Not all of us can understand
other people’s code in lightspeed time. Or maybe that’s just me – I
admit I’m not a very good coder, but give me enough time and I can
actually do stuff. (Look, ma, no (win32) handles!)

Oh, here is where the real reason for your irritation comes out. I have
tripped into one of you major insecurities. Sorry about that. Remember,
reacting according to your insecurities is your problem and is
completely under you control. It isn’t my fault that I walked into this
part of your personality. Blaming me for your problem is not healthy.
Expecting me to act as if I know you have this problem is silly. I can
not read your mind.

You do need to be careful about posting such revealing personal
information in a public place. A capable flamer with a background in
psychology and a cruel streak can use this kind of information to
inflict serious psychological harm.

And again, I’m not telling people how it should be done – I’m asking
people here why it’s done one way when it seems more logical (okay, at
least to me, just so to be very clear on that) in another way.

And, we have been trying to answer your questions. Sometimes the correct
answer is UTSL “Use the source, Luke”. At this point you need to dive
into the source, and think about it from as global a point of view as
you can.

There are a few gotchas in the code. I spent several weeks wondering why
nothing worked until I noticed the macro definitions in SDL_sysvideo.c

#define SDL_VideoSurface (current_video->screen)
#define SDL_ShadowSurface (current_video->shadow)
#define SDL_PublicSurface (current_video->visible)

Those things make the code look really nice. I spent way to long
thinking that SDL_VideoSurface and friends was a global variable.
Similar macro tricks are used in the X11 code (where I am currently
working). It makes making some kinds of changes very tricky

It is a good idea to get to know the SDL_VideoDevice structure. Any API
that has anything to do with video will eventually dive through a vector
in that structure. You’ll notice that it has an entry for a system/video
specific PollEvent structure, but not for joysticks. If you want to see
where keyboard, mouse, and joystick events come together you need to
look at SDL_PumpEvents in SDL_events.c

	Bob PendletonOn Tue, 2004-11-23 at 02:29, Eric Vidal wrote:

–
±-------------------------------------+

14

Yes there is. I apparently came to the wrong conclusion about what you
were asking for.

It’s ok, I made a mistake too – I wasn’t clear about my intentions.

Again, you need to look at the source code. The SDL joystick code is
factored out of the rest of the event code. It is built in such away
that you that it is possible to get joystick events even when you can’t

Uhm… yeah, I’m just beginning to realize that while reading the whole
thing – the lack of joystick event code in the video driver subtrees
I’ve looked at kinda gives it away. :slight_smile:

get any other type of events. I don’t know if it was designed that way,
it just works that way.
…
In other words what you did does not prove what you think it does. It
tells you something about the way joysticks are implemented on the
machine you are working on. Try to take a global view.

See, I was just suspecting that maybe it had been done this way as a
quick hack that had persisted for so long. Maybe somehow it should work
in a cleaner way. Or maybe not. I’ll just have to try.

I’m thinking of doing a big experiment on (trying to) refactor the code
such that events are handled in a separate subsystem, or maybe have
event handling all the time (that works too, and that won’t break a lot
of code, hopefully). You did say most events are emulated anyway, so
why wait for video to be initialized? Then if some real events may be
realized once the other subsystems are created, dynamically change the
handlers or something.

I’ll do it first on my own tree, of course (and given my limited
resources, it would probably only work on the machines I have). But if
does turn out successful I’ll be glad to share it. Then again, I should
work on the ps2gl module first.

The first thing I did when I downloaded the source was to look at the
TODO list. Seems like the master plan for 2.0 is to support multiple
windows and generalize the eveny system. I think therefore that it
might make good sense to decouple video and events in the long run.

Yes, I did think that. I came to that conclusion from what I read in
your messages. You apologized in the message title and I apologize for
misunderstanding you.

Thanks for accepting my apology, and your apology is accepted as well. :slight_smile:

I also use SDL in my teaching my game programming class. What do you
teach, and where?

I teach computer graphics programming and game dev in a liberal arts
school in a backwater country. :wink: Well, okay, it’s not that bad.

I am surprised to hear that you consider what I said to be a flame.
Honestly, I doubt you have ever seen a flame. I am absolutely serious
about that.

OK, maybe I was exaggerating. Yes, I’ve seen real flames. But I guess
I’ve never been criticized in a public forum before – you’re right, I
need to grow some thicker skin. :slight_smile:

I just did half an hour of standing meditation plus some other Chi Kung
and some Tai Chi Chuan. I’m feeling very mellow right now. What do you
do to balance your life?

Um… code? :slight_smile:

Okay, I actually have non-computer-related hobbies, mostly about music.
And I do have a Tai Chi book lying around in my cube (haven’t seen it
much though).

Consider how many people tried to answer your questions. Why do you
think I spend time trying to answer peoples questions? Is it because I
like to be verbally abused for trying to point them at the correct
source of information?

Deepest apologies. I don’t mean any verbal abuse – I guess I tend to
defend myself too much.

Oh, and actually it’s only you and Sam who’ve answered my questions as
of the moment. :slight_smile:

If I read it right you are in Australia? And I am in Texas. What can I

Nope, but close (geographically). I live in the Philippines.

possibly do to scare you?

Um, bare fangs and stuff?

actually do stuff. (Look, ma, no (win32) handles!)
Oh, here is where the real reason for your irritation comes out. I have
tripped into one of you major insecurities. Sorry about that. Remember,

Actually I’m not really majorly insecure with my abilities (well, maybe
a little, but not so much as to make it a really big deal). It was my
way of saying that although you’ve been very helpful, maybe the way you
phrase things might be irksome for the people you are helping. And,
yeah, I was also trying to make fun of myself, hence the child-on-a-bike
analogy.

And, we have been trying to answer your questions. Sometimes the correct
answer is UTSL “Use the source, Luke”. At this point you need to dive

Yes, master.–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

15

Again, you need to look at the source code. The SDL joystick code is
factored out of the rest of the event code. It is built in such away
that you that it is possible to get joystick events even when you can’t

Uhm… yeah, I’m just beginning to realize that while reading the whole
thing – the lack of joystick event code in the video driver subtrees
I’ve looked at kinda gives it away. :slight_smile:

Yeah, the best laid plans and all that. It seems like ever OS I play
with has a good plan for a unified method of dealing with all input
devices, and then it falls apart.

get any other type of events. I don’t know if it was designed that way,
it just works that way.
…
In other words what you did does not prove what you think it does. It
tells you something about the way joysticks are implemented on the
machine you are working on. Try to take a global view.

See, I was just suspecting that maybe it had been done this way as a
quick hack that had persisted for so long. Maybe somehow it should work
in a cleaner way. Or maybe not. I’ll just have to try.

I don’t really know. SDL runs on so many different OSes and devices.
There is evidence in the code that the event handling and input handling
has gone through many revisions while maintaining the same API and
semantics for the users.

I’m thinking of doing a big experiment on (trying to) refactor the code
such that events are handled in a separate subsystem, or maybe have
event handling all the time (that works too, and that won’t break a lot
of code, hopefully).

Keep me informed of your results. I’m very curious about how that works
out. What OSes are you going to be testing on?

You did say most events are emulated anyway, so
why wait for video to be initialized?

I don’t remember saying that any events were emulated. I don’t really
know what you mean by “emulated” in this context.

If you are working with a windowing system and are able to start getting
input events before you create a window, you are generally getting all
the input events in all windows. You generally need a window so that you
control which events you get. Not to mention that getting all input
events a huge security hole and shouldn’t be allowed.

When there is no windowing system then getting all the events is fine.

Then if some real events may be
realized once the other subsystems are created, dynamically change the
handlers or something.

I’ll do it first on my own tree, of course (and given my limited
resources, it would probably only work on the machines I have). But if
does turn out successful I’ll be glad to share it. Then again, I should
work on the ps2gl module first.

The first thing I did when I downloaded the source was to look at the
TODO list. Seems like the master plan for 2.0 is to support multiple
windows and generalize the eveny system. I think therefore that it
might make good sense to decouple video and events in the long run.

I’m pretty skeptical about the possibility of completely decoupling
input and windows. I’m currently working on adding multiple-window
support in SDL (don’t expect to see it any time soon) and I’m dealing
with the issues you are raising right now.

I teach computer graphics programming and game dev in a liberal arts
school in a backwater country. :wink: Well, okay, it’s not that bad.

I looked again. I was seeing Manila and reading it as Melbourne.
Considering the amount of tech work going on there I wouldn’t call the
Philippines a back water country.

	Bob PendletonOn Wed, 2004-11-24 at 01:28, Eric Vidal wrote:

–
±-------------------------------------+

16

Bob Pendleton wrote:

Yeah, the best laid plans and all that. It seems like ever OS I play
with has a good plan for a unified method of dealing with all input
devices, and then it falls apart.

Well, I guess that’s why SDL was developed in the first place…

I don’t really know. SDL runs on so many different OSes and devices.
There is evidence in the code that the event handling and input handling
has gone through many revisions while maintaining the same API and
semantics for the users.

Another reason why I posted that idea here is to find out if anyone else
has thought it over and decided that it really wouldn’t work. And of
course, you’re the one who first told me so. :slight_smile:

I’ll still try my experiment though – it will be more of getting my
hands dirty with the code rather than expecting an earth-shattering change.

Keep me informed of your results. I’m very curious about how that works
out. What OSes are you going to be testing on?

I’ll be testing it on Windows and x86 Linux (I’m on Debian unstable, and
it’s been really fun). And hopefully on MIPS architecture Linuxen too
Playstation.

Speaking of which, it’s been really frustrating for me to get ps2gl to
even work by itself. No wonder no one’s touching it. Their mailing
list is more or less dead too, so I’m somewhat on my own. I did get a
lot of non-texture-related stuff working though, with a lot of gotchas
involving immediate mode performance (or lack thereof) and having to
allocate ps2stuff memory instead of standard library malloc’s for
drawing mostly anything.

In which case, I’m thinking of exposing all of these PS2-specific stuff
as environment variables that you can control (so the SDL calls
themselves don’t have to change). I’m still not sure how to handle the
special PS2-specific memory allocation in a cross-platform manner,
though, since that would require putting all memory allocation in SDL’s
control, which isn’t really a Good Thing for most users and existing apps.

Recap: Most SDL-OpenGL programs won’t work on PS2 Linux without
modifying how they allocate memory for geometry and textures, and there
seems to be no way getting around it.

I don’t remember saying that any events were emulated. I don’t really
know what you mean by “emulated” in this context.

Oh, I just meant that some of the events were faked – e.g. SDL polling
for joystick input and manually creating the events in the queue, like
you said. :slight_smile:

the input events in all windows. You generally need a window so that you
control which events you get. Not to mention that getting all input

Once we get multiple windows, how would the event system work? Should
it be taking all events to itself, win32-style (and then there would be
an ID for each window so one can identify where the event goes)?

Or would it handle it in a more object-oriented way (e.g. each window
has its own event queue and events are passed to each window)? Either
way the root application has to have its own event queue, since some
input would occur even outside the context of a focused window (e.g.
mouse pointer outside of the focused window).

events a huge security hole and shouldn’t be allowed.

Really dumb question: Is SDL intended to be a secure (but direct (of
course)) way of accessing the hardware? I never really thought of SDL
that way.

I looked again. I was seeing Manila and reading it as Melbourne.
Considering the amount of tech work going on there I wouldn’t call the
Philippines a back water country.

Nowadays my countrymen are going on and on about how call centers will
be big here. Appalling, really, since there is a potential for
low-level tech work (as opposed to mere tech support) here, what with
all those new graduates in CS and CE looking for jobs. I personally
wouldn’t want to be on standby 24 hours a day to handle support
questions – I’d rather develop the stuff. :slight_smile:

–
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

17

Bob Pendleton wrote:

Yeah, the best laid plans and all that. It seems like ever OS I play
with has a good plan for a unified method of dealing with all input
devices, and then it falls apart.

Well, I guess that’s why SDL was developed in the first place…

I don’t really know. SDL runs on so many different OSes and devices.
There is evidence in the code that the event handling and input handling
has gone through many revisions while maintaining the same API and
semantics for the users.

Another reason why I posted that idea here is to find out if anyone else
has thought it over and decided that it really wouldn’t work. And of
course, you’re the one who first told me so. :slight_smile:

I’ll still try my experiment though – it will be more of getting my
hands dirty with the code rather than expecting an earth-shattering change.

Keep me informed of your results. I’m very curious about how that works
out. What OSes are you going to be testing on?

I’ll be testing it on Windows and x86 Linux (I’m on Debian unstable, and
it’s been really fun). And hopefully on MIPS architecture Linuxen too
Playstation.

Speaking of which, it’s been really frustrating for me to get ps2gl to
even work by itself. No wonder no one’s touching it. Their mailing
list is more or less dead too, so I’m somewhat on my own. I did get a
lot of non-texture-related stuff working though, with a lot of gotchas
involving immediate mode performance (or lack thereof) and having to
allocate ps2stuff memory instead of standard library malloc’s for
drawing mostly anything.

In which case, I’m thinking of exposing all of these PS2-specific stuff
as environment variables that you can control (so the SDL calls
themselves don’t have to change). I’m still not sure how to handle the
special PS2-specific memory allocation in a cross-platform manner,
though, since that would require putting all memory allocation in SDL’s
control, which isn’t really a Good Thing for most users and existing apps.

Recap: Most SDL-OpenGL programs won’t work on PS2 Linux without
modifying how they allocate memory for geometry and textures, and there
seems to be no way getting around it.

Can you solve this by having your own malloc system? It would be
commented out for all other platforms, but be compiled in on the ps2?

I don’t remember saying that any events were emulated. I don’t really
know what you mean by “emulated” in this context.

Oh, I just meant that some of the events were faked – e.g. SDL polling
for joystick input and manually creating the events in the queue, like
you said. :slight_smile:

Oh, ok. Yeah, some devices interrupt and some have to be polled. You can
make a polled device look like it is generating interrupts and you can
make an interrupting device look like it is a polled device. So, the API
has to pick one and convert for the device that needs to be converted.

the input events in all windows. You generally need a window so that you
control which events you get. Not to mention that getting all input

Once we get multiple windows, how would the event system work? Should
it be taking all events to itself, win32-style (and then there would be
an ID for each window so one can identify where the event goes)?

What I have is a surface for each window and each event has a surface
pointer that identifies the window of origin.

Or would it handle it in a more object-oriented way (e.g. each window
has its own event queue and events are passed to each window)?

First off, there is nothing object oriented about doing it that way.
Secondly, that would be a major PITA for many applications. For example,
you may want to handle joystick events in a window that does not
currently have focus. So, you need to be able to sort by both event type
and by event source. It would just be wrong for SDL to tell the
developer how to handle events. It is easy to layer policy on top of a
simple model, but nearly impossible to undo policy imposed by the
system. So, 'tis best to not build policy into the tools.

My old, best, truest saying “Tools, not Rules”.

Either
way the root application has to have its own event queue, since some
input would occur even outside the context of a focused window (e.g.
mouse pointer outside of the focused window).

No reason to believe that the underlying OS will deliver those to you.
It may, or it may not.

events a huge security hole and shouldn’t be allowed.

Really dumb question: Is SDL intended to be a secure (but direct (of
course)) way of accessing the hardware? I never really thought of SDL
that way.

No, SDL is not, and can not, be a secure way to access the the hardware.
Anything in the application layer can be circumvented so security can
not be implemented at that layer. The point I was trying to make is that
the windowing system (which does have the job of implementing and
enforcing security policy) may simply refuse to send you events that
aren’t directed at windows created by your application.

	Bob Pendleton

I looked again. I was seeing Manila and reading it as Melbourne.
Considering the amount of tech work going on there I wouldn’t call the
Philippines a back water country.

Nowadays my countrymen are going on and on about how call centers will
be big here. Appalling, really, since there is a potential for
low-level tech work (as opposed to mere tech support) here, what with
all those new graduates in CS and CE looking for jobs. I personally
wouldn’t want to be on standby 24 hours a day to handle support
questions – I’d rather develop the stuff. :slight_smile:

Yeah, me to. Developing work is globalizing so fast that I have trouble
believing there is any real barrier to doing it in the Philippines. I
met a guy on my mailing list who is developing games in Uruguay and
selling them over the Internet. If he can do that from the tip of South
America, you should be able to do it from the Philippines.

	Bob PendletonOn Thu, 2004-11-25 at 02:44, Eric Vidal wrote:

–
±-------------------------------------+

18

Eric Vidal wrote:

Keep me informed of your results. I’m very curious about how that works
out. What OSes are you going to be testing on?

I’ll be testing it on Windows and x86 Linux (I’m on Debian unstable,
and it’s been really fun). And hopefully on MIPS architecture Linuxen
too Playstation.

Speaking of which, it’s been really frustrating for me to get ps2gl to
even work by itself. No wonder no one’s touching it. Their mailing
list is more or less dead too, so I’m somewhat on my own. I did get a
lot of non-texture-related stuff working though, with a lot of gotchas
involving immediate mode performance (or lack thereof) and having to
allocate ps2stuff memory instead of standard library malloc’s for
drawing mostly anything.

Maybe you could expose such fonctionality through suitable OpenGL
extensions like :
http://oss.sgi.com/projects/ogl-sample/registry/EXT/pixel_buffer_object.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt

Most OpenGL programs that are concerned about performance make use of
vertex buffers on recent hardware (geforce 6800 and ATI x800 and
similar). That’s the current optimizing trend.

In which case, I’m thinking of exposing all of these PS2-specific
stuff as environment variables that you can control (so the SDL calls
themselves don’t have to change). I’m still not sure how to handle
the special PS2-specific memory allocation in a cross-platform manner,
though, since that would require putting all memory allocation in
SDL’s control, which isn’t really a Good Thing for most users and
existing apps.

Recap: Most SDL-OpenGL programs won’t work on PS2 Linux without
modifying how they allocate memory for geometry and textures, and
there seems to be no way getting around it.

For the textures, you have to allocate and copy the texture to this
specially allocated memory (the OpenGL texture Object which got
standardized in OpenGL 1.1 allows doing just that). That’s really what a
"standard" video card does : the texture has to be copied to video
memory first if you want to get good fill rate.

So what you describe falls very well into the current graphics hardware
trend. Or maybe I’m missing something.

Stephane

19

Recap: Most SDL-OpenGL programs won’t work on PS2 Linux without
modifying how they allocate memory for geometry and textures, and
there
seems to be no way getting around it.
Can you solve this by having your own malloc system? It would be
commented out for all other platforms, but be compiled in on the ps2?

I was thinking about doing that – I’m already wrapping the code using
my own malloc- and free-like functions anyway. The code is pretty
small – they just call mmap/munmap on /dev/ps2stuff. But since that
device has to be maintained alongside ps2gl, it really can’t be
accessed from outside of the context which maintains the file
descriptor. That is, if I get SDL to handle ps2gl internally, it has
to handle the ps2stuff device and never let go, and users cannot really
allocate their own ps2stuff memory unless it goes through SDL. Well, at
least that’s what I think.

How does SDL_GL_DMAMalloc() and SDL_GL_DMAFree() sound? :slight_smile: Or maybe
PGL instead of GL since it’s really just a ps2gl hack?

I really don’t know if this should be the way to do it though. It
sounds pretty platform-specific. And I’m not even sure if this is the
way to handle texture data as well – the (scarce) ps2gl docs keep
mentioning things about GS memory slots and areas for performing
texture management, and I still haven’t figured it out.

and by event source. It would just be wrong for SDL to tell the
developer how to handle events. It is easy to layer policy on top of
a
simple model, but nearly impossible to undo policy imposed by the
system. So, 'tis best to not build policy into the tools.

My old, best, truest saying “Tools, not Rules”.

I realized just how boneheaded my idea was. :slight_smile: Sorry, my MFC
programming background was showing. Shame, shame.

Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

20

Quoting Stephane Marchesin <stephane.marchesin at wanadoo.fr>:

Maybe you could expose such fonctionality through suitable OpenGL
extensions like :

http://oss.sgi.com/projects/ogl-sample/registry/EXT/pixel_buffer_object.txt

http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt

Hmmm, that looks promising. I can theoretically catch all queries for
OpenGL functions from SDL to see whether the app is requesting a vertex
buffer object, then redirect them to my own functions that allocate the
memory in the ps2stuff area.

Actually, should I do this? Or should I just modify ps2gl so that the
extension is officially supported?

For the textures, you have to allocate and copy the texture to this
specially allocated memory (the OpenGL texture Object which got
standardized in OpenGL 1.1 allows doing just that). That’s really
…
So what you describe falls very well into the current graphics
hardware
trend. Or maybe I’m missing something.

Oops… here’s what’s missing in my description – ps2gl isn’t a real
OpenGL library. It does have texture objects, but getting them to work
requires that the texture itself be stored in ps2stuff-managed DMA
memory, just before passing the texture data to glTexImage2D. (And
like I said in my previous post, there’s still a weird thing going on
with all the GS slots and areas and whatnot. My nose is bleeding.)

Another weird thing about this is that ps2gl’s glTexImage2D (and
actually most of its other functions) won’t copy the data – it will
just update some internal pointers. I don’t know why it was designed
this way – perhaps to conserve memory? (I can’t seem to think it’s
performance-related because textures are usually preloaded anyway,
hence copying shouldn’t be a big deal except when memory is scarce.)

Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/