People a while back were complaining on the GMC about Yoyo's refusal to add a headless mode so people could take advantage of the collision system etc in order to create lightweight servers, so I added one!
I've done my best to make graphics dependent stuff work headlessly (so we have the *_get() functions working) but some stuff (like shaders) can't be implemented without depending on a graphics API so I've made fillin functions for them (see fillin.cpp).
I noticed that d3d_model_save() is unimplemented in all graphics systems so I've left that alone, but it is quite severely needed if any of the 3D stuff is to be useful in headless mode.
Aside from that, most of the code is just bits and bobs from other graphics systems with any API calls removed and slight modification.
Sidenote: PFwindow was using string but didn't include it so I fixed that because it wouldn't compile without it.
Ay-ay-ay... I didn't realize how sore a shape code sharing between platforms was. It looks as though most of the code in the "None" graphics system is either no-op methods (which we do need) or is duplicated from other files, yes? Can those duplicated files be replaced with, eg,
I think it would be better to move that code (in particular, files like GLtiles.cpp) into General... do any of our systems use a different implementation for those methods? It seems silly to have each system duplicate that framework. Is the operative difference something nonsensical, like
glInt actual_resource; vs
D3D_RENDER_CONTEXT actual_resource;? Because if so, I'll deal with that, now.
It looks as though most of the code in the "None" graphics system is either no-op methods (which we do need) or is duplicated from other files, yes?
What has been duplicated from other files has been modified in order to remove actual calls to a graphics API and instead emulates what would happen on the screen (so like draw_set_color() would work enough that draw_get_color() would give the correct output), while all the no-ops are in fillin.cpp
There most certainly is alot of overlap between the graphics APIs though, like merge_color(), draw_get_color(), all the color_get_*() and make_color_*() functions.
Is the operative difference something nonsensical, like glInt actual_resource; vs D3D_RENDER_CONTEXT actual_resource;?
Feel free to move the color functions into general, I can't remember why I never did that. I think when I first tried I had an issue or wasn't sure about the style conventions used in ENIGMA.
This is ready for merge btw
This looks fine to me, the color changes were definitely needed. Ideally I wish there was a simpler way we could create this headless graphics mode without it being so verbose though.
@JoshDreamland do we have some sort of Macro that lets you check what graphics system is set from EDL? For new ENIGMA-only projects, that is the best method to do this because then the final project you create will be a lot smaller as a result of it just removing the code that doesn't apply to the headless mode.
This system will only be useful to existing GameMaker projects that haven't been adapted to use such macro. I think what would be a cool idea, but would require compiler support, is the ability to turn any of the systems into headless mode. For example, a more robust compiler could detect all of the functions you are calling in system x and remove them or auto-generate the empty function body. We would just add a checkbox next to each system that said "Headless" to enable this.
Again, that would require that JDI/the compiler know from which system functions are coming from.
@RobertBColton I don't think we should be autogenerating functions like that in the compiler, because it ends up with us having to modify the compiler to deal with a platform and that seems very messy to me, besides, we're still implementing at least some of the functions in some way, we can't just write empty functions for the entire thing.
Maybe I didn't convey that clearly. We wouldn't actually have to modify the compiler for it. For example, when you use LGM by itself, it can do syntax highlighting because we have all the GML functions listed in a text file with their parameters. When the ENIGMA plugin is being used, then JDI "augments" that by searching all of ENIGMASystem to find all of the functions and tell LGM about them for syntax highlighting. So we already have that infrastructure present in ENIGMA.
I am saying that we can use that same compiler technology on your project to pretty print all of the empty bodies, but only for the functions from the system you are using. So if you aren't, for example, using surface functions, then it would just skip them. It would also only do this for functions which are actually defined in said system, because you are then calling a function that system doesn't even declare. It would also be possible to cache this for performance reasons.
The goal there is try to be less "messy" and maybe a little more consistent. Because the problem always exists that someone may forget to create an empty body for some function, largely because there's several hundred functions and a compiler is better at automating that. Other reasons also include that I can think of some debugging use cases where doing this for other systems, like collisions or windowing, may be useful. It would be a lot of work to repeat this same PR for all such systems.
Either way, your PR is a fine solution, for now.