Since ATOTK is nearly complete (seriously, folks) and there have been several Linux-related threads on the forum recently, I have a question with respect to the rain and snow plugin, and Linux.
As far as I know, AGS works fine on Linux, except if you're using plugins. Does this mean the game will work except for the plugin functions, or will not work period? The former is acceptable, the latter is not. I would be interested in hearing if there are any tips or tricks that let me achieve the latter. #IFDEF maybe?
I was using the flashlight plugin too, at first, but I rewrote that using normal AGS code so that's no longer a problem. But recoding rain & snow appears to have performance issues.
Unfortunately, it won't work at all...
It will crash at start-up while trying to resolve function names of the plugin.
And I'm afraid there is no workaround to make it work the way you want.
At the moment, your options are:
- remove the plugin;
- replace it with a script version (take a look at SSH's SimpleSnow (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24075.0) and SimpleRain (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24738.0) script modules);
- compile two different versions of the game (with and without the snow/rain effect);
And for anyone else interested in technical issues and details behind this problem see that thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=25446.0) (and the relevant tracker entry (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=91)).
P.S. It's cool to know that you've almost completed the project and good luck with all the stuff that's left to do :)
I would go for #3 (compile two different versions) except that the game is about 50 megs and it seems hardly worth it making it twice that. Is there some way to compile it twice without having to duplicate all the room data? Or, for instance, if the plugin isn't actually used except in room 15, will it only crash upon loading room 15, or still crash at the beginning?
Maybe the Clickteam Patch Maker (http://www.clickteam.com/eng/patchmaker.php) will be able to create a small patch file, depending on how different the two versions are? I've been able to run these patches using Wine without problems.
Thanks for your efforts, it's nice to know people are thinking of us Linux (and Mac) users. :)
Edit:
I'm able to run Fatman (the original version) which uses the agsCreditz.dll. Ionas tells me it uses the plugin for the end credits. I haven't finished the game but I suppose it will crash when that last room is loaded.
Perhaps if the plugin is referenced in the global script (not confined to a room) the game will crash right at the beginning as Scorpiorus says.
Quote from: strazer on Thu 05/04/2007 19:19:54I'm able to run Fatman (the original version) which uses the agsCreditz.dll. Ionas tells me it uses the plugin for the end credits. I haven't finished the game but I suppose it will crash when that last room is loaded.
Perhaps if the plugin is referenced in the global script (not confined to a room) the game will crash right at the beginning as Scorpiorus says.
Ah thanks for the info, and you know that may very well be, I assumed it will crash because function imports get written into the script header which in turn is added to the global script with its unresolved names processed nearly at game start but the engine doesn't actually need to resolve these names unless they are referenced (i.e. there is a function call) in the script; and I just checked and it indeed works that way.
So if you only need a plugin to work in a certain room, you can just provide two different versions of that room: the one that calls into plugin (Windows version) and the other that doesn't (Linux). It can be a patch, as Strazer says, or an overriding "room.crm" file in the game's folder (although you may not want to use the last method for obvious reasons).
Alternatively, you can only call into plugin from the main global script and then have two versions of your executable file + splitted resources.
It won't work for Windows and Mac engines, as they seem to actually check for plugin presence, but since the Linux engine doesn't support plugins it should work fine.
Quote from: Scorpiorus on Thu 05/04/2007 20:57:55
the engine doesn't actually need to resolve these names unless they are referenced (i.e. there is a function call) in the script; and I just checked and it indeed works that way.
Interesting, but I'd have to duplicate too many rooms that way, so that doesn't sound overly feasible. If only the reference wasn't resolved until the function is actually called :)
Oh well, I'll find a workaround. Thanks guys!
Since the engine doesn't have to resolve the names unless there's a function call, could you just use preprocessor macros? I don't know that the plugin actually defines any (I've never even actually looked at the plugin), but if there were for example a version macro you could do something like:
#ifdef RAIN_SNOW_PLUGIN_VERSION
// plugin functions here
#endif
Again, I'm not sure that the plugin defines any such macros...but if it did perhaps this could be the workaround you wished for.
Yeah, I thought of that too, but that doesn't actually work.
What if you could rig up AGS to tell what OS the user is playing? Something like...
if System.User = Windows {
(RunPlugin)
}
if System.User = Mac {
(RunMacPlugin)
}
if System.User = Linux {
[Insert code for animations and manual work here]
}
I"m no great coder, and that stuff above is completely made up. (As well as incorrect coding)
Still, it's the principle. Maybe make the game assign a variable depending on what OS is being used. Then, you could call the variable from room scripts. It would be more work, but hey, any working AGS games on Linux would be dandy.
That's an idea...Maybe:
bool pluginFound = false;
if (System.OperatingSystem == eOSWindows) {
#ifdef PLUGIN_VERSION
// Windows plugin functions
pluginFound = true;
#endif
}
else if (System.OperatingSystem == eOSMacOS) {
#ifdef MAC_PLUGIN_VERSION
// Mac plugin functions
pluginFound = true;
#endif
}
if (!pluginFound) {
// module functions here
}
That way it would use the appropriate plugin if it existed, or else it could fall back onto a module to emulate the effect...maybe?
Realistically speaking, that is one hell of a workaround. Especially if you had to do it a lot. You could make functions...but with the way AGS currently works you would have to create one function for each function you wanted to run... :-X Maybe it's not very practical at all...
Just a thought though...I've mentioned (I think actually in a latter post) that I've never used any of the AGS engine ports...does the Mac engine actually have different plugins than the Windows engine? Or is the Mac engine written to work with the Windows plugins? That would at least help to simplify the process somewhat....
However, how would AGS tell what system is being run...
unless the it picks up an external variable from AGS Linux and AGS Mac?
Otherwise it might not be able to tell what OS it is.
System.OperatingSystem (http://americangirlscouts.org/agswiki/System_functions_and_properties#System.OperatingSystem) is a real AGS property. Don't ask me how Chris handles it...don't ask me if it even works properly with the Mac/Linux engine ports...I wouldn't really know as I've never used either. But seeing as the property exists I assume Chris has it running properly.
Well, shoot.
The things I learn in a day.
The use of #ifdef...#endif for conditional compiling could help with keeping both versions of the codes within a single source, but what, I think, Radiant meant is that he already have a lot of code written (and tested) and making any changes now could possibly break things and thus would require additional testing.
In general, if code of too many rooms needs to be duplicated (its logic part), an alternative idea would be to call plugin from the main global script only, with providing both versions of it, but again this could mean much restructuring of already working code.
This is something I've needed to figure out for a while now, and have shamefully not done yet.
Plugins will likely never be supported on platforms other than Windows, especially since it is centered around DirectX/DirectDraw.
However, it should be possible to make it so that the engine "fakes" success for plugin calls instead of crashing.
I'll add this to my to-do list.
It was pretty easy to support plugins on the mac. If a plugin doesn't exist, the game pops up a dialog telling you there may be problems and allows you to continue or quit.
Certain types of plugin are easier than others to port, obviously. I ported my Fire plugin though so graphics aren't necessarily a problem.