But even then...why does it work the first time (for me) but not any time after that?
Also...shouldn't that library, if it's .so, be provided together with the binary, or in case of a static library, compiled into the binary itself with no need to install it?
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.
Edited by BSzili on 2021/11/16 15:33:59
This is just like television, only you can see much further.
When i got back here 3 hours later, the same game, together with *every* other, refuse to start anymore.
I'm getting this dreaded assertion "fs" failed: file "src/filesystem.cpp", line 189 again.
edit:
sigh...
It seems as if games, started from within a .zip file, does NOT store their save data automatically (Probably writing into a .zip file is not uspported/broken. One *must* give an *available* save path to make the player not complain/silently quit on loading the game data.
But i get reproducable freezes now, some minutes into the game (any game).
Audio/Music keeps playing but the whole input is frozen. I can't switch fullscreen/window, I can't even switch back to workbench. Keyboard reset is also not possible anymore. It looks as if input is affected system-wide..
Nothing in the log (where is the log?) and no crash as far as I can see.
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.
If the library was bundled with different app and installled in the apps directory instead if LIBS: then the library will magically appear on the internal library list once that app has been run, but not other times.
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.
Internal_RunCommand() is the eventual destination of any function that runs some external code via the shell eg System[Tags]() RunCommand() Execute() et al
@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.
This is just like television, only you can see much further.
Hmm I wonder if that message is comming from the instance of Internal_RunCommand() that laucnhed EasyRPG itself.
At a guess it might occur if objects were allocated with AllocSysObject() or AllocDoSObject() and not Free with the corresponding Free#?Object() function.
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.
This is just like television, only you can see much further.
I take it you're using the libpixman-1 static library that gets built as part of pixman-1.library?
If so, the reason that you are getting the error message when running the program from CLI and exiting is that I use there AllocTaskMemEntry() to implement LTS (local thread storage). The reason I do it this way is that this type of memory gets automatically freed on task/process exit and is easily accessible from the tc_MemEntry list in the Task/Process structure.
The only minor problem is that when a program is started from CLI it is run on the context of the existing CLI process, which then complains if the program returns with this memory allocation still in the tc_MemEntry list. In the shared library I've currently fixed it by adding a call to tls_fast_path_cache_free() in the library Close() function.
For a static build you should be able to fix it by adding a destructor function like so: