Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Preliminary results: Converting real-world app
Started by ingemar Aug 19 2013 10:13 PM

14 replies to this topic
[TOPIC CONTROLS]
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

EDIT: (Nov 2, 2013) All issues reported in this old post have been fixed.

 

I've taken one of my published apps and converted it to Graphics 2.0 (as far as is currently possible).

Apart for some issues (more on that later), I've gotten it functional.

 

Most of the work that needed to be done came down to 2 things:

1) Changing setReferencePoint to object.anchorX and object.anchorY

2) Deciding which display-groups to leave as-is or convert to containers/snapshots

 

 

NOTES:

The deprecated sprite.* API is gone, so you'll need to use the new API if you aren't already doing that.

 

ISSUES in Graphics 2.0:

1) No support for the newer table style params for newText

2) Can't rotate stage around center of screen (see comments below)

3) Line objects do not accept image strokes

4) Objects that are not visible do not receive events even though isHitTestable is set to true

5) Physics objects do not take anchor point into consideration (affects collision detection)

 

(All of the above issues have separate threads in this forum section)

 

No device testing has been done as it's not functional in the current build, so testing has only been done in the Corona Simulator.

 

I've also noticed rendering issues with some containers that are nested within multiple display groups. Some (not all) containers fail to crop their contents within the bounds. I've tried to write a test-case for this issue, but it behaves as expected when doing so, which means I've stumbled upon some edge-case in my production code. I'll keep monitoring this issue in later builds...



[TOPIC: post.html]
#2

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

Thanks for the feedback! And for the issues --- we'll add them to the list.

 

We're working to improve v1compatibility mode to ease the conversion of reference points.

 

Also, containers cannot be infinitely nested b/c they use a mask. So as with graphics 1.0, you have to be careful about the number of levels of nested masks. In 2.0, you cannot to exceed 3 levels of nested masks (this includes text objects, masks on groups, and containers).



[TOPIC: post.html]
#3

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

For #4 (Objects that are not visible do not receive events even though isHitTestable is set to true), can you send us a test case?

 

We ran a quick test case using the "world.jpg" image from HelloWorld and the touch listener does seem to get called, as expected (below).

 

So curious to know if your test case is more complicated?

 

local background = display.newImage( "world.jpg" )
background.x = 160
background.y = 240

background.isVisible = false
background.isHitTestable = true

background:addEventListener( "touch", function(event)
    print( event.phase, event.x, event.y )
end )

 



[TOPIC: post.html]
#4

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Looks like I have some sort of edge case in my production code as your test-code works here as well...

(I use a newRect instead of an actual image, but still, it works.

 

I'll investigate and report back here...



[TOPIC: post.html]
#5

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

OK... found it.

It turns out that if I set the fill color to transparent it fails to register taps even if isVisible = true.

(Don't ask me why I did that, as I have no idea ;). However it works in Graphics 1.0)

local background = display.newRect(10, 10, 100, 100)
background:setFillColor(1, 0);
background.x = 160
background.y = 240

background.isVisible = true
background.isHitTestable = true

background:addEventListener( "touch", function(event)
    print( event.phase, event.x, event.y )
end ) 

 

 

 



[TOPIC: post.html]
#6

admin

[GLOBAL: userInfoPane.html]
admin
  • Administrator

  • 68 posts
  • Administrators

Regarding #2: Can't rotate stage around center of screen

 

In DP2, if you set v1 compatibility mode on (via config.lua), you should be able to rotate the stage about the center of the screen (v1 mode only) b/c we've restored ref pt in that mode.



[TOPIC: post.html]
#7

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Regarding #2:

Sorry, but having to set V1 compatibility is not a long-term solution. This would mean that *all* future apps made with Corona would have to be set in V1 compatibility mode to behave properly on iOS, which can't be right.

 

I've explained in more detail here:

http://forums.coronalabs.com/topic/38169-animated-autorotation-in-graphics-20-not-possible/



[TOPIC: post.html]
#8

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

That was a solution for pre-existing, legacy apps.

 

For pure-v2 apps (i.e. new code you are writing) you have several alternatives:

 

* Translate the origin of the stage to the center of the screen. And then place all children in that group.

* Create a group that's positioned at the center on the screen.

 

 

 



[TOPIC: post.html]
#9

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

@walter

 

I guess Option 1 would be OK. If I understand this correctly I'll then have a true Cartesian coordinate system with (0,0) at the center of the screen, right?



[TOPIC: post.html]
#10

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

Yea.

 

BTW, your suggestion on the other thread made me wonder if there were a camera concept that could be introduced that would encapsulate this somehow. 



[TOPIC: post.html]
#11

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Item 2 can be crossed off the list.

No proprietary code needed any more for animated auto-rotation of the stage on iOS.



[TOPIC: post.html]
#12

Bryan01

[GLOBAL: userInfoPane.html]
Bryan01
  • Enthusiast

  • 95 posts
  • Corona Staff

We have pushed a change in daily builds after build 2004 to address the fill color alpha value of 0 and isHitTestable = true



[TOPIC: post.html]
#13

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Alpha 0 fill issue confirmed fixed in Graphics 2.0 #2006

 

Thanks!



[TOPIC: post.html]
#14

peter.janosik

[GLOBAL: userInfoPane.html]
peter.janosik
  • Observer

  • 26 posts
  • Corona SDK

Yea.

 

BTW, your suggestion on the other thread made me wonder if there were a camera concept that could be introduced that would encapsulate this somehow. 

yep, that would be nice.

i'm converting our game (little galaxy) right now to graphics 2.0 and thinking about ideas hot to convert our "camera" system that use transitions with xyReference, scale, rotation (used for camera moving from center of one planet to center of next planet, rotating to next planets) and x,y (to positon the scene on screen. for example contentWidth*0.5, contenHeight*0.5 means that planet will end up in the center of the screen, but this changes according to some rules). and similiar for background layers with galaxy

 

it looks like this is not possible to do with graphics 2.0. experimenting with more nested groups, but it's pain in the ass.

implementing xyReferences for groups or proper camera is a must



[TOPIC: post.html]
#15

peter.janosik

[GLOBAL: userInfoPane.html]
peter.janosik
  • Observer

  • 26 posts
  • Corona SDK

ok. for working solution regarding "camera" like behaviour look here:

http://forums.coronalabs.com/topic/41529-zooming-camera-anchor-point-hell/?p=216788




[topic_controls]
[/topic_controls]