Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
Any disadvantage using a texture pack? - Gideros Forum

Any disadvantage using a texture pack?

Tom2012Tom2012 Guru
edited March 2013 in General questions

I'm using Texture packs for everything at the moment. Sometimes I have a one off sprite and I add it to a texture pack just the same. I could just add it directly to the project. But is there any advantage to this?

I've read up a fair bit on the forums about this but am still unsure what the cons of texture packs are?




  • zvardinzvardin Member
    Accepted Answer
    The only downside I know of is if one texture pack gets so big you're running out of memory. In that case, it may be worthwhile using multiple texture packs. Outside of that though it's a good idea to use texture packs because it should be a lot faster.
  • ar2rsawseenar2rsawseen Maintainer
    Accepted Answer
    1) yes what @zvardin said
    2) one texture pack will be slower to load at the start but faster usage in overall scene, while with separate sprite scene will more likely load faster, but might work slower in overall due to texture switching in CPU/GPU.
    For example, imagine if CPU/GPU can handle only 1 texture at a time, it will have to be switching between multiple texture. But if everything is in one texture, it is already loaded and can be manipulated.

    I would suggest combining texture packs by scenes. That way they will not grow so big, but will have complete advantage of processing, because each scene is displayed separately :)
  • Thanks guys - much appreciated.

    Makes a lot of sense
  • adityaaditya Member
    edited November 2014
    Need to use multiple spritesheets since no image can be greater than 1024x1024. As @zvardin points out here, the device runs out of memory and crashes.

    Basically the doc shows the usage as:
    TexturePack.new({"1.png", "2.png", "3.png", "4.png")}
    Possible to do something like this?
    TexturePack.new({"1.txt", "1.png", "2.txt", "2.png", "3.txt", "3.png", "4.txt", "4.png")}
    Loon Games LinkedIn Facebook Twitter - "Something bit me, gaah!"
  • @aditya :D good try, but nope I don't think so
    those should be different texture packs
  • KaligulaKaligula Member
    edited June 2016

    I created simple class if that can help with loading multiple atlases and holds reference of specific image to specific texture pack so you can fetch as with name of image.
    -- use as:
    -- textureCache = TextureAtlasCache.new()
    -- textureCache:loadAtlases( { "atlas0", "atlas1", "some_other_atlas" } )
    -- local img = textureCache:getTextureRegion( "duck.png" )
    This is a class which represents texture cache in images
    local AtlasesPath = "images/atlases/"  -- should be change to your path to atlases
    TextureAtlasCache = Core.class( Object )
    function TextureAtlasCache:init( )
    	self._atlasHolder, self._atlasKey = {}, {}
    -- resets state of cache
    function TextureAtlasCache:reset()
    	self:unloadAtlas( "all" )
    	self._atlasHolder, self._atlasKey = {}, {}
    function TextureAtlasCache:info()
    	return "TextureAtlasCache"
    -- loads all passed atlases to memory and creates links between image name and texturepack
    -- ( assumption is that name of atlas and txt file have same name and is passed without extension { "first", "second" } for first.png / first.txt and second.png / second.txt
    function TextureAtlasCache:loadAtlases( atlases)
    	for i=1, #atlases, 1 do
    		self:loadAtlas( atlases[ i ] )
    -- load atlas to memory
    function TextureAtlasCache:loadAtlas( name )
    	if ( not( self._atlasHolder[ name ] ) ) then
    		self._atlasHolder[ name ] = TexturePack.new( AtlasesPath..name..".txt", AtlasesPath..name..".png", true )
    		self:loadNames( name )
    		print( "loaded "..name.." into atlasHolder["..name.."]" )
    		print("atlasHolder["..name.."] already in memory")
    -- unloads atlas from memory
    function TextureAtlasCache:unloadAtlas(index)
    	if index == "all" then
    		for i,v in pairs( self._atlasHolder ) do
    			if i ~= 2 then
    				self._atlasHolder[ i ] = nil
    				v = nil
    		self._atlasKey = {}
    		if self._atlasHolder  then
    			self._atlasHolder[ index ] = nil
    			for k, v in pairs ( self._atlasKey ) do
    				if self._atlasKey[ k ] == index then
    					self._atlasKey[ k ] = nil
    	print("unloaded atlasHolder["..index.."]")
    -- create links between images and appropriate texture pack
    function TextureAtlasCache:loadNames( packName )
    	local contents, file = "", io.open( AtlasesPath..packName..".txt", "r" )
    	if (file) then
    		contents = file:read( "*all" )
    		local entities = self:split( contents, "\n" )
    		for i=1, #entities, 1 do
    			local temp = self:split( entities[i], "," )
    			local imageName = temp[ 1 ]
    			if imageName ~= nil then
    				print( "Put in dict: "..imageName )
    				self._atlasKey[ imageName ] = packName
    -- returns region for image in case that image is appropriate texturepack
    function TextureAtlasCache:getTextureRegion( texturename )
    	local key = self._atlasKey[ texturename ]
    	if key ~= nil then
    		local atlas = self._atlasHolder[ key ]
    		if atlas ~= nil then
    			return atlas:getTextureRegion( texturename )
    	return nil
    function TextureAtlasCache:split( str, delim )
        -- Eliminate bad cases...
        if string.find(str, delim) == nil then return { str } end
        local result, pat, lastpos = {}, "(.-)" .. delim .. "()", nil
        for part, pos in string.gfind(str, pat) do
    		table.insert(result, part); lastPos = pos;
    	table.insert(result, string.sub( str, lastPos ) )
    	return result

    Likes: antix

    +1 -1 (+1 / -0 ) Share on Facebook
  • By ensuring the texture dimensions are a power of two, the graphics pipeline can take advantage of optimizations related to efficiencies in working with powers of two. For example, it can be (and absolutely was several years back before we had dedicated GPUs and extremely clever optimizing compilers) faster to divide and multiply by powers of two. Working in powers of two also simplified operations within the pipeline, such as computation and usage of mipmaps (a number that is a power of two will always divide evenly in half, which means you don't have to deal with scenarios where you must round your mipmap dimensions up or down).
Sign In or Register to comment.