S3 testing

[Crivens]

I'm doing a mobile app that dynamically resizes everything depending on the screen size (9998x9999 in resolution settings for mobile devices). It's targetted at Galaxy S3 resolutions (720x1280) and everything is scaled up or down depending on the device resolution. I've tested it on the PC and a few different devices upto an iPad2 resolution of 768x1024 and a Galaxy S1 & S2 (480x800). No worries.

However I'm doing the app for a mate who works for a company in the UK (I'm in Cyprus) who has shown me it works fine on his S2. But his boss has an S3 and it does not work. Specifically it seems it cocks up the location of touch zones I have setup for it.

Replicating the 720x1280 S3 resolution is a bit difficult on my biggest 1600x1200 screen (note FreeSnap works pretty well for moving windows where you can't see the titlebar and Windows itself won't move it (even with a right click and selecting Move)), but I've noticed that using 720x1280 as a PC resolution everything is not right. Specifically everything is moved up a certain amount, losing the top section off the window. I tested with a standard print command to make sure it wasn't my resizing code, and text at (0,0) indeed doesn't show in the window at all (it does on a lower resolution)

Hmm, just did a screengrab (ALT+PRTSCR) and it's not the right size. On my 1600x1200 screen it is almost fitting perfectly to the whole screen for the interior of the window. ie. the actual window resolution is somewhere around 1200, not 1280.

Is it that GLB cannot compile a window size greater than the Window GLB is running on (incidentally I have 2 monitors with the 2nd one being a lot lower resolution that 1600x1200) and reduces the compiled window to the size of the monitor? If so, and you can bypass that restriction, then brilliant as apps like FreeSnap can move windows around regardless of their size (standard Windows move (right click snapshot image) isn't working on the GLB window in Win7)

I would imagine (waiting on confirmation from the company boss) that the S3 looks perfectly fine but my zone code is incorrect. But obviously this is impossible to test without an S3 or at least a way of testing the higher resolution on my PC.

With the newer iPads and Nexus10 having massive resolutions, higher than most people's monitors, then in the absense of actually owning all these devices then there should be a way to test much higher resolutions than your PC monitor can handle. An app like FreeSnap works ok (annoying but acceptable) if GLB could compile to a much larger resolution, but some kind of PC resize (eg. compile at 720x1280 but have an option for debug mode to show the window at a percentage size) would be ideal for accurate testing of different resolutions.

I am not using the GLB Beta yet (still on latest release version) if it helps.

Cheers

[Ian Price]

Rather than swapping the res to 720x1280 on the pc rotate the screen window on the pc only with SETROTATION 3 (or whatever the command is - I'm at work and can't remember offhand). That way you'll see the whole screen properly (albeit on its side) and can test for mouse presses properly. I did this for my portrait TouchPad apps while testing as my laptop screen wasn't high enough.

Windows mode cuts off some of the screen if your monitor resolution is not large enough (and shows the title bar) - that is probably why you can't see the text at 0,0.

Obviously there's no getting around larger screen resolutions and the average Joe isn't going to buy a monitor that fully supports iPda res just to develop iPad apps. They'll just divide by 2 (or a number their monitor can handle) and double everything. Then hope their maths worked!

[spacefractal]

this is property a windows limit error and Gernot cannot update glbasic about it. Howover you could add some debug orientation using SETORIENTATION which I did in Greedy Mouse for Windows using WASD keys. Its should do the same job.

[Crivens]

Yeah I thought it might also be a Windows thing. It's a good point about dividing the resolution. It's what I did just after I posted this. Just changed the target resolution and the final resolution to get a good replication of the problem.

But there should be something that detects the resolution and either warns you or changes the max resolution to your screen res. Otherwise you could possibly think there is a different bug on higher resolution devices like I did (ie. the S3 didn't lose the title graphics it was a completely different problem). My resolution is 1200 lines and the 1280 of the S3 looked correct in that the window was slightly bigger than my screen (why I used FreeSnap). But it was actually a 1200 line window which isn't terribly obvious. How about putting the exact resolution in the title of the window when in debug mode? That would help as I would immediately know it isn't the S3 resolution.

Another thing though. I use a dual monitor setup, with one monitor at 1600x1200 and the other at a lower resolution. I use the 1600x1200 resolution for full screen GLB coding, but the lower resolution screen is actually the main monitor (because of my job where I use a full screen VPN on the 1600x1200 screen, losing the taskbar which appears on the "main" monitor which is the lower res one). Anyway when I compile GLB the program runs on the lower res monitor (probably because it's the main monitor) regardless of where I kill it off. It must be picking up the max res from the GLB window as they are maxing at 1200 lines. But if I'm testing at a high res that's ok for the 1600x1200 screen but too big for the "main" screen then I always have to move it over. This sucks a little, esp as it seems Win7 (even with the move option from right clicking snapshot image on taskbar) doesn't allow me to move a GLB program. The FreeSnap program I mentioned helps here, but it would be nice if GLB started a program in the last place it was killed off (ie. I could move it to my 1600x1200 screen so it appeared automatically here the next time)

Cheers

[Wampus]

One solution could be to compile the app in a virtual machine. I know in VMWare I can set the desktop resolution to very high like 2560x1920 in Windows 8, 3840 by 1920 in Windows XP, etc. You still need to move the Main VMware window around with scroll bars to see everything but for testing apps in very high resolutions it should work. I'm going to test it right now in Windows 8.

EDIT: Yes, virtual resolutions work fine. I just compiled my Chaos project for 1920 x 1440 resolution in a 2560x1920 Windows 8 desktop and all went well.

[Crivens]

Interesting. Must admit hadn't thought of that. Nice one.

Actually is it possible to do a virtual resolution directly in Windows?

Also can you get monitors at a decent price that go upto Nexus10 levels (ie higher than ipad3/4)? And my laptop is HDMI out. Does that go higher than 1080p?

Cheers

[Wampus]

I'm sure its possible to hack a way to do virtual screens in Windows 7. In fact, OS virtualisation might be less problematic to set up.

Some laptops can deal with having very high resolutions set by scrolling to reveal the hidden parts of a screen when the mouse reaches the edge of the screen.

AFAIK monitors that go up to the Nexus10 resolution are horribly expensive.

[Crivens]

Hmmm so no pan-and-scan mode like on XP?

Cheers