Thanks for the info. Staying safe is the priority though so you get full understanding from me if Q1 is missed.Hey all, another quick update from us. With regards to the virus we are now fully working from home and with this comes a few challenges. Right now open beta is still on track for Q1 but in such uncertain times, this could change. I really appreciate all the interest and I hope we can deliver open beta soon. I can't wait for everyone to jump in. Thanks.
I don't understand this fear of the new GML 2020 syntax in relation to existing projects at all. Other than the new function syntax (which all existing script resources will convert to), there's nothing else in GML 2020 that you can't opt out of just by not using them. Existing projects will still work the same way they used to.Right now, the biggest potential feature that matters to me would be the ability to opt out of specific new features if they're going to break an existing project (so, transitioning a project from 2.0 to 2.2).
There are already compatibility scripts that GMS 2 automatically inserts into projects imported from GMS 1.4. So what's your point?Further down the line, creating an optional "compatibility package" to make transitioning a project from an older version of GameMaker Studio to a newer version would be very welcome. For example, if I have a game that's been running on GMS 1.4 for years, I want to be able to migrate to GMS 2 and update it gradually, versus trying to port the whole thing at once and watch it completely break.
That is already possible and being done.Now the *other* hugely important feature for me... A better version of YYC, or at least a way to "compile" your project to C++ (leaving function/variable symbols intact) before turning it into an executable.
This is because YYC, while faster than not having it at all, still produces very inefficient and wasteful code and doesn't allow you to make certain optimizations that you could do with an external compiler or IDE.
If I have a section of code that would run very well in parallel for example, YYC doesn't support OpenACC-based GPU acceleration, as well as any other specialized optimizations down the line. Rather than asking YoYo Games to try implementing these things on their own, it would be much smarter in the long run to just make it easier to use an external compiler/IDE to finish your project before pushing it to retail.
Delta time is not the magic bullet you think it is, and there are already packages on the Marketplace designed for delta time movement.One last thing I would like to see added is a set of tools and functions to make it easier to convert old projects to use Delta Time as opposed to relying on a fixed framerate (for example, wrapping an existing function into simulating a fixed framerate), or at the very least change a lot of the default things when starting a new project to account for using Delta Time right out of the box.
The main benefit I've gotten from using delta_time is actually in the opposite situation -- being able to run games at higher refresh rates without changing any code. On top of that, the changes in code for supporting it are negligible if you're not doing anything beyond basic motion.I didn't see any real benefits to it. In general, if you are targeting a certain audience, you know the specs of their machines, and you make your game work full speed on them. You likely also add a buffer of performance for when things aren't optimal. But, you can't be expected to cater to people with lesser machines than your target audience...unless you decide to change your target audience(expanding it). Generally, the people who have lower-spec machines and still insist on playing games beyond the machines capability are likely already used to slow downs, etc... anyway.
I agree with that point. As far as I know most if not all modern games are using deltaTime because they all want to try to max the framerate and of course need movement to be the same on all systems. The statement would probably be pretty accurate though if we were talking only about GMS made games.While I agree with most of what Yal is saying in that there's very little reason to support it (especially with how complicated it can get in GM), saying "Delta time also has more or less fallen out of favor with PC developers" is beyond absurd.
delta = min( time_processing_max, time_passed );
)if you make an intense game, usually having it run at half speed (30 FPS if it's a 60 FPS game) will already be basically unplayable.I have never used delta time for anything ¯\_(ツ)_/¯