Thread: [Fremantle Maemo5] [Pre-Announce] FastDOSBox 1.6
View Single Post
Posts: 19 | Thanked: 24 times | Joined on May 2014
#42
For testing fullscreen games and quitting easily, power-key menu button still works, and after you disable it, you're on desktop. You can close dosbox quickly via normal X in taskmanager, or return to dosbox - if you use power key menu once, all your Maemo's special keys (volume, camera button, ctrl+backspace) will be working 'till you restart dosbox.

One caveat - cycles=max (or cycles=auto, as it's exactly the same as max for non-timered games) goes crazy if you minimize or change volume, namely cp your cycles to some very low ammount, and doesn't rise it 'till dosbox restart. Setting cycles manually (with or without fixed) prevent it and you can minimize/change volume/etc. as often as you want.

Now, it wouldn't be a problem, as we have discovered that setting cycles manually is always better than relying on auto/max for Maemo, right? Sadly, not so right anymore. I just run into 1st (non-timered) game, that works worse on 5500 cycles (@900 mhz device), than on auto/max. Namely, Prince of Persia 2. It works like a charm with max (unless you minimize...), but much slower on 5500. Tests revealed, that it works the same as with cycles=max, when manually set to 2000 or 3000 cycles. It's still prefferable to auto/max, as it doesn't suffer slowdown after minimizing.

So, my theory, that cycles=max sets our cycles too high might be, in fact, just proven wrong. Or not, as we have no way (on Maemo) to see what max is exactly doing. Possibility to see number of cycles set (for example, in terminal, if special debug option is set in config) while using auto/max would greatly help in debugging.
---

From a different barrel - Pirates (gold edition) have mouse problems, but strange ones. Horizontal axis works completely right, while vertical axis seems "shorter" (no matter what, you will be never able to click anything on upper 1/3 of screen). Frst time I see cursor to actually drift *behind* touch point, and increasing the offset with every milimeter. Strange thing, probably some completely custom (and utterly broken) mouse handling coded in that particular game.

Also, different (but still troublesome) variable de-sync happens while using windows 3.1 or 95. Could anyone remind me, if there was a remedy for it found? I vaguely remember something to be installed on (emulated) windows side... Javispedro?

Side note: No idea why we're playing with windows in dosbox, if we could, probably, do it more effectively in qemu. For even more efficiency, qemu architecture-only emulation+wine, for particular programs instead of whole windoze. I remember guy actually PoC'ing it to the point of playing windows solitare via qemu+wine, with awesome (compared to windows in dosbox) performance.

Last edited by bla1; 2014-06-09 at 21:00.
 

The Following User Says Thank You to bla1 For This Useful Post: