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

[Karlos]

Illegal instruction?

Sounds like either code got overwritten or a jump to a nonsense location.

There is a function call via a pointer during initialisation, but the pointer is always initialised.

Try this. In the Draw_Init(), comment out all the calls to border_convert() and see if that makes the issue go away (the HUD will be blank/garbage)

https://github.com/mheyer32/alienbre.../c/draw.c#L177 - these calls are all indirect.

[paraj]

Tested a bit more, and perhaps it could be my fault. I was testing with a startup-script that runs with SCREENMODE=135168 (to auto select low-res PAL) since I don't like to use to mouse every time I test something. Manually selecting various modes it seems to work OK.

However I noticed two things that I think has to be fixed: 1) pr_WindowPtr should be set to -1 to prevent requesters (these will like cause a crash/b0rked state) and loading failures should be handle more gracefully - should cut down on Q/A time. 2) When I run with a debugger enabled I see issues (allocation failure by gfx library) - things should be debugger clean so we can focus on actual issues.

For reference my machine is recently recapped/checked A1200 + P5 B1260/50 (64MB fast) + KS/WB 3.1 + AGA only (but multisync monitor). DBLNTSC/MULTISYNC/etc. modes actually seem to work (though not in a way you'd play).

When I have some time I can look into some of these things.

[abu_the_monkey]

its not an instant guru. it takes a good few seconds before reboot to guru error message

[Karlos]

Originally Posted by paraj

Tested a bit more, and perhaps it could be my fault. I was testing with a startup-script that runs with SCREENMODE=1342771200 (to auto select low-res PAL) since I don't like to use to mouse every time I test something. Manually selecting various modes it seems to work OK.

However I noticed two things that I think has to be fixed: 1) pr_WindowPtr should be set to -1 to prevent requesters (these will like cause a crash/b0rked state) and loading failures should be handle more gracefully - should cut down on Q/A time. 2) When I run with a debugger enabled I see issues (allocation failure by gfx library) - things should be debugger clean so we can focus on actual issues.

For reference my machine is recently recapped/checked A1200 + P5 B1260/50 (64MB fast) + KS/WB 3.1 + AGA only (but multisync monitor). DBLNTSC/MULTISYNC/etc. modes actually seem to work (though not in a way you'd play).

When I have some time I can look into some of these things.

Can you confirm if the HUD digits are rendering correctly for you?

[paraj]

Originally Posted by Karlos

Can you confirm if the HUD digits are rendering correctly for you?

Ammo, energy and debug stuff seems fine. Is there an easy way to check the on screen messages you've also been working on?

[Karlos]

Originally Posted by paraj

Ammo, energy and debug stuff seems fine. Is there an easy way to check the on screen messages you've also been working on?

Check Vid_Present(), there's probably some commented out test calls.

[paraj]

Will try to check that and the other stuff more thoroughly a bit later. Unfortunately I can't verify RTG stuff (expect in WinUAE).

[Karlos]

The text stuff is independent of display choice as it renders to the fast buffer.

[Karlos]

Originally Posted by Karlos

The text stuff is independent of display choice as it renders to the fast buffer.

I think that in small screen mode however, it would be foolish not to render text to the otherwise unused area.

[Dunny]

Sorry for the delay. Downloaded from Karlos-TKG github as I don't have any facility to build my own. Ran the game/ folder's icon, chose AGA, AGA Dev, RTG and RTG Dev. 320x256x8 for RTG.

RTG show credits screens, with scrolling background and fire effect but cannot advance past those. AGA doesn't show credits (no text), but does have scrolling background and fire effects. Cannot advance past that screen in any AGA/RTG option.

Amiga 1200, PiStorm32Lite+Pi4 4GB (2GB FastRAM). 3.2 ROM softkicked by PiStorm. Running from CF Card on the PCMCIA slot if that makes any difference.

[Karlos]

So there's no menu at any point?

Does the display freeze or continue to animate?

[paraj]

Heading out in a minute, but I've had "luck" sometimes getting the menu stuck. It was waiting for the blitter to finish (in WaitFireBlits) but the blitter was inactive, and it never progressed.

Also in screen.c:102 VideoControlTags is called on a bad ColorMap (the window hasn't been created at this point).

[Karlos]

This sounds like an existing defect and not something introduced by the latest changes then.

[Dunny]

Originally Posted by Karlos

So there's no menu at any point?

Does the display freeze or continue to animate?

It continuously animates in all versions - AGA, RTG and Devs. The fire animates, the background scrolls. No mashing of keys, joystick buttons or mouse buttons allows you to advance past that screen however.

[paraj]

Originally Posted by Dunny

It continuously animates in all versions - AGA, RTG and Devs. The fire animates, the background scrolls. No mashing of keys, joystick buttons or mouse buttons allows you to advance past that screen however.

If it doesn't have a menu saying "Play game" it's still loading assets (or trying to at least).
Could you try the attached version? It replaces karlos-tkg/Game/bin/tkg_c_dev. Choose "RTG Dev" from the starting menu.
There should be an (ugly) overlay showing which file is currently being loaded. Does it get stuck on a file? Can just quit the game by pressing '*' (asterisk on the number) / PrtSc?

Originally Posted by Karlos

This sounds like an existing defect and not something introduced by the latest changes then.

Yeah, haven't found anything wrong with your changes except I've noticed that the ammo panel glitches a bit when the level is initializing (looks like it's updating the screen buffer while it's being displayed).

I found another defect: According to the documentation/NDK header files CINIT/UCopperListInit takes a UWORD specifying the size of the copperlist. However I've found that the KS3.1 ROM (at least) actually expects an ULONG. It multiplies it by 4 and passes it on to AllocMem. With an unpredictable value in the MSW of D0 that might cause some funny behavior (don't know if there will be memory corruption though). It did cause debuggers to trip up though.

I've fixed that as well, and added some code to gracefully shut down in case a file is missing for IO_LoadFile, and show an Alert on exit, rather than have the "Insert volume AB3" requester pop up on the default screen. I've kept the ingame "Insert Disk" logic for the queue, but the insert disk menu can now be quit as well.

Will cook up a PR a bit later.

EDIT: Debug build removed. Try newer version.

[Karlos]

@paraj

Great work, thanks. Please let me know when you have a PR ready.

Regarding the border glitch, the basic background image that includes the border contains a mock-up of some border digit states and values (it looks like to have a couple of weapons and number 4 is selected, even when beginning a new game). This likely gets flashed up on screen before I overdraw it.

I still haven't figured out why but I can't reliably determine which buffer is being displayed in planar modes either, which results in drawing the digits directly to both buffers always. I noticed that the original assembly language functions seem to do the same anyway.

[Dunny]

Originally Posted by paraj

If it doesn't have a menu saying "Play game" it's still loading assets (or trying to at least).
Could you try the attached version? It replaces karlos-tkg/Game/bin/tkg_c_dev. Choose "RTG Dev" from the starting menu.
There should be an (ugly) overlay showing which file is currently being loaded. Does it get stuck on a file? Can just quit the game by pressing '*' (asterisk on the number) / PrtSc?

No change I'm afraid. I've uploaded a video for you:

[ Show youtube player ]

Assigns are correct, I checked
It could be a PiStorm thing, but it's worked fine in the past.

[Karlos]

Originally Posted by Dunny

No change I'm afraid. I've uploaded a video for you:

[ Show youtube player ]

Assigns are correct, I checked
It could be a PiStorm thing, but it's worked fine in the past.

Tried choosing high spec (there's no need for low spec on a PiStorm) ? Maybe the low spec game link file has issues.

[paraj]

Originally Posted by Karlos

Great work, thanks. Please let me know when you have a PR ready.

PR created, and nitpicking/comments are fine since it's a bit of larger one. Also added handling of memory allocation failure while I was at it.
A thought: Maybe if Open fails it would be best to also try relative to PROGDIR:. Doubt many people will be playing from floppies these days.

Originally Posted by Karlos

Regarding the border glitch, the basic background image that includes the border contains a mock-up of some border digit states and values (it looks like to have a couple of weapons and number 4 is selected, even when beginning a new game). This likely gets flashed up on screen before I overdraw it.

A bit weird, but no big deal. Only seems to happen when the level is initializing.

Originally Posted by Karlos

I still haven't figured out why but I can't reliably determine which buffer is being displayed in planar modes either, which results in drawing the digits directly to both buffers always. I noticed that the original assembly language functions seem to do the same anyway.

The way you're doing it (only updating on change) all (both) buffers have to be updated though, right? So seems fine unless you want to do a two-step update.

Originally Posted by Dunny

No change I'm afraid. I've uploaded a video for you:

[ Show youtube player ]

Assigns are correct, I checked
It could be a PiStorm thing, but it's worked fine in the past.

Time for some good, old fashioned printf debugging. Please replace tkg_c_dev with the attached (hiresC) executable and try again. It should print some stuff on the screen (waiting a second or so between each update) that can hopefully tell us where it's stuck. It should just show a single line of text while loading.


(N.B. @Karlos: low spec seems to work for me)

[Karlos]

Yeah, really I just wanted to avoid drawing on the visible display (and doing a second update after the next flip on what was is now the draw buffer) but that's probably over-thinking it. You might also see it when resizing the pillarbox mode.