Nick72c said:
…but these are all new concepts to me, so I will see if I can find a way for identical enemies objects to share surface/texture data (although I'm not immediately sure I understand how to achieve this).
Even so, do you really think improving the efficiencies in this manner would have any effect of the missing sprites? How do you see the two issues being linked?
There may be no link, but while improving something, chances are you find a bug while doing so.
About efficiency, there are multiple points why this is bad (eventually, idk what applies to your case):
* Loading the same texture many times for for many sprites wastes memory.
* Switching the current texture to another texture (which is actually the same), can cause redundant state switches on GPU, which can prevent it from keeping all its cores busy.
* Even using a string to identify something is bad, because a string has variable length, so it needs to be allocated from memory which is slow. Copying the string to another string requires a loop, which also is slower than identifying your textures with simple number, e.g. an index to an array of all your textures. Numbers have constant size, copying them is a single instruction. There also is no need to resolve indirection from the string object to the actual string data, eventually causing a cache miss.
So, to fix that, you could have a std::vector (or array) of unique texture objects, where each object also has a string of it's file path.
While creating the sprites, you could iterate this vector until you find the given path string, then only store the found index in the sprite.
You pay the price of the search only once at launch or level load, so no problem. After that it's easy to get the texture for any given sprite using this index.
But this would break if you delete one of the textures. Because it would invalidate all indices to textures after the deleted one.
Thus, many people use unique IDs instead indices, with some mechanism to find some object from a given ID. This makes things easier eventually, but has a cost of resolving indirections form IDs to actual pointers, usually causing cache misses.
So this becomes an advanced topic, e.g. when designing Entity Component Systems.
For now i'd just use indices to identify textures and other things.
It's not critical as long as you just draw some two digit numbers of sprites, but you better get rid of bad habits early.
Often the software turns out slow, but no big bottleneck shows up. So you don't know what to optimize to improve it.
To prevent this situation, you try to write optimized code from the start and all the time, which rarely is real extra work.
