How to handle PlayN, JBox2D and image scaling....

[Ned Wolpert]

Folks-

  I've got a framework for my game setup now that uses PlayN with JBox2D and have the physics working where I want it. (Its effectively a 'drop' game.) I started with the Pea's showcase example as a baseline. The physics are fine, but I'm running into trouble trying to figure out how to handle all the different screen sizes and resolutions out there, and wanted to see if someone else has some advice on how to proceed.

Currently, I calculate the 'width' of the jbox2d world by taking the real graphic width and scaling down via the physUnitPerScreenUnit variable. Then when I pull in the data the describes the physical environment, I then convert it to scale against this width.  I think I might change it so that the jbox2d width is static (like 10.0f) and change the physUnitPerScreenUnit based on the real graphic width.  I do the same thing for height. This way I can use one set of coordinates for the data the describes the playfield, everything is related to where each other thing is in a consistent fashion regardless of screen resolution.

The problem really is two fold.  First, screen sizes can be more then just 'scale'.... some screens comes with a  4:3 aspect ratio versus widescreen. Second, I haven't been able to scale the images in the same manner, so a 640x480 screen has less space between objects then a 1080x720 screen. (I think I can apply the same logic to the image scaling that I do to the jbox2d world scaling)  This is all compounded by the fact that I want to be able to use box2d-editor 'https://code.google.com/p/box2d-editor/' or rube (https://www.iforce2d.net/rube/) to edit the physicals bodies and playield and pull that data in. (Though all the examples are for C++, I think I can change them to work just fine for jbox2d)

Has anyone tried to go down this path? Any dragons I should be aware of? Or is it a fools errand.... do I need to make different playfields for different aspect ratios? Special buttons on the 19:6 widescreen space that you don't see in the 4:3 space?  (FTR, I don't mind some 'stretching in the 4:3 -> 16:9 differences, as long as 'circles' still are 'round' and not oval, which is what I have now) 

Thanks for any advice you might have.

Ned

[Ned Wolpert]

I keep playing with this issue and I'm wondering how other people deal with multiple screen sizes and their game. Do game developers simply manage the same playfields for different screen ratios? (4:3 vs 16:9)?

--
 
---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Virtually,

Ned Wolpert <ned.w...@codeheadsystems.com>

[Michael Bayne]

On Wed, Jan 15, 2014 at 2:03 AM, Ned Wolpert <ned.w...@codeheadsystems.com> wrote:

I keep playing with this issue and I'm wondering how other people deal with multiple screen sizes and their game. Do game developers simply manage the same playfields for different screen ratios? (4:3 vs 16:9)?

I don't have any advice for physics related things, but I usually take the following approach with regard to UI:

The idea is to design your screens to support a maximum size of 384x568 in "display units", but ensure that all of your content fits into a (centered) 320x480 "display units" region in the middle of the screen. Extra space is either used up in the standard UI way (larger scrolled views) where you can, or decorated with border fluff in situations like a fixed game board that can't be expanded.

If you have fixed art backgrounds (like I did in Spellwood), you can have them bleed all the way out to 384x568, but still look reasonably when cropped to their center 320x480 pixels. Like this Spellwood background for example:

This ensures that you're never changing aspect ratios which will make your game look horrible, and keeps your scaling to moderately sane values (particularly on iOS).

This is an iOS-centric approach, because it prioritizes "natural" scalings on iOS, at the expense of some unnatural scalings on Android (1.5x, 2.5x). 2.5x isn't so bad because you're up in Retina resolutions there, but 1.5x is a little bit janky. YMMV.

This is also a phone-centric approach, because it assumes you want to design your UI to work reasonably well on a phone, and then just make things bigger on a tablet, rather than redesign for a tablet to keep a similar "finger size" and totally rearrange your UI to make use of the extra space. Obviously if you have the resources for that, or your game affords arbitrary expansion (you have a scrollable playfield that you can just "show more of"), then great. You don't have to do this cheap hackery. But if you don't have that luxury, this is a low-effort way to achieve a result that will not make graphic designers throw up in their mouth.

Also on Android, there are more actual screen resolutions than you will ever be able to anticipate, thus you have to make a best effort to choose a scale factor that keeps things from spilling outside your maximum supported size (384x568) while keeping scalings to sane values (not something like 1.634x). I just punted with regard to the latter situation and allowed arbitrary scalings, but most Android screens are dimensioned such that you end up with semi-sane values like 1.5x or 2.5x (because they tend to use 480, 1024, 1920, etc.), so it only suffered in the rare cases.

Also with regard to art assets, I just shipped everything at @2x resolution. So all my backgrounds were 768x1136 and all the other art was keyed to that size. This ends up looking great on Retina iPhone displays (and non-Retina iPad, which is treated like an @2x Retina display), and "good enough" (IMO) on HiDPI tablet displays (where you have absurd numbers of pixels). As long as you render text via PlayN (which will render it at native resolution), then text looks ultra crisp and your images (even if cartoony like in Spellwood) look pretty good even when scaled up for the tablet display. Shipping @4x assets is not worth it, IMO, because it increases your game size by 400% at nowhere near a 400% improvement in "looks".

-- m...@samskivert.com

[Ned Wolpert]

Thanks for the info Michael, that's helpful information. 

My current approach is going this way... I'm building up the game assuming a 4:3 (12:9) screen size, but the graphics canvas ratio is set to 16:9. So, 12:9 is effectively the game field jBox2D operates under, and the remaining 4:9 is auxiliary graphics and stats that the people with 4:3 devices won't have.  (Read that as: fun blinky graphics)

The background components aren't really able to be cropped. So I'm going to have to scale as I can.

I have the jBox2D/PlayN side down now... given weird resolutions, it looks good and plays well regardless of resolution, but if its not 4:3/12:9 or 16:9 aspect ratio, it's going to be off a bit. (I can give the playfield a bezel I suppose, :-/ I'll have to see as I build it out. Maybe I'll use your cropped background image idea there, and place the playfield on top)

Still no good solution for the box2d-editor stuff... I did come up with a 4x3 base, and recalculated the physUnitPerScreenUnit to match to the device drawing on the playfield. For now, I'm hand-drawing the components out on graph paper and translating the coordinates into the json levels I have. Its actually not a bad technique as it forces me to pay more attention to some detail I was ignoring with the editor.

--
 
---
You received this message because you are subscribed to the Google Groups "PlayN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to playn+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.