Thanks for testing it. Keep in mind that this source code was public from the start, so I wouldn't bet on someone suddenly becoming interested in it, but you never know.

@Raziel
I'm still doing 68k ports, but with a significantly lower output.

@walkero
To be honest I have no idea. This was developed on OS4.1u6 with the original Warp3D/MiniGL combo. It's probably no longer be compatible with newer configurations.

@noXLar
I lost interest in NG in general, not just OS4. There are multiple reasons for this, some related to the OS, some personal.

I can't argue about the thread's title, but alas I have retired from NG many years ago. I just found this old binary from 2018 on my site and decided to publish it. Maybe it still works and it will be useful to someone.

I did some cleanup on my site, and I found an unpublished OS4 binary for Arx Libertatis which was shelved due to performance issues. There's no harm in making it public now, but keep in mind that it's provided as is, without warranty or support.
http://bszili.morphos.me/ports/arx-os4.lha
In case someone is looking for the sources, my fork is available here:
https://github.com/BSzili/ArxLibertatis/tree/amiga

@kas1e
For example something like:


Basically you add a linenum = __LINE__; before return statements to track where it returned.

@kas1e
Yeah, it's probably not a compiler issue, but likely related to something going in inside the opengl library. Did you try adding a global variable for CompileShaderProgram? Just set it to __LINE__ before every return, and print it in InitShaders. This way you'll have a better idea of which point it fails.

@kas1e
I don't necessarily mean printfs, but for example commenting out returns or setting a variable to the line number that you print later.

@kas1e
Aha, so you had to introduce a small delay before compiling the shaders, I was completely off the mark. Is this is the program in question?
https://fossies.org/linux/SDL2/test/testshader.c
In this case it would be good to know at which point CompileShaderProgram returns FALSE.

This can be a sign of the optimizer doing something funny. Try to compile this file with -O0, or if the compiler supports it add __attribute__((optimize("O0"))) to the affected function. If that fixes the problem you can either leave that function unoptimized, or you can try to make problematic variables "volatile".

@trgswe
I stand corrected, it's from Chromium. It still works in most cases if you have readdir.

Ah, I see. The player only uses the C library for file I/O, so it's hard to guess which function allocates some system object down the line. The leak could also affect other platforms, so hopefully it'll be fixed in 0.7.1.

You can just do this:

This is taken from glibc:
https://chromium.googlesource.com/chro ... 961001/dirent/readdir_r.c

@broadblues
That makes sense, but I'm still none the wiser why RunCommand appeared in the Player, which AFAIK doesn't start any other executables. All I did way replacing the pixman library with the static version, and backported a fix to the filesystem code.

Same here, but I have no idea where it's coming from. The Player never used RunCommand, and I certainly didn't add it now either.

I applied the ZIP fix from upstream, and replaced pixman with the static library and uploaded a new archive.

I think BeWorld fixed some issue with ZIP files, I'll check it later.

It didn't even occur to me that he could be missing the library, since the Player worked sometimes. I never though libraries can phase in an out of existence, but I guess only Amiga makes it possible *shrug*

edit: For the next version I'll check if I can link a static version of pixman to the executable to avoid confusion. It looks like shared libraries work in mysterious ways.

That's too bad indeed. If the library auto init stub is broken on your system, then it's not very likely a new version will fix anything, as it's not part of the Player but the library's SDK. We'll see.

Probably, but as the comment says it's quick & dirty code. It does the job well enough to have the Player run at full speed even in WinUAE. If someone makes a measurably faster version I'm happy to merge it, I just didn't see the point of spending more time on it.

I mean there's not a lot to it, for every pixel from the source surface you write two in the destination surface, and you write lines twice. This is how it looks in the EasyRPG Player:
https://github.com/EasyRPG/Player/blob/master/src/sdl_ui.cpp#L396

edit: Feel free to send me any programs.