Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Badwrong Games

A member registered May 28, 2019 · View creator page →

Creator of

Recent community posts

(2 edits)

A priority queue is very costly and not the method I would use personally.  Like I said you can use "depth = something" as long as you have the light engine on a layer lower than the lowest of your instances.  I highly suggest just normalizing the instance depth using room_height.

Lights are all batched and there is no such thing as manually rendering them.  Eclipse uses a deferred renderer so everything is done in as few draw calls as possible. 

You may want to just copy the depth sorting that Eclipse uses, as it passes depth to the shaders for normal and materials maps using the vertex color which gives a range of -16000 to 16000.  That automatically depth sorts things just by a shader while objects remain on the same layer.

Shadow and light depth is normalized from 0 to 1.  This is so that different layer or depth setups will be easy to work.  To match the players depth you can just set the light based on whatever normalized range you use... again room_height is the answer and can easily be translated into the range 0 - 1. 

There are many ways it could be done, but one option would be similar to:

depth = room_height - y;

light/shadow depth =  y / room_height;        // creates a range from 0 to 1

In your case the isometric y value would be used and you may need to account for room_height being a bit bigger in isometric space.

Regardless the light_engine needs to be at a depth or layer lower than everything else.  So, if it is normalized based on 0 - room_height, then the light_engine should be at -1 (or I suppose 0 would work too).

Using depth = -y for depth sorting is the problem.  You lose a lot your layer functions with all those unmanaged layers and that's why YYG advises not to use such a method.

If you must use that method, then don't just set it to negative y.  Set it to a value that will actually fit between the background and the light engine.  That could be as simple as room_height - y and then set the light engine on a layer with depth of -1.  

You could also try setting the depth of the layer the light engine is on to be "-room_height - 1". 

None of these are ideal however because a real depth sorting method should be used.  Eclipse also factors in depth for lighting and your light placement might be difficult if you have everything at random layer depths.

There is a thread on the GameMaker forums where everyone has been asking and discussing Eclipse:

You can also just ask here if you want or email me

If you are importing it into an existing project with many things already going on you may need to setup a bit of inheritance or the light wont have anything to hit.  Everything drawn should inherit from a type of the __game object so that their normal map and material maps are drawn.  Or if its a shadow caster use one of the various __shadow type objects to inherit from--depending on shape.  

If you use tilemap or asset layers they should be setup too as shown  in the first basic setup video and mentioned in the User Guide:

Thanks for the update.

I have actually been doing a lot with rollback for other reasons, and I'll say right away that it still has many problems to work out.  I cannot even connect with versions past August.

So, I'm not going to stress too much about it as long as it is in beta.  Any good fix added now could break later.  I couldn't even use structs in one version a week or so ago, so...ya.

Once it comes out of beta it will be worth the time to add better support for.  I'll probably even add my objects that handle rollback clients, events, and what not to the example project area.

Hey, thanks a ton for the support and glad you like it.

The side edges of cast shadows won't have much softening in the current setup.  You can get a bit more by lowering the shadow map resolution on the light engine object's variables tab.  That will obscure things a bit and the bloom blur passes would then soften them up some, and increasing the bloom amount would add to it as well.  They won't be the same as how they taper towards the far end of the shadow due to the current GameMaker shader implementation.  Eclipse has a lot of custom solutions due to the 10+ year old graphics API that GameMaker uses.  There is hope in the larger runtime update this year that I will be able to use newer techniques for Eclipse in that area.

For animated sprites I use this program:

It was totally worth the price.  You do not want to do it frame-by-frame of course, and sprite strips are better to do an entire animation at once.  You can also do multiple images at once so that they all get the same settings.  Just drag them all into the images panel and highlight them all (shift click or something).  Then when you use the normal map tools like bevel and emboss it will apply to them all.

You can use light depth to place lights behind other things.  I show it in this video

The ambient color needs to also have the ambient light value turned up to do  much.  In the next update I will be improving how the ambient light works along with adding directional lighting and there will be a larger difference in those settings.

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.

(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?

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. 

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.

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.

Demo version is now available.  Enjoy!

Howdy. Thanks for stopping by to see what this nonsense is all about.

Run Jump Rabbit Turtle, is my first game and I decided to do an early launch on itchio before its Steam launch.

The way itchio and its community accommodates indie's made me want to put it there first and unannounced.

You can check it out here:

Be ready for stupid puns and jokes:

680k downvotes = funny

So far the game has been well received by reviewers and players:

"The game’s simple bean and kiwi system make each level playable in different ways for different objectives, thus giving the gamer more content to play though and objectives to complete. But most importantly, as a platformer I know it’s well designed because it pissed me off. The little laugh from the game every time you die, the learning curve that came with each new level – it’s all phenomenally well done for the genre."


More about the game: 

The Monkey Wizard has combined Rabbit and Turtle into one of those new designer hybrid animals to work for him. You know, like a puggle-- but with more shell and buckteeth. In order to traverse the dangerous cave areas and collect the magical kiwis for the Monkey Wizard, you can seamlessly morph between the fast nimble rabbit or the slow defensive turtle.

  • Race to collect magical kiwis before they are rotten.
  • Converse with and maybe(?) help other animals working for the Monkey Wizard.
  • Find secrets and bonus content, no microtransactions required!
  • A satire filled journey through dangerous caves where the 4th wall isn't just broken its annihilated. 
  • Finish the game with 3.5 different endings... 
  • "Speed Run" mode available.
  • Optional "Easy Mode" that can be toggled at any time... and for those who don't approve of that, an unlockable "Git Gud" mode.
  • At least one character that is wearing pants!