AmiQuake 2 - new 68k Quake 2 Port

[NovaCoder]

Yeah don't give up on PrBOOM, my BOOM port is now at 'end-of-life' and it would be nice to have a more advanced port on my 1200 one of these days

What happened to your Apollo 1260 btw, ever get it to run BOOM properly?

[Hattig]

With my port of Quake I've discovered that RTG is not really much quicker than AGA, it seems that the C2P/AGA is only slowing it down by about 3% at 320x200 vs RTG direct fame buffer writes.

Interesting - would you say that was a limitation of the A1200 RTG cards that are available rather than AGA being surprisingly capable?

It will be interesting to see this on the FPGA Arcade, as that's got a lot more chip memory bandwidth looking at the results on the other thread.

[Crumb]

With my port of Quake I've discovered that RTG is not really much quicker than AGA, it seems that the C2P/AGA is only slowing it down by about 3% at 320x200 vs RTG direct fame buffer writes.

With 32bit miggies (AGA or Amiga3000) you can write to chipmem up to 7MB/s while ZorroII only allows half of that so in some cases AGA could be even faster. Peter McGavin already stated it in ADoom documentation and I found it interesting, he only recommended ZorroIII or faster bus.

In quake most of the bottleneck comes from the cpu.

IIRC Doom doesn't write to the screen sequentially but in columns so pixels can't be grouped easily when writting to chipram. Quake probably does the same so writting to gfx ram a row of 4 contiguous pixels requires may require redesigning the rasterizer, that could speed up writes notably. Perhaps rendering in 8x8, 16x16 or 32x32 groups speeds up rendering

I think that the engine could be optimized moving to fixed point some parts. AHI usually also slows down everything so perhaps Hyperion's quake2 sources with its paula driver comes handy.

You could install CGX AGA driver and compare the speed of your port with Hyperion's Quake2.

[Hattig]

IIRC Doom doesn't write to the screen sequentially but in columns so pixels can't be grouped easily when writting to chipram.

Indeed, Doom's graphics engine is an advanced raycaster, and they get their speed because walls are merely vertically scaling a pixel-wide slice of a texture - and you can do a 1 dimensional scale very easily in integer maths.

In this case it's simply easier to render to a chunky buffer in fast RAM, and then copy/translate it to display memory using an optimised C2P routine. But even that's difficult, as you are turning 32 chunky bytes into 8 planar 32-bit words. You inevitably need to store some working data in memory as you are processing things, so a fast large CPU cache comes in very handy.

Quake probably does the same so writting to gfx ram a row of 4 contiguous pixels requires may require redesigning the rasterizer, that could speed up writes notably. Perhaps rendering in 8x8, 16x16 or 32x32 groups speeds up rendering

Quake is not a raycaster, but instead it is a more conventional 3D renderer.

[Crumb]

Amiga version could be speed up if some code was moved to the C2P and interleaved with it in the parts where C2P is waiting for chipram access. An option to disable multitasking and using copper to switch between c2p and the rest of the code would be desirable too.

[XDelusion]

Yeah don't give up on PrBOOM, my BOOM port is now at 'end-of-life' and it would be nice to have a more advanced port on my 1200 one of these days

What happened to your Apollo 1260 btw, ever get it to run BOOM properly?

When I first set up my 1200 I had it running, then I started to go through your guide on tweaking my 1200 to make it even faster, which it did indeed do, but it also caused BOOM to start crashing upon launch.

I have moved again since then and am still trying to make ends meet so I've not had my 1200 out and set up for a while.

[Karlos]

He cheated and used a PC gfx card

That's not true, the card I used was designed by Phase5 specifically for the Amiga A1200 and doesn't fit in any PC I've seen :-P

Even the chip that's on it supports proper big-endian 32-bit ARGB pixel modes, none of this horrid 32-bit ABGR filth.

However, it is a cheat because it's not running on the 68K, nor on OS3.x and is totally dependent on the graphics card to do the polygon rasterizing.

[youtube]UcuNR3yyIo4[/youtube]

[ChaosLord]

In this case it's simply easier to render to a chunky buffer in fast RAM, and then copy/translate it to display memory using an optimised C2P routine. But even that's difficult, as you are turning 32 chunky bytes into 8 planar 32-bit words. You inevitably need to store some working data in memory as you are processing things, so a fast large CPU cache comes in very handy.

Luckily for us, the 68040 with dual independent 4K L1 Caches was released in 1990 thus allowing Amiga to do 3D gaming properly.  

Not just a 4K L1 DataCache, but a CopyBack DataCache which massively helps out with this sort of code.   When you store things to memory you don't really store them to memory you just store them in the L1 Cache which is superfast.

My 68040 saved me from a life of slow 68030 drudgery.  Yahoo!

[XDelusion]

That's not true, the card I used was designed by Phase5 specifically for the Amiga A1200 and doesn't fit in any PC I've seen :-P

Even the chip that's on it supports proper big-endian 32-bit ARGB pixel modes, none of this horrid 32-bit ABGR filth.

However, it is a cheat because it's not running on the 68K, nor on OS3.x and is totally dependent on the graphics card to do the polygon rasterizing.

[youtube]UcuNR3yyIo4[/youtube]

Uhhmmmmm...

What hardware is that running on?

[Karlos]

Uhhmmmmm...

What hardware is that running on?

The worst hardware you could possibly want to run it on from the point of view of what it was originally developed for

My A1200+BPPC+BVision

[XDelusion]

The worst hardware you could possibly want to run it on from the point of view of what it was originally developed for

My A1200+BPPC+BVision

And there in lies half of the fun...

...pushing limited hardware to do things it was never intended to do.

[Karlos]

You should feel ashamed, and ban yourself!

Tried, it doesn't work.

[NovaCoder]

I think the point is, that you can do a lot more with AGA and 68k than they ever did back-in-the-day (providing you have a fast 68k CPU of course).

Basically we got to about 96(?) and everyone gave up on AGA/68k and went over to PPC with Mediators using PC graphics cards.   Quake 2 wasn't even release until 97 so for an AGA 1200 to even run it, that's pretty cool.

A modern 68060 CPU card design (like Jens ACA cards) would be really something special, if it was coupled with a decent 68k gcc compiler and a chunky graphics mode then it would be even more impressive

[Karlos]

@NovaCoder

Have you ever investigated those RGB -> HAM C2P routines that are on aminet? Some of them are probably copyspeed on the speed of 060 you are using. At some stage in the rendering code, after the shadowmap is blended with the texture colour, the engine probably has to convert an RGB value back to a palette entry. Clickboom's Quake port had a 16-bit mode in RTG, it would be very cool to see something like that in AGA.

[NovaCoder]

Hiya,

Yes I did actually spend quite a bit of time looking at those HAM8 C2P routines, I wanted to use them to display the GUI in ScummVM AGA which is natively rendered in 16 bit color.   I had really trouble getting my head around what to set the palette values to so in the end I gave up and had to covert the 16 bit color values to 8 bit color values in real-time using a look-up table.  I'm probably going to have to use the same approach for my current port of DosBox 0.74 to AGA

Anyway it appears that rendering HAM8 (via C2P) is not really any slower than normal 8 bit C2P, the real overheard is generating the color values to  be used (which is very slow to do dynamically).    I guess this is the reason that HAM8 C2P hasn't been used in any games, for the demos that used HAM8 (eg the awesome Push), I assume they just pre-calculate the palette entries.


Then again MooVid has a fast dynamic HAM8 display mode so there must be way...

[ChaosLord]

I investigated making the animated parts of my games use HAM8 mode but... it would either not work or be really really complicated and a ton of work... for that much work I could just rewrite the game to use 16.7 million TrueColor gfx cards so I just kinda gave up on HAM8.

When you start going into HAM8 it conflicts with traditional color cycling techniques that I get to use in normal 256 color mode.

You have to avoid fringing.

Its way more complicated.

More coding.  More work.

In the end I settled for 256 color mode because I can do superfast multilayer blitting. Colorcycling the way I want it.  Never have to worry about fringing.

I just use HAM8 for TitleScreens and such.

I would not mind displaying movies in HAM8.  But I could not work out how to use/adapt CDXL video format for HAM8 purposes.  It did not exactly have user-friendly documentation.  I could have figured it all out if I was willing to devote my whole life to it for 30 solid days.  I didn't feel like it was worth 30 days of my life just to play HAM8 CDXL32 movies in my game.  So I passed on it.