Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

What libraries are the included builds linked against?

A topic by dph created Apr 05, 2021 Views: 278 Replies: 3
Viewing posts 1 to 4

The extension is working fine for me, but one of our developers reports that our game is crashing without an error message when Apollo is included in the project.  From prior experience, this usually happens when someone is lacking a required DLL that an extension relies on, and I notice in the manual that it does say the extension is 'linked dynamically in all cases'.  What are the required libraries?

(Incidentally, when having trouble with this in the past, the only reliable way I found to prevent such errors was to statically link my library - do you know a way of checking for the existence of a required library ahead of time in GMS1 so that a meaningful error message could be shown to a user?  Or whether a try catch block would automatically pick up such an error when we move to GMS2?)

Developer

Are you using Apollo V2.3? It’s linked statically now (as per post).

You can also try getting logs (run the game with -output out.txt -debugoutput out.txt) from the person.

I believed so, but we were just updating our project to GameMaker 2.3, so I thought I'd wait and see if things went better on that.  Other developers on the team were still having crashes (specifically 'Attempting to use a non-existent Lua state!' the first time they tried to use the newly created state) whereas it worked for me.  Using Process Explorer, I've seen that the GameMaker Runner, as well as using Apollo.dll, is using msvcp140d.dll and vcruntime140d.dll (among a hundred or so others, but these caught my attention since they are debug builds).  I've found I can recreate the Apollo crashes that the other developers are having (as well as getting a list of DLL-loading error messages with Apollo in the text while the game is compiling) if I deleted either one of those DLLs from my system directory (specifically the Windows/SysWOW64 directory in my case, though that's probably just for 64 bit Windows).

I re-downloaded the latest Apollo to be sure when moving across to GM2.3, but I think we were using the latest version of Apollo all along.  I don't expect you would have intentionally used debug DLLs in a release build anyway, so presumably this would have been an accident no matter what version it was.  I've certainly made that mistake myself in the past!

Developer

This seems correct - I must have uploaded debug DLLs or changed something while setting up x64 builds.

Published a pair of DLLs that only rely on KERNEL32.