LÖVE

raidho36 wrote:Note that compressed GPU formats must be "pre-compressed", you can't load a PNG file and get a DXT compressed texture.

Yeah of course, that is why I posted the link to the wiki, there it should say somewhere, that you need to use those specific formats, not just PNG. Also they are not always available (depends on GPU). Again the wiki should explain all that correctly ([wiki]CompressedImageFormat[/wiki])

raidho36 wrote: Atlases speed up rendering due to reducing number of draw calls -it saves on texture switch calls- but I reckon it doesn't save any memory, in fact it could be wasteful due to blank pixels and impossibility to unload individual sprites.

Yes, this may be totally right, I don't know if compression would be more effective on a single larger file than in smaller multiple files?

Also there should be a small benefit from less LÖVE objects/Lua userdata. But I understand that the benefit is minimal. I still recommend to use spritesheets though.

About blank pixels well that depends on how well you can manage your sprites, I have seen some really optimized spritesheets that used the near tiles to avoid bleeding when drawing the quads... again that depends.

I don't usually use a single sprite sheet, I use a spritesheet for each character (all animations and such) and for each tileset (different terrains are separated)

PiFace wrote:Wow, just making graphics load only on demand, then releasing them when no longer used made everything work!

Be careful with this, loading images takes time and freeing them takes time too... Consider loading them on a separate thread and put a loading screen whenever you do loading (or simply start loading before you actually need the asset if you can somehow predict when you are gonna need them). Pokemon games used those transitions which can be done with simple polygons to hide that they were loading big assets to memory.

When freeing, remember to nill all your references to the image and if possible call [wiki]collectgarbage[/wiki] (sometimes you need to call it a couple of times) but be careful, it's a blocking operation and it may take it's time depending on how much memory it needs to free

Positive07 wrote: Yes, this may be totally right, I don't know if compression would be more effective on a single larger file than in smaller multiple files?

Also there should be a small benefit from less LÖVE objects/Lua userdata. But I understand that the benefit is minimal. I still recommend to use spritesheets though.

About blank pixels well that depends on how well you can manage your sprites, I have seen some really optimized spritesheets that used the near tiles to avoid bleeding when drawing the quads... again that depends.

I don't usually use a single sprite sheet, I use a spritesheet for each character (all animations and such) and for each tileset (different terrains are separated

Why would it be more efficient on larger files? They all use small patches with individual micro-palettes and subsampling, in different configurations with different trade-offs, but there is no real compression involved, hence performance is constant.

There is no less objects - you don't have many Images but you have equally many Quads.

Blanks in atlases are coming from sprites with different sizes not occupying 100% of available space, leaving some blank space in the corners of the image and of the sprites. And they are normally all different size due to aggressive clipping and tight packing - if your sprite sheet has all sprites of the same size, you probably didn't do the clipping.