OFFICIAL Learn About GameMaker’s Future and How We Fit in At Opera (Q&A)

kburkhart84

Firehammer Games
Vulkan doesn't use OpenGL or OpenGL ES.
Never said it did. I probably should have said more specifically that it looks like Apple is going to not allow ANY API except for Metal. I could be wrong, but why else would they not choose to use Vulkan instead of wasting time with Metal that only works on iOS?
 

Samuel Venable

Time Killer
Never said it did. I probably should have said more specifically that it looks like Apple is going to not allow ANY API except for Metal. I could be wrong, but why else would they not choose to use Vulkan instead of wasting time with Metal that only works on iOS?
That I don't think is true either, although I could be wrong. I just know that the whole point of Molten was to port Vulkan to Metal.
 

FrostyCat

Member
By this statement, it seems that it's being forced on them by Apple, like they aren't going to let us keep using OGL/ES.
The roadmap added that explanation well after I posted. That explains why Metal is a priority item, but still doesn't explain why Vulkan isn't elsewhere on the list. Is it an item for 2022 or beyond, perhaps?
Vulkan doesn't use OpenGL or OpenGL ES.
Apple explicitly refused to support Vulkan natively. There's MoltenVK, but it's a shim that doesn't have Apple's blessing, running the risk of inconsistencies, extra overhead, forward incompatibility as Metal continues to develop, and publication policy issues on Apple/iOS Store.
 

kburkhart84

Firehammer Games
That I don't think is true either, although I could be wrong. I just know that the whole point of Molten was to port Vulkan to Metal.
You may(likely) know more than I do on the subject. I just know that unless I'm missing something, it doesn't make sense to port code to a single API that only runs on a limited amount of devices, since what we have now DOES already work.

The roadmap added that explanation well after I posted. That explains why Metal is a priority item, but still doesn't explain why Vulkan isn't elsewhere on the list. Is it an item for 2022 or beyond, perhaps?
I haven't kept up with things, but I haven't heard anything about D3D or OGL going away completely, so switching to Vulkan may be a lower priority thing for the moment. It wouldn't be a bad question to pose though, even just to satisfy curiosity.
 

Samuel Venable

Time Killer
You may(likely) know more than I do on the subject. I just know that unless I'm missing something, it doesn't make sense to port code to a single API that only runs on a limited amount of devices, since what we have now DOES already work.
What we have now is OpenGL and Direct3D (for the platforms that apply). The reason Metal is on the roadmap is we are trying to get rid of OpenGL. Vulkan will run on more things than Metal will if Apple allows it, but if you and FrostyCat are correct it sounds like even Molten is not going to make this a reality, and their CI is currently not passing, so that is a red flag for YoYo not to use it on it's own.
 

Samuel Venable

Time Killer
GMS's shader system is out of date.
I'm so afraid of being surpassed or defeated by the new game engine like GDT.
I'm hopeful we don't have much to worry about. I don't really know but it's better to stay positive. I think with Opera now owning YoYo we'll see more love and passion put into GM than what we got from PlayTech, not to compare companies, but PlayTech just wasn't as good a fit for the type of software that GM is. That said, PlayTech still delivered on a lot of good things as well. I'm not out to bash them in any way. Also, what is GDT?

If you meant Game Dev Tycoon, I've just been trolled really hard by own ignorance lol
 

Zhanghua

Member
I'm hopeful we don't have much to worry about. I don't really know but it's better to stay positive. I think with Opera now owning YoYo we'll see more love and passion put into GM than what we got from PlayTech, not to compare companies, but PlayTech just wasn't as good a fit for the type of software that GM is. That said, PlayTech still delivered on a lot of good things as well. I'm not out to bash them in any way. Also, what is GDT?

If you meant Game Dev Tycoon, I've just been trolled really hard by own ignorance lol
godot....4
 

kburkhart84

Firehammer Games
GMS's shader system is out of date.
I'm so afraid of being surpassed or defeated by the new game engine like GDT.
I don't think it's a big deal. If they do switch to Vulkan, even the shader language can still be either HLSL or GLSL(it just has to to be compiled into a different byte code thingy first). And I feel like there are other features I'd prefer to see over upgrading things in the shader department(though I would welcome that as well of course :) ).

And no, I'm not worried about Godot in any case. If it were somehow to just get that much better, I would just switch. But right now, even before the Opera deal, we have dedicated paid staff for GM. There may be people getting paid to develop Godot, but I have it understood that it isn't like a whole company behind them...and if Opera gets on board with it like I think they will, there is no way Godot will catch up anytime soon IMO.
 

Toque

Member
I'd rather have fewer things that are stable than hundreds of cool new features that don't work half the time... :p

I've basically given up on the "drag files onto a GM window" import strategy since they get added to the end of the resource tree instead of the indicated dropoff point
that is annoying. “Given up”. Means that isn’t fixable?
 

HalRiyami

Member
I'm hoping that part of that "refactoring" is front facing and we can finally change resource names and have them reflected in code automatically.
 
10: Can you elaborate on this roadmap point "Workflow Improvements - A new (optional) way of working in your projects that does not use workspaces or chains" - this sounds very promising, but will you be taking community feedback before committing to one design you think will work, so we won't be stuck with something that is too late to change once again?
That sounds interesting and like they might finally be listening to those of us that don't like the new workflow and making something akin to a classic mode




I'm hoping that part of that "refactoring" is front facing and we can finally change resource names and have them reflected in code automatically.
That would be a really nice feature so you don't have to manually update a bunch of code if you decide to change an asset name
 
Last edited:

Andrey

Member
Join us hosting a live video Q&A on Zoom. Stuart Poole, Russell Kay, Andrew Turner and Ross Manthorp will be joining from YoYo Games and we will introduce Krystian Kolondra and Maciej Kocemba from Opera who will all be set to answer your questions. Dates and joining details for the live video will be announced in the future so stay tuned.
Will there be a transcript of the video? I'm more comfortable reading than watching. Or at least subtitles in the video?
 
That is exactly what I'm hoping for. It would alleviate 80% of my gripes with GMS2 right there.
Same

99% of my gripes so far are with the weird workflow stuff like not letting me be choose to pop out windows by default instead of creating new workspace tabs that have to be drug out into windows. So a classic mode that disabled a lot of that would make the software perfect. I'd also love if I didn't have to undock the room editor to have it next to the asset tree because then it's kind of floating there at all times at the front of the IED whenever a room editor tab is open.

It's especially odd because what opens as it's own dialog and what opens as a tab seems to be entirely picked at random. Like the sprite editor being a window but the image editor being a new tab.
 

Fanatrick

Member
GMS's shader system is out of date.
I'm so afraid of being surpassed or defeated by the new game engine like GDT.
I don't think it's a big deal. If they do switch to Vulkan, even the shader language can still be either HLSL or GLSL(it just has to to be compiled into a different byte code thingy first). And I feel like there are other features I'd prefer to see over upgrading things in the shader department(though I would welcome that as well of course :) ).
For the more shader savvy crowd I can assure you this is a huge deal. GM currently only supports standards which are more than a decade old, and even those are not implemented fully. There's still no vertex texture fetching (except on HTML5 where it's supported seemingly by a fluke), there's no way to include files outside the particular shader file, editing and tweaking shaders quickly becomes a juggle due to this because you'll likely want to tweak some general functions along the way, making compatibility fixes for multiple platforms is a nightmare, etc.

No other engine on the market is more finicky in this area than GM. With the advent of 2.3 it easily became it's weakest area when compared to the competition.
 

True Valhalla

Full-Time Developer
GMC Elder
"Opera is investing in YoYo Games in order to accelerate the development of GMS and increase our support for new beginner users, as well as our professional developers using GameMaker."
Is this really the only summary being offered to explain Opera's acquisition? These generic statements are intentionally opaque. If you want to establish trust, be transparent about Opera's financial motivations and tell us how GameMaker fits into their ecosystem.

I guess the GameMaker community has been so neglected by Playtech that a Q&A is considered peak engagement in 2021...
 

kburkhart84

Firehammer Games
I guess the GameMaker community has been so neglected by Playtech that a Q&A is considered peak engagement in 2021...
This is true. I'm hoping plenty of people submitting questions are being specific and asking about exactly these things you mention. It would lessen some of the anxiety around here.
 

Yal

🍋 *lemon noises*
GMC Elder
You may(likely) know more than I do on the subject. I just know that unless I'm missing something, it doesn't make sense to port code to a single API that only runs on a limited amount of devices, since what we have now DOES already work.



I haven't kept up with things, but I haven't heard anything about D3D or OGL going away completely, so switching to Vulkan may be a lower priority thing for the moment. It wouldn't be a bad question to pose though, even just to satisfy curiosity.

I don't think it's a big deal. If they do switch to Vulkan, even the shader language can still be either HLSL or GLSL(it just has to to be compiled into a different byte code thingy first). And I feel like there are other features I'd prefer to see over upgrading things in the shader department(though I would welcome that as well of course :) ).

And no, I'm not worried about Godot in any case. If it were somehow to just get that much better, I would just switch. But right now, even before the Opera deal, we have dedicated paid staff for GM. There may be people getting paid to develop Godot, but I have it understood that it isn't like a whole company behind them...and if Opera gets on board with it like I think they will, there is no way Godot will catch up anytime soon IMO.

Doing some research on SDL2 has this little bit of info:
Wikipedia said:
SDL manages video, audio, input devices, CD-ROM, threads, shared object loading, networking and timers.[6] For 3D graphics, it can handle an OpenGL, Vulkan,[7] Metal, or Direct3D11 (older Direct3D version 9 is also supported) context. A common misconception is that SDL is a game engine, but this is not true. However, the library is suited to building games directly, or is usable indirectly by engines built on top of it.
So basically, GM's rendering system that currently only handles OpenGL is replaced with one that has support for 4 different systems, so it's a direct upgrade; the Metal replacement probably is implemented by means of SDL instead of having a "raw" implementation.

Also re: Godot, it's pretty far behind GM in UX terms. GM does a lot of work hiding things for you (e.g. you can play sounds anywhere in your code without needing to instantiate an audio emitter) and the default Godot entities are on such a low abstraction level you need to do a lot of prep work to get them up to speed. I did some cursory scouting when I learned it had PBR (y'know, I wanna make 3D games) but between having to reinvent the wheel and it overall being designed for people that can't code (at the expense of coding UX) I lost interest pretty quickly. And GMS2 has stolen a lot of Godot ideas recently (GUI variables, sequences), so I kinda can have the cake and eat it sticking with GM anyway. The only two features Godot has that GM hasn't is being able to code custom IDE GUI elements (i.e. plugins), and modern 3D rendering (PBR, with 3D room editor support), but in return it lacks very basic features like being able to change the game icon.

I'm having more faith in GM overall because there's an overarching plan for how to develop it, while Godot's development plan seems to be "lol this is a fun feature I guess I'll implement it"... which leads to a lot of powerful bullet point fluff but neglect for boring-but-practical workflow stuff.


that is annoying. “Given up”. Means that isn’t fixable?
Fixable or not, I don't know; I just find the workaround I described has the best UX at the moment so I will keep using it until I learn of a better way. I find having empty placeholder assets helping organize future ideas so that's an added bonus.

Same

99% of my gripes so far are with the weird workflow stuff like not letting me be choose to pop out windows by default instead of creating new workspace tabs that have to be drug out into windows. So a classic mode that disabled a lot of that would make the software perfect. I'd also love if I didn't have to undock the room editor to have it next to the asset tree because then it's kind of floating there at all times at the front of the IED whenever a room editor tab is open.

It's especially odd because what opens as it's own dialog and what opens as a tab seems to be entirely picked at random. Like the sprite editor being a window but the image editor being a new tab.
You can force a window edit of things (that support it) by right click --> edit (selecting multiple before right-clicking lets you pick "edit all" which is faster than manually opening each). It's still kinda cumbersome and I keep opening objects in tabs by accident because of just assuming double-clicking will open them windowed. I personally also prefer having windowed edit be the default (being able to cross-reference two assets, for instance), workspace tabs helps you focus but it also requires more focus, so for quick and simple things it's just distracting.... not to mention you can't access parents and GUI variables from an object opened as code tabs either, and I use those a lot!
If the standard "object settings" window (the one with the event list, sprite settings, GUI variables, parent/child relationships etc) could be turned into a fullscreen code editor tab as well (and opened when you fullscreen an object) the default-fullscreen behavior of objects would be much better workflow-wise.

Also seconding the workflow chains being counter-productive... my biggest gripe is the automated zoom/positioning being disorienting. A big offender is setting a GUI variable in the room editor; the variable window is so far right the view scrolls away from the object entirely, doesn't scroll back when you close the variable window, and if you have multiple objects that need variables overridden (say, you plop down a dozen NPCs and proceed to give them all unique dialogue) you need to scroll the camera back every time just to click on the next one. With the default settings, the layer tab is so wide that the object you're editing goes completely offscreen when you open a child window, and even with the side tabs hidden the scrolling is far enough to be disruptive. And the worst of all? If you zoom out to not be affected by the scrolling as badly, the view zooms in to display the new windows in 1:1 size so it has no effect except wasting your time.
 

Yal

🍋 *lemon noises*
GMC Elder
For the more shader savvy crowd I can assure you this is a huge deal. GM currently only supports standards which are more than a decade old, and even those are not implemented fully. There's still no vertex texture fetching (except on HTML5 where it's supported seemingly by a fluke), there's no way to include files outside the particular shader file, editing and tweaking shaders quickly becomes a juggle due to this because you'll likely want to tweak some general functions along the way, making compatibility fixes for multiple platforms is a nightmare, etc.

No other engine on the market is more finicky in this area than GM. With the advent of 2.3 it easily became it's weakest area when compared to the competition.
Seconding this as well! Being unable to read texture data in the vertex shader means a whole slew of effects get harder to implement (bumpmapping, water surfaces), there's no way to set up compute shaders (you can kinda work around it using two surfaces, a buffer, and the surface/buffer conversion functions, but I have no idea how much less efficient it is), functions that has been available in GL ES extensions since 1.x (e.g. partial derivatives, which are useful to approximate tangents in data without tangent vertex components) can't be used because shader extensions are unavailable...
(also no native support for features that has been around for quite some time, like cubemaps which are useful for shadows - they're in the manual sheet for the version of GL ES GM's using but you simply can't use them)

And let's not forget advanced shader pipelines need a lot of manual work to get going, you need to manually handle setting the draw target to surfaces, draw things in the correct order, set up uniforms to be able to pass multiple textures into a shader if you want to combine things, etc etc. Meanwhile the other big engines on the market has a visual interface (with those chains the GM UX designer loved so much) which lets you make shader effects that do all those intermediate steps for you automatically with previews of what the results would look like:


It's probably far away as far as features go, but I think it's important to point out just how big the difference is between GM and most other modern engines. There's a lot of cool things that could be done, and it benefits everyone including 2D users.
 

kburkhart84

Firehammer Games
So basically, GM's rendering system that currently only handles OpenGL is replaced with one that has support for 4 different systems, so it's a direct upgrade; the Metal replacement probably is implemented by means of SDL instead of having a "raw" implementation.
I'm familiar with SDL(or used to be). It was always under comparisons back when I first started trying to make games, back when Unity/GM didn't exist or were just getting started, and things like using raw OpenGL, Irrlicht, and Ogre3d were still popular. I haven't kept up with it though so I didn't know it had kept up with the times being able to handle Vulkan and Metal. I didn't see anywhere that they were switching to it, but if they did or already do use it, then it would certainly make things a lot easier.

It's probably far away as far as features go, but I think it's important to point out just how big the difference is between GM and most other modern engines. There's a lot of cool things that could be done, and it benefits everyone including 2D users.
I wasn't disagreeing that an upgrade in shaders wouldn't be great, including for 2d users. My thrust of the point earlier with shaders was simply that what they have provides for the basics at least, and that IMO there are more important things to handle before upgrading the shader stuff. That said, a node-based shader editor is still on my list of eventual TODO stuff, so yes I feel it would be quite useful.
 

Yal

🍋 *lemon noises*
GMC Elder
I'm familiar with SDL(or used to be). It was always under comparisons back when I first started trying to make games, back when Unity/GM didn't exist or were just getting started, and things like using raw OpenGL, Irrlicht, and Ogre3d were still popular. I haven't kept up with it though so I didn't know it had kept up with the times being able to handle Vulkan and Metal. I didn't see anywhere that they were switching to it, but if they did or already do use it, then it would certainly make things a lot easier.
From the roadmap:
Replace OpenTK - Replace with SDL2, this is what we use to render the IDE
 

gnysek

Member
YYG is updating roadmap more frequently in last 2 weeks than in last 5 years :D vTBD for Q2 changed to 2.3.3.

As I see no mentions of Marketplace there, I finally came up with question to submit :)
 

rmanthorp

YoYo Games Staff
Admin
YYG Staff
YYG is updating roadmap more frequently in last 2 weeks than in last 5 years :D vTBD for Q2 changed to 2.3.3.

As I see no mentions of Marketplace there, I finally came up with question to submit :)
Marketplace is web development task so it won't be listed on the GMS2 roadmap right now. It's still in the works.

Just a note. We have close to 200 questions at the moments we are looking into how best to tackle this. We'll probably group questions into categories and answer the categories at a higher level rather than lots of specific questions in the call. In the follow up blog post we will answer more questions specifically but it's not likely we will be taking the time to answer all 200. We may close questions soon if more flood in. Thanks a ton so far folks! Lots of support and nice welcomes and all pretty good questions and a lot of stuff we have answers for that we can share. :)
 

gnysek

Member
Marketplace is web development task
I can see "Marketplace" entry in top menu in IDE... and there's a whole part in IDE dedicated for it, for creating packages, etc. :) That's what I meant. It became less useful in recent months, and some features aren't working anymore as they initially were, so maybe there are plans (to remove it from IDE, or to improve it).

I believe that among those 200 questions some are same, and of course I see nothing wrong in talking about similar things in general categories - that's still better info than none.
 

gnysek

Member
Maybe we finally gonna get Linux IDE too then ;) That's something they gonna cover on Teams Zoom for sure.
 

JeffJ

Member
Just a note. We have close to 200 questions at the moments we are looking into how best to tackle this. We'll probably group questions into categories and answer the categories at a higher level rather than lots of specific questions in the call. In the follow up blog post we will answer more questions specifically but it's not likely we will be taking the time to answer all 200. We may close questions soon if more flood in. Thanks a ton so far folks! Lots of support and nice welcomes and all pretty good questions and a lot of stuff we have answers for that we can share. :)
Would you consider doing more than one Q&A? In the interest of transparency and all. I'm sure many of the questions are over all the same, but it would be a shame if some burning questions are still left unaddressed after both the stream and the follow up blog. Also, it might be worth considering giving people a chance to ask follow up questions to some of the answers we get in the first two rounds.
 

rwkay

YoYo Games Staff
YYG Staff
To address some of the technical issues from the RoadMap
  • OpenTK within the IDE is being replaced as the version that we are using is out of date and buggy, and the newer versions of OpenTK actually use SDL2, we have decided to replace our use of OpenTK with SDL2 directly as that gives us more options and we find that now Apple have deprecated the use of OpenGL on macOS that our customers are getting more issues with device drivers and we need to move to Metal for rendering within the IDE, in the future we will look at moving to DX11/12 on Windows. SDL2 will allow us to improve our in IDE support for IME and better keyboard handling for input, also allowing us to better address DPI issues. We are NOT removing OpenGL from the Runner on any target platform.
  • This is only the begininning of several refactoring issues that we are addressing this year including better Undo System and Room Editor refactoring to remove architectural and design issues that have hampered our ability to improve the IDE, many of these are to pave the way for future improvements, including IDE plugin support.
  • The refactoring will include improvements to intellisense and syntax colouring which needs refactored as to date this has been driven by the syntax colouring and not the language parser, which is the wrong way round, but needs a hefty refactoring process to ensure that we can correctly interpret which choices can be presented within the intellisense dropdown, and improve the speed and responsiveness of the syntax colouring.
  • Another refactoring + consolodiation candidate is our source control integration which will be improved closer to the end of the year where we will look to move to using the command line git (rather than the buggy C# library we currently use) and have a more robust source control experience.
  • Workflow improvements are being worked on but will not come to fruition until later in the year but we shall be gradually releasing our Inspector enhancements to cover all the asset types and integrate into a more efficient editing experience within the IDE, this will decrease our reliance on the Workspace (which will still exist for those that like it) but enhance what can be acheived over the simple edit one thing at a time editors.
We are listening to your feedback all the time and please file feature requests, we review feature requests each week and we adapt our roadmap from those requests, so keep them coming.

When we have something to announce we will let you know, but the roadmap is not set in stone and we reserve the right to change it as circumstances dictate.

Version numbers were removed last year and we have just not decided what those version numbers are yet which is why they are TBD, basically we bump the big version number when big changes are being made and we have not finalised the schedules yet.

Russell
 

rmanthorp

YoYo Games Staff
Admin
YYG Staff
Would you consider doing more than one Q&A? In the interest of transparency and all. I'm sure many of the questions are over all the same, but it would be a shame if some burning questions are still left unaddressed after both the stream and the follow up blog. Also, it might be worth considering giving people a chance to ask follow up questions to some of the answers we get in the first two rounds.
It would be nice but this is ultimately a workload balance thing. We'd love to answer every question in detail but this has already taken up a lot of time for a lot of people. We want to do what we can while still allowing for the actual work to be done on GameMaker and the surrounding content and services. It's something we do see a lot of value in and it's probably not the last time but it would be pretty easy for it to take over actual development work!
 

gnysek

Member
To address some of the technical issues from the RoadMap
And that's old good YYG. No special blog posts, no special live sessions, just raw "sneak peek" info for community, with so many details, that we have no more questions. Thanks Russell!
 

kburkhart84

Firehammer Games
The refactoring will include improvements to intellisense and syntax colouring which needs refactored as to date this has been driven by the syntax colouring and not the language parser, which is the wrong way round, but needs a hefty refactoring process to ensure that we can correctly interpret which choices can be presented within the intellisense dropdown, and improve the speed and responsiveness of the syntax colouring.
This one will help greatly, as the auto-complete got way more complicated with the 2.3 additions.
 

XanthorXIII

Member
What time are you planning for the Zoom/Video Meeting. Us Yanks over here are barely awake by the time it's Noon for you. If you could do something say around say 5PM that would at least put some of us at our Lunch Breaks. Please :D
 

gnysek

Member
2PM GMT seems to be best time for video. It's 6AM i LA and 11PM in Tokio, so with getting up little early/going late to bed, everyone can view it live (sorry Hawaii...).
 

kburkhart84

Firehammer Games
While we don't have a date set in stone yet we are actually pretty set on 5PM GMT for that exact reason! :)
That hits me right at the beginning of lunch-time here in the middle of the US Central Time Zone. The only people I think it hurts are maybe Australians that need to stay up late(late for some people anyway), and that whole Eastern side of Asia for the same reason. You can't satisfy everybody though anyway...and that time is gonna be pretty close to optimal for hitting the biggest amount of people at the best possible time concurrently.
 

Kezarus

Member
For me it's 14h, right in the middle of my workshift. But it's ok, I can see the recording of it afterwards.

Hmm, would a recording of the event will even be posted?

And, wow, Game Maker is truly global. There is people from all over the world (and time zones, lol). =]
 

XanthorXIII

Member
To address some of the technical issues from the RoadMap
  • OpenTK within the IDE is being replaced as the version that we are using is out of date and buggy, and the newer versions of OpenTK actually use SDL2, we have decided to replace our use of OpenTK with SDL2 directly as that gives us more options and we find that now Apple have deprecated the use of OpenGL on macOS that our customers are getting more issues with device drivers and we need to move to Metal for rendering within the IDE, in the future we will look at moving to DX11/12 on Windows. SDL2 will allow us to improve our in IDE support for IME and better keyboard handling for input, also allowing us to better address DPI issues. We are NOT removing OpenGL from the Runner on any target platform.
  • This is only the begininning of several refactoring issues that we are addressing this year including better Undo System and Room Editor refactoring to remove architectural and design issues that have hampered our ability to improve the IDE, many of these are to pave the way for future improvements, including IDE plugin support.
  • The refactoring will include improvements to intellisense and syntax colouring which needs refactored as to date this has been driven by the syntax colouring and not the language parser, which is the wrong way round, but needs a hefty refactoring process to ensure that we can correctly interpret which choices can be presented within the intellisense dropdown, and improve the speed and responsiveness of the syntax colouring.
  • Another refactoring + consolodiation candidate is our source control integration which will be improved closer to the end of the year where we will look to move to using the command line git (rather than the buggy C# library we currently use) and have a more robust source control experience.
  • Workflow improvements are being worked on but will not come to fruition until later in the year but we shall be gradually releasing our Inspector enhancements to cover all the asset types and integrate into a more efficient editing experience within the IDE, this will decrease our reliance on the Workspace (which will still exist for those that like it) but enhance what can be acheived over the simple edit one thing at a time editors.
We are listening to your feedback all the time and please file feature requests, we review feature requests each week and we adapt our roadmap from those requests, so keep them coming.

When we have something to announce we will let you know, but the roadmap is not set in stone and we reserve the right to change it as circumstances dictate.

Version numbers were removed last year and we have just not decided what those version numbers are yet which is why they are TBD, basically we bump the big version number when big changes are being made and we have not finalised the schedules yet.

Russell
Thank you Russell for going over that. This is what we're talking about when communicating to the community. These are the changes that make us excited to continue using GameMaker.
 

gnysek

Member
doubt it'll be better than GMEdit
GMEdit generally improves code editor, while workflow improvements will probably allow to switch into no-workspace layout, where every object/sprite/script/room will open in separate tab and will fill whole screen, and there will be no chains. Something like in Android Studio or Visual Studio (assets/files on left, code in middle, properties on right). Of course I have no idea what layout they gonna chose, but that's how I understand those changes - no more dragging workspaces to edit objects and code :) So, GMEdit improves different part of IDE.

Of course I would welcome code completion for structs/constructors, even if that would require magical JSDOC, like /// @ var myvariable constructor_name in every script we need it. But that's not part of workflow changes.
 

GMWolf

aka fel666
Re Graphics APIs.
The situation kinda sucks atm.
Even though Vulkan is meant to run everywhere, in practice Its only PC, Linux and Android, because apple are a pain in the ass.
So we need at least Vulkan and Metal.
But then Xbox uses DX12, so it makes sense for PC to use DX12 too.
And then there is sony doing their own thing...
To be fair I really like Sony's APIs.

It's not as simple as saying "let's Use vulkan everywhere" Unfortunately .
 

gnysek

Member
Also, I'm not sure that switching to different apis will give noticeable performance boost. Like with every game engines, to be elastic enough for general use, it need to have pipeline which sometimes isn't most optimal, but allows lot of flexibility for programmers, and simplifies a lot, so lot of performance is lost in exchange of flexibility. For example - check @matharoo tutorial about fast grass ( youtube.com/watch?v=MTdAdVt4EIM ) - while it's still GMS, performance raises dramatically, so I would say that for most of games, if there are any slowdowns - there's for sure lot of room to optimize them with existing tools, and it should be game developers who tries to tear every FPS from games, not YYG. Those cases doesn't need new graphical API, but better knowledge of tool that we're using.
But drawing is just a part of engine - performing every step of game, events, computations. etc isn't done by graphics API, but by virtual machine, so for many games even changing graphical engine would give same result, as they might have unoptimized code outside of draw (like in many cases we're computing various things inside draw event, while it should be only to draw, but lot of us checks keyboard or mouse events there).
I've got a game in which shadows are generated by shearing sprites on surface and then surface is drawn with alpha channel. On Xbox UWP that causes poor performance about 10 FPS instead of 60, but when I used vertex buffers - it went up to 60 FPS, with same amount of graphics rendered. I think that even with vulcan, using draw_sprite_pos would still cause same performance problems, and instead of changing graphical engines (Apple forces it sadly), they should just learn us how to squeeze current engine to get most satisfying results. Or maybe prepare some helper functions/features, to optimize drawing by having less texture switching etc.
I would love to see detailed articles about optimizing games, and benchmarks on how much they were optimized giving same display result. Teaching people with few articles and examples to download might give same boost performance in games that changing graphical engine - without any need to touch engine code, which would lead to thousands of new bugs.

tl;dr - instead of changing/optimizing graphical engine, YYG should teach us how to optimize our games better as current engine might be more powerful that it seems.
 
Top