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

[Karlos]

Originally Posted by abu_the_monkey

I had a quick look and to me it's about as clear as mud and made my head hurt

I have limited time so what I've been doing is creating simple levels and then hex dumping the level files to try and get more insight into the data. It's frustrated slightly by the fact that several of them (not all) are packed in that =SB= format and need to be decrunched first.

There's some structure poking after these are loaded too, but hopefully with a bit of patience we can figure out what the end runtime representation of the data is, and that should make interpreting the code easier.

[Karlos]

If anyone fancies having a go at deciphering the level data structures, I have hex dumps of five test levels in a branch of my mod.

https://github.com/0xABADCAFE/karlos...evel_A/HexDump

I've been diffing these for successive levels that each add an extra zone, but don't have much time just now to really drill into it.

[abu_the_monkey]

Probably won't have time over the weekend, got the in-laws over

[Karlos]

Originally Posted by abu_the_monkey

Probably won't have time over the weekend, got the in-laws over

There's a lot of pointer arithmetic in the code that loads the level files. Been reading through it and cross referencing with the hex dumps. But that's between standard weekend duties.

[Karlos]

I've been staring at this seemingly innocuous bit of code for ages and I can't decide on what it is actually doing, or rather, intending to do:

https://github.com/0xABADCAFE/alienb...e/hires.s#L405

This is after figuring out most of what is being pointed to by a0-a4 at this point also. Clip data is being poked into some region of the Zone structure for each zone (I think) but I feel like I'm missing something obvious, possibly because I keep coming back to it after a long work day.

On the plus side, I've made some headway into understanding the data strucutres in the level files https://github.com/0xABADCAFE/alienb...ce/defs.i#L436

[abu_the_monkey]

;
; LEVEL DATA FILES
;
	; twolev.bin data header, after the text messages (first: LVLT_MESSAGE_LENGTH * LVLT_NUM_MESSAGES)
	STRUCTURE TLBT,12
		; todo - what are the first 12 bytes?
		UWORD TLBT_NumControlPoints_w		; 12
		UWORD TLBT_NumPoints_w				; 14
		UWORD TLBT_NumZones_w				; 16
		UWORD TLBT_Unk1_w					; 18
		UWORD TLBT_NumObjects_w				; 20
		ULONG TLBT_PointsOffset_l			; 22
		ULONG TLBT_FloorLineOffset_l		; 26
		ULONG TLBT_ObjectDataOffset_l		; 30
		ULONG TLBT_ShotDataOffset_l			; 34 - this in twolev.bin ?
		ULONG TLBT_AlienShotDataOffset_l	; 38 - this in twolev.bin ?
		ULONG TLBT_ObjectPointsOffset_l		; 42
		ULONG TLBT_Plr1ObjectOffset_l		; 46
		ULONG TLBT_Plr2ObjectOffset_l		; 50
	LABEL TLBT_SizeOf_l						; This is the end of the header

I think the first 12 bytes in twolev.bin are plr1 x, plr1 y, plr 1 start zone, plr2 x, plr2 y, plr2 start zone. or something like that.

[Karlos]

Originally Posted by abu_the_monkey

I think the first 12 bytes in twolev.bin are plr1 x, plr1 y, plr 1 start zone, plr2 x, plr2 y, plr2 start zone. or something like that.

I hadn't bothered looking into that yet, but that sounds plausible.

By first 12, you mean after the 1600 bytes of text data for the messages, I assume.

[abu_the_monkey]

what is TLBT_Unk1_w ?

[Karlos]

Originally Posted by abu_the_monkey

what is TLBT_Unk1_w ?

I don't know yet (hence unknown). It could just be a gap where a field that was originally a long ended up being used as a word.

[abu_the_monkey]

By first 12, you mean after the 1600 bytes of text data for the messages, I assume.

yes.

[abu_the_monkey]

Originally Posted by Karlos

I don't know yet (hence unknown). It could just be a gap where a field that was originally a long ended up being used as a word.

ah, ok. I couldn't figure out the abbreviation, makes sense now

[abu_the_monkey]

don't want to cause confusion but these are the offsets for ab3d1 that John Grivin used to recreate the levels in quake 1 map format, some may be similar

#define    BINOFS_P1X        0
#define    BINOFS_P1Z        2
#define    BINOFS_P1ZN        4
#define    BINOFS_P2X        6
#define    BINOFS_P2Z        8
#define    BINOFS_P2ZN        4
#define    BINOFS_NUMPTS    14
#define    BINOFS_NUMZN    16
#define    BINOFS_PTRPTS    16+6
#define    BINOFS_PTRFL    20+6
    // offsets in level bin file

#define    GRAOFS_PTRDOOR    0
#define    GRAOFS_PTRLIFT    4
#define    GRAOFS_PTRSWTCH    8
#define    GRAOFS_PTRGRA    12
#define    GRAOFS_PTRZN    16
    // offsets in level graphics file

#define    ZNOFS_NUM        0
#define    ZNOFS_LFH        2
#define    ZNOFS_LRH        6
#define    ZNOFS_UFH        10
#define    ZNOFS_URH        14
#define    ZNOFS_WH        18
#define    ZNOFS_EDGES        32
#define    ZNOFS_PTS        34
#define    ZNOFS_TELZN        38
#define    ZNOFS_TELX        40
#define    ZNOFS_TELZ        42
    // offsets in zonedata

#define    FLOFS_SX        0
#define    FLOFS_SZ        2
#define    FLOFS_XO        4
#define    FLOFS_ZO        6
#define    FLOFS_ZONE        8
    // offsets in floorline data

[Karlos]

I expect some format differences but only around point lighting which is probably twice the size. I wouldn't be surprised if the rest is the same.

What I am trying to get to is what the runtime representation ends up as after it's all loaded and poked together.

[Karlos]

I might simplify that by having a hotkey to dump the structure of the current zone and any things that it has pointers to (perhaps not objects). It could even perhaps do it for all the zones in the PVS depending on how monstrously verbose it is.

Understanding some of the higher level algorithms looking at the (mostly undocumented) code is like trying to understand the shape of a sandcastle from individual grains

[utri007]

Sorry my ignorance, but where to get latest build?

Could they be in first post?

[Karlos]

Originally Posted by utri007

Sorry my ignorance, but where to get latest build?

Could they be in first post?

I usually keep a build of the latest "stable" binaries here:

https://github.com/0xABADCAFE/karlos.../main/Game/bin

[Karlos]

Originally Posted by abu_the_monkey

I think the first 12 bytes in twolev.bin are plr1 x, plr1 y, plr 1 start zone, plr2 x, plr2 y, plr2 start zone. or something like that.

Not sure about the Y component (which is height, in the engine coordinate scheme) but I have confirmed that the player x and z components are here:

From Plr_Initialise:

		move.l	Lvl_DataPtr_l,a1
		add.l	#160*10,a1 ; message data
...
		move.w	(a1),Plr1_SnapXOff_l
		move.w	2(a1),Plr1_SnapZOff_l
		move.w	(a1),Plr1_XOff_l
		move.w	2(a1),Plr1_ZOff_l
		move.w	6(a1),Plr2_SnapXOff_l
		move.w	8(a1),Plr2_SnapZOff_l
		move.w	6(a1),Plr2_XOff_l
		move.w	8(a1),Plr2_ZOff_l

Starting zone ID for offset 4 and 10 also confirmed.

[Karlos]

There's a motif I keep seeing in the code (now that we have symbolic names for most of the constants/offsets, things like this keep creeping up):

   ; d0.w contains a Zone ID - calculate the Zone address pointer

   move.l Lvl_ZoneAddsPtr_l,a0 ; Lvl_ZoneAddsPtr_l is a table of 32-bit offsets from Lvl_DataPtr_l
   move.l (a0,d0.w*4),a0
   add.l  Lvl_DataPtr_l,a0
   ; now a0 contains the zone address

What I don't get is, why wouldn't you just convert Lvl_ZoneAddsPtr_l into a straight list of pointers after loading the level data by adding Lvl_DataPtr_l to each element?

Then you can save the extra address addition step wherever you dereference.

[abu_the_monkey]

Originally Posted by Karlos

Not sure about the Y component (which is height, in the engine coordinate scheme) but I have confirmed that the player x and z components are here:

From Plr_Initialise:

		move.l	Lvl_DataPtr_l,a1
		add.l	#160*10,a1 ; message data
...
		move.w	(a1),Plr1_SnapXOff_l
		move.w	2(a1),Plr1_SnapZOff_l
		move.w	(a1),Plr1_XOff_l
		move.w	2(a1),Plr1_ZOff_l
		move.w	6(a1),Plr2_SnapXOff_l
		move.w	8(a1),Plr2_SnapZOff_l
		move.w	6(a1),Plr2_XOff_l
		move.w	8(a1),Plr2_ZOff_l

Starting zone ID for offset 4 and 10 also confirmed.

My bad, must have been thinking in 2d

[Angus]

Immediately thinks of conversation between Spock and Kirk, in The Wrath of Khan.
"Take us down, Mr Sulu, 300 metres."


..... sorry.