display.contentWidth is the value Corona picks up from config.lua where you set the “width”. But more importantly it’s your “in-app content grid”. If you run it on a 320x480 iPhone 4, display.contentWidth is going to return 1280. If you run it on an iPad Pro with its 2732px wide screen, display.contentWidth will be 1280. Corona will internally scale up or scale down to fit the actual device.
Now if your screen is bigger than your content area, display.actualContentWidth should return you the actual screen size relative to your defined content area.
display.pixelWidth might get you the actual window size. The values you can get back from JavaScript will be the physical window size. You could potentially use display.contentScaleX multiplied by the physical window width to get the width scaled to your content area.
If your defined content size is say… 800x600 and you draw a 100x100px square in the middle, then your square will only be 100x100 if the device happens to be an 800x600 screen, because really by drawing a 100px wide square on an 800 wide canvas you’re asking Corona to make it an eighth the width of the actual screen, since that canvas is being stretched to full screen.
In HTML the canvas isn’t necessarily stretched to full screen, but it will still scale with the browser if you’re using the default index.html that Corona generates.
If you want a literal 100x100 square on all devices, and your canvas is configured to 800x600, then you’d need to lock the resulting HTML5 canvas element to 800x600 in CSS. This way, you can resize the browser all you like, or display it on other screens, and the game area will remain fixed in the middle.
I’m not sure why you’d want to do that though. One of the advantages to using Corona compared to writing your game in native JavaScript is surely its content scaling mechanic?
Alternatively, if you want to keep the canvas full size but draw your elements at literal pixel sizes, you could reverse the math yourself using display.contentScale*. I.e. if your canvas is 800 wide and contentScaleX reports 2, then the screen must be 1600 wide meaning a 50px wide rectangle will render at 100px on that screen. So rather than drawing a 100px square, if you draw a 100/display.contentScaleX and 100/display.contentScaleY square, you’d presumably get a square that outputs at a literal 100px? Untested, admittedly.
I have tested - plz look above. contentScale* is showing 1. So I can not use this technic.
I have tryed to limit element in CSS - that dosent helped as well.
I have spend many hours on this issue - even if it looks like a simple missunderstanding on my part - it dosent. I tryed and tested many configurations =)
I suspect, I may miss some properly working method. Can you tell me - how to keep 100% scale for my project?
(One that you described - I already tested above, and it dosent work like that)
I’m not sure what you’re end goal is and more importantly I don’t know why you want to avoid using Corona’s content scaling. I have a saying “Don’t fight the system” and that’s what I feel you’re trying to do here.
I’m not sure if HTML5 windows are resizable or not, so the resizable = true might not mean much here.
Doing this gets you a 1:1 contentScale value. Your window size is an exact match to what the content area is set to. In this scenario, rounding errors aside, contentWidth = actualContentWidth. .pixelWidth is still bigger (but the values seem inverted).
Remember HTML5 is still considered Beta. But I believe you need to use the window table in build.settings to control your physical HTML5 window size.
Yes, I did noticed that you ignored my reply. Plz dont =) Sorry for my English. I’m panicking here - I want to release a html5 version of my games, but I cant:
What is my Goal here? Why do I need to be scale 100%?
This is really simple question: I using corona for developing games - I dont want them to be ugly or croped.
I tryed your settings, and here what I got(spoiler - it is still not correct):
It is still incorrect.
I dont mind “going with the flow”. But do you think it is ok to have random unchangeable scale? And it is hard to fix it or give control over it?
Can you accept this as a bug? Or can I submit it as a bug? Or can you tell me how to set 100% scale?
Again sorry for my english - this issue is very important to me. But since you mentioned that html5 is somehow working - and it is, except this easy-to-fix-but-critical scaling bug.
@Rob sorry, I think my response above caused some confusion here.
My first paragraph wasn’t directed at you. It was me realising what OP was getting at and it does sound like a bug to me, but a lot is getting lost in translation here.
As far as I can tell, what’s happening is that content scaling is kicking in properly, as it should, but display.contentScaleX and display.contentScaleY are reporting as 1 despite the mechanism working.
So if OP has width and height of 800x600 defined in config.lua but the HTML5 build is shown at 1600x1200, content scaling is correctly doubling up his 100px square to 200px, but display.contentScaleX is still reporting 1 instead of 2.
Now, like you I’m not sure on the logic of not wanting content scaling to kick in, but that aside I’d expect to be able to circumvent it by drawing that rectangle at 100/display.contentScaleX so that it’s actually drawn at 50px and upscaled by *2 on the 1600 screen, and drawn at 100px and upscaled by *1 on the 800 screen. I.e. to still be a 100px output on either screen. Does this make sense?
With contentScaleX and contentScaleY reporting as 1 though, this workaround isn’t possible.
In a nutshell it makes sense for these values to be based on pixel density when building to an app, but when building to an HTML5 canvas surely it makes more sense for these values to be based on the size that canvas is output at? I.e. if config.lua defines an 800px width but the HTML5 canvas element ends up with a width of 1600, contentScaleX should be 2 I think.