Quick 2D paralax scrolling

Just wondering if anyone has any quick 2D paralax scrolling routines in
SDL…

I’ve got some myself, but their performance leaves quite a bit to be
desired… Specifically, I keep the various background layers (or looping
layers) in surfaces which I blit onto the screen surface (using
SDL_BlitSurface or the lower blit function) whenever the screen
moves. Then I (of course) blit the foreground graphics. I’ve used various
combinations of UpdateRect and UpdateRects, but can seem to increase
performance. (I’m basically trying to get performance similar to those old
16-bit cart games for SNES/Genesis… and I have a 300 MHz AMD-K6 w/ 128
Megs RAM and an 8 Meg graphic card, so I hoped that I could…)

Anyone have any suggestions? (I’m trying to do this without using
additional libraries such as PowerScroll and such…)

Thx.–
Sam Hart http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM HART
http://www.geekcomix.com/ - Geekcomix, the Daily Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ - Ghostworks (Alt./Linux Computing)

I’ve got some myself, but their performance leaves quite a bit to be
desired… Specifically, I keep the various background layers (or looping
layers) in surfaces which I blit onto the screen surface (using
SDL_BlitSurface or the lower blit function) whenever the screen
moves. Then I (of course) blit the foreground graphics. I’ve used various
combinations of UpdateRect and UpdateRects, but can seem to increase
performance.

If you are drawing to a software surface (for example, in X11 without DGA),
then it might pay off to undraw the overlays and sprites, if the background
stays put. That way you don’t have to paint the entire buffer each frame.
It could be doable on hardware surfaces as well (with page flipping) but
then you want to minimize the slow reading from the buffer.

(I’m basically trying to get performance similar to those old
16-bit cart games for SNES/Genesis… and I have a 300 MHz AMD-K6 w/ 128
Megs RAM and an 8 Meg graphic card, so I hoped that I could…)

Don’t be so sure. Those machines have dedicated multi-layer tile-based video
circuits that can do a lot of this in relatively simple hardware, while you
have to waste a huge amount of cycles each frame to do it.

What kind of game are you doing, BTW? Is it a space shooter? Please please…

In fact, I wonder about this. There are many game emulators for these
systems, and they run at full speed on my k6. (I own every ROM I play
on these emulators, of course). There is something that we are doing
way too slow, I think.

James Best

Mattias Engdeg?rd wrote:>

I’ve got some myself, but their performance leaves quite a bit to be
desired… Specifically, I keep the various background layers (or looping
layers) in surfaces which I blit onto the screen surface (using
SDL_BlitSurface or the lower blit function) whenever the screen
moves. Then I (of course) blit the foreground graphics. I’ve used various
combinations of UpdateRect and UpdateRects, but can seem to increase
performance.

If you are drawing to a software surface (for example, in X11 without DGA),
then it might pay off to undraw the overlays and sprites, if the background
stays put. That way you don’t have to paint the entire buffer each frame.
It could be doable on hardware surfaces as well (with page flipping) but
then you want to minimize the slow reading from the buffer.

(I’m basically trying to get performance similar to those old
16-bit cart games for SNES/Genesis… and I have a 300 MHz AMD-K6 w/ 128
Megs RAM and an 8 Meg graphic card, so I hoped that I could…)

Don’t be so sure. Those machines have dedicated multi-layer tile-based video
circuits that can do a lot of this in relatively simple hardware, while you
have to waste a huge amount of cycles each frame to do it.

What kind of game are you doing, BTW? Is it a space shooter? Please please…

In fact, I wonder about this. There are many game emulators for these
systems, and they run at full speed on my k6. (I own every ROM I play
on these emulators, of course). There is something that we are doing
way too slow, I think.

Console systems have FAR lower resolution than what most people design
for PC’s. (ie, something closer to 320x200 or 512x256 - TV res., vs.
640x480 or 800x600 :slight_smile: )

-bill!

What kind of game are you doing, BTW? Is it a space shooter? Please please…

No, good idea tho…

Actually, it’s simply part of a sequence of self-taught lessons I’m
doing… the game will be a simple mud, but I was thinking if I were to
do anything further with it, I’d like to add some elements I’d like to see
in muds… and I was thinkng back to all those classic cart RPGs (Phantasy
Star, FF, et al) and how fun some of those could be if they were presented
as open-ended muds… or, how cool a mud could be if it had decent
graphics w/ parallax scrolling and such ;)… nothing as ambitious as
World Forge and the like, tho…On Tue, 25 Apr 2000, Mattias Engdegard wrote:


Sam Hart http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM HART
http://www.geekcomix.com/ - Geekcomix, the Daily Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ - Ghostworks (Alt./Linux Computing)

In fact, I wonder about this. There are many game emulators for these
systems, and they run at full speed on my k6. (I own every ROM I play
on these emulators, of course). There is something that we are doing
way too slow, I think.

Exactly what I was thinking… Truthfully, on my system, most of these
old titles run even faster (with no decernable frame-loss) with the
emulator.

I know about the dedicated versus delegated game hardware issues (hell, I
wrote an essay on the subject comparing PC’s to Jeeps and VG Consoles to
Race Cars [race cars are great for racing, but lousy for towing a payload
off-road])… but I see the performance that SNES9X and XMAME get and I
want the same… was just hoping someone had figured something better…On Tue, 25 Apr 2000, James M Best wrote:


Sam Hart http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM HART
http://www.geekcomix.com/ - Geekcomix, the Daily Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ - Ghostworks (Alt./Linux Computing)

In fact, I wonder about this. There are many game emulators for these
systems, and they run at full speed on my k6. (I own every ROM I play
on these emulators, of course). There is something that we are doing
way too slow, I think.

Of course it can be done, but it comes at a price - you don’t want to spend
all CPU on just the rendering, but have something left for AI, sound etc.
Console systems typically have low resolutions, but no doubt you want to
take advantage of the video memory and high resolution of modern machines,
for at least 1024x768 in 24 bit colour.