Bad Mood : Falcon030 'Doom'

[CiH]

Not tried this yet, I will do soon (busy with other stuff) but just wow Doug!

[Eero Tamminen]

Can be run without commandline, but menus are invisible so navigating into a game requires a key sequence 'ESC, RETURN, RETURN, RETURN..' etc.

If no command line is given, arguments will be read from "doom.def" file, if it exists.

(I added that a while ago to automate running of Doom for profiling.)

[shoggoth]

Tried bmgame02.zip. Performance seems much better now! I played through 5 levels or so!! Truly amazing.

I noticed that sprite clipping sometimes goes wrong. Or maybe clipping isn't the right term in this case. In some places, I could see sprites that were on the other side of a wall, for example.

Maybe some tick rate problems on exploding barrels and/or some enemy AI, some stuff seems to happen too slow. But I guess that's expected at this point.

Palette doesn't change when I'm hit by a bullet etc, so I get no visual indication of being hit. I guess it would take CPU time to rebuild the palette info since you use mipmaps and stuff - but what about changing the borde color, perhaps?

[shoggoth]

I noticed that the Jaguar Doom seems to have some simplifications made to the engine and/or the WAD file which I guess was made for performance reasons, in particular when it comes to transparent textures:

Take a look at this video at 00:18:00.
http://www.youtube.com/watch?v=04Q_Jl7nGdM

Normally this location has transparent textures and is very slow on BadMood. Perhaps it would make sense to make it possible to use the Jag WAD data (if it's available), since this could optimize the framerate in those difficult map locations.

[dml]

Hi,

I have been away in wilderness for a few days and missed these last few messages.

Tried bmgame02.zip. Performance seems much better now! I played through 5 levels or so!! Truly amazing.

That's great! If you managed through 5 levels after those AI changes it can't be too far from a playable state. There are some things clearly wrong but it's difficult to tell how many prevent gameplay.

There are a few distance-critical jumps which are probably not achievable with current physics. This might block progress on some levels. e3m1 has one and there are probably others. This might need the physics to be properly matched against the original.

I noticed that sprite clipping sometimes goes wrong. Or maybe clipping isn't the right term in this case. In some places, I could see sprites that were on the other side of a wall, for example.

Yes I noticed those too. I removed the side-of-line test which caused a few problems but forgot a few cases where it is still needed. In fact the side-of-line test is always needed for transparent walls, and should only be shortcut with a min-z test on solid walls. Currently it's disabled and will need restored with the modified logic.

Currently you'll see some objects floating under the floor if the adjacent sector floor height is lower, or objects like barrels popping in front of transparent walls. I have some notes on places where this occurs so it can be fixed properly.

Maybe some tick rate problems on exploding barrels and/or some enemy AI, some stuff seems to happen too slow. But I guess that's expected at this point.

Yes there are definitely a few cases where the tick count changes have really affected behaviour. The barrel has a small tick count per state and the total time error for rounding each of those states is quite large. I think these cases can be fixed though with some noise trickery.

Palette doesn't change when I'm hit by a bullet etc, so I get no visual indication of being hit. I guess it would take CPU time to rebuild the palette info since you use mipmaps and stuff - but what about changing the borde color, perhaps?

At first this would have been a simple matter, with all pixels drawn indirected through global colour tables - would just need a pointer change for the active table. This is still true for walls when no HD textures are in use but would need larger tables for HD textures and the floor textures have tables encoded into them... It's still doable by switching different tables into floor textures before uploading them to the DSP and so on, but I'm wondering if all the mess is worth the effort. It also won't work with Laurent's precompiled sprite code which will be used to accelerate weapon overlays etc. Not that this is an issue, but it's just one more detail that needs special treatment for a single effect.

Probably some other method of indicating damage or pickups will suit the Falcon version better - border colour is probably enough - it's pretty hard to play the game without knowing when you're being hit so something will be needed. Sound will help but the visual feedback is more direct.

[dml]

I noticed that the Jaguar Doom seems to have some simplifications made to the engine and/or the WAD file which I guess was made for performance reasons, in particular when it comes to transparent textures:

Take a look at this video at 00:18:00.
http://www.youtube.com/watch?v=04Q_Jl7nGdM

Normally this location has transparent textures and is very slow on BadMood. Perhaps it would make sense to make it possible to use the Jag WAD data (if it's available), since this could optimize the framerate in those difficult map locations.

I have a 'port' of the Jag WAD which is compatible with PC Doom and therefore also BadMood. This does appear to run and while it's not any faster at the e1m1 startpoint I was testing with at the time, it's likely to be faster in some other areas (esp. without transparent walls).

In fact the Falcon version doesn't get too upset with large texture counts on walls and this is one of the things JagDoom optimized down quite heavily - this can be seen from just comparing the levels visually. A few textures are reused all over the level. So that optimization doesn't really affect the Falcon.

The Falcon version is pressured however by floor/ceiling texture count, having to upload a new DSP texture for each state (I think the threshold in BM is around 6-8 floor textures before it starts to be a noticeable drain). So this coupled with the transparent wall optimizations will probably make the Jaguar WAD noticably faster in some areas.

Having said that, I do plan to make some changes which will reduce the cost of transparent walls. Ideally BM should be able to run the PC version of the wad as-is, but may run faster using the Jag version - esp. in some parts of a few maps.

[Eero Tamminen]

That's great! If you managed through 5 levels after those AI changes it can't be too far from a playable state. There are some things clearly wrong but it's difficult to tell how many prevent gameplay.

Unfortunately timedemo doesn't anymore work properly, player never gets out of first screen in the demo, so profiling script does neither. :-/

Palette doesn't change when I'm hit by a bullet etc, so I get no visual indication of being hit. I guess it would take CPU time to rebuild the palette info since you use mipmaps and stuff - but what about changing the borde color, perhaps?

At first this would have been a simple matter, with all pixels drawn indirected through global colour tables - would just need a pointer change for the active table. This is still true for walls when no HD textures are in use but would need larger tables for HD textures and the floor textures have tables encoded into them... It's still doable by switching different tables into floor textures before uploading them to the DSP and so on, but I'm wondering if all the mess is worth the effort. It also won't work with Laurent's precompiled sprite code which will be used to accelerate weapon overlays etc. Not that this is an issue, but it's just one more detail that needs special treatment for a single effect.

One more possibility is e.g. drawing every other line red. Similarly to communication interference lines (video noise/static) on the screen in games where player was supposed to guide the character through some remote sensor setup. When player's character is in pain, it's natural that player momentarily sees less.

Because player's character getting hit typically happens in crowded scenes, it might even help with performance as only every other line's content needs to be calculated...

[dml]

Unfortunately timedemo doesn't anymore work properly, player never gets out of first screen in the demo, so profiling script does neither. :-/

Unfortunately that's a side effect of changing the AI time basis - however I think I was careful enough to tie everything to TICRATE so restoring that to 35 should make the demos work again. There are probably a couple of other things which need changed e.g. remove -DMANAGE_THINKERS but I did make sure it would be easy to revert all of it back to old behaviour for profiling, (just haven't tested it yet).

One more possibility is e.g. drawing every other line red. Similarly to communication interference lines (video noise/static) on the screen in games where player was supposed to guide the character through some remote sensor setup. When player's character is in pain, it's natural that player momentarily sees less.

Because player's character getting hit typically happens in crowded scenes, it might even help with performance as only every other line's content needs to be calculated...

This is actually more difficult than it seems because there is more than one 'shader' working on more than one axis, and from different kinds of sources (textures, DSP etc) so accessing colour on every 2nd line at rendering time isn't a natural extension of that. It can be done but there is probably a less expensive solution which will work for BM.

(If the lines are just drawn on top of the display like some kind of static that's a lot less trouble but at a slightly raised fillrate cost).

Another possibility is using TimerBs to move the display address around and access 'red' data at required lines. This would achieve the same at lower fill cost but with more interrupt stuff going on instead.

[Eero Tamminen]

Unfortunately that's a side effect of changing the AI time basis - however I think I was careful enough to tie everything to TICRATE so restoring that to 35 should make the demos work again. There are probably a couple of other things which need changed e.g. remove -DMANAGE_THINKERS but I did make sure it would be easy to revert all of it back to old behaviour for profiling, (just haven't tested it yet).

Are you currently scaling timedemo tic down by 3? The behavior is very different, that's why I'm asking...

One more possibility is e.g. drawing every other line red. Similarly to communication interference lines (video noise/static) on the screen in games where player was supposed to guide the character through some remote sensor setup. When player's character is in pain, it's natural that player momentarily sees less.

Because player's character getting hit typically happens in crowded scenes, it might even help with performance as only every other line's content needs to be calculated...

This is actually more difficult than it seems because there is more than one 'shader' working on more than one axis, and from different kinds of sources (textures, DSP etc) so accessing colour on every 2nd line at rendering time isn't a natural extension of that. It can be done but there is probably a less expensive solution which will work for BM.

(If the lines are just drawn on top of the display like some kind of static that's a lot less trouble but at a slightly raised fillrate cost).

Another possibility is using TimerBs to move the display address around and access 'red' data at required lines. This would achieve the same at lower fill cost but with more interrupt stuff going on instead.

One more alternative is to change palette just for the HUD when play is hit. Because BM screen size is so small, I think there's enough space to have it always visible. Can HUD palette be changed without extra performance hit?

If not, I guess it needs some testing to see which of these three methods looks best; red border, red "static", or reddish HUD.

[dml]

Are you currently scaling timedemo tic down by 3? The behavior is very different, that's why I'm asking...

*Most* of the changes involved a change to the main TICRATE constant, reduced from 35 to 12 (i.e. roughly divided by 3). However lots of stuff which previously was not tied to TICRATE (but should have been) is now affected by this including some AI and player physics (turning angles are included I think). So taking into account the increased integration error between ticks at lower Hz, it does not take long for a recorded demo to lose sync completely. The player usually skates into a wall or points in the wrong direction very quickly.

While this can be improved by calculating constants that minimize the integration error, it can't be magically fixed so it works properly, except to translate/re-record the demo using new constants. I don't see the point in this so I'm not going to try. (I will however try to reduce the integration error as much as possible so the game plays as closely to the original as possible)

There are some other changes which are not directly related to TICRATE which also cause loss of sync, mainly to help performance.


In order to restore your profiling capabilities, I'll make sure the next revision/checkin makes it easy to restore old behaviour with a compile flag. This will use the earlier compromise of unmodified AI and a 15Hz TICRATE (i.e. reasonable framerate, slow moving AIs, fairly accurate demo replay). You *might* have to modify the delays you used to start recording since some things like menu timers will still be affected by the 15Hz change, but at least the demos will work!

One more alternative is to change palette just for the HUD when play is hit. Because BM screen size is so small, I think there's enough space to have it always visible. Can HUD palette be changed without extra performance hit?
If not, I guess it needs some testing to see which of these three methods looks best; red border, red "static", or reddish HUD.

Yes changing the HUD might be a lot less trouble and give enough feedback. I'll consider that one, and maybe couple it with the border change too?

[Eero Tamminen]

In order to restore your profiling capabilities, I'll make sure the next revision/checkin makes it easy to restore old behaviour with a compile flag. This will use the earlier compromise of unmodified AI and a 15Hz TICRATE (i.e. reasonable framerate, slow moving AIs, fairly accurate demo replay). You *might* have to modify the delays you used to start recording since some things like menu timers will still be affected by the 15Hz change, but at least the demos will work!

I'm not sure that's worth the trouble. I'd rather profile the best optimized version. Time to look into worst (so far) FPS variable?

Later on it would be good if somebody could record nice BM specific timedemo.

Yes changing the HUD might be a lot less trouble and give enough feedback. I'll consider that one, and maybe couple it with the border change too?

Border change could be just top and bottom borders, especially if doing 2x wider lines there would be faster faster than having thinner line around whole screen.

[dml]

I'm not sure that's worth the trouble. I'd rather profile the best optimized version. Time to look into worst (so far) FPS variable?

Worst FPS variable - already on my list so I don't forget it I think it would be good to have the behaviour restore flag though (for reasons given below)


I think there is still significant value in profiling the code without the recent tick-rate management changes. While such changes are technically an optimization, it is more focused on reducing/scaling work globally. It doesn't directly improve throughput in any way and hides some performance issues.

I can see 3 scenarios which are useful to profile:

1) BMVIEW - just rendering and distribution of work within the renderer. This is unaffected by TICRATE or other high level stuff. Any optimization is valid which doesn't lead to obvious loss of visual information. Profiling this is easy and always valid.

2) Doom game @ default 35Hz TICRATE. While this 'amplifies' the cost of the game code on the Falcon, it's a pretty honest test for finding hotspots in the game code and areas worth optimizing. I'm happy using this to work on AI and LOS test optimizations because it pushes the rendering costs into the background.

3) Doom game @ 35Hz (?) TICRATE, but with 12Hz base timer and without AI management. This approaches 'reasonable' performance on the Falcon but still allows demos to run properly. The action will appear slowed down but otherwise everything works and cost is fairly balanced. This is what we have been using

To profile the fully managed/optimized version will require two things:

A) the management techniques need to be fairly settled i.e. not expected to change (frequently) in ways that cause demos to break
B) a demo needs to be recorded for this set of conditions, on the Falcon, for profiling purposes

I don't think the code is settled enough yet to do this, except maybe to test/validate the demo recording capability itself.

Later on it would be good if somebody could record nice BM specific timedemo.

This will be useful but it's probably not worth recording a good demo until some changes have settled down a bit, since it's so easy to invalidate the recording. However it would be good to test recording to see if it works at all.

The current AI management changes will probably not work well with recording because some state is kept in the mobj_t for individual thinking rates - but I'm aware of this one and will do something about it before long.

[shoggoth]

Border change could be just top and bottom borders, especially if doing 2x wider lines there would be faster faster than having thinner line around whole screen.

The video hardware actually has an actual border even on VGA, and even in 16bpp modes. Even if BadMood uses a custom 256xNNN resolution, it would make sense to add a 32+32 pixel horizontal border to allow TFT monitors to scale properly, since the monitor will interpret this as a 320xNNN resolution. The colour of the border area can be touched using a single longword (it's falcon 256-colour palette index 0), which means it's basically "free".

[Eero Tamminen]

1) BMVIEW - just rendering and distribution of work within the renderer. This is unaffected by TICRATE or other high level stuff. Any optimization is valid which doesn't lead to obvious loss of visual information. Profiling this is easy and always valid.

Doesn't the current render start -> end profile already provide this?

2) Doom game @ default 35Hz TICRATE. While this 'amplifies' the cost of the game code on the Falcon, it's a pretty honest test for finding hotspots in the game code and areas worth optimizing. I'm happy using this to work on AI and LOS test optimizations because it pushes the rendering costs into the background.

3) Doom game @ 35Hz (?) TICRATE, but with 12Hz base timer and without AI management. This approaches 'reasonable' performance on the Falcon but still allows demos to run properly. The action will appear slowed down but otherwise everything works and cost is fairly balanced. This is what we have been using.

Ok, but to have separate builds it might be better if Makefile would build both automatically, or at least have target(s) for that.

To profile the fully managed/optimized version will require two things:

A) the management techniques need to be fairly settled i.e. not expected to change (frequently) in ways that cause demos to break
B) a demo needs to be recorded for this set of conditions, on the Falcon, for profiling purposes

I don't think it's necessary to do it on real Falcon. Profiling happens in Hatari, so demo could be done under that too.

The current AI management changes will probably not work well with recording because some state is kept in the mobj_t for individual thinking rates - but I'm aware of this one and will do something about it before long.

For Doom2 automatic profiling of 100 frame still works as it uses different triggers, but I'm not sure how useful is run of player wandering around in acid:

Code: Select all

Time spent in profile = 20.07215s.
...
Calls:
  19.62%               99308             R_BSPHyperPlane_RHS
  15.47%               78287             R_BSPHyperPlane_LHS
  10.66%  30.16%       53981    152655   _P_MobjThinker
   7.67%   7.67%       38804     38804   _P_AproxDistance
   2.23%  10.29%       11277     52100   _P_SetMobjState
...
Executed instructions:
  32.26%                    12335509                       render_wall_1x1
   6.07%   6.08%  18.12%     2320980   2323915   6927986   _P_MobjThinker
   5.69%   5.69%   5.69%     2174502   2176655   2176655   D_AllocPreview_Dynamic
   5.66%                     2162604                       R_VisPlaneShader
   4.92%   4.93%   4.93%     1882221   1884035   1884035   D_CachePreview
...
Used cycles:
  24.35%                    78395364                       render_wall_1x1
   7.47%                    24065992                       R_VisPlaneShader
   6.52%   6.54%  20.84%    21010728  21069320  67104928   _P_MobjThinker
   4.19%   4.20%   4.20%    13491592  13530880  13530880   D_AllocPreview_Dynamic
   3.76%   3.77%   3.77%    12111348  12152680  12152680   stream_texture
   3.68%   3.69%   3.69%    11849824  11883244  11883244   D_CachePreview
...
Instruction cache misses:
  20.47%  20.51%  51.81%      982023    983566   2484737   _P_MobjThinker
   7.46%   7.47%  59.54%      357890    358121   2855933   _P_RunThinkers
   6.74%   6.74%   6.74%      323104    323387    323387   _P_AproxDistance
   4.32%   4.33%   5.85%      207205    207561    280390   R_AddSpriteSpans
   3.87%   3.88%  20.72%      185781    185967    993870   _P_SetMobjState
   3.46%   3.47%   7.78%      166040    166437    372928   add_wall_segment

[dml]

Doesn't the current render start -> end profile already provide this?

Yes, I believe it does. I wasn't suggesting we need to do more here, just outlining which 'modes' I think are useful (much of which we already have / can do already).

Ok, but to have separate builds it might be better if Makefile would build both automatically, or at least have target(s) for that.

That's probably true - there's no reason to be stuck with a single target and changing settings locally for each view.

I don't think it's necessary to do it on real Falcon. Profiling happens in Hatari, so demo could be done under that too.

Actually I didn't mean a real Falcon specifically - the virtual one will do fine. I really just meant 'not a PC'

For Doom2 automatic profiling of 100 frame still works as it uses different triggers, but I'm not sure how useful is run of player wandering around in acid:

Indeed

7.67% 7.67% 38804 38804 _P_AproxDistance

..and looks like we could do with an inline version of _P_AproxDistance now too!


5.69% 5.69% 5.69% 2174502 2176655 2176655 D_AllocPreview_Dynamic

That's the memory view bar, or part of it. Not important. Will disable this soon so it doesn't skew profiling. I didn't realize it cost so much but I suppose it does spend significant time walking the chunk list and interpreting flags, with the drawing time being insignificant.


4.92% 4.93% 4.93% 1882221 1884035 1884035 D_CachePreview

Same here, but for the resource cache blocks...


Instruction cache misses:
20.47% 20.51% 51.81% 982023 983566 2484737 _P_MobjThinker

Yikes. This one is pretty annoying and maybe hard to solve. I'll spend a bit of time on that later.


6.74% 6.74% 6.74% 323104 323387 323387 _P_AproxDistance

Definite inline/asm candidate there.


4.32% 4.33% 5.85% 207205 207561 280390 R_AddSpriteSpans

This one is still to optimize. (I'm surprised it doesn't take longer TBH).

[dml]

Eero, the new code should allow profiling again.

The makefile now has -DTIMEBASE_CONTROL=X where X specifies the level of timebase management being done.

0 = Do nothing, so it's basically Doom with original 35Hz behaviour. Slow.

1 = What we were using previously i.e. an arbitrary 15Hz with no AI management, no physics changes so there's a slow motion effect but still watchable and demos still replay properly. This is probably best for profiling (although you may note the -timedemo switch behaves exactly the same for modes 0 and 1 since this command just makes sure every demo 'frame' is rendered to the screen without chasing realtime).

2 = Full physics and AI timebase scaling, with 12Hz timebase. Needed for gameplay. Breaks demo replay.

3 = Extra timebase optimizations for AI. Helps performance for gameplay. Breaks demo replay again.

[dml]

Even if BadMood uses a custom 256xNNN resolution, it would make sense to add a 32+32 pixel horizontal border to allow TFT monitors to scale properly, since the monitor will interpret this as a 320xNNN resolution.

I think the last time I did something like this, I used a screen expander (Videlity) to roughly select the mode I wanted and wrote a small TSR program to snap the videl registers to a file. Any small changes were then tweaked from there. It's been a long while and I don't remember many of the details for the Videl esp. the horizontal scan registers.

Are there any existing tools which would make this process easier? Or does it make sense to just do something similar again?

[shoggoth]

Are there any existing tools which would make this process easier? Or does it make sense to just do something similar again?

Screens Of Pain. I think you can find it at dhs.atari.org. It generates asm source code for you.

I've never played with border settings though, and Hatari doesn't show it accurately, so you'll need a real machine (or someone with a real machine) to do it.

[dml]

Screens Of Pain. I think you can find it at dhs.atari.org. It generates asm source code for you.
I've never played with border settings though, and Hatari doesn't show it accurately, so you'll need a real machine (or someone with a real machine) to do it.

Ok thanks for the tip. I'll have a play with that and see if I can get some new modes integrated.

[dml]

Using that tool it seems the closest I can get to a 256 pixel display on my cheap LCD VGA is 208 pixels, using 32MHz clock in chunky mode.

224 pixels or higher (or using 25MHz clock) and the test pattern displays incorrectly (the test pattern is 99% white rectangle which makes validation a bit tricky!)

Should I be able to manage better than this on a stock Falcon and will it depend on the monitor's range? I was sure I had used a 256 pixel mode in the past with BM & Videlity but it's so long ago now I don't remember exactly what the resolution was - it could have been a bit less.

[dml]

A quick test today got some results for the VGA 208x200-pixel video mode @ 56Hz / 32MHz dotclock....

The framerate reading for e1m1 startpoint rose from 6.86FPS to 7.44FPS - a performance increase of about 8%. (This is a relative comparison only - sprites, display linewidth and some other things are configured differently from previous performance tests so these figures can't be compared with anything posted previously)

The test was done without changing the render window size - it still renders 320x168 with only the video register settings being changed between tests so it's a reasonably good measure of change in Videl bus load and effects on BM's renderer (but not the game code).

8% does make it worthwhile esp. with the render window sized to fit.

I wasn't able to get anything sensible beyond 160 pixels using the 25MHz clock. While 160 pixels would equate to JagDoom and run a bit faster, the loss in resolution probably doesn't offset the moderate speed gain. It's not going to be as fast as the Jag version (which has a very wide bus and the GPU/DSP can access display memory after all) so it might as well have a slightly higher res. Having said that - it wouldn't be hard to prepare a 160 pixel version too.

As it turns out, software-drawn 'fat pixels' on an RGB monitor also works out at about 208 pixels (overscan 416/2) so the same resources etc. can be used for both.

[shoggoth]

Using that tool it seems the closest I can get to a 256 pixel display on my cheap LCD VGA is 208 pixels, using 32MHz clock in chunky mode.

224 pixels or higher (or using 25MHz clock) and the test pattern displays incorrectly (the test pattern is 99% white rectangle which makes validation a bit tricky!)

Should I be able to manage better than this on a stock Falcon and will it depend on the monitor's range? I was sure I had used a 256 pixel mode in the past with BM & Videlity but it's so long ago now I don't remember exactly what the resolution was - it could have been a bit less.

This sounds weird, 256xNNN shouldn't be a problem. I'm using 256x192 for my SMS+ port, and afaik it has no trouble on TFT screens etc. You shouldn't change frequencies or anything like that; start off with a 320xNNN mode and just adjust the number of pixels (320->256). Hicolor is tricky I guess since the app only works in 80 column modes, but there's a util in the same archive which can save the current resolution as an SCP-file. Import that SCP-file into Screens Of Pain, change the number of pixels, and you should be ok.

If you change frequences etc which affects how the monitor perceives the screen, I think you're doing it wrong.

[dml]

This sounds weird, 256xNNN shouldn't be a problem. I'm using 256x192 for my SMS+ port, and afaik it has no trouble on TFT screens etc. You shouldn't change frequencies or anything like that; start off with a 320xNNN mode and just adjust the number of pixels (320->256). Hicolor is tricky I guess since the app only works in 80 column modes, but there's a util in the same archive which can save the current resolution as an SCP-file. Import that SCP-file into Screens Of Pain, change the number of pixels, and you should be ok.

If you change frequences etc which affects how the monitor perceives the screen, I think you're doing it wrong.

If you're using 256 pixels then I'll keep experimenting - I'll try on a better monitor in case it's a problem with that.

I can't actually tell if the video mode is working or not - what I see is the testcard (which consists of 4 small right-angled 'corners' on a white screen) breaking up or flickering - or black, white alternating columns appearing instead. It could be a problem with the utility or the monitor. I just avoided settings which couldn't show the testcard properly and assumed those were out of range.

Changing the frequency was an afterthought - I get the same result if I just edit the horizontal pixel size and set the pixel mode to '4'.

[Eero Tamminen]

Are there any existing tools which would make this process easier? Or does it make sense to just do something similar again?

Hatari has "some" support for Falcon borders added by Laurent, and videl register values are shown by "info videl" command. One more thing for changing the frequencies is Videl inside.

PS. Thanks for the TIMEBASE define stuff, demos work now fine! I added to Makefile some documentation for it.

[Eero Tamminen]

For Doom2 automatic profiling of 100 frame still works as it uses different triggers, but I'm not sure how useful is run of player wandering around in acid:

7.67% 7.67% 38804 38804 _P_AproxDistance

..and looks like we could do with an inline version of _P_AproxDistance now too!

5.69% 5.69% 5.69% 2174502 2176655 2176655 D_AllocPreview_Dynamic

That's the memory view bar, or part of it. Not important. Will disable this soon so it doesn't skew profiling. I didn't realize it cost so much but I suppose it does spend significant time walking the chunk list and interpreting flags, with the drawing time being insignificant.

4.92% 4.93% 4.93% 1882221 1884035 1884035 D_CachePreview

Same here, but for the resource cache blocks...

I'm not seeing them in the normal 100 frames profile of attacks at all, so I guess they're peanuts in more hectic game play:

Code: Select all

Executed instructions:
  29.03%                    13961054                       render_wall_1x1
   7.69%   7.70%   7.70%     3699792   3703070   3703070   _R_PointInSubsector
   5.71%   5.83%  10.95%     2744042   2802557   5265091   _BM_P_CrossBSPNode
   4.65%   4.65%   5.12%     2238246   2237846   2462453 * BM_P_CrossSubsector
   4.39%   4.40%  38.81%     2112819   2115558  18663119   _P_MobjThinker
   4.16%                     2000037                       R_VisPlaneSkyShader
   2.84%                     1364022                       R_VisPlaneShader
   2.83%   2.84%  16.79%     1360044   1363484   8076015   _P_CheckPosition
   2.65%   2.65%   2.66%     1274534   1276460   1277288   _PIT_CheckThing
   2.55%   2.55%   5.30%     1224953   1227418   2548130   _P_BlockThingsIterator
   2.51%   2.51%   2.51%     1204790   1207664   1207664   stream_texture
   2.49%   2.50%  41.46%     1199438   1201288  19939241   _P_RunThinkers
   1.49%   1.51%   1.51%      716054    727478    727478   stack_visplane_area
   1.32%   1.32%   1.32%      635088    636550    636550   _P_UpdateSpecials
   1.23%   1.23%   2.84%      592691    593687   1366761   _P_BlockLinesIterator
   1.16%                      559463                       render_transparent_1x1
   1.13%                      545377                       R_BSPHyperPlane
   1.07%   1.08%  30.89%      516618    517658  14855874   add_wall_segment
   1.02%                      490742                       R_AddLine_loop
   0.94%   0.94%   1.60%      453087    453921    771238   R_AddSpriteSpans
   0.89%   0.89%  11.83%      427659    429087   5691377   _BM_P_CheckSight
   0.84%   0.85%   0.85%      405900    406666    406666   initialise_freetable
   0.76%   0.76%   0.76%      365495    365962    365962   R_ViewTestSpriteLines
   0.74%   0.74%   0.74%      356622    357209    357209   add_partition_segment
   0.73%   0.74%   1.27%      353351    353886    611236   _PIT_CheckLine
   0.72%   0.72%  17.51%      344459    345283   8422598   _P_Move
   0.72%   0.72%  10.32%      344246    344864   4964176   _P_LookForPlayers
   0.63%   0.64%  19.08%      305239    306256   9176889   _P_TryMove
   0.63%   0.63%   0.63%      304821    305123    305123   init_stategroups
   0.55%                      265863                       R_BSPHyperPlane_RHS
   0.53%                      254838                       build_ssector
   0.52%   0.52%  31.96%      248791    249279  15367754   _P_SetMobjState
...
Instruction cache misses:
   7.97%   7.98%  62.57%      668233    669682   5247963   _P_MobjThinker
   7.80%   7.82%  28.98%      654291    655573   2430924   _P_CheckPosition
   7.67%   7.68%  70.51%      643259    644119   5913746   _P_RunThinkers
   5.42%   5.44%   5.44%      454465    456589    456589   _R_PointInSubsector
   4.22%   4.23%  10.06%      354251    354753    843964   _P_BlockLinesIterator
   4.05%   4.07%   8.36%      340069    341233    700766   _P_BlockThingsIterator
   4.01%   4.02%   4.03%      336539    337555    338048   _PIT_CheckThing
   3.12%   3.12%   4.82%      261717    261975    404317   _PIT_CheckLine
   2.96%   3.34%   7.16%      247956    280149    600411   _BM_P_CrossBSPNode
   2.76%   2.76%   9.92%      231218    231621    831713   _BM_P_CheckSight
   2.61%   2.62%   3.56%      219089    219522    298500   R_AddSpriteSpans
   2.55%   2.56%   3.82%      213461    214500    320105   BM_P_CrossSubsector
   2.48%   2.49%  33.87%      207956    208461   2840321   _P_TryMove
   2.30%   2.31%   5.42%      193308    193827    454253   add_wall_segment
   1.89%                      158141                       render_wall_1x1
   1.83%   1.83%  49.22%      153141    153400   4128373   _P_SetMobjState
   1.73%   1.73%  30.87%      144893    145325   2589263   _P_Move
   1.40%                      117037                       build_ssector
   1.35%   1.35%   9.54%      113059    113367    800304   _P_LookForPlayers
   1.26%   1.26%   1.26%      105340    105828    105828   BM_P_CrossSubsector_vdelta
   1.21%   1.22%   1.22%      101836    102002    102002   process_lighting
   1.21%                      101368                       R_AddLine_loop
   1.19%   1.19%  27.02%       99643     99662   2266445   _P_NewChaseDir
   1.16%   1.16%   1.16%       97049     97299     97299   R_ViewTestSpriteLines
   1.03%   1.03%  25.77%       86276     86345   2161129   _P_TryWalk
   0.95%   0.95%   1.52%       79948     80067    127271   _P_BoxOnLineSide

(that's why it's important to get the info on the "worst frame".)

Instruction cache misses:
20.47% 20.51% 51.81% 982023 983566 2484737 _P_MobjThinker

Yikes. This one is pretty annoying and maybe hard to solve. I'll spend a bit of time on that later.

This is mostly due to JSRs to thinker subroutines.