Bad Mood : Falcon030 'Doom'

[dml]

Great! Thanks for the feedback guys

[dml]

Doug can correct me but I think you need just the 08 Dec and now the 05 Jan releases to be on the latest v0.32 of the engine. (i.e. the 11 Dec patch isn't needed)

Yeah, you need the last 'big' archive with all the files in it, and recommend the latest v0.32 .ttp to replace the old one in the archive. You also need the v1.9 Ultimate Doom WAD file described earlier, and it must be renamed to DOOMU.WAD before placing it in the BADMOOD dir with the other files.

If you have already run the game once with the wrong WAD, I also recommend deleting the BMC directory which gets autogenerated as a cache, although it should replace this itself automatically anyway if its behaving itself.

[nemodhs]

Out of curiosity I started dabbling a bit with Doom Builder. So I created a super basic map and saved it into the BMT1.WAD, just to see how things work.

Bad Mood played the map just fine, after 30 minutes, as BM decided to completely rebuilt the WAD cache including all the music tracks. And whenever I made the smallest change to the map and saved it to BMT1, Bad Mood would of course again rebuild the cache. Is there a way - a command line parameter or something - to force Bad Mood not to rebuild the cache, or rather not convert all the music tracks again and again?

I'm also really looking forward to toy around with some custom true color textures. I've set up Doom Builder to load them from a folder which is easy enough. But how would I get them into the WAD file? And are there things to keep in mind / recommendations regarding texture sizes and number of textures per map?

[dml]

Out of curiosity I started dabbling a bit with Doom Builder. So I created a super basic map and saved it into the BMT1.WAD, just to see how things work.

Bad Mood played the map just fine, after 30 minutes, as BM decided to completely rebuilt the WAD cache including all the music tracks. And whenever I made the smallest change to the map and saved it to BMT1, Bad Mood would of course again rebuild the cache. Is there a way - a command line parameter or something - to force Bad Mood not to rebuild the cache, or rather not convert all the music tracks again and again?

I'm also really looking forward to toy around with some custom true color textures. I've set up Doom Builder to load them from a folder which is easy enough. But how would I get them into the WAD file? And are there things to keep in mind / recommendations regarding texture sizes and number of textures per map?

Gah - yes that will get annoying pretty fast. It will invalidate the cache when the WAD files change, and force a full rebuild. This was mainly to avoid accidents when loading PWADs which replace textures, and other stuff. But it is a nightmare for edit/test turnaround.

You can launch BM with the following additional arguments, to get around that:

'-bmcl' cleans the cache (like changing the WAD)
'-bmup' updates the cache by doing a quick scan, filling only no entries which have been added. it will also rewrite the VERSION stamp file so subsequent runs will think the cache is good.
'-bmnu' will launch BM without checking the cache, it will just use whatever is there. This is probably the best option for edit/test turnaround. You can force indlvidual files (like textures) to be rebuilt manually by just deleting them from the BMC folder by hand. This is what I normally do.

I'll be looking at this stuff again to make it a bit less hassle but hopefully that will un-stick you for now.


As for adding completely new TC textures - the primary method is to just place 8bit versions of the graphic patches into the PWAD so plain DOS Doom could use them, but to supply 'overload' versions of the same patches as .BMP format in the HD directory of BadMooD. (It will prefer the BMP versions if present).
This allows you to replace individual patches - the source graphic blobs from which textures are comprised. Textures are actually composite combinations of lists of these patches with position,offset info - some using just a single patch and some use many (like a wall texture with a switch on it). You can use SLADE to edit and create new textures from patches, but it's a fairly high-hassle way to do things in some cases. Patches were mainly used to reduce memory usage in the old Doom but doesn't really help BM much at all.

The 'new' way I introduced was to create texture entries with no patches assigned to them. This will force the BM engine to look for the TC .BMP file with the same name as the texture, shortcutting the patch stuff. Of course in this case you have to provide the whole complete texture complete with switch etc. if required. It's also not possible to preview such textures in DoomBuilder so keep that in mind. I use this method for replacing existing ID textures with new TC replacements, rather than adding completely new ones for that reason.

When I get a bit more time free I'll give an example of both of these cases and when you might use each one.


....texture counts, limits etc.

There isn't really a limit on the number but its more likely to page stuff from disk more often if you use a lot of texture real-estate So try not to go crazy with unique textures everywhere. Reuse is important. The cost is in the final texture (surface cache), not the patches used to compose them, so don't try to save memory by making lots of textures using the same patches in different positions.

Same goes for floor textures. I recently made changes which lift restrictions on floor texture count so it doesnt drag performance so much, but try to keep it within 4-6 visible floor & ceiling textures at any time for best performance. Going over that won't be too bad but having 12+ in the view will make a noticeable difference.

Keep to Doom texture size limits - 256 wide max, by 128 high max. Big textures cost a lot obviously, especially if they aren't reused a lot.

Only textures which are 128 pixels high will 'tile' vertically. So if you have a wall > 128 units high, or vertically offset to scroll more than that, you need to use a 128-high texture. Otherwise you'll get glitches.

Transparent textures have their own rules. You can't replace them yet with TC versions but i will add that at some point. For now just use them as Doom did. Alway use single-patch textures for transparency. This is a Doom restriction. A performance tip is to avoid multiple pixel runs per texture column. There is a fixed cost for skipping over transparent pixels vertically - it's quite a low cost for an outline, but rises sharply if you have tons of holes everywhere, especially if many holes are vertically stacked. I doubt this will cause any real issues but could do if you make a level with lots of transparencies at depth. Designing the transparency itself will matter in the cost.

There is a texture pegging problem for transparencies which can cause them to be invisible in BM until one of the texture peg flags is set in DoomBuilder and the position scrolled vertically to put them in the right place - then it will match DoomBuilder. This is a bug of mine, to be fixed. Mostly it doesn't get in the way so long as you know it exists

[nemodhs]

You can launch BM with the following additional arguments, to get around that:

That did the trick. Thanks!

As for adding completely new TC textures - the primary method is to just place 8bit versions of the graphic patches into the PWAD so plain DOS Doom could use them, but to supply 'overload' versions of the same patches as .BMP format in the HD directory of BadMooD. (It will prefer the BMP versions if present).

OK thanks. I plan to use completely new textures without any original Doom stuff left in the maps, so I will take this route first.

When I get a bit more time free I'll give an example of both of these cases and when you might use each one.

That would be great.

....texture counts, limits etc.

Again thanks for the detailed explanation. It's good to know where to look when optimizing the performance of a map or when something glitches.

[CiH]

Just to add one more to the good news pile:

The Fast CPU version of the 0.32 executable is happy and sweet with my crappy Mac version of Hatari. This augers well for anyone with a non-standard accelerated Falcon

[dml]

Just to add one more to the good news pile:

The Fast CPU version of the 0.32 executable is happy and sweet with my crappy Mac version of Hatari. This augers well for anyone with a non-standard accelerated Falcon

Do you mean Hatari in 'accelerated' mode i.e. 32mhz and 040/060 modes? The 'Fast CPU' version is for Falcons that have funny (high) MHz ratings for the CPU side, particularly very fast CPUs or machines with FastRAM.

This build also runs much, much slower than the other builds on a stock machine because it shuts off a stack of dangerous optimizations.

[EDIT] I'm also not sure it even works yet on real 060s I still need to try out the new Hatari which actually implements 060 stuff for real - that may be a good guide!

[CiH]

Do you mean Hatari in 'accelerated' mode i.e. 32mhz and 040/060 modes? The 'Fast CPU' version is for Falcons that have funny (high) MHz ratings for the CPU side, particularly very fast CPUs or machines with FastRAM.

Erm, here's where it gets boring again. Emulated 030 and 040 are fine, as long as my Hatari is throttled down to 16 Mhz. Setting either to 32 MHz gets you into the menu screens, but freezes when going into the game itself.

However, my Hatari build is a pretty poor Falcon version, I daresay the WinUAE core version is a lot better, but I've never got that one to work. so I would not consider this in any way a general trend, or anything you need to specifically worry about.

[dml]

For anyone interested in making/editing levels for BM, I have started a page on the main site about this.

http://devilsdoorbell.com/level-editing/

It digest some of the stuff written above, but will probably need to be broken down further as I add more and more stuff.

It's not really much different from normal Doom editing and it's hard to describe some of the weirdness involved with that - but I'm trying to put down enough that you can compare with other Doom editing guides and make sense of it. Plus adding on the BM-specific bits so they make sense in context.

Something like that

Anyway its barely started so worth checking back from time to time as I add material and details on the extra features, limits/metrics, effects etc.

[UPDATED]

[dml]

Erm, here's where it gets boring again. Emulated 030 and 040 are fine, as long as my Hatari is throttled down to 16 Mhz. Setting either to 32 MHz gets you into the menu screens, but freezes when going into the game itself.

Is that true for the 'fast CPU' version too? I'd expect that from the other versions but the 'fast' version should be ok with different MHz settings.

I should check this next chance I get, may be something simple.

[CiH]

Is that true for the 'fast CPU' version too? I'd expect that from the other versions but the 'fast' version should be ok with different MHz settings.

Yes, the game screen starts to appear in the middle of the menu screen to replace it, then it stops. After a minute or so of non-activity, the game crashes (vertical bluey-green lines).

The non-accelerated executable works fine on my shonky Hatari setup at 16 MHz, for your information.

[ctirad]

Just a note. I don't know anything about Hatari internals, but on a real F030 machine the onboard CPU has to run at the lower or the same frequency as the DSP, otherwise the DSP<>CPU transfers are not functional.

[dml]

The level editing guide has been reworked/updated again to clarify differences between classic Doom and BM editing.

[dml]

I think the 'fast CPU' build was not built correctly to work on 040/060 - I did use the cpu-clean settings so it doesn't do any 030-specific stuff or depend on DSP timings, but I didn't enable 060 mode so it flushes the caches at the right time and uses CPU exclusively for floor texturing. The 040/060 version really needs a separate build with these settings.

I'll try to correct this situation once I get the new Hatari and a bit of time to play.

[dml]

Added a very very basic guide to using DoomBuilder on the site. Still it may have errors or inconsistencies and doesn't replace the official guides!

At the very least it should be enough to play with it and do a first experiment. I wrote it from memory so if something seems to be wrong, let me know and I'll make the correction.

[nemodhs]

Thanks Doug!

Tons of useful information. Looks like I have a lot to learn about Doom level design.

[EvilFranky]

Is it worth bothering with a VGA 50hz version? Would it help the framerate on VGA by dropping from 60 to 50hz?

It's not hugely common, but my NEC TFT does 50hz nicely...maybe something that could be configured with a switch.

[dml]

Is it worth bothering with a VGA 50hz version? Would it help the framerate on VGA by dropping from 60 to 50hz?

It's not hugely common, but my NEC TFT does 50hz nicely...maybe something that could be configured with a switch.

It actually started out at 50hz but I had to keep raising it to cope with more and more monitors, and I think it's still breaking a small number of monitors at 58hz - so I may already need to do a 60 or 70hz version :-z

It could be put on a switch but its a bit more work to incorporate multiple versions of each mode, because the game already uses several modes for different events. A more flexible way is to read the modes as SCP files and just let people adjust them for their own monitor in ScreensPain, as PeP suggested a while ago. Some common defaults could then be bundled.

[EvilFranky]

Cool, just something I thought about last night.

[Zamuel_a]

I haven't tried it on an RGB monitor yet (have no cable for it) so only VGA. Which monitor will give the best performance?

[EvilFranky]

RGB...uses less BUS bandwidth I believe.

[Zamuel_a]

RGB...uses less BUS bandwidth I believe.

Ok. Need to build an RGB cable so I can try it.

[EvilFranky]

Yep! I'm sure its something to do with the clock rate of the VIDEL in RGB mode being lower...

[dml]

It's depends - the VGA version can run faster in fullscreen for example than the RGB version because of the different video capabilities (fat columns in hardware, using F5 key). Fat scanlines (RGB, F4 key) look worse, so VGA is a bit better for fullscreen play.

For windowed play, probably RGB. But below around 70% window size the monitor type has less and less impact on speed.

[ctirad]

It actually started out at 50hz but I had to keep raising it to cope with more and more monitors, and I think it's still breaking a small number of monitors at 58hz - so I may already need to do a 60 or 70hz version :-z

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.