So, I switched everything to unmanaged and I still got the illegal buffer error, so I digged a little deeper and tried to understand what was going on with vertex submit. It was fine if it returned a 0 for the local variable vertex_buffer, but it was throwing -4 when multiplayer started. What is weird is it only returns -4 for a single step. So what I did was create a local timer variable, set to 0, and add 1 in the step event. Then in the light_engine user event 11 - lighting SS (this is the event that was throwing the illegal buffer error), I had it only run if the timer variable was above 1. It actually worked and now there is no error.
Ah, that would mean something isn't initialized fast enough. I suspect "room start" is not the same when using rollback.
The shadow buffer variable is just a pointer that is first set to "noone" which is -4. In the end step event it should check with the shadow grid for which static buffer to use and then append any dynamic shadows to that as a vertex buffer. So, if that does not happen it would remain as -4.
In the next update I will add dummy buffer that renders a single triangle with no area. That is faster than adding checks for validity since the vast majority of the time it the buffer will always have something there.
Chances are the shadow grid is actually created and ready, but depending on the position of the view it could grab nothing from the grid depending on how your game is setup. So, this will add a failsafe for that. I'll add the dummy buffer in the next update and you won't need to do anything like you did. Thanks for bringing that to my attention.
Update: I've encountered a new problem. While running the game from Windows there is no problem and the lighting engine works. However, running the game from OperaGX completely disables the entire lightning system. I'm not sure if OperaGX does not support some of the graphical rendering by the engine or what is going on. Have you been able to get it to work on OperaGX?
Thanks for the update.
I also have not found it working on OperaGX, and really most things with shaders and surfaces seem to have issues there.
I know WebGL is totally capable of the type of deferred renderer which Eclipse does, but the older API implementation that GameMaker currently uses is indeed lacking some key things.
I have and will be looking into it more because I do want it supporting everything. Most likely the big changes to GM that are coming soon will be the best solution since at that point it sounds like the graphics API will be much more up to date and fully support MRT.
Also, in the last update I did add a special place holder buffer so that the illegal vertex submit error will not happen. It also turned out, after rigorous testing, that GM has some internal issues with destroying vertex buffers and how they are indexed which cause memory leaks. That was also a factor in the error you originally had, but has been fixed now as far as Eclipse goes.
Thanks for the update, I’ll try it out now! It will be nice to remove my workaround.
Hopefully when LTS gets released GM will be more stable and OperaGX will support better shaders. I don’t desperately need it, since I’ll probably wait until they release multiplayer on other platforms this winter.
P.S. You did a fantastic job on this engine. My placeholder sprites look surprisingly good with this thing haha.
Gotcha. Must be some way that the vertex buffer just doesn't get created before the first draw call. When I have a moment I'll add some failsafe so others do not have the issue. Checking if it exists or avoiding drawing for a few steps works for now, but long term something more elegant needs to be in place.
Thanks again for brining it to my attention, since multiplayer is not tested as much.