Hi! Cool system, thanks! But I have a problem in the isomteric game, for some reason objects become translucent if they overlap each other. Example in the picture. Maybe someone has encountered this?! Single object is displayed perfectly.
How are you drawing the isometric blocks? It looks like they are all on the same depth and so when the normal and material maps are drawn they "blend" together.
Eclipse doesn't fit well with isometric projection, and you'll never get the shadows 100% correct (if that matters) from that perspective.
However, if you have those all at different depths then it should separate them when the normal and materials are composed.
I’ve really been enjoying messing around with the engine and I’m currently trying to implement it into my top down (birds eye view) game. I have a few questions:
I placed the engine object into a layer above my other objects I want it to affect. I have a light switch object that, when interacted with, creates a light object that is inheriting it’s properties from one of the existing light objects included with the engine. The light switch has a creation variable that allows it to be set to on or off. It’s currently set to on so when I start the game, a light object is created instantly. For some reason, when I flip this switch, just the first one I can reach, to turn off the light, all the shadows and lighting are removed from the game. If I add in another light before hand that stays on, then the lights act normally. This engine doesn’t require a light to be present to function does it?
I’m also having this weird stuttery effect where all of my game objects jitter as I move around the game world. I have a camera that follows the player. Also objects interacting with shadows have this faint little jittery white outline on them. If I remove the engine object, the stutter goes away. Any idea what I could be missing that causes this?
And lastly, I’m trying to create a very atmospheric faint bit of light around that player, but I’m having trouble understanding how to achieve this affect. In your videos, it appears that the variable falloff is able to be changed to negative 1, but right now the lowest it can go is 0. When I set it low there is very obvious banding that is super distracting. I’m not sure how to achieve a smoother effect. Any ideas on how to achieve that?
Thanks you so much for all your hard work. I really appreciate it. And thank you for any help.
Another thing I was wondering. Here i have two light objects (not counting the one casted by the player), and they don't seem to be acting like how to lights coming from the ceiling would act. The lights form together at their intersection and create a brighter light, which is fine, but in this case I would not want this to happen. Is this a limitation of the engine or do I just need to mess around with the variables? just seems weird that they would do this when the light intensity is so low.
As I pointed out above, you can also see a white outline around the doors.
And lastly, is there a way to cover up objects that are behind shadows? The room to the right is almost completely covered in darkness but I can still see the walls that outline it.
When two lights combine it should be brighter. There will be an update at some point that makes it easier to control that however.
The walls are receiving light because the wall does not completely block it. You need to have the light at a lower light depth than the shadow depth of the wall otherwise it will pass over it and light the walls in the other room.
Falloff now just goes from 0 to 1, so adjust that how you need.
The jittery thing might be because you use too low of a resolution in your game. I do not know how you setup your camera view and application surface/window, etc. Look at the example project included and see it is not jittery like that.
You may also need to change the shadow map size to better match your resolution.
For your light objects, I cannot see your code. This sounds like you are doing something incorrect with your light switch object. Do you have a solid understanding of the difference between an object and an instance?
In the example project you will see an object Example > Scene > shadow_precise_dynamic
That is an example of how to create what you want. It should get a precise shadow mask based on your sprite_index, and unless you did not use event_inherited in the right places, it should not require you updating anything.
Don't forget, if you are changing sprite_index then you also need to change the material_map and normal_map as well.
This engine is very impressive, but I cannot seem to find a crucial feature for me, which is the ability to mark indoor areas. These areas should not be affected by the day and night cycle, and wall shadows from daylight should not end while inside.
Is this something that can be done, or alternatively, possible for you to add?
This could be a feature added at some point, or if you are in a hurry I could advise on how to add it. You would create a mask that is drawn to the shadow atlas for the maps of each directional light.
Ideally I think a new object would need to be created which defines an "indoor" area. Then that could be drawn to the atlas after normal shadows are rendered.
Question about the new runtime in development for game maker (GMRT). They have stated they the rendering backend is based on the javascript WebGPU api. Will eclipse make use of this new rendering pipeline? And if so, what can we expect?
I would like to change things once it is released. Mostly there are certain workarounds that can be removed once the more "modern" graphics API is available.
New features would come after that, not sure what at the moment. Certainly some optimizations can be done with the new API.
I just purchased the engine and I'm trying to figure things out, but I admit Im an extreme beginner with this stuff. I was wondering if there were any of the demo projects available for download as a GM project? It'd be really helpful to be able to see just you set up the light objects in the map (how many are needed, what settings you used to achieve a certain look, etc.)
Yes, I was meaning the actual .yyp project file because it'd be really helpful to see how you set up the lighting in the rooms- I played around for a few hours but couldn't get them quite like you had them (I also think I may be putting in too many light objects? Not sure).
I do understand the private asset issue though, that's too bad :(
Do you have any plans to add .yyp files (without any paid assets) in the future?
Not currently. Is there something that isn't working when you setup the scene? You mention too many light objects, but what is the result that seems incorrect for you?
Also, are you using normal maps and materials for your assets?
No, everything I’ve tried so far has worked really well! I’m just a bit lost on how to set the room up. When I open the demos, everything seems to be very well lit and the light is well distributed- I’m having a bit of trouble getting that same result. Everything’s very dark (even when I brought the ambience intensity all the way to 1 and played around with other variables in the controller obj) and I’m trying to figure out how you set up your scenes to have everything spread out so nicely without having like 30 light objects :(
And yes! Using normals and materials. Should also mention this is a pixel art project (which I’m aware isn’t the targeted use for the asset, but you got some great results in your demos!)
What sort of settings are you using on the lights?
Ambient intensity set to 1 would light the scene entirely and you would barely be able to see the actual lights since everything would be fully "lit" already. Is that the case when you have the ambient intensity at 1?
In the example project you can place lights and configure them with a GUI by hitting tab if you have a light selected with the mouse. This can help to understand what the settings on the lights do. You can also mess with some of the light engine settings as well by hitting spacebar.
This is beyond what I needed, and is SO MUCH VALUE for only $9.
A few of the tutorial vids are slightly out of date - but WHAT? There are tutorials included too!? Just... wow. Don't even worry about it.
I took 2 weeks to try to learn GLSL and make a clunky shader that sunk my performance to the watery depths. I took another week redesigning and doing math and being annoyed and got something that wasn't entirely unusable. And then I find this. I spend $9 and: It. Just. Works. And then I find that off the cuff you also tossed in a camera object that's nearly 1:1 with the one I spent hours making. And a material packer tool. And then you have more tutorials on youtube!? /sigh
I wanted to make sure you got some thanks for doing this - I only scratched the surface attempting to tackle lighting myself - so it is with a tiny speck of understanding that I can appreciate what you've done.
Is there a reason why draw_sprite_pos() in the draw event does not draw onto the surface using the lighting engine? It appears to work on the normal and material draw events, but not the normal draw event. Just curious why the draw event would fail to use this native draw function, but not the material/normal draw events.
Originally, I believed it was the draw event, because it seemed like the lighting was applying normals. But I just commented out the draw event, while keeping the draw_sprite_pos in normal and material events, and nothing is being drawn. So for some reason draw_sprite_pos() doesn't appear to work in the normal and material draw events. If you want to try yourself, I just copied the "shadow_military_crate" obj and replaced the normal draw code with draw_sprite_pos in all of the draw events.
The manual says draw_sprite_pos has some limitations. Auto-crop and 9-slice should be disabled. I have done this.
It also says:
"WARNING! The image above is only for illustrative purposes, and if you use this function on a sprite, you will get different results and may experience texture "shearing" due to the way that a sprite is constructed from a quad of primitives."
I know there are a bunch of vertex buffers, so perhaps the failure to draw_sprite_pos function has something to do with this?
{edit: I saw that an alternative to draw_sprite_pos is to draw primitives/vertex buffers, so I tried doing that too, and nothing is being drawn also]
Ah... looking at the function, I can tell it will not work. It doesn't have an image_blend parameter. Eclipse needs that to pack the other material or normal information.
It probably uses the default image_blend of the instance, so if you set image_blend to the right material or normal values like in the other user events before calling draw_sprite_pos it should work. Just make sure to set image_blend back when doing the normal drawing.
Also the alpha value needs to be the same as in the other normal and material drawing events.
I added in the image_blend = material / image_blend = normal into the corresponding user events before draw_sprite_pos and it still does not work. I also tried draw_set_color before as well, but no success. Draw_sprite_pos() only works in the draw event.
I saw there was a comment about the isometric perspective, but still curious about the potential limits of this lighting system. Is there an easy way to make the shadows cast at an angle, instead of purely top down?
Hello- I've been enjoying using the lighting system very much, but have run into a critical issue. When I build the game for both mobile android and IOS, there appears to be no lighting at all and the screen is mostly just a layer of black.
I used VM when building for both android and IOS (my build is giving me weird errors when trying to run YYC).
I'm happy to provide specs but my phone should be more than capable of supporting the engine. I bought this engine with the intention of making mobile games so I appreciate your support!
To test, go into User Event 0 of the light_engine object and on line 5 where it says "if (false) // Force GLSL ES for testing" change it to true and see if that changes anything. My assumption is the wrong shaders are trying to be used when it runs on iOS.
Apologies on the delayed response- I’ve been having a number of unrelated build errors for IOS that have kept me from testing your fix. I’ll be sure to update this post when I’m able to!
Hello- changing this to false doesn't appear to change anything in game. Can confirm this is the same for use on android devices as well. So I've been unable to get the lighting engine working on any mobile devices.
Is there a way to make colored lights with <1 falloff that do not have white colored radius borders around them? If I have a red light, there seems to always be a gradual fade into white colored lighting. I may not have set up the engine in my game correctly, but after tweaking all the different settings it seems as if the color begins in the center strong, but then gradually turns white the further out you look.
Do you have any screenshot examples to show exactly what you mean?
The light attenuation model is uses an easing function to soften the area where the falloff occurs. You could edit it in the shaders to use another easing function.
For example, in the fragment shader of shd_light_ss_hlsl on line 189 the easing is done by:
Thanks for this. I tried it but the lights became extremely dulled down. I had to pump up their intensity, and even then it did not look very bright.
If you want an idea of what I'm suggesting, look at the le_light_fire object in the example project. There is a red glow on the ground at the center of the light object, but as it moves outwardly, the glow turns white.
I'm also wondering if this is an issue with the underlying material map that is being used. When I use the same light on another more metal material map the white ring disappears.
You will not find another one as awesome and useful to beautify your project. Well documented, and good examples! Works really well and has a TON of features.
Performance is great and the creator responds to all queries quickly giving good advice!! Worth more than the price if youre serious about your game!
Question about optimization. I've tried using emissive particles, and it seems to be pretty inefficient, even in the example provided. If I have 7 le_light_fire at 1080p, my FPS dips below 51 fps. For context, I can run modern games (e.g., Baldur's Gate 3) on highest settings no problem on this same rig.
When I ran the debug it says 15% of the step was consumed by light_pre_composite, and it looks like surface reset target during light engine other 13 was consuming the highest (3%) of that. Is there a way to do particles/lighting that don't consume so much resources? Everything else runs perfectly.
The particles rely on GM's built-in particle system, so it could be limited by how efficient they have made things internally. Unfortunately, GM still has a very old graphic API implementation, and yes, you will find performance for lesser things will cost more than newer games like you mentioned.
To troubleshoot, please answer:
What is the actual time in milliseconds that you can see?
Have you ran the same test compiled with YYC? (you'd need to output your own timing or FPS values)
What is your GPU utilization actually at when the FPS is that low? (Task Manager > Performance > GPU)
surface_reset_target() is a pipeline change, but saying that is the most costly thing is actually good, because it is not costly.
15% of the step is fine (but we really need to know milliseconds), and it is normal for rendering to cost the most performance. The question is where is the other 85% going? GM did recently change some things about particles, and there could be a lot of data going between CPU and GPU which would be slow if done poorly.
For example, I added 20 of those particle fire lights and ran the profiler:
The important ones to look at here are:
Name
Time (Ms)
surface_reset_target
0.01
part_system_drawit
0.042
These are great metrics, and this is with VM of course. So, it would be faster with YYC.
My computer is not a good benchmark though, because I build a new one a few months ago with a 4090 RTX and other high-end parts. I have tested Eclipse on mobile, Surface Pro (2014), and my old Linux machine/server. Never seen a problem with particles, so I'm curious what it looks like for you?
I did realize that windows has been using my integrated card (not an awful card though can run way better looking games at 60fps), instead of the better card that is used by Baldur's Gate 3. I added my high performance card to the "Game Maker" app, but when I checked in task manager, it still shows the integrated graphics as being used (my guess is I have to add the project app to high performance, but couldn't figure out how to do that).
I tried running a debug again, and this time it is actually much worse (and what I was getting in my actual project). Essentially, if I use the game maker particle system, I experience 0 performance issues. But if I use the eclipse particle system (e.g., le_effect with particle systems and emissives), performance dips very badly. It is nothing to do with my project however, since I recreated it in the example file you've uploaded. I Added 7-8 le_light_fire objects into the room, upscaled to 1080p, and then profiled with these results.
I created an executable for the example project, and set the performance to discrete graphics card, and now I've got 60 fps at 1080p with all the particle effects. Do you think the high step % and ms I posted compared to yours is entirely due to the graphics card and the surface reset target function? I would figure out myself if I could figure out how to make windows run my debugging games from game maker using the better graphics card.
Ah, that makes some sense then. Integrated graphics are going to be extremely inconsistent depending on what rendering is being done. It is weird that it all sits at surface reset, but how they handle VRAM when its integrated would affect that.
I use a lot of multiple render target (MRT) outputs in the shaders, and I bet integrated graphics do not handle that well at all. So, yes you'll want to figure out why it decides to use your integrated graphics at all. If you do not use it at all, then I would suggest disabling it in your BIOS settings entirely. Then GM will have to choice when selecting a device.
Hi, mastiph I am getting the performance issues using shadows, or emissive as well. Like if I inherit from le_game to use textures and create an entity that's a child of le_game, I get a serious performance drop. When I mouse over the blue marker where the drop happens (when I created two instances of such an object, see below for what it does, create a sufrace, and free a surface...no idea what is happening there, perhaps badwrong can shed more light.
I have no issues having hundreds of lights on screen at once however. Yes it taxes more, but not like how only two instances of the object which inherit from le_game do as per the screenshots below!
I am on a 5600x with no integrated graphics, only 3080 graphcis card.
Dropped to 1010 on creation of two instances in the last one. Which is why I was worried I might not be able to have more than 10. But no worries all is well! Its great!!
Hi, your lighting system looks amazing... I just purchased and was just wondering (before I attempt it) if It can do something like this: ( I like how the trees and bushes are lit, but cast shadows... )
So I tried the system following the basic setup video. But my "normal_begin" tiles are offset by something upon x and y axis. (and perhaps scale, as i tried tile offsets without success )
here's some images: (without the normals layer)
(with normals layer being offset for unknown reason)
Is there a way to have background layers affected by the day/night lighting prefab object, but not any other lighting objects (e.g. __light)? I would like the backgrounds to change with daytime without being affected by other lighting objects to imply depth/distance.
There is no way in Eclipse too have a light only change a specific layer, object, material, etc. Something like that would require a totally separate render pass.
My suggestion would be to use layer scripts on your background and set a simple shader that takes the day/night values such as intensity as uniforms to change the background.
Currently, if you setup the layers correctly you can have backgrounds that are totally unaffected by Eclipse (covered in basic setup tutorial). So, all you would need to do is setup your background like that and add layers scripts.
Cool. You may not really need a shader, and just setting the global draw color would work. Basically the RGB values of the draw color would be the same as intensity of the sun light. If it looks good then no need to do much more, or if you need more control then a shader might be needed.
Layer scripts are the easiest, and you can get the intensity value from the day/night object (make sure it exists or use "with").
Thanks for this. I've managed to change the alpha of the layers depending on the day light. It works perfectly!
I have another question. Suppose I have lots of frames for character animations. I've been using both material maps and normal maps in addition to the original sprites. I haven't really needed to develop material maps for some sprites (say if there isn't a difference in metal/roughness across the entire sprite). I've also noticed that you can manually change the roughness/metalic of an object. Is there a way to simply redraw the original sprite according to these object values, instead of having to use material maps? In the draw material event, could I clear the pixels in the sprite_index (of the original sprite) to a specific material map color instead of using all these extra sprites?
If I understand what you are asking, you can do full image metal/roughness just by setting those values and not use a material map sprite. When the material map sprite is assigned to the same sprite_index (i.e., left as default) then the shaders will draw metal/roughness using the current sprite_index and all pixels at the metal/roughness set.
Great lighting system. Really impressive. Just getting the hang of it.
Any ideas what might be causing the follow problem?
Room set up with a few tilesheet layers. I cover the walls with an inherited static shadow rect.
All looks good, but a few of the objects on one of the tilesheets, when they're covered by the shadow rect have some pixels illuminated (I think particular shade/alpha) even when they are very far from the light everything else is pitch black (Doesn't happen if I include zero light objects in scene, but adding a single light anywhere causes it.)
Much worse if shadowcaster object is on them (or part of that sprite). But can see if put large version of same sprite on there even with no shadowcasters in room.
Doesn't make a difference if use titleset or just add manually as a single asset on asset layer.
Is there a way to make the shadow objects complete invisible and not interact with the world beyond casting shadows?
I'm on MacOS. Using VM compiler.
Update: did a bit more playing around. Much worse if bloom = 0. Better (but not completely) if bloom = 5.
Update 2: if I add two light engine objects to the room it fixes the problem... but assume (as everything is darker) that this is a bad idea, as effectively running the light engine twice. Odd that it fixes.
I noticed in the your demo room when compiling on Mac with VM that similar outline problem on some of the objects in dark. Similarly improved by upping the bloom, but not completly.
Hard to see on picture. This is the outline of circle with grill near the helmet.
Will see if I can get YYC working on my machine but has been tricky. Otherwise, will see if can get hold of a Windows computer to test.
Not sure if you have other Mac users? Or if can indicate if supported?
PS: Mac point, but in your demo, the le_navigate Create event needs to add a check for os_type == os_macosx. Otherwise defaults to gamepad and can't move/interact.
YYC will not change anything with the graphics API.
It may be an issue with the tilemap culling. YYG recently fixed something internally and now tilemaps are culled correctly according to the camera. When the normal maps and materials made with tiles are drawn there is no camera applied.
Do you have normal maps and materials set for your tiles?
Have only just purchased but it's quickly apparent that it lives up to the level of sophistication that is promised in descriptions. Easily worth the cost.
Thank you Badwrong Games for creating this high-quality system that helps supports the GameMaker community and creators like me!
Heya, I recently bought this asset on the official GameMaker website. I've been working with it and am adjusting things to the needs of my project.
There is one thing I want to change, but I'm not sure how to, except if I change a lot of things that may break something else: I want there to be a light source around the player, but I do NOT want it to create any shadows.
I know I can disable shadows from objects, but I want it to stay enabled for other lights. I want the shadows only disabled if there is light from the player. Making shadows have less of an effect to the light of one source but a larger effect to another light source would also be something I'd like.
How would I be able to do this? Thank you in advance for your help.
I was hoping to use this asset (https://marketplace.yoyogames.com/assets/4720/draw-sprite-pos-fixed) to fix the default draw_sprite_pos(). What is cool is that this asset allows color and alpha which is not currently supported by draw_sprite_pos(), and it fixed the weird texture effects.
So I added it in into my project, added the scripts/shader, and used the draw scripts in the normal/material events. In the material event, I ran the added script (draw_sprite_pos_fixed) including the material variable (as color), and shadow_depth variable (as alpha). In the normal event, I ran the added script (draw_sprite_pos_fixed) including the normal variable (as color), and LE_NORMAL_ANGLE variable (as alpha). Essentially, I tried to replace the ordinary draw events from the example project with this draw_sprite_pos_fixed script.
Unfortunately, the draw_sprite_pos_fixed script appears to be adding a black box around the entire sprite (and any other objects with similar draw events). This issue does not occur if either (1) I only run the script in the draw event or (2) I remove the following 2 lines from the script:
My guess is setting new shaders while the normal/material shaders are doing their work by the light engine is causing the issue. Any idea on how I might go about getting this script to be compatible? The original GM function is just not enough to make use of this powerful lighting system.
If that asset uses a shader then it would have to be completely combined with many of the eclipse shaders. They use an extra transform that their special shader uses.
The only simple method would be to draw it first to a surface then draw it normally from that surface with the eclipse stuff. That also means getting the current shader, current MRT surfaces, etc. Then after drawing it, restore those.
I've been tinkering with the system all day. I've fixed the black box and I figured I would make this post to just let anyone know if they want to use this add_on or draw_sprite_pos. So, what I've done is create a new prefab le_game_pos, which is just like le_game, except that it draws differently in the order. All it has for drawing is a draw function which uses draw_sprite_pos_fixed() (the asset I linked above).
Then, in light_engine, on the pre-composite (MRT) event (and pre-composite event), and AFTER it draws normal surface/material surface for other objects (e.g., le_game), I have it draw the normals and material for le_game_pos to each surface (surface_normal / surface_material) WITHOUT the shaders. For example, the normal code looks like:
if (!surface_exists(surface_normal)) surface_normal = surface_create(_s_width, _s_height);
surface_set_target(surface_normal);
with (__le_game_pos){ //draw script here}
surface_reset_target()
...do same for material map.
Now, since I'm not putting shaders in, the sprites may not getting the full shaders, but the lighting still applies to some extent and it does not look bad.
Note that I use the depth buffer to sort the depth of everything when drawing the normal and material maps. If not using the depth buffer things will simply draw in order, which may be ok depending on your own game.
One reason this type of drawing isn't supported directly by Eclipse is because it would be far simpler to just do it in full 3D. For normal map to display correctly after applying a transform such as draw_sprite_pos_fixed() you need to use tangent space to create a TBN matrix. The efficient way to use that matrix is to transform the actual light positions by the transpose. Since Eclipse is more or less a 2D lighting solution (using some 3D maths) that entire process is skipped because the normal maps all sit on a plane facing upward toward the viewpoint. Its cheaper and works well with how default GM drawing works.
So, doing full 3D transformed sprites would really be easier in a normal 3D lighting solution.
Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself.
That makes a lot of sense. I was just trying to add some cool top down parallax effects to add more of a 3d feel in addition to the 3d lighting. It's very impressive what this light system can do for 2d graphics. I did not want to touch 3D in GML, so I'll pass on figuring any of that out, ha!
"Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself."
I was just using the alpha setup from the other object normal draw events, which uses LE_NORMAL_ANGLE for the draw events in the events I listed. I could always have it send the emissive variable instead.
Gotcha. So, that macro packs alpha and the rotation value into one float. Then in the shader it rotates the normal vector around the z axis according to the image angle of the instance.
I've been messing around both with depth sorting and with the particle system (and presets). I have the depth sorting exactly how I want it with the engine and objects (depth= -room_height-bbox_bottom). however, I'm unsure how to modify the depth of the particles. I see that you have set_depth in the le_particles object, but when I attempt to use this function, it does not change the depth. The particles always appear below everything else no matter what I put in there. Any ideas of a work around?
Try setting the "shadow_depth" variable on the particle system object. It is normalized 0 - 1 as well.
It uses both the instance "depth" variable and that. One is for just the basic draw order (depth sorted) and the other is how it is lit. If that doesn't work let me know.
By "particle system object" do you mean _le_particles? I've been using the presets provided in the example project. The shadow_depth was already set to 1 which I presume would make it appear above other things.
I'm using the preset _le_light_fire (that is using a function to create the particles)., which has _light_cull as parent. There is no shadow_depth for this object, but I want to have the depth of this object determine the depth of the particles. Is that possible?
That fire effect is a light and uses the particle system combined. So, you would set the light depth of the object, and the depth of the particle system.
I watched your tutorial on normalized depth sorting, and decided to change my depth according to it. So now all my objects have positive depth with depth = room_height - bbox_bottom + 100 (except for lighting engine which is -100).
If I set depth of le_light_fire to -1 and part_system_depth(particle_system,-1), it does not draw the particles over the ordinary objects with positive depth.
I also tried a depth that is BELOW the lighting system itself (-100) just as a test. If I set the depth of le_light_fire to -200 and part_system_depth(particle_system,-200), it does not draw the particles over the ordinary objects with positive depth.
It's supposed to remove as much work as possible from the user. Watch some of the tutorials to see what you think. You still have to create the assets for it to work though.
Great engine mostly. I was quite pleasantly surprised on how you had set up the first import/setup into the engine. Very quick and easy and doesn't break anything I've already got running in the game. And the first visuals I got out of it when I loaded into my redux version of Voidship were very very promising.
I am getting some potentially weird behaviour though and have a couple questions which after digging a bit and watching half of the tutorials I'm still quite confused about:
1. How much should light intensity be doing? I see it's a value from 0 to 1 and that means I'd expect 1 to be full intensity and 0 to be off (or damn near close to it), but in my setup it's more like 1 is full intensity and 0 is just a tiny bit less than that. Very small change between them. It's making it very difficult to dim lights, I'm spoofing it a bit by combining intensity and falloff as a hack solution currently. But this feels unreliable and feels like I'm sitting on a bug potentially?
2. I have a lot of confusions with: What does light z do exactly? Is this the same as the game maker variable depth? Should light z be close to the layer depths I'm trying to light? How close? How close should different layers be to each other if I'm trying to light several with the same light... maybe the further back ones a bit less? I feel like my problem with question 1 might be affected by my setup of depths and light z's. Since if I test lighting out in realtime and move light z to a bigger number the lights start doing more weird stuff and intensity and other such values stop meaning less and less. This is fine if I know what the "proper" z is to use where all the settings work correctly. But I'm afraid that with my current just testing blindly to see what works solution I'll happen on a hacky unsustainable end point.
Hi there, enjoying the light engine. Is it possible to block a shadow in one direction but show it in another. ie. I'm simulating a sudden drop in an overhead game I want shadows cast over the drop but not the other way. Thanks :)
What I mean is, if the left half of the room was 100 metres lower than the right half and there was a cliff in the middle, how would I project a shadow over the drop if the sun was in the east but no shadow if in the west. Sorry, not good at explaining myself! 🤪
You will want to set the light depth and shadow depth:
The value is normalized from 0 to 1 which lets you setup your own values based on whatever depth you use for your layers/objects. A value of 1 is closest to the top and 0 is the bottom. So, you could lerp() between your maximum and minimum layer depth values for your lights and shadow casters.
I’ve had a fiddle but can’t seem to get one object to cancel the shadow of another. I’ve set the blocker object to a higher depth than the other and changed the shadow depth and light depth but can’t get the effect I want. Any ideas?
In this example I’m simulating the fact that the dark grey tile is a very tall tower block so should absorb the cars shadow.
First off, just wanted to say that I absolutely adore this lighting engine. By far the best on the market.
Now with that said, I am running into a small issue, that I'm sure just stems from my lack of famaliarity with this engine. The error occurs when trying to set le_shadow_precise_static as the parent to one of my own objects:
You can also just ask here if you want or email me badwronggames@gmail.com
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.
So I have an isometric game and I'm using the classic depth = -y to give a sense of "3D" space in my game.
However the entire lighting engine is being rendered under my objects in the room. Only the background layer is covered by the lighting engine.
I can't seem to get the lighting engine to go over my objects. I'm guessing this is related to the layers in the room but how do I get it to go over my instance layers?
I can't seem to test light_set_depth() because no matter what I do, the lighting engine is going underneath all objects anyways. I'm guessing it has to do with the layers in the room?
I have two layers: "Instances" and "Background"
Not sure what options to set in the light_engine object
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.
So I'm now using a priority queue for depth sorting as per your suggestion. The other methods weren't working unfortunately.
But I'm not sure how to draw lights at certain depths now when looping through my sorted depth instance list. I have a light of type le_light_spot created by my player and it follows my player around, but I'm not sure:
1) How to turn off its default drawing/rendering
2) How to manually render it after my player's draw event call in my depth sorting object
How do I manually render, for example, a spot light using code?
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).
Update on rollback issue. The vertex buffer data is stored in managed objects across frames, but static allocation stuff (buffers) are not rolled back in multiplayer. So when the system does a rollback, the static stuff throws an error. I'm still not sure why the first frame needs to be skipped even when the object is unmanaged, since presumably it would not be rolled back ever, but alas.
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.
That’s very reasonable! I can’t even connect on Games.GX on the most recent beta build, so yeah super bugged. I look forward to seeing where this engine goes post rollback beta.
Howdy! Been having tons of fun playing around with the engine. I have a few questions:
Is there any way to get soft edge shadows, as in those shadows cast from the edge of a rectangle in 2D? Even with soft shadows at max they are still straight lines.
How do you go about normal mapping for an animated sprite? My game is a pixel art game and I want the lights to appear behind the character, but light the perimeter of them. Hopefully such a thing is possible.
What does ambient color do? No matter what color I set it to it doesn't seem to do anything.
Is the source for the shooter and fantasy example available anywhere?
Sorry for all the questions, and thanks for the awesome engine!
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.
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.
Glad to hear this is still being actively developed! The ambient color update will be a huge help. I find that having relatively good control over the ambient color helps set the mood of a scene. I'll check out that normal mapping tool, looks really helpful.
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.
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.
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.
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.
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.
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?
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.
← Return to GameMaker asset
Comments
Log in with itch.io to leave a comment.
Hi! Cool system, thanks! But I have a problem in the isomteric game, for some reason objects become translucent if they overlap each other. Example in the picture. Maybe someone has encountered this?! Single object is displayed perfectly.
How are you drawing the isometric blocks? It looks like they are all on the same depth and so when the normal and material maps are drawn they "blend" together.
Eclipse doesn't fit well with isometric projection, and you'll never get the shadows 100% correct (if that matters) from that perspective.
However, if you have those all at different depths then it should separate them when the normal and materials are composed.
Thx!!!
I’ve really been enjoying messing around with the engine and I’m currently trying to implement it into my top down (birds eye view) game. I have a few questions:
I placed the engine object into a layer above my other objects I want it to affect. I have a light switch object that, when interacted with, creates a light object that is inheriting it’s properties from one of the existing light objects included with the engine. The light switch has a creation variable that allows it to be set to on or off. It’s currently set to on so when I start the game, a light object is created instantly. For some reason, when I flip this switch, just the first one I can reach, to turn off the light, all the shadows and lighting are removed from the game. If I add in another light before hand that stays on, then the lights act normally. This engine doesn’t require a light to be present to function does it?
I’m also having this weird stuttery effect where all of my game objects jitter as I move around the game world. I have a camera that follows the player. Also objects interacting with shadows have this faint little jittery white outline on them. If I remove the engine object, the stutter goes away. Any idea what I could be missing that causes this?
And lastly, I’m trying to create a very atmospheric faint bit of light around that player, but I’m having trouble understanding how to achieve this affect. In your videos, it appears that the variable falloff is able to be changed to negative 1, but right now the lowest it can go is 0. When I set it low there is very obvious banding that is super distracting. I’m not sure how to achieve a smoother effect. Any ideas on how to achieve that?
Thanks you so much for all your hard work. I really appreciate it. And thank you for any help.
Disregard the depth sorting with the walls.
Another thing I was wondering. Here i have two light objects (not counting the one casted by the player), and they don't seem to be acting like how to lights coming from the ceiling would act. The lights form together at their intersection and create a brighter light, which is fine, but in this case I would not want this to happen. Is this a limitation of the engine or do I just need to mess around with the variables? just seems weird that they would do this when the light intensity is so low.
As I pointed out above, you can also see a white outline around the doors.
And lastly, is there a way to cover up objects that are behind shadows? The room to the right is almost completely covered in darkness but I can still see the walls that outline it.
Thanks again!
When two lights combine it should be brighter. There will be an update at some point that makes it easier to control that however.
The walls are receiving light because the wall does not completely block it. You need to have the light at a lower light depth than the shadow depth of the wall otherwise it will pass over it and light the walls in the other room.
Falloff now just goes from 0 to 1, so adjust that how you need.
The jittery thing might be because you use too low of a resolution in your game. I do not know how you setup your camera view and application surface/window, etc. Look at the example project included and see it is not jittery like that.
You may also need to change the shadow map size to better match your resolution.
For your light objects, I cannot see your code. This sounds like you are doing something incorrect with your light switch object. Do you have a solid understanding of the difference between an object and an instance?
Hi, how do you update the shadows, when the object changes sprite_index
i used as parent a dynamic precise shadow and it doesnt update
In the example project you will see an object Example > Scene > shadow_precise_dynamic
That is an example of how to create what you want. It should get a precise shadow mask based on your sprite_index, and unless you did not use event_inherited in the right places, it should not require you updating anything.
Don't forget, if you are changing sprite_index then you also need to change the material_map and normal_map as well.
This engine is very impressive, but I cannot seem to find a crucial feature for me, which is the ability to mark indoor areas. These areas should not be affected by the day and night cycle, and wall shadows from daylight should not end while inside.
Is this something that can be done, or alternatively, possible for you to add?
This could be a feature added at some point, or if you are in a hurry I could advise on how to add it. You would create a mask that is drawn to the shadow atlas for the maps of each directional light.
Ideally I think a new object would need to be created which defines an "indoor" area. Then that could be drawn to the atlas after normal shadows are rendered.
Question about the new runtime in development for game maker (GMRT). They have stated they the rendering backend is based on the javascript WebGPU api. Will eclipse make use of this new rendering pipeline? And if so, what can we expect?
I would like to change things once it is released. Mostly there are certain workarounds that can be removed once the more "modern" graphics API is available.
New features would come after that, not sure what at the moment. Certainly some optimizations can be done with the new API.
Hi!
I just purchased the engine and I'm trying to figure things out, but I admit Im an extreme beginner with this stuff. I was wondering if there were any of the demo projects available for download as a GM project? It'd be really helpful to be able to see just you set up the light objects in the map (how many are needed, what settings you used to achieve a certain look, etc.)
thanks for the great tool!
Thanks for supporting.
The asset comes with an example project. Is there something lacking in that project that needs to be added?
The demo projects have assets that shouldn't be redistributed. They are fine as demos, but the actual project would give access to everything.
Ah, I see
Yes, I was meaning the actual .yyp project file because it'd be really helpful to see how you set up the lighting in the rooms- I played around for a few hours but couldn't get them quite like you had them (I also think I may be putting in too many light objects? Not sure).
I do understand the private asset issue though, that's too bad :(
Do you have any plans to add .yyp files (without any paid assets) in the future?
Not currently. Is there something that isn't working when you setup the scene? You mention too many light objects, but what is the result that seems incorrect for you?
Also, are you using normal maps and materials for your assets?
No, everything I’ve tried so far has worked really well! I’m just a bit lost on how to set the room up. When I open the demos, everything seems to be very well lit and the light is well distributed- I’m having a bit of trouble getting that same result. Everything’s very dark (even when I brought the ambience intensity all the way to 1 and played around with other variables in the controller obj) and I’m trying to figure out how you set up your scenes to have everything spread out so nicely without having like 30 light objects :(
And yes! Using normals and materials. Should also mention this is a pixel art project (which I’m aware isn’t the targeted use for the asset, but you got some great results in your demos!)
What sort of settings are you using on the lights?
Ambient intensity set to 1 would light the scene entirely and you would barely be able to see the actual lights since everything would be fully "lit" already. Is that the case when you have the ambient intensity at 1?
In the example project you can place lights and configure them with a GUI by hitting tab if you have a light selected with the mouse. This can help to understand what the settings on the lights do. You can also mess with some of the light engine settings as well by hitting spacebar.
Okay, first of all: are you insane?
This is beyond what I needed, and is SO MUCH VALUE for only $9.
A few of the tutorial vids are slightly out of date - but WHAT? There are tutorials included too!?
Just... wow. Don't even worry about it.
I took 2 weeks to try to learn GLSL and make a clunky shader that sunk my performance to the watery depths. I took another week redesigning and doing math and being annoyed and got something that wasn't entirely unusable. And then I find this. I spend $9 and: It. Just. Works.
And then I find that off the cuff you also tossed in a camera object that's nearly 1:1 with the one I spent hours making. And a material packer tool. And then you have more tutorials on youtube!? /sigh
I wanted to make sure you got some thanks for doing this - I only scratched the surface attempting to tackle lighting myself - so it is with a tiny speck of understanding that I can appreciate what you've done.
So Thanks.
You are very welcome. I hope it inspires you to continue learning graphics programming!
Is there a reason why draw_sprite_pos() in the draw event does not draw onto the surface using the lighting engine? It appears to work on the normal and material draw events, but not the normal draw event. Just curious why the draw event would fail to use this native draw function, but not the material/normal draw events.
The normal draw events are untouched, so it shouldn't be affected by Eclipse.
What are the actual results that indicate the normal draw events do not work?
Originally, I believed it was the draw event, because it seemed like the lighting was applying normals. But I just commented out the draw event, while keeping the draw_sprite_pos in normal and material events, and nothing is being drawn. So for some reason draw_sprite_pos() doesn't appear to work in the normal and material draw events. If you want to try yourself, I just copied the "shadow_military_crate" obj and replaced the normal draw code with draw_sprite_pos in all of the draw events.
The manual says draw_sprite_pos has some limitations. Auto-crop and 9-slice should be disabled. I have done this.
It also says:
"WARNING! The image above is only for illustrative purposes, and if you use this function on a sprite, you will get different results and may experience texture "shearing" due to the way that a sprite is constructed from a quad of primitives."
I know there are a bunch of vertex buffers, so perhaps the failure to draw_sprite_pos function has something to do with this?
{edit: I saw that an alternative to draw_sprite_pos is to draw primitives/vertex buffers, so I tried doing that too, and nothing is being drawn also]
Ah... looking at the function, I can tell it will not work. It doesn't have an image_blend parameter. Eclipse needs that to pack the other material or normal information.
It probably uses the default image_blend of the instance, so if you set image_blend to the right material or normal values like in the other user events before calling draw_sprite_pos it should work. Just make sure to set image_blend back when doing the normal drawing.
Also the alpha value needs to be the same as in the other normal and material drawing events.
I added in the image_blend = material / image_blend = normal into the corresponding user events before draw_sprite_pos and it still does not work. I also tried draw_set_color before as well, but no success. Draw_sprite_pos() only works in the draw event.
Those user events are being called by another draw event of the light engine, so they are called in draw event.
It sounds like they straight up do not use any vertex color with draw_sprite_pos then. So, it is not possible to use as is.
Instead a primitive or vertex buffer would need to be used which supplies the correct vertex color as the same as image_blend for vertex color.
I can add the feature in the future.
I saw there was a comment about the isometric perspective, but still curious about the potential limits of this lighting system. Is there an easy way to make the shadows cast at an angle, instead of purely top down?
Hello- I've been enjoying using the lighting system very much, but have run into a critical issue. When I build the game for both mobile android and IOS, there appears to be no lighting at all and the screen is mostly just a layer of black.
I used VM when building for both android and IOS (my build is giving me weird errors when trying to run YYC).
I'm happy to provide specs but my phone should be more than capable of supporting the engine. I bought this engine with the intention of making mobile games so I appreciate your support!
Yes I saw your email as well.
To test, go into User Event 0 of the light_engine object and on line 5 where it says "if (false) // Force GLSL ES for testing" change it to true and see if that changes anything. My assumption is the wrong shaders are trying to be used when it runs on iOS.
Apologies on the delayed response- I’ve been having a number of unrelated build errors for IOS that have kept me from testing your fix. I’ll be sure to update this post when I’m able to!
Hello- changing this to false doesn't appear to change anything in game. Can confirm this is the same for use on android devices as well. So I've been unable to get the lighting engine working on any mobile devices.
Is there a way to make colored lights with <1 falloff that do not have white colored radius borders around them? If I have a red light, there seems to always be a gradual fade into white colored lighting. I may not have set up the engine in my game correctly, but after tweaking all the different settings it seems as if the color begins in the center strong, but then gradually turns white the further out you look.
Do you have any screenshot examples to show exactly what you mean?
The light attenuation model is uses an easing function to soften the area where the falloff occurs. You could edit it in the shaders to use another easing function.
For example, in the fragment shader of shd_light_ss_hlsl on line 189 the easing is done by:
float edge = sin((1.0 - smoothstep(focus, radius + 1.0, light_len)) * M_PI_2);
You could keep just:
float edge = smoothstep(focus, radius + 1.0, light_len);
That would remove the easing and might get what you want.
Thanks for this. I tried it but the lights became extremely dulled down. I had to pump up their intensity, and even then it did not look very bright.
If you want an idea of what I'm suggesting, look at the le_light_fire object in the example project. There is a red glow on the ground at the center of the light object, but as it moves outwardly, the glow turns white.
I'm also wondering if this is an issue with the underlying material map that is being used. When I use the same light on another more metal material map the white ring disappears.
I might be the ambient occlusion value of your material.
I'll look at the fire object too.
Look's nice, work even for a 3D game?
The PBR shaders would work, but the shadow casting and geometry is designed for 2D planes. It also is specific to an orthographic projection only.
Thank you!
Awesome!
You will not find another one as awesome and useful to beautify your project. Well documented, and good examples! Works really well and has a TON of features.
Performance is great and the creator responds to all queries quickly giving good advice!! Worth more than the price if youre serious about your game!
Question about optimization. I've tried using emissive particles, and it seems to be pretty inefficient, even in the example provided. If I have 7 le_light_fire at 1080p, my FPS dips below 51 fps. For context, I can run modern games (e.g., Baldur's Gate 3) on highest settings no problem on this same rig.
When I ran the debug it says 15% of the step was consumed by light_pre_composite, and it looks like surface reset target during light engine other 13 was consuming the highest (3%) of that. Is there a way to do particles/lighting that don't consume so much resources? Everything else runs perfectly.
The particles rely on GM's built-in particle system, so it could be limited by how efficient they have made things internally. Unfortunately, GM still has a very old graphic API implementation, and yes, you will find performance for lesser things will cost more than newer games like you mentioned.
To troubleshoot, please answer:
surface_reset_target() is a pipeline change, but saying that is the most costly thing is actually good, because it is not costly.
15% of the step is fine (but we really need to know milliseconds), and it is normal for rendering to cost the most performance. The question is where is the other 85% going? GM did recently change some things about particles, and there could be a lot of data going between CPU and GPU which would be slow if done poorly.
For example, I added 20 of those particle fire lights and ran the profiler:
The important ones to look at here are:
These are great metrics, and this is with VM of course. So, it would be faster with YYC.
My computer is not a good benchmark though, because I build a new one a few months ago with a 4090 RTX and other high-end parts. I have tested Eclipse on mobile, Surface Pro (2014), and my old Linux machine/server. Never seen a problem with particles, so I'm curious what it looks like for you?
I have not tried YYC. Should I simply not use VM?
I did realize that windows has been using my integrated card (not an awful card though can run way better looking games at 60fps), instead of the better card that is used by Baldur's Gate 3. I added my high performance card to the "Game Maker" app, but when I checked in task manager, it still shows the integrated graphics as being used (my guess is I have to add the project app to high performance, but couldn't figure out how to do that).
I tried running a debug again, and this time it is actually much worse (and what I was getting in my actual project). Essentially, if I use the game maker particle system, I experience 0 performance issues. But if I use the eclipse particle system (e.g., le_effect with particle systems and emissives), performance dips very badly. It is nothing to do with my project however, since I recreated it in the example file you've uploaded. I Added 7-8 le_light_fire objects into the room, upscaled to 1080p, and then profiled with these results.
I created an executable for the example project, and set the performance to discrete graphics card, and now I've got 60 fps at 1080p with all the particle effects. Do you think the high step % and ms I posted compared to yours is entirely due to the graphics card and the surface reset target function? I would figure out myself if I could figure out how to make windows run my debugging games from game maker using the better graphics card.
Ah, that makes some sense then. Integrated graphics are going to be extremely inconsistent depending on what rendering is being done. It is weird that it all sits at surface reset, but how they handle VRAM when its integrated would affect that.
I use a lot of multiple render target (MRT) outputs in the shaders, and I bet integrated graphics do not handle that well at all. So, yes you'll want to figure out why it decides to use your integrated graphics at all. If you do not use it at all, then I would suggest disabling it in your BIOS settings entirely. Then GM will have to choice when selecting a device.
Hi, mastiph I am getting the performance issues using shadows, or emissive as well. Like if I inherit from le_game to use textures and create an entity that's a child of le_game, I get a serious performance drop. When I mouse over the blue marker where the drop happens (when I created two instances of such an object, see below for what it does, create a sufrace, and free a surface...no idea what is happening there, perhaps badwrong can shed more light.
I have no issues having hundreds of lights on screen at once however. Yes it taxes more, but not like how only two instances of the object which inherit from le_game do as per the screenshots below!
I am on a 5600x with no integrated graphics, only 3080 graphcis card.
Your screenshot shows an FPS of 919 with an average of 1479.
Dropped to 1010 on creation of two instances in the last one. Which is why I was worried I might not be able to have more than 10. But no worries all is well! Its great!!
I just purchased and was just wondering (before I attempt it) if It can do something like this:
( I like how the trees and bushes are lit, but cast shadows... )
I presume this is possible?
So I tried the system following the basic setup video. But my "normal_begin" tiles are offset by something upon x and y axis. (and perhaps scale, as i tried tile offsets without success )
here's some images:
(without the normals layer)
(with normals layer being offset for unknown reason)
Please Help!!
Are you changing your camera at more than one point during the draw events?
Do you have different origins on the two different tilemaps?
No change of camera and no difference in tilemap origins.
Are there any other assets being used?
I remember something similar happened to someone, and they had another asset doing something that caused the same issue.
Yes that is possible.
really useful package. thanks
Is there a way to have background layers affected by the day/night lighting prefab object, but not any other lighting objects (e.g. __light)? I would like the backgrounds to change with daytime without being affected by other lighting objects to imply depth/distance.
There is no way in Eclipse too have a light only change a specific layer, object, material, etc. Something like that would require a totally separate render pass.
My suggestion would be to use layer scripts on your background and set a simple shader that takes the day/night values such as intensity as uniforms to change the background.
Currently, if you setup the layers correctly you can have backgrounds that are totally unaffected by Eclipse (covered in basic setup tutorial). So, all you would need to do is setup your background like that and add layers scripts.
Gotcha. I've already got the unaffected backgrounds, so I'll look into alternative layer shaders.
Cool. You may not really need a shader, and just setting the global draw color would work. Basically the RGB values of the draw color would be the same as intensity of the sun light. If it looks good then no need to do much more, or if you need more control then a shader might be needed.
Layer scripts are the easiest, and you can get the intensity value from the day/night object (make sure it exists or use "with").
Thanks for this. I've managed to change the alpha of the layers depending on the day light. It works perfectly!
I have another question. Suppose I have lots of frames for character animations. I've been using both material maps and normal maps in addition to the original sprites. I haven't really needed to develop material maps for some sprites (say if there isn't a difference in metal/roughness across the entire sprite). I've also noticed that you can manually change the roughness/metalic of an object. Is there a way to simply redraw the original sprite according to these object values, instead of having to use material maps? In the draw material event, could I clear the pixels in the sprite_index (of the original sprite) to a specific material map color instead of using all these extra sprites?
If I understand what you are asking, you can do full image metal/roughness just by setting those values and not use a material map sprite. When the material map sprite is assigned to the same sprite_index (i.e., left as default) then the shaders will draw metal/roughness using the current sprite_index and all pixels at the metal/roughness set.
Great lighting system. Really impressive. Just getting the hang of it.
Any ideas what might be causing the follow problem?
Room set up with a few tilesheet layers. I cover the walls with an inherited static shadow rect.
All looks good, but a few of the objects on one of the tilesheets, when they're covered by the shadow rect have some pixels illuminated (I think particular shade/alpha) even when they are very far from the light everything else is pitch black (Doesn't happen if I include zero light objects in scene, but adding a single light anywhere causes it.)
Does it happen if there is no shadow caster on them?
Much worse if shadowcaster object is on them (or part of that sprite). But can see if put large version of same sprite on there even with no shadowcasters in room.
Doesn't make a difference if use titleset or just add manually as a single asset on asset layer.
Is there a way to make the shadow objects complete invisible and not interact with the world beyond casting shadows?
I'm on MacOS. Using VM compiler.
Update: did a bit more playing around. Much worse if bloom = 0. Better (but not completely) if bloom = 5.
Update 2: if I add two light engine objects to the room it fixes the problem... but assume (as everything is darker) that this is a bad idea, as effectively running the light engine twice. Odd that it fixes.
Wonder if problem is Mac or VM.
I noticed in the your demo room when compiling on Mac with VM that similar outline problem on some of the objects in dark. Similarly improved by upping the bloom, but not completly.
Hard to see on picture. This is the outline of circle with grill near the helmet.
Will see if I can get YYC working on my machine but has been tricky. Otherwise, will see if can get hold of a Windows computer to test.
Not sure if you have other Mac users? Or if can indicate if supported?
PS: Mac point, but in your demo, the le_navigate Create event needs to add a check for os_type == os_macosx. Otherwise defaults to gamepad and can't move/interact.
YYC will not change anything with the graphics API.
It may be an issue with the tilemap culling. YYG recently fixed something internally and now tilemaps are culled correctly according to the camera. When the normal maps and materials made with tiles are drawn there is no camera applied.
Do you have normal maps and materials set for your tiles?
Ahh. OK.
No normal maps or materials. Just plain tiles. I’ll try creating some and adding in to see if makes difference.
is there earlier version of GameMaker you’d recommend? I can see I can download all previous versions here: https://gms.yoyogames.com/ReleaseNotes.html
Have only just purchased but it's quickly apparent that it lives up to the level of sophistication that is promised in descriptions. Easily worth the cost.
Thank you Badwrong Games for creating this high-quality system that helps supports the GameMaker community and creators like me!
Heya, I recently bought this asset on the official GameMaker website. I've been working with it and am adjusting things to the needs of my project.
There is one thing I want to change, but I'm not sure how to, except if I change a lot of things that may break something else: I want there to be a light source around the player, but I do NOT want it to create any shadows.
I know I can disable shadows from objects, but I want it to stay enabled for other lights. I want the shadows only disabled if there is light from the player. Making shadows have less of an effect to the light of one source but a larger effect to another light source would also be something I'd like.
How would I be able to do this? Thank you in advance for your help.
Use an emissive sprite to draw light without shadow. A transparent or semi-transparent one would work well as a player light radius
I was hoping to use this asset (https://marketplace.yoyogames.com/assets/4720/draw-sprite-pos-fixed) to fix the default draw_sprite_pos(). What is cool is that this asset allows color and alpha which is not currently supported by draw_sprite_pos(), and it fixed the weird texture effects.
So I added it in into my project, added the scripts/shader, and used the draw scripts in the normal/material events. In the material event, I ran the added script (draw_sprite_pos_fixed) including the material variable (as color), and shadow_depth variable (as alpha). In the normal event, I ran the added script (draw_sprite_pos_fixed) including the normal variable (as color), and LE_NORMAL_ANGLE variable (as alpha). Essentially, I tried to replace the ordinary draw events from the example project with this draw_sprite_pos_fixed script.
Unfortunately, the draw_sprite_pos_fixed script appears to be adding a black box around the entire sprite (and any other objects with similar draw events). This issue does not occur if either (1) I only run the script in the draw event or (2) I remove the following 2 lines from the script:
shader_set(sh_perspective);
vertex_submit(v_buffer, pr_trianglestrip, texture);
My guess is setting new shaders while the normal/material shaders are doing their work by the light engine is causing the issue. Any idea on how I might go about getting this script to be compatible? The original GM function is just not enough to make use of this powerful lighting system.
If that asset uses a shader then it would have to be completely combined with many of the eclipse shaders. They use an extra transform that their special shader uses.
The only simple method would be to draw it first to a surface then draw it normally from that surface with the eclipse stuff. That also means getting the current shader, current MRT surfaces, etc. Then after drawing it, restore those.
I've been tinkering with the system all day. I've fixed the black box and I figured I would make this post to just let anyone know if they want to use this add_on or draw_sprite_pos. So, what I've done is create a new prefab le_game_pos, which is just like le_game, except that it draws differently in the order. All it has for drawing is a draw function which uses draw_sprite_pos_fixed() (the asset I linked above).
Then, in light_engine, on the pre-composite (MRT) event (and pre-composite event), and AFTER it draws normal surface/material surface for other objects (e.g., le_game), I have it draw the normals and material for le_game_pos to each surface (surface_normal / surface_material) WITHOUT the shaders. For example, the normal code looks like:
if (!surface_exists(surface_normal)) surface_normal = surface_create(_s_width, _s_height);
surface_set_target(surface_normal);
with (__le_game_pos){ //draw script here}
surface_reset_target()
...do same for material map.
Now, since I'm not putting shaders in, the sprites may not getting the full shaders, but the lighting still applies to some extent and it does not look bad.
Sounds, good and thanks for sharing.
Note that I use the depth buffer to sort the depth of everything when drawing the normal and material maps. If not using the depth buffer things will simply draw in order, which may be ok depending on your own game.
One reason this type of drawing isn't supported directly by Eclipse is because it would be far simpler to just do it in full 3D. For normal map to display correctly after applying a transform such as draw_sprite_pos_fixed() you need to use tangent space to create a TBN matrix. The efficient way to use that matrix is to transform the actual light positions by the transpose. Since Eclipse is more or less a 2D lighting solution (using some 3D maths) that entire process is skipped because the normal maps all sit on a plane facing upward toward the viewpoint. Its cheaper and works well with how default GM drawing works.
So, doing full 3D transformed sprites would really be easier in a normal 3D lighting solution.
Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself.
That makes a lot of sense. I was just trying to add some cool top down parallax effects to add more of a 3d feel in addition to the 3d lighting. It's very impressive what this light system can do for 2d graphics. I did not want to touch 3D in GML, so I'll pass on figuring any of that out, ha!
"Some other things to note, when drawing normal maps I use the alpha channel to encode the emissive value of that pixel. So, you would actually want to draw in 0 alpha if there would be no emissive. That can be done for the entire normal map sprite, or per-pixel in the normal map itself."
I was just using the alpha setup from the other object normal draw events, which uses LE_NORMAL_ANGLE for the draw events in the events I listed. I could always have it send the emissive variable instead.
Gotcha. So, that macro packs alpha and the rotation value into one float. Then in the shader it rotates the normal vector around the z axis according to the image angle of the instance.
I've been messing around both with depth sorting and with the particle system (and presets). I have the depth sorting exactly how I want it with the engine and objects (depth= -room_height-bbox_bottom). however, I'm unsure how to modify the depth of the particles. I see that you have set_depth in the le_particles object, but when I attempt to use this function, it does not change the depth. The particles always appear below everything else no matter what I put in there. Any ideas of a work around?
Try setting the "shadow_depth" variable on the particle system object. It is normalized 0 - 1 as well.
It uses both the instance "depth" variable and that. One is for just the basic draw order (depth sorted) and the other is how it is lit. If that doesn't work let me know.
By "particle system object" do you mean _le_particles? I've been using the presets provided in the example project. The shadow_depth was already set to 1 which I presume would make it appear above other things.
I'm using the preset _le_light_fire (that is using a function to create the particles)., which has _light_cull as parent. There is no shadow_depth for this object, but I want to have the depth of this object determine the depth of the particles. Is that possible?
That fire effect is a light and uses the particle system combined. So, you would set the light depth of the object, and the depth of the particle system.
I watched your tutorial on normalized depth sorting, and decided to change my depth according to it. So now all my objects have positive depth with depth = room_height - bbox_bottom + 100 (except for lighting engine which is -100).
If I set depth of le_light_fire to -1 and part_system_depth(particle_system,-1), it does not draw the particles over the ordinary objects with positive depth.
I also tried a depth that is BELOW the lighting system itself (-100) just as a test. If I set the depth of le_light_fire to -200 and part_system_depth(particle_system,-200), it does not draw the particles over the ordinary objects with positive depth.
Ah, I was looking through things and it is the regular instance variable depth that needs changed along with the particle system.
I have it setup to use layers which work well for drawing over things.
I'll modify things for the next update, and until then set the instance "depth" variable in the effects object as you would any instance.
Is this noob friendly 9_9, Sry, I always been a fan of bump mapping but I never had the big brains to really implement it.
It's supposed to remove as much work as possible from the user. Watch some of the tutorials to see what you think. You still have to create the assets for it to work though.
Hey Man, (I'm Mikk from facebook/twitter etc btw)
Great engine mostly. I was quite pleasantly surprised on how you had set up the first import/setup into the engine. Very quick and easy and doesn't break anything I've already got running in the game. And the first visuals I got out of it when I loaded into my redux version of Voidship were very very promising.
I am getting some potentially weird behaviour though and have a couple questions which after digging a bit and watching half of the tutorials I'm still quite confused about:
1. How much should light intensity be doing? I see it's a value from 0 to 1 and that means I'd expect 1 to be full intensity and 0 to be off (or damn near close to it), but in my setup it's more like 1 is full intensity and 0 is just a tiny bit less than that. Very small change between them. It's making it very difficult to dim lights, I'm spoofing it a bit by combining intensity and falloff as a hack solution currently. But this feels unreliable and feels like I'm sitting on a bug potentially?
2. I have a lot of confusions with: What does light z do exactly? Is this the same as the game maker variable depth? Should light z be close to the layer depths I'm trying to light? How close? How close should different layers be to each other if I'm trying to light several with the same light... maybe the further back ones a bit less? I feel like my problem with question 1 might be affected by my setup of depths and light z's. Since if I test lighting out in realtime and move light z to a bigger number the lights start doing more weird stuff and intensity and other such values stop meaning less and less. This is fine if I know what the "proper" z is to use where all the settings work correctly. But I'm afraid that with my current just testing blindly to see what works solution I'll happen on a hacky unsustainable end point.
Any help on any of this is appreciated, thanks!
Mikk,
I just pushed an update with the new attenuation model. It should now act more like you would have expected it to.
Hi there, enjoying the light engine. Is it possible to block a shadow in one direction but show it in another. ie. I'm simulating a sudden drop in an overhead game I want shadows cast over the drop but not the other way. Thanks :)
I'm not sure what you mean by that. The shadows cast according to light source position and light type determines how its lit.
Using the light depth and shadow depth you can affect some things like that, or another shadow caster blocking.
You'll have to explain in more detail, since there is no way to select a single shadow like that. Its similar to a 3D game's shadows.
What I mean is, if the left half of the room was 100 metres lower than the right half and there was a cliff in the middle, how would I project a shadow over the drop if the sun was in the east but no shadow if in the west. Sorry, not good at explaining myself! 🤪
I think I get it.
You will want to set the light depth and shadow depth:
The value is normalized from 0 to 1 which lets you setup your own values based on whatever depth you use for your layers/objects. A value of 1 is closest to the top and 0 is the bottom. So, you could lerp() between your maximum and minimum layer depth values for your lights and shadow casters.
In this example I’m simulating the fact that the dark grey tile is a very tall tower block so should absorb the cars shadow.
Well that blocker object would need to also be a shadow caster. We don't have full 3D geometry to work with here.
If the thing blocking didn't also cast shadow it would be odd that it also is tall enough to block it.
First off, just wanted to say that I absolutely adore this lighting engine. By far the best on the market.
Now with that said, I am running into a small issue, that I'm sure just stems from my lack of famaliarity with this engine. The error occurs when trying to set le_shadow_precise_static as the parent to one of my own objects:
############################################################################################
ERROR in
action number 1
of Other Event: Room Start
for object light_engine:
Variable <unknown_object>.add_shadow(100740, -2147483648) not set before reading it.
at gml_Script_shadow_area (line 222) - _list[| _i].add_shadow(_buff);
############################################################################################
gml_Script_shadow_area (line 222)
gml_Script_init_shadow_grid_gml_Object_light_engine_Create_0 (line 221)
gml_Object_light_engine_Other_4 (line 3) - init_shadow_grid();
Thank you very much for the support.
My guess with the error is you need to include event_inherited(); in the create event of your object.
Is there a discord or somewhere we can ask questions?
I'm unfortunately having issues just getting it to work in my game at all.
There is a thread on the GameMaker forums where everyone has been asking and discussing Eclipse: https://forum.gamemaker.io/index.php?threads/eclipse-light-engine-pbr-lighting-f...
You can also just ask here if you want or email me badwronggames@gmail.com
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: https://drive.google.com/file/d/1dOVpNrsVvod9C8GMnuO6_hSj5hGVmVM-/view
So I have an isometric game and I'm using the classic depth = -y to give a sense of "3D" space in my game.
However the entire lighting engine is being rendered under my objects in the room. Only the background layer is covered by the lighting engine.
I can't seem to get the lighting engine to go over my objects. I'm guessing this is related to the layers in the room but how do I get it to go over my instance layers?
I can't seem to test light_set_depth() because no matter what I do, the lighting engine is going underneath all objects anyways. I'm guessing it has to do with the layers in the room?
I have two layers: "Instances" and "Background"
Not sure what options to set in the light_engine object
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.
So I'm now using a priority queue for depth sorting as per your suggestion. The other methods weren't working unfortunately.
But I'm not sure how to draw lights at certain depths now when looping through my sorted depth instance list.
I have a light of type le_light_spot created by my player and it follows my player around, but I'm not sure:
1) How to turn off its default drawing/rendering
2) How to manually render it after my player's draw event call in my depth sorting object
How do I manually render, for example, a spot light using code?
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).
Update on rollback issue. The vertex buffer data is stored in managed objects across frames, but static allocation stuff (buffers) are not rolled back in multiplayer. So when the system does a rollback, the static stuff throws an error. I'm still not sure why the first frame needs to be skipped even when the object is unmanaged, since presumably it would not be rolled back ever, but alas.
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.
That’s very reasonable! I can’t even connect on Games.GX on the most recent beta build, so yeah super bugged. I look forward to seeing where this engine goes post rollback beta.
Howdy! Been having tons of fun playing around with the engine. I have a few questions:
Is there any way to get soft edge shadows, as in those shadows cast from the edge of a rectangle in 2D? Even with soft shadows at max they are still straight lines.
How do you go about normal mapping for an animated sprite? My game is a pixel art game and I want the lights to appear behind the character, but light the perimeter of them. Hopefully such a thing is possible.
What does ambient color do? No matter what color I set it to it doesn't seem to do anything.
Is the source for the shooter and fantasy example available anywhere?
Sorry for all the questions, and thanks for the awesome engine!
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: https://www.codeandweb.com/spriteilluminator
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.
Glad to hear this is still being actively developed! The ambient color update will be a huge help. I find that having relatively good control over the ambient color helps set the mood of a scene. I'll check out that normal mapping tool, looks really helpful.
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.
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.
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.
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?
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.