Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
How to structure bitmap heavy games — Gideros Forum

How to structure bitmap heavy games

totebototebo Member
edited April 2016 in General questions
Hi guys,

I'm working on a game with a growing number of bitmaps, with last count over 600. I've got them all in one folder and export them to one spritesheet. At some point I'm going to have to start splitting these into multiple sheets, so I'm wondering if anyone has had experience of a game with lots of bitmaps and, if so, if you have a nice way of dealing with this.

Cheers,

Niclas

Likes: MoKaLux

My Gideros games: www.totebo.com
+1 -1 (+1 / -0 )Share on Facebook

Comments

  • antixantix Member
    edited April 2016
    I'm keen to know what others do also.

    I suppose you really have to have things sorted into groups like Player, Monsters, Items, etc.

    I'm not using Texture Packer. I use spritesheets where all the sprites are grid aligned and I use regions to fetch the individual sprites.
  • @totebo: The size of a bitmap is limited, depending which devices and platforms you will target. With 1024x1024 you are save on any device I think.
    With so manys bitmaps, imho you don't get around having multiple sprite sheets.
    if you have a nice way of dealing with this.
    Creating them or how to use multiple spritesheets in the app?
  • @antix We don't use that many bitmaps in our games, but we do use multiple bitmap images to represent the various @1, @1.5 and @2 device sizes. Even with a fairly small number of bitmaps this is time consuming to manage.
  • antixantix Member
    @simwhi true, I haven't got to adding multiple resolution files yet argh.


  • @MikeHart, yeah the size limit is one reason to use multiple sprite sheets, multiple resolutions another (although for this project it's not an issue since it's a pixel graphics game with upscaled pixels). What I was wondering is if there are ways to deal with multiple spite heets in a nice way, or maybe an alternative to sprite sheets altogether, when your nymber of sprites gets bumped into the thousands.

    @simwhi, as I said above, that's not an issue for this particular project. In the past I have used TexturePacker which has support for multiple resolutions. The way I do it is have all images in their highest resolution, then let TexturePacker downsample them to all other resolutions automatically. Works great with the automatic @2, @3 (etc) image scaling in Gideros. For tiled textures, which you can't use sprite sheets for, I use Sketch 3 (Mac only), which also lets you export multiple resolutions of one image.
    My Gideros games: www.totebo.com
  • antixantix Member
    @totebo So in the case of thousands of sprites, those are just sprites that are used by the game, but not all at once right? Are we talking about managing sprites outside the game, or inside the game?
  • @totebo: With so many sprites, I am sure you have some kind of file that stores the image name/path, maybe with other "gameobject" related values. There you could also store the name off the spritesheet.

    So, how do you assign/load all these images into the game?
  • @antix, the sprites won't all be used at the same time. It would be great to head what people have done both in terms of structuring them on disk, outside the game, and inside the Gideros project.

    @MikeHart, the reason there are so many sprites is that most of them are animated and loaded into MovieClips when needed. It's a isometric shooter with characters. Each character is defines by their respective states and each state has a MovieClip attached to it. Not sure if that answers your question. :)

    Likes: MikeHart

    My Gideros games: www.totebo.com
    +1 -1 (+1 / -0 )Share on Facebook
  • antixantix Member
    @totebo I think my solution would not work at all since you use MovieClip :(
  • It's all pretty dynamic, so could easily change MovieClip for something else.
    My Gideros games: www.totebo.com
  • antixantix Member
    @totebo - I have a system in mind where you have one big atlas which is a RenderTarget. You then load different sprite sheets at predetermined positions in the atlas and just use the atlas for all sprites.

    I would post something but when I was making an example project I came across what seems to be a bug in RenderTargets clear() function. I made a forum thread but none of the devs have replied yet. http://giderosmobile.com/forum/discussion/6386/rendertarget-bug#Item_1

    So my possible solution can't be posted really since it seems to be broken from inception :-O

    Oh, I sent you a PM about MinerZ too ~:>

    Likes: pie

    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited July 2023
    Here is my solution to an old issue :)
    I am making levels for a platformer game using Tiled. One level can be 10,000 pixels wide (height not so much ;) ).

    First try, I have all my images (around 2 hundreds) and was placing each image to make a nice level (flowers, trees, foreground, background, ...). The sprites could be rotated, scaled to add variety.
    --> the result is "terrible" with lot of stuttering (export to win32 and html5).

    Second try, I put all the images as to my liking then I export each layers to a single big image (see export to image in Tiled). My images are huge, for example the background layer is 15,356 pixel width and 512 pixel height :o
    --> the result is very good, there are no visible stutters (export to win32 and html5). One issue is it doesn't work on my android phone (the big image is black) but this could easily be solved imho (cutting the big images smaller). Another issue is the making of the levels becomes a little more tedious :|

    So instead of hundreds of small images, put them in 2 or 3 huge ones :)
    Demo: https://mokatunprod.itch.io/gideros-tests-02?secret=euQJ7rsKOuidLDk5uVBcjsb74

    Another possibility is using Shapes, they work very well and are very flexible but only suitable for appropriate art style.

    PS: I am not using Tiled tile layer but image layer.
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • MoKaLuxMoKaLux Member
    edited July 2023
    a level I put together, do you have access to the link? https://mokatunprod.itch.io/gideros-tests?secret=ht8e7uTPJgGUApRozoooCCEE

    PS: I switched from ECS to classic OOP and now I have 2 working projects :* (I thought ECS was the culprit :D ). I can post the code for both on GH let me know if you are into platformers
    PS2: ECS code is less advanced than OOP but the base is here
    PS3: on my low end android using tons of sprites doesn't cause any lags :o (some very good optimisations must be running behind the scene!)
    PS4: html5 runs better than win32 (a little bit of tearing occurs) :'(

    Likes: pie

    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
    +1 -1 (+1 / -0 )Share on Facebook
  • piepie Member
    it works!
    since it's the same game can you compare resource consumption? which one is "lighter"?

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
  • pie said:

    it works!
    since it's the same game can you compare resource consumption? which one is "lighter"?

    imho ECS vs OOP seem the same memory and fps wise?

    Many small sprites vs few big sprites: memory consumption is bigger with big sprites but at least I have no lags on html5.

    Likes: pie

    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
    +1 -1 (+1 / -0 )Share on Facebook
  • MoKaLuxMoKaLux Member
    edited March 18
    I had some bad lags when compiling for win32 and found a nice solution :)

    In my use case:
    - my background is originally 3096*544px
    - I cut it in 3 for eventual android builds: 3096/3 = 1024px
    - in code, I further cut each 3 images in tiles (around 64*64px) using TileMap Class
    - I then reassemble everything back together

    please see updated code below!

    So far so good, the lags have (completely?) gone on win32 builds, great success B)

    Viva Gideros!
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
  • piepie Member
    I don't get it: each of the 3 big images is cut in a set of completely different tiles and then reassembled?
    It still has to load the 3 tilesets as big as the "source images" and then compute on those. How can it be faster? Maybe it has a better handling of what happens outside the screen (it won't load one big image but only the tiles which appear inside the screen)?

    I wonder if this might work using rendertarget and avoiding all the cut/tile/reassemble
    :#
  • MoKaLuxMoKaLux Member
    pie said:

    Maybe it has a better handling of what happens outside the screen (it won't load one big image but only the tiles which appear inside the screen)?

    pie, I tried many many things to get smooth scrolling of my background on win32:
    - normal bitmap with the whole texture => win32 lags
    - cutting the image and using different bitmaps, lags
    - putting the texture/textures in Shapes, lags
    - using Tilemap, the best so far but some lags appear as well :'(
    - ...

    I believe Tilemap won't show tiles outside the screen as I have read somewhere on the forum.
    pie said:

    I wonder if this might work using rendertarget and avoiding all the cut/tile/reassemble
    :#

    I think I tried this one too but will try again.

    Every combinations work pretty fine on all deployed platform (Qt, html5, android), the lags are on win32 export. It may be my buggy windows11 with all the scheduling things happening, my graphics drivers not up to date, ...

    Here is the latest code:
    DrawLevelsTiled = Core.class(Sprite)
     
    function DrawLevelsTiled:init(xtexpaths, xposy)
    	-- tilemaps textures
    	local textures = {}
    	for i = 1, #xtexpaths do
    		textures[i] = Texture.new(xtexpaths[i], false)
    --		textures[i] = Texture.new(xtexpaths[i], false, { format=TextureBase.YA8}) -- best win32 perfs but b&w!
    --		textures[i] = Texture.new(xtexpaths[i], false, { format=TextureBase.RGBA4444})
    --		textures[i] = Texture.new(xtexpaths[i], false, { format=TextureBase.RGBA5551})
    	end
    	-- map size
    	local tilesizetarget = 64
    	local tilesetcols, tilesetrows = textures[1]:getWidth()/tilesizetarget, textures[1]:getHeight()/tilesizetarget
    	-- create the tilemaps
    	local function createTilemap(xtex)
    		local tm = TileMap.new(
    			tilesetcols, tilesetrows, -- map size in tiles
    			xtex, -- tileset texture
    			tilesizetarget, tilesizetarget -- tile size in pixel
    		)
    		-- build the map
    		for i=1,tilesetcols do
    			for j=1,tilesetrows do
    				tm:setTile(i, j, i, j)
    			end
    		end
    		return tm
    	end
    	-- the maps
    	for i = 1, #textures do
    		local map = createTilemap(textures[i])
    		map:setPosition(map:getWidth()*(i-1), xposy)
    		self:addChild(map)
    	end
    	-- params
    	self.mapwidth = self:getWidth()
    	-- clean
    	textures = {}
    end
    Usage:
    	self.drawbglevel = DrawLevelsTiled.new(
    		{
    			"gfx/levels/beu_lvl1b/untitled_0001.png",
    			"gfx/levels/beu_lvl1b/untitled_0002.png",
    			"gfx/levels/beu_lvl1b/untitled_0003.png",
    		}, 0*32)
    	local drawfglevel = DrawLevelsTiled.new(
    		{
    			"gfx/levels/beu_lvl1/beu_fg_lvl1_0001.png",
    			"gfx/levels/beu_lvl1/beu_fg_lvl1_0002.png",
    			"gfx/levels/beu_lvl1/beu_fg_lvl1_0003.png",
    		}, 12*32)
    -- ...
    	-- order
    	self:addChild(self.levellayer)
    	self.levellayer:addChild(self.drawbglevel)
    	self.levellayer:addChild(splatlayer)
    	self.levellayer:addChild(actionlayer)
    	self.levellayer:addChild(drawfglevel)
    my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
Sign In or Register to comment.