OFFICIAL GML Updates in 2019 (Follow up AMA)

Status
Not open for further replies.

jonjons

Member
Not wanting to change the subject, and talk about myself... But it would be good if i could also get an update on my drawing skills... :banana:
Or make a button in GM application for all those bloom, blur, antialiasing shaders
 

rmanthorp

YoYo Games Staff
Admin
YYG Staff
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.
 

Amon

Member
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.
Thanks for the info. Staying safe is the priority though so you get full understanding from me if Q1 is missed.
 

gnysek

Member
I can count 1st to 3rd April as Q1 in that case ;) To get open beta in next 2 weeks I believe there must be last closed beta this/next week with no critical reports, so I keep my fingers crossed that it's already released and the results are good!
 

drandula

Member
Would there be any idea to make depth sorting with Controller priority list, where instances throw methods to it? One method would have wanted drawing functions inside of object.

Edit. Or additionally they throw Lwo's into list, and lwo has more information. Were lightweight objects now called structs?
 
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).

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.

---
As for projects transitioning from GM 8.1 to GMS 1.4 and 2.0... While that *would* be nice, it's a much lower priority for me because, in all honesty, anyone still using GM 8.1 for their project really is better off starting from scratch.
---

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.

---

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.
 

FrostyCat

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

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.
There are already compatibility scripts that GMS 2 automatically inserts into projects imported from GMS 1.4. So what's your point?

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.
That is already possible and being done.

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.
Delta time is not the magic bullet you think it is, and there are already packages on the Marketplace designed for delta time movement.

Loading up YoYo's plate with nice-to-haves that other resources are already equipped to handle isn't a good way to get important updates done.
 

Yal

GMC Memer
GMC Elder
Delta time also has more or less fallen out of favor with PC developers these days, it creates more problems than it solves compared to just adding a few options to degrade quality in exchange for speed... usually the GPU is the bottleneck these days, and there's a really nice "lower effect resolution by half --> time needed to compute the effect is reduced by 75%" rule of thumb for essentially anything that renders to a 2D canvas. Compared by how delta time can mess up collision checking in utterly broken ways and make any and all movement more involved to code, you save yourself a lot of headaches just allowing the game to slow down.

(This is another story on less powerful devices like phones, of course, but it's more of a director's cut than a completely different story these days)
 

kburkhart84

Firehammer Games
In any other game engine(including back when I was using vanilla OpenGL with C++), I've never not used deltaTime. The default in most engines is to need to use it just to make movement the same speed everywhere...and the frame speed limiting that Gamemaker does is something you would have to separately code if you wanted that behavior. But, with Gamemaker I've never used deltaTime. 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 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.
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.

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), giving a blanket statement like "Delta time also has more or less fallen out of favor with PC developers" is beyond absurd. Doom Eternal, DMCV, Rocket League, Monster Hunter World, Risk of Rain 2, and Yakuza Kiwami 2 are just a few recent PC games I'm familiar with that utilize delta timing to support arbitrary framerates. It's a bit more difficult to implement in GM, since the render refresh rate is heavily tied to the game's update speed.
 

kburkhart84

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

SSJCoder

Member
well I'm just gonna leave this here but delta time can be capped, if you are having collision issues.
(example: delta = min( time_processing_max, time_passed );)
I usually cap mine at 0.25 seconds, but then that also depends on your code too.

just this cap should fix most issues that I can think of .. you can cap it to a lower value if you still have issues - all the way down to the default amount of time passing between each frame anyway, which should mean the behaviour should be basically the same as not using delta time at that point.

also want to point out performance gains from delta time are significant, and larger scale projects IMO should always consider it.
 

SSJCoder

Member
I have never used delta time for anything ¯\_(ツ)_/¯
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.

if you use capped delta time, at something like 0.1 secs/frame, even if your game is running at about 10 FPS (down from 60) - it is still more playable than the non-delta-time-game. (assuming there aren't many glitches).

Also helps when there is a short processing overload on the machine at any point during your game - instead of you waiting a long time for it to be over delta time skips through it.

Chances are, if you've never used it and never ran into performance issues, it's because your projects are small scale enough, or there's no fancy graphics - to the point that you don't need to worry about it.
 

❤️×1

Member
I use tick time : a proper frame is calculated on each tick ( = arbitrary length of time, I usually set it at a 1/60 of a second) and, if if needed, frames in between are interpolated.
That way, I have the consistence of frame time combined with the practicality of delta time, but it comes with a small overhead on the CPU :/
 

Khao

Member
When I started using delta time I never went back. I like my games to work at 60. Some people just have ****ty PCs but still want to play games, it's just nice to allow the game to run at lower framerates, especially when implementing it is almost 0 effort once you get used to it. And it's super extra nice to allow games to run at higher framerates. Borderline horror story, the previous full commercial Game Maker game I worked on didn't have any kind of delta. physics were 100% tied to framerate. Welp, some people would play the game on 144hz monitors. The game actually ran more than twice as fast as it was supposed to, making the game unplayable. With delta, it's literally impossible for that to be an issue.

Also yes, capping delta is a good idea to avoid broken logic. Right now I actually allow my game to slowdown when framerate drops below 30, which is the point where it would feel awful to play anyway. Over 30fps literally any framerate is supported and the game will never run at the wrong speed and it just feels good.

My favorite thing about delta though is the fact that you can literally change the speed of the game with a variable. Slowmotion has never been easier. Heck my pause is pretty much just "delta = 0;" and it works perfectly. Don't even have to deal with instance deactivation.
 

rmanthorp

YoYo Games Staff
Admin
YYG Staff
Unfortunately, we’re running late on 2.3 and Sequences. We can’t really blame covid-19 either. It’s just a huge feature that has taken a bit longer than expected to get into shape for open beta release.
It’s not far off though and we’re about to release what we hope will be the open beta candidate into closed beta. Please bear with us, sorry for the slippage.
 
Status
Not open for further replies.
Top