The number of high res device is growing and it’s really becoming a problem testing into the Game window with resolutions like 2160x1440 (microsoft surface pro 3) or 2048x1536 (ipad retina) or 4K - 3840 X 2160 fullHD tvs (1920x1980) running totems with windows/mac/linux without having two monitors with really high resolution or keeping the output device connected.
Solution 1:Adding a zoom in/zoom button will resolve this problem.
Solution 2: add a couple of scrollbars when the selected device size exceeds the game window size will solve the problem too.
Both solutions wont’ change the real resolution detected by Screen.width and Screen.height.
eg: a plugin like xArms detaches the window and changes the windows size according to the selected sizes via code.
A native solution will be resolve this issue forever allowing to test on every monitor resolution without the need to have high res monitors or testing every time with the device connected.
Yeah, I do think that something like this is getting more important as time passes. High-res mobile displays are a fact of life for developers now, even though many of us are using 1080p screens or smaller. Even an iPad 3 in portrait mode, which has been around for a while, doesn’t actually fit on my newish 27" monitor.
Having the game view optionally display via a render texture, and allowing us to zoom in and out would be super handy. If I need to check something with pixel precision I probably don’t need to see the whole screen, and if i need to see the whole screen I can probably live without pixel precision. At the moment, I have to work at a different resolution and just keep testing that things scale right when I deploy to device. It’s not the end of the world, but it’s something that could be smoother.
Definitely would come in handy. Although, to me the priority should be for unity to play nice with 4k/5k monitors which would also solve this problem. While I have at least 2 test devices per platform 4K monitors are starting to become more reasonable in price (just under a 40" 4K display for $299 was a common deal I kept seeing for the holiday shopping season). At those prices it’s approaching a 4K monitor for the price of a test device.
I think that would solve a different problem. The problem I’m referring to is a lack of resolution independence for the purpose of testing in-editor. For instance, if you’re developing on a laptop with a 1366 x 768 screen (common on cheap ones) then there’s really no way to effectively test for high-res mobile devices, or even for a standard 1080p screen. Even if you have a higher res screen, because there’s no scaling options you can’t see stuff at the real-world physical size unless you deploy to device.
It’d be great if we could render at our target resolution, then display the rendered image at whatever size we wanted. With render-to-texture that should be pretty straightforward. It would also allow us to match physical size, or 1:1 pixel, or expand/shrink the display for convenience. It’s separate to how well the rest of the editor plays with high-res displays (though I agree that may also be an issue).
Unless I’m misunderstanding the distinction I think they are the same problem (just a different solution) Just handling high resolution displays keeps the same non dynamic approach (no scaling) which leaves out if your development machine is lower resolution than the end device (if it’s higher than you can always set the resolution to a 1:1 pixel it’s just the game window won’t use the whole display).
You can never match real-world physical size because displays have different PPI (some of the PPIs nowadays are an insane 500+ and this does make a difference). As far as making it a 1:1 pixel (same resolution) it is always possible provided the editor display resolution > end device display. If you change the pixel ratio (with scrollbars/zoom lets say on a 1:2 ratio) of course you can expand/shrink the views size and this would be nice but I wouldn’t say it would ever match the physical size in a true apples to apples fashion because of the PPI difference. The same resolution at different screen PPI does change impressions and this can never be overcome in the editor.
I agree this would be a great feature to have (although as cost drops I would think everyone would rather have no scrollbars/zoom needed) if they can afford it. However, obviously budgets are always tight and this would be a major upgrade for those that are stuck with low resolution displays. You’d only want to use this when you are smaller but close to the end resolution otherwise your only looking at a corner of the screen and mostly scrollbars. You’re 1366 x 768 example to say mobile QHD would mean you’d only be seeing 1/4 of the screen at a time. While it’s better than nothing that’s going to be a lot of scrollbars.
Yes, you can match physical size. You just can’t do that at the same time as showing 1:1 pixels. That’s why I suggested three options: match physical size, or 1:1 pixel, or expand/shrink the display for convenience. For an example, see any image editing application - you can zoom, or you can snap to print size (assuming it knows your screen size).
Is my 27" iMac really a “low resolution display”? Because I can’t display a whole iPad 3 image on it, let alone some of the new Windows tablet resolutions.
Here’s a use case. I’m putting together a UI for a retina resolution iPad. The options I’d like to be able to use, on my 27" screen, is:
Have the image in the Game window rendered at retina resolution, but then be scaled to match the size of a retina iPad’s screen in width and height. It is ok that the pixel density is different, because I’ll be using this for composition and size.
Have the image in the Game window rendered at retina resolution, then displayed at 1:1 pixel size with scroll bars or similar. It’s ok that this will be far wider and taller than an actual retina iPad’s screen, because I’ll be using this where I need to tweak individual pixels.
Have the image in the Game window rendered at retina resolution, but then scaled up or down arbitrarily as is convenient for whatever I’m doing at the time.
Have things displayed exactly as they currently are.
At the moment there are workarounds so I can get the job done. But why have workarounds when an RTT and some standard scroll-and-scale controls could give us the best of everything?
I definitely agree that this would be useful. I was just indicating a preference to support high resolution displays. Obviously both can be done and would be useful.
Yes, I meant the two together sorry if I wasn’t clear. All of your usecases make sense to me and would be welcome without needing a workaround. The one caveat that you are still going to prefer a 4K display for is when you scale it down to physical size. Obviously, if you do this on a 27 inch 1080p monitor vs a 4.5 inch phone(to make the math easy 6x less) handheld you are using 320 x 180 pixels to get 4.5 inches. That render texture is going to be quite small/blurry. The typical viewing distance differences between the two (~3 feet for monitor and closer for phone/tablet) will also come into play. Using it for composition or not it will still not be ideal.