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

[OldB0y]

Amazing work guys - this is definitely the best I've seen AB3D2 running on real H/W!

Have tried the exe from post 1061, and get the following:

A1200 with Blizzard 1260:
small screen, 1x1 pixel - between 15 -> ~ 29fps
full screen , 1x1 pixel - between 7 -> ~13 fps

A4k with A3660 (which tbh is actually not particularly quick)
small screen - 11 -> 19fps
full screen - 5 -> 11

If I get chance to try on my Vampire V2 1200 I'll let you know.

[abu_the_monkey]

Originally Posted by OldB0y

Amazing work guys - this is definitely the best I've seen AB3D2 running on real H/W!

Have tried the exe from post 1061, and get the following:

A1200 with Blizzard 1260:
small screen, 1x1 pixel - between 15 -> ~ 29fps
full screen , 1x1 pixel - between 7 -> ~13 fps

A4k with A3660 (which tbh is actually not particularly quick)
small screen - 11 -> 19fps
full screen - 5 -> 11

If I get chance to try on my Vampire V2 1200 I'll let you know.

I am impressed with the A3660 results considering the obvious lack of local fast ram.

[amipal]

Originally Posted by Karlos

That's not going to work. The game assumes a planar bitmap layout in chip memory that it c2ps on. We need proper RTG support for what you are trying to do.

Ah, that'd do it! I shall give it a skip for now then.

[Karlos]

Originally Posted by abu_the_monkey

yeah. its not that simple. the screen is an intuition screen but the c2p copies data directly into chip ram (or something). promoting to another AGA screen mode may be possible like dblPAL or euro36/72 but not RTG.

@karlos
is that how it works?

Yep

[OldB0y]

Originally Posted by abu_the_monkey

I am impressed with the A3660 results considering the obvious lack of local fast ram.

apologies - have just been playing it for a little while longer

the A3660 figures were a tad optimistic/and or was in 2x1 pixel mode

small screen = 5 - 11
full screen = considerably slower more like 7 max

the B1260 literally kicks its butt in every way possible!!

[abu_the_monkey]

Originally Posted by OldB0y

apologies - have just been playing it for a little while longer

the A3660 figures were a tad optimistic/and or was in 2x1 pixel mode

small screen = 5 - 11
full screen = considerably slower more like 7 max

the B1260 literally kicks its butt in every way possible!!

that makes more sense

[Karlos]

Does anyone have comparable benchmarks for the mod? I'm keen to understand if it takes a performance hit relative to the base game. Level A certainly has a lot more geometry and textures.

[abu_the_monkey]

I don't have any as yet but can try tomorrow (so long as things don't go sideways like over the weekend). Unless anyone else is in a better position to provide any info?

[abu_the_monkey]

@Karlos

I see you have been sewing the seeds for some conditional code based on which cpu is detected, the same code I shoehorned in to set the screen size to full screen if 040 or above could be expanded to detect if an fpu is also present and if it was a 881,882 or 040fpu.

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

I see you have been sewing the seeds for some conditional code based on which cpu is detected, the same code I shoehorned in to set the screen size to full screen if 040 or above could be expanded to detect if an fpu is also present and if it was a 881,882 or 040fpu.

If you look, you'll see I used your 040 detection to set the move16 flag. I'm keen to test optional FPU based transformation on 040/060 FPU.

[abu_the_monkey]

cool. not sure how the 060 is handled. I think testing bit 7 will tell you if its an 060 but not sure about the 060fpu.

*  Processors and Co-processors:
	BITDEF	AF,68010,0	; also set for 68020
	BITDEF	AF,68020,1	; also set for 68030
	BITDEF	AF,68030,2	; also set for 68040
	BITDEF	AF,68040,3
	BITDEF	AF,68881,4	; also set for 68882
	BITDEF	AF,68882,5
	BITDEF	AF,FPU40,6	; Set if 68040 FPU
;
; The AFB_FPU40 bit is set when a working 68040 FPU
; is in the system.  If this bit is set and both the
; AFB_68881 and AFB_68882 bits are not set, then the 68040
; math emulation code has not been loaded and only 68040
; FPU instructions are available.  This bit is valid *ONLY*
; if the AFB_68040 bit is set.
;
;	BITDEF	AF,RESERVED8,8
;	BITDEF	AF,RESERVED9,9
	BITDEF	AF,PRIVATE,15	; Just what it says

edit: shamelessly ripped this from another thread.

[abu_the_monkey]

Originally Posted by AlphaAmiga

Also, how do I change pixel mode (if it can be changed?).

I would like to run some FPS tests with my TF1260 at various speeds (if I can keep it stable).

I can also test my original disks install, the WHDLoad version and the versions everyone is working on if people feel the need?

'(' and ')' on the numeric key pad of real amiga will switch between 1x and 2x height/width pixel modes.
FYI 2x width modes do not work correctly at the mo.

[AlphaAmiga]

Originally Posted by abu_the_monkey

'(' and ')' on the numeric key pad of real amiga will switch between 1x and 2x height/width pixel modes.
FYI 2x width modes do not work correctly at the mo.

Thanks Abu

[AlphaAmiga]

Morning.

I am going to assume that this might be a bit of an ask, but, would it at all be possible for the game to output the monitored FPS to a file?

That way it would be great to then be able to copy the data over to a spreadsheet and compare overall FPS (average as well as highs and lows) when looking at performance across hardware and CPU frequencies.

Or, would it be possible to implement something in the vein of Quakes time demo where the game runs itself for a couple of minutes and then outputs its FPS statistics at the end, maybe also with detected hardware (this is deffo more of a nice to have)?

[Reynolds]

Quake's method is better I think, although never understood why it slows down when less polygons are visible on the screen during the turnaround. :P

[Karlos]

Originally Posted by Reynolds

Quake's method is better I think, although never understood why it slows down when less polygons are visible on the screen during the turnaround. :P

Is it not graphing the draw time, i.e. lower is better?

[Karlos]

Performance wise it is probably simpler and perhaps better to have three averages over longer time spans. A min and max tracker could also be added.

On the flipside, the game no longer shuts down the system so streaming the frame times to a file is possible. I'm not sure how safe that would be if/when the game crashes with open file descriptors that were being written to.

[AlphaAmiga]

That sounds quite sensible to me actually.

Would this be possible to implement do you think?

Could you also include a scan an output of the hardware on the system? E.g. 040 CPU AGA 2 MB Chip XMB Fast?

[grond]

Couldn't we just print to stdout? Amiga CLI does have some means of redirection, doesn't it?

[Karlos]

Originally Posted by grond

Couldn't we just print to stdout? Amiga CLI does have some means of redirection, doesn't it?

Sure, but the crash while streaming to disk scenario likely still applies there. I've had the game hard freeze on me and who knows what it might be doing in those circumstances.

The other thing is, given the typical state of Amiga IO, I wouldn't be surprised if any stream to disk would negatively impact the performance. If nothing else, consider the effect on CPU caches with all the buffers and what not.