I’m making a game similar to Baldurs Gate and Fallout so it has a lot of
graphics. I thought of using OpenGL to render it but I don’t think all the
graphics would fit into a graphic cards memory. So I have
decided to stay with SDL only. To speed it up I thought of using the Dirty
Rectangle technique so only the animated objects would need to be drawn each
update. The only problem I can think of is when the view port moves across
the map. The whole screen would need to be redrawn. This would very likely
drop the frame rate to 10-15 fps on a P200. I was wondering if there is
another method I haven’t thought of?_________________________________________________________________
Join the world?s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
moves across the map. The whole screen would need to be redrawn. This
would very likely drop the frame rate to 10-15 fps on a P200. I was
wondering if there is another method I haven’t thought of?
you could try to scroll the screen by moving the framebuffer then update
the borders.
eg: blit the screen from (0,0,640,480) to (10,0,630,480)
the screen will move to the right, then update the 10x480 zone on the left.
this will only be fast if the framebuffer is HW accelered.
in SW, you will just update all the screen i think…
Gautier
I’m making a game similar to Baldurs Gate and Fallout so it has a lot
of graphics. I thought of using OpenGL to render it but I don’t think
all the graphics would fit into a graphic cards memory.
That shouldn’t be a serious problem. Either rely on the OpenGL driver to
do texture caching, or do it manually.
Also note that you don’t have to run all graphics in full resolution on
low end cards - halving the texture resolution on less sensitive stuff
and then having OpenGL stretching it with bilinear interpolation can save
a great deal of space.
So I have decided to stay with SDL only.
Oh well, that’s probably a good idea, unless you really need maximum
frame rate action all the time.
(And eventually, you might be able to use OpenGL indirectly through SDL
anyway. I have a few more features to implement in glSDL, and then we can
see for sure if it’s a viable solution. Results with Kobo Deluxe so far
definitely indicates it is, though. Over 10 times higher frame rates at
higher resolutions on some systems… 
To speed it up I thought of using the
Dirty Rectangle technique so only the animated objects would need to be
drawn each update.
Yeah, that’s a very good idea.
The only problem I can think of is when the view
port moves across the map. The whole screen would need to be redrawn.
This would very likely drop the frame rate to 10-15 fps on a P200. I
was wondering if there is another method I haven’t thought of?
The only method I can think of, short of relying on hardware
acceleration, is hardware scrolling. However, apart from being inherently
messy to get right, it’s not supported by SDL, and it’s not even possible
to do on many targets.
You might be able to get around it by using a different "scrolling"
style, more like switching between “scenes” when crossing certain
boundaries. A very basic version would be to simply center the reference
character whenever it crosses a rectangular boundary some 25-30% from the
edge of the screen.
Not smooth scrolling, but I’d rather have that than some massively
blurred, eye straining mess as soon as you try to walk some where… It’s
either stills or real smooth scrolling - never anything in between, IMHO.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 21 December 2001 15:07, David Moffatt wrote:
moves across the map. The whole screen would need to be redrawn. This
would very likely drop the frame rate to 10-15 fps on a P200. I was
wondering if there is another method I haven’t thought of?you could try to scroll the screen by moving the framebuffer then
update the borders.eg: blit the screen from (0,0,640,480) to (10,0,630,480)
the screen will move to the right, then update the 10x480 zone on the
left.
Yes, that should work well on some targets.
(Unfortunately, it’s less helpful for parallax scrolling - but then
again, that probably belongs in games that should use OpenGL or very low
resolutions anyway…)
this will only be fast if the framebuffer is HW accelered.
in SW, you will just update all the screen i think…
Yeah, that’s the problem. You’d better make damn sure you have
VRAM->VRAM acceleration if you intend to use that method, because you’ll
get real time raytracing class frame rates if you do it with software
blitting…
Ask SDL first, and preferably have an explicit configuration option as
well, just in case some driver is lying about it’s capabilities.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 21 December 2001 15:29, Gautier Portet wrote:
you can also use one of the oldest tricks in the book:
limit the amount of screen real estate that the viewport uses, like the
original BG does. less area means less to update when scrolling. in BG you
have the “menu” type area on the left, the characters on the right, and the
message window on the bottom. typically the view port is only 510x320,
which looks like a lot on the screen, but in reality covers only 53% of it.
(go ahead and do the math, i didn’t really believe the results either,
because the viewport LOOKS a lot larger than a mere half of the screen)>From: “David Moffatt” <david_moffatt at hotmail.com>
Reply-To: sdl at libsdl.org
To: sdl at libsdl.org
Subject: [SDL] Scrolling the view port without dropping the frame rate
Date: Sat, 22 Dec 2001 01:07:45 +1100I’m making a game similar to Baldurs Gate and Fallout so it has a lot of
graphics. I thought of using OpenGL to render it but I don’t think all the
graphics would fit into a graphic cards memory. So I have
decided to stay with SDL only. To speed it up I thought of using the Dirty
Rectangle technique so only the animated objects would need to be drawn
each
update. The only problem I can think of is when the view port moves across
the map. The whole screen would need to be redrawn. This would very likely
drop the frame rate to 10-15 fps on a P200. I was wondering if there is
another method I haven’t thought of?
Join the world?s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Chat with friends online, try MSN Messenger: http://messenger.msn.com
you can also use one of the oldest tricks in the book:
limit the amount of screen real estate that the viewport uses, like the
original BG does. less area means less to update when scrolling. in BG
you have the “menu” type area on the left, the characters on the right,
and the message window on the bottom. typically the view port is only
510x320, which looks like a lot on the screen, but in reality covers
only 53% of it.
Of course! Didn’t think of that right away - probably becaues I’m too
much into fullscreen “graphics demo” style action games. 
BTW, Kobo Deluxe scrolls only 65% of the screen - and that’s including
the area under the rounded corners, which doesn’t really have to be
updated at all. (That’s part of the explanation why software mode can
sometimes be faster than glSDL on some machines - the rendered area is
smaller than you really think.)
(go ahead and do the math, i didn’t really believe the
results either, because the viewport LOOKS a lot larger than a mere
half of the screen)
Yeah, that length/area/volume scale thing… It’s nice when it works to
your advantage for a change!
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 21 December 2001 16:58, Ernest Pazera wrote:
David Olofson <david.olofson at reologica.se> escribi? en el mensaje de
noticias mailman.1008949144.9818.sdl at libsdl.org…On Friday 21 December 2001 15:29, Gautier Portet wrote:
moves across the map. The whole screen would need to be redrawn. This
would very likely drop the frame rate to 10-15 fps on a P200. I was
wondering if there is another method I haven’t thought of?you could try to scroll the screen by moving the framebuffer then
update the borders.eg: blit the screen from (0,0,640,480) to (10,0,630,480)
the screen will move to the right, then update the 10x480 zone on the
left.
Yes, that should work well on some targets.
(Unfortunately, it’s less helpful for parallax scrolling - but then
again, that probably belongs in games that should use OpenGL or very low
resolutions anyway…)
Using that technique (that is scrolling the framebuffer, and only painting
the edges) at 640x480, 30bpp with no HW acceleration and no RLE blitting, I
got around 30FPS windowed, 40FPS full screen.
That on a PIII @ 500MHz with a Matrox G450
Drirr C.
At 16.48 21/12/2001 -0600, you wrote:
eg: blit the screen from (0,0,640,480) to (10,0,630,480)
the screen will move to the right, then update the 10x480 zone on the
left.
Using that technique (that is scrolling the framebuffer, and only painting
the edges) at 640x480, 30bpp with no HW acceleration and no RLE blitting, I
got around 30FPS windowed, 40FPS full screen.
The quoted technique has sense only if you are working on an hw_surface,
with the card blitter enabled.
You may do a check on that and set a function pointer to the scroll
function that switch between that way if you
are working on an HW_SURFACE and you have the blitter capable of HW to HW
blits, otherwise you’d better
redraw all the visible area for each frame.
Bye,
Gabry