Quake III on MorphOS (details turned up = slow down)

[Karlos]

I'm running Quake III on an eMac under MorphOS, but when I turn all the details on, it slows down horribly.

Why would this be? I thought this game was old and could run without any issues on hardware that came out around the eMac era...
-----------------------
System requirements:

3D graphics accelerator with full OpenGL support, Pentium II 233 MHz or AMD 350 MHz K6-2 processor or Athlon processor, 64 MB RAM, 8 MB video card, 500 MB of free hard drive space, 100% DirectX 3.0 or higher compatible sound card, CD-ROM drive (600 kB/s sustained transfer rate)

I'm pretty sure I more than have that covered right?

Whatever problems you are having, they're all because of your avatar. That thing is weird, in a scary way, man... :roflmao:

On a more serious note, the above requirements are the absolute minimum to get it working. A 64MB video card with proper multi-texture support should be considered a minimum if you want to use the highest texture quality.

[Karlos]

gfx ram allways help but on the requirements talks about 8mb of gfx memory.

That's the absolute minimum. Under typical PC implementations, the chances are that an 8MB card will be using graphics-card mediated AGP transfers to page stuff from a shared memory region in system RAM with the graphics card, without really strangling the CPU. I don't expect that to be the case under any existing amiga RTG specification.

In short, gfx ram probably makes much more difference to the performance under AmigaOS/MOS than it does under Windows.

[Karlos]

I was thinking in classic Amiga terms, thinking anything above 2Mb or GFX RAM would carry me through the day. I never expected this. :/

Depends on what you do with it. Whenever I'd run a 3D game on my 8MB gfx card, I'd always drop the workbench to 320x240x8-bit first to free up as much of the RAM as possible.

You have to be realistic though. A 1280x1024x32-bit display (a modest resolution for a desktop today) requires 5MB just for the frame buffer. There'll be various allocations going on all the time when windows are opened.

Suppose you wanted to play Quake 3, fullscreen, at 800x600 in 32-bit colour. You're bound to have at least double, if not triple buffering. Then there's the Z-buffer, which may be 16-bits (as it is on the Permedia, actually 15-bit with one bit of stencil) or 24-bit with 8-bits of stencil on many radeon cards. So, with triple buffering and a Z buffer, you might already have 4 800x600x32-bit buffers. There's 1.8MB gone immediately. If your 1280x1024 desktop display is still paged in, you've now got 6.8MB in use before you've loaded a single texture map.


The reason you never really thought of this with your 2MB chip-ram system is because you couldn't actually have resolutions that high. A single 256 HighGfx (1024x768) display, about the best you'll get from AGA, will eat almost half of that in one go.

[Karlos]

Or you can play quacke3 on your old pc at full speed and use morphos for other funny things (i supose)

[Karlos]

heheh...Thats on ultra quality gfx mode, you need at least 128mb

Playing various 1st person games on the PC has kind of killed the genre on any other platform for me. Just counting the days until Fallout New Vegas

[Karlos]

What resolution do you use exactly?

I can play Quake3 at 1024x768@32bits at high quality preset without any problem on my Mac mini with 32MB vram (demo four runs between 40 and 120fps depending on places).

In background i also had 2 1280x1024@32 screens (one for ambient and one for OWB). But it doesn't matter, since the memory management is per-screen.

[EDIT] But indeed, with texture details at max, it consumes quite more video ram, and it's too much.

Call that 10MB for your 2 background screens, leaving you with 22MB, assuming they weren't paged out. You then have 3MB per frame buffer for the game, so if you are using double buffering, that's 6MB. You probably have a 32-bit combined stencil/z-buffer (8-bit/24-bit), so there's another 3MB, although you might have a 16-bit Z-buffer only. We are down to 13MB of video memory free for textures, less if we assume that there are other allocations going on.

As you can see, it all adds up. The moment you go for the highest texture detail, you are probably getting to the point where stuff starts having to be switched in and out of VRAM. Not sure how MOS implementation of CGX does this, but I suspect it's not as quick as it could be.