Hi, y’all.
We’re making a game that is almost entirely blt-bound. The basic game structure is
forever
do a little math
handle some events
if (usingDirtyRectangles)
draw background over stuff that's not there anymore
draw any new items
else
blt entire background
draw all display elements
end if
flip
We’re doing the initial development under Windows. We’ve been experimenting with
different video display setups (always 800x600 at the moment).
So here’s the story:
If we use software surfaces for all our data, the flip call does a blt from our
final surface to the display. This takes widely varying amounts of time on different
computers; on a fast Pentium 4, it’s only about 12 seconds do draw and 6 msec to flip,
on a P2/450 it’s about 20 msec to draw and 13 to flip,
but on several different laptops (not slow ones, either – 600 mhz or so) we’re
seeing 20 msec flip times and 40 msec draw times!
In fullscreen mode, we can upload all our surfaces to the hardware and then the draw
(on the P2/450) is only 3 msec and the flip is 0. THAT’s more like it.
But while you can ask for hardware mode in a window, nothing changes. So we poked
into SDL and found a line of code in SDL_dx5video.c that forces software mode if
you’re not in fullscreen. When we commented out this test, we found two
important things:
a) the game still worked, even under alt-Tab and under other windows
b) it ran like a bat outta hell - we saw the same 3 msec draw times and 0 msec
flip times.
We’ve only tested about 5 different machines so far, but it’s a pretty broad
range of stuff, and it always seems to work – and it’s WAY faster.
So the question of the hour is – what are we missing? Why is this test here, and
under what circumstances is it going to fail? We’d hate to ship and find out that “oh,
yeah, that’s there because it fails on the first prime-numbered Tuesday and then never
works again.”
Can anyone shed any light on it?
Kent---
Kent Quirk, CTO, CogniToy
@Kent_Quirk
http://www.cognitoy.com