Issues with graphicsCompatibility = 1

Solar2D General Questions/Discussion
#1

I’m having a problem running my graphics 1.0 code in graphics 2.0 with compatibility mode switched on.

Here’s my config.lua

application = { content = {                 graphicsCompatibility = 1,  -- Turn on V1 Compatibility Mode                 width = 320, height = 480,  scale = "letterbox",  fps = 30,         imageSuffix = {     ["@2x"] = 1.5,                     ["@4x"] = 3, -- for iPad 3 } }, }

I’m running 2189 - when I run without the compatibility flag it’s all over the place.

Here’s one object that works just fine:

myMenuObject.MenuMessageDialog.HeadingTxt = display.newText(myMenuObject.MenuMessageDialog.Group, "Heading", 0, 0, font.bold, 16) myMenuObject.MenuMessageDialog.HeadingTxt.x = 100 myMenuObject.MenuMessageDialog.HeadingTxt.y = 100It over-rides the original x,y at object creation with a new x & y which were always relative to the middle of the object.

Here’s one that doesn’t work (appears in the wrong position):

local textOptions = { parent = myMenuObject.MenuMessageDialog.Group, text = "", x = 100, y = 100, width = 200, height = 100, align = "center", font = font.normal, fontSize = 14} myMenuObject.MenuMessageDialog.MessageTxt = display.newText(textOptions)

Note that this method of text creation which allows alignment has always been relative to the centre of the object on creation - perhaps compatibility doesn’t take this into account?

Also buttons don’t work if their alpha is zero (“myMenuObject.MenuMessageDialog.ButtonOK:setFillColor(217,217,217,0)”) which was fine before.

These were just the things I noticed on my first screen - wanted to make sure I wasn’t missing something obvious before I took a deeper dive.

Nathan.

#2

Hi @Rob - any chance you can take a look at this?

Thanks,
Nathan.

#3

Hello???

#4

Run this block of code:

local block = display.newRect(100,100,200,100) block:setFillColor(1,0,0,0.5) local textOptions = {      text = "somestring",      x = 100,      y = 100,      width = 200,      height = 100,      align = "center",      font = native.systemFont,      fontSize = 14} mytext = display.newText(textOptions) mytext:setFillColor(1) local dot = display.newCircle(100,100,4) dot:setFillColor(0,0,1)

What I’m doing is drawing a 200x100 rectangle centered on 100,100, which is what your second form of display.newText() is doing.  I also draw a dot at 100,100 to show you where the center of the block is.

In your first display.newText() you’re not specifying a width or height, so the image returned by the function is a tight fit to the actual text.  If your string ends up being 50px wide and 20px high, then that 50x20 box will be centered on 100,100.  But in your second form,  you’re saying fit the text to a 200x100 box.  The text will wrap when it gets wider than 200px and be centered horizontally in the box, however, it starts from the top of the box as the sample above shows.  If you want it vertically centered, then specify a height of 0.  If not we are going to give you what you asked for.

Rob

#5

Hi Rob,

I don’t doubt that your code will work - what I’m saying is that my second example behaves completely differently on graphics 1.0, to what it does on graphics 2.0 with compatibility mode turned on.

The text wrapping and alignment is fine - it’s the positioning of the text that has changed.

I adjusted your code a little to get the colours to light up…

local block = display.newRect(100,100,200,100) block:setFillColor(100,100,100,150) local textOptions = {      text = "somestring",      x = 100,      y = 100,      width = 200,      height = 100,      align = "center",      font = native.systemFont,      fontSize = 14} local mytext = display.newText(textOptions) --mytext:setFillColor(1) local dot = display.newCircle(100,100,4) dot:setFillColor(255,0,0)

Here is the output when running on 1262 (graphics 1.0):

  corona_1262.png

Here is the output when running on 2189 (graphics 2.0) with no compatibility - which I don’t expect to work:

corona_2189_no_compat.png

Here is the output running on 2189 (graphics 2.0) with compatibility turned on:

corona_2189_compat.png

As you can see the final output looks nothing like the graphics 1.0 output???

Nathan. 

#6

Hi @Rob - any chance you can take a look at this?

Thanks,
Nathan.

#7

Hello???

#8

Run this block of code:

local block = display.newRect(100,100,200,100) block:setFillColor(1,0,0,0.5) local textOptions = {      text = "somestring",      x = 100,      y = 100,      width = 200,      height = 100,      align = "center",      font = native.systemFont,      fontSize = 14} mytext = display.newText(textOptions) mytext:setFillColor(1) local dot = display.newCircle(100,100,4) dot:setFillColor(0,0,1)

What I’m doing is drawing a 200x100 rectangle centered on 100,100, which is what your second form of display.newText() is doing.  I also draw a dot at 100,100 to show you where the center of the block is.

In your first display.newText() you’re not specifying a width or height, so the image returned by the function is a tight fit to the actual text.  If your string ends up being 50px wide and 20px high, then that 50x20 box will be centered on 100,100.  But in your second form,  you’re saying fit the text to a 200x100 box.  The text will wrap when it gets wider than 200px and be centered horizontally in the box, however, it starts from the top of the box as the sample above shows.  If you want it vertically centered, then specify a height of 0.  If not we are going to give you what you asked for.

Rob

#9

Hi Rob,

I don’t doubt that your code will work - what I’m saying is that my second example behaves completely differently on graphics 1.0, to what it does on graphics 2.0 with compatibility mode turned on.

The text wrapping and alignment is fine - it’s the positioning of the text that has changed.

I adjusted your code a little to get the colours to light up…

local block = display.newRect(100,100,200,100) block:setFillColor(100,100,100,150) local textOptions = {      text = "somestring",      x = 100,      y = 100,      width = 200,      height = 100,      align = "center",      font = native.systemFont,      fontSize = 14} local mytext = display.newText(textOptions) --mytext:setFillColor(1) local dot = display.newCircle(100,100,4) dot:setFillColor(255,0,0)

Here is the output when running on 1262 (graphics 1.0):

  corona_1262.png

Here is the output when running on 2189 (graphics 2.0) with no compatibility - which I don’t expect to work:

corona_2189_no_compat.png

Here is the output running on 2189 (graphics 2.0) with compatibility turned on:

corona_2189_compat.png

As you can see the final output looks nothing like the graphics 1.0 output???

Nathan. 

#10

@beernathan: Any luck on any of this? Due to the IDFA issue I too am likely going to have to update my game to Graphics 2.0, and the compatibility mode leaves much to be desired. All of the transitions happening (Graphics 2.0, Composer) around the release of my game have left me frustrated with Corona.

#11

Hi @davidcondolora,

Frustrating for me too - no reply from @Rob-Mircale. feel like I can’t progress without some direction here as Corona is not behaving as per the documentation.

#12

I’m confused about why with Graphics 1.0, your text block is drawing where it is.

If you use the old style text creator:  local mytext = display.newText(“somestring”, 100, 100, 200, 100, native.systemFont, 14)

Then there is no difference between G1 and G2 in graphics compatibility mode.  But when I use the display.newText() in the new way, it’s not drawing in the right place with your G1 method.  The red dot represents 100, 100 on your screen.   The display.newText() you are telling to draw it’s top left corner at 100, 100, which under G1 it is not.  It’s centering the block on the X axis.  I don’t know why the Y axis is drawing as high on the screen as it is.  It’s almost like it’s got a :setReferencePoint() on it or it’s like the display.newText() in the new mode is behaving like it should in G2 mode.

I would say the G1 version with the new style is a bug.  The way it should work in G1 and G2 with compatibility mode is that you should get a 200x100 box.  The text should be centered in that box and then the top left should be at 100, 100. 

In G2 without compatibility mode, that block should be centered at 100, 100.  Which is what looks like is happening in G1 builds.

#13

Hmmmmm. OK thanks @Rob-Miracle - so if I read your comment right, you’re saying G1 with the new style had a bug in it, and that G2 with compatibility isn’t compatible with that G1 bug :wink:

I’m happy that at least i know that - it’s a much more solid foundation for me to move forward on, as I can update my “new style” calls across the board to make them compatible with “G2 compatibility mode”. At least then I can move onto a current release before I make the big jump to G2.

#14

That’s what it would appear to be.   G2 is working as it supposed to.

Rob

#15

@Rob, I’m running graphicsCompatibility = 1 now, and trying to transition to 2.0. I think the only offending thing that I’m using is setReferencePoint. All of my objects are center referenced like this:

[lua]

local label = display.newImageRect(“images/label.png”, 100,100);

label:setReferencePoint(display.CenterReferencePoint);

label.x = 646; label.y = 706;

label.scene = “label”;

[/lua]

Based on what I’m reading, it looks like all I need to do is remove the setReferencePoint line of code for each object. Is that right?

#16

That should take care of it.  We also dropped out the legacy sprite library with the Graphics 2.0 build.  If you need it, you can download ti from github and just drop it in your folder and won’t miss a beat.

Rob

#17

@Rob,

Thanks very much. Mostly ok, but several Problems

Currrent stand out … 

Corona staff have consistently recommended that I create a series of rectangular, hand-coded, overlay objects to distinguish user touches on irregular-shaped juxtaposed objects. The 50 visible objects were center referenced; they’re fine. The ‘alpha = 0.01’ overlays were upper-left xy referenced. All 100+ have shifted out of place.

I’ll include sample code for one overlay. Tried to include a pic but can’t find the accepted file format.

Do you you know of any search-and-replace-based syntax assignment to easily readjust their new centered location to their former upper left xy location? Or, worst case, can you recommend a clever algorithm to recalculate the values?

[lua]

me_shape_1 = display.newRect( 835, 100, 57, 60 );

me_shape_1.alpha = .01;

me_shape_1.order = 1;

me_shape_1.match = me;

me_shape_1.isMask = true;

[/lua]

Thanks.

#18

@Ibolduc: I just went through the same ordeal. Anywhere you use display.newRect, if you expect it to be Top-Left aligned, you’ll need to manually anchor it to top left. My recommendation is to include this line after you create the object:

me\_shape\_1.anchorX = 0; me\_shape\_1.anchorY = 0

Positioning should work as expected from here, now that it has a top-left anchor point.

#19

@lbolduc,

I noticed you mentioning using alpha 0.01 for your your overlay (invisible) touch objects.  

My assumption is you want the overlay to act as a touch object but to not be visible to the user.

Might I suggest one of two better options?

  1.  Use a fully transparent (alpha == 0) rectantgle and set the isHitTestable attribute to true.  Why?  In my experience, previously using your technique over several devices, I found that sometimes low alphas got treated like zero alpha and thus no touch was recorded.  Also, sometimes even low alphas are visible, thus creating ugly artifacts.

  2. Use an imageRect and fill with a fully transparent texture.  I use this solution exclusively now.  In fact, all my projects keep two textures:

  • fillT.png - 16x16 Transparent fill texture.
  • fillW.png - 16x16 White fill texture.

When prototyping and debugging I use fillW.png for my (later to be invisible) touch objects/helpers so I can see them, position them, and verify their placement.  I may set the alpha to 0.5 and colorize them too based on my debugging situation.  

Then, after I’m satisfied, I change the fill texture to fillT.png and bingo, an invisible touch object that always works.

I hope this helps.

#20

@lbolduc and @roaminggamer: On that same idea, anytime I use invisible objects that I attach touch events to, I toggle invisibility to false and hit testability to true:

newObject = display.newRect(0, 0, 1024, 768) newObject.isVisible = false newObject.isHitTestable = true

My guess is that this is ‘cheaper’ from a processing standpoint, as no alpha operations are involved.