For a video card, accessing its Video RAM is vastly faster than accessing system memory. System memory access, even over AGP, are slow for a video card. And, ignoring location and busses, modern video card RAM is vastly superior to main memory.

Video RAM is slow for the CPU to access. CPU read/write requests to V-RAM typically go through a 33MHz interface, and are uncached. CPU read/write requests to main memory go through a (on modern machines) 100MHz, 133MHz, or better interface that is cached. Ignoring the cache improvement, that's a 3-4x speed up at least.

The basic idea if you're going to be working your video card is to keep everything in video memory. That means 100% of your BITMAPs are video memory bitmaps. Also, you shouldn't touch video BITMAPs. That means no blitting to them, no read/writing, nothing.

There are some limitations to this, however. Allegro's blending (including FBlend) will be very slow. These are software blits, so they work best in main memory.

Also, video memory tends to be small. 32MB on most modern game-quality video cards (though games are starting to demand more). Therefore, you should consider using system BITMAPs. These (presumably) use AGP memory, which is main memory that the video card can access directly through an enhanced DMA bus. They still blit pretty fast, too, so they offer another possibility.

If you want to get hardware blending, you're going to have to use OpenGL.

If your video card only has 1MB of video RAM... it doesn't have any power worth exploiting. There's no AGP, no accelerated OpenGL, nothing. You'll fill up the video RAM with your framebuffer, leaving precious little left for your BITMAPs.

I think a healthy upgrade ($600-800) is in order.

Thanx for the replies. I have 2 computers, one is my main machine with 640 megs of system ram and a geforce2 MX 400 with 64 megs of DDR vram (i think its DDR), so memory here aint a problem, but I also have a laptop with 2 megs of vram, and no special videocard and 233mHz processor, so my games run a lot slower. My games do not use any 3D grafx or anything special, so, they should not slow down (considering that everything else but my drawing routines are perfect), hence my question. Any adivce, or any more information would be great.
THANX

When I started using VRAM on my game, the frame rate went up from around 30fps to about 230fps. But it doesn't work on my older pc.

The main thing that was slowing my game down was the tilemap which was being drawn every frame. By storing the double buffer and tiles in VRAM I could do VRAM blits which gave me this speed increase.

On the whole, I think its only worth it if the game is only going to run on newer pc's. Since its only the newer pc's which are going to have a graphics card with enough VRAM and have the hardware acceleration.

I agree mostly with Mr. Fjellstrom, except that if you want to page flip (which you almost certainly do . . .), then you can't use 640x480x32bit mode with just 2mb of RAM, since 640*480*4*2 = 2,457,600. Maybe switch down to 16bit colour?

Anyway, I have a machine of a similar age to the Mach64, but instead fitted with a 2mb S3 Virge. This also is a very good 2d card and using it provides a much better frame rate than the CPU can alone. One game where I can definitely notice the difference is DX-Ball 2.

double buffering would be faster since page flipping/triple buffering wait for a screen refresh.. limiting yoru FPS to 75 - 80 fps.

Cool, double buffering it is! I will try using my same style, but using video bitmaps instead. When I test this out, I'll let you know how it goes. I'm pretty sure I'm not the only one who wants to know about this. Anybody reading this should feel free to give any advice or help in the mean time, thanx!

double buffering with vram would be slower on slower systems but faster on faster systems, since you have an extra blit that is totally unneeded. Only on faster machines would there be extra fps gaining from not having to wait for a vsync make any difference. And even then does > 999 fps vs caped at 60 fps make any difference at all to gameplay in 2d games? as far as memory goes you need the exact same amount of ram for either method.

if are on a newer machine and you have some extra ram you could optional switch from page flipping to triple buffering with very little code changes and then you would have all the speed of page flips + no waiting for a vsync.

create_video_bitmap() returns NULL when there's no space in vram for the bitmap. your program should put the bitmap in system ram if this happens.

Except, as already discussed, 32bpp is not really an option on a 2mb card. So we're talking 16bpp. Then, of course, most people don't store all 8 directions, but they use h_flip and v_flip. Which divides the number of directions you need to store by 4. Giving 32x32x16bppx32 = 65536 - a paltry 7.5% of memory, and allowing room for 13 such creatures and 16 other 32x32x16bpp tiles for things like mouse cursors and so on. Or say, 10 animated beings and a tileset for the map and cursor and so on of 104 elements.

But it wouldn't be visibly smoother, since you wouldn't be able to see more frames. In fact it would, as has been pointed out, be less smooth for some users who have machines which could have kept up with page flipping, but can't quite keep up with double buffering.

for example my video program.. it allows mode switching for the best mode in a game.. so it's up to the user to select which mode is best for the game.. and I'd have to disagree on the pageflipping/triple buffering being less smooth.. it runs the smoothest on my machine.. with double buffering I get tearing.. even if I set vsync.

Does hardware allow 16-bit blits to a 32-bit framebuffer? I figured the hardware blitter would require the use of the same bitdepth for blitting.

First, v_flip isn't going to give you a reasonable result at all unless your sprites are designed to be viewed from directly top-down (top-down shooters). Most games that allow the user to move up/down look at sprites at an angle (Zelda, virtually all RPGs, etc). v_flip can't help them.

Secondly, h_flip causes an annoying problem. It flips handedness. Sure, if it has no handedness, then you can get away with it, but one of the things that annoyed me about Zelda et. al. is that you always switch handedness when you face a certain way. You can choose to ignore this, but I prefer to bump up the memory requirements. Of course, my personal minimum memory requirements are 32MB of video or better, but that's just me.

Third, is h_flip supported in hardware?

Well, I tried using video bitmaps with my standard double buffering methods, and things did get smoother. I didnt put any tiles or animation in VRAM, just my buffers. I will try those other options soon, but I didnt have time to try them yet. The reason why I wanted to use some hardware accel. is because my games ran kinda slow (only Super Grand Prix auctually). I didnt know why becuase it is not complex enuff to run slow! So, I did some optimizations (includeing hardware accel) and now its a little better. I got more work to do in a little amount of time...but thanx everybody for the VRAM info.