[Ohrrpgce] Android SdlVideoResize=y

Sat Jun 8 10:42:16 PDT 2013

On 9 June 2013 04:00, James Paige <Bob at hamsterrepublic.com> wrote:
> On Sat, Jun 08, 2013 at 09:01:20PM +1200, Ralph Versteegen wrote:
>> On 8 June 2013 02:26, 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
>>
>> Yes, that's a good idea.
>>
>> This would be the first instance of patching a game's scripts. We'll
>> have to replace any script named "input string" with the
>> android-specific version. Doing so based on checksum isn't really
>> possible because the script calls other scripts, which have variable
>> script IDs. (scanscripts.py shows 38 different checksums).
>
> I think it would be best to just hook up the android keyboard trigger to
> the "enable input text" command. I know that command is only about a
> year old, so it would mean that people who used "input text" in their
> scripts would have to re-compile them before publishing on android.

But that's not what "enable input text" does at all. I don't know if
anyone has actually used this command, but you're meant to call it at
the beginning of the game, not at the point that you call "input
text"... in fact, doing that won't work. So I think it's something
that should be a new command if added at all, but that changing
inputstring is better.

> But that seems better than a really complicated solution.

If you mean "patching" scripts, that's not complicated at all. Iterate
through the scripts when loading the game, find one named
"inputstring", provide an alternative compiled .hsz file.

> ---
> James
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org