S
Sam (Deleted User)
Guest
Vulkan doesn't use OpenGL or OpenGL ES.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.
Vulkan doesn't use OpenGL or OpenGL ES.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.
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?Vulkan doesn't use OpenGL or OpenGL ES.
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.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?
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?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.
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.Vulkan doesn't use OpenGL or OpenGL ES.
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.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.
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.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?
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.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.
GMS's shader system is out of date.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.
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?GMS's shader system is out of date.
I'm so afraid of being surpassed or defeated by the new game engine like GDT.
godot....4I'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
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 ).GMS's shader system is out of date.
I'm so afraid of being surpassed or defeated by the new game engine like GDT.
Is it ironic that DGT was not made in GDT, but in UE4?If you meant Game Dev Tycoon, I've just been trolled really hard by own ignorance lol
that is annoying. “Given up”. Means that isn’t fixable?I'd rather have fewer things that are stable than hundreds of cool new features that don't work half the time...
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 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 mode10: 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 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 nameI'm hoping that part of that "refactoring" is front facing and we can finally change resource names and have them reflected in code automatically.
Will there be a transcript of the video? I'm more comfortable reading than watching. Or at least subtitles in the video?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.
That is exactly what I'm hoping for. It would alleviate 80% of my gripes with GMS2 right there.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
It was written in HMTL/JS from scratch using 3rd party libraries (mainly jQuery related).Is it ironic that DGT was not made in GDT, but in UE4?
SameThat is exactly what I'm hoping for. It would alleviate 80% of my gripes with GMS2 right there.
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.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 ).GMS's shader system is out of date.
I'm so afraid of being surpassed or defeated by the new game engine like GDT.
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."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."
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.I guess the GameMaker community has been so neglected by Playtech that a Q&A is considered peak engagement in 2021...
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.
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.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.
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.that is annoying. “Given up”. Means that isn’t fixable?
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!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.
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...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.
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.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 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.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.
From the roadmap: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.
Replace OpenTK - Replace with SDL2, this is what we use to render the IDE
I saw when the updated the roadmap with those details...somehow forgot that specific one. Things are starting to make some more sense, how they would fall in place.From the roadmap:
Marketplace is web development task so it won't be listed on the GMS2 roadmap right now. It's still in the works.YYG is updating roadmap more frequently in last 2 weeks than in last 5 years vTBD for Q2 changed to 2.3.3.
As I see no mentions of Marketplace there, I finally came up with question to submit
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).Marketplace is web development task
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.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.
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!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.
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!To address some of the technical issues from the RoadMap
This one will help greatly, as the auto-complete got way more complicated with the 2.3 additions.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.
While we don't have a date set in stone yet we are actually pretty set on 5PM GMT for that exact reason!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
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.While we don't have a date set in stone yet we are actually pretty set on 5PM GMT for that exact reason!
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.To address some of the technical issues from the RoadMap
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.
- 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.
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
Damn, that's 4am here in Sydney. Guess this is the time I ask if there be vod's made available of the Q&A ?While we don't have a date set in stone yet we are actually pretty set on 5PM GMT for that exact reason!
Almost teared up. Too bad it's only for Q4 and doubt it'll be better than GMEdit, but still.Workflow Improvements - A new (optional) way of working in your projects that does not use workspaces or chains
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.doubt it'll be better than GMEdit
/// @ var myvariable constructor_name
in every script we need it. But that's not part of workflow changes.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.