Strategic advice on blitting

SDL Development
1

Hello,

I need a stategic advice.

I’m writing this game seen from above (like Warcraft). I want that,
when user presses the right button mouse and drags it, the map moves
with it. (if anyone ever played Transport Tycoon, it’s exactly like
this).

I’m doing something like this: a big map surface, and the screen
surface. So when the event mousemove happens (with the right button
pressed), the part of the map is blitted on the screen. But the
problem is that it’s too slow!

So how could I do that? Maybe with a thread? Any advice would be
apreciated!

Andre’–
? Andre’ Wagner - 2003 - All rights reserved

2

Well, if it’s actually too slow (ie insufficient frame rate to look
good), all you can do is check your display settings, surfaces
formats etc; the usual performance tweaking stuff. If all else fails,
try glSDL or native OpenGL rendering.

However, I suspect your problem is that you can’t keep up with the
rate of the mouse motion events, so they queue up, and you get that
nice rubber band delay feel. :slight_smile:

What you do about that is simply make sure you empty the event queue
once per rendered frame. That is;

while(running)
{
	while(there_are_events)
		process_event();
	render();
	SDL_Flip();
}

Obviously, this implies that you do not repaint the screen as a direct
effect of processing any events! Only update variables and stuff
until you have nothing more to do, then refresh the display.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 22 September 2003 16.47, Andre’ Wagner wrote:

Hello,

I need a stategic advice.

I’m writing this game seen from above (like Warcraft). I want that,
when user presses the right button mouse and drags it, the map
moves with it. (if anyone ever played Transport Tycoon, it’s
exactly like this).

I’m doing something like this: a big map surface, and the screen
surface. So when the event mousemove happens (with the right button
pressed), the part of the map is blitted on the screen. But the
problem is that it’s too slow!

So how could I do that? Maybe with a thread? Any advice would be
apreciated!

3

Do you mean that you have the entire map as a surface? Like an image of the
map in finished form?
You don’t use tiles? If not, that is one thing I would advice you to do.
It’s easier to get change the map and it’s easy to get it fast.
If you are using one HUGE surface to hold the map I guess you decide wich
part is visible on the screen and blit only that region right?> ----- Original Message -----

From: andre@syspoint.com.br (Andre Wagner)
To:
Sent: Monday, September 22, 2003 4:47 PM
Subject: [SDL] Strategic advice on blitting

Hello,

I need a stategic advice.

I’m writing this game seen from above (like Warcraft). I want that,
when user presses the right button mouse and drags it, the map moves
with it. (if anyone ever played Transport Tycoon, it’s exactly like
this).

I’m doing something like this: a big map surface, and the screen
surface. So when the event mousemove happens (with the right button
pressed), the part of the map is blitted on the screen. But the
problem is that it’s too slow!

So how could I do that? Maybe with a thread? Any advice would be
apreciated!

Andre’

–
? Andre’ Wagner - 2003 - All rights reserved

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

4

Just to add to David’s comments, a thread won’t solve your problem on a single-processor machine, as your game won’t get more processing power, instead, it will divide the processing power between two threads, not to mention that you will need to synchronize them so that neither of them screw up anything (in the end it may be actually slower). It’s similar to the Turing Machine dilemma, ie, a multi-headed/multi-tape machine is not more powerful than a single-head/single-tape machine.

DAvid’s idea to get all mouse events from the queue is feasible, if you can’t draw at the same speed your mouse updates its position, the best is to draw only the most recent position you have.

Paulo>

From: David Olofson
Date: Mon, 22 Sep 2003 17:21:54 +0200
To: sdl at libsdl.org
Subject: Re: [SDL] Strategic advice on blitting

On Monday 22 September 2003 16.47, Andre’ Wagner wrote:

Hello,

I need a stategic advice.

I’m writing this game seen from above (like Warcraft). I want that,
when user presses the right button mouse and drags it, the map
moves with it. (if anyone ever played Transport Tycoon, it’s
exactly like this).

I’m doing something like this: a big map surface, and the screen
surface. So when the event mousemove happens (with the right button
pressed), the part of the map is blitted on the screen. But the
problem is that it’s too slow!

So how could I do that? Maybe with a thread? Any advice would be
apreciated!

Well, if it’s actually too slow (ie insufficient frame rate to look
good), all you can do is check your display settings, surfaces
formats etc; the usual performance tweaking stuff. If all else fails,
try glSDL or native OpenGL rendering.

However, I suspect your problem is that you can’t keep up with the
rate of the mouse motion events, so they queue up, and you get that
nice rubber band delay feel. :slight_smile:

What you do about that is simply make sure you empty the event queue
once per rendered frame. That is;

while(running)
{
while(there_are_events)
process_event();
render();
SDL_Flip();
}

Obviously, this implies that you do not repaint the screen as a direct
effect of processing any events! Only update variables and stuff
until you have nothing more to do, then refresh the display.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

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

5

[…]

DAvid’s idea to get all mouse events from the queue is feasible,
if you can’t draw at the same speed your mouse updates its
position, the best is to draw only the most recent position you
have.

And keep in mind that some mice and similar devices can generate
hundreds of events per second, while the screen could (should!) be
retrace sync’ed, clamping the frame rate somewhere between 60 and 200
fps.

In, short never assume that you can do one update per input event.
Someone will file a bug report sooner or later if you do.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 22 September 2003 17.42, pvwr at sympatico.ca wrote:

6

— Daniel Liljeberg <damien_ at hotmail.com> wrote:

Do you mean that you have the entire map as a surface? Like an image
of the map in finished form? You don’t use tiles? If not, that is
one
thing I would advice you to do. It’s easier to get change the map
and
it’s easy to get it fast. If you are using one HUGE surface to hold
the map I guess you decide wich part is visible on the screen and
blit
only that region right?

My current project also involves a 2d map built out of tiles. At the
entry to each level, the entire map is built onto a rather large
surface
and then sub-sections of that surface are blitted to the display to
provide the map underlay. I chose this approach on the grounds that
while the larger ‘entire map’ surface was, well, quite large, it was
much quicker to blit a since section of it once every render loop than
it would be to build the appropriate section of background out of tiles
each render loop. The former only takes one blit, the latter would
take dozens.

                                                          NBarnes__________________________________

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

7

While doing tests I discovered that it’s how MUCH you blit, not HOW MANY
TIMES you blit thats important. Ok, there is an overhead for a functioncall.
But when meassuring the time it took to render an image onto the screen and
then cuttin that image into 222 pices and rendering them, the time was
almost identical. Thus the consensus emerging here is that the time it takes
to call SDL_Blitsurcae is of no importance in relation to the time it
actually takes to blit a full screen. So using tiles and representing your
map as a 2dvector of tiles is probably an easy way to handle the map and
with VERY little speed disadvantage.

Anyways, for speed purposes I can second the guy who mentioned glSDL. I used
gl to render a 2D tilebased game once. I didn’t use glSDL though but rather
did the gl-thing from the ground up. It worked nice though and you can do
some cool fx’s.

Best regards
Daniel Liljeberg> ----- Original Message -----

From: nw_barnes@yahoo.com (NBarnes)
To:
Sent: Tuesday, September 23, 2003 12:44 AM
Subject: Re: [SDL] Strategic advice on blitting

— Daniel Liljeberg <@Daniel_Liljeberg> wrote:

Do you mean that you have the entire map as a surface? Like an image
of the map in finished form? You don’t use tiles? If not, that is
one
thing I would advice you to do. It’s easier to get change the map
and
it’s easy to get it fast. If you are using one HUGE surface to hold
the map I guess you decide wich part is visible on the screen and
blit
only that region right?

My current project also involves a 2d map built out of tiles. At the
entry to each level, the entire map is built onto a rather large
surface
and then sub-sections of that surface are blitted to the display to
provide the map underlay. I chose this approach on the grounds that
while the larger ‘entire map’ surface was, well, quite large, it was
much quicker to blit a since section of it once every render loop than
it would be to build the appropriate section of background out of tiles
each render loop. The former only takes one blit, the latter would
take dozens.

                                                          NBarnes

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

8

Actually, unless you have very small levels, or tons of different
tiles (ie no reuse), I suspect that the “direct to screen” approach
is faster.

Pre-rendering a large map means you get a huge surface, which may not
fit in VRAM (for accelerated blitting), and definitely won’t fit in
the CPU cache. The latter may not be a major issue, since you’ll only
get cache misses around the edges of the screen when scrolling. Don’t
do it with RLE accelerated surfaces, though… As to “out of VRAM”,
the only way to avoid that with such amounts of graphics data is to
use some graphics caching system - and then slow uploads to VRAM
might kill performance.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 23 September 2003 02.07, Daniel Liljeberg wrote:

While doing tests I discovered that it’s how MUCH you blit, not HOW
MANY TIMES you blit thats important. Ok, there is an overhead for a
functioncall. But when meassuring the time it took to render an
image onto the screen and then cuttin that image into 222 pices and
rendering them, the time was almost identical. Thus the consensus
emerging here is that the time it takes to call SDL_Blitsurcae is
of no importance in relation to the time it actually takes to blit
a full screen. So using tiles and representing your map as a
2dvector of tiles is probably an easy way to handle the map and
with VERY little speed disadvantage.

9

I do not mean that you blit all of your tiles to form the map to a surface
and then blit that surface onto the screen. You blit your tiles directly to
the screen, every loop. Say that you have a 2dvector of 32x32 pixels tiles.
You calculate wich ones are visible on the screen depending on where the
camera is and draw these tiles one by one to the screen. One thing to think
of to gain some extra speed if you are using open gl is to sort them by
texture also so that you won’t have many switches between textures.> ----- Original Message -----

From: david@olofson.net (David Olofson)
To:
Sent: Tuesday, September 23, 2003 10:30 AM
Subject: Re: [SDL] Strategic advice on blitting

On Tuesday 23 September 2003 02.07, Daniel Liljeberg wrote:

While doing tests I discovered that it’s how MUCH you blit, not HOW
MANY TIMES you blit thats important. Ok, there is an overhead for a
functioncall. But when meassuring the time it took to render an
image onto the screen and then cuttin that image into 222 pices and
rendering them, the time was almost identical. Thus the consensus
emerging here is that the time it takes to call SDL_Blitsurcae is
of no importance in relation to the time it actually takes to blit
a full screen. So using tiles and representing your map as a
2dvector of tiles is probably an easy way to handle the map and
with VERY little speed disadvantage.

Actually, unless you have very small levels, or tons of different
tiles (ie no reuse), I suspect that the “direct to screen” approach
is faster.

Pre-rendering a large map means you get a huge surface, which may not
fit in VRAM (for accelerated blitting), and definitely won’t fit in
the CPU cache. The latter may not be a major issue, since you’ll only
get cache misses around the edges of the screen when scrolling. Don’t
do it with RLE accelerated surfaces, though… As to “out of VRAM”,
the only way to avoid that with such amounts of graphics data is to
use some graphics caching system - and then slow uploads to VRAM
might kill performance.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

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

10

I do not mean that you blit all of your tiles to form the map to a
surface and then blit that surface onto the screen. You blit your
tiles directly to the screen, every loop. Say that you have a
2dvector of 32x32 pixels tiles. You calculate wich ones are visible
on the screen depending on where the camera is and draw these tiles
one by one to the screen.

Exactly. I was just trying to point out that this approach isn’t only
practically as fast; it’s most probably faster in some situations.
:slight_smile:

One thing to think of to gain some extra
speed if you are using open gl is to sort them by texture also so
that you won’t have many switches between textures.

That actually slowed things down last time I tried it… Wierd.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 23 September 2003 11.28, Daniel Liljeberg wrote:

11

Odd, it is generally a pretty noticeable speed boost if the renderer is
at all designed for it.
(OTOH, if you end up with a good bit of overhead just to make it
possible, the gain is not going to be much.)On Tue, Sep 23, 2003 at 12:11:05PM +0200, David Olofson wrote:

On Tuesday 23 September 2003 11.28, Daniel Liljeberg wrote:

One thing to think of to gain some extra
speed if you are using open gl is to sort them by texture also so
that you won’t have many switches between textures.

That actually slowed things down last time I tried it… Wierd.

–
1024D/E65A7801 Zephaniah E. Hull <@Zephaniah_E_Hull>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.

Emergency medicine: It’s like sysadminning, but with better LARTs and
more blood. – Mike Sugimoto on ASR.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030923/036f822e/attachment.pgp

12

— David Olofson wrote:> On Tuesday 23 September 2003 11.28, Daniel Liljeberg wrote:

I do not mean that you blit all of your tiles to form the map to a
surface and then blit that surface onto the screen. You blit your
tiles directly to the screen, every loop. Say that you have a
2dvector of 32x32 pixels tiles. You calculate wich ones are visible
on the screen depending on where the camera is and draw these tiles
one by one to the screen.

Exactly. I was just trying to point out that this approach isn’t
only practically as fast; it’s most probably faster in some
situations. :slight_smile:

As far as My Current Project goes, I’ve been learing SDL, graphics
programming, and developing a Serious Game in paralell, so there’s a
lot I don’t know about all three. I’ve only recently been
introduced to the importance of matching your source format to your
destination format for blitting (and haven’t gotten around to doing it
yet, my framerate is fine for function testing and there’s still so
much functionality to implement…). I’m deeply grateful to have a
resource like this list around. My Tidbits of SDL Wisdom file is
getting thick…

                                                           NBarnes

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

13

Care to share your “Tidbits on SDL” file? Would make a great website,
it’s difficult to sift through some of the noise here to get the true
gems out… if you really have such a file please consider sharing it!

— NBarnes <nw_barnes at yahoo.com> wrote: >> — David Olofson wrote:

On Tuesday 23 September 2003 11.28, Daniel Liljeberg wrote:

I do not mean that you blit all of your tiles to form the map to
a

surface and then blit that surface onto the screen. You blit your
tiles directly to the screen, every loop. Say that you have a
2dvector of 32x32 pixels tiles. You calculate wich ones are
visible

on the screen depending on where the camera is and draw these
tiles

one by one to the screen.

Exactly. I was just trying to point out that this approach isn’t
only practically as fast; it’s most probably faster in some
situations. :slight_smile:

As far as My Current Project goes, I’ve been learing SDL, graphics
programming, and developing a Serious Game in paralell, so there’s a
lot I don’t know about all three. I’ve only recently been
introduced to the importance of matching your source format to your
destination format for blitting (and haven’t gotten around to doing
it
yet, my framerate is fine for function testing and there’s still so
much functionality to implement…). I’m deeply grateful to have a
resource like this list around. My Tidbits of SDL Wisdom file is
getting thick…

NBarnes

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

14

One thing to think of to gain some extra
speed if you are using open gl is to sort them by texture also so
that you won’t have many switches between textures.

That actually slowed things down last time I tried it… Wierd.

I guess it depends on the hardware and the drivers. In my Parhelia card
there was almost no difference while in my Radeon 9000 there was a
noticeable speed-up. So it’s always a good idea to avoid texture switching
since you never know in what hardware your app will be running :slight_smile:

ciao, DrSlump

----- Original Message -----
From: david@olofson.net (David Olofson)

15

One thing to think of to gain some extra
speed if you are using open gl is to sort them by texture also
so that you won’t have many switches between textures.

That actually slowed things down last time I tried it… Wierd.

Odd, it is generally a pretty noticeable speed boost if the
renderer is at all designed for it.

Then again, how much should it actually cost to change a pointer and a
few other parameters on any reasonably modern card? I suspect you
can’t do all that much work before you start slowing things down.

(OTOH, if you end up with a good bit of overhead just to make it
possible, the gain is not going to be much.)

Well, the weird thing is that the overhead was minimal in that case -
or at least, that’s what I think! :wink: I should have profiled that
code to find out what was actually going on, but I’m not using that
card these days, and the code was just a messy prototype.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 23 September 2003 13.16, Zephaniah E. Hull wrote:

On Tue, Sep 23, 2003 at 12:11:05PM +0200, David Olofson wrote:

On Tuesday 23 September 2003 11.28, Daniel Liljeberg wrote:

16

One thing to think of to gain some extra
speed if you are using open gl is to sort them by texture also
so that you won’t have many switches between textures.

That actually slowed things down last time I tried it… Wierd.

I guess it depends on the hardware and the drivers.

Yeah - but I can’t figure out how any driver could run faster if you
switch textures more frequently…! Multiple asynchronous rendering
pipes and multiple texture memory banks with individual busses,
maybe? (Though I strongly doubt an old Matrox G400 has anything like
that. :slight_smile:

So, until I can prove anything else, I’ll assume I did something
stupid in that code, or possibly that there was some weird bug in
that driver.

In my Parhelia
card there was almost no difference while in my Radeon 9000 there
was a noticeable speed-up. So it’s always a good idea to avoid
texture switching since you never know in what hardware your app
will be running :slight_smile:

Right. Even better; unless the “avoid texture switching” algo is
virtually free, make it optional. Put it somewhere in “Advanced
Options”, and/or use a list of known cards/drivers to pick the best
mode. I dunno about benchmarking, though. Maybe as part of that
"Autodetect Best Settings" feature that many games have in the
Options dialog?

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 23 September 2003 13.40, Iv?n Montes wrote:

----- Original Message -----
From: “David Olofson” <@David_Olofson>

17

— Paul Smith <googoodolls_uk at yahoo.com> wrote:

Care to share your “Tidbits on SDL” file? Would make a great
website, it’s difficult to sift through some of the noise here to get
the true gems out… if you really have such a file please consider
sharing it!

Er… it’s mostly a collection of kinda-contexted cut-n-pastes from
messages here. Not terribly readable by people other than myself
unless I were to clean it up.

                                                          NBarnes__________________________________

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

18

— David Olofson wrote:> On Tuesday 23 September 2003 13.16, Zephaniah E. Hull wrote:

On Tue, Sep 23, 2003 at 12:11:05PM +0200, David Olofson wrote:

On Tuesday 23 September 2003 11.28, Daniel Liljeberg wrote:

One thing to think of to gain some extra
speed if you are using open gl is to sort them
by texture also

so that you won’t have many switches between
textures.

That actually slowed things down last time I
tried it… Wierd.

Odd, it is generally a pretty noticeable speed
boost if the
renderer is at all designed for it.

Then again, how much should it actually cost to
change a pointer and a
few other parameters on any reasonably modern card?
I suspect you
can’t do all that much work before you start slowing
things down.

But what if you don’t have enough memory to have all
your textures in vid card memory at the same time?
each switch could possibly force the texture to come
across the pipeline again… and wouldn’t vid cards
have caches something akin to processor L1/2 caches?

It all depends on the hardware… and being no video
card hardware expert, I’ll shutup…now.

snip rest of message

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

19

They don’t have caches, or you could say that they have very large
caches :wink: Modern cards prefetches the needed textures in almost any
cases before they are needed. The only difference is if the texture is
so big that it doesn’t fit in the VRAM at all, so the prefetch can be
too slow ie the card needs to wait the data. This on the other hand
needs situations which are not seen in the normal usage. I although
know one specific case that really uses the prefetching. One student at
University have done a space ‘game’ that uses real photos taken from
moon and earth. These take about 300MB of space plus the space needed
for the other planets :).On Wednesday 24 September 2003 07:42, Michael Rickert wrote:

— David Olofson wrote:

Then again, how much should it actually cost to
change a pointer and a
few other parameters on any reasonably modern card?
I suspect you
can’t do all that much work before you start slowing
things down.

But what if you don’t have enough memory to have all
your textures in vid card memory at the same time?
each switch could possibly force the texture to come
across the pipeline again… and wouldn’t vid cards
have caches something akin to processor L1/2 caches?

20

NBarnes wrote:

My current project also involves a 2d map built out of tiles. At the
entry to each level, the entire map is built onto a rather large
surface
and then sub-sections of that surface are blitted to the display to
provide the map underlay. I chose this approach on the grounds that
while the larger ‘entire map’ surface was, well, quite large, it was
much quicker to blit a since section of it once every render loop than
it would be to build the appropriate section of background out of
tiles each render loop. The former only takes one blit, the latter
would take dozens.

Bad call. If you use small tiles, there’s a good chance they’ll go into
video memory (assuming you have all of the setting correct on your side, and
your rendering target supports it), while a surface larger than the screen
is likely to stay in system RAM. The large surface is also likely to result
in many more cache misses for a further decrease in performance.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com