Comments

Log in with itch.io to leave a comment.

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!

(1 edit)

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!

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.

(+1)

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!

(1 edit)

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: 

NameTime (Ms)
surface_reset_target0.01
part_system_drawit0.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 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. 

(3 edits)

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.

(+1)

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.

(1 edit) (-1)


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!!

(1 edit)
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... )



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!!

(1 edit)

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.

(+1)

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.

(+1)

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").

(1 edit)

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.

(1 edit)

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?

(4 edits)

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.

(1 edit)

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 

(1 edit)

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. 

Deleted 1 year ago
Deleted 1 year ago
(+1)

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.

(1 edit)

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.

Deleted 1 year ago

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.

(1 edit)

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!

Deleted 360 days ago

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! 🤪

(1 edit)

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.

(2 edits)

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. 

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.

(+1)

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

Deleted 1 year ago

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


(+1)

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.

(4 edits)

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?

(2 edits)

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

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

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

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

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

depth = room_height - y;

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

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

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

(+1)

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. 

(+1)

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

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


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

ERROR in

action number 1

of Other Event: User Defined 11

for object light_engine:

vertex_submit: Illegal vertex buffer specified.

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

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

gml_Object_light_engine_Other_21 (line 72)

gml_Object_light_engine_Draw_0 (line 3)



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

(+1)

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

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

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

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

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

(+1)

So, I switched everything to unmanaged and I still got the illegal buffer error, so I digged a little deeper and tried to understand what was going on with vertex submit. It was fine if it returned a 0 for the local variable vertex_buffer, but it was throwing -4 when multiplayer started. What is weird is it only returns -4 for a single step. So what I did was create a local timer variable, set to 0, and add 1 in the step event. Then in the light_engine user event 11 - lighting SS (this is the event that was throwing the illegal buffer error), I had it only run if the timer variable was above 1. It actually worked and now there is no error.

(+1)

Ah, that would mean something isn't initialized fast enough.  I suspect "room start" is not the same when using rollback.

The shadow buffer variable is just a pointer that is first set to "noone" which is -4.  In the end step event it should check with the shadow grid for which static buffer to use and then append any dynamic shadows to that as a vertex buffer.  So, if that does not happen it would remain as -4. 

In the next update I will add dummy buffer that renders a single triangle with no area.  That is faster than adding checks for validity since the vast majority of the time it the buffer will always have something there.

Chances are the shadow grid is actually created and ready, but depending on the position of the view it could grab nothing from the grid depending on how your game is setup.  So, this will add a failsafe for that.  I'll add the dummy buffer in the next update and you won't need to do anything like you did.  Thanks for bringing that to my attention.

(+1)

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

I look forward to the update! Thanks!

Update: I've encountered a new problem. While running the game from Windows there is no problem and the lighting engine works. However, running the game from OperaGX completely disables the entire lightning system. I'm not sure if OperaGX does not support some of the graphical rendering by the engine or what is going on. Have you been able to get it to work on OperaGX?

(+1)

Thanks for the update.

I also have not found it working on OperaGX, and really most things with shaders and surfaces seem to have issues there.

I know WebGL is totally capable of the type of deferred renderer which Eclipse does, but the older API implementation that GameMaker currently uses is indeed lacking some key things.

I have and will be looking into it more because I do want it supporting everything.  Most likely the big changes to GM that are coming soon will be the best solution since at that point it sounds like the graphics API will be much more up to date and fully support MRT.

Also, in the last update I did add a special place holder buffer so that the illegal vertex submit error will not happen.  It also turned out, after rigorous testing, that GM has some internal issues with destroying vertex buffers and how they are indexed which cause memory leaks.  That was also a factor in the error you originally had, but has been fixed now as far as Eclipse goes.