Using sprites to create a tiled background

Getting Started Newbie Questions
#1

I want to create a tiled background. I started with an image with 32 by 32 pixel tiles. Then created sprite sheet. I used a loop to create a 10 by 15 grid of sprites.

This seems to work. I have a couple questions.

  • Is this a good system?

  • How can i set the reference point of each sprite to the upper left corner?

Here’s the sample code I’m using.

-- Include sprite 
require "sprite"

-- name the image file containing your sprites, followed by the width and height of each sprite
local back\_sheet = sprite.newSpriteSheet("Scenery.png", 32, 32)

-- Create a set by naming the sheet and starting frame and number of frames
local back\_set = sprite.newSpriteSet( back\_sheet, 1, 24)

local i = 1
for row = 1, 10, 1 do 
 for col = 1, 15, 1 do 
 local n = math.random( 1, 24 )
 sprite.add( back\_set, "tile"..i, n, 1, 1000, -1 )
 local tile\_sprite = sprite.newSprite( back\_set )
 tile\_sprite.currentFrame = n
 tile\_sprite.x = (row-1)\*32
 tile\_sprite.y = (col-1)\*32
 i = i + 1 
 end 
end

[import]uid: 98652 topic_id: 19670 reply_id: 319670[/import]

#2

Hey there, RE reference point; http://developer.anscamobile.com/reference/index/objectsetreferencepoint

How is your memory usage looking currently?

Peach :slight_smile: [import]uid: 52491 topic_id: 19670 reply_id: 76128[/import]

#3

Thanks for the reply. I haven’t checked the memory usage. Seemed to work fine, of course I only ran this in the simulator so far. Is there a more efficient approach that I’m missing?

I’d really like to make this scroll. I’m trying to this together in my head. My plan at this point is to add all sprites to a group. move the whole group up. When the sprites in the top row get above the top of the stage move them below the bottom row and change the frame number to new frames showing the new tile images.

I’m also picturing adding a second layer or third layer of sprites to show back ground elements and foreground elements over laying the main scenery.

Here’s the code I have so far, slightly updated from the code above. Here I added an array describing the tiles that make up the map I want to display.

[lua]display.setStatusBar( display.HiddenStatusBar ) – hide the status bar

– Include sprite module
require “sprite”

local tile_size = 32 – set the tile size to 32
local tile_group = display.newGroup()
tile_group.x = tile_size / 2 – offset the group half the width of a tile so the tiles align with the upper left corner of the screen
tile_group.y = tile_size / 2

– name the image file containing your sprites, followed by the width and height of each sprite
local back_sheet = sprite.newSpriteSheet(“Scenery.png”, tile_size, tile_size )
– Define an array that describes the tiles used to create the scene.
local tile_array = {20,10,10,10,10,10,10,18,16,18,
20,19,19,19,19,19,19,17,17,20,
23,19,19,19,19,19,19,19,19,20,
20,19,1,1,1,1,1,1,1,20,
20,19,1,32,33,36,34,32,1,20,
20,18,1,24,33,35,34,24,1,20,
23,15,17,31,33,35,34,31,15,20,
27,26,26,26,26,26,26,26,26,28,
29,14,10,13,14,13,13,14,10,30,
29,13,12,9,13,13,12,11,10,30,
29,11,10,10,11,12,13,14,9,30,
26,26,26,26,26,26,26,26,26,26,
14,14,14,14,14,14,14,14,14,14,
21,21,21,21,21,21,21,21,21,21,
22,22,22,22,22,22,22,22,22,22}
– Create a set by naming the sheet and starting frame and number of frames
local back_set = sprite.newSpriteSet( back_sheet, 1, 36)

local count = 1 – use this to count the tiles created
for col = 1, 15, 1 do
for row = 1, 10, 1 do
sprite.add( back_set, “tile”…count, 1, 1, 1000, -1 )
local tile_sprite = sprite.newSprite( back_set )
tile_sprite.currentFrame = tile_array[count]
tile_sprite.x = ( (row-1)*tile_size )
tile_sprite.y = ( (col-1)*tile_size )
tile_group:insert( tile_sprite ) – add tile sprite to tile group
count = count + 1
end
end[/lua] [import]uid: 98652 topic_id: 19670 reply_id: 76138[/import]

#4

What you are describing actually sounds like the kind of thing that could really benefit from the third party tool Lime. Are you familiar with Lime?

I’d encourage you to check memory usage just to see where you are currently at before planning any other layers.

Do you know how to check this? If not let me know and I’ll grab a quick function for you.

Peach :slight_smile: [import]uid: 52491 topic_id: 19670 reply_id: 76151[/import]

#5

I’ve looked Lime. I’m planning on teaching class, and feel I can’t expect students to buy it and school doesn’t really want to buy it to support a single assignment.

I’m guessing that Lime is doing what I’m doing. Of course Lime is also streamlining the whole process. If students want to continue with Corona they can buy Lime for them selves. I’ll probably mention Lime when we get into sprites and tiles.

I’d be interested in looking at memory usage code snippet. Please post it, it sounds useful. [import]uid: 98652 topic_id: 19670 reply_id: 76155[/import]

#6

I’m doing something similar to the above, but I have a static array of about 7000 sprites, and it seems to work fine on the iPad.
I’m not moving the sprites: just changing the currentFrame

I’d be interested in the memory aspect too.
I already added a texture memory line of code so that I could watch for memory leaks. (Now very stable)

But I’d like to know how much memory used is ‘too much’ memory used, if that even makes sense.

Texture memory showing at about 5000 currently.
(I assume that’s 5Mb…)
[import]uid: 108660 topic_id: 19670 reply_id: 76158[/import]

#7

I had an iPad (1) crash only when trying to use over 100MB of texture memory. Of course the app was receiving memory warnings long before that, but still it ran. An iPhone 3GS only started crashing at about 80MB. Android is much more constrained in terms of memory usage due to the Java VM. If you don’t go over 24MB it will probably run fine in the majority of the compatible devices.
Program memory on the other hand is much more limited. Usually shouldn’t go over 1,5MB or you are really going to face serious slowdowns and possibly some instability as well. [import]uid: 61899 topic_id: 19670 reply_id: 76172[/import]

#8

The example code I posted above using the tile image here: http://www.webdevils.com/2011/12/27/pixel-art-background-tiles/ seems to be using 0.278528 mb which seems very reasonable.

I want to add a new layer and see what happens.

I figure if I add a row above and a row below for 20 more sprites. As long as motion doesn’t exceed the height of a tile I can move the top or bottom row of tiles to the opposite side to create a continual scrolling effect.

Then again maybe this is overly complicated. Might be easier to just make one large tiled group of sprites. Figuring that this block of 150 sprites is taking up a about a 0.28 MB making three more like will bring the memory to something just over a 1 MB.
[import]uid: 98652 topic_id: 19670 reply_id: 76237[/import]

#9

Wow that was a great experiment. I’m using the fps module from the sample code library.

Seems that when I increase the number of sprites, all using the same sprite sheet, to increase the number of rows from 15 to 60 the memory doesn’t change. Even when I up the number to 90 rows the memory stays at 0.278.

Must be that the sprite engine is making an image that is the size of the screen using the tiles. Rather than making a larger image. I’m guessing that the sprite system composites all of the sprites into an area the size of the screen and doesn’t draw things that fall outside.

I might doing something wrong here someone point out any problems you see please.

[import]uid: 98652 topic_id: 19670 reply_id: 76239[/import]

#10

>>Seems that when I increase the number of sprites, all using the same sprite sheet, to increase the number of rows from 15 to 60 the memory doesn’t change. Even when I up the number to 90 rows the memory stays at 0.278.

Must be that the sprite engine is making an image that is the size of the screen using the tiles.<<

Theory:
The screen memory is always there because the screen never goes away.
The tile sheet has to be read into memory, once.

But the sprites?
A a raw level, they are ‘just’ copies of bits of the tile map, changing parts of the screen display.
So once copied, a sprite need not take any more memory.

The sprite itself needs to know where it is, what frame number it is to use, and a bunch of other stuff, but thats a data structure/class of not very much memory at all.
SO your experiment backs that up: you don’t need a new screenful of memory and a new pictureful of textures, if the sprite library is just copying bits from A to B.

(But if it is, I’d like to access the blitting functionality)
[import]uid: 108660 topic_id: 19670 reply_id: 76244[/import]

#11

it makes sense that the texture memory is reused. So all of the sprites that make use of the same sprite sheet image don’t really take up much memory by themselves. It’s the actual sprite sheet that takes up text memory.

The sprite class and Corona are probably just drawing the visible sprites to the screen buffer, which uses a fixed block of memory.

Will have to experiment some more and see what happens.

on a side note. I have been making sprites with Spritesomething on my iPad. It outputs CSV of the tiles maps. Basically it emails you the images and a text block of comma separated numbers corresponding describing the tiles that make up the map. I just copy and paste this between the {} and you have an array describing your tile map. [import]uid: 98652 topic_id: 19670 reply_id: 76311[/import]