Fixed GM_COMPATIBILITY_VERSION using the old 0,1,2 system instead of …
Reporter: faissaloo | Status: closed | Last Modified: September 19, 2016, 02:35:27 pmEither I forgot to commit that file or it got lost because of the force-push. Either way, this fixes GM8 behaviour always being used.
There are big distinctions between GM5 and 6 (and even between 6 and 6.1); I'd probably use numbers like 530, 600, 610, 700, 710, 800, and 900, and just use 0 for Standard. It's not a huge issue, as I think Sorlok just put his 5.3 compatibility layer in an extension (correct me if I'm wrong, @sorlok).
&& not 0
everywhere which would be really ugly. My idea was to have standard be the highest so when we check compatibility with GM_COMPATIBILITY_VERSION<=8
or GM_COMPATIBILITY_VERSION<=6
etcI don't think there's any need to have the versions be in the hundreds, we can just put them in tens like 81, 70, 61, 60 etc
If you mean to say, "If we're doing GM compatibility for an old version," say it; #if ENABLE_GM_COMPATIBILITY && GM_COMPATIBILITY_VERSION <= 610
, or I suppose even if GM_COMPATIBILITY_VERSION && GM_COMPATIBILITY_VERSION <= 610
would be fine.
It's just a way to avoid future surprises.
ENABLE_GM_COMPATIBILITY
would seem like it's disabling all compatibility with Game Maker, but above all when I write GM_COMPATIBILITY_VERSION<=61
I am saying 'do this for any compatibility with versions older than 6.1', when I say GM_COMPATIBILITY_VERSION>=61
that means 'do this for compatibility with versions newer than 6.1', with your method we would have to go 'do this for compatibility with versions newer than 6.1 or the current version', think of it in a chronological manner, GMS is a newer version and therefore compatibility with anything higher than 6.1 should imply GM:S, instead of having to be made explicit as you suggested.GM_COMPATIBILITY_VERSION >= 61
are themselves a little short-sighted, as historically, features have popped in and out between GM versions, as well. So while the idea that STANDARD
is mathematically greater than any kind of GM compatibility is cute, I think we're conflating a shorthand for GM_COMPATIBILITY_VERSION==610 || GM_COMPATIBILITY_VERSION==700 || GM_COMPATIBILITY_VERSION==710 || GM_COMPATIBILITY_VERSION == 800
with some notion of monotonic improvement with time.STANDARD
is, it's the most up to date rendition of the language/library/compiler. I understand that compatibility isn't the sole purpose, but you can't just ignore that STANDARD
is the newest rendition because everything else is legacy behaviour from old versions of Game Maker, so unless we have a 'Studio' compliance level and completely abandon everything about Game Maker, thus separating from the Game Maker timeline then STANDARD
is the most current rendition of all behaviour within ENIGMA and GM:S (to a degree). If a feature pops in or out we'll have a 50/50 chance of having to change the code anyway, should it be non-retarded and deemed worthy of compatibility, regardless of which style we use. This has nothing to do with improvement of a thing over time, it has to do with the intended behaviour for whatever the current rendition of that code should be.I think part of the issue is this:
So while the idea that STANDARD is mathematically greater than any kind of GM compatibility is cute
I think you and I have different ideas about what comparative operators, or maybe numbers in general 'mean', and that might just be because I'm not a particularly 'mathy' person. You look at
<
as 'greater', I look at it as 'higher'. I hope you get what I'm saying.I think our core disagreement lies in the idea that ENIGMA's default is Studio compatibility. I think I speak for most of the other contributors when I say that Studio isn't really part of ENIGMA's equation. Harri doesn't care about Game Maker at all, at this point; his sights are set much higher. Sorlok is most interested in compatibility with really old GM versions (including 5.3). I'd say Robert cares the most about further GM versions, actually, but he usually goes with the flow. In my eyes, Studio doesn't really bring much to the table. Most of the ideas introduced in Studio were in ENIGMA since the beginning, and the rest are largely AIDS (like that new subscript syntax from #988).
ENIGMA was created when Yoyo initially bought Game Maker at version 6.1. Both GM and ENIGMA have improved on 6.1 immensely, but feature parity beyond 6.1 is a combination of convergent evolution and feature requests, rather than principle.
I could probably ramble for a while about places we've deliberately diverged vs places we've entertained minute differences, but there's not much point. And this is probably way more discussion than a short series of three-digit numbers is worth. We can deal with any needed refactoring if and when we decide to conditionally support a difference between ENIGMA and GM:S (so far, we've just canned them).
That said, this change is basically fine by me, for now; I'll let Robert or Harri merge this, so they have a chance to opine.
execute_string
.
That said, and considering Josh's position, I don't understand why he is the one that is wanting more specific version numbers. But yes I do believe we should only focus on compatibility where it's actually kind of useful. I don't think anybody really cares about execute_string
. Most games, like Project Mario, used it for debugging and it can be simply commented out.
What I mean is that I don't really care about GameMaker version numbers less than a minor. I don't even really care about anything less than a major. GM 8.1's changes over 8.0 were great and don't require any debate. Most of it being in the graphics system where they added a model batcher that significantly sped up 3D games, something it should have been doing all along. Additionally, old games didn't need refactored in order to benefit from the changes.
I say go ahead and merge it.