Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

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

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed May 29, 2013 8:23 am

Fortunately for me, Id put a nice function in there that does all the precache hard work for sprites. I just need to have it call BM's API.


//
// R_PrecacheLevel
// Preloads all relevant graphics for the level.
//
int flatmemory;
int texturememory;
int spritememory;

void R_PrecacheLevel (void)
{
char* flatpresent;
char* texturepresent;
char* spritepresent;


Walls and floors already precache properly so it's tempting to just leave that as it is. It might be more tidy to move it all here but I'd be a little concerned it starts loading more than needed (I had various optimizations which skip invisible walls with textures assigned etc.). I'll leave it alone for now and perhaps move it here later and transfer the optimizations at the same time.

[EDIT]

In fact it looks like Doom precaches all possible sprites and their frames - no special magic at all. Doesn't seem optimal but then perhaps most levels use most of the available sprites and trying to trim the others just makes it more complicated...

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed May 29, 2013 9:35 am

Eero, it should be possible to profile now with sprites precached.

Some memory leaks are also fixed and Doom isn't allowed to precache its own textures since it won't be using them anyway. While this has probably reduced level loading times by some degree, having BM precaching the sprites instead of Doom may have the opposite effect (On balance the total time should have gone down though).

The HD texture preview has also been disabled so the strobing background should be gone :-)

[EDIT]

I suspect the same situation applies to sfx samples - it will probably load them the first time they are needed. I don't see any precache step for those but there is a cache lookup present in the game code so I think they will be getting loaded and upsetting performance at runtime even if the audio device is not mapped.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu May 30, 2013 12:22 pm

A quick update from last night.

For Doom1 demo loop, the main Doom game code is now using just 500k for itself, out of the <=6MB max it tries to claim at startup. This is reasonably good news for a 4MB system. BM uses a lot more but at least it won't get much pressure from the game code.

Doom2 (and episode #4 of Ultimate Doom, most of Final Doom) will probably use double that figure but there will still be some game resources which can be freed up given some time. There are still 2 copies of some of the level structures loaded in 2 different forms (one for BM, one for Doom) which might be collapsed together at some point later. These aren't large but its still not a great situation.

Unfortunately Doom still wants the biggest chunk of RAM its likely to need for the biggest level loaded, and won't use all of it most of the time. This means BM can't use the slack for cache purposes. There isn't an obvious answer to this yet because BM's resource cache has indefinite lifespan with everything temporary and 'kickable' whereas Doom applies lifespan rules to whole groups resources and pulls the rug on those from time to time. The two systems aren't very compatible in principle. BM's cache does perform well under pressure so some wasted memory isn't a complete disaster but it does make things more of a challenge on a 4MB box.

The between-level cleanup is now working so leaks are not apparent in the game, and BM now also cleans up any fixed resources and is able to recycle everything else through its resource cache on demand. So the demo loop now runs indefinitely without crashing.

I still haven't figured out what's going on with the demo repeat levels which de-sync at the start. Looks like the player might be starting off the level facing the wrong way, which would explain some things - but not sure why. Doesn't seem to be a BM thing - game needs debugged.

Looks like it's nearly time to start doing the 2D overlays.

Eero - I screwed up the precache stuff in the last version - the global precache flag was off by default, and was being forced off by the game code for demo loops, so sprites were still not precached. This should be fixed with the next commit :)

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri May 31, 2013 8:52 am

Found more memory related bugs but I think I'm close to having solved them all - there is one obvious problem left as far as I can tell. The resource cache is eventually becoming exhausted after many demo loops despite also being empty, running out of old stuff to eject to make room for new stuff - possibly leaking a big temporary buffer somewhere or the cache itself is broken.

Once this is fixed I'll be looking at 2D overlays and then back to performance work.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Fri May 31, 2013 4:38 pm

Doom 1 takes now 11s to start, 41s to load level.

Of the level loading, slightly more than half goes to flat loading (mipmap generation etc), of the remaining half, half goes to texture rendering, rest goes mostly to BM level loading and some to sprite loading.

Callgraph generated of it by following is attached:

Code: Select all

hatari_profile.py -r autoprofile/doom.sym -p -g --ignore ascii_err_pwaddir --ignore-to framecounter,new_vbi,stabilizer_b,ikbd_handler,get_dx,get_dy,_Z_Malloc,_Z_Free,allocate_chunk,deallocate_chunk,_strlen,__isatty,_memset,_memcpy,_W_LumpLength,_W_CacheLumpNum,_SwapSHORT --emph-limit 2.0 --limit 0.5 --compact --no-leafs --no-intermediate -st badmood-level-load-CPU.txt

(-> calls to many functions that don't use that much CPU, but are called from all over the code, are ignored to make graph clearer.)


During 20 first frames in timedemo, there are no disk access.

Between that and first barrel explosion (39s of demo), there are 15 disk reads:

Code: Select all

GEMDOS 0x42 Fseek(7076560, 65, 0)
GEMDOS 0x3F Fread(65, 132, 0x18df98)
GEMDOS 0x42 Fseek(7075708, 65, 0)
GEMDOS 0x3F Fread(65, 144, 0x18df98)
GEMDOS 0x42 Fseek(7070308, 65, 0)
GEMDOS 0x3F Fread(65, 320, 0x18df98)
GEMDOS 0x42 Fseek(7069988, 65, 0)
GEMDOS 0x3F Fread(65, 320, 0x18df98)
GEMDOS 0x42 Fseek(7070628, 65, 0)
GEMDOS 0x3F Fread(65, 1316, 0x18df98)
GEMDOS 0x42 Fseek(7071944, 65, 0)
GEMDOS 0x3F Fread(65, 1624, 0x18df98)
GEMDOS 0x42 Fseek(7073568, 65, 0)
GEMDOS 0x3F Fread(65, 2064, 0x18df98)
GEMDOS 0x42 Fseek(7075632, 65, 0)
GEMDOS 0x3F Fread(65, 76, 0x18df98)
GEMDOS 0x42 Fseek(7075852, 65, 0)
GEMDOS 0x3F Fread(65, 256, 0x18df98)
GEMDOS 0x42 Fseek(7076108, 65, 0)
GEMDOS 0x3F Fread(65, 376, 0x18df98)
GEMDOS 0x42 Fseek(7076692, 65, 0)
GEMDOS 0x3F Fread(65, 216, 0x18df98)
GEMDOS 0x42 Fseek(7076484, 65, 0)
GEMDOS 0x3F Fread(65, 76, 0x18df98)
GEMDOS 0x42 Fseek(9109784, 65, 0)
GEMDOS 0x3F Fread(65, 944, 0x18df98)
GEMDOS 0x42 Fseek(9110728, 65, 0)
GEMDOS 0x3F Fread(65, 924, 0x18df98)
GEMDOS 0x42 Fseek(9111652, 65, 0)
GEMDOS 0x3F Fread(65, 1584, 0x18df98)


During the next 100 frames, there are only 2 disk reads:

Code: Select all

GEMDOS 0x42 Fseek(9113236, 65, 0)
GEMDOS 0x3F Fread(65, 2696, 0x18df98)
GEMDOS 0x42 Fseek(9115932, 65, 0)
GEMDOS 0x3F Fread(65, 3420, 0x18df98)


Which is a definitive improvement to earlier.

Btw. If you want to see GEMDOS calls in the hatari.log, do following change to profile.sh script:

Code: Select all

 # debugging options
-trace="--conout 2" # "--bios-intercept --trace xbios,gemdos"
+trace="--conout 2 --trace gemdos" # "--bios-intercept --trace xbios,gemdos"


Or should I enabled that by default in it?
You do not have the required permissions to view the files attached to this post.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri May 31, 2013 5:26 pm

Eero Tamminen wrote:Callgraph generated of it by following is attached:


Thanks!


Eero Tamminen wrote:During 20 first frames in timedemo, there are no disk access.

Between that and first barrel explosion (39s of demo), there are 15 disk reads:

Code: Select all

GEMDOS 0x42 Fseek(7076560, 65, 0)
GEMDOS 0x3F Fread(65, 132, 0x18df98)
GEMDOS 0x42 Fseek(7075708, 65, 0)
GEMDOS 0x3F Fread(65, 144, 0x18df98)
GEMDOS 0x42 Fseek(7070308, 65, 0)
GEMDOS 0x3F Fread(65, 320, 0x18df98)
GEMDOS 0x42 Fseek(7069988, 65, 0)
GEMDOS 0x3F Fread(65, 320, 0x18df98)
GEMDOS 0x42 Fseek(7070628, 65, 0)
GEMDOS 0x3F Fread(65, 1316, 0x18df98)
GEMDOS 0x42 Fseek(7071944, 65, 0)
GEMDOS 0x3F Fread(65, 1624, 0x18df98)
GEMDOS 0x42 Fseek(7073568, 65, 0)
GEMDOS 0x3F Fread(65, 2064, 0x18df98)
GEMDOS 0x42 Fseek(7075632, 65, 0)
GEMDOS 0x3F Fread(65, 76, 0x18df98)
GEMDOS 0x42 Fseek(7075852, 65, 0)
GEMDOS 0x3F Fread(65, 256, 0x18df98)
GEMDOS 0x42 Fseek(7076108, 65, 0)
GEMDOS 0x3F Fread(65, 376, 0x18df98)
GEMDOS 0x42 Fseek(7076692, 65, 0)
GEMDOS 0x3F Fread(65, 216, 0x18df98)
GEMDOS 0x42 Fseek(7076484, 65, 0)
GEMDOS 0x3F Fread(65, 76, 0x18df98)
GEMDOS 0x42 Fseek(9109784, 65, 0)
GEMDOS 0x3F Fread(65, 944, 0x18df98)
GEMDOS 0x42 Fseek(9110728, 65, 0)
GEMDOS 0x3F Fread(65, 924, 0x18df98)
GEMDOS 0x42 Fseek(9111652, 65, 0)
GEMDOS 0x3F Fread(65, 1584, 0x18df98)


During the next 100 frames, there are only 2 disk reads:

Code: Select all

GEMDOS 0x42 Fseek(9113236, 65, 0)
GEMDOS 0x3F Fread(65, 2696, 0x18df98)
GEMDOS 0x42 Fseek(9115932, 65, 0)
GEMDOS 0x3F Fread(65, 3420, 0x18df98)


Which is a definitive improvement to earlier.


That's good. I suspect these are audio samples but it does need checked properly.

Eero Tamminen wrote:Btw. If you want to see GEMDOS calls in the hatari.log, do following change to profile.sh script:

Code: Select all

 # debugging options
-trace="--conout 2" # "--bios-intercept --trace xbios,gemdos"
+trace="--conout 2 --trace gemdos" # "--bios-intercept --trace xbios,gemdos"

Or should I enabled that by default in it?


It's probably useful to have it there by default as we'd be looking for the same things while profiling/optimizing (at least to prevent interference with that, if not to measure it).

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri May 31, 2013 10:42 pm

I thought I'd have something more interesting to look at by now, but have instead been debugging something annoying.

I expected to have some memory allocator problems when BM and Doom were joined together and this didn't happen - not immediately. But I'm noticing problems now since BM releases its grip on cache entries between levels and this has required some extra effort to trace.

BM now has a visual memory block 'status bar' which shows the linear memory map and which systems own which blocks (Doom, BM cache, other) to help indicate fragmentation, leaks or inconsistencies. A consistency checker has been added to make sure the blocks form consistent pools.

That all seems to be working and all tests pass before/after every memory event, but after a few rounds of attract mode cache allocations still begin to fail even with the cache reporting empty and only light fragmentation in the main pool.

A bit puzzling that it's not solved yet with all the pedantic checks and the status bar not showing anything unusual. Probably time to dump the memory pool to a text file and pick through it by hand.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sat Jun 01, 2013 7:37 am

dml wrote:BM now has a visual memory block 'status bar' which shows the linear memory map and which systems own which blocks (Doom, BM cache, other) to help indicate fragmentation, leaks or inconsistencies. A consistency checker has been added to make sure the blocks form consistent pools.


Wow! :-)

dml wrote:That all seems to be working and all tests pass before/after every memory event, but after a few rounds of attract mode cache allocations still begin to fail even with the cache reporting empty and only light fragmentation in the main pool.


Good that it's at least no memory corruption. Memory shortage should be easier to track down.

What kind of alloc fails and to what kind of error? Does the error come from TOS?

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jun 01, 2013 8:32 am

Eero Tamminen wrote:
dml wrote:BM now has a visual memory block 'status bar' which shows the linear memory map and which systems own which blocks (Doom, BM cache, other) to help indicate fragmentation, leaks or inconsistencies. A consistency checker has been added to make sure the blocks form consistent pools.


Wow! :-)


It is just an indicator for the allocators *above* the TOS/compiler malloc, but that's good enough here since malloc-level calls are only used once at the very start to make the memory pools. From then onwards everything is visible (which helps a lot :)

Of course perhaps I missed interesting versions of the malloc-level calls here and there but the problems I'm seeing are almost certainly my own doing, at a level above that.

Eero Tamminen wrote:Good that it's at least no memory corruption. Memory shortage should be easier to track down.
What kind of alloc fails and to what kind of error? Does the error come from TOS?


Yes it doesn't seem like corruption is occurring.

The main problem is cache allocation refusals between BM resource cache layer and BM allocator layer, with the cache getting stuck in a loop trying to eject old stuff in order to place new stuff, when its already empty. It's behaving like old blocks are being freed but not consolidated/defragmented. That used to work but I have perhaps broken something which the block-merging is sensitive about. I'll find out later today when I look at it.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jun 01, 2013 9:09 am

This is in fact what is happening - I added free blocks to the visualizer (previously it showed only different kinds of allocated blocks colour-coded by who owns them) and the free pool is badly fragmented when it should have been merged back together, so it becomes increasingly difficult to allocate anything except tiny blocks.

16MB address range is divided into 256 pixels across the screen. One pixel represents 64k of ram.

The red bar has a red dot representing the beginning of each freeblock - it appears to be solid red instead of having a dot immediately after each used block and this is just wrong.

mem.jpg


I must have messed up the edge flags on memory blocks so it's no longer consolidating blocks when freed. Should be able to fix this tonight if I get time.

It's also obvious from this bar that Doom steals a ton of ram and doesn't give it back :) (I chopped off the left side of the image which represents another couple of megs or so) BM doesn't get much to play with after this and the executable are accounted for. This will be improved later.
You do not have the required permissions to view the files attached to this post.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sat Jun 01, 2013 12:56 pm

dml wrote:
Eero Tamminen wrote:During the next 100 frames, there are only 2 disk reads:

Code: Select all

GEMDOS 0x42 Fseek(9113236, 65, 0)
GEMDOS 0x3F Fread(65, 2696, 0x18df98)
GEMDOS 0x42 Fseek(9115932, 65, 0)
GEMDOS 0x3F Fread(65, 3420, 0x18df98)


That's good. I suspect these are audio samples but it does need checked properly.


They seem to be coming from sprite loading code:

Code: Select all

GEMDOS 0x42 Fseek(9113236, 65, 0)
Reading debugger commands from 'profile-stack.ini'...
> profile stack
- 0x2d448: _A_Explode (return = 0xffffffff)
- 0x22e56: _D_Display (return = 0x232ba)
- 0x1f482: _I_FinishUpdate (return = 0x230fe)
- 0x44344: _BM_R_DrawScene (return = 0x1f4ae)
- 0x4934c: display_engine (return = 0x44378)
- 0x4b6c6: render_transparent (return = 0x49482)
- 0x48998: cache_resource (return = 0x4b70e)
- 0x492c0: load_sprite (return = 0x48a38)
- 0x46be2: read_resource (return = 0x492fa)
- 'NextPC' -> $46c22
> b pc=$46c22 :once :quiet :noinit :file profile-d0.ini
GEMDOS 0x3F Fread(65, 2696, 0x18df98)
Reading debugger commands from 'profile-d0.ini'...
> e d0
= %101010001000 (bin), #2696 (dec), $a88 (hex)
GEMDOS 0x42 Fseek(9115932, 65, 0)
Reading debugger commands from 'profile-stack.ini'...
> profile stack
- 0x2d448: _A_Explode (return = 0xffffffff)
- 0x22e56: _D_Display (return = 0x232ba)
- 0x1f482: _I_FinishUpdate (return = 0x230fe)
- 0x44344: _BM_R_DrawScene (return = 0x1f4ae)
- 0x4934c: display_engine (return = 0x44378)
- 0x4b6c6: render_transparent (return = 0x49482)
- 0x48998: cache_resource (return = 0x4b70e)
- 0x492c0: load_sprite (return = 0x48a38)
- 0x46be2: read_resource (return = 0x492fa)
- 'NextPC' -> $46c22
> b pc=$46c22 :once :quiet :noinit :file profile-d0.ini
GEMDOS 0x3F Fread(65, 3420, 0x18df98)
Reading debugger commands from 'profile-d0.ini'...
> e d0
= %110101011100 (bin), #3420 (dec), $d5c (hex)


Same thing with all the other Fread() after level initialization.

FYI: I added code to Hatari to be able to get subroutine call backtraces from breakpoints during profiling (i.e. breakpoint option to not re-initialize debugger stuff i.e. reset profiling data when breakpoint is hit):
http://hg.tuxfamily.org/mercurialroot/h ... cc6daa7dfc

And I commited code using that to Doom profile.sh. It should be obvious how to use that to get backtraces to any other functionality (including checking function's return value). :-)

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jun 01, 2013 1:51 pm

Eero Tamminen wrote:They seem to be coming from sprite loading code:

Code: Select all

GEMDOS 0x42 Fseek(9113236, 65, 0)
Reading debugger commands from 'profile-stack.ini'...


Same thing with all the other Fread() after level initialization.


Hmm. Odd that sprites still load frames after precaching, but audio does not. Maybe related to the bugs I'm fixing but I'll look more closely after this is done.

Eero Tamminen wrote:FYI: I added code to Hatari to be able to get subroutine call backtraces from breakpoints during profiling (i.e. breakpoint option to not re-initialize debugger stuff i.e. reset profiling data when breakpoint is hit):
http://hg.tuxfamily.org/mercurialroot/h ... cc6daa7dfc

And I commited code using that to Doom profile.sh. It should be obvious how to use that to get backtraces to any other functionality (including checking function's return value). :-)


That's great! Backtrace is essential but I didn't ask for it because it seemed like a big job. I can definitely use it.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sat Jun 01, 2013 4:35 pm

dml wrote:That's great! Backtrace is essential but I didn't ask for it because it seemed like a big job. I can definitely use it.


Note that backtrace contains only symbols which are called as subroutines, not ones jumped or branched to. That's why there's also caller address given for each of the called functions so that you can track from the profile save file what actually was done.

With OS functions this is handly because Hatari tracing outputs their arguments. For your own functions (or functions in libraries you link) you need some other way to find out the arguments for those functions, either by outputting relevant part of stack in Hatari debugger script file, or adding printing of them to the program itself (show that they e.g. show up in hatari.log file with "--conout 2" Hatari option).

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jun 01, 2013 5:42 pm

The annoying bug is now fixed and the demo loop has been going for half an hour without getting stuck and without the memory self-tests complaining. The memory pool is no longer fragmenting, although I can see something small is leaking between level loads.

I'll probably leave it running overnight (without the cache flush before level loading) as a stress test for the cache and to help identify the leak.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jun 01, 2013 9:58 pm

Have committed those repairs now.

The memory visualizer is enabled and I removed the graphics cache flush between level loads so the cache will still be full before each new level begins - this will put it under a bit of fragmentation pressure and see some testing before it gets changed back.

I haven't identified the leaks yet, if they are leaks - will need to look at that separately.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Jun 01, 2013 10:55 pm

So one of the memory leaks is the game colour palette, which gets loaded on every level and needs moved to once-only init. There may be another one caused by a temporary buffer getting lost. I'm out of time tonight so I'll find that tomorrow. Should be leak free by next week and can finally make a start on the 2D/status bar bits.

Note: I found the leaks easily by enforcing a new rule - every block of memory allocated has to say what it is being used for or by. Since this 'annotation' affects how the memory visualizer is drawn (i.e. colour and position of that memory block) its easy to see which types don't get cleaned up. It's also easy to breakpoint the allocator when a block is requested without identification. This simple rule removes a ton of pain and wasted time.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jun 03, 2013 11:29 am

I found an interesting detail in JagDoom last night - mainly that line-of-sight functionality is performed for all 'thinkers' in one big burst before each gametick, instead of being done randomly from within AI code.

This is done on the DSP, and that code is pretty horrible to read but there's an obvious clue in the new C function 'P_CheckSights' which makes a single call to a DSP routine, with a comment that all thinkers get sight checked together and refers to at least one AI flag.

Code: Select all

===============
=
= P_CheckSights
=
= Check sights of all mobj thinkers that are going to change state this
= tic and have MF_COUNTKILL set
===============

From what I can read of the DSP code, it does appear to walk the active mobj list and inspect AI flags, filtering which pairs of objects have line-of-sight interest in each other and then doing the expensive LOS tests.

Presumably this logic can be done on the Falcon as well if translated properly. I had considered doing this already but the thought of working out which types of interactions were needed to make all the AIs work properly just put me off. Having an existing, working example could make it doable.

A few things I'm not sure about though - the same logic may not work for Doom2 AIs since there could be extra flags not accounted for in the pattern. Testing all the AIs to make sure they haven't got broken would be tiresome. The AIs could individually be performing fewer LOS tests in total if they only check specific targets in specific states, further complicating any attempt to do them all in one efficient pass.


If it can be done, then P_CheckSight can be collapsed to a simple flag lookup for any mobj pair, and so decrease the instruction cache miss rate while processing AI. i.e. it wouldn't necessarily speed up sight checking but will probably speed up AI.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jun 03, 2013 7:39 pm

A more interesting update this time.

Early keyboard, mouse support is now present and the AI thinking & movement scaling has been adjusted for a ticrate of 12Hz, which is just about playable.

On a first test (using keyboard) I managed to play through e1m1 of Doom1. I got killed half way through map01 of Doom2/ On a 2nd attempt I ran past all the AIs on map01 and just made it to the exit - didn't get far on map02!

(The difficulty level is a bit high, framerate still too low, no sound and no visible weapon overlays but it was still fun :-) )

Mouse support is tricky to test in Hatari at the moment since my cursor is still visible (distracting) and loss of mouse focus/capturing causes turn angle to get capped. Hatari fullscreen doesn't work very well on my laptop too (just not fast enough).

There will be problems trying to reduce the ticrate further. There are already a few problems at 12Hz - the game wasn't designed to run at low ticrates since the AIs count ticks spent in each 'thinking state' and these values are already small, normally ranging between 1 and 10. Divide those counters by (~36/12)=3 and things start to get lossy. (They are event counters, so using fractions won't work - but injecting some pseudorandom noise might even things out for lost values over several ticks).

There's not much point in a vid until the demo recording code is tested - existing demos don't play properly at 12Hz with the AI fixes, they all desync within the first second.

The last level I tried was map13, which ran very slowly on a base Falcon. Lots of monsters, lots of fireballs and stuff flying around. Didn't last long...

map13.jpg


(old, broken sky still in use here)
You do not have the required permissions to view the files attached to this post.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jun 03, 2013 8:53 pm

Just tested it for the first time on a real machine with the precached sprites, memory fixes etc. and it seems to run quite well on early Doom1 levels. Not 'smooth' but playable. Best with just the keyboard. Mouse is poorly calibrated and mousebuttons are strangely inverted but it does work with that too.

Haven't tested more complicated levels but it's looking ok so far.

Player momentum is wrong, it's a bit like running on wet ice. I'll try to fix this and post a binary here for anyone who wants to try it.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2025
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Mon Jun 03, 2013 9:12 pm

dml wrote:Hatari fullscreen doesn't work very well on my laptop too (just not fast enough).


By default Hatari scales Falcon screen to your desktop resolution (with nearest integer scaling factors) in fullscreen. If this scaling is too slow, you can try either "--desktop off -z 1" to turn off this scaling completely so that your display will do the scaling (from mode libSDL found to be closes to 320x200 implied by "-z 1" option), or by using frameskip, e.g. "--frameskip 1".

The reason why scaling is default on Falcon is some Falcon demos doing really fast resolution switches (even once per sec), and some LCDs taking several seconds to adapt when resolution is changed.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jun 03, 2013 9:58 pm

Eero Tamminen wrote:you can try either "--desktop off -z 1" to turn off this scaling completely so that your display will do the scaling (from mode libSDL found to be closes to 320x200 implied by "-z 1" option), or by using frameskip, e.g. "--frameskip 1".


Ok I'll give the "--desktop off -z 1" a try and see what happens.

Eero Tamminen wrote:The reason why scaling is default on Falcon is some Falcon demos doing really fast resolution switches (even once per sec), and some LCDs taking several seconds to adapt when resolution is changed.


Understood. I'll compare with mouse behaviour on the test Falcon to see if some of the weirdness is just the mouse packet handler. It was done in a bit of a hurry :)

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jun 03, 2013 10:04 pm

Eero, one other thing I wanted to do was get memory address info from the basepage so the executable text,data,bss sections can be added to the memory map viewer. This is quite easy for an assembly program but it means hacking the CRT module in this case and it would be nice to have a clean way to get the info without being tied to a specific CRT version or patching it when it changes.

I was going to lift the crt.s from gcc 4.6.3 and just make it conditional on the makefile (native gcc 2.95 builds just use the normal crt.o and don't provide extra info) but there might be a better way. e.g. it could take approximate info from the previous build via a script from the makefile. Less accurate since it uses the previous not current build, but less intrusive. Maybe you have some ideas here?

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Jun 03, 2013 10:50 pm

Ok here's a first test binary.

It needs a 14MB Falcon with FPU - for now. It also needs a Doom v1.9 WAD to work nicely. Preferably shareware DOOM1.WAD or Ultimate Doom / registered version DOOM.WAD. Doom2 will work but you won't be happy with the performance as it is.


Be warned - apart from the missing status bar, weapon overlays, menus, sounds and everything else - the Imps are fierce :twisted:

(best to '-warp e1m1' to start the first episode unless you know the Doom menus blind - otherwise it will sit on a black screen for a bit then start a demo which doesn't run properly)

[EDIT] ^^^ incorrect - actually use '-warp 1 1' for Doom game. BMVIEW uses the other form.


[EDIT] ...and it runs a bit faster in RGB video modes, for now. This will improve when the new VGA mode is added and the 2D stuff works properly @ 256 pixels.

Keyboard controls are:

< ^ > usual arrow keys to drive, CTRL to shoot, SPACE to open doors. You can strafe with ALT + arrows.

Mouse: left button to open doors etc., right to shoot. Not sure why yet, but that's how it is for now.

This build was configured for real hardware. It may work in Hatari but I didn't check it. I can upload a separate Hatari-friendly build with no MMU/cache extras if anyone has trouble with this one.
You do not have the required permissions to view the files attached to this post.
Last edited by dml on Tue Jun 04, 2013 11:19 am, edited 1 time in total.

User avatar
shoggoth
Nature
Nature
Posts: 989
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby shoggoth » Tue Jun 04, 2013 11:00 am

Funny, -warp -e1m1 takes me to some much later level. Blindly navigating through the menu system takes me to level 1. I'd much rather warp to level one, performance is nice there :) The -warp -e1m1 level is obviously much more demanding.

I do miss a low detail mode, but I take it this won't make much difference since the main bottleneck is the actual game logic?

EDIT1: I accidentally cause a 3rd person perspective (by pressing some - god knows which - key), i.e. camera was fixed, and I could see my own gameplay character run around. That's supposed to happen? :)

EDIT2: This was truly an awesome experience.
Ain't no space like PeP-space.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Tue Jun 04, 2013 11:14 am

shoggoth wrote:Funny, -warp -e1m1 takes me to some much later level. Blindly navigating through the menu system takes me to level 1. I'd much rather warp to level one, performance is nice there :) The -warp -e1m1 level is obviously much more demanding.


Try without the '-' before the e1m1.

e.g. '-warp e1m1'

[EDIT] ^^^ incorrect - see post on next page

...should work. I'll double check it though just in case I broke something here.

For Doom2 maps its just '-warp xx' where xx=mapnum,

e.g. '-warp 02'

shoggoth wrote:I do miss a low detail mode, but I take it this won't make much difference since the main bottleneck is the actual game logic?


Low detail mode can go back in without much trouble but I think it's not going to make a big difference now that the game is eating up so many cycles. There is still quite a lot to be done with the game code so maybe low detail modes will have some extra value later.

The game is crammed full of 64bit multiplies as all the coordinates, vectors are stored in 16:16 format. JagDoom removes many of those and simplifies some areas to cope better. I'll probably try to move more of those changes over to the Falcon version on a gradual basis.

shoggoth wrote:EDIT: I accidentally cause a 3rd person perspective (by pressing some - god knows which - key), i.e. camera was fixed, and I could see my own gameplay character run around. That's supposed to happen? :)


That's interesting, because I haven't seen it yet :-) I expect it must be a Doom cheat which is now bound to the keyboard. I'll look at the bindings to see which one might activate the 'out of body' camera view :).
Last edited by dml on Tue Jun 04, 2013 11:18 am, edited 1 time in total.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 2 guests