Compileable version of Alien Breed 3D II - The Killing Grounds

[abu_the_monkey]

Originally Posted by Dunny

Quick question: Any way to invert mouse vertical axis (or prevent the mouse from looking up/down entirely)? I just cannot get along with the way it's set up at present!

the new years edition from post #1278 has the option to invert the mouse so up is down and down is up

[grond]

Originally Posted by Karlos

There could be faster ways to do the eclock timeval difference calculation with inlined sub/subx pair to perform the 64-bit difference without calling the library routine.

Well, it's a once per calculated frame penalty that is only there if the FPS are calculated and displayed (i.e. debugging version, not release version of the game).

Other things I thought of were having an array buffer of the last 4 or 8 frames and incrementing a buffer position (modulo the buffer length) to record the next time into, and using the average of all values in the buffer for the FPS. This is like your averaging of the current and last, just spread over more samples.

The current algorithm averages between the current frame time and the previous averaged frame time. This means the current average value is determined by 0.5*current frame, 0.25 preceding frame, 0.125 the frame before that, 0.0625... You get the idea. Disregarding the limited precision of the calculation, one could say that all frame times influence the resulting value but the more current frames have a much higher influence on the result than older frames. Thus, you get averaging over more values for very little effort. On the other hand, there are some disadvantages inherent to the long memory of the "algorithm". E.g. he FPS stats may be too optimistic for a current complex scene because previously you had been looking at a very simple scene or vice versa.

[Karlos]

@grond

As I said, these are not optimisations or changes I consider remotely worth the effort which is why I merged them anyway. It was more to answer the question "what might I have done differently".

The averaging of the last 8 frames is specifically to avoid the memory effect you described but to be fair, the influence of each previous frame is halved every time so it's not actually a big deal.

[utri007]

Would it be OK to ask compiled new versions to first post?

[Karlos]

I've updates the makefile to have a dev target and began conditionally assembling all the instrumentation. I've also moved it to it's own source file.

Once I've finished tidying I'll actually start implementing the stuff I intended in the dev build.

[abu_the_monkey]

Originally Posted by Karlos

I've updates the makefile to have a dev target and began conditionally assembling all the instrumentation. I've also moved it to it's own source file.

Once I've finished tidying I'll actually start implementing the stuff I intended in the dev build.

have you got your real amiga up and running now?
I don't think testing under emulation will be that representative as I believe the cpu emulation is not instruction timing correct for 68020 and above, I could be wrong however.

[Karlos]

Originally Posted by abu_the_monkey

have you got your real amiga up and running now?
I don't think testing under emulation will be that representative as I believe the cpu emulation is not instruction timing correct for 68020 and above, I could be wrong however.

No, I'm afraid I haven't yet. However what I'm looking for are smaller code paths, less data duplication, etc.

I tried to add you as a reviewer to this PR but I think you may need to be a collaborator. Either way, it moves the code you've added and makes some renaming changes: https://github.com/mheyer32/alienbreed3d2/pull/56

It also leverages the fact that the frame render and c2p timing calls are adjacent and simplifies it a bit to get 2 fewer eclock calls per frame.

To build with instrumentation you now have to do "make dev". The default behaviour is to build the "release" version.

[abu_the_monkey]

looks good to me

[Karlos]

Originally Posted by abu_the_monkey

looks good to me

I'm probably going to move the info into a horizontal line at the foot of the display where the in game messages used to render, assuming the full height is still 256 pixels. That way avoid overdrawing the play area. Can probably get away with a single text buffer and Text() call then too.

[Karlos]

@grond & @abu

I noticed in the frame timing, d1 seems to contain the result of SubTime(), but according to the autodocs, this is supposed be a void return. Is this behaviour documented somewhere? Or did I just misread what was going on?

[abu_the_monkey]

This may well be a mistake? by me.

[Karlos]

Originally Posted by abu_the_monkey

This may well be a mistake? by me.

Well, it works. If I had to guess it's the ABI saying d0 and d1 can't be trusted after a function call. If I had to guess how the SubTime() was implemented I'm going to guess at the aforementioned sub/subx pair. It may well be that d1 happens to contain the lower 32-bit difference afterwards.

Maybe the assembler includes say different than the C docs.

[grond]

AddTime() and SubTime() store the result in the first of the two specified timeval structs. If the result is also available in d1, this is probably an undocumented and unreliable side effect of the implementation of the timer.device. Future versions or alternative implementations (AROS) could do it differently.

[Karlos]

@grond & @abu

I may update the instrumentation code to just record a number of eclock values per frame at certain points in the code and then do all the analysis in one place at the end. At the moment we have discrete start/finish markers per thing measured, although I've consolidated a pair of them, there are still the same marker values due to the destructive nature of SubTime(). Not in a rush to do it but I think consolidating it makes sense.

[abu_the_monkey]

Modify away, your the guy who's going to be using it.

[shelter]

Does a 060 compiled version make any difference for such a system?
I can't really try myself as I don't have an 060.

[Karlos]

Originally Posted by shelter

Does a 060 compiled version make any difference for such a system?
I can't really try myself as I don't have an 060.

It's not compiled, it's assembled. It is set for 68060 but from an optimisation perspective assemblers are pretty restricted in what they can do.

[Karlos]

Any word on what pipper is up to?

[shelter]

Originally Posted by Karlos

It's not compiled, it's assembled. It is set for 68060 but from an optimisation perspective assemblers are pretty restricted in what they can do.

Ok, good to know. Yeah I keep writing compiled because it's the thread title.

[abu_the_monkey]

@Karlos
not heard anything for a while, I have seen him popup as being on line here on eab a couple of times recently.