Bad Mood : Falcon030 'Doom'

[dml]

So I was having difficulty with 256 pixel display width because I was trying to use fat pixel mode (+overscan) instead, assuming that was part of the deal. But it just forces use of the faster dotclock and makes other problems.

Just reducing a normal 320 pixel display to 256 works ok.

However the 256 pixel mode looks square, whereas the 208 pixel mode is rectangular, at least on this monitor and without messing with borders or hsync. This provides some options to play with. I'll see how they compare re: bus load.

[dml]

While there are plenty of other things I could/should be doing next (especially 2D stuff), there's still a lingering performance problem in the BM renderer caused by frequent alternation between 3 stages of work - the CPU figuring out wall surfaces from the map, loading terms onto the DSP and then drawing those surfaces. The CPU cache misses incurred by this are avoidable and do become a drag when the wall count is high, especially if the walls don't use much area.

I'm going to try to fix this before doing anything else while I have the timing measurements in front of me. Separating out the three phases so they occur in blocks should help, and it will probably allow configurable batching (i.e. permit walls from more than one subsector to be buffered up to a configurable limit before committing to render - reducing occlusion test feedback efficiency but increases drawing pipeline efficiency - there will be a good balance point somewhere between the two).

I don't expect much improvement for simple scenes but it's likely to help in areas that get choppy due to dense scenery and sprite count. The nice thing about such a change is that it affects several areas at once (walls, transparencies, sprites). Many of the other waiting optimizations are very specific and while they do add up, not much gain expected from each individual change.

Rendering still isn't fast enough for good play at 256x168 so anything which can be done in this area is going to be useful.

[dml]

One other interesting optimization for 'choppy' areas of map affect texture uploads to the DSP for floors/ceilings. This gets quite expensive as the texture count rises because about 5k of texture/LCLUT data needs transmitted for each unique texture drawn and there can be many in view at once (It's typically around 4-6 but I have seen as many as 15 in some cases).

By determining the minz for each textured zone, it should be possible to predict the largest mip page needed for that texture state, and transmit only that (and smaller pages), with a nonlinear gain (any given mip page takes approx 3x the space of all remaining pages added together so removing even one page makes a big difference to transmit time - and the biggest pages are generally only needed for a few cm of floor area in front of the viewer - which is likely to be only 1 or 2 textures from the whole set required).

The pages are compressed in a funny way which will make this tricky but it should still be doable.

[shoggoth]

So I was having difficulty with 256 pixel display width because I was trying to use fat pixel mode (+overscan) instead, assuming that was part of the deal. But it just forces use of the faster dotclock and makes other problems.

It's possible to do that and get fairly similar display timings, I think. However, the 32MHz clock may in fact be anything from 32-50MHz on some motherboards... I think I have some C code which loads SCP files, if needed. It's based on trial & error but it seems to work; this means people could define their own screen mode. Let me know if you need it and I'll pastebin it or something.

[dml]

So I was having difficulty with 256 pixel display width because I was trying to use fat pixel mode (+overscan) instead, assuming that was part of the deal. But it just forces use of the faster dotclock and makes other problems.

It's possible to do that and get fairly similar display timings, I think. However, the 32MHz clock may in fact be anything from 32-50MHz on some motherboards... I think I have some C code which loads SCP files, if needed. It's based on trial & error but it seems to work; this means people could define their own screen mode. Let me know if you need it and I'll pastebin it or something.

That's not a bad idea. I'll need to think about what changes would be needed for un-fixing the display size. I was going to compile-in some fixed linewidth stuff (256 or 512-pixel lines) a part of existing optimizations but there could be a separate build without that, or using the larger linewidth to allow flexible (smaller) sizes.

Once I've reviewed what's needed I'll ping you and see if it can be bolted in Cheers.

The DSP memory will quickly exhaust for rendering windows much bigger than 320x200 but I doubt anyone will want to increase it beyond that on anything short of a '060 Falcon

[shoggoth]

If fixed display width makes a difference - I say stick to it. Users of accellerated machines can use other Doom implementations in such case, imo. Or a future DSP-less version of BadMood

[dml]

I stumbled on some interesting observations from John Carmack on performance issues while working on JagDoom:

"The problem is that Jag DOOM usually becomes speed limited by the
game logic, not by the rendering code. The problems of movement
clipping and line of sight calculation for all the monsters are more
difficult to run efficiently on the risc processors. The basic actor
logic is too bulky and spread out to run on one of the risc chips,
but it is really a bit too much for the 68k to handle when the
rendering is taking up most of the bus bandwidth."

This is basically what I found on the Falcon, having optimized the rendering side - the game code has these other problems which needs a lot of effort to work around when you have a slow CPU and a space- or access-restricted coprocessor arrangement. In a sense it's worse on the Jag for the CPU part but the GPU/DSP do at least have access to blitter, display and AI memory space and this makes a huge difference.

On the Falcon, the LOS testing is too heavy for the CPU but difficult to entirely DSP. The movement clipping I haven't modified yet but it does show in the profile for similar sorts of reasons. The AI is very large and distributed, random-access behaviour which caches poorly and spends a lot of time on the STRam bus.

So while the problems aren't identical they are caused by the same areas of code for similar reasons. The methods I've been using to suppress the costs are generally working but need more effort to make up for what is still a relatively heavy rendering overhead.

[dml]

Minor update on code...

Surface deferral pipeline is now properly implemented for all types of surface including sprites. Without sprites it doesn't speed things up much but there is a larger gain with sprites enabled.

Lighting information is now picked up from the gamestate instead of being faked up by BM, so when the lights get turned off in the game code they do actually go off at rendertime...

d1.png

d2.png

d3.png

Flickering lights also now respect surrounding light levels instead of occasionally strobing darker than the surrounding area - which always looked wrong in BM.

Some sprites and surfaces are supposed to glow ('fullbright') and this isn't implemented yet so fireballs can be shadowed and are invisible in a dark room. This will get fixed a bit later.

[EDIT]

Player muzzle flash is now also picked up by the lighting fx.

[dml]

If fixed display width makes a difference - I say stick to it. Users of accellerated machines can use other Doom implementations in such case, imo. Or a future DSP-less version of BadMood

It doesn't appear to make much difference on Hatari - have still to compare with a real box...

DSP-less version of BM. The codebase can be recompiled without the BM renderer (but display, keyboard etc still attached) and it will run - there are compile flags for that but it has the downside of being a bit slow on unmodified Falcons

[dml]

Another test release. This time using the same display resolution as JagDoom - 160x180 for the play area, 40 pixels left for status bar.

Other previously mentioned fixes/additions also included. Gamma/brightness has been raised a bit mainly to help with debugging lighting. This one is probably VGA only because of the video mode setup as I haven't done anything for RGB, but it's just an experiment - the final thing will work on both display types.

Note that demo replay won't work, so use '-warp x y' where x=episode y=map. e.g. '-warp 1 1' for e1m1. See earlier posts for more keys.

[Xerus]

Tested on RGB monitor and no problem with the display.
Your port is on the good way, continue the fight

[dml]

Tested on RGB monitor and no problem with the display.
Your port is on the good way, continue the fight

Cool I think I had set up RGB/VGA detect and different display config for each so RGB is probably running 320x180 - or something else unknown. So I guess it will be running a bit slower for now.

[dml]

@shoggoth

...while BM isn't ideally targeted at '060, it might be interesting to try it on a SuperVidel with some tweaks just for fun. I'm not sure that SCP loading will be enough for that (display address range needs changed?) but it sounds like it wouldn't be very difficult to add specific support?

Doing this would not increase the working rendersize limit of 320x200 but display writing should be cheaper and it would pave the way for a version using the native IDTECH renderer on 060 (i.e. no DSP).

[shoggoth]

@shoggoth

...while BM isn't ideally targeted at '060, it might be interesting to try it on a SuperVidel with some tweaks just for fun. I'm not sure that SCP loading will be enough for that (display address range needs changed?) but it sounds like it wouldn't be very difficult to add specific support?

Doing this would not increase the working rendersize limit of 320x200 but display writing should be cheaper and it would pave the way for a version using the native IDTECH renderer on 060 (i.e. no DSP).

Basically, there is a simple way to achieve that. You could do it the hard way; allocate VRAM, use a new modecode etc. Or you could just access the screen using an OR-mask on the screen pointer: *((uint16_t*)(screen_ptr | 0xA0000000UL)) = 42; (this means the screen is still allocated in STRAM, but accessed in the corresponsing snooped STRAM area in SuperVidel VRAM. All registers etc works like they allways did). There is even a hybrid mode which switches the standard VIDEL 8bpp planar mode -> chunky, while still keeping VIDEL register compatibility.

If you want to use fancy pancy high screen resolutions, you need to allocate VRAM (ct60_vmalloc()), and use SuperVidel-specific physbase pointers (32-bit). It changes the code a bit more, I guess.

I've experimented with misc. doom ports myself on the 060, and at one point I ported AmigaDoom. It runs really well on the 060. What makes BadMood fun is the renderer, and the enhancements you made. Without them, it's really very similar to any other doom port, isn't it?

[dml]

Basically, there is a simple way to achieve that. You could do it the hard way; allocate VRAM, use a new modecode etc. Or you could just access the screen using an OR-mask on the screen pointer: *((uint16_t*)(screen_ptr | 0xA0000000UL)) = 42;

Ok that's easy enough. I can add a new commandline arg to Doom which enables this, although somebody with a SV will need to test it and I expect there will be other problems with that (e.g. DSP texturing speed problems on 060)...

I've experimented with misc. doom ports myself on the 060, and at one point I ported AmigaDoom. It runs really well on the 060. What makes BadMood fun is the renderer, and the enhancements you made. Without them, it's really very similar to any other doom port, isn't it?

Yes not much point in porting the C version again. Removing the DSP dependency would be a challenge though at this late stage Easier to write in 68k or C of course, but still a lot of rewriting involved...

[dml]

Got the menus working over lunch, by some loose interpretation of 'working'.

menus.png

The 'patch' assets are loaded directly and drawn by Doom's C code instead of BM's cache - there's so much of that stuff scattered around the menus and status bar code that redoing it all is not very tempting - would take a lot of time. However I think it's fine where it is. It's easy to spot-optimize.

Doom uses 5 screenbuffers (!) for all of its 2D intermission screens, wipes, status bar, scratch space, dirty rectangle copies etc. I'm trying to do it with 2-and-a-bit (the 'bit' is the status bar buffer, 40 pixels high). Worse, 2 of them are being flipped and Doom isn't written for that - it expects each buffer to have fixed duty and there is plenty of code assuming buffer '1' is never visible and it is now...

...so some intermission screens currently strobe, as do bits of the status bar. I tried a few tricks to schedule rectangle copies so they reach both framebuffers (each event repeated on successive frames) and that works but some patches are drawn direct to the framebuffer and others to the status bar buffer and then copied, so there are still problems. It's going to take some time to fix all of that nonsense properly. I might even just limit double-buffering to the renderer window and disable it for the status bar with a TimerB or something. Might be simpler.

Fortunately the patches drawn on top of the play area do work properly and the status bar is on a very limited part of the display with a fixed starting line so it should be solvable.

Getting all of that to work with funny resolutions will be tricky. Draw directly scaled patches? Prepare different versions offline? Rescale and cache? Other? Still thinking about this one. Will try to fix it for 320x200 first.

The weapon overlays are going to be handled differently and probably need to be loaded and drawn by the BM engine, and the aim is to use the compiled sprite tech mentioned previously. Hopefully that stuff is less messy and easier to intercept than all the other 2D bits!

[shoggoth]

Basically, there is a simple way to achieve that. You could do it the hard way; allocate VRAM, use a new modecode etc. Or you could just access the screen using an OR-mask on the screen pointer: *((uint16_t*)(screen_ptr | 0xA0000000UL)) = 42;

Ok that's easy enough. I can add a new commandline arg to Doom which enables this, although somebody with a SV will need to test it and I expect there will be other problems with that (e.g. DSP texturing speed problems on 060)...

Just look for the 'SupV'-cookie. If it's there, you're on a SuperVidel. I'll test it for you when BM works on the 060

[shoggoth]

Another test release. This time using the same display resolution as JagDoom - 160x180 for the play area, 40 pixels left for status bar.

Holy cow, this was severely playable. If fixed display sizes doesn't matter much, I don't mind having the option to use this resolution as well. This is better than I expected. Played through a couple of levels, it is indeed playable++.

I noticed while playing that there may be a bug in the IKBD code (I noticed this in previous versions also). Basically, if you run (SHIFT) and turn a lot (Multiple arrow keys), it generates a faulty keypress (ESC). Mouse seems to be inverted vertically in this version.

EDIT: Personally I often default to IKBD code written by Patrice Mandin (he has a project called 'Cleancode' which is full of useful stuff).

[viking272]

Holy cow, this was severely playable. If fixed display sizes doesn't matter much, I don't mind having the option to use this resolution as well. This is better than I expected. Played through a couple of levels, it is indeed playable++.

I did wonder whether the smaller resolution would have an increase in FPS levels. Anyone able to post some stats?

Sent from my GT-I9300 using Tapatalk 4 Beta

[dml]

Holy cow, this was severely playable. If fixed display sizes doesn't matter much, I don't mind having the option to use this resolution as well. This is better than I expected. Played through a couple of levels, it is indeed playable++.

Having reviewed the res stuff a bit, user defined modes should be fine for the display and 3D renderer - the status bar and menus are more of a problem because of the assets to be drawn.

I think it makes sense to have a few builtin modes based on 320x200 (double-line on vga, with optional fat pixels, normal low res on rgb with optional double-line) and then have user-definable fullscreen modes with no status bar, allowing any resolution within limits. This way the 2D assets don't need a lot of effort to adapt for new modes, and it's probably not too difficult to have splitscreen res for status bar.

I noticed while playing that there may be a bug in the IKBD code (I noticed this in previous versions also). Basically, if you run (SHIFT) and turn a lot (Multiple arrow keys), it generates a faulty keypress (ESC). Mouse seems to be inverted vertically in this version.
EDIT: Personally I often default to IKBD code written by Patrice Mandin (he has a project called 'Cleancode' which is full of useful stuff).

I have also noticed some problems with key combinations. I haven't really spent any time looking at the BM keyboard code other than collecting the events and handling them in the Doom code. When I get a chance to look closer I'll see if it's a trivial fix - otherwise I'll consider swapping it for PM's stuff.

[dml]

I did wonder whether the smaller resolution would have an increase in FPS levels. Anyone able to post some stats?

With the modified AI it's possible to get decent framerates by shrinking the window. Without the AI mods the framerate gets capped quite heavily by the game.

Unfortunately I disabled the FPS counter on that one for a clean display (I should have just defaulted it to off and left the toggle in).

[dml]

Status bar and intermission screens are now mostly working, but I had to turn off player messages for now (e.g. "you got the armor" because it was causing severe slowdown and I haven't had time to investigate properly.

The status bar is also sucking quite a bit of time with dumb dirty rectangle copies much bigger than needed (nearly the whole status bar every frame ?!) so it needs redone. Will try something else for that before posting a version with working 2D.

[Eero Tamminen]

Unfortunately I disabled the FPS counter on that one for a clean display (I should have just defaulted it to off and left the toggle in).

Profiler can tell. You can e.g. profile 100 frames:

Code: Select all

  profile on
  b pc=r_begin :100

And then just calculate from the time shown by profile for 100 frames, the average FPS value for them:

Code: Select all

  e <time>/100

To get comparable values, one would really need to start profiling from the same point though...

[Eero Tamminen]

Status bar and intermission screens are now mostly working, but I had to turn off player messages for now (e.g. "you got the armor" because it was causing severe slowdown and I haven't had time to investigate properly.

Could you commit them to HG?

From the current code in HG, I can see that on the first LineAttack call (in Doom1), some sprites are still loaded through this path:

Code: Select all

- 0x2fc88: _P_LineAttack (return = 0xffffffff)
- 0x22662: _D_Display (return = 0x22ac6)
- 0x1f07c: _I_FinishUpdate (return = 0x2290a)
- 0x434c8: _BM_R_DrawScene (return = 0x1f0a6)
- 0x48fb0: display_engine (return = 0x434fc)
- 0x4b010: render_transparent (return = 0x49162)
- 0x48658: cache_resource (return = 0x4b058)
- 0x48f1c: load_sprite (return = 0x4875e)
- 0x45eda: read_resource (return = 0x48f56)

The reads and their sizes are:

Code: Select all

GEMDOS 0x3F Fread(65, 144, 0x18d0b0)
GEMDOS 0x3F Fread(65, 320, 0x18d0b0)
GEMDOS 0x3F Fread(65, 320, 0x18d0b0)
GEMDOS 0x3F Fread(65, 1316, 0x18d0b0)
GEMDOS 0x3F Fread(65, 1624, 0x18d0b0)
GEMDOS 0x3F Fread(65, 2064, 0x18d0b0)

render_transparent + load_sprite -> transparent sprites? (data amounts are pretty small though)

[dml]

Could you commit them to HG?

It's probably in a state now where I can do that. I'll review the changes and put them in. I'll add a define around the player messages bit. However it does imply being stuck with a 320x168+40 display (the window can now be shrunk with +/-) since no other mode works with status bar and menus yet.

I suspect the slowdown is a combination of very slow patch-based character drawing and unnecessary backbuffer blits. I figured it wasn't worth spending a lot of time on trying to fix now (esp. with audio, weapons etc. missing) but can be visited later, maybe with Laurent's compiled sprites for the font characters.

I don't remember ever needing those messages in the game, although they can be amusing in network play.

From the current code in HG, I can see that on the first LineAttack call (in Doom1), some sprites are still loaded through this path:

Code: Select all

- 0x2fc88: _P_LineAttack (return = 0xffffffff)
- 0x22662: _D_Display (return = 0x22ac6)
- 0x1f07c: _I_FinishUpdate (return = 0x2290a)
- 0x434c8: _BM_R_DrawScene (return = 0x1f0a6)
- 0x48fb0: display_engine (return = 0x434fc)
- 0x4b010: render_transparent (return = 0x49162)
- 0x48658: cache_resource (return = 0x4b058)
- 0x48f1c: load_sprite (return = 0x4875e)
- 0x45eda: read_resource (return = 0x48f56)

render_transparent + load_sprite -> transparent sprites? (data amounts are pretty small though)

Interesting that Doom doesn't report these as needing precached (I'm relying on Doom now to say which things are needed on a level). They may just be special cases that went under the radar and don't upset a PC. Could be a bit more noticeable with a Falcon's disk interface.

All sprites are 'transparent' wall surfaces - in fact masked would be a better term. There is no real transparency as such. Not yet anyway