So slow...

[stiv]

When i had a integrated intel video card 32Mb,

It can cost as little as USD $5 to put an integrated video chipset on a motherboard. While they are fine for email and web surfing, they are usually quite inadequate for modern video games and 3D graphics applications, especially ones using OpenGL.

The less the vido card/chipset does in hardware, the more the cpu has to work. Here is a basic description of what is going on (from docs for FlightGear, a flight simulator that uses OpenGL for drawing http://www.flightgear.org/hardwarereq.html ). Note the bit at the end about display depth and software rendering.

Here is a bit of general background information on OpenGL and 3D hardware acceleration contributed by Steve Baker ([email protected])
Updated by Curt Olson (9/25/2000)

When you are drawing graphics in 3D, there are generally a hierarchy of things to do:
Stuff you do per-frame (like reading the mouse, doing flight dynamics)
Stuff you do per-object (like coarse culling, level-of-detail)
Stuff you do per-polygon or per-vertex (like rotate/translate/clip/illuminate)
Stuff you do per-pixel (shading, texturing, Z-buffering, alpha-blend)
On a $1M full-scale flight simulator visual system, you do step (1) in the main CPU, and the hardware takes care of (2), (3) and (4)

On a $100k SGI workstation, you do (1) and (2) and the hardware takes care of (3) and (4)

On a $100 PC 3D card, you (or your OpenGL library software - which runs on the main CPU) do (1), (2) and (3) and the hardware takes care of (4).

On a machine without 3D hardware, the main CPU has to do everything.

The amount of work to do each of these operations goes up by one or two orders of magnitude at each step. One eye point, perhaps a hundred objects, tens of polygons per object, hundreds of pixels per polygon.

Hence, putting step (4) into hardware is vital - you could easily need to draw a million pixels for each time you read the mouse. Putting step (3) into hardware is also very nice - cards like the nVidia GeForce are now doing this.

So, if you put a cheap accelerated 3D card onto a slow-ish PC, you still get all the benefits of not doing the per-pixel math in software - so your frame rate will speed up. But since that per-pixel stuff now goes very fast, you are probably limited by the speed that your old clunker can do step (3) - the per-vertex math.
....
If your 3D card doesn't provide a speedup then make sure you have a proper OpenGL driver installed for that card - some cards only support Direct3D which FGFS is unable to interface to. Some 3D cards can't function if you set the display resolution too large or the pixel depth to something that card won't support. Some OpenGL drivers silently drop back to software-only rendering under those circumstances.

[cybersphinx]

how much would that be - just so we are all on the same math page.

As a rough figure:

I think all used textures are loaded on starting, not on demand, so memory needs are more or less constant during play. I don't know if cards with only 16 or 32 MB support texture compression, if they do, the final figure is lower.

Terrain tiles: 128x128 pixels, 32 bit. 128 * 128 * 4 (32 bit colour depth) * 1.5 (for mipmaps) ~= 100 kB. There are ~80 tiles per tileset, so that's ~8MB.
Buildings etc.: 256 * 256 * 4 * 1.5 ~= 400 kB. I guess of the ~30 texpages ~10 are used per terrain type, so another ~4MB.
Frame buffer: 1024 * 768 (is that a reasonable resolution for a 16/32 MB card?) * 4 ~= 3MB (twice for double buffering).
So until now we need at least 15 MB, plus the textures for text (don't know how much that needs), and interface (some more 256*256 textures, so x * 400kB). The Z-buffer also needs some space, screen resolution * depth (16 bit?). I guess 16 MB won't be enough, but with lower resolutions, 32 MB should be enough (but then, it's late, maybe I forgot something that needs more space...).

Edit:
* The tiles are loaded onto larger textures, so the memory needed is more than shown above.
* If you reduce texture resolution to 64 pixels (the resolution of the original tiles), you need 1/4 memory, but get more blurry ground.

[EvilGuru]

On my integrated ATI 9200 (which had 32MiB of VRAM) only 24MiB was available for applications. The rest was either reserved or used by the system. The system could play 2.0.x. 2.1.x was un-playable, however.

64MiB is an absolute minimum (and you will probably need to reduce the tile size to 64x64). For integrated chipsets (read: Intel) support for texture compression is a must. This results in a 4x reduction in texture size. While the memory savings are nice, the bandwidth savings are vital. The memory bandwidth of a 7-year-old GeForce 3 is 7.4GiB/s. A cheap desktop computer with PC6400 DDR2 SDRAM has 6.4GiB/s of memory bandwidth (assuming it is operating in single-channel mode, which is common).

So even if all of the systems memory bandwidth could be devoted to the graphics card (which is impossible, as the CPU needs to hit main memory as well) it would still be worse off than a GeForce 3. In reality the integrated chipset it likely to only get a fraction of that. Therefore, by reducing the texture space-requirements fourfold the amount of memory bandwidth required is also drastically reduced.

Regards, Freddie.

[Buginator]

The requirement is minimum 2MB SVGA card for basic game. So the newest version, with all fireworks, cant require even more than 16 MB of memory of gfx. 32 MB gfx Card is more than good for this game.

It went from PCX (256 colors) to 16 bit jpg, to 32 bit pngs.

Now, lets say you are playing 1600x1200x32bit.
That is about 7,680,000 bytes of VRAM needed for the screen. Since we use double buffering, you need to double that. That is around 14.6MB of VRAM. Now in come the textures, and depending on the size, and how many textures are loaded, your VRAM will be eaten up pretty quickly.

If all textures fit into your VRAM, then fine, if not, then it swaps back and forth between main RAM and this can get really, really slow, and sometimes, not even supported correctly!

Since none of the devs have very low end hardware, it is impossible for us to fix it without getting the same old crappy hardware that has the problem.

Most of the time it is a gfx driver issue, or terrible integrated (*cough* intel/S3 *cough*) chipset. There isn't much we can do to fix THEIR drivers, nor their crappy chipset.

Perhaps one day, when we have a real texture manager in place, we can spit out just how much we are actually using, but that is far into the future.