[Ohrrpgce] Android SdlVideoResize=y

Sat Jun 8 20:05:27 PDT 2013

I guess we should probably do that too. Older games don't use "input
string" but input text based scan codes. I see that the
android-onscreen keyboard can be shown without pausing the program,
and SDL will apparently translate the text into keypress events (how
on Earth does that work with autocorrection?).

However I don't much like the idea of allocating screen space to a
button which is of no use to 98% of games.

On 9 June 2013 05:50, Seth Hetu <seth.hetu at gmail.com> wrote:
> You could also just add a "show keyboard" button to the holo-bar when
> the application starts, since SDL "fuzzes" out these menu buttons
> anyway (see my screenshots for the fuzzy effect). Then the user could
> trigger the soft keyboard whenever they want. Obviously not ideal for
> text input, but it might be a good fail-safe.
>
> -->Seth
>
> On Sat, Jun 8, 2013 at 1:42 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
>> 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
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org