Unreal AmigaOs4.1

Hi,

I got Unreal Engine 1 running on my X5000 (fgsfdsfgs/UE1 sources, cross-compiled with GCC 11.5.0 via walkero's Docker toolchain). It renders, it's playable, and it exits cleanly. Took a lot of debugging to get here.
The last problem is sound. When I enable audio (UseSound=True, NOpenALDrv), the window opens and then the whole system freezes — 100% CPU, no crash log, have to reboot. With sound off, everything works fine.
I'm using OpenAL-Soft 1.23.1 with the SDL2 backend, linked against the SDK's SDL2. Just before the freeze I get:
[ALSOFT] Failed to set 44100hz, got 48000hz instead
[ALSOFT] No capture backend available!
I already ruled out my own threading code (custom sem_t and gthread stubs for GCC 13) — a standalone sem_wait/sem_post stress test runs fine on the real machine.
I think it's the SDL2 audio backend on AmigaOS4. Questions:

Has anyone had a similar freeze with OpenAL-Soft's SDL2 backend?
Would building OpenAL-Soft against a native AHI backend instead of SDL2 be the better way?
The MorphOS port by BeWorld/BSzili uses the same OpenAL+SDL2 setup and mentions an early "audio bug" fix — does anyone know if that applies to AmigaOS4 or was it MorphOS-only?

Thanks for any help.

@Maijestro
OpenAL surely works (i use it in many projects), but just what you can try firstly is:

At first, be sure you use static build of whole exe, i.e. when you do "ppc-amigaos-readelf -d yourfile.exe", you have "no dynamic" listed. That by itself can solve lots of issues

Also, use this version: https://os4depot.net/share/development ... ary/audio/openal-soft.lha . This one from Salas00, and his ports always of high-quality (and i use exactly this version always).

ps. And don't forget to have stack cookie of 2mb, i always use it for any more or less "big" projects, just to never worry about possible stack issues which can cause all sort of weird issues too.

@Maijestro

Wow, good work.

I'm looking forward to playing that myself, compared to
Doom3 it seems to run very well.

I do have a retro PC with a Voodoo 5 5500 though, which I'm currently playing the game on

Nice icons by the way you have in desktop

@Maijestro

Amazing work! Thank you for this.

@Maijestro

We had a similar problem with Woof (Doom Port)
https://github.com/fabiangreffrath/woof/issues/1285

@all

While playing, RAM just keeps draining, even standing still - no crash, just slowly eats memory until it runs out. Happens in scenes with animated textures (water/lava). Doesn't come back after quitting, and even a full GL context recreate doesn't help.

I tracked it down to about 1.4 KB lost per glTexSubImage2D call on an existing texture. Rate scales with call frequency, not format or upload path.

Weird bonus fact: first launch after a reboot leaks way faster than later launches in the same session - like something gets "warmed up" - but the leaked memory itself never comes back.

Things I've ruled out: my own code (UE1's CHECK_ALLOCS tracker stays flat while RAM drops), sound, all the fancy render options, BGRA vs RGBA, mip levels (helps some, doesn't fix it), throttling upload frequency (also just slows it down).

ogles2.library is closed source so I can't dig further there. Skimmed SDL2's AmigaOS4 GLES2 backend - context handling looks fine, but I didn't get to check the MANAGE_BITMAP buffer path (OS4_GL_AllocateBuffers/FreeBuffers) closely.

My best guess at this point is that it's a bug either in ogles2.library itself or in SDL2's AmigaOS4 GLES2 backend, somewhere around how texture uploads get handled internally - I just can't tell which of the two without being able to look inside ogles2.library.

Things I might still try:
- Look closer at OS4_GL_AllocateBuffers/FreeBuffers in SDL2's AmigaOS4 backend, especially the resize path
- Try building against SDL3 instead of SDL2, in case the AmigaOS4 backend differs there
- Check if there's a newer ogles2.library/Warp3D Nova version than what I'm on

Any ideas welcome - happy to share logs/a test build if useful. Thanks!

Also, big thanks to kas1e for the stack size tip early on - that was the main blocker at the start and I wouldn't have gotten this far without it.

@Maijestro
The bugs looks very much like the one i found lately. Check this post : https://www.amigans.net/modules/newbb/ ... id=161260#forumpost161260 , with reproducible test case. It was fixed in the beta of ogles2, but no one know if it ever will be released anymore. So, you need to make a workaround if that the case.

Just point on this topic your AI dev, and ask "is unreal use glBindTexture(GL_TEXTURE_2D, 0) and can't it be the same sort of bu g in amigaos4 ogles2". If that will be it, good, easy workarable, and if not, you will need to create small as possible test case, so it also can be workarounded if bug will be known.

@kas1e

Quote:

Bullseye!!! - ran into that exact same bug. Thanks, that was the missing piece, everything's working perfectly now, sound included. Many Thanks

@Maijestro
Cool ! So, time to release ?:)

@kas1e

Quote:

Why publish so fast, it's largely untested :D

Now the real beta testing begins - weeks of it, across different machines: Pegasos2/Sam460/X1000/X5000 :D I've only tested it myself on an X5000 with an RX580. Just kidding... one more nice video and then nothing stands in the way of release. Oh, one more thing: the build is based on GLES2, OpenGL should work fine too, but it would delay things a bit.

So should I add MiniGL support as well?

@Maijestro

Great news! Looking forward to the release.

Hello, don't forget to credit BSzili and myself for the endianness fixes and other changes. Available on MorphOS for over a year. Thanks.

Can SPE-version be made?

@all


AmigaOS4 (SDL2 renderer): fullscreen works fine at every resolution except 1920x1080. At that one specific resolution, the game opens behind Workbench. No crash, game's running fine, you just can't see it unless you flip screens manually.

Turns out it's not random. In SDL_os4modes.c, OS4_SetDisplayMode() has this:



If the fullscreen resolution you ask for happens to match your current Workbench resolution, SDL2 doesn't bother opening a new screen — it just reuses the Workbench screen. Every other resolution gets its own fresh screen, which naturally lands on top. 1920x1080 was just my Workbench's native res, so it hit this path.

And then OS4_ShowWindow() only does:



ScreenToFront moves screens around, not windows. When it's reusing the Workbench screen, that screen's already in front — it's the actual game window sitting behind Workbench's own windows/icons. ScreenToFront doesn't touch that.

Fix was just adding WindowToFront next to it:

[code]cif (OS4_IsFullscreen(window)) {
IIntuition->ScreenToFront(data->syswin->WScreen);
IIntuition->WindowToFront(data->syswin);
}
[code]

Also added a small workaround on the game side, forcing a real resolution change before the final one (drop fullscreen, resize slightly, fullscreen again, resize to actual target) so it never hits that shortcut at all. Either one fixes it on its own, using both.

Figured I'd post it in case someone else porting SDL2 stuff to AmigaOS4 runs into "fullscreen at desktop resolution hides behind Workbench" — it's only that one code path, not fullscreen in general.

Update: still not fixed

So, turns out the WindowToFront fix above didn't actually solve it. Tested on real hardware, rebuilt everything, made sure the new binary was actually the one running — still opens behind Workbench at 1920x1080, same as before. Either WindowToFront isn't enough on its own here, or there's something else going on that I haven't spotted yet.

If anyone's dealt with something similar on AmigaOS4 — a fullscreen SDL2 window refusing to come to front specifically when it reuses the Workbench screen instead of opening its own — I'd really appreciate any pointers. Happy to share more code/logs if it helps. Kind of stuck on this one.

@beworld

Quote:

Thanks for pointing that out, and no worries — I will absolutely credit you and BSzili for the endianness fixes. I actually just came across that work in the source myself and wanted to say: really appreciate what you two put together there. Big-endian bugs like that are exactly the kind of thing that eat up hours, so having a reference to check against helped a lot. Credit is going in the readme/docs for sure.

@Majirestro
Quote:

You mean you choose in the game 1920x1080 full screen, it opens, but not activates ? If so that strange, and feel like some code issues, but not SDL2 , because i use SDL2 a lot and it surely switch fine to 1920x1080 fullscreen and they surely start to be active.

I think (but not sure), that it can be some issues in your setup with Window2Front, Click2front and all that sort of things running in background which prevent normal working. So for sake of tests try to disable all you have enable in startup/etc in terms of those commodities and tools.

Also, it can be some left overs in your tests in the port itself, like you may try something and forgot, and it keeps there.

Not that i say SDL2 can't have problems, but i use a lot it, and never seen such a problem, while i love to tinker with fullscreen-window modes, and especially 1920x1080 (because this is one i use when record videos via my LGP2).

@Maijestro

Quote:

Quote:

So does it open a screen or not?

My resolution is 1920*1200 and testwm2 seems to work OK when choosing 1920*1200 and going to fullscreen.

@Capehill @kas1e

It doesn't necessarily have to be an SDL2 issue; I think it could also be a problem with my window manager configuration.

So yes, the screen opens correctly but is hidden behind the window manager, and I can make it visible using the left Amiga key and M or N—but then it's visible behind the window manager.

As I mentioned before, this only happens at the native window manager resolution of 1920x1080. All other resolutions below that work perfectly. I have the same problem with ScummVM in full-screen mode, so I’d really like to fix this.

It could also be something in the Screen Mode preferences that’s causing these issues. Right now, I have no idea what it could be. If there’s anything else I can test or try, please let me know.

@Maijestro
To avoid guesses, you can send me binary for tests (with removed all click2front/etc code-hacks in game) and i can check if it will behave correctly on my setup or not. That will nail it down a lot.

@Maijestro

You could also create a simple program which simply opens a 1920*1080 screen and see how that works. This should rule out app or library issues.