Compatibility Issues

[Josh @ Dreamland]

Questions that have been haunting me since day one, and I'm sick of dealing with them, so I'll present them to my user base.

• Var can't return int, string, double, and char*. It just can't; it leads to ambiguity out the back end to where your game won't compile.

Knowing this, do I have all the functions take double and string as parameters (a 100% waste of memory and at least 800% waste of speed), or do I alienate std::string as a return type?

Neither of those are very attractive choices. There is a middle option where I have the user decide whether or not they want to keep var as a type, and re-compile ENIGMA optionally to take scalar arguments. (Scalar meaning one type, in this case of the smallest needed size)

I will try again to get var to work with conflicting cast types, but std::string is the one that causes ambiguity. Even though I added an explicit cast function for it in var. (Meaning I told it exactly what to do to convert var to string, but it errored anyway.)

• Game Maker does not have functions that don't return anything. Even functions in GM that return nothing will actually behave as zero, and can be used in assignment and arithmetic. This isn't the case in C++.

For the first three releases, I returned zero in all those functions, as int for max speed.

Why not do away with them? Some people like to add a function that needs called but returns nothing to a function that must be called after the first function, in order to call them in one statement. Like registry_set_root(3)+registry_read_real_ext("blah","blah")

That's an ugly, yet useful feature of the language. I was considering having function return ENIGMA_VOID, and the return statement at the end be return_void;. This would enable the user to choose whether or not to do this and recompile.

• Game Maker does not return success or fail. Especially for functions like registry_write_string(). A lot of functions that are VERY prone to failure have unclear methods or no method at all of determining whether it worked.

Should ENIGMA return error codes as WinApi does? For registry functions, this would also eliminate combining things like registry_set_root(3)+registry_read_real_ext("blah","blah"), though since registry_set_root will never fail and the latter returns nonzero normally, that's not exactly the best example here.

Maybe a function to check if the last calls succeeded?

• WinApi has developed some since its first release in 1912. As such, we have a set of 16 bit functions that are preserved for compatibility with 95 and 98, but then more recent functions that are meant for 2000+ and may not work on really old Windows systems.

The problem here is, do we stick with the old ones and risk being obsolete come Windows 7, or do we lose 95 and 98 compatibility and go with the new? Again, this can be fixed by compiling separate releases for each operating system, but that's not exactly attractive as an option.



There are plenty more conflicts, but these are just a few that are immediately bothering me.
If you haven't guessed, registry functions have been implemented.

College classes are nearly over; I have a huge take-home final exam to worry about this weekend, followed by 23 more days of high school. But then I'm done, and will actually have a decent amount of time to work. I hope.

[Game_boy]

For the registry issue, could you include both and have an internal switch that determines the OS and therefore the functions to use? And even if you fix it for Win 9x vs. Win NT, how will those functions work on non-Windows OSs? Perhaps it could write to an external text file called "registry" in the game folder?

For the other conflicts, the priority (at least until ENIGMA is more widely known) should be that copy-pasted GM6/GMK files should "just work" and the resulting behaviour is the same under both GM and ENIGMA. So for the "return zero" thing it should return zero by default just in case. And therefore an option to turn it off is a 'nice to have'.

[Josh @ Dreamland]

I'd have to agree with that.

For Linux and Mac, I was thinking about writing it to the var folder, if permission allows, because I'd really rather not store things like that in the same folder as the game, for obvious reasons. Not so much for security, considering the registry really isn't as hidden as GM users would like to believe. In fact, I don't think security of it would really be a problem: If you're on Linux, chances are you already know what Windows' system registry is anyway, so putting it in a nearby file wouldn't make much of a difference in that respect. Here, the real beauty of the registry (or writing to var/ in Linux' case), would be that the game could still access the data, even if it the game's file was moved without the registry file.

Thinking about it, Windows' registry is also used for associating file types. To be honest, I'm not sure how that works on Linux, so that'd require some research... It'd probably never be compatible anyway. But ENIGMA wasn't really intended to need to associate file types anyway, and if the need arises, I can always make a built-in function for that.

[Game_boy]

You'd probably want to use /etc (configuration files) rather than /var, /var is for more temporary data like logfiles and program 'working set data' like databases. And, you're right, writing to the registry for security is always a bad idea; I don't know why anyone thought otherwise.

Interestingly, GNOME (which is the most common desktop environment for Linux) does have a registry, called Gconf. But by using it you would be making it GNOME-specific and really it's not worth it.

I think Linux uses MIME-types for file association. File extensions are meaningless on Unix systems.

[RetroX]

Yeah, GNOME does have Gconf, but I really go against using it.  Just create a fake registry as a file in the same folder with the values in it.  I see that as being simpler, and you could modify the name of that file in the game settings or something.

For compatibility, how about having multiple versions that support different compatibility?  I mean, you could have one that has 16-bit and 32-bit functions, and another that has 32-bit and 64-bit functions.  You could change which one you compile in the settings.

As for functions, you could check if it doesn't return anything and make the function return void or simply be void.  For var... would it be possible to check what type the variable is from the beginning and use that type from start?  I mean, you can't change a string var to an int, so I really see no differences.  Of course, the only real thing you would do is make every number a double so that decimals can be used.

[Josh @ Dreamland]

Every number is currently a double. Which is the problem; doubles are slow.
And yes to the MIME types. But I don't know where that data is stored. I've used GConf, for setting hot keys system wide, but I don't know where it keeps that info.
Ism was looking into ext/ just yesterday, and turned out to not have permission to write to it except when she was root. So that's no good either.

And again, I'm sort of opposed to the idea of keeping the registry file in the main directory. Ism suggested a hidden folder on the user's home directory. Since GM uses registry_set_root for some BIZARRE reason, (it's almost like GM was meant to be cross platform), I could easily rig it to change locations of where I'm writing. But I don't think I'd have permission to put anything on the root of the drive, either. If I did, though, registry_set_root could simply change the directory I write the registry info in.

Also, Retro, I don't want to make a separate release for each group of Windows platforms. I'll stick with the idea of allowing it to be recompiled for older systems. LGM can probably make calls to ENIGMA to rebuild parts of itself for different platforms, since GCC will always be available.

[Game_boy]

You use GConf already in ENIGMA? What happens under KDE?

Yes, forgot /etc required permission. A hidden directory in the user area is probably the best solution. That's where GConf is stored, by the way.

Off topic:

Will the next be release be on the order of weeks, months or years? (Don't shoot me...)

[Quadduc]

The usual way for user programs to store settings on GNU/Linux is to store it in a hidden directory in the user's home directory, so each game could have a file like "~/.enigma/registry/$gameid". This should be good for most games. System-wide settings are in /etc. Non-root users can read some of the files there, but not write to any of them, of course.

For file association, I have a directory named "~/.local/share/mime" that maps file extensions (and possibly file contents like magic numbers) to mime-types, and a file named "~/.local/share/applications/mimeapps.list" that maps mime-types to applications. This may be distribution-specific.

Edit: See the XDG Base Directory Specification at http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

[Josh @ Dreamland]

Game_boy--
 Not for ENIGMA, just in general to see what my options are. There aren't any ENIGMA functions that depend on it yet.
 I don't want to set a release date, but I'm hoping a month, maybe two. It's a lot of time, but I want all the bugs out, and I want the system to be at its best and most solid. With all the other releases, I've left room for improvement. With this one, I'm trying to leave only room for additions.
 And yeah, I know it's been a while. Sometimes I forget how long a while, and then I remember, gee, the last release of ENIGMA still takes more than a few seconds to compile. But I'm pulling out all the stops.

Quadduc--
 Hero for the day.

[Game_boy]

Thanks.

[RetroX]

Every number is currently a double. Which is the problem; doubles are slow.

Which is the advantage of using int when you can?

You use GConf already in ENIGMA? What happens under KDE?

GConf is not limited to GNOME, although it is a GNOME application.  KDE distros like Kubuntu or KDE Fedora will probably have some sort of registry.

[Game_boy]

You use GConf already in ENIGMA? What happens under KDE?

GConf is not limited to GNOME, although it is a GNOME application.  KDE distros like Kubuntu or KDE Fedora will probably have some sort of registry.

KDE doesn't have a registry of any kind by default, and nor do distros using it. GConf is portable, sure, but it'd have to be a dependency and GConf itself depends on several GNOME libraries; to install a single GConf-using app would bring along a lot of GNOME baggage.

[sprintf()]

How about since Enigma is supposed to be cross-platform, you only include features that are cross-platform. I haven't been keeping up with Enigma but is it still even supposed to be able to compile any GM code?

[Game_boy]

How about since Enigma is supposed to be cross-platform, you only include features that are cross-platform. I haven't been keeping up with Enigma but is it still even supposed to be able to compile any GM code?

(As far as I know) ENIGMA will implement all or the vast majority of GM functions, but using cross-platform libraries like OpenGL instead of GM's Direct3D. So, yes, it will compile 'any' GM code.

[Josh @ Dreamland]

Sprintf(), all of the C++ world hates you for no reason at all. Go away.

Also, I'm not dumping useful Windows functions just because Linux and Mac don't have something just like it. That's what SDL did; it's a wonder SDL even creates a window for you since it provides no interface to manipulate it. <_<