CreateWindowFrom() on Linux

A colleague of mine is currently trying to replicate my recent efforts (http://forums.libsdl.org/viewtopic.php?t=7589) on the Linux side of our engine and is having quite a bit more difficult time then I had. He’d be posting this himself but currently can’t post on account of waiting for moderator approval. :frowning: He did sign up for the mailing lists though. Just to help reach as many people as possible I’m posting his email here as well:-------------------------------------------------------------------------------------

I am having some trouble getting user input working again.

Once upon a time we had it working correctly, We are trying to use Ogre3d for 3d rendering and SDL for user input. We started off creating an SDL window and passing some operating system specific information from SDL into Ogre3d, and then Ogre could render onto the SDL window just fine, likewise SDL was gathering all the correct user input events. However, this had some limitations, Ogre3d could not control the pixel format of the window, couldn’t adjust anti-aliasing settings, and a few other things. So we decided to create a window using Ogre3d and try passing some operating specific token into SDL.

There were some hiccups on windows, but Mako resolved those:
http://forums.libsdl.org/viewtopic.php?t=7589&highlight=
http://forums.libsdl.org/viewtopic.php?t=7426&highlight=
http://forums.libsdl.org/viewtopic.php?t=7415&highlight=

Now it seems fine on Windows, but it no longer works on Linux. Ogre is rendering to the window, but none of the SDL events are being gathered by our game code on Linux anymore.

Whats on/in my system in case it matters.

  • Ubuntu 11.04
  • Unity3d desktop environment
  • uname -a reports “Linux fast 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:17:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux”
  • I have an nVidia 560m that reports as “nVidia Corporation Device 1251 (rev a1)”
  • I have SDL 1.3 from the mercurial repo at http://hg.libsdl.org/SDL that I cloned on Saturday morning. The issue existed on older versions of 1.3 as well.

Here is what I know and where I am at:

  • I have all the bug fixes Mako applied to the codebase.
  • This all works fine on Windows, It seems to be a Linux/X11 specific bug.
  • I patched an SDL bug that segfaulted getting when the X11 window title.
  • When I attempt to initialize SDL using SDL_Init(SDL_INIT_VIDEO | SDL_INIT_NOPARACHUTE) or SDL_Init(SDL_INIT_VIDEO) it returns successfully, despite this I checked SDL_GetError() and it returns “Invalid window” in both cases.
  • The windows side also get the “Invalid window” error message but works perfectly
  • I am pulling all the events from SDL every frame using SDL_PollEvent()
  • We set an event filter with SDL_SetEventFilter() and our code makes the usual calls to it, but SDL does not.

Any ideas? Where else should I look?


Also, while source diving I found this bit of code sitting in the linux SetupWindowData() function:

Code:
/* FIXME: How can I tell?
{
DWORD style = GetWindowLong(hwnd, GWL_STYLE);
if (style & WS_VISIBLE) {
if (style & (WS_BORDER | WS_THICKFRAME)) {
window->flags &= ~SDL_WINDOW_BORDERLESS;
} else {
window->flags |= SDL_WINDOW_BORDERLESS;
}
if (style & WS_THICKFRAME) {
window->flags |= SDL_WINDOW_RESIZABLE;
} else {
window->flags &= ~SDL_WINDOW_RESIZABLE;
}
if (style & WS_MINIMIZE) {
window->flags |= SDL_WINDOW_MINIMIZED;
} else {
window->flags &= ~SDL_WINDOW_MINIMIZED;
}
}
if (GetFocus() == hwnd) {
int index = data->videodata->keyboard;
window->flags |= SDL_WINDOW_INPUT_FOCUS;
SDL_SetKeyboardFocus(index, data->window);

   if (window->flags & SDL_WINDOW_INPUT_GRABBED) {
   RECT rect;
   GetClientRect(hwnd, &rect);
   ClientToScreen(hwnd, (LPPOINT) & rect);
   ClientToScreen(hwnd, (LPPOINT) & rect + 1);
   ClipCursor(&rect);
   }
   }
 */

This is identical to the windows counterpart, and makes reference to windows specific stuff (such as the HWND). So I can see why it was commented out, but I don’t understand the comment. It does seem apparent that nothing in SetupWindowData() calls on input, which is why we’re having everything but input work properly. Is this snippet of code what is responsible for ensuring input gets registered by the window? Does the Linux side need a counterpart and that is just missing?

This is a question for Sam or Ryan mostly, though anyone “in the loop” is
welcome to pitch in. I’m aware that at some point during April/May or so Sam
left SDL’s future in the hands of the community and went to pursue other
endeavours, changing the SDL license, etc.
My question is, after a few months have passed, what’s the current status of
SDL development? I mean no disrespect or impatience by this, it comes from
genuine curiosity and a desire to help out. I see very little action going on
in hg, and the bugs in the tracker get very little attention. I myself have
volunteered some patches, and I’ve seen quite a few by others, that don’t add
stuff but fix very narrow, to the point issues, and that are left there with no
further review or comments.
So I think what I’m asking in short is what’s the strategy in place for
community driven development? Is there any? Will there be at some point?

Thanks for your replies!

Gabriel.

I foolishly sent this earlier as a reply to a different thread, apologies! Here
it goes again in proper form.

This is a question for Sam or Ryan mostly, though anyone “in the loop” is
welcome to pitch in. I’m aware that at some point during April/May or so Sam
left SDL’s future in the hands of the community and went to pursue other
endeavours, changing the SDL license, etc.
My question is, after a few months have passed, what’s the current status of
SDL development? I mean no disrespect or impatience by this, it comes from
genuine curiosity and a desire to help out. I see very little action going on
in hg, and the bugs in the tracker get very little attention. I myself have
volunteered some patches, and I’ve seen quite a few by others, that don’t add
stuff but fix very narrow, to the point issues, and that are left there with no
further review or comments.
So I think what I’m asking in short is what’s the strategy in place for
community driven development? Is there any? Will there be at some point?

Thanks for your replies!

Gabriel.

My question is, after a few months have passed, what’s the current status of
SDL development?

I do SDL work when I have time. It’s important to me, but my time is
always pretty limited. At the moment, it’s not unusual for good (and
simple, and obvious) patches to sit in the bug tracker for way too long,
but they do get into revision control eventually…I hope.

Prodding me to pay attention to specific patches is actually
appreciated. If something can be reviewed in a few minutes, it’s better
to get that bug closed than have it sit open.

Bigger patches tend to be a problem, because we get patches that
introduce new bugs too often, and every time I’ve trusted them without a
lot of review, I end up regretting it.

–ryan.

Hi Ryan,

I wasn’t aware of the history of SDL, having joined the mailing list only a
couple of weeks ago to submit this simple (1-character, if it’s fixed the
"easy" way) bugfix for a serious joystick problem in the 1.2.14 library (under
Linux):

http://forums.libsdl.org/viewtopic.php?t=7593

The bugfix I supplied is for a problem that (unbeknown to me) happened to be
fixed already in 1.3, but I suspect that many GNU/Linux distributions are still
including 1.2.x and will continue to do so until 1.3 is officially released.

So I was very glad when Gabriel asked these questions, because I’ve been
wondering the same thing.

I’d like to humbly add a question of my own: Is there ever going to be a new
1.2.x release or is that branch essentially abandoned? I realize that the main
SDL page mentions the “last planned release” of 1.2, but if 1.3 isn’t going to
come out soon and there are bugs accumulating in 1.2, would that possibly
drive a new release of 1.2?

As Gabriel aptly said, “I mean no disrespect or impatience by this”. I’m just
sort of curious what the plan/timeline (if any) might be.

Thanks to you and all other contributors to the SDL project. And thanks in
advance for any added insight you might offer on this topic.

Regards,
Bill MarrOn Tuesday 11 October 2011 22:22:22 Ryan C. Gordon wrote:

My question is, after a few months have passed, what’s the current status
of SDL development?

I do SDL work when I have time. It’s important to me, but my time is
always pretty limited. At the moment, it’s not unusual for good (and
simple, and obvious) patches to sit in the bug tracker for way too long,
but they do get into revision control eventually…I hope.

Prodding me to pay attention to specific patches is actually
appreciated. If something can be reviewed in a few minutes, it’s better
to get that bug closed than have it sit open.

Bigger patches tend to be a problem, because we get patches that
introduce new bugs too often, and every time I’ve trusted them without a
lot of review, I end up regretting it.

–ryan.

I’d like to humbly add a question of my own: Is there ever going to be a
new
1.2.x release or is that branch essentially abandoned? I realize that the
main
SDL page mentions the “last planned release” of 1.2, but if 1.3 isn’t going
to
come out soon and there are bugs accumulating in 1.2, would that possibly
drive a new release of 1.2?

Sam and Ryan have both stated many times on the mailing list that SDL 1.2
will still receive patches, but it is no longer on active development
(meaning it is no longer the main project being worked on).

-AlexOn Tue, Oct 11, 2011 at 11:22 PM, Marr wrote:

On Mar 11 Oct 2011 23:22:22 Ryan C. Gordon escribi?:

Bigger patches tend to be a problem, because we get patches that
introduce new bugs too often, and every time I’ve trusted them without a
lot of review, I end up regretting it.

I fully understand the issue with available time and this being a side project
for you, but I wonder if there’s a middle ground where control on new code can
be shared (I’m thinking out loud, but perhaps a pre review stage for more
complex patches, where one person contributes it, another reviews it and then
you or Sam do a second stage pass on it and finally accept it, and a lighter
policy on smaller patches).
I fear the alternative that at some point a fork of the project will take
place and whatever goodwill and willingness to help there is in the community
and patch contributors will be unnecessarily split.

Anyway, my two cents. I don’t want to end the message without stating again
how grateful I’m for the project and your work in it! I’m just looking on how
to keep improving on what’s already done.

Gabriel.

I share the concerns that gabomdq brought up regarding the possibility of a fork occurring elsewhere if there isn’t sufficient drive occurring in SDL, be it from a single organizer, or the community overall. I also have one additional concern though. I don’t mean to shamelessly draw attention to my own issues(ok, maybe I do (http://forums.libsdl.org/viewtopic.php?t=7618)), but it’s clear that there are still some medium(in my case at least) portions of functionality just missing from SDL and some other various one liner (http://forums.libsdl.org/viewtopic.php?p=30406#30406) issues.

Overall…SDL is not in a good state to slow down, imo. It needs at least one person that is active and committed with repo access to stay alive. Otherwise…people like myself that run into these issues and can’t get help(Sam’s post in the second link is the closest thing to help I’ve gotten since Sam left) are forced into considering alternatives. I really like SDL, and I want to stick with it which is why I’m posting instead of researching other libraries. But if SDL can’t do what I want/need it to, then that is all there is to it.

It sounds sounds like we need a community experimental repo (forked from the
main SDL repo) that we regularly apply and test patches - this way, we take
a huge weight off Ryan’s shoulders (seriously, he shouldn’t be responsible
for testing each patch! That’s a lot of man-hours!), and give the community
access to a development repo. Probably if we had 5-10 developers who could
be monitoring/updating the repo. The experimental repo would not be for
implementing new features, though - just bug/patch testing. If we started
accepting new features, we’d be dealing with a lot of issues of trying to
keep compatibility with the main repo. On that note, I propose that the
experimental repo re-syncs with the main repo once a week, so we have a week
to test patches, then it becomes reset - that way, we avoid adding huge
features to the experimental repo, we stay in line with any updates from the
main repo, and it promotes lots of testing per week. Patches that get
submitted will show up in the repo the beginning of the next cycle, so every
patch has a full week to be tested.
We could probably set up some sort of build bot that can do a daily build to
check for any compile time errors (and possibly identify which patch caused
an issue).

Thoughts?
-AlexOn Wed, Oct 12, 2011 at 2:20 PM, Mako_energy <mako_energy02 at yahoo.com>wrote:

**
I share the concerns that gabomdq brought up regarding the possibility of a
fork occurring elsewhere if there isn’t sufficient drive occurring in SDL,
be it from a single organizer, or the community overall. I also have one
additional concern though. I don’t mean to shamelessly draw attention to my
own issues(ok, maybe I do http://forums.libsdl.org/viewtopic.php?t=7618),
but it’s clear that there are still some medium(in my case at least)
portions of functionality just missing from SDL and some other various one
liner http://forums.libsdl.org/viewtopic.php?p=30406#30406 issues.

Overall…SDL is not in a good state to slow down, imo. It needs at least
one person that is active and committed with repo access to stay alive.
Otherwise…people like myself that run into these issues and can’t get
help(Sam’s post in the second link is the closest thing to help I’ve gotten
since Sam left) are forced into considering alternatives. I really like SDL,
and I want to stick with it which is why I’m posting instead of researching
other libraries. But if SDL can’t do what I want/need it to, then that is
all there is to it.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That is a very nice idea.
We should start recruiting developers for this task…

MrOzBarry wrote:

It sounds sounds like we need a community experimental repo (forked from the main SDL repo) that we regularly apply and test patches - this way, we take a huge weight off Ryan’s shoulders (seriously, he shouldn’t be responsible for testing each patch! ?That’s a lot of man-hours!), and give the community access to a development repo. ?Probably if we had 5-10 developers who could be monitoring/updating the repo. ?The experimental repo would not be for implementing new features, though - just bug/patch testing. ?If we started accepting new features, we’d be dealing with a lot of issues of trying to keep compatibility with the main repo. ?On that note, I propose that the experimental repo re-syncs with the main repo once a week, so we have a week to test patches, then it becomes reset - that way, we avoid adding huge features to the experimental repo, we stay in line with any updates from the main repo, and it promotes lots of testing per week. ?Patches that get submitted will
show up in the repo the beginning of the next cycle, so every patch has a full week to be tested.> We could probably set up some sort of build bot that can do a daily build to check for any compile time errors (and possibly identify which patch caused an issue).

Thoughts?
-Alex

On Wed, Oct 12, 2011 at 2:20 PM, Mako_energy <mako_energy02 at yahoo.com (mako_energy02 at yahoo.com)> wrote:

   	I share the concerns that gabomdq brought up regarding the possibility of a fork occurring elsewhere if there isn't sufficient drive occurring in SDL, be it from a single organizer, or the community overall. I also have one additional concern though. I don't mean to shamelessly draw attention to my own issues(ok, maybe I do (http://forums.libsdl.org/viewtopic.php?t=7618)), but it's clear that there are still some medium(in my case at least) portions of functionality just missing from SDL and some other various one liner (http://forums.libsdl.org/viewtopic.php?p=30406#30406) issues. 

Overall…SDL is not in a good state to slow down, imo. It needs at least one person that is active and committed with repo access to stay alive. Otherwise…people like myself that run into these issues and can’t get help(Sam’s post in the second link is the closest thing to help I’ve gotten since Sam left) are forced into considering alternatives. I really like SDL, and I want to stick with it which is why I’m posting instead of researching other libraries. But if SDL can’t do what I want/need it to, then that is all there is to it.


SDL mailing list
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

I’d like to humbly add a question of my own: Is there ever going to be a new
1.2.x release or is that branch essentially abandoned? I realize that the main
SDL page mentions the “last planned release” of 1.2, but if 1.3 isn’t going to
come out soon and there are bugs accumulating in 1.2, would that possibly
drive a new release of 1.2?

There will likely be a 1.2.15 release. Work is meant to be targeted at
1.3, but we do tend to accumulate good fixes for 1.2 still.

–ryan.

We could probably set up some sort of build bot that can do a daily
build to check for any compile time errors (and possibly identify which
patch caused an issue).

http://buildbot.libsdl.org/ :slight_smile:

–ryan.

I don’t mean to shamelessly draw
attention to my own issues(ok, maybe I do
http://forums.libsdl.org/viewtopic.php?t=7618)

Was there a fix for this, or is it still considered a mystery?

functionality just missing from SDL and some other various one liner
http://forums.libsdl.org/viewtopic.php?p=30406#30406 issues.

This is now hg changeset 612b41c44af1.

Were these the only two issues remaining with the Ogre integration? I
wasn’t sure which of the other forum posts were still considered unresolved.

–ryan.

Prodding me to pay attention to specific patches is actually
appreciated. If something can be reviewed in a few minutes, it’s better
to get that bug closed than have it sit open.

Since you insist on being prodded, I volunteer two patches that should be
quite painless to accept, Android multitouch
(http://bugzilla.libsdl.org/show_bug.cgi?id=1294) and a implementation for
GL_GetProcAddress for Android
(http://bugzilla.libsdl.org/show_bug.cgi?id=1290).

Thanks,

Gabriel.

Ryan C. Gordon wrote:

I don’t mean to shamelessly draw
attention to my own issues(ok, maybe I do
http://forums.libsdl.org/viewtopic.php?t=7618)

Was there a fix for this, or is it still considered a mystery?

We’re not entirely sure. As I posted in the second post there is a large chunk of code that is commented out identical to windows code with the comment of “fix me” at the top. That isn’t too descriptive. We made a guess as to what it means, which was we thought that focus simply wasn’t being applied to the window, so we tried adding code to match was commented out there, but for linux. This didn’t give us the results we were looking for, however closing the console window does close the main window now, which it didn’t use to. We think that means we’re going in the right direction, but we really don’t know. This is pretty deep innards of SDL and we don’t know where to go from here. This should probably go into the other thread, as I don’t want to hijack this thread, but it’s good to get some acknowledgement.

Ryan C. Gordon wrote:

functionality just missing from SDL and some other various one liner
http://forums.libsdl.org/viewtopic.php?p=30406#30406 issues.

This is now hg changeset 612b41c44af1.

Were these the only two issues remaining with the Ogre integration? I
wasn’t sure which of the other forum posts were still considered unresolved.

Good to know it was commited. I suppose I should check the hg commit log more often. Currently the linux side is the only standing issue, I consider the windows side integration complete since I haven’t had any further issues. However we plan to do this for each platform we plan to support(Windows, Mac, Linux, iOS, Android), and having issues with two of the two platforms we’ve tried so far doesn’t bode well. Mac is our next target, and we’re already gritting our teeth. Any help we can get from someone that actually knows what they are doing in this regard would be amazing.

Since you insist on being prodded, I volunteer two patches that should be
quite painless to accept

Done and done. :slight_smile:

–ryan.

I’ll add my prodding of one liners here :slight_smile:
additional symbol for ios config http://bugzilla.libsdl.org/show_bug.cgi?id=1292
doublefree corruption http://bugzilla.libsdl.org/show_bug.cgi?id=1191

and also some longer ones but related
uimodescreen being 3.2 only http://bugzilla.libsdl.org/show_bug.cgi?id=1266
wrong displaymode returned http://bugzilla.libsdl.org/show_bug.cgi?id=1130
which have a fix here by Kees https://bitbucket.org/keestux/sdl

also in my opinion these ones could be closed
don’t include main http://bugzilla.libsdl.org/show_bug.cgi?id=1045
invalid/inactive http://bugzilla.libsdl.org/show_bug.cgi?id=1057

If the community driven repository ever takes place I would like to
take part in the ios/osx testing team, just fyi!
Best,
VittorioOn Thu, Oct 13, 2011 at 2:55 AM, Gabriel Jacobo wrote:

Prodding me to pay attention to specific patches is actually
appreciated. If something can be reviewed in a few minutes, it’s better
to get that bug closed than have it sit open.

Since you insist on being prodded, I volunteer two patches that should be
quite painless to accept, Android multitouch
(http://bugzilla.libsdl.org/show_bug.cgi?id=1294) and a implementation for
GL_GetProcAddress for Android
(http://bugzilla.libsdl.org/show_bug.cgi?id=1290).

Thanks,

Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On that note, Ryan, what sort of work would we have to put in to get the
build bot to use a second repository? And is it possible for us to use the
sdl website for some automated mercurial clones and patching, or should we
have someone set that up on their private computer?
Also, who would want access to a public dev repo, and what sort of access.
Also, we should have some sort of automated patch submission system, where
a patch is submitted, and along with that, a link to a bugzilla entry.
-AlexOn Thu, Oct 13, 2011 at 3:03 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:

I’ll add my prodding of one liners here :slight_smile:
additional symbol for ios config
http://bugzilla.libsdl.org/show_bug.cgi?id=1292
doublefree corruption http://bugzilla.libsdl.org/show_bug.cgi?id=1191

and also some longer ones but related
uimodescreen being 3.2 only
http://bugzilla.libsdl.org/show_bug.cgi?id=1266
wrong displaymode returned http://bugzilla.libsdl.org/show_bug.cgi?id=1130
which have a fix here by Kees https://bitbucket.org/keestux/sdl

also in my opinion these ones could be closed
don’t include main http://bugzilla.libsdl.org/show_bug.cgi?id=1045
invalid/inactive http://bugzilla.libsdl.org/show_bug.cgi?id=1057

If the community driven repository ever takes place I would like to
take part in the ios/osx testing team, just fyi!
Best,
Vittorio

On Thu, Oct 13, 2011 at 2:55 AM, Gabriel Jacobo wrote:

Prodding me to pay attention to specific patches is actually
appreciated. If something can be reviewed in a few minutes, it’s better
to get that bug closed than have it sit open.

Since you insist on being prodded, I volunteer two patches that should be
quite painless to accept, Android multitouch
(http://bugzilla.libsdl.org/show_bug.cgi?id=1294) and a implementation
for
GL_GetProcAddress for Android
(http://bugzilla.libsdl.org/show_bug.cgi?id=1290).

Thanks,

Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On that note, Ryan, what sort of work would we have to put in to get the
build bot to use a second repository?

This wouldn’t be hard. The config file could really use some cleaning
up, but it’s possible to point it at different repos already.

And is it possible for us to use
the sdl website for some automated mercurial clones and patching, or
should we have someone set that up on their private computer?

bitbucket.org makes it trivial to make public clones of the repo. We had
the Google Summer of Code people use it, and it worked like a champ.

We can also set up new clones on hg.libsdl.org, but it’s easier to let
the community control it on their own servers (and/or bitbucket),
instead of petitioning me for access. If really good clones show up,
they can come and go trivially and at their own whims.

Also, who would want access to a public dev repo, and what sort of
access. Also, we should have some sort of automated patch submission
system, where a patch is submitted, and along with that, a link to a
bugzilla entry.

Buildbot recognizes commit messages with the text “Bugzilla #XXXX” and
autolinks them to the appropriate bug report. I’d like to start hacking
that trick into other things, like Mercurial itself. There might be
extensions that support it already…?

–ryan.On 10/13/11 8:02 AM, Alex Barry wrote:

Hi Vittorio,

Just curious. Are you saying that my version fixes bug #1191 (the double
free issue)?

In any case, Ryan, would you be willing to pull my repo?
– Kees

Op 2011-10-13 09:03 , Vittorio G. schreef:> I’ll add my prodding of one liners here :slight_smile:

additional symbol for ios config http://bugzilla.libsdl.org/show_bug.cgi?id=1292
doublefree corruption http://bugzilla.libsdl.org/show_bug.cgi?id=1191

and also some longer ones but related
uimodescreen being 3.2 only http://bugzilla.libsdl.org/show_bug.cgi?id=1266
wrong displaymode returned http://bugzilla.libsdl.org/show_bug.cgi?id=1130
which have a fix here by Kees https://bitbucket.org/keestux/sdl

also in my opinion these ones could be closed
don’t include main http://bugzilla.libsdl.org/show_bug.cgi?id=1045
invalid/inactive http://bugzilla.libsdl.org/show_bug.cgi?id=1057

If the community driven repository ever takes place I would like to
take part in the ios/osx testing team, just fyi!
Best,
Vittorio

On Thu, Oct 13, 2011 at 2:55 AM, Gabriel Jacobo wrote:

Prodding me to pay attention to specific patches is actually
appreciated. If something can be reviewed in a few minutes, it’s better
to get that bug closed than have it sit open.
Since you insist on being prodded, I volunteer two patches that should be
quite painless to accept, Android multitouch
(http://bugzilla.libsdl.org/show_bug.cgi?id=1294) and a implementation for
GL_GetProcAddress for Android
(http://bugzilla.libsdl.org/show_bug.cgi?id=1290).

Thanks,

Gabriel.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org