Flare enough

@walkero

This is not pretty but worked in 2024.

EDIT:

As I checked six months ago, Flare 1.14 worked on QEMU M1 Peg2.
Compiling with cmake cross compiling clib4
This compilation was done to work well under QEMU emulation.
Someone needs to do it for the real hardware profile.
It should work.

test video - > https://youtu.be/SIhOf26v58Y

@smarkusg
That's an interesting topic to discuss. For not derailing this thread, would you like to open another and discuss it there?

@walkero
I have corrected the entry.

@smarkusgQuote:

If you need a tester, I'm available. And great that you accepted! 😉

@Maijestro
I sent it - it works for me.
I also checked it on Qemu passthrough Asus Radeon HD 7750 with acceleration settings - it works for me too.
I hope it will work for you as well.

ps
Once everything is working, you can go ahead and share the files without even mentioning who created them.

@smarkusg

Quote:

Thank you for making it available for me to test

However, when I run Flare, I get a GR and I don't know why this happens. The GR can be ignored and then the game starts. I played for about 5-6 minutes until my system froze completely.

I am attaching the GR log in case it might be useful.

@Maijestro
It is possible that something is not working because this version of Flare has forced compositing modes and a few other changes to work under QEMU and sm502.
I remember playing it for a few hours and the system was working.
Yesterday, I just launched it under Qemu passthrough Asus Radeon HD 7750 and ran it for a while.
It launched normally....

In that case, the topic of the new version of Flare is open so that it works on all machines.

@smarkusg

Quote:

You are not to blame, with some ports the errors do not occur under Qemu Peg/A1XE and even on X1000, but sometimes problems can occur on Sam460 or X5000. Of course you could not reproduce it because you are not using any of these hardware.

Steffen Häuser explained it like this in another thread.


Zitat:

"If the author of the port has a Peg2 or x1000, he can't KNOW about the problem, because there are no alignment problems with them. In other words, the author is not to blame here (except perhaps for the fact that he did not use enough different hardware during the beta test ;---) ). With AmigaOS4 ports it is ALWAYS important to test on devices that are neither x1000 nor QEmu nor Peg2 in order to rule out alignment problems."

I also tested it under Qemu/Peg2 with Wazp3d, and yes, the GR could not be reproduced here.

@Maijestro
QEMU does emulate sam460ex too including the different BookE CPU so it could be tested on that but I'm not sure every detail of this system is emulated but it could be improved if that helps testing. Also in AmigaOS most binaries are the same between machines and the kernel handles differences between CPUs in most cases (e.g. A1222 kernel emulates missing FPU) so I'm not sure what alignment issue is referred to here. One difference is that on some systems (at least sam460ex, X5000 and A1222) the kernel uses the SoC's DMA engine so maybe that has some required alignment on real machine that is not there on other systems or QEMU. If this is the case it could be checked in the 460EX DMA engine emulation in QEMU and produce a guest_errors warning for it to help developers but I'm not sure what the real issue is here. In any case it should not crash (unless the app uses DMA itself) as the kernel could also fix it up and provide a warning for such unaligned DMA requests but I don't know how this is handled in AmigaOS and I may be completely wrong about what is causing the problem.

@Maijestro

What I wrote here in the part you quoted does NOT apply to this GR.
According to the GR you posted it is NOT an Alignment exception but a DSI.

Did you check if your SDL2 settings are set to Compositing (as Marek wrote that his code required compositing) ?

If this does not help my suggestion would be to compile a debug version of the program to see if this gives more details of what exactly is going wrong.

Also maybe compare if the system where it runs and the system where it doesn't use the same version of clib4.library (myselves I did not do much with clib4, I usually use newlib).

@TheMagicSN

I have SDL Prefs set to Compositing. I also copied the included clib4 library to SYS:Libs/. None of this helped.

I would like to find out why there are no problems under Qemu Peg/A1Xe or even with qemu passthrough gpu. This could be useful for developers.

First, it will be tested on a similar real machine to confirm that my configuration here is not the problem.

@balaton
I doubt the 460 emulation of QEmu emulates it's alignment restrictions and exceptions.

The problems with alignment of especially FPU accesses, and to a much smaller extent integer ones as well (IIRC only used in WarpOS software, not in any AmigaOS 4.x native software), are:
- The G2 CPUs (603(e)/604(e) in classic Amigas with Blizzard/CyberStormPPC) support nearly anything without exception, partially even odd addresses.
The WarpOS API wrappers like my powerpc.library for AmigaOS 4.x include alignment exception handlers making it work. Very slow of course because of the exceptions, but it's no big problem for executing code created for a 150 MHZ G2 CPU without L2 cache on the much faster G3/G4 800 MHz-1.4 GHz CPUs.
However, it's a problem when porting old WarpOS PPC software to AmigaOS 4.x PPC (which doesn't include alignment exception handlers for such, on most CPUs, illegal accesses), and @TheMagicSN should have had that problem in some of his ports.
- 440/460 CPUs have an additional problem: The 405 CPU core doesn't include a FPU but uses an "external" FPU, even if it's on the same SoC.
FPU accesses which cross a cache line boundary cause an alignment exception on it, for example 64 bit double accesses on only 32 bit aligned addresses can be in 2 different cache lines, which works without any problems and without slowdown for example on G3 and G4 CPUs, but not on 440/460.
The 440/460 HAL part of the AmigaOS 4.x kernel includes an alignment exception handler, but the exceptions make such code very much slower and it should be fixed in the sources.
- POWER CPUs (X1000) may have completely different alignment restrictions than PowerPC CPUs (all other AmigaOS 4.x systems), but I don't know anything about it.

@smarkusg

Another tester confirmed that there are problems, at least on the X5000. During execution, a memory overflow occurs, meaning the memory is consumed until the system eventually freezes. DSI and GR were also present in these tests.

But as already mentioned, it's not your fault, as these problems don't occur under QEMU.

@Maijestro
I don't know what the problem could be.
I've been playing for over an hour now on Qemu passthrough Asus Radeon HD 7750 Peg2 with hardware acceleration.
On Peg2, I only have 1 Gb of memory. I exited the game - I don't see any memory leaks. I still have over 700 Mb of free space.
The graphics card memory hasn't changed either. I haven't encountered any GR.

@walkero asked for someone to make a port. Maybe someone will recompile a version and send it to you for testing.

@smarkusg

I just wanted to clarify once again that it's not your fault.

Perhaps you could make your work available somewhere so that we can work together to find out why it works perfectly under Qemu gpu but not on real hardware like X5000?

Someone could then look at your source code, make corrections, and let us know what the problem might have been.

@Maijestro

Please try https://capehill.kapsi.fi/flare/

It's the latest code, tested very quickly. I have no plans for this, no time. It just compiles out of box so there is no reason not to have it.

@smarkusg

Please release a debug version of your binary, it could help to investigate crash issue on some systems.

@Capehill

Thank you for providing this test version. I simply copied your build into the Flare directory provided by @smarkusg and then ran it.

It seems to work really well, there was no DSI/GR and the music in the game can also be used.

Did you compile the whole thing with Newlib? @smarkusg's version was created using clib4.

Here is a short test video showing how your build works.

Klick me -----> Flare Test Video

@Maijestro

Yes, Newlib was used. Different C libs shouldn't be mixed.

By the way, you can enable FPS counter using Interface menu. (show_fps on config)

@Capehill
Quote:
I no longer have the source files. I only have the binary files that I sent to @Maijestro.
Your version works for @Maijestro on the files from my package. My version was built statically, so nothing should break.

Thank you for your help for those who would like to play Flare.