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

[abu_the_monkey]

are any of these 'real amiga' setups running kickstart 3.1.4 or just the standard 3.1, 3.5, 3.9 ? cos under winuae the current build works for me with ks3.1.4 but bombs with 3.1 (both bare bones/vanilla installs of workbench for each. everything else is setup the same) maybe it is a bug in the kickstart libraries but then again it is easy to miss stuff with assembly language.

[abu_the_monkey]

Originally Posted by Angus

Just to add, I tried to run the program on my Blizz 1260 AGA machine, when I ran it on Hires, all went black and stayed that way. When I tried the standard(?) exe I got nessages saying that Hires wasn't executable, then the same for segtracker, then for vbrmove.....

For installation I basically copied the contents of the data directory from the WHDLoad install into a new directory AB3D2_Run - then copied the contents of the Fresh archive over that.

getting a black screen only without a crash/guru sound more like an assign is not correct.

[Jacques]

Nope, I had the same on Warp 1260 with assigns done, but standalone hires stayed on black screen. Running included TKG script from an icon works. Of course all entries that are run by the script required setting executable attrib manually beforehand.

[abu_the_monkey]

fair enough, 2 can't be wrong. and was that with ks3.1 or 3.1.4 or other?

[Angus]

Originally Posted by abu_the_monkey

fair enough, 2 can't be wrong. and was that with ks3.1 or 3.1.4 or other?

Kickstart 3.1 here.

[Karlos]

In order to help debug some of the visual issues, I've branched my mod (not pushed yet). I've created a simple 3 zone level A that performs texture scale and alignment tests.

[ Show youtube player ]

[abu_the_monkey]

wow! that really shows up the wall/floor/ceiling alignment issue far more so than when your playing the game.
good job

[paraj]

Tried it on my 1200 (P5 Blizzard 060, KS3.0/WB3.1) and the pre "system friendly" version works, but latest (after fixing 2 bcc.s -> bcc.w) does not. The SystemPatch299 thing didn't help either, also tried increasing stack massively, and that didn't help either. Tried running it with MuForce/MuGuardianAngle, but didn't get anything useful. There's a bit of graphics corruption before it hangs with a gray (WB default background) screen.

Perhaps some other OS data structure (like an IORequest) is being corrupted, but it only shows later on? Or maybe some bitmaps (etc.) aren't aligned properly?

Some random ideas to help debug it:
- Comment out code until it works (even unrelated things), then comment things back in until it doesn't.
- Pad all data structures with free space around them starting with OS related ones (i.e. just have ds.l 1024 before and after each one that could possible be affected).
- Check all interrupt related code for whether it really saves all registers etc. Also maybe using system friendly routines changes assumptions of which interrupts can be disabled etc.

[Karlos]

Originally Posted by abu_the_monkey

wow! that really shows up the wall/floor/ceiling alignment issue far more so than when your playing the game.
good job

I'm going to start adding levels that test other features

[abu_the_monkey]

excellent

[Karlos]

Originally Posted by abu_the_monkey

excellent

I was a bit surprised to find the floor textures seem to be mirrored.

[abu_the_monkey]

is it the same for the ceiling if you change the texture?

[Karlos]

Originally Posted by abu_the_monkey

is it the same for the ceiling if you change the texture?

I'll have to try it. One thing I discovered by accident is that both the upper and lower halves of a vertically split zone count as the exit. That could be put to some good use in level design.

[abu_the_monkey]

I don't see that so much as a bug but more of a feature
need's remembering/documenting for anyone else wishing to create mods.

do you know if the 'enemy/aliens' can use the teleports? I seem to remember that it crashes the game if they happen upon one.

[Karlos]

I'd be interested to know if it has any cache impact. Floor texturing doesn't have any fixed texture "scan direction" though so maybe not. I wonder if any games that did this sort of "flats" rendering for floors and ceilings ever used subpatch arrangements to improve cache locality?

[pipper]

I once tried to do that in Doom. I.e arrange groups of 4x4 floor texels such that they lie linearly in memory, 16byte aligned. This should make sure that the whole group of 16 pixels gets bursted into one cache line and after the first texel access there’s a high chance that the next texel access is already cached.
But it didn’t make a notable difference. The texel addressing gets more complicated and the cycles saved on fetching may be spent on computing the texel address (in particular on an 030). To be effective it also requires that the next texel access is close to the last one, which can only be ensured if mipmapping is available for distant textures (where otherwise we‘d be skipping through the texture at steps larger than 4x4).
To be honest, I didn’t measure things properly back then, so it still may be worthwhile… but I don’t expect much of a boost from it. It may be first interesting to know how much time overall we spend in various parts of the rendering.

[Karlos]

Originally Posted by abu_the_monkey

do you know if the 'enemy/aliens' can use the teleports? I seem to remember that it crashes the game if they happen upon one.

They are supposed to be able to. It's even a recommendation made in the editor docs: How To: Create Challenging Levels

I can create a simple test level for that. Create a simple corridor where a walking alien has to follow control points that take it through a teleport zone. This then teleports it back to a starting point close to where it originates. The player spawns at the other end, visible to the enemy.

If the mechanism is bust we'll know immediately :

[Karlos]

Originally Posted by pipper

I once tried to do that in Doom. I.e arrange groups of 4x4 floor texels such that they lie linearly in memory, 16byte aligned.

Interesting. It's a technique used in a lot of older fixed function GPUs for both texture and zbuffer.

It may be first interesting to know how much time overall we spend in various parts of the rendering.

I have a plan for exactly this tbh. When working on warp3d drivers I added conditionally compiled instrumentation (via function enter/exit hooks) that was quite useful. A report would be generated when the context was closed. I was thinking of something similar when the level exits. Would involve writing to disk though, so may need some precautions there.

[abu_the_monkey]

can someone try this on os 3.1 and see if it runs please

[abu_the_monkey]

Originally Posted by Karlos

They are supposed to be able to. It's even a recommendation made in the editor docs: How To: Create Challenging Levels

I can create a simple test level for that. Create a simple corridor where a walking alien has to follow control points that take it through a teleport zone. This then teleports it back to a starting point close to where it originates. The player spawns at the other end, visible to the enemy.

If the mechanism is bust we'll know immediately :

probably something I was doing wrong as per usual
but would be nice to know either way