@paraj

I'm not having that issue, but I'm also using a 68040 emulation. My issue is that the game flat out refuses to work without giving UAE a big wedge of imaginary chip memory.

Here it is running the result of the most recent commits that fix the fullscreen water submersion crash: https://youtu.be/0rvaRBLOg3w

I do not understand how one of my setups runs everything you can throw at it and all the rest die on their arse. I had this when I was trying the develop a 68k quake engine for Qbreed and flat gave up as it made no sense. I put it down to my lack of knowledge.

The devpac build definitely doesn't have the weird massive ChipRAM requirement in UAE. I'm going to have to carefully read the vasm and vlink docs.

I was not using vasm for the quake builds, but, was developing in winuae. that is not that odd, but, when everything works on your dev setup only? odd.

also, the devpac build was a much older version of the source code.

The "works on my machine" phenomenon in enterprise software ultimately led to shipping everything in docker containers... Allegedly.

What I'm keen to do is test one of these executables on my real A1200. That will involve putting the HD back in, cleaning out dust and most terrifying of all, turning the damn thing on.

fingers crossed it don't release any magic smoke.

Yeah, there's no chance it will happen before the weekend. And little that it will happen during lol

I pushed some experiment to the 'link_with_gcc' branch.
It links with GCC and tries to emulate assembling devpac. Let me know if it makes a difference.

This is a really puzzling bug - for me the executables work just fine in WinUAE and on a real A1200 with either 060 or 030 accelerator in it.

The only thing odd on the real machine is that the music replay seems off timingwise.
Maybe its time to invest some effort into getting actual debugging working. WinUAE debugging seems impossible. Bebbo's bgdbserver is ill suited for the task. Maybe something native + WinUAE's ability to inject NMI's will do...

The memory issue in UAE is definitely something I need to compare to a real system to rule out some chicanery of it just being a UAE thing.

Something I'm keen to look at instead in the meantime is the water, lighting and vector object animation speed. Unlike sprite and projectile animations which continue to work normally, these seem to update a fixed amount per frame and end up ludicrously fast when running under emulation. Running the game at a rock solid 50fps but not having an epileptic fit to go with it will be nice.

In semi related news, I think I've found the project directory and editor assets for my mod.

I have been trying to reproduce the startup problem and got some form of lead.
I created a barebones 3.1 A1200 030 with 32MB of ZIII fastram. It will crash pretty much immediately after startup.
In this config the WinUAE debugger seems to work. It even supports a form of "source level" debugging.
I.e. one can create a label in the source like 'Test:' and then in the debugger run
which will then break into the code at the line Test.

The commands 'z' and 't' let you single-step the code.
I followed the code until the crash... weirdly it happens when opening the Intuition window here
https://github.com/mheyer32/alienbre...eensetup.s#L46

Somewhere deep down in the OS code it copies some data from inaccessible addresses to somewhere else.

So maybe it's a value being interpreted as an address that happens to fall into the region where the new "32-bit addressable" chip memory is located in UAE. Specifically somewhere between $10000000 and $10ffffff which is where showconfig reports it to be.

Great that you're making progress on the debugging. Unfortunately the code is much too complicated for me to make good suggestions, but one thing I tried was to use the repo just before the "sysfriendly" change and just change the interrupt from COPPER to VERTB and it still worked FWIW.

If I were you I'd try to comment out as many parts of the code as you can and see when it stops crashing starting with anything that's run in interrupt context.

Is the taglist for the open window correctly terminated?

More generally, I was thinking that if the goal is to make a more system friendly version, perhaps it's better to implement new parts that handle resource allocation like windows, bitmaps and such (especially for RTG) as external C files that export assembly language callable entry points and link them. I'm certainly more familiar with writing this sort of code in C than I am 68K these days. We aren't talking about performance critical operations here, just ease of implementation and safety. Thoughts?

Purely as a player, (no coding skills) I thought TKG attempted to be a high res AB3D sequel for faster Amigas, but largely failed as it seemed like it attempted to do too much and perhaps required more time and resources for the author to optimise things.

I don't know if it's even an option but maybe a system friendly version would allow specific parts of the engine to be "reduced" so that the game could deliver a good player experience on an 030 AGA type machine?

Would there be any implications for an easier the TKG editor which I gather was a bit of a nightmare to use?

I think there's a lot of scope for performance improvement but much of that involves extensive rewriting of the rendering code.

One more data point: using 3.1.4 ROMs in WinUAE makes the 'hires' executable start up instead of crashing. I have no idea why... TKG is not using any fancy 3.1.4 features...