Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

EvilFranky wrote:Excellent progress as we've come to expect Doug! :cheers:
:cheers:
EvilFranky wrote:It's looking like one of the big 'what ifs' of the Falcon scene will come to a close in the coming months, great to see and never thought a proper attempt at a Falcon Doom would ever materialize.
As ever, it turns out to be more work than I thought.
EvilFranky wrote:This is obviously for much mater in the development...but will you enable JagPad support please! :angel:
I imagine jagpad isn't hard to support. Unfortunately I offloaded all my jag stuff a few years ago (mistake) so unless somebody else adds it, guesswork may be involved :)
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 895
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: Bad Mood : Falcon030 'Doom'

Post by EvilFranky »

Regarding this Hatari profiling resource that has been used.

I remember years ago when the PS1 was coming to the end of its life, magazines were reporting stuff about improvements to the development kits which provided programmers with analysis of each PS1 component and its utilization. Meant to help programmers squeeze every last bit of performance out of the system. I recall the likes of Tekken 3 and GT2 used this newer system.

Is this a similar thing? I wonder if this development would never really have been possible back in 93-94, because knowledge of the Falcon just wasn't available? Not doubting your abilities of course Doug! :mrgreen:

But seems like a lot has been discovered in 20 years that couldn't have been in its first 2-3 years?
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

EvilFranky wrote:Regarding this Hatari profiling resource that has been used.

I remember years ago when the PS1 was coming to the end of its life, magazines were reporting stuff about improvements to the development kits which provided programmers with analysis of each PS1 component and its utilization. Meant to help programmers squeeze every last bit of performance out of the system. I recall the likes of Tekken 3 and GT2 used this newer system.

Is this a similar thing? I wonder if this development would never really have been possible back in 93-94, because knowledge of the Falcon just wasn't available? Not doubting your abilities of course Doug! :mrgreen:

But seems like a lot has been discovered in 20 years that couldn't have been in its first 2-3 years?
I think it's fair to say that results can only be better with more visibility. It doesn't necessarily make things easier - it just means you can go further/deeper with improvements than you would have without it. The more complex the project, the more that holds true.

I worked on PS1 and PS2 and with the profiling kits, and without them it was tough to tell what was going on. Lots of chips and data paths busy at once, esp. PS2.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

I meant to add to the strategy ^^^ above that Dio's suggestion about managing LOS tests still holds and I'm hoping to get something working there - it is potentially better than lowering the TICRATE too far since the latter limits the resolution of enemy movements and collisions - which might surface some unwanted bugs as mentioned earlier.

I figured out a fairly (!) elaborate scheme to cache LOS test results between uses, subject to radical movements of enemies and/or floor/ceiling heights moving inside sectors recorded as interacting with those rays. In fact there are a few ways to do this but they are all nasty and complicated so it may be better to just get the LOS test as fast as possible and manage down it's rate of use.


Tonight though I'm looking at a bunch of DSP vector co-processor operations which will help speed up all those C functions doing things with rays and coordinates in the map. The first is a linesegment vs bounding circle test, which will speed up LOS slightly for those sectors the rays actually pass near. I counted an increased rejection rate with this and I'm still looking into the reason why - it seems higher than I would expect. Might have been a bug.

The next will be a which-side-of-line test which should speed up LOS significantly. There is also a line/line intersection function which is used by my 'add on' optimization which splits rays against the BSP (the one that halved the number of sectors visited!).

I'm not so sure that I will implemented fixedmul/fixeddiv ops on the DSP, since the time to shuffle 24bit+ values through the port doesn't really make it worthwhile. It's only useful if it's done as part of reworking a larger function into 030 or DSP. For now they will remain as 030 asm, much like those used on the other m68k Doom ports.

This will take a while and I'm very busy next week so I don't know when there will next be news. I'll be working on it during gaps anyway.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Eero Tamminen wrote: I imagine that people with different machines (accelerated Falcons) might want to use different TICKRATEs and that it will be changed as BM performance changes. Doom1 WADs might also work with higher TICKRATE than Doom2 ones.
What if TICKRATE would be configurable from command line or config file, instead of being build time option?
The problem with the TICRATE constant is that it's used at compile time by lots of AI code to scale behaviour according to the the target AI frequency. It's not very nice, but OTOH doesn't cost much.

Making that into a variable is possible at some unknown (possibly small) cost penalty (but a lot of code edits and AI debugging!).

I need to figure out how it's being used anyway because at a glance it looks like it's scaling movements literally, which is the opposite of what I'd expect to see. Vectors should scale down as the frequency goes up and slices get smaller. Another thing to investigate soon, when I get to the AI stuff itself.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2315
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Eero Tamminen »

dml wrote:The problem with the TICRATE constant is that it's used at compile time by lots of AI code to scale behaviour according to the the target AI frequency.
Ok, it seems to be used directly in:
- doomdef.h
- i_sound.c
- i_system.c
- st_stuff.c
- wi_stuff.c

but there are additional TIC defines, either derived from it (in doomdef.h), OR defined independently:

Code: Select all

d_net.h:#define BACKUPTICS              12
doomdef.h:    INVULNTICS        = (30*TICRATE),
doomdef.h:    INVISTICS = (60*TICRATE),
doomdef.h:    INFRATICS = (120*TICRATE),
doomdef.h:    IRONTICS  = (60*TICRATE)
g_game.c:#define SLOWTURNTICS   6
p_spec.h:#define SWAITTICS              4
I assume all of these tics should actually be relative to TICRATE?

And there are some places here where 35(*2) might actually mean TICRATE:

Code: Select all

$ egrep -e '\b35\b' -e '\b70\b' *.[ch] | grep -i -e count -e time -e delay -e tic -e rate -e sleep
d_main.c:           pagetic = 35 * 11;
d_main.c:           pagetic = 35 * 11;
doomdef.h:#define TICRATE               35
doomdef.h://  assuming TICRATE is 35 ticks/second.
g_game.c:       wminfo.partime = 35*cpars[gamemap-1]; 
g_game.c:       wminfo.partime = 35*pars[gameepisode][gamemap]; 
i_system.c:    usleep (count * (1000000/70) );                                
p_doors.c:              door->topcountdown = 35*30;
p_doors.c:    door->topcountdown = 30 * 35;
p_doors.c:    door->topcountdown = 5 * 60 * 35;
p_mobj.c:       if (mobj->movecount < 12*35)
p_mobj.c:    if (leveltime - itemrespawntime[iquetail] < 30*35)
p_pspr.c:    angle = (FINEANGLES/70*leveltime)&FINEMASK;
p_pspr.c:    angle = (FINEANGLES/70*leveltime+FINEANGLES/2)&FINEMASK;
p_spec.c:       levelTimeCount = 20 * 60 * 35;
p_spec.c:       time = atoi(myargv[i+1]) * 60 * 35;
p_spec.h:#define BUTTONTIME      35
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Yes, it's a bit of a tangle. :-) Fortunately many source ports tried to fix some of it and at least one has changed the TICRATE and were therefore forced to fix all the AIs for Doom1 at least. Doom2 and onwards might not be so lucky.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2315
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Post by Eero Tamminen »

Some other, potentially relevant places:

Code: Select all

$ for i in count counter time timer delay tic tics rate sleep; do egrep "$i *[-+]?= *[0-9]+" *.[ch]; done | egrep -v '\b[01] *;'
d_main.c:       borderdrawcount = 3;
d_main.c:           borderdrawcount = 3;
p_inter.c:          player->damagecount = 100;  // teleport stomp does 10k points...
p_lights.c:    flick->count = 4;
p_lights.c:    flick->count = 4;
p_pspr.c:       count = 2;      // Double barrel.
r_draw.c:       count -= 8;
r_draw.c:       count -= 4;
g_game.c:       wminfo.partime = 35*pars[gameepisode][gamemap]; 
p_lights.c:    flash->maxtime = 64;
p_lights.c:    flash->mintime = 7;
p_mobj.c:    mo->reactiontime = 18;
p_setup.c:    wminfo.partime = 180;
p_telept.c:                 thing->reactiontime = 18;
wi_stuff.c:     cnt_time += 3;
d_main.c:           pagetic = 35 * 11;
d_main.c:           pagetic = 170;
d_main.c:       pagetic = 200;
d_main.c:           pagetic = 35 * 11;
d_main.c:           pagetic = 200;
f_finale.c:     casttics = 15;
i_video.c:      if (tics > 20) tics = 20;
(greps check several variables with potentially timing related postfixes, that are set to, increased or decreased by value larger than 1.)

EDIT: grep out only things where 0 or 1 is just before ';', otherwise it might take out too much.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Tonight I tested a DSP 'vector co-pro' operator which replaces an important function in the game code (InterceptVector) and is used by the replacement LOS BSP algorithm. It requires 8 fixedpoint inputs which are quite costly to load onto the DSP. However a nice optimization in the LOS BSP walk means one of the vectors (the sight ray) can be loaded once at the start, and the second ray (the bsp planes) can be loaded for each new slice. This halves the cost straight away. Not all BSP nodes will slice the ray - especially with the new algorithm - and the BSP plane can be loaded speculatively and calculation started before the answer is needed.

While the more important optimizations are still missing the results look promising using just the simple version of the operator combined with the new BSP walk. Noticable rise in FPS with 35hz tick (originally 1.5fps with old code, 2fps with new algorithm, risen to 3fps+ with new vec operator).

The LOS code still needs a lot of work to get it off the radar but not a bad start.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

So I'm now working on a concurrent CPU+DSP version of the line-of-sight search, where the vector state remains on the DSP and the BSP walk logic is on the CPU side, with both running synchronously and without very much communication. The idea is that one or other gets absorbed for 'free', and the CPU code shrinks to fit in the instruction cache. This last bit might be tricky with the C version as it's still about 500 bytes big with the current DSP communication overhead - but an ASM version will be smaller and maybe small enough to fit in the cache. Doing so would probably drop the LOS tests off the performance radar (Hatari profiler shows it to be at the top of the cache-miss offender list**) - and then the focus moves somewhere else.


**Hatari cache miss information for function-level analysis is proving to be extremely useful here! Without this tool its really only possible to be aware of cache miss profiles for predicted, measured hotspots. e.g. rendering inner loops. Finding those as bottleneck correlations in unfamiliar areas of game code by hand would be a lengthy, painful and inaccurate process.

[EDIT]

The whole optimization is made possible by storing the line-of-sight ray on the DSP for the entire walk, unmodified, but cropping the ray against BSP planes by constantly updating two ray scalar values (beginning,end of active ray fragment). This means the DSP only needs to know when one or other value changes to apply each crop, which it does very quickly, and it can find the ends of the fragment quickly with a couple of cheap multiplies. In fact the DSP has enough information to do everything except find the next BSP partition, which is where the CPU comes in - a 'side code' is sent back to the CPU after each ray classification and the CPU supplies the next line/plane from main memory (4 values) based on that. Since the CPU is left with only addressing duties, the resulting code can be tiny and begins to cache well.
User avatar
viking272
Atari Super Hero
Atari Super Hero
Posts: 505
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: Bad Mood : Falcon030 'Doom'

Post by viking272 »

Could Bad Mood be the greatest stock Falcon release? :-)
Great work Doug!

Sent from my GT-I9300 using Tapatalk 2
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

viking272 wrote:Could Bad Mood be the greatest stock Falcon release? :-)
Great work Doug!
There are lots of quality Falcon releases - but it could become one of the more ambitious Doom ports at least. :-)
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Managed to rework the C code for the main search part of the line-of-sight test into 226 bytes of 68030 asm, using DSP for vector work. So it now fits in the i-cache.

There are still some problems with it which I'll have to fix next week - it's still a recursive function which is unnecessary and some nasty register saving and stack frame stuff on every visit to match the C version. This will get flattened out into data recursion and will cost less.

The vector parts are using 32bit & 24bit values in places where 16bits would do (and recursive calls still pass 32bit args), so that will get fixed too.

It is much faster as it is, but it's better to fix those things before checking performance properly.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Beginning to get traction on the performance problems in the game code.

Using the original code with only minor modifications I was seeing around 1.5-2.5fps on most of the maps with a 35hz gametick frequency and not much better than that at 15hz (since it has a sort of bail-out mode when game time falls too far behind, and this happened constantly at 35hz - so slowing down time just causes it to try filling in even more work). A noticable improvement was only seen at 6hz and that was still using nearly half of the available time.


Now with the DSP/68k line-of-sight test implemented I'm seeing around 4-7fps in most of the Doom1 maps, and around 2.5-5fps in the Doom2 maps I tried. I think this is quite positive esp. given that it's just one function that has been replaced.

So far this is just applying code optimizations - the game behaviour has been left alone as far as possible (except for reducing the game tick frequency - which I think is just unavoidable now). At some point that will need to change too, and some things (like sight checks) will need to be regulated over time to get reasonable performance for playability. For now its good to see the framerate rising noticably without having to do that yet.

Despite rewriting the line-of-sight code to execute in less than 200 bytes and with DSP help, it still dominates quite a lot in the profiling snapshots, and this is mainly caused by it having to frequently leap in and out of that code to another C function to test wall segments against the sight ray. I tried variations on this which deferred the 'leaping' to a 2nd process but it didn't help at all - the raycast BSP process needs to terminate as soon as it touches the first wall, otherwise the total work increases a lot even just for determining which sectors need checked, without actually checking them. It is a bigger job to convert that code because it contains a lot of C-struct size sensitive stuff and lots of shortcut logic - it's messy - but worth doing eventually. Might not attack it right now but it's on the list. There are 4 or 5 other bits of code which need replaced and while they don't cost as much, cumulatively they do incur about the same overhead as the line-of-sight stuff and share some things in common so they will probably get attention first.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

I should have clarified in the last post that the new results are with a 15Hz gametick, and not 6Hz! So things are a bit better than they might have seemed in that post.

The two projects are now joined in source control with the original Doom source as a reference startingpoint to make the diffs easy to follow. Will continue to focus on speeding up the game code for a while, before looking at other fun things (like sprites and moving floors).
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

I have uploaded another video in AVI format this time, showing some improvements from recent days, albeit none of them complete yet.

https://dl.dropboxusercontent.com/u/12947585/swd.AVI

The video shows Shareware Doom 1.9 running in Hatari in Falcon 16mhz mode. It incorporates optimizations recently made to the game code using the DSP and chunks of 68k. It is frame-skipping but the FPS figure in the corner is correct. The performance is much better in these shareware episode levels, having been built for earlier/less powerful PCs - they are more enclosed and this occlusion stops line-of-sight rays reaching very far across the map most of the time. Doom2 levels by comparison are much more open and expensive and it shows when testing on the Falcon. There is obvious 'tearing', 'wall shuffling' effects and bad flickering on transparencies - mainly a lack of back-buffering - and will eventually get fixed.

The most obvious change - sector floor and ceiling heights are now interpreted from the game state, so you can see platforms and doors moving around as they should for the first time. They were always static in the BM viewer previously.

There is actually still a small bug with this since BM doesn't re-read the state of adjacent sectors until it tries to render their interior, so some doors don't appear to open until the player walks 'into' them and suddenly they are half-way open. This also causes a kind of lag so the floor or ceiling isn't exactly showing the correct height on each frame. You'll see this problem sometimes in the video but at least half of the platforms move as expected already.
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 895
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: Bad Mood : Falcon030 'Doom'

Post by EvilFranky »

Excellent! :D

That's a 320*200*16 screen then Doug? So there is even possibility to half the vertical resolution in game (Like Jag Doom etc), and it'll be even faster.

Top draw :cheers:
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

It's less than 320x200 (the default aspect in Doom and BM is actually 320x168 to accommodate for the status bar, currently missing).

The window is reduced to some fraction of that so it's probably near 256 x ??? something-or-other. It's set by a scale factor and I haven't checked the resulting resolution properly yet.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

EvilFranky wrote:So there is even possibility to half the vertical resolution in game (Like Jag Doom etc), and it'll be even faster.
TBH the size of the display isn't the limiting factor at the moment - the game code is still the main cost for most of the levels tested. This is slowly getting fixed so hopefully the display will end up being the limiting factor again and resolution hacks will start to make sense again.
kristjanga
Captain Atari
Captain Atari
Posts: 400
Joined: Sat Jul 25, 2009 3:35 pm

Re: Bad Mood : Falcon030 'Doom'

Post by kristjanga »

WOW the progress on bad mood is huge..
This is definitely one of the biggest thing in Falcon history
video is just great :cheers:
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

kristjanga wrote:WOW the progress on bad mood is huge..
This is definitely one of the biggest thing in Falcon history
video is just great :cheers:
:cheers:

The height animation bug is now fixed (easy), so doors are now opening and closing correctly and lifts working without the glitches and the laggy effects. I think getting the sector lighting to work will be a similar deal (the room at the end of one of those levels in the demo should go completely dark when the switch is thrown but BM is using its own random lighting fx instead so it doesn't tie up with the game).

I don't have time to make a new video just now to show the fix but will remake it soon. Will probably revert to a full size window too.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

Something else I didn't make very clear - and maybe interesting. There are already enemies running around thinking, shooting and being shot at, it's just that they aren't visible yet :) The sprite code is completely broken and needs rewritten to tie properly with game state. On my list...
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 895
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: Bad Mood : Falcon030 'Doom'

Post by EvilFranky »

That is interesting! So the AI side is there but the routines for drawing aren't?

Once they are drawn we can expect the FPS to drop or are they already being processed as if they were being drawn?
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3634
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Post by dml »

EvilFranky wrote:That is interesting! So the AI side is there but the routines for drawing aren't?
Correct.
EvilFranky wrote:Once they are drawn we can expect the FPS to drop or are they already being processed as if they were being drawn?
Drawing the sprites does cost, but based on experience with the original BM viewer and the fact most sprites occupy a small area of display (viewsize = dimensions / distance), the actual impact isn't that great - except when you have several quite close to the player and overlapping. Then it gets a bit interesting.

I have a plan for this last problem, but haven't put it into action yet. It will work.
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 895
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: Bad Mood : Falcon030 'Doom'

Post by EvilFranky »

Giddy with excitement Doug :mrgreen:
Post Reply

Return to “680x0”