Bad Mood : Falcon030 'Doom'

[Cyprian]

I think the 60Hz would be just perfect and 100% compatible with any VGA/LCD screen. The higher BUS usage of the VGA comes from the fact that every scanline needs to be read twice. The framerate impact is very subtle.

"I compared 320x240xtc mode with and without double-lines, speed difference is maybe 2%-3% (Videl don't read same lines again from st-ram but from its buffer)"

http://mikro.naprvyraz.sk/docs/mikro/videl.html

[ctirad]

I think the 60Hz would be just perfect and 100% compatible with any VGA/LCD screen. The higher BUS usage of the VGA comes from the fact that every scanline needs to be read twice. The framerate impact is very subtle.

"I compared 320x240xtc mode with and without double-lines, speed difference is maybe 2%-3% (Videl don't read same lines again from st-ram but from its buffer)"

http://mikro.naprvyraz.sk/docs/mikro/videl.html

This is confusing. If you disable the double-lines on VGA, you effectively switches screen mode from 240p to 480p. And yes, there is really almost no difference in BUS speed between these modes.
There are more misleadning informations. Namely the 16MHz videobus myth. There is no such thing. Videl works also as a DRAM controller and it acts as a bridge between DRAM and the system BUS. The system BUS is indeed a 16MHz/16bit one, but between the Videl and the RAM is dedicated 32bit BUS that has no "MHz", because DRAM has no clock, only access time. Also the Videl uses burts for reading the VRAM data, which is also something different than 68k BUS cycle on the system BUS.

[Eero Tamminen]

I did some testing with latest BM version from devilsdoorbell and latest Hatari from Mercurial.

Doom II WAD works fine, but I think cache creation takes longer time and there's no music at all. Warnings it gives at startup are:
-------------
$ hatari-prg-args.sh --machine falcon --tos tos404.img -s 14 --conout 2 -- ./bm032.ttp -iwad doom2.wad
...
couldn't open bmt2.wad
numlumps: 2919

Could not locate entry in WAD: texture2
...
-------------

bm032_fast.ttp works fine with 030 Falcon emulation. With 040 and 060 Falcon emulation, it freezes at game start after statusbar is drawn, when game content is still to be drawn. This happens both with 16Mhz and 32Mhz 040/060 CPU emulation. Attached is a profile of what it's doing while it's frozen.

[dml]

I did some testing with latest BM version from devilsdoorbell and latest Hatari from Mercurial.

Doom II WAD works fine, but I think cache creation takes longer time and there's no music at all. Warnings it gives at startup are:
-------------
$ hatari-prg-args.sh --machine falcon --tos tos404.img -s 14 --conout 2 -- ./bm032.ttp -iwad doom2.wad
...
couldn't open bmt2.wad
numlumps: 2919

Could not locate entry in WAD: texture2

Beta doesn't work properly with Doom II, it assumes you're supplying DOOMU.WAD + BMT1.WAD.

It will probably run, kindof - if you supply a dummy BMT2.WAD, but I didn't do any work in that direction for this release.

Incidentally, all of the F30 music and SFX material is in BMT1.WAD That's why that bit doesn't work.

bm032_fast.ttp works fine with 030 Falcon emulation. With 040 and 060 Falcon emulation, it freezes at game start after statusbar is drawn, when game content is still to be drawn. This happens both with 16Mhz and 32Mhz 040/060 CPU emulation. Attached is a profile of what it's doing while it's frozen.

I forgot to build it with the 040/060 flag It just uses the cpu-clean flag, which means avoid 030 stuff. But it doesn't do the 060 stuff (like flushing caches after evil SMC)

[Eero Tamminen]

Beta doesn't work properly with Doom II, it assumes you're supplying DOOMU.WAD + BMT1.WAD.

It will probably run, kindof - if you supply a dummy BMT2.WAD, but I didn't do any work in that direction for this release.

Incidentally, all of the F30 music and SFX material is in BMT1.WAD That's why that bit doesn't work.

Although there's no music, Doom II seems to work otherwise fine without any BMT2.WAD. There are also at least some sound effects.

[dml]

Although there's no music, Doom II seems to work otherwise fine without any BMT2.WAD. There are also at least some sound effects.

Ok. On the plus side it means nothing really bad happened to DII while working on the DI release. But I was planning to handle a DII release separately (which is why it looks for a non-existent BMT2.WAD) so its probably best ignored for now unless people are desperate to play it.

[Zamuel_a]

Is it easy to make it work with Heretic and Hexen WAD files to in the future? I guess the levels are more complex so it wouldn't be so fast.

[dml]

Is it easy to make it work with Heretic and Hexen WAD files to in the future? I guess the levels are more complex so it wouldn't be so fast.

The version of the engine from the 90's could view Heretic/Hexen WADs so in theory yes it should still be able to do that. But it's a completely different game source base, so there is no 'quick' way to just make the games work. It involves similar work to that carried out with the Doom game code so far.

[nemodhs]

I was wondering, whether using a specific art style for maps could have a positive effect on performance.

Specifically, what if you created Noir-style (i.e. Sin City) maps? Would a greyscale version of the engine be significantly faster?

Or a comic styled map with textures that only have a handful of different colors?

Not that I have anything planned in particular already. Just curious.

[dml]

In terms of the textures - you do get a small speedup from using fewer colours in the source texture but its a small effect so I'm not sure that it's worth designing whole levels that way. I did some tests for 64 cols vs 256 cols per source texture and found a very small but consistent gain. I didn't try with 8 colours though

Most of the cost comes from geometry - particularly height differences between sectors.

In order of approx (descending) cost these are important in design:

- number of line-height-differences in view at any time (it is per line!)
- number of visible 'front walls' (lower/upper) from these height diffs
- number of state changes between sectors (light, texture)
- number of lines visible generally

Solid walls stop view-recursion - nothing happens behind them. Transparent midwalls or junctions require recursion through those holes which continues until something solid is encountered (or in BM, until the upper and lowers 'cross' or meet to block the view, like a door closing). This happens at a per-pixel-column level of accuracy. The engine will happily view-recurse through a gap one pixel wide.

I'll do a better writeup on performance design for BM levels on a separate page when I get a bit of time.

[EDIT]

BTW I can produce special builds for level builders, which show a metrics hud overlaid on the game window - it prints all the counts for textures, walls, sprites and details which affect performance. Can be handy for debugging slow areas. I used it to help optimize the engine but it can be used also for designing levels.

[shoggoth]

Played another level on my coffee break. It's a habit now. Damn hell demons though, they keep winning.

[dml]

Played another level on my coffee break. It's a habit now. Damn hell demons though, they keep winning.

Seems like some new levels might be needed just in case!

[Eero Tamminen]

bm032_fast.ttp works fine with 030 Falcon emulation. With 040 and 060 Falcon emulation, it freezes at game start after statusbar is drawn, when game content is still to be drawn. This happens both with 16Mhz and 32Mhz 040/060 CPU emulation. Attached is a profile of what it's doing while it's frozen.

I forgot to build it with the 040/060 flag It just uses the cpu-clean flag, which means avoid 030 stuff. But it doesn't do the 060 stuff (like flushing caches after evil SMC)

Could you do a new test-build with 040/060 flags which I could try in latest Hatari?

[dml]

Could you do a new test-build with 040/060 flags which I could try in latest Hatari?

Yes I can do that - although it might be better if I can spend a little time trying it myself in case something is wrong and is an obvious fix. If I can't get that time over the weekend I'll try to at least send you a build with the right flags.

[Eero Tamminen]

Could you do a new test-build with 040/060 flags which I could try in latest Hatari?

Yes I can do that - although it might be better if I can spend a little time trying it myself in case something is wrong and is an obvious fix. If I can't get that time over the weekend I'll try to at least send you a build with the right flags.

If it's less work to mail me the binary instead of trying to transfer it to real HW, just send it to me and we'll see who gets to test it first. On my part checking it with latest Hatari is no effort at all.

[nemodhs]

There is a new series of Let's Play videos with game developer commentaries up on the Double Fine YouTube channel.

A few days ago they posted a playthrough of some Doom levels with John Romero, where he shares some insights into his design process and philosophy. Quite interesting

https://www.youtube.com/playlist?list=P ... xNtfWZPm5W

[dml]

There is a new series of Let's Play videos with game developer commentaries up on the Double Fine YouTube channel.

A few days ago they posted a playthrough of some Doom levels with John Romero, where he shares some insights into his design process and philosophy. Quite interesting

https://www.youtube.com/playlist?list=P ... xNtfWZPm5W

Yeah I saw that playthrough a while back - it's interesting because he explains a lot about how the levels came into existence and why stuff was done. ...In between shouting >BOOM< as he is known to do while playing. Guess where that Doom port name came from

[dml]

BTW here's a newly re-optimized release of BM beta, for 16mhz machines. I'll redo binaries for other setups later if this one behaves itself.

https://dl.dropboxusercontent.com/u/129 ... doom33.zip

It's faster at dealing with all things involving spans and columns. I'm not sure exactly how much, but it seemed faster to me

[shoggoth]

Oh me like.

[Zamuel_a]

Could it be possible to run the Nintendo 64 DOOM levels? I always liked this version and since it's not as common as the regualr one, it would be more fun to play.

[dml]

Only if the maps are somehow converted to the PC map format. Usually the console versions use custom formats to optimize for space and other problems (The JagDoom maps I have tried were actually converted back to PC).

If the format turns out to be very close then its more practical. Somebody may even have done it already, as was done for JagDoom.

However there are a lot of PC Doom maps out there - a lot. It's probably better overall to get PWAD support improved so more of them will work correctly. i didn't do much in that direction (PWAD compatibility) since BM3.07, and there are still problems needing fixed.

[bullis1]

Could it be possible to run the Nintendo 64 DOOM levels? I always liked this version and since it's not as common as the regualr one, it would be more fun to play.

This isn't very likely. The Doom64 engine supports all kinds of things that aren't in the PC or BadMooD engine. These include 3D floors (bridges, floating sectors), room-over-room, lighting gradients, moving/transforming sectors, etc.

To dml's credit, the BadMooD engine supports some stuff similar to Doom64 (coloured lighting, shaders) and even some stuff that is more advanced

Someone could definitely make some approximations of Doom64 but the full experience is not possible. There are PC ports of Doom64 but they use custom extended engines.

[Zamuel_a]

I haven't played DOOM 64 in a long time so don't remember the differences, but maybe it's more a "Quake" game than a DOOM game.

[calimero]

Hi,
I am trying to run BadMood for last six hours :/
I have right doomu.wad (12,408,292 bytes like it is advised at http://devilsdoorbell.com/setup/)
I have 14MB, F030 mode, VGA monitor, CTRL clean boot...
I download http://devilsdoorbell.com/downloads/BMBETA01.zip
wait for 30 min. for BMC creation
and when I start BadMood
I see intro pic, hear music... for aprox. 5 sec. and when intro pic should
remove (my guess) I got white screen with error:

"Error: R_FlatNumForName: F_SKY1 not found"

what could go wrong? (I try twice entire process and I got same error)

[dml]

It reports that kind of error if it can't find an essential file in the WAD. It usually means the wrong WAD file. It can't be caused by any of the other data files being wrong, except perhaps for the executable itself. It is specifically a WAD directory scanning failure.

It can also mean the WAD file is truncated, corrupt, can't be opened/read reliably or otherwise faulty. This can happen if the file is not transferred or archived/de-archived properly. I would look at that before doing anything else.

(BTW check your PM soon for more info)