The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Have you set SDL_VIDEODRIVER to some specific value?
Make this to output the value (if it is set):

echo $ SDL_VIDEODRIVER

Have you tried this before starting:

export SDL_VIDEODRIVER=x11

That sets the video mode to X11 which should always work in a X11
environment.

There are some more options:

http://www.libsdl.org/cgi/docwiki.cgi/SDL_envvars

Please say if you had some value before or not (the echo command) and
if it worked with X11.

Question to other developers: How does SDL select the video driver if
it is not set? Is it predefined (for each system) and if that fails,
it just breaks? Or does it try multiple ones and uses the one which
worked?

If the latter is not the case, I probably would like to set some
fallback for our game for Linux if it doesn't work.


Am 09.03.2009 um 20:55 schrieb Jeff91:

If not set, it tries several targets in a reasonable order to find the
best option. You should NOT set the environment variable unless you need
to force it for some reason.

Frequently, on Linux, "No available video device" means SDL was
miscompiled (without X11 support), or SDL can't talk to your X server
for some reason.

--ryan.

On Mon, Mar 9, 2009 at 3:55 PM, Jeff91 <blue_starsoar at yahoo.com> wrote:

If you could download the SDL source code and try to build and run the
tests therein, that would probably go far in pursuit of narrowing down
the possible problems.

--
http://codebad.com/

Am 25.03.2009 um 15:32 schrieb Ryan C. Gordon:

Ah thanks for the information. Then I don't have to care about this.

(Except for Windows, where SDL doesn't prefer DirectX for some reason
(it prefers WinDIB over DirectX if I recall correctly) but we have
much better performance with the DirectX backend; thus we try first
with forced DirectX backend (if env is unset) and if that fails, we
unset the env and try it again.)

Hello !




SDL 1.2 uses DirectX 5 and there were some problems
with it on Windows Vista, so GDI was set as the new default.


CU

On Wed, Mar 25, 2009 at 2:15 PM, Torsten Giebl <wizard at syntheticsw.com> wrote:


Also, I think that in DirectX 8, "proper" DirectDraw (which SDL was
using) was dropped, and the older interfaces give you a Direct3D
wrapper, which will work very well (and fast) if you have a 3D
accelerated card, but if you did not, a bunch of things that the 2D
hardware made fast became really slow, to the point where doing in
software with the GDI was much faster (but slower than the actual 2D
accelerated support that DirectDraw gave you). Thankfully, DirectX 8
is usually on new enough computers that doing it in software seems
okay, and SDL games are often "used to" software rendering, often
being used on Linux, where it's all software, all the time.

--
http://pphaneuf.livejournal.com/

Am 25.03.2009 um 20:05 schrieb Pierre Phaneuf:


Is the assumption ok that a user which has DirectX8 installed probably
has hardware which can do this fast?

What other problems are there with the DirectX backend on Windows
Vista? (Just failing wouldn't be a problem as we have the fallback
then to just use the SDL default.)

I wonder if we perhaps should change the behaviour in our game.
Whereby up to now we got a lot of reports that our game is running
faster since we have it. But it could be that I am not up-to-date
anymore (I only get this reports indirectly from our Windows developer).



Is that also true for OpenGL & SDL_HWSURFACE?

On Wed, Mar 25, 2009 at 3:49 PM, Albert Zeyer
<albert.zeyer at rwth-aachen.de> wrote:


That sounds reasonable. The problem is that if you've got someone with
Win95 on an ancient machine where DirectDraw would be a better choice,
we still default to GDI first, and *that* is less nice. I guess a
"maybedirectx" driver could be put in front of the GDI one, which
would try to figure out if DirectX is a good or a bad idea (query for
DirectX 8, if you get it, then skip DirectX, for example). That said,
this is becoming less and less relevant, I think...


I'm not entirely aware of the details there, as I don't use it myself,
it's just been reported. I saw the DirectDraw slowdowns on DirectX 8
and up, though, pretty visible (test programs that used to have 50 fps
and up down to below 10 fps, but they also sucked on Linux, so...).


You could still have a bit of Windows-specific code to use SDL_setenv
to set the video driver to DirectX in your game before initializing
SDL, checking on some conditions that work for your users. No
modification to SDL required, just more hacking. ;-)


OpenGL is its own deal, separate from SDL (the latter only gives you a
portable access to the platform OpenGL), so if OpenGL is hardware
accelerated, then it will be for a program using OpenGL through the
SDL binding (but any SDL calls that aren't using OpenGL won't be
accelerated). That's one of the reasons that the OpenGL rendering in
SDL 1.3 is so nice, SDL will use OpenGL itself if available, so we
finally have access to hardware acceleration on Linux! If your OpenGL
isn't hardware accelerated, though, software is still the word. I
curse the lack of (useful) access to the 2D accelerators on Linux all
the time, there's very little you can do even using Xlib directly
(solid fills, non-colorkeyed, non-alpha blits, that's more or less
it)...

SDL_HWSURFACE is just a "nice request", if it's not available, you
still get a surface that won't be on hardware, and/or won't be
accelerated.

The general situation on Linux is that either your game should be
simple enough to be doable in software (which is still fairly nice on
a modern machine, but on an old geezer, it gets unimpressive real
quick), or you can do 2D effects with OpenGL, basically requiring 3D
hardware acceleration, but guaranteeing solid performance everywhere
(even a crappy Intel GMA can do a whole bunch of 2D effects without
sweat).

--
http://pphaneuf.livejournal.com/

On Wed, Mar 25, 2009 at 08:49:07PM +0100, Albert Zeyer wrote:

I forget exactly, but Tux Paint in fullscreen mode on some Windows systems
had some crazy issues when using the (at the time) default DirectX driver
via SDL.

*digging up details*

So the issues we had listed in the "Known Issues" for Tux Paint 0.9.15
(from November 2005), and whcih were resolved by using 'windib' driver
in SDL, included:

* Running Tux Paint causes Windows to reboot or display a "blue screen"
error message.
* Fullscreen mode causes monitor synchronization problems.
* TabletPC stylus does not work properly in fullscreen mode.
* Mouse does not move properly in fullscreen mode, or is offset.

Pretty nasty, and the work-around involved asking users to screw around
with their environment variables. :^P

http://tuxpaint.org/docs/windib/

--
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

Am 25.03.2009 um 21:41 schrieb Bill Kendrick:


Uh, that's not nice. But I don't think that this is TuxPaint's (or
SDL's) fault. That seems more like a driver problem. Probably these
users have similar crashes also with other 3D applications. Whereby it
could be more stable with WinDIB of course.


Hm, we didn't had such reports yet. (But our game is also mostly
controlled by keyboard; only in the menu is controlled by mouse.)

Btw., November 2005, these problems were on Windows XP then?

I am still not sure if we should change our current behaviour.
Probably a lot of people will complain about less FPS.

I am really looking forward to a stable SDL 1.3, then we can finally
really use OpenGL without much changes and can use this as the
prefered videodriver. We already thought often about implementing all
this by ourself but nobody found the time/encourage to implement this,
so it's nice to have this already in SDL.

It's definitely a driver issue, but TuxPaint gets the blame. :)

DirectDraw was becoming a liability on Windows, so we switched to WinDib
as the default. This all becomes irrelevant with SDL 1.3, which is
likely drawing with Direct3D behind the scenes, even for 2D stuff.

--ryan.

On Thu, Mar 26, 2009 at 04:06:51AM -0400, Ryan C. Gordon wrote:

Millions of users can't be wrong! >:^)

-bill!