Bad Mood : Falcon030 'Doom'

[dml]

Audio panning (left/right separation) is now working on ingame SFX, so you can now tell the direction of hidden monsters and of doors opening/closing in the distance.

Distance volume attenuation is also now working so doors opening in the distance are much quieter.

[bullis1]

I didn't expect such differing opinions on Doom's music! Personally, I found the lack of music to completely ruin Jaguar Doom. It just loses all drive to me. It's also my only gripe with Doom 64.

Some YM solution would be fantastic if could be kept moody. People can always turn it off.

EDIT: Also I thought one of the goals of the project was to provide an Atari-specific game engine for future developments, which would hardly be complete if it didn't support music playback.

[troed]

Currently SNDH is not working despite much hackery and experiments, and hand-patching bits of it out in the debugger. Unclear exactly whats going on in there and why it needs all those timers and stuff for normal YM playback.

FYI, SNDH is just a wrapper and contains the appropriate replayer for that specific song. That means that different SNDH files can have different replay routines - some which use a lot of timers (like Sid Sound Designer) and some that don't (regular VBL/50Hz calls).

/Troed

[FedePede04]

it was also the reason why I suggest to find a player where you had sourced code for it...

FYI, SNDH is just a wrapper and contains the appropriate replayer for that specific song. That means that different SNDH files can have different replay routines - some which use a lot of timers (like Sid Sound Designer) and some that don't (regular VBL/50Hz calls).

/Troed

[dml]

FYI, SNDH is just a wrapper and contains the appropriate replayer for that specific song. That means that different SNDH files can have different replay routines - some which use a lot of timers (like Sid Sound Designer) and some that don't (regular VBL/50Hz calls).
/Troed

I noticed in the header there is a field to determine playback mode/capabilities. I tried messing with this and setting it to VBL playback only. However when I did that, I didn't consider that the actual *code* might vary in each SNDH file and the field isn't just a switch influencing the setup code. That would explain things.

I should probably go back and retest with a song exported in that mode and see if anything changes.

[dml]

The water/lava/slime shaders are now working properly on the correct surfaces with the builtin textures. They don't work yet with HD textures because the format is wrong for that kind of shader but this can be fixed.

Now I need to go through the levels with these different liquids and configure the shaders to look nice on each one

[EDIT]

The code has been checked in with the green 'nukage' liquid shader configured pretty well. All the others are using a different default for now.

[Eero Tamminen]

I didn't expect such differing opinions on Doom's music! Personally, I found the lack of music to completely ruin Jaguar Doom. It just loses all drive to me. It's also my only gripe with Doom 64.

Hm. You're marine confronting monsters from hell. Instead of trying to hear in which direction they come from, you put on some loud music on. That sounds... suicidical.

While I think music at startup etc is great idea (similarly to Ray's Wolf3D), I think actual game play can do without. I'm also afraid that if it's of high quality, it takes too much CPU away from game the itself and otherwise it may be of too low frequency.

MIDI music is still an option. Many Atari users had MIDI gear (me included) and Hatari supports MIDI too. There's MIDI music included to WAD files, but there could also be MIDI music made specially for BM (there still are Atari MIDI musicians I hope).

[FedePede04]

YmmPlayer.rar

I am with you on that one, i also love the sound of pure YM.
but i do have an idea to a YM format (like then one on the PC) it takes a more spaces then a normally Score+Instruments, but where you can make a fast and very simple replay routine, that should not interferer with the code.

hi
here is a little example on streaming ym datas,
i know, you can't use this type of music in doom it is just for the testing purpose.

the data was recorded at 250hz, so they should be as good as if it was the player playing them.
the player routine was not optimize for speed, i have made the format to save space.
and i also know that the code is not very optimize, but it should give a good idea on how it work.
the routine takes about an half raster*5..

to start the player press 2 to stop the player 3, exit 1..
i have include the source code, and i don't know if it runs on a real computer, i made the code in a hurry under STeem,
just to see how it would work...

[dml]

hi
here is a little example on streaming ym datas,
i know, you can't use this type of music in doom it is just for the testing purpose.

Many thanks for that! I was going to have to find time to do it myself and you've probably saved me some trouble

Contributions like this really help even if they don't seem like a lot of code, because there are so many things to do in total and making the first version of something new work can take the longest time of all...

I have nearly finished making the liquid shaders for different types of texture and level variations so I will take a look at this next.

Cheers!

[FedePede04]

Hi
you are welcome,
i don't know if it is something you can use, the code is incomplete, like then it reach end of the score it don't restart,
and it is also pretty bad coded, i have not code anything for the Atari for sometime, so i have forgot most again

it was more to see if it could be done (at one point, i was thinking of use this method my self for a game), it is an easy way to get music into a program, as you can see from the source code.
but the music take a lot of space, one could do like we take about the sample music, you could also chose to split the music into small part, and make some form of simple sequencer. and you could also lower the replay hz
but i know you already know this

the hardest part to this method is to record the music, into this format,
i don't know if you can setup a irq that capture the data from the soundchip, and save them to a file..

hi
here is a little example on streaming ym datas,
i know, you can't use this type of music in doom it is just for the testing purpose.

Many thanks for that! I was going to have to find time to do it myself and you've probably saved me some trouble

Contributions like this really help even if they don't seem like a lot of code, because there are so many things to do in total and making the first version of something new work can take the longest time of all...

I have nearly finished making the liquid shaders for different types of texture and level variations so I will take a look at this next.

Cheers!

[Eero Tamminen]

Attached is processed spinloop information (discussed earlier), for full Doom II timedemo (timerbase 1 etc) from Hatari.

I've also enabled doing that in the BM profile.sh. If you haven't got the very latest Hatari HG version, you get some errors in hatari.log for commands related to this, but rest of profiling should still work. I hope spinloop detection doesn't slow down things too much.

Here are a couple of things which seem to be spinning huge number of times, but always at maximum 2/3 times:

Code: Select all

CPU loop statistics
   max: at VBL:    min: at VBL: times:  stddev: addr:   size:
...
      2    8812       2    5704    5245     0.0  03291a      2
      2    8811       2    5707  164856     0.0  055c8a      2
      2    8811       2    5707   11191     0.0  055c7a      2
...
DSP loop statistics
   max: at VBL:    min: at VBL: times:  stddev: addr:   size:
...
      3    8812       3    5704    5283     0.0  000d2d      2
      3    8811       3    5707  165078     0.0  000ca0      4
      3    8811       3    5707   92317     0.0  000ce2      4
...
$ grep -A2 055c8a badmood-all-frames-CPU.txt
$055c8a :             btst      d4,(a4)                    0.45% (495073, 5365864, 19953)
$055c8c :             beq.s     $55c8a                     0.45% (495073, 3304720, 77)
$ grep 0ca0 badmood-all-frames-DSP.txt
p:0ca0  0aa980 000ca0  (06 cyc)  jclr #0,x:$ffe9,p:$0ca0                           1.41% (5768258, 34609548, 0)

[dml]

Attached is processed spinloop information (discussed earlier), for full Doom II timedemo (timerbase 1 etc) from Hatari.

That's great! I'll take a look at this very soon. Interested to see which spins are really needed...

BTW on reading your description on hatari-devel, the 'VBL' tag is used to associate DSP and CPU spins belonging on the same frame. I worry about this, because the same spinloop can occur many times inside the same VBL - and in fact it's possible a group of spins could cross more than one VBL (like shading the floor for example). I'm not sure how meaningful the VBL information really is here as it depends on the 'grain' of what is happening.

However I need to start using it and thinking about it properly before knowing if it matters or not. I'll let you know when I've tried it. It looks like it will be very useful.

[dml]

...have got the liquid shaders working with HD textures now, and with optional animation if the textures (and engine rules) provide it. Each type of liquid has a group of possible behaviours to choose from which work well with that liquid/texture, and is chosen randomly when a level loads.

Just messing with the textures etc. to make things look decent.

[EvilFranky]

Have you ran this on a real Falcon yet Doug?

Any idea about frame rates yet?

[dml]

Have you ran this on a real Falcon yet Doug?

Any idea about frame rates yet?

Not tried it for a while probably would be a good idea... providing it works (!) it should run close to Hatari's speed. It's a bit slower than normal floors but for the resolution which will be used ingame it won't have much impact overall.

[Eero Tamminen]

BTW on reading your description on hatari-devel, the 'VBL' tag is used to associate DSP and CPU spins belonging on the same frame. I worry about this, because the same spinloop can occur many times inside the same VBL - and in fact it's possible a group of spins could cross more than one VBL (like shading the floor for example). I'm not sure how meaningful the VBL information really is here as it depends on the 'grain' of what is happening.

It's just an approximate timing that is easy to get inside Hatari [1]. From VBL you can get at least approximate timing for the loop, is it at the start of the Doom timedemo or at the end, and more easily find it from the full spinloop data file.

[1] Currently getting CPU cycle information in Hatari is pretty annoying, it works differently depending on which CPU core is used, is DSP enabled etc. After Nicolas has had time to make the CPU cycle counter saner in Hatari (monotonic 64-bit one starting at boot which works similarly on all CPU core configurations), I can change several things in debugger to use that instead of VBL and instruction counts.

[dml]

Finally, managed to assemble a video:

http://www.youtube.com/watch?v=MUWJSUiP ... e=youtu.be

This is using all the latest code, running the full game with a custom made map for testing the liquids. It has all optimizations enabled and is running on a stock 14MB machine. No emulation and no acceleration.

The window is 224 pixels wide, using the default 320-pixel video mode with a 512-pixel virtual linewidth. This is what causes the menus to mess up (no it hasn't crashed).

I turned the status bar off because it's still in C and slows everything else down.

Recorded from VGA monitor using a camcorder.

[EvilFranky]

Looking immense Doug.

It's super smooth, quite amazing to see this on the Falcon at last

Sent from my Nexus 4 using Tapatalk 2

[FedePede04]

Looking Good
i must be very rewarding for you to see the result, after all that work you have put into it.

keep up the good work

[rian_ata]

Impressive!

[dma]

Wow, indeed those liquids look toxic as they should!

Thinking about all this, indeed true that, along DOOM itself, it will provide a complete playable/enjoyable FPS engine on 'stock' (14mb) Falcon, ready for creating new games.
Also all the appropriate wad-creating tools are available (OK, not on Falcon directly, but nearly all Falcon owners also got some other actual machine along now).

By the way, will the engine work with existing "vanilla DOOM" TCs (total conversions)?
http://doom.wikia.com/wiki/Batman_DOOM
http://doom.wikia.com/wiki/Aliens_TC
http://www.doomworld.com/idgames/index.php?id=15174
http://www.doomworld.com/idgames/index.php?id=12228
http://www.doomworld.com/idgames/index.php?id=15645
http://www.doomworld.com/vb/doom-genera ... doom-wads/

Also i was wondering which engine part was handled by the DSP exactly? Graphics rendering only or more? (maybe the BSP system also?)

Congrats again on the achievement Doug.

[dml]

Wow, indeed those liquids look toxic as they should!

It's just a pity the camcorder saturates out the lava one. It looks better on the monitor.

Thinking about all this, indeed true that, along DOOM itself, it will provide a complete playable/enjoyable FPS engine on 'stock' (14mb) Falcon, ready for creating new games.

It will be great if somebody tries to make something new with it. I would help as much as I can - although when its finally done (soon I hope) I'll want a break to do something else for a while!

Also all the appropriate wad-creating tools are available (OK, not on Falcon directly, but nearly all Falcon owners also got some other actual machine along now).

Yes AnthonyJ has kindly given us the source for GemDEU which will run on Atari and I think this can provide a launch point for customizations to the engine - stuff the other editors don't / won't do. Although I don't know if anyone will find the time to actually make such mods. At least it should be possible with that.

I used DoomBuilder to make the test map there. It didn't take more than a few minutes - the tools are pretty mature. Not perfect, but pretty good. Slade3 is also good for browsing the WADs and splicing/organising PWAD resources.

By the way, will the engine work with existing "vanilla DOOM" TCs (total conversions)?
http://doom.wikia.com/wiki/Batman_DOOM
http://doom.wikia.com/wiki/Aliens_TC
http://www.doomworld.com/idgames/index.php?id=15174
http://www.doomworld.com/idgames/index.php?id=12228
http://www.doomworld.com/idgames/index.php?id=15645
http://www.doomworld.com/vb/doom-genera ... doom-wads/

(>caveat alert<)

Providing the WAD is made for 'vanilla/chocolate/classic/dos Doom' it should work. There will likely be small things which don't look exactly the same, or don't work, or even crash the engine. But IMO that stuff is a small subset of what's out there.

If the WAD contains weird stuff specific to ZDoom, Boom etc. engines then it's probably not going to work.

If the WAD relies on new AI code which has been added to the game side of the program (e.g. Doom II contains monsters not present in Doom I, so you can't use the Doom II WAD with older Doom's code) the WAD may load but the game likely won't do what it's supposed to. I don't think that's a common scenario - most of the WADs just replace map and other data resources to use with the original code.

Fortunately for us, the source this is based on is a hybrid amalgamation of Doom, Ultimate Doom, Doom II, Final Doom so all of those IWADs should work, as should the PWADs made to work with them (I don't actually have the Final Doom IWAD so it remains untested)

I'm pretty sure I tested the Aliens_TC WAD recently and IIRC it at least render ok. The game part hasn't been working long enough to have tried PWADs much for gameplay but so far it looks ok...

Also i was wondering which engine part was handled by the DSP exactly? Graphics rendering only or more? (maybe the BSP system also?)

I took a quick survey of what's there:

Whole project is divided very roughly into 7 areas:

1) Id's original game code package: LinuxDoom 1.10, (provided as C)
2) Some patches/bugfixes crossported from Boom and other engines (also in C)
3) Audio, video, input layers, implemented the usual way for a Doom port (mixture of C and asm)
4) Some rewritten code (by me, Eero) either as optimizations, fixes or Atari compatibility work (mostly C, a little asm)

Some attempt has been made at keeping the above parts as close to the original code as possible so mods/extensions from elsewhere are not too hard to apply.

The next parts are all assembly language, and are not part of Doom or Id's code. It can be considered a 'black box' that draws maps and things on the screen.

5) 'BadMood' engine API, around 50% of which was redone in the last year, the rest dates from around '97-ish. This part is basically what's used by BMVIEW.TTP with a small shell wrapped around it for the viewer. It's used as a library by Doom for drawing scenery etc.
6) DSP co-processing API (subset of engine API), providing services to game code for a few things.
7) DSP engine core & RPC interface


DSP services... based on a quick survey of the RPC interface:

main engine services:

- geometryengine for processing map line segments / sprites -> rendering in 2D
- generating (and testing/clipping things against) pixel column occlusion and clipping buffers
- spanbuffer generation for floor drawing
- checking visibility of various things against viewcone
- texture streaming/buffering as part of floor drawing
- used as mini GPU/pixelshader for drawing floors with mipfiltering
- used as mini GPU/pixelshader for liquid distorts
- providing spans and columns to the CPU for drawing with (CPU does all of the drawing, but DSP assists where it makes sense)

co-processing services (used directly by game code - direct reimplementations of existing C functionality):

- ray pathtracing across map/BSP for AI visibility tests
- more ray pathtracing for collision tests

The DSP doesn't directly interact with the BSP during rendering, although it does get close to that for the game co-processing tasks which are really BSP oriented. The reason for this is the small amount of DSP memory and the large size of the BSP data. For the rendering work, the BSP isn't a major cost anyway as it's only traversed once. The game code uses it much more, which is why the co-processing interface was added (which puts the DSP in the driving seat for BSP traversal, using CPU as a data server).

Congrats again on the achievement Doug.

Thanks to you and everyone else for following progress.

[AnthonyJ]

By the way, will the engine work with existing "vanilla DOOM" TCs (total conversions)?

Some (many?) of the bigger TCs use DeHacked ( http://doom.wikia.com/wiki/Dehacked ) to modify properties like strings, health/damage stats etc inside the gamecode via a binary patch that won't work with Bad Mood. Certainly the Batman one says it used it a lot.

Many modern forks of the Doom codebase include support for loading these patches and applying them at runtime instead of modifying the binary - maybe it'd be possible to add support for this to Bad Mood, although I don't know what the performance impact of this runtime flexibility is.

Congrats again on the achievement Doug.

Seconded - this is an interesting read watching it getting progressively better and better!

[EvilFranky]

Hi Doug,

So what is left to do before an initial release?

Are there further optimizations planned or is that part all done now?

And lastly...will you still look into JagPad support?

[dml]

Hi Doug,
So what is left to do before an initial release?

There are a lot of problems with the status bar, menus and intermissions which I haven't figured out yet. Partly cost, partly incompatibilities with double-buffered drawing.

There are lots of other small annoying problems, like the problem with the keyboard (limit on simultaneous keypresses, also causing spurious/random key events) and mouse (calibration, also interacts with simultaneous keys problem). The program doesn't quit cleanly (well, currently doesn't quit at all). I have a list of these things and it tends to stay the same size no matter how much I do.

There are also a lot of things I hoped to do which are not part of the original. Some I've shown bits and pieces of, others I haven't mentioned yet.

Hi Doug,
Are there further optimizations planned or is that part all done now?

Unfortunately while that map runs quite fast, it is rather simple. There are few sectors visible at any time, few upper/lower step surfaces, few wall segments and lots of occlusion. Real maps - especially more recent ones designed for faster 486's, Pentiums and onwards don't care about map efficiency and just use tons of sectors for visual effects like fake lighting/shadowing & fine details. This really puts stress on the engine. BadMood isn't strongly pixel-fill-limited now but it is complexity limited in terms of scenery.

Some Doom II maps are still unplayable because of this.

Then there is the game code, which is big and slow. It gets slower as the number of enemies on the map grows. Again, some maps that look like they should draw fast will run poorly because of this. I have done a lot of work on the worst parts but there's so much of it that it needs more, and will have to cut off at some point.

So it does need more optimization to run existing maps, especially Doom II maps.

If maps were made for a Falcon game, it would likely run 2-3x the speed of the average Doom II map.

If the game code (the AI stuff) was chucked away and a new game manager written for a Falcon game, it could run nearly as fast as the BM viewer - faster than what's in the video.

And lastly...will you still look into JagPad support?

I'm sure JagPad support would be easy. However I don't have one If I can't do it, I'm sure somebody else can.