itch.io

Thanks for this! 

Any chance you could implement billboards that are non-players, that keep their location on the floor relative to the camera? I've been tinkering with it some, but can't figure it out.

Also: how might I go about normalizing depth? I usually use depth=room_height-y, but the object doesn't draw with the shader when using that depth sorting method.

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?

Thanks for the clarification! I moved the vertex_position() code into the step event from the draw event, and it all runs smoothly at 60 fps now.

I was destroying the buffer in the clean-up, but then I switched to creating the buffer as a temporary var which I assumed wouldn't work in a separate event. I switched to a local variable for the buffer, so I don't have to keep creating and destroying it every draw event (which I assume is not efficient). I also used the var _angle suggestion for normal events. Still seeing a frame drop even with these modifications, but it seems better. There is a frame dip from 60 to 50 if I make the scale of the object bigger or place 6 of them on screen at once.

Yes! I plan on utilizing shadows if possible. A shadow path object that has the functionality of draw_sprite_pos would be incredibly helpful.

I used the __le_game object as a parent, then overrode the create/normal/material events with additional vertex buffer drawing, AND IT WORKED!

I'm very new to writing my own vertex buffers, but I understand that if you have dynamic shapes, you can't just store the data once since you are recalculating the coordinates. Is this correct for the normals draw event or do I have too much that could be moved to the create event (obviously I would make some of the vars into local variables)? (I just want to make sure I'm doing this efficiently, because it dips below 45 fps if I have like 8 objects drawing this on screen)

CREATE

////

event_inherited()

vertex_format_begin();

vertex_format_add_position_3d();

vertex_format_add_colour();

vertex_format_add_texcoord();

format = vertex_format_end();

USER EVENT 15

////

var _uv_data = sprite_get_uvs(normal_map, 0);

var _umin = _uv_data[0], _vmin = _uv_data[1], _umax = _uv_data[2], _vmax = _uv_data[3];

var vb = vertex_create_buffer();

vertex_begin(vb, format);

vertex_position_3d(vb,  bbox_left,  bbox_top, 0); vertex_color(vb, normal, LE_NORMAL_ANGLE); vertex_texcoord(vb, _umin, _vmin);

vertex_position_3d(vb, bbox_right,bbox_top, 0); vertex_color(vb, normal, LE_NORMAL_ANGLE); vertex_texcoord(vb, _umax, _vmin);

vertex_position_3d(vb,  mouse_x, mouse_y, 0); vertex_color(vb, normal, LE_NORMAL_ANGLE); vertex_texcoord(vb, _umin, _vmax);

vertex_position_3d(vb, mouse_x+100, mouse_y, 0); vertex_color(vb, normal, LE_NORMAL_ANGLE); vertex_texcoord(vb, _umax, _vmax);

vertex_end(vb);

var _tex = sprite_get_texture(normal_map, 0);

vertex_submit(vb, pr_trianglestrip, _tex);

It would be a great feature! Using draw_sprite_pos can create a parallax effect by modifying sprites based on camera position. It really creates an additional sense of depth for the top down perspective.

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.

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]

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.

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?

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.

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. 

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.

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. 

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.

Yep. 

Since I have multiple sprites that change depending on the player input, everytime the sprite changes, I get the sprite name and add an "_n" then use asset get index to change the normal map to the sprite that is named the same as sprite index with a "_n" after it. I did notice that when I updated the material map in this way (instead of just setting it to sprite index in the variable defs) the result was much closer to the original set up I had with material sprites, but it wasn't exact. I might be able to tweak the metalic/roughness set numbers to get it to where it was.

so the material map I was using was a single color. But switching to sprite index, and using the set metallic/smoothness functions doesn’t replicate the lighting effects. I think I I just need to adjust the values to recreate the effect. 

Yes, that is what I intended to ask. For some reason doing this (setting to sprite_index) does not draw the metal/roughness set the same.  I may need to tinker with the specific metal/roughness settings in light of a change away from the original material sprites.

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?

Gotcha. I've already got the unaffected backgrounds, so I'll look into alternative layer shaders.

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.

I would be interested in trying out the static array method, since I've mostly done away with layers and moved to the depth sorting you propose in your tutorial. 

There really should be an easier way to do all of this. GM is supposed to be an easy engine to develop on, but some things....

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.

Yep. That fixed it.  Also, you don't have to change the depth of the particle system or the le_light_fire, just the le_effects object.

Only problem with this set up is now all of my particle effects depth are determined by a single abstract object that may need different depths depending on what is using it to make the particle effects.

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.

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.

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.

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? 

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?

Thanks for the warning! This is a bit off topic, but are there any tentative plans to make it compatible with rollback multiplayer? (Maybe if YYG ever release it!?)

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.

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.

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

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

Thanks for the update, I’ll try it out now! It will be nice to remove my workaround. 

Hopefully when LTS gets released GM will be more stable and OperaGX will support better shaders. I don’t desperately need it, since I’ll probably wait until they release multiplayer on other platforms this winter. 

P.S. You did a fantastic job on this engine. My placeholder sprites look surprisingly good with this thing haha. 

Update: 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?

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!

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.

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.