How to structure bitmap heavy games

totebo

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

antix

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.

MikeHart

@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?

simwhi

@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.

antix

@simwhi true, I haven't got to adding multiple resolution files yet argh.

totebo

@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.

antix

@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?

MikeHart

@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?

totebo

@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.

antix

@totebo I think my solution would not work at all since you use MovieClip

totebo

It's all pretty dynamic, so could easily change MovieClip for something else.

antix

@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 ~:>

MoKaLux

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
--> 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.

MoKaLux

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 ). 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 (some very good optimisations must be running behind the scene!)
PS4: html5 runs better than win32 (a little bit of tearing occurs)

pie

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

MoKaLux

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.

MoKaLux

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

Viva Gideros!

pie

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

MoKaLux

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)