Using xReference/yReference in Graphics Compatibility 1.0 mode

Solar2D Advanced Graphics
#1

I have a large legacy Corona project that for various reasons hasn’t been continuously updated to recent versions of Corona. Due to Apples Gatekeeper changes in 10.9.5 I’m now at a point where I need to update to a recent version in order to publish updates. 

I’m using Corona 2015.2731.

Adopting the entire project to the Graphics 2.0 engine is not realistic at this point as its just to large (> 400k LOC) and very graphical. A complete rewrite is more likely. 

I’ve enabled graphicsCompatibility 1.0 mode and adopted most things to the changed API:s. The thing that I haven’t solved yet is how to properly use xReference/yReference and anchorX/anchorY when using graphicsCompatibility 1.0 mode. Conceptually I’m completely on board with the changes I need to make with the different coordinate systems, origins etc.

However, with graphicsCompatibility 1.0 mode the xReference/yReference properties are not available, and using anchorX/anchorY yields the following warning:

[lua] o.anchorY is only supported in graphics 2.0. Your mileage may vary in graphicsCompatibility 1.0 mode [/lua]

The resulting transformations are up to now working as expected when using anchorX/anchorY, I’m however concerned about this warning as I don’t want to be backed into a corner if an updated version of Corona changes the behaviour. 

My question is: What is the proper way to achieve xReference/yReference dependent functionality in graphicsCompatibility 1.0 mode without producing the above warning? 

I’m very grateful for any help or insights

Best,

#2

Hi @hatti,

Can you give an example of where you use this (code)? You can’t use anchors with 1.0 compatibility mode on, which is why the warning message is produced. If I can see some of your code, I should be able to assist you further.

Best regards,

Brent

#3

Hi Brent,

Thank you for getting back to me.

One quite simple example that I have is a rotation, imagine for instance a clock with hour and minute indicators. This is currently handled by setting a display.CenterReferencePoint reference point and using an x/yReference offset before performing the rotation.

E.g.

[lua]

local img = display.newImageRect( “image.png”, 10, 40 )

img:setReferencePoint( display.CenterReferencePoint )

img.yReference = 10

…

img.rotation = 45

[/lua]

Most likely I’m missing something obvious here, but I’m struggling how I can reproduce this behaviour with the 2.0 engine with 1.0 compatibility mode enabled.

Best,

hatti

#4

Hi @hatti,

In the case of a clock hand, couldn’t you set the reference point to center-left and have it rotate around that point?

Brent

#5

Hi Brent,

Absolutely, I totally get what you’re suggesting - we could definitely make that work for this case. I’m sure similar solutions could be applied to most of our other concerns as well by transposing and reworking the existing solutions. I’ll have to look a bit further to see if there are any issues that cannot be solved this way.

In more general terms though, are there any ways to offset tranformations from the 9-point referencePoint grid system in 1.0 compatibility mode, such as described above with x/yReference? 

I have a related question to you as a Corona staff that I’d like to post, although it might belong as a separate topic or even in another form - feel free to let me know in that case and we can take that discussion somewhere else.

We are at a crossroads in deciding if we should take the plunge and convert our apps to graphics 2.0 or to merely adopt them to 2.0 with 1.0 compatibility mode. The difference in terms of effort for us is huge, so I need to make sure we’re making the right decision based on a number of parameters to make the investment work. 

My main concern with going the 1.0 compatibility route is how Corona is planning to support that mode going forward? Can we expect the current features to continue to work with 1.0 compatibility mode in future version of Corona, or do we need to be concerned that you are phasing that mode out? I’d like to get a sense of how you’re approaching this question.

Thanks for your help, Brent.

Regards,

hatti

#6

Hi @hatti,

My honest advice at this point is that you should upgrade to graphics 2.0. The 1.0 engine is almost two years old now, and the V1 compatibility mode was intended as temporary placeholder to allow developers to convert to 2.0. While we don’t have immediate plans to remove the V1 compatibility, it would really benefit you to upgrade… not only will you bring your code up-to-date, but you’ll get to use all of the new/improved features of 2.0 like fills/strokes, 2.5D transforms, containers, snapshots, and much more. Basically, upgrading to 2.0 isn’t just about making your legacy project “work,” but also about (hopefully) using new visual features as well. :slight_smile:

Brent

#7

Hi Brent,

Thanks for your honest advice and your thoughts. I totally agree to your point that upgrading to graphics 2.0 is the way to go. For us its a question of where in the product lifecycle we’re currently at with these products and if the investment will pay off. 

Thanks again, you’ve answered all my current questions and concerns. You’ve provided a good view on our options moving forward.

Best,

hatti

#8

I’m really interested with any solution possible to solve this problem, that is to say : get round the x/yReference using 2.0 engine with 1.0 compatibility mode enabled.

Thank you,

Laurent

#9

Hi Laurent,

As I mentioned in other responses above, upgrading to the current 2.0 graphics APIs is virtually a necessity. We no longer test against 1.0 compatibility mode, so we can’t vouch for behavior and/or bugs introduced into those deprecated APIs. At some point in the near future, we may outright deprecate 1.0 compatibility entirely, since the last build which supported it was about 2 years and 3 months ago (an eternity in the tech world).

Best regards,

Brent

#10

And having converted several apps, it’s not that difficult. You can use search to quickly jump to places and do the updates. A typical 5000 line program can probably be converted in an hour or two.

Rob

#11

is graphicsCompatibility still supported right now?

#12

I believe it is, but we’ve been discussing removing it.

#13

Hi @hatti,

Can you give an example of where you use this (code)? You can’t use anchors with 1.0 compatibility mode on, which is why the warning message is produced. If I can see some of your code, I should be able to assist you further.

Best regards,

Brent

#14

Hi Brent,

Thank you for getting back to me.

One quite simple example that I have is a rotation, imagine for instance a clock with hour and minute indicators. This is currently handled by setting a display.CenterReferencePoint reference point and using an x/yReference offset before performing the rotation.

E.g.

[lua]

local img = display.newImageRect( “image.png”, 10, 40 )

img:setReferencePoint( display.CenterReferencePoint )

img.yReference = 10

…

img.rotation = 45

[/lua]

Most likely I’m missing something obvious here, but I’m struggling how I can reproduce this behaviour with the 2.0 engine with 1.0 compatibility mode enabled.

Best,

hatti

#15

Hi @hatti,

In the case of a clock hand, couldn’t you set the reference point to center-left and have it rotate around that point?

Brent

#16

Hi Brent,

Absolutely, I totally get what you’re suggesting - we could definitely make that work for this case. I’m sure similar solutions could be applied to most of our other concerns as well by transposing and reworking the existing solutions. I’ll have to look a bit further to see if there are any issues that cannot be solved this way.

In more general terms though, are there any ways to offset tranformations from the 9-point referencePoint grid system in 1.0 compatibility mode, such as described above with x/yReference? 

I have a related question to you as a Corona staff that I’d like to post, although it might belong as a separate topic or even in another form - feel free to let me know in that case and we can take that discussion somewhere else.

We are at a crossroads in deciding if we should take the plunge and convert our apps to graphics 2.0 or to merely adopt them to 2.0 with 1.0 compatibility mode. The difference in terms of effort for us is huge, so I need to make sure we’re making the right decision based on a number of parameters to make the investment work. 

My main concern with going the 1.0 compatibility route is how Corona is planning to support that mode going forward? Can we expect the current features to continue to work with 1.0 compatibility mode in future version of Corona, or do we need to be concerned that you are phasing that mode out? I’d like to get a sense of how you’re approaching this question.

Thanks for your help, Brent.

Regards,

hatti

#17

Hi @hatti,

My honest advice at this point is that you should upgrade to graphics 2.0. The 1.0 engine is almost two years old now, and the V1 compatibility mode was intended as temporary placeholder to allow developers to convert to 2.0. While we don’t have immediate plans to remove the V1 compatibility, it would really benefit you to upgrade… not only will you bring your code up-to-date, but you’ll get to use all of the new/improved features of 2.0 like fills/strokes, 2.5D transforms, containers, snapshots, and much more. Basically, upgrading to 2.0 isn’t just about making your legacy project “work,” but also about (hopefully) using new visual features as well. :slight_smile:

Brent

#18

Hi Brent,

Thanks for your honest advice and your thoughts. I totally agree to your point that upgrading to graphics 2.0 is the way to go. For us its a question of where in the product lifecycle we’re currently at with these products and if the investment will pay off. 

Thanks again, you’ve answered all my current questions and concerns. You’ve provided a good view on our options moving forward.

Best,

hatti

#19

I’m really interested with any solution possible to solve this problem, that is to say : get round the x/yReference using 2.0 engine with 1.0 compatibility mode enabled.

Thank you,

Laurent

#20

Hi Laurent,

As I mentioned in other responses above, upgrading to the current 2.0 graphics APIs is virtually a necessity. We no longer test against 1.0 compatibility mode, so we can’t vouch for behavior and/or bugs introduced into those deprecated APIs. At some point in the near future, we may outright deprecate 1.0 compatibility entirely, since the last build which supported it was about 2 years and 3 months ago (an eternity in the tech world).

Best regards,

Brent