[Ohrrpgce] Android SdlVideoResize=y

[Ralph Versteegen]

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.

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 ;).

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.