Handling multiple Textures and Vertex Arrays

[Cyrana]

Dear SFML-community : )

I'm trying to solve the following problem:

My game shall have the possibility to support customised levels by users.
Therefore, I want to offer already implemented game-objects and the chance of creating new ones.

A game-object can be a platform to walk on, an enemy, ...

Every object owns its very own set of animation key frames (idle, attack, ...)
Now, the game provides multiple level. I could provide one complete sprite-sheet optimised for every level. Optimised as in, only the needed objects shall be on the sheet.

But at the moment, my game works like this:
Every object brings in its very own sprite-sheet, e.g. an enemy owns a sprite-sheet (texture) with all its needed animation key frames nothing more. This texture gets cached.
If an animated ground-part - on which the player can walk - is loaded, it will only provide these needed texture.

My idea behind this was to only load the needed textures and offer flexibility for customised objects.
Players can create their very own object by specifying characteristics (as behaviour and sprite-sheet locations) via a Lua file.
Once the player feels the need of creating their complete custom animated enemy (or whatever entity they want), they can easily integrate them on this way.
If they would have to invoke them on a large tile-sheet, they would have to set all the mapping of objects as well - which is a bigger hassle. Especially, it would need the player to know, how their final level will look like. Therefore, they would have to provide an already thoroughly planned tile-map before they even can start creating.

Now, the worry with my approach is the performance and RAM usage. Current testing results in rather large RAM usage per vertex-array. As this game runs on a variety of platforms, I want to keep requirements low.

I could think of a merging-process before one level is loaded. This would provide only one texture, therefore only one vertex-array/draw-call.
But this will take some work in order to track the mapping of where are what subsets. It might also create some ugly loading/processing screens.

Does someone might know how to solve this problem with a different approach? Or do I have to bite into the sour apple and just simply go with a possible large amount of vertex-arrays?

Thanks a lot for taking your time and reading my thread. If I've been unclear in anything I said, please let me know : )

[Mr_Blame]

If i understand you correctly, you are holding an sf::Image insatnce in ram and load it into texture, when needed. In that case you cannot escape lags, because of some data transitions. So you'spd pre-load, than use some "lazy-loading-technique"

[Cyrana]

I'm caching the loaded textures. Game element objects own a proxy to them.

If there would be one large sprite-sheet for the whole level, all objects would hold a shared proxy to this loaded instance.

However according to my current approach, enemy type A holds a proxy to its very own tile-sheet.
Enemy type B holds a proxy to a different tile-sheet.

I was just wondering if there might be a better approach to this, when taking my necessities into consideration.

[Mr_Blame]

I am sure that caching texture and delaying loading is not a good approach, as i said in any way, no matter from where you take data(ram or disk), in order to load texture, causes lags(because of data transition)

[Jonny]

I am sure that caching texture and delaying loading is not a good approach, as i said in any way, no matter from where you take data(ram or disk), in order to load texture, causes lags(because of data transition)

delay loading is fine, and there's a massive difference between loading something from RAM and loading something from the disk. I also don't think you're really addressing OP's problem

To address OP's problem: vertexarray's shouldn't use up much RAM at all, how much RAM are we talking? It'll be the textures which increase the memory usage most I suspect, and the difference between loading lots of separate tiles or loading one big tile comprising the smaller ones I don't expect would be that huge (might be worth testing?).

The main thing I'd say is don't worry about performance unless you're sure there's an issue that needs to be addressed (it's also much more fun not worrying about it all the time )

[Hapax]

You can use a different texture per draw so, for example, you can draw all of the map from a map texture, all of the enemies from an enemy texture, and all of the players from a player texture. In this example, still only three draw calls. Depending on your number of enemies etc., you might not even have to draw them all together. A map, ten enemies and one player (for example) should be fine to draw separately.

However, if you have a map that uses multiple textures, I think pre-combining them is the best option; you'll most likely want to draw that map as one.
By "pre-combining" here, I mean: creating the texture already prepared (although this doesn't allow customisation), loading the separate image and creating a custom texture from those before use, or (as a compromise) create the custom texture from separate images in a separate "customisation" application (or part of the game), which would reduce delays to only when customising (the customed image would be saved and then used as loaded).

[Cyrana]

I am sure that caching texture and delaying loading is not a good approach, as i said in any way, no matter from where you take data(ram or disk), in order to load texture, causes lags(because of data transition)

Why do you think I delay loading?

I am sure that caching texture and delaying loading is not a good approach, as i said in any way, no matter from where you take data(ram or disk), in order to load texture, causes lags(because of data transition)

delay loading is fine, and there's a massive difference between loading something from RAM and loading something from the disk. I also don't think you're really addressing OP's problem

To address OP's problem: vertexarray's shouldn't use up much RAM at all, how much RAM are we talking? It'll be the textures which increase the memory usage most I suspect, and the difference between loading lots of separate tiles or loading one big tile comprising the smaller ones I don't expect would be that huge (might be worth testing?).

The main thing I'd say is don't worry about performance unless you're sure there's an issue that needs to be addressed (it's also much more fun not worrying about it all the time )

Well, it is not "much", but let's say, would I have to use separate vertex arrays, if the same texture-type object has a different animated key frame going?
For example: Enemy1 type A has frame 2 going
but enemy2 type A has frame 6 going.
This would probably require 2 vertex arrays for the same sprite sheet (texture).

You can use a different texture per draw so, for example, you can draw all of the map from a map texture, all of the enemies from an enemy texture, and all of the players from a player texture. In this example, still only three draw calls. Depending on your number of enemies etc., you might not even have to draw them all together. A map, ten enemies and one player (for example) should be fine to draw separately.

However, if you have a map that uses multiple textures, I think pre-combining them is the best option; you'll most likely want to draw that map as one.
By "pre-combining" here, I mean: creating the texture already prepared (although this doesn't allow customisation), loading the separate image and creating a custom texture from those before use, or (as a compromise) create the custom texture from separate images in a separate "customisation" application (or part of the game), which would reduce delays to only when customising (the customed image would be saved and then used as loaded).

Yes, this is what I was afraid of. I had the idea, that my game checks whether textures have been merged yet - which is the case for all my default provided levels. Once someone creates a new level and saves it, all needed textures will be drawn on one huge tile sheet. Mapping would become an annoying part though.