@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.

Great to hear it works better now! In theory game data shouldn't affect library auto-open stubs, but if the scripts work that's fine.
The SDL 1.2 version doesn't use SDL for scaling the graphics, it has a simple 2X scaler written by me, while the SDL2 version uses the SDL2 software renderer for scaling which will always be slower as it's generic.

Sorry I forgot to mention, I already updated the original archive with the SDL1.2 exe.

For once I took my own advice and rebuilt the Player with SDL1.2. This should offer much better speed than the SDL2 software renderer, and hopefully be compatible with a wider range of machines.

Unfortunately there's not much I can do about that, it's part of the library auo init code.