Bad Mood : Falcon030 'Doom'

[dml]

Eero, new code for SFX is now merged and available.

I'm going to return to 2D/hud stuff for a while to see if that can be tidied up and made quicker, and try to put the compiled sprite system in for the weapons if possible.

[dml]

Here's an early, early, early beta of Doom on F030 with menus, weapons and sound roughly working - and so far without much of the Atari addons visible. Just the basic version.

You'll need to shrink the screen to about half size or less with '-/+' keys as it's too slow at full size and this build is noticably slower than the previous build because of all the extra stuff that was crammed in recently without being optimized... each thing which gets turned on in the game code just hurts the poor CPU so it all needs a few more passes and effort.... the menu is particularly slow just now.

Sound does have volume control but it's not connected up so everything happens at max volume (ouch) until I fix that. Same goes for left/right panning - its fixed at centre for now.

There's still a bug in the keyboard input which causes the help screen or menu to appear at bad times when holding several keys at once. While this isn't high on my list it will get fixed before it's done.

[EvilFranky]

Haha! It rocks!

Can't quite believe it. I got it running on Hatari 1.7.0 and the progress is bloody brilliant.

Cursor keys didn't work, so I ran round the first level using the trackpad on my laptop which was ermm, interesting!

Managed to blow up a couple of barrels and then kill the first 2 bad guys...all with sound! It was joyful

And to think it's only going to get better

[dml]

Haha! It rocks!

Can't quite believe it. I got it running on Hatari 1.7.0 and the progress is bloody brilliant.

Cursor keys didn't work, so I ran round the first level using the trackpad on my laptop which was ermm, interesting!

Managed to blow up a couple of barrels and then kill the first 2 bad guys...all with sound! It was joyful

And to think it's only going to get better

Cool - I'm just glad it worked at all. I didn't get time to run it on a proper box, it was hot out of Hatari's GEMDOS filesystem

[dml]

Cursor keys didn't work, so I ran round the first level using the trackpad on my laptop which was ermm, interesting!

That *might* be a Hatari keyboard config thing. There are a few modes - try changing them (scancode, symbolic etc?).

Cursors should work ...although I always preferred custom keys for Doom/Quaking - ASDW to run/strafe, mouse to 'look' and shoot... and 'wild' fingers for other stuff

[EvilFranky]

I'm waiting for some additional power point getting installed in my spare/computer/guest room before the Falcon can actually be set up...on a more permanent basis.

God knows what people will think when they come round, see an ancient computer next to all my modern stuff. How do I explain that's it's worth more money than any single other item in there?

[EvilFranky]

Cursor keys didn't work, so I ran round the first level using the trackpad on my laptop which was ermm, interesting!

That *might* be a Hatari keyboard config thing. There are a few modes - try changing them (scancode, symbolic etc?).

Cursors should work ...although I always preferred custom keys for Doom/Quaking - ASDW to run/strafe, mouse to 'look' and shoot... and 'wild' fingers for other stuff

Tried switching about but that didn't work, so plenty of my own finger gestures ensued

[dml]

Tried switching about but that didn't work, so plenty of my own finger gestures ensued

Ok I'll grab Hatari 1.7 soon and see if there's a problem with that. Works fine here in 1.6.2

[dml]

Quick update from tests + coffee session this morning:

On profiling the new version with sound, it seems a bunch of new game code performance issues are again right at the top of the list.

I did some tests running around in 'nightmare' difficulty mode with the chaingun running most of the time.

To my surprise, the profiler appears to show a tiny function P_RecursiveSound is taking more cycles than rendering the scene, or any other task. All that function does is propagate echoes around the map for monsters to hear them and wake up.

(Eero - I only noticed this when the %used cycles in the first column didn't sum up to 100%, and the 3rd column showed 39% for that function - which I assume is a side effect of recursion and self-time vs graph time?)

Code: Select all

Used cycles:
  10.88%                   124999228                       render_wall_1x1    <- optimize a bit more
   9.52%   9.52%   9.54%   109345236 109372536 109650492   _audio_mux_frame      <- easily optimized
   6.16%   6.19%   6.88%    70767268  71138492  79040588   stream_texture   <- not much to do here
   6.03%   6.06%   6.67%    69275816  69613636  76598664   _memmove   <- status bar, to kill
   5.72%   5.75%   8.36%    65693492  66028324  96030524   _V_DrawPatch   <- status bar/weaps, to optimize
   5.65%   5.67%   5.91%    64879440  65182932  67887064   _R_InitTextureMapping   <- ????? not mine, investigate
   4.19%                    48172244                       R_VisPlaneShader   <- not much to do here
   3.24%   3.26%  12.60%    37250768  37437352 144753264   _P_MobjThinker   <- hmmm
   2.91%   2.86%  39.41%    33400140  32908560 452757900 * _P_RecursiveSound   <- .....whoah! 40% of total?

There were some obvious problems with the C code for this - calling some out-of-line map utility functions which the compiler couldn't optimize properly. I fixed those but it's still a candidate for ASM and probably capping recursion depth somehow. It doesn't do anything complicated, it just seems to be used without any bounds or limits and is probably VERY sensitive to map complexity and open-plan scenes.

I don't think it's too big a deal if a sound is made to die off after traversing through too many sectors or too much (approx) distance. The only real problem this would cause is PC-recorded demo desync and we're beyond that point for many other reasons.

I'll also take a look at JagDoom to see if they had to do anything special with P_RecursiveSound.

The audio mixer is taking up to 10% CPU when things get really busy with the chaingun or plasma rifle, which is too much for comfort. This isn't optimized yet (not even unrolled the code - not had time) so it should be easy to squash the cost down. DSP mixing is still an option if it can be made friendly with rendering.

That's all for today probably.

[EDIT]

Turns out R_InitTextureMapping is just a precalc/table generator Doom sets up every time the viewport is resized, and can be ignored. Can probably be removed completely.

[dml]

Ok so there's a bit more to it after all...

Beginning to think there's a bug in P_RecursiveSound, so it's visiting the same sectors more than once per audio event and waking up monsters many times over. It has some nasty logic to implement Doom's 'it takes 2 soundblocking linedefs to actually stop a sound' rule and I'm not sure it's working properly.

It attempts to shortcut a sound's propagation through a sector if the sector has already been visited by that sound event AND has been visited before on that level (by any sound) at a lower blocking threshold (to apply the 2-threshold rule). It uses state recorded in each sector to track this, but I don't see where that state gets initialized. That can't be good.

The sector state does not get reset at any point until the next level is loaded, I assume that's because once monsters are surprised by a sound in any sector there's no point in waking them up again. I thought monsters could go back to sleep but maybe that's wrong...

Been scratching my head a bit on this one over lunch - going to take out the 2-level rule / state part to see what happens...

...lo and behold, one edit later the function is gone from the profiling list. Nowhere to be seen...

Code: Select all

Used cycles:
  11.76%                    80344560                       render_wall_1x1
  11.36%  11.38%  11.41%    77612940  77686204  77922892   _audio_mux_frame
   7.93%   7.97%   8.86%    54167976  54442544  60494256   stream_texture
   6.56%   6.59%   7.37%    44798904  45028160  50359956   _memmove
   6.02%   6.05%   9.01%    41137772  41316912  61561992   _V_DrawPatch
   3.91%                    26714352                       R_VisPlaneShader
   3.44%   3.46%  15.21%    23487988  23601540 103850048   _P_MobjThinker
   2.86%   2.87%   3.39%    19510540  19610360  23175300   _P_PointOnDivlineSide
   2.29%   2.30%   2.72%    15640940  15724912  18549784   _R_PointInSubsector
   1.83%   1.84%   8.71%    12522952  12579448  59475300   _P_BlockLinesIterator
   1.72%   1.73%   5.61%    11728676  11796140  38311956   _PIT_AddLineIntercepts

It looks like the game is probably relying on Z_Malloc clearing memory before initializing sector structures (!!!). That's probably causing this bug, and maybe some others too. Good that I spotted it now

[EDIT]

Figured out what was really going on. Short version is: the code was correct but overzealous and has now been modified to limit audio propagation events to once per second per sector (there's no need to wake up monsters more often than that - the conditions for them going back to sleep or getting distracted are complex and changes here are not very impactive on gameplay). This lets the game work normally but the cost isn't visible.

[dml]

Now I'm scratching my head over this problem which causes the HELP screen (F1) to appear sometimes in the middle of a fight when you hold down multiple arrow keys plus LSHIFT...

This seems to be a scancode ($3B or $BB) returned directly by the IKBD port fffc02 and I can't find any documentation explaining why this might happen, assuming it's not picking up mouse or midi packets etc. as keyboard packets (which I'm pretty sure it's not - the mouse isn't even plugged in).

There are some 'fake shift' multi-byte scancode patterns produced on PCs keyboards to extend keyboards outside the normal scancode set but I don't think that should be happening on Atari.

The problem also doesn't seem to happen inside Hatari - only on my real F030 (Or at least, it happens frequently on the F030 and I couldn't reproduce it when I tried in Hatari). I don't know if this means its not happening, or a different scancode is being returned for the same strange case, which happens not to be F1/helpscreen.

I tried rewriting the IKBD handler to deal with all the corner cases for midi, joysticks etc. and also tried patching in Patrice's 'cleancode' version (which looks a lot like the one I'm using, but seems not to check some of the IKBDCTL error bits?) and exactly the same thing is happening. I can catch the code at the lowest level of the 68k handler so I know it's not anything downstream from that.

Is this maybe some sort of IKBD error response to too many keys being held at once, and I just happen to have the same unfortunate $3B/$BB code mapped to the help screen, making it especially annoying?

Any input welcome - no pun intended.

[Eero Tamminen]

Eero - I only noticed this when the %used cycles in the first column didn't sum up to 100%, and the 3rd column showed 39% for that function - which I assume is a side effect of recursion and self-time vs graph time?

Most likely yes, I haven't been able to track the recursion miscalculation issue down. There's never been simple enough recursion example that what happens could be tracked from the profile disassembly data (e.g. thinker stuff in Doom recurses through multiple levels and different functions).

[dml]

The aspect ratio has been corrected so the view is identical to PC Doom at 168 lines. It was too short / vertically squashed before. Now it matches 1:1 with a PC screenshot at e1m1 startpoint. Gamma and shading curves are still wrong but I'll look at that another time.

The weapons now also draw in the correct place.

There has been a bug in the DSP code for a while now since the new floor renderer was done, which breaks texturing for small window sizes due to a scaling overflow. This has now got worse so I'll need to fix that too. Otherwise it's beginning to look mostly tidy except for some sprite glitches and intermission screen backbuffer problems.

Overall the framerate has dropped from the BMVIEW timings by ~2fps or so for a fullsize view but proportionally more for a reduced window size. It needs more effort.

F030 Doom

dooma2.png

DOS Doom

dooma1.png

[EvilFranky]

Looks miles better than the PC version. It's obvious how much a 16-bit screen makes a difference.

Sent from my Nexus 4 using Tapatalk 2

[dma]

Ah, it seems i need a FPU...
Would it run on RGB output then?

[dml]

Ah, it seems i need a FPU...
Would it run on RGB output then?

I'll take a look tomorrow and see if the remaining FPU code can be taken out, and repost a new build. It shouldn't really be needed.

It should run on RGB or VGA yes. I checked it the other day on a real F030 on a TV.

[dma]

Ah if it's not too much work for now, that would be super. Thanks in advance!

[kristjanga]

will the final version have fpu version or does fpu not make the BM run faster at all?
p.s best falcon thread ever

[dml]

Hi!

will the final version have fpu version or does fpu not make the BM run faster at all?
p.s best falcon thread ever

Currently I haven't found a use for FPU that makes it valuable in BadMood. I haven't really spent enough time on that area but will look at it when the CPU side settles down and there is no more DSP work left to do.

FPU is very good at precision calcs for minimal instruction fetching (e.g. something needing precise multiplies or overlapping divides that is struggling to cache well). The DSP can also do this in a lot of cases but means adding significant code for each case.


BadMood won't need an FPU to run. There may be a build which uses it but only as an alternative and only if there is some gain.

[dml]

Removing FPU support isn't as easy as I thought - apparently the MiNTlib package I'm using with GCC assumes FPU if you generate code for 68020 or higher - it detects and rejects missing FPU on startup and bypassing this test just leads to crashes inside MiNTlib's fileio (trying to use the FPU).

So I'll probably have to obtain and rebuild MiNTlib for pure 68020 minus FPU and work with that instead...

[shoggoth]

Tried the latest beta! Progress is amazing

I noticed some stuff though:
- keyboard still have a funny habit of displaying the help screen every now and then
- it's a bit slower (obviously)
- random pixels / graphics corruption in some textures here and there, it seemed to build up over time (not 100% sure though).

So I'll probably have to obtain and rebuild MiNTlib for pure 68020 minus FPU and work with that instead...

Do you really need mintlib, or could you do without it? It shaves off some 100k + you make the build process more failsafe/easy for other people.

[dml]

Tried the latest beta! Progress is amazing

I noticed some stuff though:
- keyboard still have a funny habit of displaying the help screen every now and then

Yes I tried to fix this but it has me stumped (there's a recent post here about it although I didn't really conclude anything). Will have another look next week. At the very least I'll remap the help screen so it doesn't get in the way while I figure out what's wrong.

- it's a bit slower (obviously)

Fortunately this is something I think can still be improved in a lot of areas and I'll probably spend a quiet couple of weeks just working on that one alone.

- random pixels / graphics corruption in some textures here and there, it seemed to build up over time (not 100% sure though).

That's something I hadn't noticed. Does it happen on walls or floors? Or both? This might offer a clue.

I'll keep an eye on it as I test other stuff.

Do you really need mintlib, or could you do without it? It shaves off some 100k + you make the build process more failsafe/easy for other people.

TBH I don't know the answer to this one - I'd like to get rid of it as many of the operations are very slow, especially fileio under TOS.

BMEngine doesn't use it at all, but the game code is a port of LinuxDoom which is a posix project, and there are various things scattered around which would need replaced. It might be worth doing though just for the file access speedup.

[Eero Tamminen]

BMEngine doesn't use it at all, but the game code is a port of LinuxDoom which is a posix project, and there are various things scattered around which would need replaced. It might be worth doing though just for the file access speedup.

There's libcmini project for making GCC library that does less than MiNTlib:
http://www.atari-forum.com/viewtopic.php?f=70&t=25192

Using that would add extra build dep for Doom, but it might fix the issue more easily that replacing libc calls with TOS calls...

[dml]

Thanks, looks like I have a few options now.

Just for fun, here's a trace of the last bunch of symbols encountered before the FPU is hit deep in MiNTlib. Since it doesn't hit any symbols from the game code during that process, it looks like it's all happening within fprintf() or fstat(). The game code does call fstat() from two places. Most of the other symbols are probably reached via fprintf.

Anyway I'm going to try relinking with the 68k libs (as suggested on the MiNT mailing list) to see if this can be avoided without code changes and will look at removing MiNTlib separately.

Code: Select all

_vfprintf:
___internal_flockfile:
_fwrite:
___stdio_check_offset:
___stdio_check_funcs:
_memcpy:
_fwrite:
___stdio_check_offset:
___stdio_check_funcs:
_fwrite:
___stdio_check_offset:
___stdio_check_funcs:
_fwrite:
___stdio_check_offset:
___stdio_check_funcs:
_fwrite:
___stdio_check_offset:
___stdio_check_funcs:
_memcpy:
___internal_funlockfile:
_puts:
_fputs:
_strlen:
_fwrite:
___flshfp:
___stdio_check_funcs:
___stdio_text_write:
___fstat:
___do_fstat:
___sys_fstat:
__bzero:
___isatty:
___time:
___gettimeofday:
_mktime:
_tzset:
_getenv:
_strlen:
_strncmp:
_tzsetwall:
___calloc:
___malloc:
___sbrk:
__bzero:
___calloc:
___malloc:
___sbrk:
___calloc:
___malloc:
___sbrk:
_strlen:
___calloc:
___malloc:
___sbrk:
_memcpy:
_strncpy:
___strchr:
___strchr:
___strchr:
___strchr:
_strlen:
B-Trap f23c at 7137a (0x9e9afa)
1. CPU breakpoint condition(s) matched 7 times.
        pc = ( $8 )

[dml]

@dma...

...this version should work without FPU. It seems ok here in Hatari with FPU disabled.

I think it may be running a little slower due to relinking with 68000 libraries to make this work but even so that will be a temporary situation - and the effect isn't big enough to cause a serious problem IMO (the performance hit will be mainly during occasional file accesses or system warnings/messages going to the console... it does seem to jerk noticeably when this happens).

I have fixed a few more issues including a recent scaling problem with the floor texturing and rendering the smallest viewport sizes (when shrunk with the '-' key).

The annoying HELP screen issue is still there but I'll need more time to fix that.


Since the game is mostly running now I will probably stop posting new builds and just work on tidying it up, finishing the various loose ends and optimizing things. I don't think there will be much interest value in drip-drip builds until something looks visibly improved. I will still post updates on anything that seems relevant.