Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed GM_COMPATIBILITY_VERSION using the old 0,1,2 system instead of … #993

Merged
merged 3 commits into from Sep 19, 2016
Merged

Conversation

faissaloo
Copy link
Contributor

…version numbers which broke new alpha behaviour from #969
Either I forgot to commit that file or it got lost because of the force-push. Either way, this fixes GM8 behaviour always being used.

…version numbers which broke new alpha behaviour from #969
@JoshDreamland
Copy link
Member

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).

@faissaloo
Copy link
Contributor Author

faissaloo commented Aug 10, 2016

I can't use 0 for standard because then the comparisons won't work the same and I'll have to have a && 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 etc
I 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

@JoshDreamland
Copy link
Member

Personally, I think it's better for the code to say what it means; it's true that in most cases, changes made to future versions of GM are improvements, and that ENIGMA would always want to include those improvements. But we know that even so far, this isn't always the case, so designing a check system around that can cause issues.

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.

@faissaloo
Copy link
Contributor Author

faissaloo commented Aug 10, 2016

I disagree, for one 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.

@JoshDreamland
Copy link
Member

What I'm saying is that I don't think it's valid to try to place ENIGMA somewhere in Game Maker's chronology; it's nice that ENIGMA's selection of reasonable defaults coincide with most versions of Game Maker, but that compatibility is not the engine's sole purpose (and even with the support macros we have, it doesn't accomplish full compatibility, anyway). Checks like 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.

@faissaloo
Copy link
Contributor Author

faissaloo commented Aug 10, 2016

Yeah but ENIGMA's default is to be compatible with Studio, that's what 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.

@JoshDreamland
Copy link
Member

JoshDreamland commented Aug 11, 2016

In practice, it's probably better if we fit our concepts to math, given that this code is running on a giant calculator.

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.

@RobertBColton
Copy link
Contributor

Believe it or not, I am of the opinion that GMS is more compatible with ENIGMA. The reason being that it is compiled and has removed support for most of the things we could never get around to, like looking up variables by name and 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.

@faissaloo
Copy link
Contributor Author

Bump; This needs merging

@JoshDreamland JoshDreamland merged commit a4b528a into enigma-dev:master Sep 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants