Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

Greetings. Great work on this engine. I've been messing around with the new rollback multiplayer functionality (GM beta) and noticed that the engine doesn't work with managed objects. The new multiplayer function won't allow global or local variables (basically anything beyond temporary variables) to be set or modified within the draw function of objects. This causes an error to be thrown. 

I switched the light_engine to be unmanaged and avoided the above error (from the multiplayer issue), but  a new error was thrown.


############################################################################################

ERROR in

action number 1

of Other Event: User Defined 11

for object light_engine:

vertex_submit: Illegal vertex buffer specified.

 at gml_Object_light_engine_Other_21 (line 72) -                                    vertex_submit(_v_buffer, pr_trianglelist, -1);

############################################################################################

gml_Object_light_engine_Other_21 (line 72)

gml_Object_light_engine_Draw_0 (line 3)



Perhaps this is an issue with the beta version of game maker, just curious if you've got this engine working in beta or if you plan on fixing some of these issues given the limitations of the new rollback system.

(+1)

The illegal vertex buffer error seems to get thrown when my multiplayer object starts an online game. The engine works prior to any multiplayer functionality.

The shadow objects use a lot of local variables as well and are very likely not submitting proper vertexes if rollback does not allow that. 

The entire shadow grid which sub-divides the static shadow casters also builds a grid of structs which use a large number of local variables. 

I do have the beta and have messed with rollback, but not with my light engine.  I will check it out sometime, but the entire engine would have to be modified to accommodate something like that if it is the case.

Hopefully it is possible to not manage the shadow casters as well to get it working.

(+1)

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.

(+1)

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.

(+1)

No problem! I think you may be right about room create during rollback. The manual says that the event order for rollback is room end, clean up for defined players, and then room start.

I look forward to the update! Thanks!

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?

(+1)

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. 

Update: the illegal vertex buffer error still exists for me in the latest update. 

(1 edit)

That is odd.  I may need to bother YYG about why buffer_exists() does not always work with vertex buffers.

Does your original work around still work?  I certainly will figure out a way to not have to use it.  Also, this is just when using rollback?

The original work around still works, so no issues on that front. I haven’t tried to implement the engine into non-multiplayer projects, but the example you provide in the download works fine for me. The problem, so far as I can tell, only occurs with multiplayer. 

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.