Post by Badwrong Games in Eclipse Light Engine comments

Viewing post in Eclipse Light Engine comments

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.

mastiphal872 years ago(+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.

Badwrong Games2 years ago(+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.

mastiphal872 years ago(+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!

mastiphal872 years ago

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?

Badwrong Games2 years ago(+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.

mastiphal872 years ago

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.

mastiphal872 years ago

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

Badwrong Games2 years ago (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?

mastiphal872 years ago

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.

Badwrong Games2 years ago

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.

itch.io

Viewing post in Eclipse Light Engine comments