Deleted 1 year ago
Those fountain objects are not going to make it into the final build. They were made for the placeholder level in the second mission, and I made them explode into a ton of debris since they can damage the enemies. In hindsight there's probably way too many. I'm working on optimizing the game's particles even further though, and the next build should be twice as efficient as the current one on older systems.
I mean, is there going to be a campaign with a story or something more straightforward like Nuclear Throne or Counter Strike (in case there would be multiplayer)?
I want there to be a linear campaign with a story and hand-crafted levels. I don't want random generation for any of the stages since I think the game's design at its core must have manually placed enemies and structures. Multiplayer would be cool, but it's very difficult to do in GM:S. Not impossible by any means, but I'd need external help.
1 year 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.
1 year ago(+1)
Hey you could hide the posted source code by switching to the forum system again haha. (I'm joking).
1 year 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