Directx vs windib

While porting my SDL game to windows I’ve noticed that SDL’s directx
graphics support is awesome slow compared to the windlib driver. I ran a
small benchmark to verify my suspicion: I ran testwin.exe which comes
with the sdl package with different parameters (see below for the results).

The biggest problem is running directx fullscreen with doublebuffer
enabled. Windib is about 10x faster there! What’s the reason for this
odd behaviour? DirectX is somewhat unusable because of its speed right
now…

Here are the results with directx:-----------------------------------------------
testwin -speedy -hw -flip -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in video memory)
Double-buffering enabled
(image surface located in video memory)
Time: 1622 milliseconds

testwin -speedy -hw -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in video memory)
(image surface located in video memory)
Time: 73 milliseconds

testwin -speedy -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 498 milliseconds

testwin -speedy -flip -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in video memory)
Double-buffering enabled
(image surface located in video memory)
Time: 1605 milliseconds

testwin -speedy -hw -flip
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 156 milliseconds

testwin -speedy -hw
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 258 milliseconds

testwin -speedy -flip
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 252 milliseconds

testwin -speedy
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 251 milliseconds

and here with windlib:

testwin -speedy -hw -flip -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 158 milliseconds

testwin -speedy -hw -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 158 milliseconds

testwin -speedy -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 158 milliseconds

testwin -speedy -flip -fullscreen
Set fullscreen 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 160 milliseconds

testwin -speedy -hw -flip
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 139 milliseconds

testwin -speedy -hw
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 141 milliseconds

testwin -speedy -flip
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 148 milliseconds

testwin -speedy
Set 640x480x32 mode
(video surface located in system memory)
(image surface located in system memory)
Time: 143 milliseconds

Bye,
Michael Prager

Oops… forgot to post my specs :stuck_out_tongue:

Hardware:
GeForce4 Ti 4200 64MB (BIOS 4.25.00.30)
AthlonXP 3000+
1GB ram
K7S8XE+

Software:
WindowsXP Professional SP2
Nvidiadriver 6.14.10.6177
DirectX 9.0c
DirectDraw Library Version 5.03.2600.2180
Desktop Res 1280x1024x32
SDL-1.2.7
SDL compiled using MinGW-3.1.0-1 and msys with DirectX headers from
libsdl.org/extras/win32

Michael Prager wrote:

The biggest problem is running directx fullscreen with doublebuffer
enabled. Windib is about 10x faster there! What’s the reason for this
odd behaviour? DirectX is somewhat unusable because of its speed right
now…

I noticed SDL/directx is slow on my program, but I couldn’t verify if it
was due to SDL or my code. How do you enable windib support? If a
specially compiled DLL is required, could you mail it to me, or post a
link so I could download it and try at my system?

Btw. I noticed in your results that, using windib, there are no reports
of using double-buffering. Can someone clarify why is it so?

Ivan Voras wrote:

I noticed SDL/directx is slow on my program, but I couldn’t verify if
it was due to SDL or my code.

I thought it was a problem in my code in the first place too, but when I
ran the test programs supplied with SDL I noticed that this problem has
nothing todo with my code.

How do you enable windib support? If a specially compiled DLL is
required, could you mail it to me, or post a link so I could download
it and try at my system?

There is no special dll required, SDL should have windib support
compiled in by default. You can switch to windib by setting the
SDL_VIDEODRIVER environment variable to windib (more info here:
http://www.libsdl.org/faq.php?action=listentries&category=9#10) or by
compiling SDL without DirectX support. I didn’t find a way to choose the
driver from inside the application yet though.

You can found out the video driver currently in use with
SDL_VideoDriverName (http://sdldoc.csn.ul.ie/sdlvideodrivername.php) or
you can simply run test/testvidinfo.c supplied within the SDL package.

Btw. I noticed in your results that, using windib, there are no
reports of using double-buffering. Can someone clarify why is it so?

Obviously SDL does not activate double buffer when using the windib
driver. Don’t ask me why this is happening, maybe someone else on this
list has an idea.

I’ve run further tests using different SDL versions and have noticed
that there is no difference between SDL 1.2.4, 1.2.6, 1.2.7 and today’s
CVS version concerning this problem.

This is the output I got from testvidinfo.exe:

Video driver: windib
Current display: 32 bits-per-pixel
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Fullscreen video modes:
1280x1024x32
1024x768x32
800x600x32
640x480x32
640x400x32
512x384x32
480x360x32
400x300x32
320x240x32
320x200x32
A window manager is available

Video driver: directx
Current display: 32 bits-per-pixel
Red Mask = 0x00ff0000
Green Mask = 0x0000ff00
Blue Mask = 0x000000ff
Fullscreen video modes:
800x600x32
1280x1024x32
1024x768x32
800x600x32
640x480x32
640x400x32
512x384x32
480x360x32
400x300x32
320x240x32
320x200x32
640x480x32
A window manager is available
Hardware surfaces are available (59776K video memory)
Copy blits between hardware surfaces are accelerated
Colorkey blits between hardware surfaces are accelerated
Copy blits from software surfaces to hardware surfaces are accelerated
Colorkey blits from software surfaces to hardware surfaces are accelerated
Color fills on hardware surfaces are accelerated

If someone wants to run the benchmark I did - here is the scrip I used
(you’ll need msys and the msysDTK to run it): run-benchmark.sh

#!/bin/sh
testvidinfo.exe && cat stdout.exe > results.txt
echo -e “\ntestwin -speedy -hw -flip -fullscreen” >> results.txt
testwin -speedy -hw -flip -fullscreen && cat stdout.txt >> results.txt
&& sleep 3
echo -e “\ntestwin -speedy -hw -fullscreen” >> results.txt
testwin -speedy -hw -fullscreen && cat stdout.txt >> results.txt && sleep 3
echo -e “\ntestwin -speedy -fullscreen” >> results.txt
testwin -speedy -fullscreen && cat stdout.txt >> results.txt && sleep 3
echo -e “\ntestwin -speedy -flip -fullscreen” >> results.txt
testwin -speedy -flip -fullscreen && cat stdout.txt >> results.txt &&
sleep 3
echo -e “\ntestwin -speedy -hw -flip” >> results.txt
testwin -speedy -hw -flip && cat stdout.txt >> results.txt && sleep 3
echo -e “\ntestwin -speedy -hw” >> results.txt
testwin -speedy -hw && cat stdout.txt >> results.txt && sleep 3
echo -e “\ntestwin -speedy -flip” >> results.txt
testwin -speedy -flip && cat stdout.txt >> results.txt && sleep 3
echo -e “\ntestwin -speedy” >> results.txt
testwin -speedy && cat stdout.txt >> results.txt

Michael Prager wrote:

The biggest problem is running directx fullscreen with doublebuffer
enabled. Windib is about 10x faster there! What’s the reason for
this odd behaviour? DirectX is somewhat unusable because of its
speed right now…

I noticed SDL/directx is slow on my program, but I couldn’t verify if
it was due to SDL or my code. How do you enable windib support? If a
specially compiled DLL is required, could you mail it to me, or post
a link so I could download it and try at my system?

Try this code from within your program, somewhere before you call
SDL_SetVideoMode:

putenv(“SDL_VIDEODRIVER=windib”)

The putenv command is available under Linux and Windows, so it should
work almost everywhere. Another thing (which I’ve done) is to make
this a commandline and settings file option.

So, my application can do ‘NAME_OF_APP -video_driver windib …’ and it
then uses the windib driver.

Btw. I noticed in your results that, using windib, there are no
reports of using double-buffering. Can someone clarify why is it so?

Since I was using software mode in single buffered mode, using windib
vs. directx was the answer. I never tried it for a double-buffered
display.

SteveOn September 14, 2004 08:48 pm, Ivan Voras wrote:

The biggest problem is running directx fullscreen with doublebuffer
enabled. Windib is about 10x faster there! What’s the reason for this
odd behaviour? DirectX is somewhat unusable because of its speed right
now…

DirectX is sync’ing to vertical refresh in double-buffer mode.

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

I’m aware of that, however I don’t think this is the whole problem.
Example: in my little game I have a fade effect, it fades from a pic to
black for example. Using DirectX+double buffer I can actually see single
pixels getting painted!

Sam Lantinga wrote:>>The biggest problem is running directx fullscreen with doublebuffer

enabled. Windib is about 10x faster there! What’s the reason for this
odd behaviour? DirectX is somewhat unusable because of its speed right
now…

DirectX is sync’ing to vertical refresh in double-buffer mode.

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


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