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

XanthorXIII

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.
There's a lot of times in which I'll go back on my stuff and go, WTF was I thinking making these many functions and calling them a bunch of times. We have the tools to make really great fast and perfectly sized games, we also have the tools to make really slow bloated games. The motto should be "If at first you do succeed, try try again to make it more optimized!"
 

slojanko

Member
Just a quesiton to consider, why are you continuing to update the built in source control? There's plenty of easy to use clients which support more than I could expect from GM in the next year.
Seems like a bit of a time waster to add a wrapper for git. I know Unity did it but it's still horrible and often causes problems if more than 1 person is using it.
 

GMWolf

aka fel666
Just a quesiton to consider, why are you continuing to update the built in source control? There's plenty of easy to use clients which support more than I could expect from GM in the next year.
Seems like a bit of a time waster to add a wrapper for git. I know Unity did it but it's still horrible and often causes problems if more than 1 person is using it.
I actually quite like in IDE git support. I use it all the time with jetbrains IDEs.

However jetbrains IDEs do it really well.
I prefer it to every other git tools out there.

Unfortunately GM does a terrible job at it.
I agree that unless they can allocate the resources needed to rival existing tools, they shouldn't bother supporting the feature.

In general I I would like to see a shift away from the all IDE experience.
I understand that it's a draw for most new comers, but I feel like big picture it actually serves a disservice.

Its tricky to balance between giving people what they think they want (all IDE experience ) vs what is actually a good experience (well built, Purpose Tools).

For instance, decoupling the code IDE and resource IDE would be great.
Have one ide to manage things like rooms, sprites, curves, sequences etc, and one for code (which we could swap out for a good coding environment like vs code).

Especially now with the better directory structure This would work better than ever.


[Edit]
I'm sorry I realize this has nothing to do with this topic.
 
Last edited:

gnysek

Member
I actually quite like in IDE git support. I use it all the time with jetbrains IDEs.
I'm using Jetbrains PHPStorm to open GMS 2 projects and I'm pushing/merging/branching/annotating/comparing history fragments from there, that's how good it is... Sometimes I'm even using it to find/replace, as it finds sprites usages in objects and rooms too that way.

So yeah, I would also say that updating git in IDE would take a lot of time, and effects would be still far from expected, compared to other tools. That could be a question: "Will you drop git support inside IDE to save time on better features" ;)
 

Yal

🐧 *penguin noises*
GMC Elder
I actually quite like in IDE git support. I use it all the time with jetbrains IDEs.

However jetbrains IDEs do it really well.
I prefer it to every other git tools out there.

Unfortunately GM does a terrible job at it.
I agree that unless they can allocate the resources needed to rival existing tools, they shouldn't bother supporting the feature.

In general I I would like to see a shift away from the all IDE experience.
I understand that it's a draw for most new comers, but I feel like big picture it actually serves a disservice.

Its tricky to balance between giving people what they think they want (all IDE experience ) vs what is actually a good experience (well built, Purpose Tools).

For instance, decoupling the code IDE and resource IDE would be great.
Have one ide to manage things like rooms, sprites, curves, sequences etc, and one for code (which we could swap out for a good coding environment like vs code).

Especially now with the better directory structure This would work better than ever.


[Edit]
I'm sorry I realize this has nothing to do with this topic.
Yeah, the in-engine git integration always seemed too limited to actually be useful... most notably for not supporting branching in any way, only a monotonous timeline of commits that everyone pushes and pulls from... no rolling back, no alternate branches to test out a feature (or make a special build) you can easily switch between, and so on. I've always just used the Git command line (with the repo created 1 level above the root folder of the project so GM won't accidentally do anything to the git directory) and it's been working just fine. Rolling back especially is vital, there's been a handful of times where I've accidentally made a really destructive change without realizing and my "commit every time you finish something important" philosophy has saved me (especially now when GM constantly autosaves changes).

Between all obscure command-line stuff Git can do, and how rarely most of it is used (e.g. e-mail patches for limited-connectivity repo synchronization) there definitely isn't a lot of business sense for a full 100% GUI integration of Git IDE-wise. And as for the other purposes it could have... the GM Git Gui workflow has very little to do with a standard source control workflow (where everyone tests features on their own separate branch and they're later merged into the "master" branch, with git tags created for notable builds like customer releases so you can recreate that state later if needed, etc) so on top of being limited in utility, it doesn't serve particularly well as a learning tool either...
 

Yal

🐧 *penguin noises*
GMC Elder
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.
Instead of only fullscreen, it would be really nice to see a columns/grid layout system like the one you see in SublimeText (you can pick between up to 4 horizontally arranged columns, up to 4 vertically arranged rows, or a 2x2 grid) where each "chunk" of the screen has its own tab list... while having the "code workspace tabs also has tabs so you can have a million scripts open at a time" thing is nice, being able to compare two things with each other side by side is really useful, e.g. having the list of all item data at hand when you're preparing loot tables (also useful for situations where you're outright copying code from one thing to another new thing). Code usually is more vertical than horizontal in nature, so having only 1 script visible at a time in a fullscreen code editor is a waste of space because half the screen is gonna be the void past the end-of-line... why not let us open another script there and work twice as efficiently instead? :p
 

Yal

🐧 *penguin noises*
GMC Elder

HalRiyami

Member
I remember that Mike also wanted to have minimap of bigger script files, like this thing on right: -Image snipped-
Or they could allow us to use the text editor of our choice by default and supply us with proper language integration for some of the most popular editors. I find myself using Sublime to edit my code sometimes.
Doing this could alleviate some of the pressure of maintaining a modern code editor.
 

kburkhart84

Firehammer Games
I have nothing against an external code editor, as you let the experts do their job if you get what I mean. The catch is that for newer people that just wanna make Click the Clown it suddenly adds a layer of complexity. Maybe they could do both now that they theoretically have an owner that cares and may be more willing to invest more time and money into the product.
 

Elodman

Member
Very interesting readings in recent days,
so perhaps each of these topics (versioning, IDE, ...) would deserve a dedicated thread s.where (for obvious visibility, focus, ... reasons)
+ could bring some insight to both sides - as a base for (non)wishlists, too.
 

JeffJ

Member
This whole in-IDE Git discussion, to me, is basically the same as the sprite editor - I generally oppose the vast amount of time and resources they put into the sprite editor when they went over to GMS2, because even now, it still hasn't caught up to a lot of actual useful features that GMS1's sprite editor had, and what's even more, they will never be able to even remotely compete with the quality and features of dedicated tools, of which there are too many to even count. If they can't even compete with their own older version, how should they ever hope to compete with anything outside their own suite?

And here's the thing - they shouldn't. I wish they would drop the focus on trying to be everything - a sprite editor, a sound editor, a Git environment... If there's a better, more complete and dedicated alternative out there, their resources could be spend so much better literally anywhere else to improve GAMEmaker (not spritemaker, soundmaker, gitcommitter or any other funny name).
 

FrostyCat

Redemption Seeker
This whole in-IDE Git discussion, to me, is basically the same as the sprite editor - I generally oppose the vast amount of time and resources they put into the sprite editor when they went over to GMS2, because even now, it still hasn't caught up to a lot of actual useful features that GMS1's sprite editor had, and what's even more, they will never be able to even remotely compete with the quality and features of dedicated tools, of which there are too many to even count. If they can't even compete with their own older version, how should they ever hope to compete with anything outside their own suite?

And here's the thing - they shouldn't. I wish they would drop the focus on trying to be everything - a sprite editor, a sound editor, a Git environment... If there's a better, more complete and dedicated alternative out there, their resources could be spend so much better literally anywhere else to improve GAMEmaker (not spritemaker, soundmaker, gitcommitter or any other funny name).
Given what I have seen in the roadmap and staff replies on this topic, YoYo has relented on trying to be everything, in fact I think they are preparing to be the opposite.

The last time this similar topic has been brought up, I objected to almost a dozen items on the "planned features" list for having their functionality duplicate community and third-party software. That list is now gone, and I hope it stays gone for good.

With current details on what the refactoring work is about, much of it is for reversing inverted dependencies that impede IDE work (which YoYo staff also use to continue work on the IDE), and "IDE plugin support" has been cited as an outcome of that. Opening the ecosystem to YoYo staff will eventually lead to opening it to us as well.

I understand that the focus on "Inspectors" and "integrated experience" looks like a step back to the "IDE-does-everything" model, but in my opinion this is also a step towards externalizing. If the "Inspectors" are what I think they are, the intense focus on "Inspectors" is a change in course for editors in the GMS 2 IDE, where it only tries to edit GM-exclusive properties instead of everything. I cannot expect Photoshop or GIMP to add support for collision masks or sprite origin points, for example, but they are good at working with the pixels. As long as "Inspectors" work toward a better division of labour between in-IDE and third-party software, I am all for it.
 

Yal

🐧 *penguin noises*
GMC Elder
Re: what constitutes as core functionality, source control is in the "only professionals know what they're doing" turf much more firmly than graphics editing. (everyone has doodled stick figures and forced their parents to glue them to the fridge, right? We don't have fridges in sweden because we can just open a window and put the food in the snow, but that's besides the point) The concept of source control itself makes no sense unless you've done code for some time, it's mostly useful when working in a team, and it requires a bunch of web knowhow to hook up upstream.... you're already required to do a whole lot of external stuff before you can use it. So I'm pretty sure rather few newbies would miss it being relegated to pure external-editors-only, while tearing out the code or sprite editors would instantly impact their experience.

I'm no enemy of external editors, though (I mean, just take a look at my "asset creation program" taskbar section) but it's definitely convenient to be able to instantly create placeholders for new objects.
1613852848268.png
Top to bottom: JAZZ, MilkyTracker, SynthFont, Mixcraft 9, Viena, OpenMPT, Audacity, GxSCC, MS Paint, Snipping Tool, GifCam, GIMP, Krita, Blender, Clip Studio Paint

IMO the only two things the sprite editor needs is
  • A standard clipboard: Ctrl-C copies the image to the system clipboard to allow pasting it into e.g. Photoshop or GIMP, Ctrl-V pastes a chunk of image data in "selected, dragging" mode instead of creating a new brush, so you can click and drag it for precise adjustments (an image-sized paste is almost impossible align correctly in e.g. a 1024x1024 background texture for example). The existing brush paste could be e.g. ctrl-shift-V or ctrl-alt-V. Having to save images to disk and then import them (on both ends!) slows down any image-editing process considerably, and importing an image will silently reset a whole bunch of GM's sprite settings. If just copypasting worked like in literally any other major image editor on the market, using an external art program for effects would be considerably more convenient (thus removing the need for the GMS2 image editor to have any effects at all)
  • Keys to switch subimages while drawing (e.g. ctrl-dot and ctrl-comma as in GMS1). You can click the timeline and use the arrows to change subimages, but this loses focus the instant you click on the drawing canvas and stops working. A lot of my animation work includes either batch editing where I do a certain change (e.g. color replace to change the palette) for each frame, or jump forth and back a lot to chisel out a smooth motion after an initial "just wing it" pass (the onion skinning isn't super useful for animations with like a dozen frames), and having to constantly move my mouse from the center/bottom canvas zone to a very precise timeline moment in the top-left corner of the screen (without accidentally clicking the wrong moment or dragging images around) wears out my hand and patience at about the same rate.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
  • Keys to switch subimages while drawing (e.g. ctrl-dot and ctrl-comma as in GMS1). You can click the timeline and use the arrows to change subimages, but this loses focus the instant you click on the drawing canvas and stops working. A lot of my animation work includes either batch editing where I do a certain change (e.g. color replace to change the palette) for each frame, or jump forth and back a lot to chisel out a smooth motion after an initial "just wing it" pass (the onion skinning isn't super useful for animations with like a dozen frames), and having to constantly move my mouse from the center/bottom canvas zone to a very precise timeline moment in the top-left corner of the screen (without accidentally clicking the wrong moment or dragging images around) wears out my hand and patience at about the same rate.
Try pressing the 1 or 2 keys on the keyboard. ;)
 

gnysek

Member
Copy-paste in image editor is a pain that only those who where in Dundee and went up from YYG Office to Law Hill know*.

*there's quite a view from there, but the hill is very steep
 

JeffJ

Member
If you ask me, the only thing the sprite editor needs is the ability to import frames, switch them around, add more frames and delete existing frames, and the offset setting. That's about it. It doesn't need to be able to draw a single pixel for all I care. But I realize this is probably a highly unpopular opinion.

The only internal editors I could honestly defend as being relevant to GM is a particle editor and the room editor. I'll admit that a shader editor would be very nice, but even that is non-GM specific fluff.
 

Gamer (ex-Cantavanda)

〜Flower Prince〜
In the OpenSQL of Opera intornet Browser's (Not Bowser from Mario but B R Owser with an R) you are can now put videeo games of making in "Game Maker 2" integrated HTLM function OpenVulkan when also GMEdit feels a little weeping birthday cake under the development of optimisation of New Technical Writer At YoYoGame'S when the Q&A goes live inside of my mind inside of my skull inside of my insides when the boat goas roaring in the sea feels like cute birds inside of a cave with bubbles OpenSQL Vulkan Bowser's lol This Time (WITH R) So I was ACTUALLY referring to Bowser from Mario lol.
 

gnysek

Member
the sprite editor needs is the ability to import frames
And don't namimg them with random GUID, so you can easily replace those frames, and see changes in git, instead of getting a new random file, which you cannot compare in git history (some tools allows to preview image differences).
But as @Dan mentioned in this post, it seems that YYG gonna change those random names to something better, as it's possible that antiviruses treat those files as suspicious. Also, in 2.3.0 release there get rid of GUIDs in all .yy files used for structure, as using those random identifiers works only for things that aren't often (or at all) changed - otherwise any randomness leads to problems with tracking changes in version control systems.
Another good change.
 

Toque

Member
If you ask me, the only thing the sprite editor needs is the ability to import frames, switch them around, add more frames and delete existing frames, and the offset setting. That's about it. It doesn't need to be able to draw a single pixel for all I care. But I realize this is probably a highly unpopular opinion.

The only internal editors I could honestly defend as being relevant to GM is a particle editor and the room editor. I'll admit that a shader editor would be very nice, but even that is non-GM specific fluff.
I like having the sprite editor. For simple edits with sprites. My number one complaint is the pencil tool has a big double cross with a huge pencil pointer when your drawing. I mean in pixel art the pencil covers half of what your doing. Hard to see what you drawing. Hate it. I dont see anything in preferences to get rid of it.........
 

Posh Indie

That Guy
If you ask me, the only thing the sprite editor needs is the ability to import frames, switch them around, add more frames and delete existing frames, and the offset setting. That's about it. It doesn't need to be able to draw a single pixel for all I care. But I realize this is probably a highly unpopular opinion.
Get in line, pal. I have been carrying that torch and pitchfork for eternity. I prefer the focus drops away from the sprite editor as there are already really great (read: way better) dedicated applications for that. Typically it ends in everyone telling me it is useful and should stay. Then I ask, "Why not throw a DAW in while we are at it?" and somehow that is absurd.

(Disclaimer: I do not actually want an integrated DAW in GMS.)
 

Kezarus

Endless Game Maker
Don't know why the sprite editor on GMS 1.4 is vastly better than GMS 2.3. .......it's a little confusing. o.Ô

But I agree with @Posh Indie and @JeffJ, no need for a full fleged sprite editor. If it imports, crop images, and offset settings, its just wonderful. There is a lot of other dedicated drawing software just for just drawing (and some really good are even free!).

No need for the YoYo Team to expend time and resources on that in my humble and honest opinion.
 
Last edited:

kburkhart84

Firehammer Games
Don't know why the sprite editor on GMS 1.4 is vastly better than GMS 2.3. .......it's a little confusing. o.Ô
This is because GMS2 was a complete re-write of the IDE...the functions missing in the GMS2 Sprite editor weren't removed, rather they were simply never written in the first place(I know someone said that already, maybe in this same topic but I can't remember).

I also agree that integrating these things in the IDE is pointless as it already can be done externally. @Posh Indie is right...if we care about the internal Sprite Editor, why not a DAW? It's the same logic to me.

I also understand though that the reason they do it is try to make it easier for newer people to get into. It is one less external program they have to mess with, and a Sprite editor lets you get something visual on the screen going...other editors like a DAW would be more complicated to add and don't add to the visual appeal, despite the fact that games need audio too. The visuals are really what brings customers in many cases...that's the reality of the thing.
 

Alice

Darts addict
Forum Staff
Moderator
If I were to explain why add Sprite Editor and not DAW: You can get something playable using sprites without audio, but you're much more limited if you have audio without sprites.
(full disclosure: you're not *that* limited because you can still use Draw functions to create visuals without sprite, but it's much more of a chore)

That said, I do agree that there's no much need for advanced sprite editor, because there are plenty of external advanced sprite editors. What GM:S 2 has right now seems quite sufficient; no need to axe something that's already there, but also no need to make it a tool for professionals if professionals already use other tools.
If there's one change I'd ask for, is for Ctrl+C to paste-select copied region like a normal graphics editor. I have yet to find someone who thinks: "wow, this brush on Ctrl+C is so cool, it's so much better than just plain pasting".
 

Alice

Darts addict
Forum Staff
Moderator
@Alice I've seen cool stuff done with custom brushes, but they're usually their own tool. In GMS, the brush affects the paste, eraser, pencil(?!), etc.
I am well aware brushes - when properly implemented - can be extremely useful tool. I just dislike how Ctrl+C is taken from regular pasting to creating a new brush, and I've yet to find anyone who prefers this specific shortcut acting this way (especially since - as far as I know - there is no hotkey for basic Paste).
 

gnysek

Member
If we could get all missing features from GMS 1.4 in sprite editor, which aren't already improved in 2.x, that would be enough. Copy-paste topic is definitely "must-have" in my opinion, others should be "under consideration".
 

mykyl66

Member
I wish I had a tick box that when I create a sprite it automatically creates an object for it if I tick the box. e.g I name a sprite spr_Beasty and I tick create obj it creates obj_Beasty automatically as well. Im lazy. ;)
 

Yal

🐧 *penguin noises*
GMC Elder
I am well aware brushes - when properly implemented - can be extremely useful tool. I just dislike how Ctrl+C is taken from regular pasting to creating a new brush, and I've yet to find anyone who prefers this specific shortcut acting this way (especially since - as far as I know - there is no hotkey for basic Paste).
There's several objective issues with the "paste as brush" system so I think it goes beyond just preferences:
  • Since you can't not paste as a brush, things you don't want to use as brushes will eat up the 5-brush buffer, eventually pushing away the stuff you'd want to use unless you take special measures to keep them in memory.
  • Drawing is a one-off operation without potential for adjustments later, and brushes are centered around the mouse cursor, which makes it really difficult to paste large images (if you're zoomed in so you can make precise adjustments, you can't see the edges of the sprite so you're drawing blindly, if you're zoomed out so you can align it properly you can't make precise adjustment)
  • Since copying also creates brushes instead of putting the image on the system clipboard, you can't copypaste an image to a separate paint program for quick filters... and you can't even copypaste images from one sprite to another unless you first open both of them for editing!

I wish I had a tick box that when I create a sprite it automatically creates an object for it if I tick the box. e.g I name a sprite spr_Beasty and I tick create obj it creates obj_Beasty automatically as well. Im lazy. ;)
You have it the wrong way 'round... there's a button to create a new sprite on the object editor form, it's one of the old GM traditions.
 

gnysek

Member
I'm not sure, but I think that there window focus issues in sprite editor, and sometimes when I cannot copy and paste, clicking (preferably with selection tool) fixes this issue.

I've added question about Image editor using Q&A Form :) We'll see if they gonna say something about it :)
 

Yal

🐧 *penguin noises*
GMC Elder
I'm not sure, but I think that there window focus issues in sprite editor, and sometimes when I cannot copy and paste, clicking (preferably with selection tool) fixes this issue.

I've added question about Image editor using Q&A Form :) We'll see if they gonna say something about it :)
As far as I can tell there's an issue where copying only makes an image available for pasting in currently open image editor windows, which might very well be a feature intended to work around the lack of a clipboard. So select->copy->open new sprite->paste won't work, you need to open the target sprite first and then copy the source.
 
Top