• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion Mobile developers should be able to compile to YYC for testing

G

Guest

Guest
YYC and the VM have different behaviors. This is a problem. YYG's position on this problem has fluctuated. I think originally they acknowledged the different behaviors, then for a period they denied that there was any difference, and now recently they've gone back to acknowledging the different behaviors, fixing some of the differences, and labeling others as unfixable.

This is particularly a problem for people working on platforms other than desktop, because we cannot sufficiently test code without fully compiling to YYC, but we cannot compile to YYC without actually compiling to the target platform. For mobile, this is a serious drag because (1) it means connecting a device or AVD, which can be a bit of a hassle, particularly if coding somewhere other than a desk (hey, GMS2 specifically has "laptop mode"), and (2) the compile time is quite long, if not for an individual build then for the aggregate of multiple builds as code is refined.

Thus, although the non-desktop exports cost a lot more, they have significantly worse debugging experiences.

Mike at one point indicated that this will never change because allowing YYC on the desktop could risk circumventing the desktop license.

Bollocks. First, purchasers of the non-desktop licenses have paid enough to diminish any loss YYG may have for those few individuals willing to pay for a non-desktop license but go through whatever would be necessary to make desktop versions of their game without paying for the desktop license. Second, this continues to reflect YYG's prioritization of anti-piracy measures over user experiences. This gave them a huge black eye with the sprite-destroying debacle in GMS 1, and it continues to reflect poorly on them every time people can't use their software because something is wrong with YYG's licensing code or licensing servers, or simply when people want to work offline.

Non-desktop users should be able to compile to YYC to adequately test their games. YYG's insistence on hobbling the more expensive exports hurts GMS2's image and makes the software worse to use.

(Really, the VM should die, but maybe that should be addressed separately.)
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Ummm... With all the permanent licences you can compile using the YYC... Desktop, Mobile, UWP and Console (Web no, because it creates a JS file). It's also always been this way, so I'm not at all sure what you are talking about.
 
G

Guest

Guest
Compile to the desktop with YYC for testing purposes, versus needing to attach a device to see if your code works with YYC as well as the VM. Currently, if you only have a mobile license and not a desktop license, you cannot run the game in Windows with YYC. You can only test the game in Windows using the VM.

I assume you obviously have at least both licenses, so you wouldn't run into this.
 

rIKmAN

Member
If I'm understanding you correctly, you want to be able to export to Windows using YYC when you only own the mobile licence?

Even if you could do that (which you can't because you don't own the desktop licence) then the performance of your code wouldn't be indicative of the performance you would get on a mobile device anyway, and YYC also takes longer than VM to compile on the desktop target as it does with the other targets.

As for it being a hassle to need to plug the device in if you are away from home, all you need is the phone and a USB cable - presumably the phone / tablet would be in your pocket and a USB cable weighs nothing and fits easily in a laptop bag along with the laptop charger etc.

If it's a tablet that also would fit easily in the laptop bag so isn't any extra hassle as you are carrying the laptop with you anyway.

The last part of your OP sounds like you are saying that you can't compile using YYC on any other targets than Windows, but as Nocturne has said you can use YYC on any of the targets apart from HTML5.

Android

iOS

If you really want to be able to use YYC on Windows then maybe grab a Creators Licence, but as I said I don't see how that is useful at all if you are targeting mobile - other than saving compile times in which case using VM would be quicker anyway.

Maybe I've misunderstood your point?
 
Last edited:
G

Guest

Guest
No, I don't want to be able to export to the desktop. I want to be able to do with YYC what I can do with VM: Test it on the desktop. Testing with only VM is inadequate because VM and YYC behave differently.
 

rIKmAN

Member
No, I don't want to be able to export to the desktop. I want to be able to do with YYC what I can do with VM: Test it on the desktop. Testing with only VM is inadequate because VM and YYC behave differently.
I think the bit I'm confused about is why you want to do it on desktop rather than the device - which is already possible.

With mobile especially it's important to see how the game performs on the hardware - which I'm sure you already know - so I'm not sure why you want to do it on desktop as it bears no relation to how it would perform on mobile.

One of your points is that VM and YYC are different, but so are mobile hardware and PCs so even if you could test YYC on desktop without owning the licence it would bear no relation to mobile performance making the test largely pointless in the first place.

As I said I don't think having a phone/tablet and a USB cable with you isn't really a hassle when you are already carrying around your laptop bag which could easily hold both.
 
G

Guest

Guest
So apparently neither of you guys, when developing for mobile, ever test your code except by compiling the game in YYC mode on a physical mobile device.

I find that hard to believe, but okay? I don't think it's that uncommon with mobile dev software to want to test your code quickly, on the platform you're coding in, via a method that accurately represents how the code will execute on the target platform. But maybe I'm wrong.
 

Dog Slobber

Member
Being able to compile to the desktop with YYC doesn't tell you much about using YYC on mobile.

If you want YYC to the desktop
So apparently neither of you guys, when developing for mobile, ever test your code except by compiling the game in YYC mode on a physical mobile device.

I find that hard to believe, but okay? I don't think it's that uncommon with mobile dev software to want to test your code quickly, on the platform you're coding in, via a method that accurately represents how the code will execute on the target platform. But maybe I'm wrong.
YYC on the desktop is not an accurate representation of how the YYC will behave on a different platform. YYC executables are not only susceptible to platform differences, but also differences introduced by the native compiler on the different platforms.

YYC doesn't actually compile the source code into executable code, it compiles th code into the source code suitable for the native compiler, then calls the native compiler for the platform.
 
Last edited:
G

Guest

Guest
I'm going to drop this conversation here, because this obviously isn't an issue that the community's very worried about, but I think you guys are maybe being a titch willfully obtuse, so just for history I'll go ahead and make it painfully clear what I meant and what I think it's plain that I meant.

Some examples of what I mean by VM and YYC behaving differently are (and some of these may've been fixed by now):
  • Some sloppy coding practices, like lack of semicolons or brackets, are fine in VM, not in YYC; maybe also placement of variable declarations are/used to be handled differently.
  • Mistakenly using "if (a = b)" is silently corrected in VM, and the check is silently ignored in YYC.
  • VM and YYC differ in how they, uh, read numbers, which is why you can do "if (image_index == 5)" in VM but must floor it or use "if (image_index >= 5)" in YYC.
  • Dot notation work differently in VM and YYC (safest code is just to make a global variable if you're using a singleton pattern).
  • This official blog post by MF Russel Kay about "consistency issues between the VM and YYC compilers."
Plus---the worst part, the reason people with just a mobile license should be able to test code as YYC in Windows the way that they can test code as VM in Windows---whatever else we don't yet know about. I had never heard of the "if (a = b)" and dot notation differences, and each one burned a chunk of my time recently, and they wouldn't have if I'd been able to do quick unit testing in YYC the way that I can in VM.

None of that is platform dependent, hardware dependent, or speed/resource/performance-related. It's a bunch of unknown differences that are still being discovered because at some point GameMaker gained the YYC function and it's still being worked out. One way to make development more predictable and rational for mobile licensees is to allow them to run their code with the YYC compiler on the desktop.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Some sloppy coding practices, like lack of semicolons or brackets, are fine in VM, not in YYC; maybe also placement of variable declarations are/used to be handled differently.
Mistakenly using "if (a = b)" is silently corrected in VM, and the check is silently ignored in YYC.
I'm honestly not sure if this was ever the case or just a long game of broken telephone.
YYC always generated C++ code from GML AST, meaning that whether you had parentheses around an if-block or whether you used "==" or whether you added semicolons is completely irrelevant - different syntactic structures simply act as alias for one another.

I can tell you this with a good degree of confidence as virtually all of my projects use YYC, and a many of these inherited rather non-strict codebases (e.g. Spelunky has zero semicolons; Nuclear Throne spotted strange brackets, indentation, and = for comparisons)

VM and YYC differ in how they, uh, read numbers, which is why you can do "if (image_index == 5)" in VM but must floor it or use "if (image_index >= 5)" in YYC.
You would want to use math_set_epsilon to force VM-like precision if the game relies on that

Dot notation work differently in VM and YYC (safest code is just to make a global variable if you're using a singleton pattern).
Also not sure of this - the only thing I can recall is "obj.v = 1" when there are multiple instances of obj, which used to assign value to all of them on VM, but not so much on YYC/JS.

This official blog post by MF Russel Kay about "consistency issues between the VM and YYC compilers."
This does cover edge cases like
Code:
var v = 1 - math_get_epsilon() / 2;
switch (v) {
case 0: show_debug_message("0"); break;
case 1: show_debug_message("1"); break;
}
working differently between VM and YYC because switch cases aren't real in VM (it just compares the value to each case value while minding epsilon) while YYC would faithfully cast the variable to an integer (usually rounding down).


I would have thought that the right thing would be to report inconsistencies between VM and YYC rather than requesting a workaround so that you can test YYC on PC, and then also test YYC on Mobile - for example, there used to be some weird stuff (I have maybe 15 YYC-specific bug reports total over period of 2014-2019), but now we are at the point where I can do a YYC build of a 50KLOC project (after testing purely on VM), push it to store without prior testing, and not see anything break. So getting the rest of the issues reported-fixed would seem like a logical choice...
 
G

Guest

Guest
Okay! I give, I give.

When both Nocturne and YellowAfterlife say this isn't a big deal, I'm willing to admit that I'm making an issue where there isn't one.

 
Top