I still can not solve, my mobile is also a lumia 535, which I do not understand is why the games of other work, it just happens to my games on my phone, I have an application in the phone windows store and some users are already complaining of this problem.
Can you both do a quick test for me please?
Open your “MainPage.xaml.cs” file and add the following lines of code to the bottom of the MainPage() constructor…
System.Diagnostics.Debug.WriteLine("### Resolution Scale: {0}", Windows.Graphics.Display.DisplayProperties.ResolutionScale.ToString()); System.Diagnostics.Debug.WriteLine("### Content Scale: {0}", (double)System.Windows.Application.Current.Host.Content.ScaleFactor / 100.0);
Then run your project in Visual Studio in “Debug” mode on your Lumia 535 device.
The above code will log Microsoft’s scale factors to Visual Studio’s “Output” panel.
Please post the results to this forum here.
If you can do this by tomorrow, then that would be great… because I *think* I know what the issue is, but I need confirmation from real devices. If you can do this, then I’ll personally jump on this issue tomorrow. Thanks!
This would be the result:
Resolution Scale: Scale100Percent
Content Scale: 1
Platform: Not Supported Yet / ARM / 8.0 / ANGLE (Qualcomm Adreno 305 Direct3D11 vs_2_0 ps_2_0) / OpenGL ES 2.0 (ANGLE 1.2.0.2446) / 2016.2830 / Português (Brasil) | BR | pt-BR | pt
Well there’s the problem. Microsoft is only supposed to return a scale of 1.0 for a 480x800 resolution device. Corona uses the “Content.ScaleFactor” property (recommended by Microsoft’s examples) to calculate the pixel width/height of the screen. Microsoft documents what the content resolution and scales are here…
https://msdn.microsoft.com/en-us/library/windows/apps/jj206974(v=vs.105).aspx#BKMK_Supportedresolutions
From looking at the Lumia 535 device’s specification, it has an unusual resolution of 540x960 pixels…
https://www.microsoft.com/en/mobile/phone/lumia535/specifications
I suspect that Microsoft’s APIs are returning 480x800 pixel resolution for that device based on your screenshots, making it a bug on their end. You can confirm this by adding the following to your MainPage.xaml.cs file.
public MainPage() { // Initialize this page's components that were set up via the UI designer. InitializeComponent(); // Set up Corona to automatically start up when the control's Loaded event has been raised. // Note: By default, Corona will run the "main.lua" file in the "Assets\Corona" directory. // You can change the defaults via the CoronaPanel's AutoLaunchSettings property. fCoronaPanel.AutoLaunchEnabled = true; // Set up the CoronaPanel control to render fullscreen via the DrawingSurfaceBackgroundGrid control. // This significantly improves the framerate and is the only means of achieving 60 FPS. fCoronaPanel.BackgroundRenderingEnabled = true; fDrawingSurfaceBackgroundGrid.SetBackgroundContentProvider(fCoronaPanel.BackgroundContentProvider); fDrawingSurfaceBackgroundGrid.SetBackgroundManipulationHandler(fCoronaPanel.BackgroundManipulationHandler); this.Loaded += OnLoaded; } private void OnLoaded(object sender, RoutedEventArgs e) { var content = System.Windows.Application.Current.Host.Content; System.Diagnostics.Debug.WriteLine("### Resolution Scale: {0}", Windows.Graphics.Display.DisplayProperties.ResolutionScale.ToString()); System.Diagnostics.Debug.WriteLine("### Content Scale: {0}", (double)content.ScaleFactor / 100.0); System.Diagnostics.Debug.WriteLine("### Content Size: {0}x{1}", content.ActualWidth, content.ActualHeight); System.Diagnostics.Debug.WriteLine("### Page Size: {0}x{1}", this.ActualWidth, this.ActualHeight); System.Diagnostics.Debug.WriteLine("### CoronaPanel Size: {0}x{1}", fCoronaPanel.ActualWidth, fCoronaPanel.ActualHeight); { object result = "null"; Microsoft.Phone.Info.DeviceExtendedProperties.TryGetValue("RawDpiX", out result); System.Diagnostics.Debug.WriteLine("### RawDpiX: {0}", result); } { object result = "null"; Microsoft.Phone.Info.DeviceExtendedProperties.TryGetValue("RawDpiY", out result); System.Diagnostics.Debug.WriteLine("### RawDpiY: {0}", result); } { var size = new System.Windows.Size(0, 0); object result = null; Microsoft.Phone.Info.DeviceExtendedProperties.TryGetValue("PhysicalScreenResolution", out result); if (result is System.Windows.Size) { size = (System.Windows.Size)result; } System.Diagnostics.Debug.WriteLine("### PhysicalScreenResolution: {0}x{1}", size.Width, size.Height); } }
The above will log the widths and height from various APIs to Visual Studio’s “Output” panel like before. If the above returns a 480x800 resolution, then unfortunately there is nothing we can do in code to fix this. All we can do is report it as a Lumia 535 specific bug to Microsoft and hope they’ll patch it in the near future.
There is 1 more thing I’d like you to print out. Please add the following line to your code.
System.Diagnostics.Debug.WriteLine("### Logical DPI: {0}", Windows.Graphics.Display.DisplayProperties.LogicalDpi);
The “LogicalDpi” is the scale factor Microsoft uses to scale fonts and Microsoft typically does dynamic layout based on the system’s default font size. So, I’m thinking that API has to provide the correct scale factor for your phone.
For your info, the font scale factor is calculated like this…
scale = logicalDpi / 96.0
So, hopefully the logical DPI is greater than 96.0 for your phone. (Fingers crossed.)
I understand, but because usually works when the machine is running Windows 8.1 phone?
Right. I’ve never heard of any scaling bugs on Windows Phone 8.0 or 8.1.
Microsoft did report scaling bugs on Windows Phone 8.x devices that were upgraded to Windows 10 during the beta last year. You can see that in the link I provided in my 1st forum post up above. It sounds like Microsoft hasn’t fixed these scaling bugs on all devices yet. I’m guessing that these scaling bugs only happen with Silverlight *.xap applications and not with Universal *.appx applications which were designed for Windows 10.
If you can tell me what the “LogicalDpi” property returns, then that would be a big help. I gave you that code snipped in my last forum post on this thread (just above this one). I’m hoping that property returns the correct scale factor for your device on Windows 10 Mobile. If it does, then we should be abel to work-around this Microsoft bug.
Hi,
I have the same problem. I am using Lumia 535. Here is output
Platform: Not Supported Yet / ARM / 8.0 / ANGLE (Qualcomm Adreno 305 Direct3D11 vs_2_0 ps_2_0) / OpenGL ES 2.0 (ANGLE 1.2.0.2446) / 2016.2853
The thread 0x2ec has exited with code 0 (0x0).
The thread 0x16e4 has exited with code 0 (0x0).
Resolution Scale: Scale100Percent
Content Scale: 1
Content Size: 480x800
Page Size: 741x480
CoronaPanel Size: 741x480
RawDpiX: 196,645161290323
RawDpiY: 196,645161290323
PhysicalScreenResolution: 480x800
Logical DPI: 96
It would be great if Corona would provide some kind of solution.
Best,
Primoz
A doubt, because this game: https://www.microsoft.com/pt-br/store/games/corona-cannon/9nblggh5pwvn
It works seamlessly on lumia 535?
Is it any adaptation in the lua code or visual studio project?
Primoz, Welton,
If you look at the returned values, notice that the device is returning a 480x800 resolutions with a 1.0 scale factor. A Lumia 535 is a 540x960 resolution device. So, Microsoft’s APIs are clearly returning the wrong values for that device. That’s the issue. It’s a Microsoft bug that they need to fix. I don’t see how we can work-around this issue on our end.
I think the best we can do at this point is report it as a bug to Microsoft. The only means I know of doing this is to start a “discussion” (aka: forum post) on their website here…
http://answers.microsoft.com/en-us/mobiledevices
If you are to report it, then the best description to use is…
Lumia 535 running Windows 10 Mobile returns the wrong pixel resolution and scale factor to Silverlight apps. This causes Direct3D apps to render at a smaller scale onscreen than they should.
The following API returns a 480x800 size when it should return a 540x960 size…
Microsoft.Phone.Info.DeviceExtendedProperties.TryGetValue(“PhysicalScreenResolution”, out result);
And the following APIs return a 1.0 scale factor when it should be a larger scale since the “Content” object’s ActualWidth/ActualHeight are 480x800…
System.Windows.Application.Current.Host.Content.ScaleFactor; // = 100
Windows.Graphics.Display.DisplayProperties.ResolutionScale; // = Scale100Percent
Windows.Graphics.Display.DisplayProperties.LogicalDpi; // = 96.0
Hmm… apparently this is a common problem with the Lumia 535. Have a look here…
We have tried running our Corona Cards apps on some devices running Windows Phone 10: Lumia 535, Lumia 640XL, Lumia 735 and Lumia 550. There was problem on all of them as in welton-alexandre’s first post images (Hello world example). Apps are scaled down and black borders are on top and from side (on Lumia 535 there is diffrent problem, black bar is on the bottom if you hide Windows nav buttons).
You can try to reproduce this by creating new Corona Cards app (Hello World default template) in Visual Studio (2013 or 2015) and deploy it on any Windows 10 phone.
We have commented out 3 lines
// Set up the CoronaPanel control to render fullscreen via the DrawingSurfaceBackgroundGrid control.
// This significantly improves the framerate and is the only means of achieving 60 FPS.
/*fCoronaPanel.BackgroundRenderingEnabled = true;
fDrawingSurfaceBackgroundGrid.SetBackgroundContentProvider(fCoronaPanel.BackgroundContentProvider);
fDrawingSurfaceBackgroundGrid.SetBackgroundManipulationHandler(fCoronaPanel.BackgroundManipulationHandler);*/
regarding DrawingSurfaceBackgroundGrid and now apps are rendered FINE in fullscreen, not scaled down.
Is this good aproach? Do you use DrawingSurfaceBackgroundGrid in your game Corona Cannon published on MS Store? Can you share VS project of Corona Cannon?
Thanks!
I looked up the specs of all the Lumia modes you listed. The one thing they *all* have in common is that they use an onscreen navigation bar. So far, this appears to be never an issue with a device that has physical navigation buttons.
We don’t have those specific devices. So, can you run the code that I’ve posted above to retrieve the resolution and scale factor being reported by Microsoft’s APIs please? I suspect that Microsoft’s APIs are returning 480x800 resolutions for all of those devices, which would account for the scaling issues.
Regarding disabling background rendering, you’ll run into 2 issues with that. First, 60 FPS is impossible because rendering to a Silverlight view/control is the equivalent to taking a screenshot every frame; it’s slow, but it’ll work. Second, the touch/tap points Corona reports will likely be wrong because they’re based on the resolution reported by Microsoft’s APIs I’ve mentioned above.
Note that the reason that disable background rendering works is because we’re rendering to the view’s coordinates and letting Silverlight scale up the view for us. But background rendering involves us rendering straight to the screen in pixels for best performance and this means Microsoft’s APIs *need* to return the correct resolution and scale in order for us to render fullscreen.
I have installed Corona Cannon ( https://www.microsoft.com/pt-br/store/games/corona-cannon/9nblggh5pwvn ) to all my devices. Game works fine, without any scaling.
If I build Corona Cannon from github ( https://github.com/coronalabs-samples/CoronaCannon ) with BackgroundRenderingEnabled as recommended, game is scaled down, on Lumia 640 XL whole game is rendered to only 1/4 of the screen.
So I assume that if you were using BackgroundRenderingEnabled in Corona Cannon project, there is a *solution*. Maybe it has something to do with your Visual Studio project setup.
Is there a way that you share your Corona Cannon Visual Studio project and Corona Cards version it was build and published with? Which version of Visual Studio and Visual Studio update were you using? I would like to build Corona Cannon as you did.
Anyway, a lot of MS Lumia Windows Phone 10 devices are without physical navigation buttons, so we must figure out workaround :).
Thanks!
Output >>>>>
Lumia 535
Resolution Scale: Scale100Percent
Content Scale: 1
Content Size: 480x800
Page Size: 480x771
CoronaPanel Size: 480x771
RawDpiX: 196,645161290323
RawDpiY: 196,645161290323
PhysicalScreenResolution: 480x800
Logical DPI: 96
Platform: Not Supported Yet / ARM / 8.0 / ANGLE (Qualcomm Adreno 305 Direct3D11 vs_2_0 ps_2_0) / OpenGL ES 2.0 (ANGLE 1.2.0.2446) / 2016.2830 / English (United States) | US | en-US | en
Lumia 640 XL
Resolution Scale: Scale150Percent
Content Scale: 1
Content Size: 480x800
Page Size: 480x772
CoronaPanel Size: 480x772
RawDpiX: 171.718309859155
RawDpiY: 171.718309859155
PhysicalScreenResolution: 480x800
Logical DPI: 144
Platform: Not Supported Yet / ARM / 8.0 / ANGLE (Qualcomm Adreno 305 Direct3D11 vs_2_0 ps_2_0) / OpenGL ES 2.0 (ANGLE 1.2.0.2446) / 2016.2830 / English (United States) | US | en-US | en
Lumia 550
Resolution Scale: Scale150Percent
Content Scale: 1
Content Size: 480x800
Page Size: 480x768
CoronaPanel Size: 480x768
RawDpiX: 210.206896551724
RawDpiY: 210.206896551724
PhysicalScreenResolution: 480x800
Logical DPI: 144
Platform: Not Supported Yet / ARM / 8.0 / ANGLE (Qualcomm Adreno 304 Direct3D11 vs_2_0 ps_2_0) / OpenGL ES 2.0 (ANGLE 1.2.0.2446) / 2016.2830 / English (United States) | US | en-US | en
Interesting. If you look at the results of the Lumia 550 and 640XL, notice that the “Resolution Scale” and “Content Scale” differ. A ContentScale of 1.0 is wrong for those devices, but the ResolutionScale of “Scale150Percent” is correct. And the LogicalDPI of 144 is correct for both of the devices too. This is good news. This means we can implement a work-around. All we have to do is compare the 2 scale factors (which are supposed to be the same; that’s the Microsoft bug) and choose the greater value. Thanks for this @primoz. 
I was also able to reproduce this bug in the Windows 10 Mobile emulators too, but only if they’re set up as follows:
- Must be a 720P or WXGA resolution Win10 emulator. (WVGA, 1080P, and QHD scale correctly.)
- Must be set up to use a software navigation bar. (Scales correctly if emulating with hardware buttons.)
You can enable the software navigation bar in the Windows Phone emulator by doing the following:
- Launch the Windows 10 Mobile emulator via Visual Studio.
- Click the [>>] button on the floating toolbar to the right of the emulator to show the “Additional Tools” window.
- Click on the “Optional Settings” tab.
- Check the “Software buttons” checkbox.
- Click the Apply button. (This will cause the emulator to reboot.)
After doing the above, the emulator reports the same values you’ve noted on the Lumia 550 and 640 XL where the “ContentScale” property returns the wrong value but the “ResolutionScale” property returns the correct value. This is a big help to us.
So, I’ll go ahead and implement a work-around today and try to get you guys a daily build as soon as possible. Again, thanks for your help on this.
Unfortunately, the Lumia 535 appears to be a lost cause. Notice that all of Microsoft’s APIs return the wrong values for that device. The above mentioned work-around will not work on this device. The only possible solution that I can think of is to identify that device by its make/model name and if it is a Lumia 535, then assume hardcode the resolution and scale factor on our end. *ugh* I would prefer not to hardcode hacks like this since they’re a maintenance issue on our end, but if it’s a popular device then we may consider doing it. I’ll have to ponder our options.
Regarding the WP8 version of Corona Cannon, I don’t have access to the code either. But I’ll reach out to the developer on how it’s set up.
Thank you Joshua! Please let us know when daily build with work-around available. I’ll be happy to test.
Regarding Lumia 535, it would be great to put hack into daily build. +1 from my side (need to update 40 apps, and don’t want to do it twice :-) ).
Okay. I need you to do 1 more test for me. Please run the following code on your Lumia 535 and tell me what it outputs…
System.Diagnostics.Debug.WriteLine("### DeviceManufacturer: {0}", Microsoft.Phone.Info.DeviceStatus.DeviceManufacturer); System.Diagnostics.Debug.WriteLine("### DeviceName: {0}", Microsoft.Phone.Info.DeviceStatus.DeviceName);
The above is needed in order for me to identify your Lumia 535 device in code. Thanks!
Everyone,
Daily build #2860 will provide our work-around for those Windows 10 Mobile scaling bugs you’ve seen on devices having an onscreen navigation bar. Just note that this is a “blind fix” since I can’t reproduce this issue on my devices. I can only sort-of reproduce it in the Windows Phone emulators. Please let me know how it works out for you all. Also note that it won’t solve the problems you are seeing with the Lumia 535 unfortunately.
Please test the new build with the following “main.lua” code. The following project does not need a “config.lua” file. The content area will be displayed white, and if you do add a “config.lua” file, then the letterbox areas will appear red.
-- Hide the status bar. display.setStatusBar(display.HiddenStatusBar) -- Display a black bacground rectangle in Corona's content region and red in the letterbox region. local backgroundRectangle = display.newRect(0, 0, 0, 0) --backgroundRectangle:setFillColor(0, 0, 0) backgroundRectangle:setFillColor(1, 1, 1) display.setDefault("background", 1, 0, 0) --display.setDefault("background", 1, 1, 1) -- Define the rest of our variables. local textObject = nil local textGuideLineTop = nil local textGuideLineBottom = nil local textGuideLineLeft = nil local textGuideLineRight = nil -- Creates a red horizontal line at the given position within the content region. -- It will not draw the line in the letterbox region. local function createHorizontalGuidingLineAt(positionY) local line = display.newLine(0, positionY, display.contentWidth, positionY) line:setStrokeColor(1, 0, 0) line.strokeWidth = display.contentScaleY -- Set line width to 1 pixel. return line end -- Creates a red vertical line at the given position within the content region. -- It will not draw the line in the letterbox region. local function createVerticalGuidingLineAt(positionX) local line = display.newLine(positionX, 0, positionX, display.contentHeight) line:setStrokeColor(1, 0, 0) line.strokeWidth = display.contentScaleX -- Set line width to 1 pixel. return line end -- Creates and/or updates all display objects to fit the window. local function updatePositions() -- Update the text object. local pixelWidth = display.pixelWidth local pixelHeight = display.pixelHeight if ((system.orientation == "landscapeRight") or (system.orientation == "landscapeLeft")) then local length = pixelWidth pixelWidth = pixelHeight pixelHeight = length end local message = "Window Size: " .. tostring(pixelWidth) .. "x" .. tostring(pixelHeight) .. " pixels" print(message) print("Content Size: " .. tostring(display.contentWidth) .. "x" .. tostring(display.contentHeight)) print("Orientation: " .. tostring(system.orientation) .. ", Content Scale: " .. tostring(display.contentScaleX)) if textObject then textObject.text = message textObject.size = 0 textObject.x = display.contentCenterX textObject.y = display.contentCenterY else local textSettings = { x = display.contentCenterX, y = display.contentCenterY, text = message, align = "center", } textObject = display.newText(textSettings) -- textObject = display.newEmbossedText(textSettings) textObject:setFillColor(0, 0, 0) end -- To prevent text blurriness, make sure it is displayed on a whole pixel. local xInPixels = textObject.x \* display.contentScaleX local yInPixels = textObject.y \* display.contentScaleY local xOffset = (math.floor(xInPixels) - xInPixels) / display.contentScaleX local yOffset = (math.floor(yInPixels) - yInPixels) / display.contentScaleY textObject:translate(xOffset, yOffset) -- Update the black background rectangle to fit the content region. backgroundRectangle.x = display.contentCenterX backgroundRectangle.y = display.contentCenterY backgroundRectangle.width = display.contentWidth backgroundRectangle.height = display.contentHeight -- Re-position the text object's guiding lines. local bounds = textObject.contentBounds if (textGuideLineTop) then textGuideLineTop:removeSelf() end if (textGuideLineBottom) then textGuideLineBottom:removeSelf() end if (textGuideLineLeft) then textGuideLineLeft:removeSelf() end if (textGuideLineRight) then textGuideLineRight:removeSelf() end textGuideLineTop = createHorizontalGuidingLineAt(bounds.yMin) textGuideLineBottom = createHorizontalGuidingLineAt(bounds.yMax) textGuideLineLeft = createVerticalGuidingLineAt(bounds.xMin) textGuideLineRight = createVerticalGuidingLineAt(bounds.xMax) end updatePositions() -- Called when the window has been resized. Re-layouts the app display objects to fit. local function onResized(event) updatePositions() end Runtime:addEventListener("resize", onResized) -- Called when a key has been pressed/released. local function onKey(event) -- If this is a Windows app, then toggle fullscreen mode via the F11 key. if (system.getInfo("platformName") == "Win") and (event.keyName == "f11") and (event.phase == "down") then local windowMode = native.getProperty("windowMode") if (windowMode == "fullscreen") then native.setProperty("windowMode", "normal") elseif (windowMode ~= nil) then native.setProperty("windowMode", "fullscreen") end end end Runtime:addEventListener("key", onKey) system.activate( "multitouch" ) local touchCircles = {} local function onTouch(event) if (event.phase == "began") then local circle = display.newCircle(event.x, event.y, display.contentWidth \* 0.2) circle:setFillColor(0, 0, 1, 0.75) touchCircles[event.id] = circle elseif (event.phase == "moved") then local circle = touchCircles[event.id] if circle then circle.x = event.x circle.y = event.y end elseif (event.phase == "ended") or (event.phase == "canceled") then local circle = touchCircles[event.id] if circle then touchCircles[event.id] = nil circle:removeSelf() end end end Runtime:addEventListener("touch", onTouch)
The above project will display a circle when you touch the screen. Can you please drag your finger from top to bottom on the screen to verify that the circle is always centered around your finger please? This tests that our touch coordinates are being correctly converted to pixels.
Also note that I *suspect* that your Lumia 550 and 640 XL might display a red or black rectangle onscreen. I say this because the height being reported by Microsoft’s APIs are a little short for those devices. I’m guessing that Microsoft made it that way on purpose and that the bottom navigation bar no longer overlays on top of Silverlight apps like how it did on Windows Phone 8.1.
Thank you! I am unable to download #2860. It is not visible yet… Will test when available.
Lumia 535 output with DeviceName >>>
Resolution Scale: Scale100Percent
Content Scale: 1
Content Size: 480x800
Page Size: 480x771
CoronaPanel Size: 480x771
RawDpiX: 196,645161290323
RawDpiY: 196,645161290323
PhysicalScreenResolution: 480x800
Logical DPI: 96
DeviceManufacturer: Microsoft
DeviceName: RM-1089_1024
Platform: Not Supported Yet / ARM / 8.0 / ANGLE (Qualcomm Adreno 305 Direct3D11 vs_2_0 ps_2_0) / OpenGL ES 2.0 (ANGLE 1.2.0.2446) / 2016.2830
The WP8 CoronaCards daily build with this work-around is available now.
If you can test it out with the above “main.lua” code I posted above and do that touch test, then that would be great. Thanks.