Windows builds not working after a recent daily build & window size issues

Solar2D Win32 Desktop
#1

Hey,

I had recently updated Corona to v2015.2777. Following the update, all attempts of building for Win32 have failed. According to the console log, “Everything is Ok” and “Win32 desktop app build succeeded”, but when I actually start the application, the application window remains frozen.

I just updated Corona to v2015.2786 and the problem is still present. I asked my colleague, who is using v2015.2731, to try and build the application for Win32 and his Win32 application runs smoothly. We are using the same game resources in our Win32 builds. Prior to updating from v2015.2731, I was also able to build the game for Win32 without any issues.

Also, trying to assign defaultViewWidth = 320, defaultViewHeight = 480, which match our config file values, into the game’s build file does not seem to work. The resulting window actually has height of 720 and width of 480 (see attached screen1.png). I decided to tweak around and see if I could find the problem so I changed the values to defaultViewWidth = 500, defaultViewHeight = 500. The resulting window now has height of 750 and width of 750 (see attached screen2.png). This would suggest that both values are multiplied by 1.5 in both cases. Is this a bug or am I missing something?

Regards,
Eetu
 

#2

I’m wondering if you are running into the same issue as this Corona developer here…

   https://forums.coronalabs.com/topic/60286-corona-win32-beta-app-build-issues/

We’re not able to reproduce this issue, but the other developer discovered that the “Icon-win32.ico” was causing the issue.  Try temporarily moving it out of your Corona project directory and rebuild your app.

#3

I perused that post earlier today.

I have tried building with and without the “Icon-win32.ico” and it does not seem to matter either way. My colleague was, however, able to build and run the application both times. Unlike the gents on the other thread, I am running Corona on Windows 10, if that makes any difference (my colleague uses Windows 8.1).

#4

The one thing I’m confused about is that you say it’s frozen, but you posted screenshots of your app working.  This tells me that your app started up just fine.  Are you sure you’re not running into a Lua runtime error on startup?

By default, runtime errors are displayed via a native alert dialog unless you have them disabled in your “config.lua” file via the “showRuntimeErrors=false” setting.  Make sure that’s turned on.

Also, we’ve made a breaking change in build #2741 for Win32 desktop apps where the “build.settings” window width and heights. These settings used to be handled inconsistently between Windows and OS X.  These widths/heights on Windows used to be set relative to portrait like the “config.lua” file.  We’ve changed it to be taken as-is instead (relative to the desktop) like how it works on OS X.  So, if you’ve upgraded from a build older than #2741, the you may need to flip these widths/heights.  The good news is that it’ll now work consistently with OS X apps.

#5

Apologies, the confusion is all on me. I ran the game using Corona.Shell.exe to take those screenshots to demonstrate the window size issue.

If I build for Win32 on my computer and then run the game, it does freeze on start (i.e. I just see a black screen). I am currently residing in the UK and it is getting close to midnight now so I will be turning in for the night. I will try to see if I can find a solution to this issue tomorrow and I will post here if I do.

#6

I would make two suggestions to help narrow down the problem:

  1. Uninstall the current build and install build 2731 on your own machine to make sure it still works with the same project that is not working now. Sometimes you make code changes that you think are minor and it causes problems.

  2. Try building one of the sample apps with the build that you think is causing problem and see if it works. Try some of the physics samples that generate motion and allow interaction,

#7

I’m wondering if you are running into the same issue as this Corona developer here…

   https://forums.coronalabs.com/topic/60286-corona-win32-beta-app-build-issues/

We’re not able to reproduce this issue, but the other developer discovered that the “Icon-win32.ico” was causing the issue.  Try temporarily moving it out of your Corona project directory and rebuild your app.

#8

I perused that post earlier today.

I have tried building with and without the “Icon-win32.ico” and it does not seem to matter either way. My colleague was, however, able to build and run the application both times. Unlike the gents on the other thread, I am running Corona on Windows 10, if that makes any difference (my colleague uses Windows 8.1).

#9

The one thing I’m confused about is that you say it’s frozen, but you posted screenshots of your app working.  This tells me that your app started up just fine.  Are you sure you’re not running into a Lua runtime error on startup?

By default, runtime errors are displayed via a native alert dialog unless you have them disabled in your “config.lua” file via the “showRuntimeErrors=false” setting.  Make sure that’s turned on.

Also, we’ve made a breaking change in build #2741 for Win32 desktop apps where the “build.settings” window width and heights. These settings used to be handled inconsistently between Windows and OS X.  These widths/heights on Windows used to be set relative to portrait like the “config.lua” file.  We’ve changed it to be taken as-is instead (relative to the desktop) like how it works on OS X.  So, if you’ve upgraded from a build older than #2741, the you may need to flip these widths/heights.  The good news is that it’ll now work consistently with OS X apps.

#10

Apologies, the confusion is all on me. I ran the game using Corona.Shell.exe to take those screenshots to demonstrate the window size issue.

If I build for Win32 on my computer and then run the game, it does freeze on start (i.e. I just see a black screen). I am currently residing in the UK and it is getting close to midnight now so I will be turning in for the night. I will try to see if I can find a solution to this issue tomorrow and I will post here if I do.

#11

I would make two suggestions to help narrow down the problem:

  1. Uninstall the current build and install build 2731 on your own machine to make sure it still works with the same project that is not working now. Sometimes you make code changes that you think are minor and it causes problems.

  2. Try building one of the sample apps with the build that you think is causing problem and see if it works. Try some of the physics samples that generate motion and allow interaction,