Quake 2 on Falcon030

[dml]

Brief indirection: http://www.atari-forum.com/viewtopic.ph ... 59#p263258

[dml]

While *not* working on this project, I had a few ideas which are worth trying.

I think it's possible to disappear the per-face setup calculations behind the scanconvertor. Or at least, disappear whichever part takes less time. This involves refactoring the (already split in two) per-face setup math into a more trivial DSP part (just-in-time before drawing) and a more complex/precise part (FPU) and moving the FPU bit to a sort of service which runs simultaneously with scanconversion.

It sits and waits for the scanner to report the first real span emitted to any new surface, and places it in a queue. On the other side, the CPU occasionally reads a face id from the queue and starts to 'do the math' (sorry). The queue can be primed to collect several faces before working, so the CPU doesn't block the DSP scanner. After the first scanline, new faces will stop appearing in bursts and begin to appear incrementally, spaced out in time, just enough for the queue to soak it up. The FPU keeps busy as needed without getting in the way. sorted!

Just need to make it work.

There's another, much better optimization to be used on faces but will try it afterwards.

I'll keep looking for ways to reduce the per-face overhead because its still a limiting factor on the texturemapping version. I'll take turns between that and the geometry part until the choppyness starts to flatten out more, and leaves the per-pixel cost problem to be dealt with separately.

Won't start doing much on this until I get more time (and fix BM bugs) but planning makes it quicker

[shoggoth]

But what sort of bricks? Are we talking full-sized house bricks here, or the
easier to pass but still horrible in a knobbly manner lego bricks?

Details are unknown, but I do remember yelling "MEDIC!" before passing out after having watched the latest release of BadMood.

[dml]

Details are unknown, but I do remember yelling "MEDIC!" before passing out after having watched the latest release of BadMood.

Did you find your special floortile? For some reason it insisted on rendering backwards before SillyVenture, no matter what I did. I'm not sure what that means!

[dml]

I decided to post that 68882-optimizer tool I wrote about earlier in the thread, made to help with this project. Can be found in a new thread made for that:

http://www.atari-forum.com/viewtopic.php?f=16&t=27288

[shoggoth]

Did you find your special floortile? For some reason it insisted on rendering backwards before SillyVenture, no matter what I did. I'm not sure what that means!

I saw it right away! Socks flew off, spewed coffee through my nose etc!

[AdamK]

I'm sorry Doug, but the coolest Quake2 engine ever has been done: https://www.youtube.com/watch?feature=p ... Mli33ornEU (Quake2 on osciloscope). You can only take 2nd place

[dml]

I'm sorry Doug, but the coolest Quake2 engine ever has been done: https://www.youtube.com/watch?feature=p ... Mli33ornEU (Quake2 on osciloscope). You can only take 2nd place

Yeah, was wondering when that was going to happen

X:Y plotting from a preprocessed 2ch audio sample. Not technically 'running' quake as such, but certainly does qualify as 'drawing' it in a cool and crazy way.

[dml]

Have converted the last of the more important C functions into 68k, applied some smaller optimizations and starting to go through all the existing 68k code again looking for better ways to do things.

Once I'm happy with that I'll do the same with the DSP code.

This is being done on the non-textured version of the code. Will merge the optimizations forward once it settles and continue on the textured version.

[dml]

The current profile looks a bit like this:

Used cycles:
28.25% _R_SubmitFaceGeometry_DSP56k ****
14.66% _R_ReindexFaceVertices_68k **
14.27% _R_RecoverSurfacesCPU_DSP56k
13.75% _R_RecursiveWorldNode5PL_68k
10.19% _R_ScanConvert_DSP56k
9.17% _R_ProcessBSPVisitQueue_68k **
4.36% _R_XFormProjectTaggedVertices_DS

The ones with stars are currently being worked on. The others are already quite optimized.

R_SubmitFaceGeometry is reasonably optimized on the 68k side, and mainly blocked by the DSP taking too long to process edges as they are inserted & clipped - so this will need more work on the DSP side.

Some time is still currently wasted in R_ReindexFaceVertices_68k and R_ProcessBSPVisitQueue_68k checking for invisible sky faces via expensive lookups, which can soon be removed.

[dml]

The latest version (untextured) shows a 15%+ increase in speed when viewing the same content, for the most dense scenery. In some cases 20%.

This involves C and 68k work only - no changes to DSP code yet.

[kristjanga]

Thank you for the update.. Fun to read like always.

[dml]

Some tests with Quake 1 maps:

[dml]

...cont'd

[DarkLord]

Doug, every time I go to the dictionary and look up "overachiever"
these days, I see a picture of you holding a stock F030.

[calimero]

The latest version (untextured) shows a 15%+ increase in speed when viewing the same content, for the most dense scenery. In some cases 20%.

This involves C and 68k work only - no changes to DSP code yet.

untextured version was already crazy fast! and now even faster!?

can you make new video with untextured vesrion?

[dml]

Doug, every time I go to the dictionary and look up "overachiever"
these days, I see a picture of you holding a stock F030.

Thanks for the kind comments

Well I suppose this is an alternative to working on a demo - anything bigger than an intro usually requires a group of people and different skills working simultaneously - and with any luck some existing code to build upon. I haven't built up enough new code yet to work on a decent demo but I can work on this on my own and get some sort of result, and it contains a bunch of new stuff to explore and play with. I'm also building up some useful material as I go along.

I have notes on about 30-ish different experiments to try on Atari (mostly Falcon but some ST), but not yet really in a position to turn them into something useful. I have started on 2 or 3 of them but not enough progress to demonstrate anything nice looking.

A couple of things fell out of the Q2 work which I have not yet mentioned at all, and which I believe will make some interesting new techniques possible in future. These did not come from Q2 itself but from trying to work out how to solve various problems on a Falcon.

[dml]

untextured version was already crazy fast! and now even faster!?
can you make new video with untextured vesrion?

A 15% improvement in the flat-filled version is probably not visually impressive enough to be worth re-recording something - but once the 68k and DSP code have been re-optimized and bugs flushed out it may be worth posting something new.

The texture mapping version I last showed is a prototype only and needs a lot of work to optimize it properly so it will need a separate chunk of work as well. The main annoyance with the TM version is the reliance on two sections of FPU code executed during face setup. Hatari executes this code faster than real HW and I haven't tested how much faster - perhaps significantly (like 5x) - so it remains a negative factor for running on real HW until I remove at least one of those sections. The FPU drag may not be noticeable on very simple scenes but must be draining for some of the more common scenery in the game.

Replacement of that FPU code is planned as part of the TM optimization work.

[dml]

After the last hour analyzing execution I can now see a sensible way to overlap the CPU reindexing/compacting of visible geometry with the DSP clipping and inserting edges, by reordering some steps and introducing a new deferral step for submitted face and edge indices, allowing them to be processed in parallel.

In principle it is simple to do but in practice it would need to steal yet more DSP memory for the deferred data. Figuring out how/where to steal that memory without compromising something else will probably be difficult - but if that can be done it should be possible speed up the geometry part of the engine in a measurable way (read: speed up complex scenery). It might then be possible to collapse a couple of steps together to save even more time. Adjusting the geometry batch size could then find the ideal batching pattern for worst case scenery.

[Scarlettkitten]

Keep up the great work Doug

[dml]

Happy New Year!

[EvilFranky]

And to you Doug!

[DarkLord]

Ditto to all!

[dml]

I did do a bit more on this but the holidays were busy and I was trying to release an update for BM at the same time.

The last changes mentioned were been included after scraping some extra DSP space from obscure holes in existing buffers. This alone did result in a small to moderate speedup.

The next changes will focus on making the most of this:

- rework code to minimize the duration of time spent using CPU+DSP at the same time - make those blocks of time as narrow as possible
- split off as much DSP-only and CPU-only code as possible into separate time blocks, even if they are just parts of the same high level routines
- reorder blocks of work to overlap DSP tails as much as possible
- break up and move single-pass work (e.g. post-BSP queue processing, maybe other stuff) into batching loop so it can be overlapped with other stuff, even if it doesn't actually need batched

This secondary pass should give yet another speedup by increasing parallelism.

There is one significant block of DSP work which can't be batched, but it can be moved and overlapped later with collision detection work, so one or the other will become 'free' - whichever takes less time (most likely the DSP part for now). This simple change will again knock away 10% or so.

I'm not sure how some of these changes will interact with object drawing in future but I suspect its as compatible with that idea now as it was before.

[AdamK]

- rework code to minimize the duration of time spent using CPU+DSP at the same time - make those blocks of time as narrow as possible

Why? Isn't processing in parallel faster?