Bad Mood : Falcon030 'Doom'

[dml]

That sounds really great! Running both BM in Hatari with WinAUE CPU core & DSP emulation, and a good softsynth in the same computer needs beefier machine than mine, to do all that without getting frame skips in Hatari though...

I'm still trudging along as I find the time.

There are now 33 music tracks converted and working in the game.

I have also considered adding 'modes' so you can play (at least some of) the tracks using 'chippy' fx instruments instead of the intended ones, for that YM experience

[dml]

Minor update.

Nearly all D1 and D2 tracks are now working with most good enough for a release - except a couple which I skipped because they depend so much on pitchbend it didn't make sense to try a workaround. Conversion is pretty reliable and only a few special cases have needed manual tweaks. More instruments have been added so fewer need remapped.

I have since figured out a way to support pitchbend without breaking anything but will leave it until HW MIDI is done. If it does get included in the SW version it will involve reconverting all of the tracks again after a format update.

Some tracks still have minor todo's (e.g. volume adjustments, instrument mismatches or minor sound quality issues) but most can wait.

I'll try to reconvert some Q2 tracks before moving on with the HW version. They might begin to work better after recent improvements to the code.

Suddenly realized I don't know how music looping works in the game - probably does some form of IsPlaying check and restarts periodically from the game code - I don't see a looping mode in the sound layer. One more item on the list!

Progress isn't exactly fast (!) but the current version looks much more tidy, has a lot more stuff in it and won't be long now for a beta release.

[dml]

The last time I tried to transfer files from PC to Falcon using CFlash, I was unable to get any files across because there seemed to be format compatibility problems and I couldn't figure out what was wrong.

I did have it working in the past but I am not sure what changed between now and then.

I used HDDriver to format a 2GB SanDisk flash card to <1024mb and created a TOS/Windows partition. I then plugged it into a PC running Windows, copied the file onto the cflash (which seemed to work) and moved it over to the Falcon.

The falcon has an existing CFlash on IDE device 0.00 acting as C, which is permanent. I used a second CFlash adapter on device 1.00 to plug in the new 'transfer' flash card and tried to read the contents. The filename was there, with the right number of characters - but the characters were corrupted.

e.g.

"BMT1.WAD" became "B[x1.WaD"

The Falcon was unable to open the file to copy, probably because of the symbols in the name.

I then swap the CFlash back into the PC and it is no longer readable on the PC - without having written it on the Falcon!

Trying to format the CFlash now on the PC results in failure every time, so it's now unusable on a PC. It does however reformat ok under HDDriver - until I move it back to the PC and then it's dead again. grrr.


I initially thought this might have something to do with having 2 cflash cards plugged into the Falcon at the same time - either the HW or HDDriver not coping with it properly - but *before* I created the dual-format partition on the card, I was able to see an old copy of HDDRIVER.SYS which was not corrupted - while both were plugged in at once. This suggests 2 at once is ok at least for reading. So the involvement of a PC copying stuff onto the card and swapping it between machines seems to mysteriously trash it - despite the fact that the mere copying of the file from Windows to card seems to be successful....

Anyone have a clue whats going on here? It's bizarre and kinda frustrating since my files are getting too big to move using the floppy emulator...

[dml]

I quickly tried a different CFlash - an old 64MB card I had lying around from an obsolete camera. Went through the process again and this time it worked, got some files across.

A quick test of the sound engine indicates it works properly on a real Falcon. It sounds better on HW than Hatari but I think that's related to filtering by Codec circuit versus replay rate mismatches under emulation - probably unavoidable.

I think the music code is slower on F030 than in Hatari - the track tested shows 4.1% in Hatari and 5.2% on a F030. Will try to optimize this later. Mixing cost is about the same, tiny bit slower on F030.

Got a cold today so don't have any patience for code or fiddling with HW - going to leave the F030 testing now until the weekend.

[dml]

Up to 45 music tracks now, from 3 ID games.

The few missing ones really depend on pitchbend and these can be added later now that I figured out a way to do it without overhead on other notes. Looks like a simple change to the storage format for the extra controller, keep note and pitch info separate and sum them only for sampling, generate new note tables and an extra mix pass for pitchbend-affected channels (tracks seem to use no more than 1 or 2 simultaneously and only needed for intermediate pitches which rarely hold on long notes).


Have stopped adding new tunes, but still tweaking some of them. Later levels reuse earlier tunes several times and this is an opportunity to merge/reshuffle tunes from the different games. Will stick mostly with the original mappings though where it makes the best fit.

Most of these changes (incl. Falcon Codec music tracks) will only appear when the special BM wad is loaded. Otherwise it will be 'vanilla' Doom behaviour and HW MIDI only, since it can only use what it finds in the original WAD and conversion to Codec isn't automatic.

Will be working mainly on music mapping and control, HW MIDI loading & replay, fixing bugs and adding some presentation stuff.

[dma]

Very cool, i'm eager to hear those tracks.

[dml]

Very cool, i'm eager to hear those tracks.

It should all be done within the next few weeks, somewhere between end of June and mid August. The todo list is now getting shorter instead of longer

[dml]

More random improvements - transparent skulls, fireballs and plasma fx.

tskul.png

This is mainly because the shader pipeline for walls and sprites had to be finished to get the attract mode demo stuff to work properly and that allowed some other delayed stuff to get finished.

[Eero Tamminen]

More random improvements - transparent skulls, fireballs and plasma fx.

Looks great!

Transparency means 50% more memory operations per sprite + blend calculation, so I'm wondering a bit about the cost. There are some places where one can have a lot of skulls and explosions close (i.e. covering lot of screen area) and they can overlap each other which makes this worse...

[dml]

Transparency means 50% more memory operations per sprite + blend calculation, so I'm wondering a bit about the cost. There are some places where one can have a lot of skulls and explosions close (i.e. covering lot of screen area) and they can overlap each other which makes this worse...

I'll put anoption in the .cfg file to turn off the extra shaders if wanted - it seems ok for the levels I tested but I didn't test very many - so 'lean and mean' options are always nice to have

[Eero Tamminen]

Regarding lean & mean options, is flat-shading going to be an option? While it made some things invisible, I was quite fond of the look.

[dml]

Regarding lean & mean options, is flat-shading going to be an option? While it made some things invisible, I was quite fond of the look.

Yes that shouldn't be a problem now - although it doesn't meaningfully apply to everything (such as sprites) and it's not supposed to be an optimal drawing path vs normal drawing paths. It will save some time but will mainly be a 'look & feel' thing.

The engine is optimized for texturing and drawing flat-filled spans at the lowest level of rendering doesn't save a lot of time because a lot of work is still being done to set up edges with attributes, and walls are still drawn as columns from texture-ready span data etc. etc.

[Eero Tamminen]

Yes that shouldn't be a problem now - although it doesn't meaningfully apply to everything (such as sprites) and it's not supposed to be an optimal drawing path vs normal drawing paths. It will save some time but will mainly be a 'look & feel' thing.

That's fine. If it provides some small perf improvement that's just a bonus. And it's one more additional unique feature supported by BM compared to other Doom ports.

[dml]

Not been well this week but during last month got a lot done overall. Getting close to beta release.

SW music replay working reliably, if still producing occasional cracks and pops in a few tracks. Will return to that later.

MIDI format handling integrated, hardware replay being done right now. Got a couple of Adafruit MIDI synth pcbs and will fit one inside my Falcon to test it

Engine has many new optimizations. Runs faster than before, but music steals time so on balance probably about the same.

New texturing technique - finally solved a problem with this which bugged me for ages. I think it is now finally at theoretical limits for the DSP with indexed textures and lighting (famous last words). But no, really - this took me 5 separate attempts to crack, with no progress until now.

Going to attempt one more big optimization that has bugged me even longer - floor span fragmentation caused by BSP walk order alternating between surfaces with different textures, creating seams. Tends to rise with scene complexity, causing nonlinear slowdown, mis-representing the Falcon's ability to texture the scene. Think I finally have a solution to this now. If it works it will be worthwhile, and will be the last big opt attempted on this project before it is put to bed.

Several new shaders, including addblend (skulls, fireballs, muzzleflash etc) and alphablend (some enemies).

New method of rendering Doom transparencies, much faster when up close. Better way to use the original postmap algorithm developed for BadMood transparent textures and sprites.

Completely replaced the lighting model, which preserves glows and specular highlights, and reduces saturation in dim light. Makes (some brightly painted) enemies look more anchored in the world at their respective distances.

Intermission game logic modified to swap old 'progress map' for new intermission art, based on Doom II progression.

Lots of bugs fixed, including a couple of really evil ones, and some issues with map rendering glitches.

New attract mode underway...

[dhedberg]

Wow, that's a lot of great improvements! Most impressive work! Everything that you've done so far on Bad Mood is absolutely amazing and I really appreciate you taking your time to share the progress here at Atari-Forum! Can't wait to get my hands on the new beta and eventually the final version!

[viking272]

That is amazing work, so much listed there and great to read the updates.
It's going to be the best Doom game on any format for sure!

[EvilFranky]

Amazing progress as per normal Doug, true Atari scene legend.

So can music be switched off to enjoy the added performance optimizations to their fullest?

[dml]

Amazing progress as per normal Doug, true Atari scene legend.

So can music be switched off to enjoy the added performance optimizations to their fullest?

Yes you can turn off the music - or better still, emit music directly via MIDI ports at low cost and high quality. Run a softsynth on your PC/Mac/Linuxbox or plug it into music hardware.

There will be other tweaks for making it faster in the config file, like reducing the sfx channel count, turning off the more expensive shaders, changing the DSP texture upload cap for higher or lower res windows, other stuff. But defaults should be good enough for most levels.

[dml]

It's not BadMood, or Doom - but somebody still might find it interesting.

https://www.youtube.com/watch?v=ghEaNY- ... e=youtu.be

This is one of the things I was doing after BSS closed and left the scene. Salvaged from an VHS and bits of code on various HD backups.

Aside from the obvious procedural universe thing - and having to use triangles for everything because pixel shaders didn't work yet - 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

It even had a network play mode, provided by one of the other coders, which let you chase between planets in one of two ships (but not actually shoot).

You may spot some trees, rocks and buildings on the ground on one of the planets. I had just started working on that bit when the project ended.

Fun times, like the demodays before that...

[EvilFranky]

Frontier but on steroids?

[dml]

Frontier but on steroids?

Frontier on steroids - but a bit less complicated.

[CiH]

This was the stuff you referred to a long time ago in an earlier email, before Falcdoom took over your life

Might be able to run on an '060 class at least, if simplified/changed around as I recall?

[dml]

This was the stuff you referred to a long time ago in an earlier email, before Falcdoom took over your life

Yes, endless friggin' falcdoom! I see bobbing corridors now when I close my eyes.

Might be able to run on an '060 class at least, if simplified/changed around as I recall?

I have something else to finish first after this thing, and then I'll start poking around with those sleeping projects. There are a few loose ends needing dug up.

[dml]

Well I finally got that optimization to work today. It was pretty hard, and needed solid attention and debugging.

It seems to have worked, and forced me to fix a few other things at the same time. One of them caused big maps to overflow DSP memory and either glitch & crawl, or crash. That doesn't happen anymore - the DSP can signal a flush request when it detects space is running out, allowing the scene building to continue.

I had to fix this, because the new optimization demanded that I chop available memory in half, to add another level of async/buffering of data. Without that fixed, the new changes made it blow up constantly.


It's not finished with some hacks still in there to draw out bugs - so its a waste of time measuring anything - light levels are broken and jumping around, affecting the total number of states needing drawn. However in the default view I get 8-12fps much of the time, with some dropoff during action - which is definitely better than before even with the debug hacks in there. The 160x200 fullscreen VGA mode seems quite playable and mostly fluid.

Will need to fix the lighting part and tidy it up, then check nothing has regressed.

I thought of one more, less complicated optimization affecting polygon edge scanning - it's optimized for vertical edges e.g. where floor meets a doorway but not so much for diagonals above/below view-facing walls. I think some simple changes can improve that. Probably not a big gain but might try it since it looks easy.

Apart from that, will focus on finishing the loose ends.

[dml]

Did some light testing on a real F30 this evening. At first it didn't work at all ...but that's been fixed.

It seems to run quite a bit faster than before. You can now play comfortably without XLOD (chunky column) mode, with a slightly reduced window even on some of the tougher maps like e2m2 (warehouse). The combined texturing speedup and DSP code rework has helped a lot.

Still slows down a bit in fights. Will look into that again some other time.