On 9 June 2013 17:37, James Paige <[email protected]> wrote: > On Sun, Jun 09, 2013 at 02:53:40PM +1200, Ralph Versteegen wrote: >> On 9 June 2013 05:55, James Paige <[email protected]> wrote: >> > On Sun, Jun 09, 2013 at 05:42:16AM +1200, Ralph Versteegen wrote: >> >> On 9 June 2013 04:00, James Paige <[email protected]> wrote: >> >> > 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'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. >> > >> > Oh, I guess I misundersttood that command. It is definitely used by >> > the latest iplementation of "input text" >> >> (You mean "input string". Also, in any previous emails in which I said >> "input text" I meant "get input text"). Oh, I forgot that I had >> actually used it there. >> >> >> > 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. >> > >> > Ah, well if that is easy, then I can't possibly complain ;) >> > >> > Seems like that would only work for patching scripts that only call >> > built in functions, and do not call any other scripts in plotscr.hsd >> > >> > Aren't the id numbers for compiled scripts allocated dynamically at >> > compile-time? >> > >> > --- >> > James >> >> Are you talking about replacing script based on checksum? As I said, >> because the ID numbers are variable the only realistic solution is to >> replace based on script name. > > Nah, I understood what you meant about replacing by name. > > I was thinking about references to a compiled script from a compiled > script. I don't think that is actually an issue with "input string", I > was just wondering about how scripts that call each other store the > reference to the script that they are calling. > > I know in the older implementations of hspeak, scripts called each other > using autonumbered id numbers, and those could change if you recompiled. > I don't know if that is even still the case anymore. > > --- > James
That hasn't changed at all. But you simply figure out the ID number of inputstring, and overwrite the original <id>.hsz with a replacement. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
