Bad Mood : Falcon030 'Doom'

[dma]

Great news Doug!
A new video would be really cool for sharing your joy to us visually.

[dml]

Great news Doug!
A new video would be really cool for sharing your joy to us visually.

It currently looks very ugly after the rework - a bit of a flickery mess with rainbow colours on all the floor edges. I'll fix those things and record an update to post.

Cheers,

[SteveBagley]

the starchart was interesting because it used a nice algorithm which 'learned' how to fabricate names using a list of samples, and could produce a myriad of stable procedural names with a similar flavour, for all the stars on the chart. You could feed it a list of Italian village names and it would make more of those if that's what you wanted. Every star was pulled from an astronomical database (IIRC a merge of 3 large databases). The stars without names were named by my engine. It got pretty hard to spot which were real and which were synthetic

Using Markov chains and letter n-grams, per chance?

Steve

[dml]

Using Markov chains and letter n-grams, per chance?

Well deduced, yes. Synthesis used turbulence based on a location seed, so you just had to query the name of a place with its coordinates, to find out what it had called itself. Much of the rest of the system worked that way too.

We had a bit of a laugh back then feeding e-books into the name generator and getting it to emit prose (encoding tokens instead of characters). If you fed more than one book - really different kinds of book - it would produce some insane stuff. Combining 'A Brief History of Time' with a swearword dictionary was one of the more interesting ones tried IIRC. I probably still have some of the text but won't be posting it here

[SteveBagley]

Using Markov chains and letter n-grams, per chance?

Well deduced, yes. Synthesis used turbulence based on a location seed, so you just had to query the name of a place with its coordinates, to find out what it had called itself. Much of the rest of the system worked that way too.

Clever

We had a bit of a laugh back then feeding e-books into the name generator and getting it to emit prose (encoding tokens instead of characters). If you fed more than one book - really different kinds of book - it would produce some insane stuff. Combining 'A Brief History of Time' with a swearword dictionary was one of the more interesting ones tried IIRC. I probably still have some of the text but won't be posting it here

I used a similar system to generate prose to teach my first year CS programming class how changing the algorithms and data structures you use could have a huge effect on the program speed. It's amusing what stuff comes out of it (although it was always worrying what might come out when running it live during a lecture )

Steve

[dml]

I used a similar system to generate prose to teach my first year CS programming class how changing the algorithms and data structures you use could have a huge effect on the program speed. It's amusing what stuff comes out of it (although it was always worrying what might come out when running it live during a lecture )

Haha. That's a really good, and important point.

I spent a good amount of time writing sythesis grammars for various types of content - and then spend much longer trying to figure out how to stop it producing offensive or copyrighted things from nowhere. It was a bit of a minefield. I bet it still is.

For example, I remember one 'starsytem' would pop up with the name 'F*ckit'.

Perturbing or masking this away was not difficult, but others would turn up. Increasing the minimum name length or reducing probability of short names worked very well - but at the same time there was this dread knowledge that you couldn't stop it inventing things you hadn't seen yet. After a few of those we started talking whitelists and training from blacklist material to de-weight them. I don't think anything would ever work 100% though. Part of the point really.

[dml]

I've been up late again cobbling a video together with some of the latest stuff in it. Feeble production values, but covers the key points. There some minor problems with choppyness and unexpected data loading during play. It does need looked at but I'm done for now.

https://www.youtube.com/watch?v=QZEd3aG ... iv&index=7

Ingame music!

[EvilFranky]

Fantastic! Quite incredible Doug.

2 main things stand out for me...

1. The frame rate appears much improved, you may be under selling this Doug! E1M1 appears to hit the upper 12fps hardcoded limit regularly.
2. The transparent texture processing seems a LOT faster, again noticed during E1M1 at the end of the level.

Love all the little extras, they are very well done and suit the rest of the game perfectly.

[Scarlettkitten]

Wowzers, that's impressive Just shows what can be done.

I can see a space hulk game working well on the falcon a bit like the 3DO spacebulk game.

[dhedberg]

I've been up late again cobbling a video together with some of the latest stuff in it.

Holy crap! This is crazy unreal Doug!

[shoggoth]

Can't find my socks. They flew off.

[dma]

Indeed totally amazing!
The additional sound features make the game so much more lively!
That's superb Doug!

[dml]

2 main things stand out for me...
1. The frame rate appears much improved, you may be under selling this Doug! E1M1 appears to hit the upper 12fps hardcoded limit regularly.

There are many new optimizations in this version which were not in previous vids. The map engine and sprites have both had large chunks rewritten. Much of the DSP code was rewritten, at least as far as sensibly could without starting again! (something I did consider, but won't go there).

The vid used 'software' chunky column mode on RGB. If the music/sfx is silenced and the AI time-frozen (debug keys), you can maintain 10-12fps easily *without* chunky mode, using a window size one notch smaller than that one.

Unfortunately all the other stuff places a load on the poor old CPU side so ingame it varies quite a bit as can be seen in the video. I'm putting some tweak thingies in the config file to soften that blow, if FPS is the only aim.

I'm *really* looking forward to the HW midi version because it will allow the audio mixer to be dropped from 6 channels to 3 and remove the cost of the software music code - which varies in cost according to the track. Some tracks are cheap and others not so much. It's a midi timing grain thing - fine grained timing causes lots of fragmentation during mixing. But the SW version does show off the Falcon a bit more even if it costs extra to run.

2. The transparent texture processing seems a LOT faster, again noticed during E1M1 at the end of the level.

The transparency system used by sprites and walls was split in two, for billboard and perspected paths, and those paths were again divided in two for near and far objects. The near objects use a special algorithm for expanding sparse shapes into a description which is fast to render from. The distant objects use a quick and simple path lower setup but higher fill cost, mainly to avoid wasting time when many objects are onscreen. Combining these things and tweaking transitions made transparencies and sprites a lot faster. I don't think I'll be changing that bit anymore.

Love all the little extras, they are very well done and suit the rest of the game perfectly.

Thanks. The aim was to do small but audio/visually distinctive things, without making it 'un-doom'. Most of the extras can be disabled by not loading the BadMood WAD file.

I can see a space hulk game working well on the falcon a bit like the 3DO spacebulk game.

If anyone can be tempted to do something Atari with the engine, that would be cool. I've made that easy in most areas, but there's enough of my crappy hacky mess left in the game code that it could do with a proper tidy up first.

Thanks for all the comments once again (even more so from those of you who produce awesome stuff of one sort or another). It's always less motivating to finish things in a vacuum!

[CiH]

Everything everyone else has said about this one. It's great to see just how far this has come. Thanks for spending the time and effort Doug!

[NGF]

The video looks and sound great, this will be a great port of Doom
Thanks for all your hard work bringing Doom to Atari
Have you tried the Jaguar Doom wad on the Falcon? Maybe they will run even faster since they are optimized (less complicated) in some ways.

[dml]

Have you tried the Jaguar Doom wad on the Falcon? Maybe they will run even faster since they are optimized (less complicated) in some ways.

I did try it quite some time ago, and didn't see much gain because of the way BM was working at the time. Not much of a cost for extra textures and the geometry didn't seem to contribute a lot.

That might have changed after all the rework, so it's worth trying again. It will likely be faster (or more consistent fps) at the cost of looking a bit worse/repetitive.

After winding down from work hassles today (grr) I thought of 2 new optimizations this evening which seem quick to try, one may even help a lot. The other is more difficult to guess. Since they're easy I'll give it a go. Then I'll *stop* fiddling with it and do the content bit for beta.

[dml]

Tried the last 2 optimizations. One made a big difference. The other one, hardly any difference. Overall, worth the hassle of a couple of hours.

The improvement occurs where it is needed most - scenes with lots of floor/ceiling textures in view. Some previously choppy areas are now smoother.

This is all to do with deciding the best time to send a texture to the DSP (about 5.5k of data, slow to transfer over the port). The spanbuffer algorithm ensures no overdraw, but it can also count pixels needing filled. So it does that now, and the CPU can use this info to figure out if a zone of floor or ceiling in a given texture state has enough pixels in it to be worth transmitting a texture. When the area is too small, it uses a (still DSP-assisted) path with a lower fillrate, but no need to send textures.

The old system just used a simple rule, always sending dsp textures, but capped to 2 or 4 per frame, and fell back to the other path once this limit was reached. This usually worked because the scene tends to draw stuff from front (nearest/biggest) to back.

This stopped working so well when I optimized the renderstate stuff to work against BSP ordering. It also broke anway, in some cases. The result was sending too many DSP textures (if the cap was too high) or worse, not sending enough for a big fill area. This really could slow things down.

Now it always decides correctly, never mis-estimates because it has pixel-accurate measurements and can predict the cost. It has helped quite a lot. At least on the engine/rendering side.

The other optimization was nearly useless, so I won't mention it

[dml]

Here's a quick Fraps capture of the newly optimized engine, with half of the game activity and all of the audio disabled.

https://www.youtube.com/watch?v=zkW_W3u3Q-s

So it's not truly representative of the game framerate like this, and it wasn't captured from a real machine (still, Hatari is close enough) but it does show the renderer can cope with a decent sized window on a complex map without using chunky pixels, and maintain 10-12fps.

That's the last vid I think until it gets tied up and released.

[EvilFranky]

Wow! Impressive Doug. Amazing what these little old Falcons can do

[christos]

I am really sad I get motion sickness on FPS. Impressive work Doug!

[dml]

Speaking of what little old Falcons can do, here's something else which came to life on my old box. Well, mostly Hatari but it runs on the box also.

grab0007.png

This isn't an attempt to port the game - just to draw the maps for now. It's 8-bit rendering with a conversion pass just as my Doom port was on day 1. It should get the TC treatment though. This will be 'free', except for alphablending for water etc. which is not so easy to do quick on F030 in TC mode.

It is still awesomely slow, but I might be able to fix that. I'm sure I can make the rendering fast enough but there are some middle bits which I probably can't de-FPU without massive work and might become a limiting factor. Will see.


The hard part so far was getting the game data to fit in 14mb, because Hatari has no FastRAM emulation and it's too slow to turn around compile/test every 5 minutes with a normal 030 machine. This blocked me from starting on the project for *ages* so I decided to scrap the game code and work from the rendering module outwards. That's one of the reasons the doors and objects are missing. They are not actually part of the map.

And fixing all the intel-formatted data There are still some items which don't load properly because of this. The map files store many different kinds of thing, with offsets and pointers to stuff but not always sizes and that makes some things difficult to reformat without digging through the original code that uses it.

While I do have it, and did look through it, I did not use the Amiga/68k source port here because I just couldn't get it to fit in RAM. It is also 060/FPU optimized which doesn't help with an 030 version. It's easier to work from the original as reference. The Amiga material will be very good for CT60 targets but I gave up trying to get it to work in Hatari or 030 just because of the sheer greedy factor of Q2!

[EvilFranky]

Doug, I think you might be a little bit mental

Quake on standard Falcon?? Come on, surely there is a limit to what this machine can do?

[dml]

Quake on standard Falcon?? Come on, surely there is a limit to what this machine can do?

Quake 2 is interesting because it was the last 'new' engine to support legacy software rasterization. This makes it a viable candidate. All of the important constraints are being observed.

I did look briefly at Quake 3 and played with map reading/displaying code but the problem with it is the technology gave up on software rendering and the map clusters and PVS are designed for hardware - overdraw, z-sorting and other problems don't really exist in the same sense. So I'm not convinced anyone can sensibly attack it with a software rasterizer on old hardware because the maps would need reinterpreted and recomputed for efficient drawing. Not to mention the curved surfaces. So while it could be done, the result probably would be poor.

But Q2 is worth a go. The DSP can probably manage a scanline-coherence spanbuffer if there is enough space for it, and I have some new 'special sauce' for perspective correct textures, FPU-less floating point and tricks for lightmaps.

Dynamic lightmaps could be dumped if they just take too long to update. Perspective correction can be sidestepped for 90% of the surfaces in the scene. Floating point can be removed from much of the edge processing. The zbuffer isn't needed until you start adding meshes - but again the z's can be flattened for 90% of the surfaces in the scene. etc. etc.

[EvilFranky]

Ha! Crazy Doug.

Although standard Falcon RAM limitations would play a major part surely?

EDIT - Just looked up the specs, seems minimum RAM for Windows 95/98 was only 16MB! That includes having a nice bloated OS in the background...

[dml]

Although standard Falcon RAM limitations would play a major part surely?

EDIT - Just looked up the specs, seems minimum RAM for Windows 95/98 was only 16MB! That includes having a nice bloated OS in the background...

Yes it's just about feasible but need to avoid some of the bigger table expansion tricks I had in BadMood

It's also not the full game - but being able to run around a map at better than 0.2fps would be a good start.