Deleted 286 days ago
287 days ago (+1)
Yes, it's the sprite stacking loop that is easily the most intensive thing in the entire game. This is why sprite stacking is not a commonly seen method in games, it's inherently an unoptimized method of drawing things even using a shader, but I am pulling out all the stops that I can to optimize the effect because I want to use it regardless of its inefficiency. building_parent is what every single building object is connected to for the most part, they all execute that code block with the calculations and I refrain from using the two drawing scripts you found because calling scripts is more intensive than doing it in each object manually. The reason your FPS jumps up by 40% is it's simply drawing far fewer sprites when you set the For loop to 4 and thus calls the draw_sprite_ext command less. For some taller buildings which are around 30-50 sprites I plan on cutting them down and increasing their skew angle to save some CPU.
Perspective must be calculated every single frame because the camera is tied to the view, so pre-rendering each building is unfortunately not an option.
P.S. You can keep tinkering but please do not post images of the full code, the source code is not public.
286 days ago(+1)
Hey you could hide the posted source code by switching to the forum system again haha. (I'm joking).
287 days ago (+2)
It seems like most of what you are saying is that you gain optimizations by, well... removing details from the game. I'd generally agree that running multiple sprite operations per frame is inefficient, but in this context it's also a creative solution to the problems coming from trying to make a 2.5D game in a 2D engine.
If I was doing this in Unity, I would just throw a pixel shader on a 3D scene and call it a day, but that seems to defeat the purpose of doing fun pixel artsy stuff by hand, which seems to be the dev's intention and driving motivation.
Most efficient ≠ artistic intention and engine limitations