Is there a way to port old worlds to newer versions or does that happen automatically?
Also that's not how zoom levels should render stuff. When I have the largest view, it should be slower than the smallest view, because I'm rendering more stuff.
Other than that, you should test more how many times something renders and what renders exactly. There might be some cases you've missed, if you aren't sure about that.
Old worlds should be compatible with newer versions, so you should be able to just load it and it should be fine. Some issues could still arise, some recipes have been changed in newer versions, so if you have a world with a crafter you placed in the first version, when loading it into a newer version, the recipes stay the same until it is destroyed and placed again. There could be other problems that come from loading old worlds into new versions, but I have tried my best to preserve compatibility.
About the rendering, as far as I've tested, it does only 4 texture swaps every frame (6 if goddess is on screen), where before it did between 2 and 4 for every structure (depending on the structure). Texture swaps are slow, and the performance impact of 40 texture swaps every frame is a lot more than drawing 40 sprites. The engine only renders stuff on screen, so it doesn't swap textures for off screen stuff. So in old versions it performs worse when zoomed out because it needs to swap a lot more, not only because it needs to draw more sprites.
You are right that when zooming out, it should be slower, and in old versions it is a lot slower because of texture swaps, but after v9.8 it performs about the same on all zoom levels, because the main difference in performance between zooms is no longer there. Drawing more sprites itself has almost no impact on performance in comparison to other things the game does, so you won't notice it between zoom levels.
Ah, good to know. Why do you need to swap textures? You have a big spritesheet, so isn't it better to change the image coordinates for each render update of the sprite routine? I'm fairly new to game dev, so I ask because it sounds like you switch the whole image instead of using texture coordinates.
It doesn't really need to swap the whole texture page, it does get all the sprites from the same page. It only swaps for the goddesses which I put on a separate page because the sprites are very large and they wouldn't fit on the main page.
The reason it was doing a lot of swaps before v9.8 was because I was using the built in draw_rectangle function which swaps textures to a built in page that contains only a white pixel which it uses to draw the rectangles (I wasn't aware of this). Rectangles were used for progress bars on structures, so it had to swap a few times for every structure that had a progress bar. The way I fixed it was using a white pixel I had on the main page, and just making my own rectangle function.
Oh, ok. I see that the progress bars are just one colored growing rectangles. Why don't you detach it from the building, render it above it and just draw the vertices of the rectangle growing and color it with a shader something like that? That doesn't require any textures. If your engine supports shaders, you can even calculate the position of the colors of the conveyor belts with a bit of math. This would be much more faster then swapping the textures. I see that some sprites are just simple rectangles or lines. Calculating and rendering them yourself is much much faster than using a texture. You should consider that in the next update.
The progress bar is already not a part of the structure sprite, and the game does draw the rectangle above the structure. I don't know if calculating and rendering vertices is faster in this engine, maybe it is, but it's fine now. The rectangle function that I made uses a white pixel on the texture page that is already loaded, and stretches and recolours it to make a rectangle for things like the progress bar, so there are no swaps (basically works the same as the built in rectangle function, but without swapping pages). Drawing more sprites doesn't impact performance that much, so it's fine.
If I should optimize, it would be other parts of the code at this point. The crafters for instance start at the top of an array containing the recipes in the form of arrays of items, and check every one of those arrays against their inventory until they find an array whose items the inventory contains (and then they start the crafting countdown). This is really inefficient, and is probably having a much larger performance impact than the same structure drawing an additional sprite as a progress bar.
Conveyors do already use a shader to swap colours.
I hope I'm understanding your points properly, and not speaking past you. If you want you can add me on discord, it could be easier to talk there.
Oh, that would be nice if you could add me to discord. I will send you a request when I can, I probably don't understand the language of your engine, but having someone to talk about game dev and engine stuff would be really nice for once and maybe I can help you with some stuff.
The thing I was getting at is that texture swaps are apparently really expensive. I was just naming examples to reduce them. And conveyor belts with 2 sprites are much more expensive as you build a lot more of them and are always active than just a building with 6 sprites that are only active when you place items in them.
