Patch for missing ; in SDL 1.2

Hello !

Index: src/video/Xext/Xxf86vm/XF86VMode.c===================================================================
— src/video/Xext/Xxf86vm/XF86VMode.c (revision 4084)
+++ src/video/Xext/Xxf86vm/XF86VMode.c (working copy)
@@ -290,7 +290,7 @@
}
_XRead(dpy, (char*)modeline->private, modeline->privsize *
sizeof(INT32));
} else {

  •   zap_ptr((char *)&modeline->private, sizeof(modeline->private))
    
  •   zap_ptr((char *)&modeline->private, sizeof(modeline->private));
    }
    UnlockDisplay(dpy);
    SyncHandle();
    

CU

(my fault: fixed in svn revision #4088 for 1.2 branch, #4089 for trunk.)

–ryan.

Hi Ryan,

In case you haven’t yet noticed, this fixes
http://bugzilla.libsdl.org/show_bug.cgi?id=624

Thanks,
Oliver

Ryan C. Gordon wrote:>

(my fault: fixed in svn revision #4088 for 1.2 branch, #4089 for trunk.)

–ryan.


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

Hello !

(my fault: fixed in svn revision #4088 for 1.2 branch, #4089 for trunk.)

Thanks.

Please also add my other patch,
that sets Waveout before DSound. Not only DirectX 5
is problematic for Video today, but also for sound.

CU

Please also add my other patch,
that sets Waveout before DSound. Not only DirectX 5
is problematic for Video today, but also for sound.

waveout sound has 1/4 second latency. What issues are you running into
using DirectSound?

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

Not only DirectX 5 is problematic for Video today, but also for sound.
waveout sound has 1/4 second latency. What issues are you running into
using DirectSound?

Not directly on topic, but as it was mentioned in
the original post: why has the directx/ddraw interface
been deprecated (special vista issues it seems but
information seems sparse) and why is the hardware
acceleration for directx/ddraw always disabled?

Thanks.

hi,

Because some code is broken on some machines. You can set it back
with a SDL_VIDEODRIVER environment variable.

For pygame we changed it so that directx is default for windows <= XP
machines. Since this seemed to break less code, than the default SDL
choice.

By this I mean directx is way faster for many machines (but not all),
and some old machines could no longer run some programs at acceptable
frame rates. directx also seems to have faster input from mouse.

Since the last pygame release we realised that is not enough… we
should really choose windib also for directx >= 9 (mainly for
un-updated intel machines). Or maybe intel + directx > 9… because
the directx driver works with many dx9 cards. We also decided to do
add a function to do a runtime test to see which driver works best.

cheers,On Mon, Sep 22, 2008 at 1:51 AM, wrote:

Not only DirectX 5 is problematic for Video today, but also for sound.
waveout sound has 1/4 second latency. What issues are you running into
using DirectSound?

Not directly on topic, but as it was mentioned in
the original post: why has the directx/ddraw interface
been deprecated (special vista issues it seems but
information seems sparse) and why is the hardware
acceleration for directx/ddraw always disabled?

Thanks.


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

Because some code is broken on some machines. You can set it back
with a SDL_VIDEODRIVER environment variable.

Right that’s what we’re doing (along with placing the directx/ddraw
interface at the first place during init).
What code is broken on what machines? Is it documented somewhere?

For pygame we changed it so that directx is default for windows <= XP
machines. Since this seemed to break less code, than the default SDL
choice.

The windib interface does not work reliable for us as well
(ugly bugs in fullscreen, severe slowdowns during palette changes,
keyboard problems etc.), that’s why I’d like to have information
why the default was changed.

By this I mean directx is way faster for many machines (but not all),
and some old machines could no longer run some programs at acceptable
frame rates. directx also seems to have faster input from mouse.

Right, and the directx/ddraw interface seems to be even faster and
more reliable (gaining higher fps in most situations) when hardware
acceleration is enabled, which is disabled in the SDL sources for
reasons I could not figure out (it can’t be enabled by application
code but needs changes to the sources).

Since the last pygame release we realised that is not enough… we
should really choose windib also for directx >= 9 (mainly for
un-updated intel machines).

So intel graphics cards bear problems? How does this surface
(speed? graphics bugs? fullscreen problems?)

Thanks!

Hello !

Right, and the directx/ddraw interface seems to be even faster and
more reliable (gaining higher fps in most situations) when hardware
acceleration is enabled, which is disabled in the SDL sources for
reasons I could not figure out (it can’t be enabled by application
code but needs changes to the sources).

Why do you need to change the sources ?

You can set the env. variable
SDL_VIDEODRIVER to directx :

SDL_putenv(“SDL_VIDEODRIVER=directx”);

before SDL_Init i think.

CU

Hello !

waveout sound has 1/4 second latency. What issues are you running into
using DirectSound?

On Windows XP i never had problems with DSound, but
with Windows Vista two other machines crash with my game
and using DSound.

First i thought it is an error in my code,
but then i tested also the loopwave example on these machines
and they crashed, too.

CU

I have patches in bugzilla for some of the DirectX backend’s
shortcomings, for what it’s worth. Perhaps they’ll make it into the
next maintenance release:

http://bugzilla.libsdl.org/show_bug.cgi?id=611
http://bugzilla.libsdl.org/show_bug.cgi?id=618
http://bugzilla.libsdl.org/show_bug.cgi?id=619

My (potenitally poor) understanding about windib being the default is
that 2D performance is quite poor with DirectX since newer versions of
DirectX emulate the API of the version which SDL utilises. This
emulation, for whatever reason, is not optimal. This is all by memory
though, so could be 100% bullshit. I’m sure it’s been covered on the
mailing list in the past, so maybe it’s worth doing a search.On Mon, 22 Sep 2008 21:21:34 +0200 c2woody at gmx.net wrote:

Because some code is broken on some machines. You can set it back
with a SDL_VIDEODRIVER environment variable.

Right that’s what we’re doing (along with placing the directx/ddraw
interface at the first place during init).
What code is broken on what machines? Is it documented somewhere?

TA> I have patches in bugzilla for some of the DirectX backend’s
TA> shortcomings, for what it’s worth.

Thanks for pointing to the bug tracker threads. The WM_SYSKEYDOWN is
a point we’ve encountered as well. I hope that the directx/ddraw
interface is not completely ignored so patches like yours will be
incorporated.

I have patches in bugzilla for some of the DirectX backend’s
shortcomings, for what it’s worth. Perhaps they’ll make it into the
next maintenance release:

http://bugzilla.libsdl.org/show_bug.cgi?id=611
http://bugzilla.libsdl.org/show_bug.cgi?id=618
http://bugzilla.libsdl.org/show_bug.cgi?id=619

My (potenitally poor) understanding about windib being the default is
that 2D performance is quite poor with DirectX since newer versions of
DirectX emulate the API of the version which SDL utilises. This
emulation, for whatever reason, is not optimal. This is all by memory
though, so could be 100% bullshit. I’m sure it’s been covered on the
mailing list in the past, so maybe it’s worth doing a search.

I believe the problems were from Vista and 64-bit. Your patches help a
lot, but I’m still having troubles with OpenGL in Vista (it’s almost as if
Microsoft doesn’t want people to use OpenGL, maybe they have a competing
API they’d rather people use?) and one user running the new Aleph One in
Windows 9x reports no mouse control with the directx backend (without
OpenGL enabled, no less).

I’m guessing non-SDL Windows games must do a lot of runtime version and
quirk checking to see which features to try and turn on, or maybe they
just don’t try to run on as wide a range of platforms as SDL (XP only, DX9
only, etc.), or they just use Direct3D and are done with it.

If anybody has any suggestions on how to handle this whole directx vs
windib thing I’d love to hear them. windib is pretty safe but
SetDeviceGammaRamp is restricted so our fade-ins and fade-outs look
stupid. directx is nice and smooth when it works, which it doesn’t always.
Right now I just apply Tim’s patches, and make the backend a checkbox so
it’s the user’s problem :frowning:

In Mac OS X and Linux, everything works flawlessly, of course.

GregoryOn Mon, 22 Sep 2008, Tim Angus wrote:

GS> I believe the problems were from Vista and 64-bit.

I’ve played with 64bit vista a bit using msvc to compile a native
64bit version of SDL and there are indeed a few problems (all are
fixable as far as I can tell, the build works fine for my testings).
I have not done testing/debugging of 32bit builds under 64bit vista
yet though.

Thanks for your information.

TG> On Windows XP i never had problems with DSound, but
TG> with Windows Vista two other machines crash with my game
TG> and using DSound.

Where does it crash? Why not fixing it but rather switch
to a (rarely used) different interface and proposing that
as a default?

Hello !

Where does it crash? Why not fixing it but rather switch
to a (rarely used) different interface and proposing that
as a default?

The problem was, it was not happening on my machine.
in general does not run well with the todays DirectX APIs.

DirectX5 is now completely software emulated on top of DirectX 9
or 10.

Changing from DirectX5 to 7 or 9 would break a big
part of SDL installations, as simply not every system has
a way to upgrade to 7 or 9.

But if you are willing to write a DX7 or 9 driver,
i think Sam will be happy to integrate it into SDL 1.2

Another reason is to be consistent as we changed the Video API
to GDI, why not also changing the Sound API to WaveOut.

It is always a good way to ask the user what he wants
to use, DirectX 5, WinDIB, X11, FBCON, SVGALIB …

In the future you will have two options for games, you can
write your game with SDL 1.2 and have it perfectly fine running
with old systems and old installations for example Windows 98 and so on.

With SDL 1.3/2.0 you can run your game perfect on newer systems like
XP and Vista.

CUFrom my searches with Google through the net DirectX 5

The problem was, it was not happening on my machine.

Indeed it is the easiest to switch to a different interface then.

Hello !

Indeed it is the easiest to switch to a different interface then.

If you can debug and fix this problem on your machine,
i think Sam will be happy to integrate it.

But besides from Bugs :

Personally i think it would be
better to write a DirectX5 driver for

SDL 1.3/2.0 or port it from SDL 1.2 to SDL 1.3/2.0

This is the next version of SDL with superb features
and the most coding power should go into it.

CU