What's the fastest way to do parallax scrolling in a 16-bit 640x480 graphics mode, using Allegro (DOS)? The game that I'm writing (a platform game) uses two parallax scrolling layers plus 3 "normal" layers, and it's too slow to redraw the whole screen using a double buffer every frame (I only get 20 fps on my P2-233 MMX with a cheap Cirrus Logic 5446 video card, with 2MB of VRAM, without music or even enemies.) The only way to get my game to run at a decent speed right now is to drop frames (it's choppy, but at least it's playable). I could try to use 8-bit mode instead, but I designed my graphics to work in 16-bit, and I don't really want to deal with the inevitable pallete problems - together, some of the background and foreground graphics use as much as 27,000 colors. I will if I absolutely have to, though, because I care more about the gameplay than what the graphics look like... but part of the reason I used 16-bit in the first place was to make my game engine more flexible (and forward compatible with future games I might write) - it's designed to be added onto in just about every respect including levels, graphics, and music. It's easier to do this without having to deal with palletes. I could also just live with the choppy framerate, but imagine what it would be like on a slower system. I could also drop the parallax backgrounds, but I want to do that even less than converting my game to 8-bit (they add a lot of feel to the game). Any ideas to make this run faster (40-60 fps)? Or is this really just too much for the computer (and video card) to handle? Dirty rectangles probably wouldn't work too well, since everything on the screen scrolls. Hardware acceleration might, but the VBE/AF drivers don't work right with my card (I can get into the mode, but blitting doesn't work right), and not everybody has hardware accelerated drivers anyway.

Why do you think there ARE no decent multilayer parralax scrolling games available on PC? Things like this only work well with specialized hardware (like those found in every game-console), they just require too much (simple calculations: (5 layers + one blit=) 5*640*480*2 bytes of data, that is a LOT to move around.)<p>
The 20 fps you get are actually not that bad at all for the amounts of layers you are displaying, I would offer to take a look at your routines but I actually don't think it will get a raving lot faster than that.<p>

: Why do you think there ARE no decent multilayer parralax scrolling games available on PC? Things like this only work well with specialized hardware (like those found in every game-console), they just require too much (simple calculations: (5 layers + one blit=) 5*640*480*2 bytes of data, that is a LOT to move around.)<p>
: The 20 fps you get are actually not that bad at all for the amounts of layers you are displaying, I would offer to take a look at your routines but I actually don't think it will get a raving lot faster than that.<p>
I do the following steps to redraw the screen:<p>
1. Draw parallax layer #1 on buffer<br>
2. Draw parallax layer #2 on buffer<br>
3. Draw "normal" layers #1 and #2 on buffer<br>
4. If there is currently any enemies on the screen, draw them on the buffer (this step isn't implemented yet. This is the fifth layer.)<br>
5. Draw player<br>
6. Blit double buffer to screen.<p>
Without enemies, this routine calls draw_sprite() 14 * 21 * 4 times, plus 1 more for the player (and any more for enemies). I found out using RLE sprites increased the framerate to 25 fps, so I now use them instead of regular sprites. (I use 32x32 pixel tiles, and the bottom 80 rows of pixels are taken up by the status display, so I don't draw anything there. I draw one extra row and column of tiles, otherwise when it scrolls the tiles on the edges will be missing.) My game is more of a console-style game than a PC-style game, and I thought that if you could do something similar to this on a SNES with a measly 3.57 MHz processor, you could do it on a PC with a 233 Mhz processor. Of course, the SNES only used 256 colors, but I thought the processor speed of a modern PC was enough to offset that... But then, the SNES certainly has specialized hardware to do graphics, and probably doesn't rely too much on the processor for that - on the PC you don't have this kind of specialized hardware.

That's pretty cool, I was planning on making a tile-based graphics engine to make games like FF3/Chrono Trigger too.<p>
What do you mean by parallax blitting? Are you just using draw_trans_sprite() or another method like the blitting counterpart?<p>
For your 20fps, that is not bad.100fps is the maximum of the human eye to see but 30fps is good enough that the eye can't tell much difference.<p>
On a per-tile basis, maybe use some non-translucent blitting when you don't need to. If you use it for every tile it can slow it down extremely.<p>
Last, if you are into assembly, those worthless MMX instructions have some registers for doing translucency quickly.<p>
If the problem is not the functions maybe see if your video card is not very good at blitting highcolor modes.<p>
-Xotor-<p>
: I do the following steps to redraw the screen:<p>
: 1. Draw parallax layer #1 on buffer<br>
: 2. Draw parallax layer #2 on buffer<br>
: 3. Draw "normal" layers #1 and #2 on buffer<br>
: 4. If there is currently any enemies on the screen, draw them on the buffer (this step isn't implemented yet. This is the fifth layer.)<br>
: 5. Draw player<br>
: 6. Blit double buffer to screen.<p>
: Without enemies, this routine calls draw_sprite() 14 * 21 * 4 times, plus 1 more for the player (and any more for enemies). I found out using RLE sprites increased the framerate to 25 fps, so I now use them instead of regular sprites. (I use 32x32 pixel tiles, and the bottom 80 rows of pixels are taken up by the status display, so I don't draw anything there. I draw one extra row and column of tiles, otherwise when it scrolls the tiles on the edges will be missing.) My game is more of a console-style game than a PC-style game, and I thought that if you could do something similar to this on a SNES with a measly 3.57 MHz processor, you could do it on a PC with a 233 Mhz processor. Of course, the SNES only used 256 colors, but I thought the processor speed of a modern PC was enough to offset that... But then, the SNES certainly has specialized hardware to do graphics, and probably doesn't rely too much on the processor for that - on the PC you don't have this kind of specialized hardware. <p>

About the SNES processor:<p>
Remember that the SNES scrolling hardware is just that: Hardware. Hardware, no matter what speed is almost ALWAYS faster than software. The SNES has a dedicated scrolling hardware engine on it which makes it extremely fast. Also the SNES uses 320x200 graphics which is less than one fourth of the screen size you're dealing with (640x480), in fact the SNES really only uses 200x200.<p>
It takes my AMD K6-III to run Chrono Trigger nice and fast with the ZSNES emulator and I didn't get good framerate with the emulator on my P150.<p>
ZSNES is also nearly completely Assembly code and it run also very nice because of MMX optimizations.<p>
www.zsnes.com/<p>
-Xotor-

My game isn't an RPG, is a platformer, but the same tile scrolling concepts apply (it's actually not that hard to just scroll a tilemap, but getting it to run fast enough in a hi-res truecolor video mode is.) Parallax blitting? What I'm doing is parallax scrolling - i.e. backgrounds farther back scroll slower than the ones "closer" to the player, it gives the illusion of depth. You can see this effect in many games such as Super Mario World, Donkey Kong Country, etc. Not many PC games use it but there are some, in particular, Jazz Jackrabbit 2 uses parallax scrolling in hicolor modes (I think.) AFAIK it's the only PC game that does, so it is possible. Maybe I'll download the demo and see what it's like. I'm not using translucent sprites yet (but I planned on using them for things like water.) Right now I just use draw_rle_sprite() to redraw the screen (it upped the framerate to 25 fps.) I'm not into assembly yet, as I'm not that advanced yet (I just taught myself C this year. Most of what I know is learned on my own. I'll probably learn it someday, though, I'm just not ready for it yet.) I suspect my video card is the problem: if the hardware accelrated modes worked properly, perhaps I could get it to run reasonably fast. At 20 fps the controls in my game are way too sluggish, so that's why I want to get it to run faster. I could tweak the controls, too, but tweaking them to work well at 20 fps would likely require sacrificing a lot of precision (as I'd have to make my character run and jump more pixels/sec.) Of course, right now, I have a choppy framerate (although it's not THAT bad, it's actually kind of like playing something on ZSNES with frameskip. It's choppy, but you can still play the game just fine. My game skips about every other frame, so it really only runs at 25 fps, I just let the game logic update more often.)<p>
: That's pretty cool, I was planning on making a tile-based graphics engine to make games like FF3/Chrono Trigger too.<p>
: What do you mean by parallax blitting? Are you just using draw_trans_sprite() or another method like the blitting counterpart?<p>
: For your 20fps, that is not bad.100fps is the maximum of the human eye to see but 30fps is good enough that the eye can't tell much difference.<p>
: On a per-tile basis, maybe use some non-translucent blitting when you don't need to. If you use it for every tile it can slow it down extremely.<p>
: Last, if you are into assembly, those worthless MMX instructions have some registers for doing translucency quickly.<p>
: If the problem is not the functions maybe see if your video card is not very good at blitting highcolor modes.<p>
: -Xotor-<p>
: : I do the following steps to redraw the screen:<p>
: : 1. Draw parallax layer #1 on buffer<br>
: : 2. Draw parallax layer #2 on buffer<br>
: : 3. Draw "normal" layers #1 and #2 on buffer<br>
: : 4. If there is currently any enemies on the screen, draw them on the buffer (this step isn't implemented yet. This is the fifth layer.)<br>
: : 5. Draw player<br>
: : 6. Blit double buffer to screen.<p>
: : Without enemies, this routine calls draw_sprite() 14 * 21 * 4 times, plus 1 more for the player (and any more for enemies). I found out using RLE sprites increased the framerate to 25 fps, so I now use them instead of regular sprites. (I use 32x32 pixel tiles, and the bottom 80 rows of pixels are taken up by the status display, so I don't draw anything there. I draw one extra row and column of tiles, otherwise when it scrolls the tiles on the edges will be missing.) My game is more of a console-style game than a PC-style game, and I thought that if you could do something similar to this on a SNES with a measly 3.57 MHz processor, you could do it on a PC with a 233 Mhz processor. Of course, the SNES only used 256 colors, but I thought the processor speed of a modern PC was enough to offset that... But then, the SNES certainly has specialized hardware to do graphics, and probably doesn't rely too much on the processor for that - on the PC you don't have this kind of specialized hardware. <p>
<br>

Ah, I should've guessed the meaning. If you want you could send me a copy and I could see if it runs nicely on my system and/or give you some tips on how to tweak it.<p>
As for Zsnes, I use dynamic frame skipping to a max of one frame skip. This is using the Super Eagle Engine which makes the graphics look a lot better than just pixels.<p>
Also are you using the Allegro timer? Last, are you using Vsync()? Vsync slows the program down dramatically.<p>
-Xotor-<p>
: My game isn't an RPG, is a platformer, but the same tile scrolling concepts apply (it's actually not that hard to just scroll a tilemap, but getting it to run fast enough in a hi-res truecolor video mode is.) Parallax blitting? What I'm doing is parallax scrolling - i.e. backgrounds farther back scroll slower than the ones "closer" to the player, it gives the illusion of depth. You can see this effect in many games such as Super Mario World, Donkey Kong Country, etc. Not many PC games use it but there are some, in particular, Jazz Jackrabbit 2 uses parallax scrolling in hicolor modes (I think.) AFAIK it's the only PC game that does, so it is possible. Maybe I'll download the demo and see what it's like. I'm not using translucent sprites yet (but I planned on using them for things like water.) Right now I just use draw_rle_sprite() to redraw the screen (it upped the framerate to 25 fps.) I'm not into assembly yet, as I'm not that advanced yet (I just taught myself C this year. Most of what I know is learned on my own. I'll probably learn it someday, though, I'm just not ready for it yet.) I suspect my video card is the problem: if the hardware accelrated modes worked properly, perhaps I could get it to run reasonably fast. At 20 fps the controls in my game are way too sluggish, so that's why I want to get it to run faster. I could tweak the controls, too, but tweaking them to work well at 20 fps would likely require sacrificing a lot of precision (as I'd have to make my character run and jump more pixels/sec.) Of course, right now, I have a choppy framerate (although it's not THAT bad, it's actually kind of like playing something on ZSNES with frameskip. It's choppy, but you can still play the game just fine. My game skips about every other frame, so it really only runs at 25 fps, I just let the game logic update more often.)<p>
: : That's pretty cool, I was planning on making a tile-based graphics engine to make games like FF3/Chrono Trigger too.<p>
: : What do you mean by parallax blitting? Are you just using draw_trans_sprite() or another method like the blitting counterpart?<p>
: : For your 20fps, that is not bad.100fps is the maximum of the human eye to see but 30fps is good enough that the eye can't tell much difference.<p>
: : On a per-tile basis, maybe use some non-translucent blitting when you don't need to. If you use it for every tile it can slow it down extremely.<p>
: : Last, if you are into assembly, those worthless MMX instructions have some registers for doing translucency quickly.<p>
: : If the problem is not the functions maybe see if your video card is not very good at blitting highcolor modes.<p>
: : -Xotor-<p>
: : : I do the following steps to redraw the screen:<p>
: : : 1. Draw parallax layer #1 on buffer<br>
: : : 2. Draw parallax layer #2 on buffer<br>
: : : 3. Draw "normal" layers #1 and #2 on buffer<br>
: : : 4. If there is currently any enemies on the screen, draw them on the buffer (this step isn't implemented yet. This is the fifth layer.)<br>
: : : 5. Draw player<br>
: : : 6. Blit double buffer to screen.<p>
: : : Without enemies, this routine calls draw_sprite() 14 * 21 * 4 times, plus 1 more for the player (and any more for enemies). I found out using RLE sprites increased the framerate to 25 fps, so I now use them instead of regular sprites. (I use 32x32 pixel tiles, and the bottom 80 rows of pixels are taken up by the status display, so I don't draw anything there. I draw one extra row and column of tiles, otherwise when it scrolls the tiles on the edges will be missing.) My game is more of a console-style game than a PC-style game, and I thought that if you could do something similar to this on a SNES with a measly 3.57 MHz processor, you could do it on a PC with a 233 Mhz processor. Of course, the SNES only used 256 colors, but I thought the processor speed of a modern PC was enough to offset that... But then, the SNES certainly has specialized hardware to do graphics, and probably doesn't rely too much on the processor for that - on the PC you don't have this kind of specialized hardware. <p>
<br>

No, I'm not using vsync() - I found out that it really didn't do much besides slow the game down. I'm using the Allegro timer, however, I use them to calculate the framerate and also to put a time limit in the levels of my game (and I'll likely use them for some other things as well).<p>
<br>
: Ah, I should've guessed the meaning. If you want you could send me a copy and I could see if it runs nicely on my system and/or give you some tips on how to tweak it.<p>
: As for Zsnes, I use dynamic frame skipping to a max of one frame skip. This is using the Super Eagle Engine which makes the graphics look a lot better than just pixels.<p>
: Also are you using the Allegro timer? Last, are you using Vsync()? Vsync slows the program down dramatically.<p>
: -Xotor-<p>
: : My game isn't an RPG, is a platformer, but the same tile scrolling concepts apply (it's actually not that hard to just scroll a tilemap, but getting it to run fast enough in a hi-res truecolor video mode is.) Parallax blitting? What I'm doing is parallax scrolling - i.e. backgrounds farther back scroll slower than the ones "closer" to the player, it gives the illusion of depth. You can see this effect in many games such as Super Mario World, Donkey Kong Country, etc. Not many PC games use it but there are some, in particular, Jazz Jackrabbit 2 uses parallax scrolling in hicolor modes (I think.) AFAIK it's the only PC game that does, so it is possible. Maybe I'll download the demo and see what it's like. I'm not using translucent sprites yet (but I planned on using them for things like water.) Right now I just use draw_rle_sprite() to redraw the screen (it upped the framerate to 25 fps.) I'm not into assembly yet, as I'm not that advanced yet (I just taught myself C this year. Most of what I know is learned on my own. I'll probably learn it someday, though, I'm just not ready for it yet.) I suspect my video card is the problem: if the hardware accelrated modes worked properly, perhaps I could get it to run reasonably fast. At 20 fps the controls in my game are way too sluggish, so that's why I want to get it to run faster. I could tweak the controls, too, but tweaking them to work well at 20 fps would likely require sacrificing a lot of precision (as I'd have to make my character run and jump more pixels/sec.) Of course, right now, I have a choppy framerate (although it's not THAT bad, it's actually kind of like playing something on ZSNES with frameskip. It's choppy, but you can still play the game just fine. My game skips about every other frame, so it really only runs at 25 fps, I just let the game logic update more often.)<p>
: : : That's pretty cool, I was planning on making a tile-based graphics engine to make games like FF3/Chrono Trigger too.<p>
: : : What do you mean by parallax blitting? Are you just using draw_trans_sprite() or another method like the blitting counterpart?<p>
: : : For your 20fps, that is not bad.100fps is the maximum of the human eye to see but 30fps is good enough that the eye can't tell much difference.<p>
: : : On a per-tile basis, maybe use some non-translucent blitting when you don't need to. If you use it for every tile it can slow it down extremely.<p>
: : : Last, if you are into assembly, those worthless MMX instructions have some registers for doing translucency quickly.<p>
: : : If the problem is not the functions maybe see if your video card is not very good at blitting highcolor modes.<p>
: : : -Xotor-<p>
: : : : I do the following steps to redraw the screen:<p>
: : : : 1. Draw parallax layer #1 on buffer<br>
: : : : 2. Draw parallax layer #2 on buffer<br>
: : : : 3. Draw "normal" layers #1 and #2 on buffer<br>
: : : : 4. If there is currently any enemies on the screen, draw them on the buffer (this step isn't implemented yet. This is the fifth layer.)<br>
: : : : 5. Draw player<br>
: : : : 6. Blit double buffer to screen.<p>
: : : : Without enemies, this routine calls draw_sprite() 14 * 21 * 4 times, plus 1 more for the player (and any more for enemies). I found out using RLE sprites increased the framerate to 25 fps, so I now use them instead of regular sprites. (I use 32x32 pixel tiles, and the bottom 80 rows of pixels are taken up by the status display, so I don't draw anything there. I draw one extra row and column of tiles, otherwise when it scrolls the tiles on the edges will be missing.) My game is more of a console-style game than a PC-style game, and I thought that if you could do something similar to this on a SNES with a measly 3.57 MHz processor, you could do it on a PC with a 233 Mhz processor. Of course, the SNES only used 256 colors, but I thought the processor speed of a modern PC was enough to offset that... But then, the SNES certainly has specialized hardware to do graphics, and probably doesn't rely too much on the processor for that - on the PC you don't have this kind of specialized hardware. <p>
<br>

: What's the fastest way to do parallax scrolling in a 16-bit 640x480 graphics mode, using Allegro (DOS)? The game that I'm writing (a platform game) uses two parallax scrolling layers plus 3 "normal" layers, and it's too slow to redraw the whole screen using a double buffer every frame (I only get 20 fps on my P2-233 MMX with a cheap Cirrus Logic 5446 video card, with 2MB of VRAM, without music or even enemies.) The only way to get my game to run at a decent speed right now is to drop frames (it's choppy, but at least it's playable). I could try to use 8-bit mode instead, but I designed my graphics to work in 16-bit, and I don't really want to deal with the inevitable pallete problems - together, some of the background and foreground graphics use as much as 27,000 colors. I will if I absolutely have to, though, because I care more about the gameplay than what the graphics look like... but part of the reason I used 16-bit in the first place was to make my game engine more flexible (and forward compatible with future games I might write) - it's designed to be added onto in just about every respect including levels, graphics, and music. It's easier to do this without having to deal with palletes. I could also just live with the choppy framerate, but imagine what it would be like on a slower system. I could also drop the parallax backgrounds, but I want to do that even less than converting my game to 8-bit (they add a lot of feel to the game). Any ideas to make this run faster (40-60 fps)? Or is this really just too much for the computer (and video card) to handle? Dirty rectangles probably wouldn't work too well, since everything on the screen scrolls. Hardware acceleration might, but the VBE/AF drivers don't work right with my card (I can get into the mode, but blitting doesn't work right), and not everybody has hardware accelerated drivers anyway.<p>
That type of game is very difficult to pull off without hardware acceleration. I'd suggest jumping to Windows (bleh), which does support hardware accel, because I can't imagine more than 2% of DOS users have VBE/AF drivers. Faster CPUs don't do much since they still have to wait for memory, and the ever-so-slow video memory. An average video card software throughput is probably around 40MB/sec, but I've seen between 8MB/sec and 96MB/sec. Just calc how much time it takes to copy the double buffer alone (614KB). On average (40MB/sec), just doing that will already be limited to about 70FPS. High color action games are not feasable without hardware accel(or some really good tricks). I'd suggest trying to draw directly to a back video surface, and using page flipping. In your scenario it may not be better because you're re-drawing alot of the frame, but in general its faster than double buffering.<p>
One thing to try if you have a PPro or PII, is to get the FastVid utility from www.fastgraphics.com. It can GREATLY speed up software access to video buffers by optimizing the cache writes, and also some write posting stuff. These systems can actually run SLOWER than Pentium systems by default. Speeds up older PPro systems mainly. (My game runs great on my P200, but was horrible on my friend's PII450. Finally, after quite a long time, I found that was the problem. My video card wrote about 45MB/sec, and his only did 13MB/sec. With the utility, his now does around 45MB/sec also. It is a kick-butt little program)<p>
Also, Allegro is not going to cut it for this type of performance. The Win version may be OK, since it uses DirectX, but the software DOS version just isn't fast enough. Ideally, you should allow the user the choice of 8 or 16 bit color too. But 8 bit color is not that bad. If you want software drawing, you're going to have to accept it, or put LOTS of time trying to create a drawing scheme that will work front-to-back so as not to keep redrawing over background layers with foreground layers.<p>
If you're a glutton for punishment, and your foreground layers aren't terribly large, you may want to look into hardware scrolling. It isn't really supported by Allegro (it is, but but its somewhat different and limited), so you'll have to write your own VESA graphics driver to do this. NOT an easy thing to do. <p>
Bottom line is, your trying to make a very professional game, but you've said that you're basically a beginner. To get this to run well in your described system, you must use some advanced techniques, some of which will require assembly. It will be FAR from easy.<p>
Rock