AmiQuake - new 68k Quake Port

[Karlos]

I have to say, that's an impressive speed for 68K/AGA!

One thing I'd love to see is a quake port that uses Warp3D as the rasterizer. Not a GLQuake port on MiniGL (GLQuake was, by John Carmack's own admission a suboptimal hack), but the vanilla Quake with it's original 3D transformation pipeline with just the rendering stage delegated to warp3d. This should be able to bypass a number of inefficiencies both in the GLQuake code and in MiniGL.

[Karlos]

Cool thanks, I've just uploaded v1.07 to AmiNet and it's even quicker on my machine

I'll do a new video when I get the time....

You say it will work on RTG too, right?

[Karlos]

@NovaCoder

Again here : seven emulated 060 instructions on this game !

Slow down because the 68060.library is not fast you know...

Surely that depends on where they are. If they are in some inner loop, yes, if they are in some initialisation code or something called infrequently, does it matter so much?

@novacoder

Being 68060 only, is there any reason it wouldn't actually run on 68040 too? Are you doing any supervisor mode stuff or relying on any other 060-only features?

[Karlos]

@NovaCoder

@Karlos
68060 compiled code I've seen should run without problems on a 68040 although at a slower speed. Using the utility.library for integer 32x32=64 is nearly as fast for the 68040 but the missing FINT/FINTRZ in the 68040 for floating point is a performance killer. What were the Motorola Engineers thinking? Programs using floating point should provide separate 68040 and 68060 compiled versions because of this.

I'm curious to test it under petunia It only advertises 68020/68882, but implements most of the additional instructions, AFAIK.

[Karlos]

I would imagine it will run at very acceptable speed.

If my experiments with DoomAttack on my BlizzardPPC are any measure, perhaps. That ran 640x400 faster than my 040 does 320x200.

[youtube]AQ1t5q3xmYk[/youtube]

[Karlos]

As promised, here's a quick video of the latest build -> AmiQuake

Since it's so smooth already, any chance you might add some CPU chewing RGB -> HAM C2P as an experiment?

I'd love to see that!

[Karlos]

Trapped instructions are slow all the time, everywhere and anywhere !

I know they are slow, but depending on where they are called, it really may not matter. Even a thousand trap-and-emulate calls aren't a problem if they only happen when loading a level, for example. You simply aren't going to notice (or care about, even if you do) a few hundred microseconds wasted.

If, on the other hand, you are doing a trap-and-emulate every time you do a perspective correction inside your texture mapping loop, it's going to suck abominably.

Ideally, there'd be no emulated instructions but in practise, context is everything.

[Karlos]

Quake in 4096 colors?  Sign me up!

I was thinking more of the sort of 18-bit C2P routines that you can find on aminet, but even HAM6 would be neat.

[Karlos]

I did have a look a doing HAM8 C2P for my ScummVM port but could never get it to render properly

Seriously, that would be a really nice touch.

[Karlos]

Oh I spoke in jest; Quake has an 8-bit pallet and would hardly benefit from 12-bit

Actually, it would as clickboom's original port demonstrates with it's slow but pretty 16-bit option.

The reason being that although the textures are 8 bit, they are shaded with light maps to produce the end result which results in many more shades than can be displayed.  These are quantized back to the game palette, resulting in a loss in fidelity.

Tell me more of these 18-bit routines, though.  I'm a coding newborn and didn't touch anything on the Amiga post AmigaBasic though so be gentle.

A number of routines are available courtesy of various demoscene coders that can convert an RGB chunky framebuffer in formats from 12-bit up to full 24-bit into suitable HAM planar displays.