Incorrect represents PirateSoftware's code

[SarvokX]

This test is misrepresenting PirateSoftware's code as it seems to miss the purpose of his lightcatcher lighting system and does not accurately portray performance relative to his game due to a huge difference in the diffuse value.

The purpose of the lightcatcher isn't for full sprite lighting, the purpose is for partial lighting such as edge lit. This is evident through the use of the break statement within the xx loops for light_direction cases 0 & 2 and the rendering of a partial sprite in case 3. This test misrepresents this as lighting for the whole sprite. Using the UndertaleModTool to inspect the game there is only 16 light sources that inherit from light_parent that utilise the catcher system, and these sources all define their own properties that the light_parent draw routine applies to catchers it collides with and each of these 16 light sources use a diffuse value of 5 or 8, Also for what it's worth only a single one of these sources used in a single location uses a direction of 0 and none use 2 (rest are all 1 (despite having no implementation) or 3), so this lighting pixel code will only ever be utilised in a single highly specific case.

So this means your diffuse value being set to the width of the sprite does not represent either the intent of Pirate's code nor it's performance in his use of it.

Furthermore the removal of the last_image and last_sprite check further portrays inaccurate performance of his code, or rather his use of it. This check exists to prevent the code from running multiple times for the same sprite sub image, these variables will only change when the sprite changes during animation (his animations seem to run at 10 game frames per frame) or movement. The flickering would be because nothing being drawn in the in-between frames which seems like it would also affect his use, however he is drawing the whole sprite first every frame before calling this function so flickering would likely be unnoticed.

[barkermn01]

Completely agree with the original post—this benchmark fundamentally misrepresents Thor's lighting system in multiple ways.

This creates an apples-to-oranges comparison. This repo shows static lighting with pre-calculated surfaces, while Heartbound uses dynamic lighting that would require recalculations every frame and using this method would mean drawing the complete 3 surfaces every frame. That's a completely different performance profile.