Getting Napalm to run on AmigaOS 4.1.2?

@alfkil

Are there any more updates to your patch planned to fix the enemy AI timing and or sound issues?

@TheKorn

I would really very much like to do an update that fixes the difficulty problem. I don't know what you mean by sound issues, here it works perfectly well now.

The problem with the difficulty in level 2 is, that it is going to be hard to pin down the problem. You have to understand, that I do NOT have the source code for this game, and so the only way to go is by disassembling. The parts, that I have fixed so far, are all distinguishable by making references to system objects, which are detectable in the code. The part that concerns gameplay is completely uncommented and unstructured, so it is going to be like finding a needle in a haystack. When all that is said, I might try at some point to go in there and see what I can do...

@TheKorn
Napalm has the same problem with difficulty under WinUAE (with JIT).

I am guessing that the CPU is used for timing certain in-game events, and when it is too fast things happen too quickly... or it may be something far more complicated than that!

@ChrisH

In this case, the game probably uses timer.device functions. Maybe Alfkil can look for them in the ASM. But it's only the visible part of the iceberg.

@Elwood

See that's the problem: There is a "timer.device" string in the code, but it is not used for anything. Also if you notice the time written during gameplay in the upper left corner, it doesn't nearly follow real seconds no matter how you set the game speed.

I have located a counter, that might have something to do with the timing, and I have tried slowing it down, but this doesn't solve the problem either. So I am basically stuck...

EDIT: By the way: Has anyone tried the preliminrary NETWORK.SERIAL driver?? I'm dying to see if it works or not!

@alfkil

Just for laugh: maybe you can try to change timer.device string on something like "#OOPS#.device" , and then trying to run a game. If it will crashy, buggy, or have any kind of problems , then timer.device is indeed uses somehow. If no changes will happens, then nope. Through strange why string present at all then.

@kas1e

If I did that, it would just fail with a recoverable error saying, that I cannot open the serial device. And it's not necessaery: I can very easily see from the code, that the timerrequest is only referenced in opening and closing the device, and TimerBase is only referenced by one function, which calls GetSysTime, and the resulting timeval struct is not referenced anywhere else in the code. So it is a nil reference.

@alfkil

Got it .. Anyway, that info from CrhisH that "Napalm has the same problem with difficulty under WinUAE (with JIT)." sounds intersting. Maybe TonnyW (author of winuae) can help here more, or Rachy (who do petunia for aos4, and who works now on ppc-jit for e-uae).

Also, if it happens on winaue and only with JIT, maybe for that purposes add napalm to black-list for JIT and check if without JIT all will be fine ? And if so, then Rachy can help imho here.

Today retested the latest patch from os4depot with original NapalmCD - still works on latest os4 with all beta stuff, cool :)

@All
Alfkil uploads the latest sources with fixes he has (that patch which on os4depot), so I reupload it there just it not die:

https://kas1e.mikendezign.com/aos4/68k ... /Napalm/crimsoncrisis.asm

@Alfkil

Btw, what do you mean by "timing issues", how to reproduce them?

For myself, I have issues mostly with save/load being totally broken and crashes.

@kas1e

There is a timing bug, that makes it impossible to win in level 2 of the game. The enemy attack comes too fast, which makes it impossible to build up ressources to win the battle.

There are references in the code to some of the custom chips, that have to do with timing. I think these references are responsible for the error, but I never made it through to understand, what was going on. Maybe you can do a better job.

@Alfkil
For myself I have found 2 issues that IMHO need to deal with before timing bug:

1. Save/Load does not work. Dunno if both, or just a Load.

For first loading screen messed up (click to open in new tab for full-size):




For the second, with enabled Petunia, we just crash when trying to load anything. There is a crash log with Petunia enabled:

https://kas1e.mikendezign.com/aos4/68k ... s_2022-01-14_22-55-39.txt


I assume that can be related to the mess we have in the loading screen which trash the memory and crash appear to be visibly when petunia optimizes things. So maybe fixing a visual issue in the loading screen will deal with the Petunia crash as well.

2. The pointer in the menu is wrong when highlighting items for the size of the previous item. I.e. when you come to the Game Controls for example and want to choose something in scroll response, you need to move the mouse cursor between "scroll response" and "digital audio" items. Like things for menu starts wrongly calculate the first item.


3. The second bug can be a cross-bug of timing issue: if you play a bit with settings of game-speed and scroll-control, you have sometimes weird behaviors (too fast move of the screen even if it is off, and so on).

But 3st not that important one (At the moment) as 1 and 2, because firstly need to deal with things we can understand, and then have a look at timing bug (which probably can be related and to 3, but 3 can be a good test case of it, if that of course related to timing bug in end).

@kas1e

That loading screen does not really look messed up, but the areas where there is text have the background behind darkened which would happen in cases like where someone had had a 32 bit truecolor screen, read the pixels into a 16 bit truecolor buffer and write it back to 32 bit screen.

The asm source you linked contains lots of data (dc.l, dw.c) which is code. For example LAB_0323 is code which calls timer.device/GetSysTime() and stores timeval.tv_secs at 14c(a4).

@Georg
Quote:

Mean shouldn't be very hard to fix once found a place in the code?

Quote:

By default, IRA tries to analyze parts of binary which is code and data, etc but of course, can't do so with 100% result. So for that one always should run IRA like "ira -a -preproc", and then when .cnf is created, by hands made it better and better by showing what kind of regions are text, what code, etc, etc. Alfkil probably just disassembly it as it, and work on what he got.

I will try to build what Alfkil upload and compare if it is the same which we have on os4depot or not...

@Alfkil
I compiled your source code, and it seems too old version. It just gives me the same issues as the original one. Even the screen mode chosen screen is old one.

Can you check maybe you have a newer version somewhere which was one from which os4depot's patches were done?

@kas1e

I think the most up-to-date version of the file is located on my Sam, that resides with a friend for the time being. I can get it earliest by the end of next week.

If you are in a workflow, I suggest you work your patches from what you have now. AFAIR the changes, that are needed, are pretty easy to spot. Basically all calls to RtgMaster.library need to replaced by calls to graphics.library. If you manage to do this, you should have a running version with very few bugs (there are still some graphics in the in-between-games screens, that are off). And if you get this far, then maybe you will see clearly how to fix the timing bug, that makes it impossible to play and win level 2 of the game.

@Alfkil

Quote:

You make it sounds like a can do what you can't :) All i can do, is start to find out from where problems come, and then ask for help from others :)

Quote:

Oh, that will be very good if you can find out the latest one. At least we will know that this is the version we all test , and all the issues you fix are in.

@kas1e

Quote:

Well, maybe you can? :) At least you are in a better position to do the work at the moment. I am in a total burnout, trying to recover.

@kas1e

Here is the latest version, I could find :

Crimsoncrisis.asm

@alfkil
Yeah, compile that version and that one surely works as one from os4depot, cool. At least we have the latest sources saved :)

Btw, you seem also to have the same issues we have with two games i patched: Foundation and Exodus.

1). Mouse cursor is always not active when we run games. You need to amiga+m, made wb active, and then back. Have a clue what is that? In the Foundation i fix it by just commenting out setting their new mouse pointer (intuition's setmousepointer() ), so keep system one. But better to fix it properly, like maybe add code for auto-activate cursor after it is loaded with new data? Maybe something like "makepointeractive()" or so is present somewhere? Or some other function will do the trick to make the cursor be visible.

EDIT: tested in Napalm: yeah, commenting SetPointer() also "fix" it, but that kind of sucks, keep their pointer from the beginning is much better surely.

2). All the intros are too fast :) And in Napalm, and in Foundation, and i have the same with Earth2140 too.