SpriteGrabber class -SpriteSheets in 2 lines

SpriteGrabber is now in Code Section

FEATURES:

*Mix sprites of different characters, different movements and/or various stationary images in a single SpriteSheet and call them by common image-name prefix (e.g. "hero-", "background", "enemy3attack").

*Rapidly grab and display sprites in 1 line of code - e.g. hero=sprites.getSprite("hero", true)

*Conveniently register a sprite's animation clips - e.g. enemy=sprites.getSprite("enemy", true, {stand={1,6,1000,0}, attack={7,6,1000,1}})

*Play a named clip without preparing it - e.g. enemy:playClip("attack")

*Normally use all spriteInstance SDK-supported functions - e.g. enemy:pause()/play()

*Start/Stop rendering or transform a given sprite in 1 line of code - e.g. enemy:hide() , enemy:show() , enemy:show(100,100,0.5,"c")

I downloaded your module and tried to use it but I'm getting a weird error:

grabber = require("SpriteGrabber")
local chars = grabber.grabSheet("sprites/chars")
local hero = chars.grabSprite("hero", true)

Runtime error
        /test/SpriteGrabber.lua:192: bad argument #1 to 'len' (string expected, got boolean)
stack traceback:
        [C]: ?
        [C]: in function 'len'
        /test/SpriteGrabber.lua:192: in function 'grabSprite

@ZeStuff

What "sprites/chars" stands for? Is it a path tree.. ?
The function grabSheet(string) waits for the name of the image that is your spritesheet (e.g. the "uma.png" file that contains a series of images). Specifically the string should be given without the extension (e.g. grabSheet("uma") )

The second string ("hero" in your code) should be a part of the name you use for some images which show movements of the same character. For example, if you have :

charJump1.png
...
charJump16.png

charRun1.png
...
charRun16.png

the common image-name preffix here is "char" for all movements (frame sets). So your code would be:

1
2
3

grabber = require("SpriteGrabber")
local characters = grabber.grabSheet("myCharsSpriteSheet")
local herochar = characters.grabSprite("char", true)

sprite/icons is because I was using subfolders. I removed that.

hero refers to hero.png in my spriteSheet. It's a single sprite with no other image related to it.

@ZeStuff

The SpriteSheet.png (or whatever named) + the SpriteSheet.lua files have to be where your main.lua file is. Not in other directories. You can have your images anywhere in your disk. This is how Corona works...

So, having the SpriteSheet.png/lua files in your main.lua directory, and supposing you have a "hero" frame injected in your SpriteSheet.png, you would write:

1 2	local sheet = grabber.grabSheet("SpriteSheet") local hero = sheet.grabSprite("hero", true)

I stripped it to the bare minimum and I still can't get it to work.

main.lua

grabber = require("SpriteGrabber")
 
local sheet = grabber.grabSheet("icons")
local hero = sheet.grabSprite("hero", true)

I can reproduce this error by changing the code to this:

1
2
3

grabber = require("SpriteGrabber") 
local sheet = grabber.grabSheet("icons")
local hero = sheet.grabSprite(true, true)

That's the thing. I recreated the module myself (just a few functions) and I get the same problem.

I'm starting to think my environment is fubar. Yay. :\

Wow ok.

I reformatted my MacPro, reinstalled Corona before anything else and re-ran my code.

Got this:

/test/SpriteGrabber.lua:192: bad argument #1 to 'len' (string expected, got boolean)
stack traceback:

So yeah... I have no idea why it just won't work for me :\. I'm running Corona 2010.109 by the way.

@ZeStuff, lets be optimistic, at least you brought some order to the OS. Now, lets continue with the network. Maybe you should change connection provider! ;p
I really can't translate the debugging output you get. It just doesn't make sense to me. I would only understand this, if you had a declaration hero = some-conditional within your main, before calling SpriteGrabber. But if you have only the above 3 lines in your main, then I can't help... sorry.

Nobody else uses SpriteSheets in these forums?

Is everything OK with SpriteGrabber, for you?

@ZeStuff

Let's try something else:

1) Make a new folder in your desktop and name it "horse".

2) Open your Corona GE 109 installation directory, go to /SampleCode/HorseAnimation/ and copy these two files: a) uma.png b) uma.lua

3) Paste the two uma files inside your "horse" folder. Also, open your Text Editor, make a new file "main.lua" and save it (empty) inside the "horse" folder too.

4) Open SpriteGrabber from the code section and copy paste the module code inside a new text file. Then save it as "SpriteGrabber.lua" inside your "horse" folder.

5) In your main.lua file, copy and paste this:

local grabber = require("SpriteGrabber")
 
local umaSheet=grabber.grabSheet("uma")
local horse=umaSheet:grabSprite("",true,{runSlow={1,8,1000,0},runQuick={1,8,300,0}})
 
horse:playClip("runSlow")

That worked. I was also able to use local horse=umaSheet:grabSprite("01.png",true).

I replaced uma.lua with my spritesheet (generated with zwoptex) and got the same line 197 error. I started to think that somehow, the problem could lie in my sheet so I redid it using TexturePacker and.. it worked!

I have no idea why it wasn't working before or why it generated such a weird error message but I finally figured it out. Thank you so much! :) I guess I know which sprite software I'll be buying ;).

@ZeStuff

I am glad you managed to make it work for you!

1)
You don't have to (actually, you are not supposed to) give the whole png name for a sprite!
Supposing you wanted to display just the third frame of uma as a static character you can use "03" (since it is named "03") as the image-name preffix:

1	horse=umaSheet:grabSprite("03",true)

You don't have to (actually, you are not supposed to) give the whole png name for a sprite!

I know. I was just copy pasting some stuff and forgot to remove the extension.

Actually, sprite:play() just resumes the last playing clip that was paused, but since here we haven't started playing anything yet it resumes playing the whole animation at default speed.

Actually, my sheets don't have animations. They are just tiles either for maps or units.

I don't see any problems with the output that the trial license of Zwoptex gives. I am using the default publish settings and have just selected "Corona Game Edition" for the Coordinates format. Actually, I guess that the uma spritesheet itself was made with Zwoptex.

My spritesheet lua file had 295 records in it. I'm not sure why it didn't work. I will probably do a diff of both data files today or tomorrow out of curiosity.

Thanks again for everything.

Hi Magenda,

Just got back into Corona after an unavoidable lay off from my dev work and SpriteGrabber looks great. I can see how it works and have studied the 'horse' example. I must be missing a step somewhere though as I haven't managed to set up a sprite animation using my own exported sprite sheet from Texture Packer (T.P).
I've never used it, or Zwoptex before so can you clarify the process for me. After the sprites are loaded and sorted in T.P I 'Publish' them to my project folder ? And both the image and data file should be published, and both named the same, but with correct extensions (.png and .lua).] ?

I've tried a few times and I get a blank screen. I'm using the mentioned-above Horse example code, modified to take my own 2 files. Any ideas ?

@delta

For publishing spritesheets with TexturePacker take a look at:
http://developer.anscamobile.com/forum/2010/10/18/spritesheet-data-file-explained#comment-8752

The workflow for using SpriteGrabber goes like this:

1) You draw your images and save them in a folder "images". The images can be some animation frames with a number suffix after the sprites starting name (e.g. hero01.png ... hero16.png) or several single-framed stationary graphics (e.g. button2.png, snow.png, background1.png).

2) You then open terminal, write "cd " and drag and drop the folder *above* "images" folder (its parent folder). Press enter, so your terminal path is now the parent folder.

3) Follow the syntax of TP from the link above and write something like this:
TexturePacker images/*.png --format corona --max-size 1024
This will take just the images with png extension (replace *.png with *.* to include all image files). TP will make two files with default names: out.png and lua.png inside the parent folder of "images" (the terminal path from which you run the TP command).

4) Take those two files and place them inside the folder where your main.lua resides.

5) Inside your main.lua require SpriteGrabber and call its functions to show the sprites. Ask for the sprites with the image names you have inside your "images" folder (without extensions). Supposing you have an image "hero.png" you should write something like this to show the sprite on screen:

1
2
3

grabber = require("SpriteGrabber") 
local out = grabber.grabSheet("out")
local hero = out.grabSprite("hero", true)

Thanks for that. I was using the GUI on TexturePacker and all seemed ok... though I may have muddled up the part where you ask for the actual names of the image files that have been packed. I shall try again and try not to speed-read in my haste to learn.....

Thanks.

Yes, the whole concept of SpriteGrabber is to easily bring sprites on screen, from a spritesheet that holds *several* sprites, without continuously referencing spritesheet.lua for the exact table position of each sprite's frames.

You just tell SpriteGrabber the string you have used as a root-name for your sprite's frame-images and all the rest is done automatically.

Moreover, you can register all your spite's animations, with 1 line of code instead of building and adding separate datasets one by one.

Don't hesitate to ask for any additional help...

Hi Magenda,

This query isn't directly related to SpriteGrabber but I'd appreciate any help. Being able to call up any image frame by it's name is great and I was wondering if this could be applied to my experimental code.
I'd like to take an integer value and use that as the image name. Say for example I have 5 images named simply 1,2,3,4 and 5 in a SpriteSheet. I then have an object that is placed at X position of 1, and is then randomly placed at a position between 1 and 5. Can this objects X position value (i.e 3) be converted to a string ( called "3" ) and that string/name then used in defining the image name for the object, something like...

testObject=testSheet:grabSprite("3",true)

Hopefully I've explained it clearly. I can see how SpriteGrabber coud do this but I'm insure on the conversion of the integer to a string.

I came across the Tostring() and String.Format() commands, this could achieve the above ? If so, is one more suitable than the other ?

@delta

I am trying to fully understand what you exactly mean. Why not, for example, just register the frames as individual clips of 1 frame and also make a table "iClip" that gives a clip name for a specific integer (the index number of the table).

1
2
3

framsheet=grabber.grabSheet("myFrames")
sprite=frameSheet.grabSprite("",true, { clip1={1,1,1000,1}, ... clip5={5,1,1000,1} } )
iClip={"clip1", "clip2" ... "clip5"}

Yes, I probably overcooked the example a bit there. I just need a way to turn an integer value into a text version, be it an X coordinate or whatever. To that end, would an integer converted to a string, as in my last message, be usable as the image file name ?
(I'm not able to get on Corona right now to test this)

Ok...

From the Lua manual: http://www.lua.org/manual/5.1/manual.html
"Lua provides automatic conversion between string and number values at run time. Any arithmetic operation applied to a string tries to convert this string to a number, following the usual conversion rules. Conversely, whenever a number is used where a string is expected, the number is converted to a string, in a reasonable format."

So, the following, for example, runs like a charm:

1
2
3

        umaSheet=grabber.grabSheet("uma")
        uma=umaSheet:grabSprite("",true,{[1]={1,8,1000,0}})  
        uma:playClip(1)

That sounds promising. I've used a similar system in other dev programs but often had to concatenate the output, which I really wanted to avoid. I really need to get this coded in Corona to see it in action but it sounds like it should do what I'm after.

Thanks for the input, and SpriteGrabber of course,

[ ref: http://developer.anscamobile.com/forum/2010/11/11/sprite-sheet-returning-incorrect-physics-body-dimensions ]

hey magenda,

this is great!

the trouble i'm having is my physics addBody thinks the square sprites are all the same size from what I can tell. I'm not sure how i need to get this info or whether it's a corona bug because it's not coming from a single image. they all come back as 60x60. I am using texture packer to pack differently shaped sprites

this may be because somewhere in my spritesheet i have one "crate.png" that is 60x60. i also have a "crateA.png" that is 90x90 and a "createB.png' that is 53x30. The rest of my sprites aren't called "crate...."

thanks for any advice

I think it's a corona bug not a spritegrabber bug

regards
j

@jmp909

It doesn't sound like a bug. Could you please post the code you use to make a sprite and add it as physics object?

(I follow the other topic too, so feel free to answer wherever you want)

it's just the normal code

1	local spriteSet = sprite.newSpriteSet(mySpriteSheet,1,1)

@jmp909

You can extract a single framed sprite (even if the frame is part of an animation sequence) like this:

1 2	mySheet=grabber.grabSheet("uma") hero=mySheet:grabSprite("03",true,{openlegs={1,1,1,1} })

what we could do is parse the lua file and override the physics shape with the relevant height and width. this works when i use a custom radius/polygon for a sprite, so i just need to make a function to get the data from the spritesheet.lua file

you could actually add this to your SpriteGrabber class presumably.

then attach eg a sgRect table dynamically to returnSprite

1 2	returnSprite.sgRect = self:getSpriteGrabberRectangle(returnSprite) return returnSprite

I've embedded jmp909's suggestion into SpriteGrabber. You can download it again from Code Section.

WHAT IS NEW: Having a single-framed sprite, you can call sprite:getShape() to get what physics:addBody() is waiting as a "shape", to override the sprites dimensions.

WHY USE sprite:getShape() ?
Because there is bug in SDK regarding sprites' dimensions, which falsifies the resulting dimensions of a physics enabled sprite. With this method, you override the SDK returned dimensions and get the actual ones from the spritesheet.lua file, which you then give to physics.addBody() to apropriatelly make the physics object.

REQUIREMENT: The sprite has to be single-framed for the getShape() function to be created. Otherwise, it has no real meaning to get the "shape" of a multi-framed animation series (in which the individual frames can be of different sizes).

CAVEATS:
1) When scaling the sprite the shape doesn't get in sync.
2) There is an offset of some pixels which I suspect is affected by this other bug. Probably, the the reference point of the sprite is always that of the second frame in the spritesheet, and because of this the shape is not placed precisely (sometimes it gets significantly shifted). Not sure yet...

EXAMPLE:

grabber=require("SpriteGrabber")
mySheet=grabber.grabSheet("uma")
horse=mySheet:grabSprite("05",true)
 
physics = require "physics"
physics.start()
physics.setGravity(0,0)
physics.setDrawMode( "hybrid" )  --so you can see the shape outline
physics.addBody( horse, { density = 1.0, friction = 0.3, bounce = 0.2, shape=horse:getShape() } )

great, this worked for me...

im my Actor class

1 2	sprite = mySheet:grabSprite(img,true) sprite.parsedShape = sprite:getShape()

Hi,
I am using TexturePacker along with SpriteGrabber, what the guide didn't tell me was that this line:

local hero=mainSprites:grabSprite("hero",true,{ breath={1,8,1000,0}, jump={9,8,700,1}})

assumes the texturepacker spritesheet is in order, which is not always the case, you might have to reorder the data sprite sheet

@newbie101

I actually had in mind to write this to the guide but then I saw that if you leave TexturePacker / Zwoptex with the default settings both of them have the data alphabetically ordered and there is no real reason to order them otherwise. Am I wrong to this? What setting caused the different order in TP for you?

I did basic settings, I think the order is random, I tried generating other sprites and sometimes the order would be correct so I talked to the creator of TexturePacker, and he said the new texturepacker 2.1.0 will have an option to order the spritedata based on the file name, e.q: "Basic" + SortBy "Name" + "Order Ascending" so I guess 2.0 is not actually ordered? or it is naturally ordered (the order of file being processed)

I currently have TexturePacker version 2.00 rc3 installed and it works fine without any settings for ordering (same for Zwoptex). I am going to install the new version and report back the results.

Hi,

I updated TexturePacker which should now work perfectly with SpriteGrabber. Please report back any problems you find.

You can now create textures up to 2048x2048 in basic layout mode for free. It also supports creation of non power of 2 textures in PNG format. So if you have an animation with 10 23x43 sprites it'll set them up in 230x43.

You can order the sprites by name, size and others.

There are several other features but I think these are the major ones for corona.

Cheers
Andreas

Some SpriteGrabber news...

There is a SpriteGrabber v1.2 currently released in code section, which supports "on the fly blurriness elimination" (aka: always get crisp sprites, even if you have odd image dimension for width/height), after an idea of Amigoni. I still haven't documented this and 2 other features already implemented in v1.2, so I apologize for this...

I am also thinking of releasing a v1.3 update that implements a super duper (yeah!) core feature, but I would like some feedback about whether you find it a good or ...messy idea.

The new feature, which actually I already have implemented and I am currently beta-testing it in my own game, is called "Adaptive Layout". In its essence it incarnates the "Desired Scenario" as I have described it here (with extra improvements, optional HD versions, any number of versions and full automation), which allows Universal-ready builds for games with spritesheets.

In a nutshell, Adaptive Layout is an alternative to Ansca's "Dynamic Content Scaling", and requires/supports "relative positioning" of sprites, which IMHO is the only real solution to get trully Universal-ready builds.

Adaptive Layout:

1) Detects the device resolution the game is running on.

2) Dynamically loads a provided spritesheet version (normal, HD, etc) which best fits the device, even if you have provided only 1-2 versions but there are dozens of possible device resolutions that don't exactly fit your provided assets. It then makes corrective scaling to get sprites appearing the same on eye to any device resolution.

In other words, you make a High Definition version for your spritesheets, autoscale them down with a tool like TexturePacker to get a "normal" version and with them you are ready to go for any current/future iDevices and the dozens of Android devices, without caring about the involved resolutions.

3) It requires "relative positioning" of sprites, which may seem an extra step but to my opinion is a best practice if you trully want to be to be Universal-ready, not only for 2-3 devices but for any current and future ones, regardless their width/height ratio (which makes Ansca's "Dynamic Content Scaling" prune to blank stripes that break real "universability" on many devices, like iPad and Galaxy).

4) It supports quick and easy relative positioning: instead of writing mysprite.x=240 (yuck!) you write mysprite.x=px(50) ...meaning x=50% of the device width resolution. It doesn't get easier/healthier !

I am also thinking of releasing this feature as an optional one, that when deactivated will provide automatic support for Scenario 3 (which is explained here and in the next 3-4 posts) that is based on Ansca's Dynamic Content Scaling. Again it will be provided as a fully automated solution with the appropriate handling to be ready to work for spritesheets.

***

Now, help me on this: are you ready to invest on relative positioning (on sprites creation) to get perfect universability once and forever, or do you find "Adaptive Layout" as something messy and outside of SpriteGrabber scope? I am trying to understand whether Adaptive Layout would make SriteGrabber an awesome module or it would totally mess things up regarding the already hard to understand "Proper Scaling" thing in our beloved Corona SDK.

Feedback is much appreciated...

Regards

Does this introduce additional requirements from my side (TexturePacker)? Or is all you need already available for that?

@Andreas

Adaptive Layout already works nicely with TexturePacker, which is a lifesaver with its "Auto SD" feature!

Thanks for the high quality support you provide to the Corona community.

Let me put my 2 cents in,

I think it's a good feature, but you are solving a problem that corona should be solving.

Corona might in the future have an automated solution for publishing to more devices with less configuration for each, I am not sure how your solution would work into that. However, if you get every corona user to use your library, which is easy if it's noob friendly, I can see you having the upper hand.

My suggestion: Release 2 versions? Basic and Advanced, there are developers who specifically target certain devices. There are also developers who want to cover as many devices as possible, having 2 options will enable them to pick and choose. Should corona solve what you are solving in Advanced, people can still use SpriteGrabber basic as it is currently being used.

Also, I might be wrong in this but isn't positioning in corona already relative? I use object.x = constants in my current game, I use the simulator's view as=> ipad, iphone, etc the position still works fine, am I missing something? Is px(coordinate) a function from SpriteGrabber?

EDIT: added my suggestion.

@newbie101

Your feedback is always welcome.

I tend to believe that people here don't even use spritesheets, because of the involved additional steps for preparing the spritesheets. So, it may be somewhat romantic to promote a "best practice" for universal scaling that not only *requires* everything to be in spritesheets, but also dictates every coordinate to be given as a percentage. Maybe it's the healthiest thing in the world, but in the end Corona is more or less a middleware for people that prefer convenience (easiness) over flexibility (including myself to an extent).

Now, regarding your question, positioning is *absolute* in Corona (by default). To see how this lacks universability try the following:

Place a sprite/image/shape at coordinates (480,320), which stands for bottom right on landscape, while working with the iPhone Simulator. You now have two options for getting your sprite showing on the iPad simulator...

You either setup your config.lua to include (width=480, height=320, scaling="letterbox") for activating Ansca's "Dynamic Content Scaling" and you get a properly sized sprite BUT displayed NEAR bottom right, because iPad has a different ratio to that of iPhone

You delete config.lua (deactivating Dynamic Content Scaling) and then you correct the coordinate *by hand* to (1024,768) and you get your sprite at the proper position (bottom right of the screen) on iPad BUT you also get it half sized because of the double+ resolution that iPad has over iPhone (while your image stays the same).

Now can you see where "Relative Positioning" (percentages instead of absolute coordinates) can help? You don't want to make a different build (correct coordinates) for each set of devices that have a different ratio (width/height). You only want 1 Universal build !

The solution I propose ("Adaptive Layout"), uses relative positioning to correctly place things on screen and alongside it detects the device and selectively loads the most appropriate version of your provided spritesheets to maintain same sprite sizes among ANY devices. It also corrects the absence of suited versions by scaling sprites up/down, so that you always get a sprite with a size of the same screen proportion.

I know, I am stupid, but I don't get it.

I did everything I'm supposed to do.

I have only ONE animation in my sprite. A coin is spinning.

How do I get it onto the screen and let it spin?

There is a description for sprite sheets with multiple animations, which I can't use at the moment.

I get my coin to the screen, but it is not spinning, so I do something wrong, but I don't know, how to write the code for a SINGLE animation.

Can somebody make my stupidity away, please?

Hi Hunnenkoenig,

Have you read the examples in SpriteGrabber module page?
You can also see a very quick example in the first post of this thread.

If you still have issues plz post your code here so we could help you.

I have no code, because I messed around already so much, I don't know anymore, what worked and what not.

The simplest I can find anywhere is this (from the OP),but this is an animation with two sequences. I have no two sequences.

enemy=sprites.getSprite("enemy", true, {stand={1,6,1000,0}, attack={7,6,1000,1}})

I think, I understand the sample codes if I have more sequences and more animations on one sheet, but I can't figure out, how to do this for only one animation on one sheet.

I have a coin.lua
There are 11 png files registered in it: coin1.png - coin11.png

I have a sprite sheet named coin.

So, what is the code to get this onto my screen and animate, please?
Because the above code doesn't work, because there are attack and stand in it and I don't know, what to remove, because no matter how I alter this, I get all kind of error messages.

All the samples on the code exchange page are useless for me too, because all of them do things, I don't want to do.

For me it seems, in corona everything has to be as complicated as possible.

Nobody can write examples with the simplest things. Everything is bloated with super duper extra stuff, so a newb can get lost in the first second for sure. Frustrating :-P

EDIT:

I messed around a bit today again and I still don't get it.
Here is the code, which gets the coin onto the screen, but doesn't animate.

local coinSprites=grabber.grabSheet("coin")
 
 
local coin=coinSprites:grabSprite("coin", true, {1,11,100,0})

If you have difficulties to understand how to code in Corona, be sure that you will find the other choices much more complicated. For example, take a look to what you have to master just for bringing in life a simple animation in Cocos2d (which is considered as the "easy" Objective-C way).

http://www.raywenderlich.com/1271/how-to-use-animations-and-sprite-sheets-in-cocos2d

In your code, replace getSheet and getSprite with grabSheet and grabSprite. (hm.. I see you already found it).

To place sprites on screen use :
spritename:show(150,200)

Physics have nothing to do with SpriteGrabber. Just be sure to have all your sprite frames in fixed (same) dimensions to eliminate artifacts and other known problems. To have fixed dimensions, don't check the "trim" option in TexturePacker/Zwoptex.

Thanks!

I could manage it already :-)

That cocos2d stuff is crazy :-P

I'm new here and my first attempt using sprites went perfectly using your helper code! Thanks a million!
The support within the Corona community is simply amazing.

@noahm26

Yes, Corona community is constantly growing and has many members that love to share useful things. I also use code snippets from other guys and their work have saved me much time. Among them is Color-to-RGB, FPS module, Director, EasingX...

Sharing is a win-win situation :)

A last thing, I need a little help with:

How do I rearrange the animations on layers?

It seems, my coin animation is on top of the screen above my player, but I want the coin being behind my player.

Even if I place the coin code before my player code in the lua file, the coin will be drawn over my player.

EDIT:
Got it, thanks!
I inserted my animation to the localGroup, what I didn't do before....silly me...

@Hunnenkoenig

What really matters is the precedence you follow when inserting your objects to a group.

The objects are firstly auto-inserted in a default "screen" group on creation, so if you don't use a custom group there is also some importance in the precedence of objects creation.

You may want to read a mini tutorial I once wrote about properly using Groups in Corona:

http://developer.anscamobile.com/forum/2010/10/03/mini-code-tutorial-groups

Again, if you still have issues publish your code here for the rest to take a look.

PS: You may also want to check the new API methods: object:toFront() , object:toBack()
http://developer.anscamobile.com/reference/index/objecttofront

Thanks for the links!

views:2573 update：2011/10/17 8:58:49


Label: corona android iphone ipad building error inmobi problem display screen View image tableView failed object physics touch button game lua config event listener