I have been been programming with java using eclipse for a few months and would consider myself at an intermediate level, and i have a vb.net background originally.
I have a question about screen resolution( in pixels) and auto-scaling my application with two parts
A) When you design a desktop application with swing( or JavaFX ) do you actually calculate the pixel width and height of every single component and then scale it up or down in code by detecting the screen resolution at startup? Scene-Builder for JavaFX, Eclipse Windows Builder Gridbag layout and GroupLayout have the facility to do it with a couple of clicks, and it is relatively easy . If it IS calculated and handcoded then that means I'll have to spend a lot of time planning ahead for each control.
B) Is there a common consensus over a screen resolution ( 1024x768 e.g.) to design the application for "initially" ( and then scaling all controls according to detected screen resolution)? My monitor has 1920x1080 resolution but I am confused which resolution should i begin designing my application in. 1024x768 seems reasonable to me.
Thank you very much for your time
I've done all my work in Java Swing, so this might not be appropriate for other GUI sets.
Layout all the components within panels and one frame.
Pack the frame.
Print out the size of the frame.
If the frame is too big, put some components in a scroll pane.
Repeat until the frame is the desired size.
In other words, I'm concerned with the functionality of the GUI. I don't care how big it is, unless it's too big for a display.
I put together an alarm clock that has a frame of 170 x 152 pixels. It sits in the lower right hand corner of my display.
I put together a clock / calendar that has a frame of 1097 X 522 pixels. It sits in the upper right hand corner of my display.
I put together a Cobol Paragraph Structure display where I maximized the frame to the size of the display, mainly so the paragraph name tree had the maximum amount of space.
Related
Trying to get Gameboy resolution which is 160px x 144px in unity and then the game will scale up when in full screan with bars around the side where the aspect ratio doesn't fit. But it still only has 160 "pixels" just scaled to take up however many pixels it takes
You could start by reading the documentation file on "Resolution and Presentation"
here is the link: https://docs.unity3d.com/Manual/class-PlayerSettingsAndroid.html#Resolution
and this forum page also seems to be helpful:https://forum.unity.com/threads/target-dpi-vs-render-scale-vs-resolution-scaling-fixed-dpi-factor-vs-setresolution.1076789/
Now based on these two I would consider this to be your solution:
Go to Edit > Project Settings > Player (on the left list) > Resolution and Presentation
once you are here find the Resolution Scaling Mode option and set it to Fixed DPI as shown in this Image
Once you do that you get the option to choose a number between 30 to 1000, which you would decide based on the output screen you target. If the number you set is lower than the screens native dpi, your game will upscale and by the same reasoning, I would say it would downscale if you set it higher than the native dpi of the target screen. I am not 100% sure this is the solution to your problem, but I hope it sets you up on the right direction.
I need to determine the dimensions of a full-screen application window on a display with a camera housing notch. I'm using a Mac Book Pro (14-inch, 2021) but I'm looking for a general technique. Crucially, I need to do this from outside the full-screen application itself before it is launched, so I can predict the window position in advance in an application testing/screen-capture scenario.
The full screen size including the notch region is reported from NSScreen frame as 1512x982. The safeAreaInsets are reported as top = 32.0 with the other three edges being zero. Subtracting the top inset gives a size of 1512x950, yet full-screen applications (I'm using Chromium) report a maximised window size of 1512x945, which is what we might expect as it has a 16:10 aspect ratio. For example, SwitchResX allows setting the resolution to 1512x945 HiDPI 16:10 to ignore the notch area.
The regions returned by auxiliaryTopLeftArea and auxiliaryTopRightArea also have a height of 32.
Confusingly, visibleFrame reports 1512x944 (not 945) and I'm not sure where the one pixel discrepancy is coming from.
What API calls can I make to determine the dimensions of the full-screen application area?
I'm making a small game of the single-screen, shoot'em up/platformer sort with javafx, and i wish to make it work on screens with different resolutions. All my graphics are made of java shapes in a single Pane, whose positions on the screen are determined by coordinates which correspond to pixels. I'd need the gameplay to be consistent accross platforms, but I'm having trouble since, for example, a velocity of 10 pixels per unit time is faster on a smaller resolution.
The only solution I can think of with what I know is multiplying everything by a ratio between some constant and the resolution, but that seems a little sloppy, so I'm wondering if there's a better way. Could I, for instance, have the game run "internally" at a constant resolution to get the math consistent, then scale that to fit whatever screen the player is using?
Your solution of rendering at a constant scale resolution is generally how it is handled with different aspect ratios getting different treatments in emulators and such. Sometimes revealing more of the background image or adding side bars so the playable space remains constant and it is only upscaled for view.
In general though the way this is best accomplished with modern hardware is probably abstracting away 'pixels' entirely from your game layer. Your game should move '10', 10 what? 10 units. Then when your rendering engine comes in behind it the renderer knows 10 units = 10px or 20px or whatever scale factor. That way your game pieces only worry about playing the game, while your rendering layer worries about how to write it all to image. Then you just have to worry about handling different aspect ratios which you really have to account for no matter what.
Typically with games the only time I use pixels directly is with UI elements.
I am developing a game that uses levels. The levels are made at a default scene width and height resolution.
The thing i am worried about is when the game is played on IPads iphone 5′s etc, the position of sprites loaded from the level xml files will be out of place due to the screen size.
In my case, could someone tell me the best thing to do in this situation or some advice on the approach i should take?
Also if any has experienced this, please let me know.
Thanks. :)
Generally this has nothing to do with how or where you store the level data.
These are the standard approaches, which one works for you depends on your requirements and desired results:
design each screen resolution individually (error-prone, tedious)
design for one screen resolution, then scale up or down according to screen aspect ratio (can lead to skewing as the screen size scaling for width & height are likely to be different)
design for the smallest screen resolution, then center the contents on the screen (this leaves unused areas either at the top/bottom or left/right sides)
same as above, but zoom content to fill the screen (this will remove the letterboxing, but also partially remove one side's content from the view)
In essence this is the same problem as movies have in trying to fit to screens of varying aspect ratios.
In general this is all a matter of scaling the input (positions) to a desirable output. The easiest approach is to maintain aspect ratio and allow for letterboxing. However Apple may reject letterboxing apps if nothing is done to hide the letterboxes (black areas) since Apple requires apps to support widescreen resolution, and letterboxing does not normally fall into their definition of "supporting widescreen".
In IB, there is a dropdown in Size Inspector showing "Layout" and "Frame". I know what a frame is, but I don't know what the layout is in this case. What is the difference?
When lining controls up and measuring their distances from each other it's often desirable to think about the controls' locations in terms of the visual space they occupy on the screen, rather than simply their raw frames. In many cases, the visual rectangle a control occupies, and its frame are vastly different. For example, a regular size push button looks to be about 20 points tall on the screen, with a 2 or 3 point drop shadow. In reality, the frame of a properly configured push button is 32 points tall, not ~23. This extra 9 points points of padding isn't visually apparent.
"Layout Rectangle" is the name Interface Builder uses for this concept.
The layout rectangle is useful to look at for applications of measuring and sizing. The Apple Human Interface Guidelines might make the statement that "Two push buttons aligned vertically, and horizontally next to each other should have 12 points of space separating them horizontally." This 12 points of space separating the buttons should be measured from the button's layout frames, not their raw frames.
Many built-in IB elements have a separate "layout" versus "bounds" rectangle. You can see the difference by showing them using the "Layout>Show XXX Rectangles". The drop-down indicates which rectangle the coordinates refer to.
On Mac, this impacts UITextFields that are labels for example. If you switch between Layout and Frame, the X coordinate will change by 3 pixels. I haven't played with iPhone controls to see if it impacts any of them. It doesn't come up a lot.