Windows Is there a reason we can't export to Test with YYC without the desktop license?

[Guest]

I have the mobile license and thought I'd give a shot at hammering out my code so YYC will work. This is not an easy process... I wish I'd been working toward this from day 1. Two problems:

(1) I couldn't work intelligently toward YYC-compliant code from day 1 because you cannot export to Test using YYC. I did try to write my code correctly, but I am not a programmer, and my understanding is that staying YYC-strict is difficult even for programmers.

(2) It's hard even now because, despite having paid $400, I can't quickly test my build on my desktop but have to wait and see if (when) it crashes out by building to mobile--which is much slower.

Perhaps I am simply misunderstanding something. However, I do have VS correctly installed and configured, and the error I get is that it's missing the Win32\Runner.rc and Win32\Runner.manifest files, and in those locations I do have android and ios folders.

If in fact GMS2 does not allow export to Test with YYC, then, unless there is a very good reason related to cracking/piracy for the limitation, I think it is unreasonable not to allow trial users---or at least non-desktop licensees---to export to Test with YYC.

 

[sylvain_l]

YCC means instead to use the VM to run some bytecoded GML you get the code translated to nativ platform code;

I don't know for sure if android does YCC translate as C++ or java ??

IMO, even if for both it was C++,problem could still stand. Because it won't garantee that you don't face a problem when going to compile your code as apk for the android mobiles instead of exe for windows. (the wholes framework and platform environnement is different. IMO, you could find code compiling as YCC exe for windows, and get problem when exporting as YCC C++(I suppose more if java) for android.)

 

[Guest]

Since YYC is YYG's answer to the criticism of GMS being slow, I'm surprised it's not more of a central focus in terms of debugging. Even a simple toggle or report on whether your code is "YYC compliant" in the process of development would seem to be common sense. This would also serve GMS's purpose of being an educational tool and a gateway into programming.

 

[Guest]

Crud. Went through and ensured I met all the suggestions for YYC compatibility here, but it still crashes once my actor takes a step. (My game does run, and even takes input, but it crashes once my actor tries to move.) On the plus side, the real FPS actually appears to be ... edit: okay, it's actually a bit better with YYC, although granted I can't see any real gameplay, but it's not the astonishing increase I'd hoped for.

Edit edit: I think I just went through all the stages of grief. Denial, anger, bargaining, depression and acceptance. After additional tinkering, including a harrowing period involving varying-length arrays where I considered rolling back to my admittedly ty but functional non-YYC code, we came through to the other side, and I can now run in YYC. Still not sure the additional frames (if any) were worth it, but I feel cleaner and more accomplished. Hooray for clean. Hooray for more accomplished.

But I stand by my original post. If YYC is how you get a GameMaker game to run more quickly, YYC should be baked in at every step, including Trial. As someone with only the mobile license, I don't look forward to having to sit through two builds every time I want to test.

 

[Mike]

If you only have mobile, then desktop test is purely to allow you to quickly iterate on your game, that's all. Aside from getting it working, there is no reason to provide YYC on desktop, as the performance comparison is so different it's not a valid one. There's also nothing to stop you getting it working with "just" mobile, except the longer compile times. This is just a fact of life with iOS and Android due to how they've both created their compilers and systems.

Due to the nature of YYC, final code is visible and subject to bypasing things once compiled, so Trial users won't ever get this.

 

[Guest]

Bypassing the license is a valid concern, so the limit on compiling is reasonable. That does not change the need for a baked-in system for auditing code and ensuring YYC compliance. What other development software has two sets of rules for development, never clearly explains the different requirements of the two rulesets, and then heavily penalizes use of the default, documented rules? GMS2 touts the benefits of YYC while requiring people to refer to this random website to figure out how to make their programs YYC-compilable rather than an official document.

 

[Mike]

You do of course still have YYC for mobile - it just takes longer to build thanks to iOS and Android compile process being so bad. I'm not sure spending heaps of time and effort on doing a YYC "trial" is really justified, or cost effective from our standpoint.

Really... it should "just work". If it doesn't, we'd be interested to see why and fixing these cases so you don't NEED to "get it working" at all.

 

[rwkay]

YYC should be functionally equivalent, if you find something that does not work then congratulations! you have found a bug, if you report it then we will fix it....

This is why we do not document the differences as they should be the same...

The only real difference is in the handling of handling the <object>.variable syntax for both reading and writing and that has been well discussed and documented as a difference in YYC (though I believe the current GMS2 version has limited even that difference now). Please NOTE: JavaScript targets (like HTML5) also have the same limitations.... (This is why we discourage you from using that syntax)

YYC is not perfect and you will still find issues here and there but it is very much edge conditions now... please file bugs when you find them (as that helps everyone)

Russell

 

[Guest]

@Mike @rwkay I don't know how to interpret what you're saying. YYC does not "just work." This appears to be common knowledge. Google it. Take anyone's random project that works with the VM and try to play it (actually play it) compiled with YYC. I've run into this twice now; once when I initially spent a day getting it to work in YYC by following that random web page's suggestions, and now I'm back in the same boat after I had to do a fairly extensive overhaul of my turn-handling system. VM? Peachy. YYC? My actors get stuck inside each other. In my experience, a project will not work correctly in YYC without special tinkering unnecessary to the VM, and everything I've read except for your two comments above agrees with my experience.

Edit: The issue this go-round may've been as simple as running Clean before compiling (as recommended by that random web page). Things appear to be working, but I'm feeling very cautious about YYC.

 

[Mike]

Our point is YYC "should" just work. If it doesn't, then we need to see the project and find out why it's not working, as you've probably hit an edge case where it IS failing.
File a bug, an include a link to the non-working project, and someone will take a look.

I've used it (and so have many console devs), on some very large projects so it does - and should work fine. If not, you need to file an issue so we can fix it. If it's not filed, we can't fix it.