AmiQuake 2 - new 68k Quake 2 Port

[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.

[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.

[Crumb]

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.

In some demos the screen is configured as SuperHiRes, grouping 3/4 pixels and drawing R/G/B separately, the palette is fixed and the c2p  changes the colour to the nearer, if it's in the 64 colour palette you draw it, if it's not you modify the previous one. You can simply avoid using the palette and just modify the value of the previous pixel :-)

[Crumb]

You have understand it all wrong, Crumb's avatar has a Saint Peter's cros, he was crusified head down, so his cross is like in Crumb's profile.

http://en.wikipedia.org/wiki/Cross_of_St._Peter

Those pentagrams are symboling Christ's 5 wound or five senses of human, it might also protect Amiga.org against demons.

http://en.wikipedia.org/wiki/Pentagram
.

Without the protection of my avatar moobunny's demons could enter amiga.org. It also keeps away disguised osx/linux users who claim to be amiga users (signing posts on an amiga forum claiming to use osx/linux is offensive!) ;-)


@Novacoder

do you think there's room to introduce more fixed point math?

[Crumb]

@nicholas

not bad for a c64 although I was more amazed by smash design's versions of amiga&pc demos.

BTW, on an AGA miggy this smoothness is achieved using copper-synchronized c2p :-)
http://pouet.net/prod.php?which=56885

It would be nice to see some techniques like these in Q2-AGA

[Crumb]

Do you have the source for this copper assisted C2P?

Well, it's not like 030s using copper to help with c2p but copper is used to choose between rendering and c2p. The time you have between one frame and the next one you can write to chipmem at maximum speed (7MB/s). In this short interval your copy to chipmem shouldn't be interrupted by the rest of the system or the system wouldn't make much sense, that's why disabling multitasking is usual with this technique (perhaps running your program with a very high priority like 127 helps, I don't know).

If you talk to Blueberry/Loonies he'll tell you that performing just a copy to chipmem is a waste of time because you can do more effects at the same time. And he's very right but both techniques aren't mutually exclusive so you probably can perform the copy in the short interval *and* apply some filters.

All in all you should organize your code to have 2 phases: one of rendering and another one of c2p (c2p one would include a pair of c2p functions, one that does c2p inside fastmem and the other that does c2p to chipmem).

Article by Rune Stensland (put special attention to the part titled "DMA Problem"):
http://membres.multimania.fr/amycoders/opt/fasttruec2p.html

This part is the one that you could implement:

I use 2 interrupts triggered by the copper, one when the frame starts, and one when the frame ends. Each time the interrupt is triggered I change state from c2p->effectrender or effektrender->c2p. Inside the interrupt I exgange all registres used by the current routine (a0-a7/d0-d7,PC,SR), the Program counter and status register changes are performed by writing to the supervisor stack, so when I RTE the system will automaticly change to the right PC,Sr)

You told me some time ago that you didn't want to shut down multitasking, if you have changed your mind Winden/Network offered me the sources a pair of years ago, I could ask him if he wouldn't mind sending you the sources to do that. Perhaps it's already in the sources he published of some his demos/intros.

[Crumb]

Do you have a github or similar account with the sources?