»

[kickstart]

@novacoder

Nice work... maybe on a 50mhz 060 runs smooth too.

[Karlos]

Originally Posted by NovaCoder

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]

Originally Posted by Cosmos

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.

[B00tDisk]

Originally Posted by Karlos

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!

Quake in 4096 colors? Sign me up!

[Karlos]

Originally Posted by B00tDisk

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.

[NovaCoder]

Originally Posted by kickstart

@novacoder

Nice work... maybe on a 50mhz 060 runs smooth too.

No, not quite there yet, I'll keep hacking away in my spare time to make it faster. I have other more interesting projects waiting to be started so I can't spend all my time on it

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

A more interesting update would be Graffiti, when Jens eventually updates the Indivision AGA Mrk2 with Graffiti support (maybe even 16bit chunky support) then we can have some fun.

[Karlos]

Originally Posted by NovaCoder

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.

[B00tDisk]

Originally Posted by Karlos

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

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

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.

[Karlos]

Originally Posted by B00tDisk

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.

[NovaCoder]

I thought I'd do some videos of recordings of myself playing the game this time which gives a better idea of how it actually runs on my machine with the latest release.

NovaCoder vs Chthon

Amiga AGA Quake - Citadel

[runequester]

Wow, thats quite playable. Nice to see

[NovaCoder]

Yep still could do with a little fps but it's getting harder to get any more speed out of it now

[delshay]

It would be nice to see a 16bit PPC version.

[Cosmos]

Have you included the asm parts of the Frank Wille Quake version ?

[NovaCoder]

Originally Posted by Cosmos

Have you included the asm parts of the Frank Wille Quake version ?

No not yet but I might do it in the future if I can get it working