Help with display objects

Solar2D General Questions/Discussion
#1

I’m trying to write routine that saves a game on application exit and I’ve been stymied by a problem I’ve had with display groups and objects.

I have game graphics defined thus:
[lua]enemy =
{
{ image=“block1.png”, x=20, y=40, yv=yv1, lock=0, val=0, mult=1}
{ image=“block1.png”, x=20, y=40, yv=yv1, lock=0, val=0, mult=1}
– etc
}[/lua]

The enemy table has been inserted into a display group, enemyList:

[lua]local obj = display.newImage(enemy[enemyID].image, enemy[enemyID].x, enemy[enemyID].y)
obj.yv = enemy[enemyID].yv
obj.lock = enemy[enemyID].lock
obj.val = enemy[enemyID].val
obj.mult = enemy[enemyID].mult
obj:addEventListener( “touch”, onTouch )
obj.isVisible = false
enemyList:insert(obj)[/lua]

When I try to save these variables to a file thus…

[lua] dataTable.x1 = enemyList[1].x
dataTable.y1 = enemyList[1].y
dataTable.yv1 = enemyList[1].yv
dataTable.lock1 = enemyList[1].lock
dataTable.mult1 = enemyList[1].mult
dataTable.val1 = enemyList[1].val
dataTable.image1 = enemyList[1].image[/lua]

…everything saves fine, except the last line. enemyList[1].image is nil and I can’t figure out the proper way to read the name of the image file (which may end up as block2.png or something else) used to make the display object.

Is it a scope problem, in that I can’t use a local variable like obj to insert the image and instead have to use a consistent variable throughout the file to make the reference consistent?

Thanks.
[import]uid: 1560 topic_id: 2603 reply_id: 302603[/import]

#2

You may have to do something like this:
http://developer.anscamobile.com/content/application-programming-guide-graphics-and-drawing#Object_References [import]uid: 8194 topic_id: 2603 reply_id: 7397[/import]

#3

The problem is “enemyList[1].image” doesn’t point to anything. You have “image” defined in a lua table but not in the object itself. If you need access to the image file name, you have to store it with the display object.

You can add the image name as a custom property of the display object:

obj.image = enemy[enemyID].image [import]uid: 7559 topic_id: 2603 reply_id: 7398[/import]

#4

Cool, thanks. [import]uid: 1560 topic_id: 2603 reply_id: 7407[/import]

#5

It would be great if Ansca would provide a more extensive set of standard properties that we can use to retrieve this kind of info instead of all of us inventing our own custom properties to do the same thing…

I have the exact same requirement to save an app’s state and having to define my own custom properties.

Another great example is setFillColors()… I haven’t seen any standard way of retrieving those either.

Or the set of body properties… or the type of display object… or displayCircle radius…

All that state must have been kept internally of those objects - please make them available as well-defined standard properties.

-Frank.
[import]uid: 8093 topic_id: 2603 reply_id: 7410[/import]

#6

@FrankS,

The problem with making everything available means the information must be stored and made available in a standard form. Since every implementation is different that could be a lot of stuff. You have the ability to store whatever you need in the DisplayObject so it can be accessed later. I don’t think many programs require the color of the object or the filename of the image. For the times when they’re needed, you can easily add the properties to the display objects.

-Tom [import]uid: 7559 topic_id: 2603 reply_id: 7437[/import]

#7

Sorry Tom, but I disagree.

Corona provides many “setter” functions for its objects but not all have the equivalent “getters”.

For the assigned colors, I can think of many examples where you would like to know the currently assigned color of an object: cloning, preference setting, persistence, introspection…

If you are forced to maintain the set colors with your own properties, you always run the risk of getting out of sync as setFillColors() can be called from any part of your program. It also makes it more difficult to reuse libraries and snippets. Without any standard naming, it’s also more difficult to reuse other people’s code.
In general it is not a good idea having to maintain copies of state in order to get to the current state… error prone and can introduce nasty bugs not to work of the master copy.

The fact is that Corona already keeps the color settings… it is just not exposed. It’s also easy for you guys to expose those kind of getter-functions, because it doesn’t effect the internal code which makes QA easier.

Right now “we” have to go to the following process when we require the current color settings: search thru the docs to find any color-getter function - not finding it - not understanding why it has not been exposed - searching the forums for that functionality - not finding it - wondering why it is not exposed - not understanding it - deciding to maintain the color settings in custom defined properties - realizing that others may already have done the same thing - realizing that it is easy to get out of sync - trying to come up with a good naming convention -contemplating if it’s worthwhile to overload the setFillColor() to prevent out-of-sync - wondering again why the @#$%^ this is not provided by the toolkit…

You can substitute setFillColor() with a number of other state setting functions…

I can fully understand the push-back to expose “everything” and that feature creep is a valid concern - however, you guys are not writing an end-user application but a toolkit where the required features are determined by our imagination and creativity - please give us those low-hanging fruit getter-function.

-Frank.
[import]uid: 8093 topic_id: 2603 reply_id: 7494[/import]

#8

Frank,

I totally understand the need but you must realize that we have a ton of request for features that currently have no work-around solution. Each feature we implement must be designed, implemented, tested and documented. We have a limited number of developer, so we try to balance the work between bug fixes and the most popular requests, with a priority on features that have not other solution. Yes, this or that would be easy to implement, but everything takes time and does it come before all the existing items on our roadmap?

I will add this as a feature request but realize we are doing our best to fix bugs and add the most requested features.

We are also working on improving our documentation so it’s easier to find the information about our APIs and provide sample clips that can be copied and pasted into your code.
Thanks for your input.
-Tom [import]uid: 7559 topic_id: 2603 reply_id: 7499[/import]