Suggestion:
plugin DLLs don't work in the Linux or Dos versions. Now it may be useful to be able to use the same game data file for both Linux and windows... this could be done if the Linux version of the AGS runtime simply ignores the DLL function calls. In the AGS editor I could supply a list of external functions; in windows these are linked to the DLLs, in Linux they are not.
That depends on what the plugin is doing.
For example, just ignoring the maths plugin would be very bad.
Also, for calls that return values the stack would at least have to be padded.
CJ said plugin authors would be able to make their plugins for the linux version too one day?
Interesting idea. The scripting system could 'stub' the functions I guess, but of course it would depend on the plugin as to whether this was possible. For a purely graphical plugin where it would just look less pretty without it, it's a possibility - but as Steve says, if the plugin is used for vital calculations by the scripting, it can't really be worked around.
This could be specified on a plugin-by-plugin basis I guess - but it's a low-priority feature.
I have never tried using AGS on another platform, does it crash if a plugin is used?
If it could be made not to, we could use a game. variable to detect what platform engine was being used, and to make the script conditional. Much like an HTML frames page that is properly written will tell you if you're using a browser that does not support frames, or direct you to a page that is written for such browsers. You could conditionally replace a plugin-fire with an animated sprite, for instance.
Sounds good, Hollister.
Actually, do a lot of people use the Linux and Dos versions of AGS?
Not many I guess, but there're still some.
At least I'll be one who will use DOS version whenever possible.
I think Pumaman said something like 98% of visitors to the site are using Windows.
By the way, doesn't the Windows version of AGS run under Wine? (windows emulator for Linux)? That would solve some issues.
That's like running Virtual PC on a Mac, then running it that way. Its not actually running on the Mac, just a *virtual pc* inside the mac. ;) lol
The DOS and Linux engines will load a game that uses plugins, but when they attempt to initialize a script that uses a plugin function, they will exit with an "undefined function" error.
Hm... so would it be possible to make a simple way around this, like a If_Windows_running () function? So that the Linux interpreter simply ignores the relevant bits of code...
(low priority of course, I'm just curious)
As I remember a global system.os variable holds the engine version - dos, windows or linux.
Yep, you can do that to find out the OS, but it won't help here, since the runtime error will occur when it loads the script file (since at that point it attempts to resolve all external function calls). Therefore you'll never get a chance to run the code to check OS.
Yep, so what if for the linux version the engine would initialize pointers to external functions with some internal error-handling function that aborts the game when gets called (with the error message saying that the function doesn't have implementation).
Thus we can have optional calls in the script:
if (system.os == OS_WINDOWS) {
pluginFunction1(); //external functions
pluginFunction2();
pluginFunction3();
} else {
// Workaround code if possible
}
pluginFunction4(); //game will be aborted with theÃ, linux engine to tell that an alternative code is not provided;
EDIT: This way the engine will behavior correctly just in case if the pluginFunction4() implements vital math calculations or whatever.
Sounds like a good idea to me, I'll add it to my list.
I appreciate it's a low priority but if it will be implemented, a good idea would be to have a function telling if a certain plugin is available (returns NO for both dos and linux). Thus a developer can decide (on game start and on restore, for example) whether to run the game or quit when a vital dll is not linked.
Good idea - though currnetly, the Windows engine won't load the game if a plugin is missing.