On Sat, Jun 08, 2013 at 09:01:20PM +1200, Ralph Versteegen wrote: > On 8 June 2013 02:26, James Paige <[email protected]> wrote: > > On Fri, Jun 07, 2013 at 09:12:35PM +1200, Ralph Versteegen wrote: > >> On 7 June 2013 03:05, James Paige <[email protected]> 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 <[email protected]> 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 seems better than a really complicated solution. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
