• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Things that need added(or exposed) for 3d games

kburkhart84

Firehammer Games
I'm making a nice long list of things that we need to make 3d games better, and better looking. I'm specifically looking for things that we simply CANNOT do ourselves. I won't be adding things like vector objects, model importing/animation, or similar as those are things we should be able to code ourselves. I'm adding things that must be added(or exposed) at a lower level than what we have access to. I'll show the current list here, and as people mention things, I'll add it on. This way, we can have the information stored in a single place. Note that these are not in any particular order, and many of them are much less useful or less priority than the others.

Updated shaders(we are on an extremely early version of OpenGL(ES) shaders right now)
Geometry Shaders(possibly redundant with GPU Buffers)
Tesselation Shaders(possibly redundant with GPU Buffers)
Compute Shaders
Exposure of Shader compilation and upload(maybe integrating the build-time converter via extension)
Texture reading in vertex buffer(if it doesn't get added via updated shaders)
3d Textures
Array Textures
cubemaps
GLSL ES MRTs(if not included in shader updates)
Stencil buffer access
Texture options(formats, layouts, steamed/not streamed, filtering, etc...), including, block texture compression (all the BCs, including BC6 and BC7, and ASTC compression for mobile).
Arbitrary Surface formats(for things like depthmaps instead of just RGB)
More direct control over texture loading(which ones are in memory, etc...), as in more direct control than what is provided by texture groups
GPU Buffers(as shared by GMWolf), can be used for sending data to shaders, as well as have shaders modify in order to share data with other shaders. These need to be accessible by both GML and on the GPU side
Scissor masks, which can be quite useful for 2d as well(we currently abuse surfaces for this)
 
Last edited:

GMWolf

aka fel666
  • More texture options (formats, layouts, streamed/not streamed, filtering etc)
  • More explicit texture loading functions.( being able to say exactly what textures should be in memory, this includes loading and evicting textures. perhaps even disabling automatic loading of some textures. as well as querying the status of textures).
  • maybe partially resident textures? this seems overly specific to 3D rendering so i don' feel as strongly about it.
  • more powerful file system apis: allowing us load binary ready files directly into pinned memory.
    This would be useful to load data directly into buffers etc.
  • A generic asset API (both IDE and GML). Loading external files is great and all, but being able to have a "binary blob" type resource, that can be referenced with an identifier like all other resources would make things like 3D models much easier.
    Perhaps even have a processing stage that happens at compile time. (A small GML or C# script that processes the input file into the binary blob available at runtime)
    This would be useful for models etc.
  • lots of coffee
  • Higher performance GML (for CPU culling etc)
  • Ring buffers / buffer allocators. I don't like writing that kind of stuff.
  • Some kind of first class support for uniform buffers / layouts. Maybe we could just supply a Struct or something.

Things I don't think make sense for GM:
  • Async compute (I don't think anyone wants to cry in a sea of barriers and semaphores).
  • memory aliasing (again, lots of pain)
  • partial residency (that's way too specific to 3D and if you really needed GM clearly isn't the right tool)
 

kburkhart84

Firehammer Games
More texture options (formats, layouts, streamed/not streamed, filtering etc)
I'll add it.

More explicit texture loading functions.( being able to say exactly what textures should be in memory, this includes loading and evicting textures. perhaps even disabling automatic loading of some textures. as well as querying the status of textures).
I'll add it. They may come back saying that Texture groups fill this role, and they have some(but not all) of these things.

maybe partially resident textures? this seems overly specific to 3D rendering so i don' feel as strongly about it.
I'm unfamiliar with this. What are "resident" textures?

more powerful file system apis: allowing us load binary ready files directly into pinned memory.
This would be useful to load data directly into buffers etc.
Can't we already directly load a whole file into a buffer already? Maybe I'm missing something of what you are getting at on this point.

A generic asset API (both IDE and GML). Loading external files is great and all, but being able to have a "binary blob" type resource, that can be referenced with an identifier like all other resources would make things like 3D models much easier.
I think it's a good suggestion...and though it could be useful, I don't think it really directly applies to 3d so much, especially since we have the external files. And I honestly think it would be inferior to using external files simply because you would have to re-import every time it changed(unless they did this asset different from the others).

lots of coffee
I usually do Mt. Dew Code Red for my caffeine fix. I love the smell of coffee, but have never liked the taste.

Higher performance GML (for CPU culling etc)
I'm not sure what else they can do besides optimizing it in general(including the YYC). It doesn't really fit on this list though.

  • Ring buffers / buffer allocators. I don't like writing that kind of stuff.
  • Some kind of first class support for uniform buffers / layouts. Maybe we could just supply a Struct or something.
I'm also not familiar with these either. Isn't a uniform a value that gets sent to a shader or something? Can you explain more what you are getting at so I can see what is best added to the list(and how to describe it)?
 

Roldy

Member
Out of all those I would say the first on your list would be the most useful/highest priority/biggest bang for the buck: Updated shader model.

At the very least a GLSL ES version that supports MRTs and sampler access in vertex shader. It is a pain if you need those too write separate platform specific shaders for basic functionality that is supported on virtually every platform.

It is equally useful for 2d as it is 3d.
 
Last edited:

GMWolf

aka fel666
I'm unfamiliar with this. What are "resident" textures?
Resident textures are on the GPU (and have memory allocated and bound totthem, plus depending on the APIs have views etc...).

A partially resident texture would only have some portion of the image loaded, so you could, for instance, stream in the mips as the object gets closer to the camera.
I actually dont think its something GM needs/should get. It's very much not in scope.

Can't we already directly load a whole file into a buffer already? Maybe I'm missing something of what you are getting at on this point.
What I'm proposing is allowing us to load contents of a file directly into a GPU buffer without any CPU staging buffer.

I think it's a good suggestion...and though it could be useful, I don't think it really directly applies to 3d so much, especially since we have the external files.
It applies to GM as a whole.
But for 3D it would be useful to store model data, look up tables, acceleration structures, etc. Stuff you dont want to do processing on at runtime.
Rather than have to run my exports through a tool to "compile" the asset, and then load it through file apis, I would rather be able to have GM run my tool at compile time, as needed.

Also being able to refer to those assets via a first class identifier would bring those custom assets closer to built in assets (I dislike having to manipulate files).

And I honestly think it would be inferior to using external files simply because you would have to re-import every time it changed(unless they did this asset different from the others).
That's were the custom script tool plays in. You would add your source file (like an external file), and GM would rerun your converter tool whenever the asset is changed.
It's much more ergonomic than having to run your converter manually everytime you change modify your source asset.

If you're loading your models directly from Objs or GLTFs you're gonna leave a lot of optimizations on the table.
Usually you will want to process your meshes offline to split then into meshlets, optimize the vertex layout for cache etc, make it ready for GPU upload, and generate visibility and bounding box data to cull your meshes.
That's not something you want to be doing at run time.

I'm not sure what else they can do besides optimizing it in general(including the YYC). It doesn't really fit on this list though.
Its part of the things needed for more effective 3D.
Arguably everything on your list isn't specific to 3D either. Those are just general graphics things...

I'm also not familiar with these either. Isn't a uniform a value that gets sent to a shader or something? Can you explain more what you are getting at so I can see what is best added to the list(and how to describe it)?
Rather than upload your values one by one, you can populate a buffer with data and have your shader read that.

The issue is that shaders have strict layout concerns so writing your data to the buffer for consumption by the GPU is always tricky.
Some kind of first class concept to manage uniform buffers would be great. (Maybe we can have a uniform buffer asset type, written in glsl, that allows structs to be converted into a matching uniform buffer).

Of course I say uniform buffer but this applies to SSBOs as well.

Ring buffers are basically a way of allocating data from a buffer.
You create a large buffer and grab sections of it to fill with data and bind to your render passes (You could fill it with transforms, uniforms data ,material data etc). The size of the buffer will depend on how many objects you are about to render so an allocation strategy is needed.
The buffer will eventually get recycled so it also needs to be fenced so you can synchronise writing to the buffer, and reading from the buffer on thr GPU.
If you don't, you risk writing over sections that the GPU is reading, and your gonna have a bad time.

Rather than have everyone write their own solutions to ring buffers, it would be nice to have functions to manage them.
 
Last edited:

GMWolf

aka fel666
I also dont see buffers in your list.
Those are, I'd say, by far the most important features. (More important than MRTs, compute shader, and certainly Geometry shaders).

But I think all that can be boiled down to having a more complete Graphics API abstraction. No need to list every feature out there. Which is why I didn't Focus on that in my list.
 

kburkhart84

Firehammer Games
Resident textures are on the GPU (and have memory allocated and bound totthem, plus depending on the APIs have views etc...).

A partially resident texture would only have some portion of the image loaded, so you could, for instance, stream in the mips as the object gets closer to the camera.
I actually dont think its something GM needs/should get. It's very much not in scope.
Interesting...though I don't think it is anything that would enable us to do something with 3d that we can't do now, and as you say it isn't in scope.

What I'm proposing is allowing us to load contents of a file directly into a GPU buffer without any CPU staging buffer.
So you are referring to a GPU buffer instead of the buffer in RAM that we already have. Is there something in particular you can do with this that we really can't do right now though?

That's were the custom script tool plays in. You would add your source file (like an external file), and GM would rerun your converter tool whenever the asset is changed.
It's much more ergonomic than having to run your converter manually everytime you change modify your source asset.

If you're loading your models directly from Objs or GLTFs you're gonna leave a lot of optimizations on the table.
Usually you will want to process your meshes offline to split then into meshlets, optimize the vertex layout for cache etc, make it ready for GPU upload, and generate visibility and bounding box data to cull your meshes.
That's not something you want to be doing at run time.
This seems like it would be nice...but it seems more of a convenience and performance enhancement than something that opens a door to something we simply can't do in any fashion right now. It also seems like something that would have Yoyo spend a lot of time on.

Rather than upload your values one by one, you can populate a buffer with data and have your shader read that.

The issue is that shaders have strict layout concerns so writing your data to the buffer for consumption by the GPU is always tricky.
Some kind of first class concept to manage uniform buffers would be great. (Maybe we can have a uniform buffer asset type, written in glsl, that allows structs to be converted into a matching uniform buffer).

Of course I say uniform buffer but this applies to SSBOs as well.

Ring buffers are basically a way of allocating data from a buffer.
You create a large buffer and grab sections of it to fill with data and bind to your render passes (You could fill it with transforms, uniforms data ,material data etc). The size of the buffer will depend on how many objects you are about to render so an allocation strategy is needed.
The buffer will eventually get recycled so it also needs to be fenced so you can synchronise writing to the buffer, and reading from the buffer on thr GPU.
If you don't, you risk writing over sections that the GPU is reading, and your gonna have a bad time.

Rather than have everyone write their own solutions to ring buffers, it would be nice to have functions to manage them.
I also dont see buffers in your list.
Those are, I'd say, by far the most important features. (More important than MRTs, compute shader, and certainly Geometry shaders).
So are the buffers you are referring to here in these two quotes two different things? I know the first one is about sending data to shaders(as an alternative to individually defining uniforms). Is that what you are getting at in the second one as well?
 

GMWolf

aka fel666
Interesting...though I don't think it is anything that would enable us to do something with 3d that we can't do now, and as you say it isn't in scope.
lets you do texture streaming more easily, and do unique texturing (virtual texturing). but yeah, not in scope i dont think.
So you are referring to a GPU buffer instead of the buffer in RAM that we already have. Is there something in particular you can do with this that we really can't do right now though?
The GPU can read and write to it. (vertex buffers, index buffers, uniforms, ssbos).
For example, instead of rendering your object one by one, and setting the transform for each object individually via uniforms, you can have one big buffer with all your transforms and render all your objects in one go.

Specifically the file stuff i'm referring to: it would allow you to upload mesh data from the disk to the GPU without needing to have an intermediate buffer in ram.

This seems like it would be nice...but it seems more of a convenience and performance enhancement than something that opens a door to something we simply can't do in any fashion right now. It also seems like something that would have Yoyo spend a lot of time on.
But that's the point of an engine, to make it easier than having to do everything yourself.
I don't think it would be that difficult for yoyo to integrate. they already have a dependency system to rerun the texture packer and audio converter. All we would need is a new asset type which points to a source file, and an executable to compile that file, and have a function to access the raw bytes that were produced by that file.

So are the buffers you are referring to here in these two quotes two different things? I know the first one is about sending data to shaders(as an alternative to individually defining uniforms). Is that what you are getting at in the second one as well?
yeah, they are the same thing, but buffers can be used for the following:
Index buffers, vertex buffers, uniform data, SSBOs (whatever data you want to send to the GPU for the shader to access and do whatever you like). and more.

They can also be written to by shaders. So you could have one shader generate data that is read by another (that includes mesh data).


I dont think its worth sending them a list of all the API features. They know they exists and are more than likely already using them internally.
If you do send a list i think saying something along the lines of "a more complete graphics api abstraction" would be sufficient.
I think that the other features that are then built on top of, or around graphics features are far more interesting to discuss. After all, if all you wanted were more shaders and stencil buffers, you would just be using opengl.
The point of GM is to manage your assets and provide utilities on top of low level apis.
 

kburkhart84

Firehammer Games
The GPU can read and write to it. (vertex buffers, index buffers, uniforms, ssbos).
For example, instead of rendering your object one by one, and setting the transform for each object individually via uniforms, you can have one big buffer with all your transforms and render all your objects in one go.

Specifically the file stuff i'm referring to: it would allow you to upload mesh data from the disk to the GPU without needing to have an intermediate buffer in ram.
Gotcha...makes sense. But I'm not sure it applies to the list because unless I'm missing something, there isn't anything you can do as far as the final game with it that can't be done the "normal" way, except some performance enhancement. It seems like it would be good for a second round of improvements once we got the higher priority things done.

EDIT***** forgot the rest, adding it now.

But that's the point of an engine, to make it easier than having to do everything yourself.
I don't think it would be that difficult for yoyo to integrate. they already have a dependency system to rerun the texture packer and audio converter. All we would need is a new asset type which points to a source file, and an executable to compile that file, and have a function to access the raw bytes that were produced by that file.
This is a valid point, but it still isn't really the kind of thing I'm looking for on this list. I'm more looking for things that they need to expose for us to be able to do things with 3d, things we simply cannot do because we don't have access to the pipeline. Updating shaders for example makes perfect sense, as that opens a lot of doors to things. This thing you suggest feels like an enhancement, but not a requirement to be able to do something. I don't disagree that it is a good suggestion, but it is kinda out of scope for what this list here is supposed to be.

yeah, they are the same thing, but buffers can be used for the following:
Index buffers, vertex buffers, uniform data, SSBOs (whatever data you want to send to the GPU for the shader to access and do whatever you like). and more.

They can also be written to by shaders. So you could have one shader generate data that is read by another (that includes mesh data).
This one actually makes more sense to add to the list now that you have elaborated. It isn't the part about using a buffer instead of uniforms for shaders, but the fact that shaders can share data with each other. Adding... :)

I dont think its worth sending them a list of all the API features. They know they exists and are more than likely already using them internally.
If you do send a list i think saying something along the lines of "a more complete graphics api abstraction" would be sufficient.
This is actually a valid point. But, since Russell PMed me asking for specifics, I figured I would give him some.
 
Last edited:

GMWolf

aka fel666
Gotcha...makes sense. But I'm not sure it applies to the list because unless I'm missing something, there isn't anything you can do as far as the final game with it that can't be done the "normal" way, except some performance enhancement. It seems like it would be good for a second round of improvements once we got the higher priority things done.
haha well in that case, the higher priority stuff isjust : a more complete graphics API. I don't think that's a terribly useful list to suggest to YYG.

Exposure of Shader compilation and upload(maybe integrating the build-time converter via extension)
I think offline shader compilation is the way to go. They could even generate reflection data at compile time, or change binding points of uniform resources according to some descriptor data structure.
 

kburkhart84

Firehammer Games
Sorry, I edited my above post to address the other things(I accidently finished the post when I wasn't actually finished).
 

kburkhart84

Firehammer Games
I think offline shader compilation is the way to go. They could even generate reflection data at compile time, or change binding points of uniform resources according to some descriptor data structure.
Part of why I personally would like to see this though is that it would allow a much easier pipeline for creating something like a node-based shader editor. We need something to be able to preview shaders as created from the nodes, and I don't think that a CPU code emulator for the shader pipeline is a good way to go for that.
 

GMWolf

aka fel666
We need something to be able to preview shaders as created from the nodes, and I don't think that a CPU code emulator for the shader pipeline is a good way to go for that.
could still be offline shader compilation.

Or do you mean being able to compile arbitrary shaders? I think this will be a huge issue for GM.

First of all its not compatible with consoles. They need to have their shaders be compiled first, and I don't think they can ship the game with the proprietary shader compilers. So I think that rules out the feature out right.
Also shader compilation can be slow as heck.

Second of all, modern APIs (such as dx12 which is used on xbox) require you do do a lot more than just binding a shader. you have to build pipelines, compatible pipeline layouts, descriptor sets etc.
Knowing the set of all shaders that will be used is a great way to greatly improve the performance of your graphics system, and can simplify a lot of processes.
Being able to create new shaders arbitrarily at runtime could be problematic and prevent YYG from moving to newer APIs or make optimizations.
Its generally not a great idea.
 

GMWolf

aka fel666
oh, of course:
Block texture compression (all the BCs, including BC6 and BC7, and ASTC compression for mobile).
(very high priority)

you have 3D textures, but array textures are very useful too.
(high priority)

surface/texture formats and such.
(very high priority)

UAVs! both for buffers and textures. This allows you to write data to textures without them being render targets or bound to a frame buffer.
(kinda medium priority)

arbitrary SRVs, UAVs and RTVs. This allows you to bind different image planes, mip levels, and sub-resources (such as stencil buffers).
(this is not super hight prority to be fair)

Scissors masks (extremely useful in 2D as well. currently people abuse surfaces as scissors 🤦‍♂️).
(high priority)

buffer mapping, (including persistent, coherent, device local, pinned memory etc). This could produce an object accessible through the existing buffer functions.
(medium/high priority.)

queries.
(low priority)

Fences. streaming data to the gpu will require us to fence our buffers. (unless GM somehow manages that for us).
(depending on how buffers are managed, either high priority or not necessary)
The exact strategy used for buffers here will be the difference between rendering dozens of objects and rendering millions of objects so i think special consideration needs to be taken here.

also If you do want a list that discriminates the various API features, I don't feel like geometry shaders are a priority at all. they are practically useless.
also stencil buffers; of very limited utility when compared to the rest.

This is actually a valid point. But, since Russell PMed me asking for specifics, I figured I would give him some.
Fair enough, I guess ill keep posting api features as I remember them.


To be honest: i'm actually not the best person to be contributing feature lists.
100% buffers, surface formats, block compression should be accessible.
but a lot of the other things I mention are just what I would want/need to create a high end renderer (which is not the goal of GM)
Although they would also be super useful for 2D effects 🤔
 
Last edited:

kburkhart84

Firehammer Games
could still be offline shader compilation.

Or do you mean being able to compile arbitrary shaders? I think this will be a huge issue for GM.
That's what I mean...you can change the shader at any time by changing the node tree so you need to be able to recompile shaders basically on demand. I know other engines can do it, so it is certainly possible. That said, it only needs to do it on the development machine, no need to do it on all the exports. This is why I mention doing it in an extension instead of as part of the native code base. To do it right now, I would have to find a DLL to do it(YAL provided me with something but I haven't done any testing as this idea is far down my TODO list honestly). But there is nothing wrong with me putting in on the list so hopefully they get it in and I can do it natively instead of having to do it with a workaround DLL dependent on undocumented methods.

Block texture compression (all the BCs, including BC6 and BC7, and ASTC compression for mobile).
I'll add a note to include this with the line I have about texture formats.

you have 3D textures, but array textures are very useful too.
I can add that.

surface/texture formats and such.
I thought I had that on there, I'll add it.

UAVs! both for buffers and textures. This allows you to write data to textures without them being render targets or bound to a frame buffer.
(kinda medium priority)

arbitrary SRVs, UAVs and RTVs. This allows you to bind different image planes, mip levels, and sub-resources (such as stencil buffers).
(this is not super hight prority to be fair)
I'm not sure if I should really add these...I think as you say, the priority is kinda low for them. Maybe for the next round?!

Scissors masks (extremely useful in 2D as well. currently people abuse surfaces as scissors 🤦‍♂️).
(high priority)
ADDING! especially since you are right that it would be really useful for 2d as well.
buffer mapping, (including persistent, coherent, device local, pinned memory etc). This could produce an object accessible through the existing buffer functions.
(medium/high priority.)

queries.
(low priority)

Fences. streaming data to the gpu will require us to fence our buffers. (unless GM somehow manages that for us).
(depending on how buffers are managed, either high priority or not necessary)
The exact strategy used for buffers here will be the difference between rendering dozens of objects and rendering millions of objects so i think special consideration needs to be taken here.
I'll hold off on adding these things...we don't even have the buffers at all just yet, so I think we should wait and add these to the second list later. They may actually add part of these once they add the buffers in the first place.

To be honest: i'm actually not the best person to be contributing feature lists.
100% buffers, surface formats, block compression should be accessible.
but a lot of the other things I mention are just what I would want/need to create a high end renderer (which is not the goal of GM)
Although they would also be super useful for 2D effects
No worries...you have posted more ideas than anyone else so far, even if I disagree with how high a priority some of them would be.
 

HalRiyami

Member
At this point, this list is looking more like "just give us everything" than "here is a short list of things we want in the near future" and I don't think it is what YYG was hoping for when they asked @kburkhart84 to make them a list. I personally prefer to give them a short list that the community curates than to leave YYG to decide which of these to implement. Maybe we could hold a poll once the list reaches a satisfying length to gauge the community's support for each of these options. People are far more likely to vote than comment with their suggestion and if we could choose up to three different options I reckon we would get those three implemented much sooner than if we were to leave YYG to decide that on their own.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
While I think it's great that you guys are creating this list and I'm all for pushing GameMaker forward, it's been said many many times that YYG will NOT be doing much in GM directly for 3D support. If any new feature gets added it will have to be useful for 2D - or incredibly easy to impliment - as they aren't going to add anything that is for a tiny niche group and that takes many man-hours to add and test. Also, none of this is very beginner friendly, which also puts it lower down the priority list, since YYG (and now Opera) have stated a lot recently that they want to lower the bar for beginners and entry-level programmers.

Not saying that you shouldn't be doing this, as I 100% support ANY feature request that improves GM or pushes it forward, but I just want you to have a realistic perspective on what YYG may or may not add. :)
 

kburkhart84

Firehammer Games
At this point, this list is looking more like "just give us everything" than "here is a short list of things we want in the near future" and I don't think it is what YYG was hoping for when they asked @kburkhart84 to make them a list. I personally prefer to give them a short list that the community curates than to leave YYG to decide which of these to implement. Maybe we could hold a poll once the list reaches a satisfying length to gauge the community's support for each of these options. People are far more likely to vote than comment with their suggestion and if we could choose up to three different options I reckon we would get those three implemented much sooner than if we were to leave YYG to decide that on their own.
While I think it's great that you guys are creating this list and I'm all for pushing GameMaker forward, it's been said many many times that YYG will NOT be doing much in GM directly for 3D support. If any new feature gets added it will have to be useful for 2D - or incredibly easy to impliment - as they aren't going to add anything that is for a tiny niche group and that takes many man-hours to add and test. Also, none of this is very beginner friendly, which also puts it lower down the priority list, since YYG (and now Opera) have stated a lot recently that they want to lower the bar for beginners and entry-level programmers.

Not saying that you shouldn't be doing this, as I 100% support ANY feature request that improves GM or pushes it forward, but I just want you to have a realistic perspective on what YYG may or may not add. :)
I 100% agree with both of you on this. It is why I filtered so many of the suggestions that were already provided. I was planning on doing something like that, filtering out the ones that are either of zero benefit to 2d or are simply too much work with too little benefit. Then with what is left, I'm going to either filter some more based on priority and the bang for buck factor as far as effort taken to implement compared to the gain, or I will submit what is left, possibly adding a priority to them as I get community feedback on such.
 

Joe Ellis

Member
I haven't got much to add on this subject besides what other people have already said. I'm not really big into new graphics stuff, although I have implemented pbr shading and have found it really useful for retro type graphics aswell as modern, cus of the versatility, so I'm kind of a hybrid of loving old 3d graphics while embracing new techniques. Also @Yal I'm flattered that you mention me along side @TheSnidr, I think we are both really good, but also we have more drive to go out of our way to do things where most people would rather use something that's already been done, like being able to try out different materials without having to code them or a system that handles it from scratch, which is completely understandable cus there are so many programs that have this kind of stuff now. I'm saying people like me and thesnidr are software engineers at heart so we will do stuff like this, whereas other people just want to make a game with the best software.
So the main thing I want to be improved is the glsl language interpreter, cus on windows it gets compiled in hlsl 11\directx11, and there's a lot of features and functions usable in hlsl that can't get interpreted from glsl. But the main problems are on the gml side, such as the texture sampling functions, there's no way to pass a texture into the vertex shader in gml, or a 3d texture etc. while it is possible to use the functions in the shader, they just won't have received anything, are in the wrong format or there's something disabling them. And like people have said, these things can be equally as useful for 2d games, depending on the game. But then it gets into the beginner friendly zone, while I would argue that the best thing to come out of the software is making high quality successful games. But if their target market is beginner programmers or even program users, then what can we do..
I know that if many successful games were made with gm then it'd increase their sales, so the 2 things work together, and I also realize that these features we want aren't economically viable cus of 3d being a niche in this engine. It kind of makes me want to make a multi million dollar best selling game that's 3d though, just to see how quick then they would be to implement all these features.
 

Fanatrick

Member
While I think it's great that you guys are creating this list and I'm all for pushing GameMaker forward, it's been said many many times that YYG will NOT be doing much in GM directly for 3D support. If any new feature gets added it will have to be useful for 2D - or incredibly easy to impliment - as
Last I remember seeing any word on this was more than half a decade ago, not to mention most of these features work just as well in 2D or are not exclusive to graphics at all.

...they aren't going to add anything that is for a tiny niche group and that takes many man-hours to add and test.
Utilizing more modern tech for GPU processing and using the GPU for more than just graphics might seem niche for the uninitiated. A more savvy practitioner knows this isn't in any way "niche" but rather mandatory even in the indie scene nowadays. The group is anything but tiny and many of these requests shouldn't be too demanding to fulfill.

Also, none of this is very beginner friendly, which also puts it lower down the priority list --
Neither are shaders in general, physics, networking and a bunch of other things, yet those were prioritized when it was adequate. The interest is apparent and there's little to no use parroting the same "beginner-friendly" excuse for almost a decade. How beginner-friendly were 2.3 GML standard updates?

-- since YYG (and now Opera) have stated a lot recently that they want to lower the bar for beginners and entry-level programmers.
This lacks relevance as well. Being beginner-friendly and modern is not mutually exclusive at all. What's preventing YoYo from both lowering the bar for beginners and extending functionality for veterans?
 

Yal

🐧 *penguin noises*
GMC Elder
So the main thing I want to be improved is the glsl language interpreter, cus on windows it gets compiled in hlsl 11\directx11, and there's a lot of features and functions usable in hlsl that can't get interpreted from glsl.
You can just make your shader HLSL directly if you want... the key thing here is that GL ES is the most compatible language (and works on all supported platforms) which is why it's the default, shaders written in GL ES becomes cross-platform automatically (not sure how automatic that process is). Between potential linux ports and Windows deprecating stuff constantly, it feels like going for HLSL instead of stubbornly use GL ES for everything would just invite future trouble... which makes it using such an ancient version feel like a mixed message type situation.


GPU buffer access (both GML and shader side) sounds like it'd make geometry and tesselation shaders completely redundant while also adding room for even more utilities like GPU-side data crunching for RTS / city builder style games (or research projects!), which probably is the whole reason they were invented, so that sounds like a good thing deserving of more emphasis. (kburkhart84, you might want to clarify that they're "GPU buffers" in the OP and also point out that they need to be accessible both GML-side and GPU-side)

Arbitrary surface color formats also sounds like a big convenience feature... when I tried implementing dynamic shadows for my big 3D project, I ended up having to write a special shader that would encode the distance to the fragment as a RGB value (since I couldn't just use the built-in depthmap format) and it overall was a whole bunch of unnecessary hoops to jump through...
1614454527514.png
(and there's plenty of 2D-friendly uses for other formats, like increasing performance 4x if you only need one 8-bit color channel for an effect control texture)

Note that these are not in any particular order, and many of them are much less useful or less priority than the others.
How about bolding the most important features and graying out the almost-useless/nice-to-have ones to make it easier to tell priorities at a glance? (also make it a bulleted list for max readability perhaps)
 

renex

Member
Arbitrary surface color formats also sounds like a big convenience feature... when I tried implementing dynamic shadows for my big 3D project, I ended up having to write a special shader that would encode the distance to the fragment as a RGB value (since I couldn't just use the built-in depthmap format) and it overall was a whole bunch of unnecessary hoops to jump through...
GOD yeah you can just google for "game maker depth encoding" and you get presented with dozens of methods, ech more complicated than the last and all of them having some form of banding artifacts... not even to mention just how bad the precision is! i remember writing a depth encoder for a 3d project and running into banding and zfighting everywhere. even that one very well-made SSAO demo that circulated a few years ago has these problems.

12202194_786236811507034_668825986_n.jpg

not to mention the more interesting uses like fluid simulations and computation...
 

kburkhart84

Firehammer Games
GPU buffer access (both GML and shader side) sounds like it'd make geometry and tesselation shaders completely redundant while also adding room for even more utilities like GPU-side data crunching for RTS / city builder style games (or research projects!), which probably is the whole reason they were invented, so that sounds like a good thing deserving of more emphasis. (kburkhart84, you might want to clarify that they're "GPU buffers" in the OP and also point out that they need to be accessible both GML-side and GPU-side)
Sounds good. I'll add those details.

Arbitrary surface color formats also sounds like a big convenience feature... when I tried implementing dynamic shadows for my big 3D project, I ended up having to write a special shader that would encode the distance to the fragment as a RGB value (since I couldn't just use the built-in depthmap format) and it overall was a whole bunch of unnecessary hoops to jump through...
I'll word it a little more specifically than just "surface formats" so it is more clear what is being asked for.

How about bolding the most important features and graying out the almost-useless/nice-to-have ones to make it easier to tell priorities at a glance? (also make it a bulleted list for max readability perhaps)
I'm just giving it a little more time to make sure I don't miss anything important, and I'll do better/proper formatting of the list. I was planning on ordering them as well based on a combination of priority, usefullness, and how easy to implement the things are.
 
  • Like
Reactions: Yal
Top