Just to chime in: When I worked on my (highly experimental) port of the OHR to Java Mobile, I had to deal with resolution issues right off the bat, since there's no standard phone size.
The number one problem I ran into was choosing whether to stretch resources or not. Backdrops usually had to be stretched to fit the phone's native resolution, since they were designed to be seen in full. Maps, on the other hand, could _usually_ just be scaled by a constant factor, and if the phone's resolution wasn't a direct multiple of this then a row or two of tiles wouldn't show. In regards to Ralph's concern about engine support, I know that Android supports some kind of resource naming scheme that allows you to get a resource at a specific resolution without too much of a headache; it simply scales another resolution if the one you requested doesn't exist. Regarding users scripting the engine into an "invalid" resolution for phones, perhaps you could have them request the scale factor they want? Like: my_resolution = GET_RESOLUTION(4:3) ...this will return the highest quality resolution the current device supports at a ratio of 4 width to 3 height. Just a note to Pete that I rarely look at the FB internals to the OHR, so these ideas should all be taken with a grain of salt. -->Seth On Thu, Oct 20, 2011 at 9:31 AM, Ralph Versteegen <[email protected]> wrote: > On 20 October 2011 05:06, James Paige <[email protected]> wrote: >> On Wed, Oct 19, 2011 at 08:49:30AM -0500, Pete Michaud wrote: >>> Hey everyone, this is my first message to the list, but I've been >>> watching >>> and tinkering with OHR practically since its original release. Pre shops! >>> Anyway, I am toying with the concept of making the resolution larger, and >>> I searched the list already and found a couple mentions of it, but I got >>> a >>> strong "thar be dragons" sense. Nothing specific, just >>> "Let's change resolutions, maybe" >>> "I'd rather stick my face in the microwave" >>> Too much hard coded to assume 320x200? worried about backward >>> compatibility? >>> If I do it, I'd like to know what I'm getting into, and maybe get some >>> help on where to begin. I already have all the source and everything I >>> need, but as you know, it's a little hairy in there. I'm sure gotchas >>> abound. >>> Thanks a lot, >>> Pete > > Hello! Always pleased to see someone willing to help! > > We're not as pessimistic about supporting more resolutions as you make > out. In fact it's something I'd like to get done within the next, say, > 5 months. > > All of the builtin menus in Game need to be replaced with slice > collections. Eventually we'll allow people to customise these, but at > first they'll be fixed. So this would be a good place to help (both > creating the slice collections, and rewriting the menus to use them), > in fact it'll be the bulk of the work. However, we haven't worked out > how slice based menus are going to work (how do you specify where they > menu items go? Will they be laid out in code, or by copying a template > slice?). I started on that recently, and I'll get back to work on it > when I find the time. > > James already created wip/battle_layout.slice and also a collection > for shops which it seems he didn't upload. Note that these are > examples and not what the real slice collections will look like. The > real collections have to be robust to different resolutions, font > sizes, number of menu items, UI colours, global strings, and so on. > > BTW, shift+! does not work in gfx_directx, you have to use a different > graphics backend (eg. "-gfx sdl") > >> Hi, Pete! Right now there is no way to change resolution with scripts. >> There is a secret debug key you can use to change resolution; SHIFT+1+R >> and then drag the corner of the window. Obviously that is not suitable >> for a distributed game. >> >> We do indeed plan to allow games to choose other resolutions. Here are >> the obstacles blocking that feature that I can think of off the top of >> my head: >> >> * The battle system would still be 320x200, with empty space around its >> edges. >> * Built-in menus like inventory, equip, shops, etc would still be >> 320x200 >> * We can't yet display text at any size other than 8x8 pixels. > > Well actually we can, aside from the issue of fonts. Of course, > everything that's hard coded for an 8x8 font needs to be updated, but > switching to text slices solves that for free! > >> * We would like to support portable versions like Android and iOS >> sometime in the future, and we don't want to allow people to use >> resolutions that couldn't work on those. > > *don't want to allow people to use those resolutions without being > aware that their games won't work on those. > >> * We want to make sure we have thought out all of the backwards >> compatability issues with this before we proceed > > Well, are there any? If all existing games continue to run at only > 320x200, there shouldn't be any problems. > >> All of those issues can be solved. >> >> --- >> James >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
