Messages

[with Steam achievements]

It's still a bit of a mess, but I got a working build of a game project (not a real game) running on OS X High Sierra with Steam achievements.

I cloned Janet's osx-nick branch and reused the WEG Xcode workspace files (and the Shivah project files). I tried to figure out how to embed a binary version of AGSteam into the app, but I kept getting an error that the library didn't exist in the final executable. So instead I followed the approach that was already partially implemented by WEG (judging by the project files and the lack of an existing port of AGSteam to Mac), and built the AGSteam source directly as part of the project files. Took a bit of knackering about as I've never used Xcode (or even OS X) before, but it definitely is working.

I will try to make a more detailed post of what I did after I try to abstract it out of the WEG files.

[a lot]

Android\Sdk\tools\bin\jobb ...

The jobb tool distributed with the Android SDK (including latest versions) is not suitable for games over 511 MB. This won't affect most games, but it is something that should be pointed out explicitly.

Additionally, you've committed a lot of binary files into your git repo, and don't even have a .gitignore file. I appreciate the fact that you made an effort to maintain this project (or the steps described therein), but you have missed important steps that obfuscate what you did actually fix from the original git repo. FWIW, I have time and an interest in getting the original repo working, but I can't promise anything definitive as I also have other projects to revisit.

[OS X support is in beta]

The latest version 3.4 now includes Mac OS X ".dylib" files! OS X support is in beta as I don't (currently/yet) have a means to test it myself with real games. However, I don't foresee issues as it is built using Code::Blocks in a nearly identical way to the Linux ".so" libraries.

The Windows and Linux builds are also now bundled with the appropriate version of the "steam_api".

Edit: Was able to test this over the last couple of days and everything seems to be working. I've also written a Makefile! I will push up the Makefile to the git repo and update the Mac download link ("libagsteam.dylib", blast it!).

the extender trick (I didn't know you could use extenders as attribute accessors).

Yeah, the way extender methods inject themselves means they are exactly the same as standard struct methods, even down to ridiculous and unnecessary definitions like:

Code: ags

import void Scream(this Character*); // imported using extender method syntax

void Character::Scream() // defined using standard method syntax
{
  this.Say("AHHHHHH!");
}

The engine and compiler don't make any distinction between the two once the extender is imported. This makes it particularly useful when attributes are involved, so you don't have to clutter up your struct definition with a bunch of hidden accessor methods. If you did have a static attribute, you can use either an instance extender or a static extender -- either one will work.

The only workaround presently is to not use static attributes.

Code: ags

struct MyModule_t // renamed, because we have to use an instance rather than statics
{
  import readonly attribute Character* ActiveCharacter;
};

import MyModule_t MyModule; // import the instance

Code: ags

MyModule_t MyModule;
export MyModule;

Character *_activeCharacter;

Character* get_ActiveCharacter(this MyModule_t*) // switched to extender just to avoid having to rely on $AUTOCOMPLETEIGNORE$, functionally the same
{
  return _activeCharacter;
}

Code: ags

MyModule.ActiveCharacter.Say("Blah blah");

This is the method I used in the latest ScrollingDialog module, for example, to achieve such feats as:

Code: ags

ScrollingDialog.ScrollArrows.Up.Padding.Bottom = 2;

It is a hassle to not be able to take full advantage of static attributes, but that's the current situation.

[Edit:]

Aside from the above, there appears to be an issue with your latest version of the Steam plugin (the one from the quoted post). Specifically, it prevents the game from accepting keyboard input, when ran from Steam. If I log out from Steam and run the game directly from Windows, it works normally. Earlier versions of the plugin did not have this issue.

Hi Monkey, I was wondering if you had some time to look into this? I would like to upgrade to the newest version of AGS2client but I'm stuck with the old one because of this keyboard bug. Thank you for your time!

Hi, sorry about that. It was a breaking change I introduced due to my own misunderstanding. Dave actually had asked me recently about the same, and I realized what the issue was. I'm doing some refactoring of the code currently, but I'll push up a new build with the fix.

Edit: Fixed build v3.3 should be available via Github. There's no binary for the Linux builds yet (but the Code::Blocks project for Linux is provided; never got around to authoring a Makefile from scratch).

I may not have time to investigate this for several weeks at least. Even if the plugin is not working, the processes it use do work. Use the jobb tool and Oceanspirit Dennis Android Studio project files available from my GitHub account. That's the best advice I can give for now.

[Edit:]

Running Beta 7 on Windows XP, I get the following crash when closing a window using the red 'X' in the corner of the window:

---------------------------
Illegal exception
---------------------------
An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x081019EF ; program pointer is +9904, ACI version , gtags (0,12)

AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and post the details on the AGS Technical Forum.



Most versions of Windows allow you to press Ctrl+C now to copy this entire message to the clipboard for easy reporting.

An error file CrashInfo.dmp has been created. You may be asked to upload this file when reporting this problem on the AGS Forums. (code 0)
---------------------------
OK   
---------------------------

This is Heroine's Quest on Steam, I'm investigating the overlay not appearing when running from the 3.3.0 engine with either renderer. I get nearly the same error if exiting the game from the title menu, except it references a line in the GlobalScript.asc.

Unless I'm mistaken "program pointer is +9904" is only set immediately before calling "exit(EXIT_NORMAL);", so why would this be crashing? I can upload the crash dump if it's helpful.

Edit: If it's relevant, I've completely removed the code from AGS_EngineShutdown in the plugin and still got the same error.

[Edit:]

Huh... Actually, I think that the plugin I linked above is initializing the Steam API, it's just not showing the Steam Overlay. Which is also the behavior I'm now getting with the VS2017 plugin. I'll investigate the overlay issue, but if nothing turns up soon then I'll just push up a new build with the fixed VS2017 code.

Edit: The Steam overlay works with the 3.4.1-b7 engine on Windows XP under D3D9 and OpenGL, but not software renderer. Oh, and it crashes with a segfault when I close the window via the red 'X'. Not sure if that's related to the plugin, nor if it would cause crashes during playing. Oh boy.

I've managed to track this down to the use of "static" variables inside functions. STL, free, and class functions are all working, until it encounters a static definition inside a function. Using the more traditional approach of static struct/class members with external storage defined in a .cpp file works. It will take a short time to port the code, but it seems that I should be able to get this fully working on XP.

[Technical discussion:]

Okay, so this build of AGSteam (built using VS2008) loads on WinXP without crashing, but I don't seem to be getting the Steam API to initialize. This is a release build, not a debug build, so it doesn't include any debug info about what result is returned by the call to initialize Steam. Effectively, it's functioning the same way as the stub at the moment, which is to say that the game is playable, but you won't get Steam achievements.

Technical discussion: I think there may have been some misunderstanding on my part regarding how C++ assemblies with differing ABIs can communicate. And while the core functions are all implemented as free functions, it's possible that they are being mangled in some unexpected way between the different VS versions, or that there is some other ABI incompatibility (probably the changes in the STL would make the ABIs incompatible, I might think). Based on this thread on Stack Overflow, I have some hope that perhaps forcing the DLL exports to use the C ABI instead could solve the runtime issues, though I'm honestly not sure about this. I'll look into porting the stub to the C ABI and see if I can get it to load that way when compiled from VS2017. If I can't, then I'll probably just call it all a wash and only maintain project files for AGSteam (etc.) that match the current AGS project files' VS version.

Edit: Unfortunately, even with every single free function marked as extern "C", the AGS engine is still crashing when trying to load the VS2017 plugin from WinXP. I even went as far as wrapping every single entire file in an extern "C" block (sans #include lines), to absolutely no avail.

[is]

I can confirm that the issue is related to the VC++ runtime. Building the stub with VS2008 makes the game playable on Windows XP without Steam achievements. The AGSteam project itself is not currently compatible with VS2008, but I can see about adding the same compatibility measures used by the stub.

The stub download links have been built with VS2008 and work on Windows XP with AGS 3.3.0 engine. It also loads with the AGS 3.4.0-p4 engine, but the mouse goes absolutely insane and is unusable.

[and]

Then maybe use some dummy plugin to debug the issue, like stub plugin (which is open source?).

You might have misunderstood my most recent comments above, but I did actually test this with the stub. The stub does nothing more than register itself with the engine's plugin API. All of the functions are no-ops. But when built with Visual Studio 2017, using the "v141_xp" toolchain, the AGS engine fails to initialize the stub with the exact same error message.

Ok, so if I understand you correctly, AGS3 games using any kind of plugins will no longer run under Windows XP. Is that correct? Given that XP is fifteen years old by now, I'm actually ok with telling people to do an upgrade, since we now know what's causing it. Thank you both for looking into this issue.

I don't think it's "any kind of plugins", but I think it must have something to do with the VC++ runtime and the way the AGS engine is loading the plugins. My suspicion is that the engine is somehow expecting the plugin to have the same VC++ runtime libraries as it uses itself. I don't know if this is a limitation of the engine or the way it invokes the plugin functions, but it has always been my understanding that external libraries should be allowed to link against a different C++ runtime, so long as that linked runtime is available (which is the case, due to static linkage).

I don't suppose it would help to build the plugin against the same VC++ runtime as the AGS main executable?

I will have to reinstall VS2008 to test this, but I will see what I can find out. (P.S. As an aside, I noted above that I had mucked some things up with the configuration settings of the stub when renaming the project (namely, when using the stub for "disjoint" builds, which I forgot to test). The stub should be able to build against VS2008, and I will upload relevant binaries and source once I'm sure that everything is working there properly.)

I realized there were some issues with the changes I made converting "AGSteamStub" to "AGS2ClientStub", but even after I corrected those and rebuilt the stub with the "v141_xp" toolchain, the stub still crashes with the exact same error. Based on the fact that "AGSteam-debug.exe" is running perfectly on Windows XP while both the AGSteam plugin and the stub plugin are resulting in a crash, I really feel that this is an error in the way that AGS is loading the plugin, possibly related to the fact that the plugins are built against a different VC++ runtime (despite static linkage, which is meant to prevent this kind of failure).

[Edit:]

Interesting find, CW. I had done some high-level skimming of MSDN and hadn't come across that particular article (or the enclosed topic). I'll see if I can get something working with that, now that I also have XP installed in a VM.


Edit: Unfortunately, still no dice. Even with the "v141_xp" toolset selected, I get the exact same crash before the plugin is able to create the debug log.

Edit 2: Just to test that the AGSteam assembly itself is working, I've created an executable version of AGSteam. This is meant to test only whether the AGSteam assembly can run successfully on your system. Extract the zip somewhere you have write permissions (e.g., "Desktop/AGSteam-debug/"), then run "AGSteam.exe" from the Command Prompt. You should get exactly this output (the number after "Caching Steam ID:" may actually differ, this is printed by Steam so I'm not sure) in the console window:

calling engine startup
ofstream.is_open()? true
writing to debug log...
finished writing to debug log
Calling AGSteam::Startup()
Setting breakpad minidump AppID = 283880
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198046544449 [API loaded no]
AGSteam::Startup complete, calling AGSteam::Shutdown()
AGSteam::Shutdown complete, exiting AGS_EngineStartup
done!

And you should have the much sought after "agsteam_debug.log":

AGS_EngineStartup called, engine = '0x00000000' (not yet initialized) and lpEngine = '0x00000000'
AGSteam::GetClient called, returning address '0x005738CC'
Steam not initialized, calling SteamAPI_Init()
SteamAPI_Init() succeeded, creating UserStatsReceivedListener
UserStatsReceivedListener created, requesting current stats. SteamUserStats = '0x00CF07B0'
User stats requested, AGSteamPlugin_Initialize() complete

In this case, the engine and lpEngine pointers are meant to be NULL, as the AGS engine isn't even running.

I've tested this on Windows XP, using the "v141_xp" toolset in Visual Studio, and everything appears to be working exactly as expected here. If this also works for you, then my suspicion falls back to the AGS engine failing to load the plugin properly, despite the fact that the crash dump says the DLLs are both loaded.

I've gotten so far as to verify that I can extract your game data file from the OBB. I haven't yet had time to investigate why it isn't working. I will try and get back to you with further details soon.

EDIT3: I just thought I've already seen standard C++ library functions crashing before. That happened when one component of program was linking to debug version of std library and another to release version.

Well there are three assemblies to consider here:  acwin.exe, AGSteam.dll, and steam_api.dll. acwin.exe and AGSteam.dll both have static linkage to the STL, though they are different versions of the STL. steam_api.dll... well, it could have dynamic or static linkage to the STL, I'm not really certain that it's documented anywhere. Given that Steam is meant to work on a wide range of systems, it seems probable that they would have static linkage, and the file size of steam_api.dll seemingly supports this, but none of that is a guarantee. Regardless of whether steam_api uses static or dynamic linkage though, would different assemblies using their own version of the STL be problematic? If that were the case then I would think steam_api.dll would be unusable. AGSteam is a single assembly which links against steam_api, so I don't see how any part of AGSteam could have the wrong linkage to the STL, if that's what you were suggesting.

You could make another version of the engine which writes full dump, but first make sure that's okay for eMTe to upload huge files .

Assuming he'll read this, any hint on how to go about "mak[ing] another version of the engine which writes full dump"? I clearly don't know anything about this, so I don't even have any idea where in the engine code (or solution settings, maybe?) that I would go about doing this. Thanks for the explanation.

They were mainly useful to know the exact point and callstack of crash, which could help reproducing it (sometimes).

Oh, and in this case, the dump from AGSteam-debug-2.zip's plugin indicates that the crash occurred at the point that the log file is supposed to be created by the std::ofstream constructor. If the ofstream constructor is actually failing, then presumably I should be able to catch an std::exception, wouldn't you think? I can try and decouple opening the file from the constructor (just initialize the ofstream as an empty object) then put the ofstream.open() call in a try/catch block. I was working on the assumption that the error must be coming from before the ofstream constructor begins, but maybe that's an asinine assumption?

Monkey, the problem with these mini-dumps is that they do not have full memory contents. Which means that every variable can be displayed as zero. You'd need to make AGS write a full dump (but it will be many megs large, or even hungreds of megs).

Well in that case, are the dumps even useful at this point?

[AGSteam-debug-3.zip]

No log again. Dump:

https://bitbucket.org/Maciek_Tr/sosnowy-las/downloads/CrashInfo.3.3.0.1162a.dmp

This latest dump is crashing when the std::ofstream is being constructed, citing engine being NULL, but engine isn't even used in that constructor:

Code: cpp

    static std::ofstream ofstream{ "agsteam_debug.log", std::ios::trunc };

AGSteam-debug-3.zip doesn't even use engine in AGS_EngineStartup. Instead, it operates directly on the parameter lpEngine (which should be the same value, regardless). It attempts to create the debug log as soon as AGS_EngineStartup is entered, before any parameters are inspected or touched.

If this crashes, there is one other approach you could try, which is simply running Heroine's Quest with the AGS 3.4.0 engine. To do that, you would need to install (zip archive or installer) AGS 3.4.0, then copy the "acwin.exe" from the AGS folder into the Heroine's Quest folder. Drag and drop "Heroine's Quest.exe" onto "acwin.exe", and it will launch the game using the AGS 3.4.0 engine. The Steam version of Heroine's Quest does run on Windows 7 with the AGS 3.4.0-P4 engine, but I don't have Windows XP installed to test that environment. I'll see if I can get an XP VM running.