{ "version": "https://jsonfeed.org/version/1", "title": "Moldling Dev Blog", "home_page_url": "https://moldling.com/", "feed_url": "https://moldling.com/api/feed.json", "description": "A feed containing the latest blog posts about the development of the game Moldling.", "author": { "name": "soraslove", "url": "https://soras.love/" }, "items": [ { "id": "https://moldling.com/blog/2026-06-06-ray-traced-shadows", "content_html": "

Every now and then I try to experiment with the visuals of my game to see if there's anything I can improve on. This\ntime I wanted to see if I could implement dynamic shadows to make my game look a little less flat.

\n

This was hugely inspired by the shadows\nin Rain World\nand Iron Bramble.

\n

First: Results!

\n

The top video is the before and below is the after.

\n

\n

\n

It's a very subtle change, but I think it achieves my goal of giving my world more visual depth.

\n

First of all, my game is made in (my custom fork of) Godot so some of the implementation details will be specific to\nthat, but the general idea can be applied to other environments.

\n

Alright, onto how I made this. Since I was inspired by Rain World I first tried to see if there were any resources on\nhow they implemented their shadows. I found\nthis Twitter\nthread which explains nicely how they approached their implementation. I used this as a starting point, but ended\nup diverging from it and working on my own approach.

\n

Rendering the depth map(s)

\n

The first thing we need is a depth map of our scene. I did this by assigning each object (CanvasItem) in my scene a\ndepth value and an optional depth texture in case I want the depth to vary across the object. Each object also has a\nboolean called is_solid which decides if the object is solid (meaning that no light rays can pass behind the\nobject), or if the object is flat (meaning that light can pass behind the object, just not through the object). Things\nlike doors are solid since I don't want any light to pass through them. Additionally, every light source also has a\ndepth, which comes into play later.

\n

Then I create two additional render passes (using SubViewports in Godot) which render my depth maps. They use the\naforementioned depth values and textures and calculate the objects total depth based on those (depth value +/- depth in\nthe texture). The first pass renders all the solid objects, the second one all the flat (non-solid) ones. These get\nstored in textures and are used in my shader.

\n
\n Technical Note\n
\n

\n The depth value was implemented by adding a depth property\n to the CanvasItem node.
The depth texture was done by adding a depth texture property to the CanvasTexture\n resource.
Both of these properties get passed onto the canvas shader.\n

\n
\n

\n The render passes were done by\n adding an overwrite material property to Viewports. This overwrite material gets applied to all elements rendered in the\n viewport and handles the depth.\n

\n
\n
\n\n

The depth maps end up looking something like this:

\n

First the solid one, second the flat one.

\n\n\n\n

Rendering the shadows

\n

Now that we have depth maps "all" that is left is to actually calculate the shadows. This is done in my main shader\nwhich is used for every CanvasElement. I have a function in my fragment shader that gets executed for every fragment of\nevery light source.

\n

The basic idea is this: We shoot a ray from our current position to the light's position and if we hit anything, then we\nare in shade.

\n

In detail this means the following:

\n
    \n
  1. We get the lights depth value. If the depth value is 0.0 then no shadows will be drawn (we don't want this light to draw shadows).
    2. \n
  2. Then we get the current position by taking the SCREEN_UV.
    3. \n
  3. Then we sample both depth maps (the solid one and the thin one) at the current position and save the higher depth as our start depth value.
    4. \n
  4. If our start depth is higher than the light depth no shadows will be drawn (the object is in front of the light).
    5. \n
  5. We then assemble two vec3s one is the spatial start position (start_pos.xy, start_depth), and one is the spatial light position (light_pos.xy, light_depth).
    6. \n
  6. We then step from the spacial start position to the spacial light position in increments of a constant step size (This step size determines how well we catch every shadow caster. A step size of half a pixel has worked well for me).
    7. \n
  7. At every interpolated position we first sample the solid depth map and check if our current interpolated depth is less than the sampled depth. If it is smaller, then that means there is a solid object casting a shadow on us, and we can break out of the loop.
    8. \n
  8. After not finding a solid object casting a shadow on us, we sample the thin depth map. If our current interpolated depth is within a small error margin of our sampled depth, then that means there is a thin object casting a shadow on us, and we can also break out of the loop.
    9. \n
  9. If we don't find either a solid or a thin object casting a shadow on us, we continue stepping towards the light.
    10. \n
  10. If we reach the light without finding any shadow casters, then that means that we are in view of the light and we are fully lit.
    11. \n
  11. Finally, we multiply the current Light color based on if we found a shadow or not. Multiplying it with 0.0 would mean that things in shade are fully unlit. I've also found that interpolating the factor based on how far away the shadow caster is gives a nice decaying shadow effect.
    12. \n
\n\n

That's basically it. As you can imagine tracing a ray for every fragment can get quite expensive and only works since my\ngames resolution is so small (320x180). I've also included an option to disable ray traced shadows in case weaker\nmachines struggle doing all of those calculations.

\n
\n Technical Note\n
\n

\n I added a custom function to the base canvas shader that I can overwrite in my shaders that gets called for every light. It is similar to the light function but does not overwrite any default light behaviour, so a similar implementation could definitely be implemented using the default light function.\n

\n
\n
", "url": "https://moldling.com/blog/2026-06-06-ray-traced-shadows", "title": "Dev-Log: Ray Traced Shadows", "summary": "Implementation of real time ray traced shadows.", "image": "https://moldling.com/blog/2026-06-06-ray-traced-shadows/thumbnail.png", "date_modified": "2026-06-06T00:00:00.000Z", "author": { "name": "soraslove", "url": "https://soras.love/" } }, { "id": "https://moldling.com/blog/2026-03-26-screen-transition-improvements", "content_html": "

I've been able to improve screen transition performance drastically. Moving into a big screen used to have stutters of\nup to 50ms, meaning that the frame that you go into a screen would take 50ms. This is much longer than a frame should\ntake. Now there is no additional frame delay when going into screens of any size, meaning that the frame rate stays a\nconstant smooth rate.

\n

First: Results!

\n

This is before. First is the screen transition frame itself. In the top graph you can see the red bar being the frame,\nand you can see that the frame takes 54ms. Below you can see the game in action and the stutter when moving between the\nlarge screen.

\n\n\n\n

Now after my changes! As you can see the frame now takes as much time as any other frame (around 15ms in this case) and\nthe stutter in the game footage is gone!

\n\n\n\n

Now onto how I achieved this.

\n

First of all, some necessary details on how my game works. My game is made in Godot so the implementation details will\nbe specific to that. My game loads neighboring screens in a separate thread whenever you enter a new screen. The loaded\nscreens get stored for later use.

\n

My previous setup was that I have a SubViewport that renders my game and a list of inactive nodes that store the\nneighboring screens. Whenever the player moved into a new screen the previous screen would be removed from the\nSubViewport and the new screen would be moved into the SV. Moving these large screens around was what caused the\nhiccups.

\n

My new solution inverts this approach. I have a list SubViewports. The active screen is in one of them and the\nneighboring screens are in the other ones. Only the one SV with the active screen renders anything the other ones are\ndisabled (meaning they have their Update Mode set to 'Disabled'). Whenever the player moves into a neighboring, screen\ninstead of the screen being moved, I now only move the player. The player gets put into the SV of the screen and the SV\ngets set as the active one. Thats all that needs to happen now. This is much more performant since the player is a lot\nless complex than the screens, so moving it around in the scene tree is much simpler.

\n

That's it, thanks for reading. I'm happy with how smooth my game runs now :)

\n", "url": "https://moldling.com/blog/2026-03-26-screen-transition-improvements", "title": "Dev-Log: Screen Transition Improvements", "summary": "Reduction of lag caused by screen transitions.", "image": "https://moldling.com/blog/2026-03-26-screen-transition-improvements/after.png", "date_modified": "2026-03-26T00:00:00.000Z", "author": { "name": "soraslove", "url": "https://soras.love/" } } ] }