[Ohrrpgce] Android SdlVideoResize=y

[Seth Hetu]

When the program first starts, you can click on the "Change Device
Configuration" button at the top of the app (it only appears for a
second with the SDL splash screen). This allows you to change button
mappings, *some* graphics settings (4:3 aspect ratio) and where data
is saved (SD card or internal memory).

There's an option in there to put a "text input" field on your screen
which summons the virtual keyboard when pressed. In terms of summoning
it at will (for hero names, etc.), I don't really know.

-->Seth

On Fri, Jun 7, 2013 at 10:26 AM, James Paige <Bob at hamsterrepublic.com> wrote:
> On Fri, Jun 07, 2013 at 09:12:35PM +1200, Ralph Versteegen wrote:
>> On 7 June 2013 03:05, James Paige <Bob at hamsterrepublic.com> wrote:
>> > On Thu, Jun 06, 2013 at 07:52:15AM -0700, James Paige wrote:
>> >> On Thu, Jun 06, 2013 at 01:35:03PM +1200, Ralph Versteegen wrote:
>> >> > On 6 June 2013 04:53, James Paige <Bob at hamsterrepublic.com> wrote:
>> >> > > I was experimenting with the Android build a little. It runs really nice
>> >> > > on the OUYA. Don't Eat Soap goes the full 18.2 fps, and bell of CHaos
>> >> > > runs at a pretty solid 18.1 fps (on the first screen with no enemies, I
>> >> > > couldn't jump)
>> >> > >
>> >> > > I change the button mappings. I figured there was no point to mapping
>> >> > > any of the buttons to arrow keys because there is already an arrow key
>> >> > > thingy on the left, so just for testing Bell of Chaos I mapped:
>> >> > >
>> >> > > AppTouchscreenKeyboardKeysAmount=4
>> >> > > AppTouchscreenKeyboardKeysAmountAutoFire=0
>> >> > > RedefinedKeysScreenKb="LCTRL LALT RETURN ESCAPE"
>> >> > > RedefinedKeysScreenKbNames="CTRL ALT Enter ESC"
>> >> > >
>> >> > > and tested it on a Nexus 7 at work. It played very nicely. Small
>> >> > > slowdown when a lot of stuff is happening, but still totally playable.
>> >> >
>> >> > Cool!
>> >> >
>> >> > > One thing I have noticed on all three of the devices I have tested is
>> >> > > that the screen only takes up the top left corner, and that there are
>> >> > > black spaces on the right and bottom, like this:
>> >> > > http://i.imgur.com/O7F3NxB.jpg
>> >> > >
>> >> > > I tried setting:
>> >> > >
>> >> > > SdlVideoResize=y
>> >> > >
>> >> > > But it seemed to make no difference. (and I did remember to increment
>> >> > > AppVersionCode)
>> >> > >
>> >> > > ---
>> >> > > James
>> >> >
>> >> > If you want to try stretching the screen, modify gfx_sdl.bas.
>> >> > Currently it asks SDL_SetVideoMode for a buffer the size of the
>> >> > screen, and then uses the highest zoom amount possible. I did that
>> >> > because on my emulator when I only asked for a 320x200 screen it was
>> >> > glitchy with the image cut up into pieces.
>> >>
>> >> Oh, I understand!
>> >>
>> >> I/OHRRPGCE(20248): gfx_sdl: screen size is 1280*736
>> >> I/OHRRPGCE(20248): gfx_sdl: selected zoom = 3
>> >>
>> >> So SDL_SetVideoMode(0, 0, bitdepth, flags) returns the actual
>> >> resolution, 1280*736 and then allocates a screen of that full size. Then
>> >> select_zoom_automatically finds the biggest zoom that fits within that
>> >> size.
>> >>
>> >> ... *testing*
>> >>
>> >> I forced the screen size to 320x200 and zoom to 1, and then recompiled
>> >> with SdlVideoResize=y and it works beautifully on the Nexus 7
>> >>
>> >> http://i.imgur.com/Rsghv3v.jpg
>> >>
>> >> Now if we can just figure out a method that works on both old and new
>> >> devices, or a graceful way to pick between the two screen sizing
>> >> methods.
>> >
>> > Just a thought on this, what if we leave SdlVideoResize=y in the
>> > AndroidAppSettings.cfg and then make gfx_sdl respect the -f command line
>> > option on android to do a 320x200 zoom=1 screen? but when -f is not
>> > specified, it will continue to use the current behavior (although we
>> > probably still do want to center it rather than top-lefting it)
>> >
>> > ---
>> > James
>>
>> I just tried out turning on SdlVideoResize myself, and it works fine
>> on both my phone and all emulator instances. I don't know what caused
>> the problem which I experienced before.
>
> Ah, wonderful! :)
>
>> I'm surprised that I can barely notice the blurriness due to the
>> stretching and linear interpolation, even on text. (It's really
>> noticeable when you take a screenshot and scale it up to 200% though).
>> However I find the change in aspect ratio when 320x200 isstretched to
>> 320x240 surprisingly noticeable; I can immediately tell that tiles
>> aren't square and NPCs are skinnier. Of course the DOS versions of the
>> OHR used to have exactly the same amount of stretching when played on
>> the common monitors of the day ;).
>
> Yeah, I remember back in the DOS days I expected tiles to be non-square,
> and just didn't mind because I knew the pixel count. After the Windows
> port, for a while, running in Windowed mode felt strange to me because
> it seemed vertically squished :)
>
>> So it would be nice to have an option to preserve aspect ratio (though
>> I would still have it off by default I think). SDL's "perserve 4:3
>> aspect ratio" setting does just that: it causes stretching to a 4:3
>> ratio, rather than preserving the aspect ratio of the resolution the
>> app actually asked for. (You can turn the option on and off in the
>> config menu without having to recompile). We could either patch the
>> SDL fork, or put our own black bars on the sides (calculated with
>> knowledge of the real resolution) to preserve the ratio.
>
> Yeah, that sounds good as long as we can switch it at runtime as opposed
> to compile time. What is this config menu you mention? Does the
> sdl-android port have its own built-in config menu? And if so, how do I
> access it?
>
> Oh, this also reminds me, what about summoning the on-screen keyboard. I
> see there are some commands related to this in
> project/jni/sdl-1.2/include/SDL_screenkeyboard.h I think we can use them
> in gfx_sdl as long as we wrap them in #ifdef __FB_ANDROID___
>
> I was thinking we should have a request_virtual_keyboard()
> hide_virtual_keyboard() pair of commands which would do nothing on most
> platforms, but on android would open/close the viertual keyboard.
>
> Then in game, we could call those functions when a hero is re-named, and
> when the "input string" plotscripting command is used.
>
> ---
> James
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org