Puppeteer
Emperor
Creating this thread to post a link, will return shortly to start the conversation. In my mind there are two approaches to the discussion: the modder approach and the dev approach.
Some terrain animation would be good to have. Even a few frames can liven things up
I agree... a few animated terrain tiles such as a Waterfall or Billboard as I placed in EFZI2 Elite add a nice touch to Games. Immobile Units were used but it would be Great to be able to add such animations as simply animated Terrain so the AI would not go after them as Units. In order to prevent the AI from going after Terrain Units, they need to be set on Impassable Terrain and that can also cause problems such as if pollution appears on them, it cannot be cleaned.
Is this going to be a separate file? Probably will be easier to work with, that way.
Of course it can also be that "terrain animations" can be part of a larger file, say for "resources", which modders can set to appear at xy tile. I don't know the code, so can't say which of the two ideas is more practical/easy to implement; personally I'd rather have a separate animated gfx file.
Also, imo some animation for cities can be provided as well, even if only animated flags/banners.
I don't mind working with layers. I am not sure if that is really useful in a CivIII-like game, though, for terrain gfx (?).
For animation frames. I want to know how you're expecting to make animation. I presume you will have a number of images/frames slightly different from each other. Are those frames separate files each? Separate layers in a single file? Laid out side by side in a strip? Something else?
For my experiments with unit animation I've been using a MeshInstance2D instead of AnimatedSprite because a mesh is a natural vessel for a shader. We could probably attach the shader to an AnimatedSprite instead since shaders in Godot operate through a kind of material, ShaderMaterial, that presumably can be used with any CanvasItem. But if all AnimatedSprite is going to do for us is pick a sprite from a sheet I don't think it's worth using. Also I'd be interested in comparing the performance of the two approaches. That animated warrior sprite took 400 ms to load even after Quintillus worked on optimizing it, which is still unacceptably slow since we should count on loading hundreds of unit types. I suspect the reason it was so slow is that there's a significant fixed cost to creating any texture and that approach was creating one texture per frame (does it have to?). Meanwhile I haven't noticed any increase in loading time when loading one texture per FLC to be drawn with the shader+MeshInstance2D.If any of the devs think I'm crazy for considering animated terrain just now: actually I don't think it will be particularly challenging to get done. (To get right is another matter, but I'm always "working first, pretty later".) We're using Sprites. AnimatedSprites are a child of Sprite, so the display code doesn't change, just the preparation of the Sprite.
For my experiments with unit animation I've been using a MeshInstance2D instead of AnimatedSprite because a mesh is a natural vessel for a shader. We could probably attach the shader to an AnimatedSprite instead since shaders in Godot operate through a kind of material, ShaderMaterial, that presumably can be used with any CanvasItem. But if all AnimatedSprite is going to do for us is pick a sprite from a sheet I don't think it's worth using. Also I'd be interested in comparing the performance of the two approaches. That animated warrior sprite took 400 ms to load even after Quintillus worked on optimizing it, which is still unacceptably slow since we should count on loading hundreds of unit types. I suspect the reason it was so slow is that there's a significant fixed cost to creating any texture and that approach was creating one texture per frame (does it have to?). Meanwhile I haven't noticed any increase in loading time when loading one texture per FLC to be drawn with the shader+MeshInstance2D.
Pre Optimizations said:700+ ms = total
200 ms = ImageTexture creation
350 ms = SetPixel calls
150 ms = everything else
Post Optimizations said:420+ ms = total
200 ms = ImageTexture creation
70 ms = SetPixel calls
150 ms = everything else