Notices

i did test 800x480 vs 640x480 when testing existing mouse patches but not since.

i tend to run windowed as it is easier to quit. some titles make you start a new game before giving the option to quit to dos. the usable screen is therefore positioned to bottom left of the screen. as a result my offset seems to cause cursor to display to the right and up from where you actually click.

i'm thinking the working games must initialize the mouse to the centre of the screen when launching. still need to look into dummy event or warpmouse calls

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.

i've been playing a bit this morning. there is afaik no calls to sdl_warpmouse. mouse_reset seems to set position and constraints using mouse_newvideomode as well. in either window or fullscreen, max mouse seems to be set to 639,199.

I wrote the following mouse.drv replacement that "talks" to the mouse patches I made. It'll probably work with any 3.x windows released after the "for Pen" editions. I remember testing it once with 3.1.
http://depot.javispedro.com/dosbox/w3x-mouse/

EDIT: Seems that I announced this on http://talk.maemo.org/showpost.php?p...&postcount=695 .

qemu for arm was awfully slow in early days. Dunno about now.

Note DOSBox runs most BIOS code in ARM while qemu would not, and even some DOS code. Obviously for 9x upwards that doesn't matter that much.

Android_808, any plans to push your latest dosbox build into -devel? As said earlier, it not only works much faster, but also fixed (most of) mouse desycn-on-borders issues - with no regressions, as it seems. Really no reason why it shouldn't land in extras*.

BTW, I still wonder why cycles=max doesn't work OK in Maemo's dosbox build, and we need to finetune max cycles manually... Is it possible, that dosbox calculates max cycles on the lowest frequency at the moment of starting up, and doesn't scale up afterwards? (so, if I have limits 500-900, it sets cycles for 500 mhz, ignoring fact that device jumps to 900 half a second later)

Or someone have better explanation of WTF could be happening?

/Estel

Sorry estel, missed your latest reply.

I don't mind pushing it to -devel, if I have/get rights to do so, but I need a little more input from those who want it before I do. Does reverting 800x480 to 640x480 in config solve more problems than it creates for most users with regards to de-sync at borders?

I know 800x480 isn't a standard resolution for DOS games (if at all supported), so was this only purely a change made for supporting windows. If reverting this reduces the de-sync of mouse in the majority of cases, I'll try pushing a build with the defaults set to 640x480.

I still would like to be able to solve the initial offset fault as some stage, when I can find time.

I don't know *any* case when it creates *any* problems. Definitely solves them, for many games/program aimed at run at 640x480.

I would think that someone wanting to run 800x480 program (windows, most likely), would just go to config and set resolution appropriately. As you said, 800x480 isn't standard DOS-era resolution. I would say "change it's default in config" for more default-friendly value, can't imagine how it could be a problem for anyone.

Fixing initial off-set would be great, but even before, it's worth pushing to -devel by any means. After all, you can push next version after fixing another milestone issue...

Cheers,
/Estel

Config fix is easy enough, just need to omit patch or edit it. Can't remember stock value of the top of my head. Should be able to do that one morning next week before work.

Maintainer request sent.

Here's a quick, untested edit before I go out. Only changed default resolution for fullscreen. If it's ok I'll try pushing this version.

https://www.dropbox.com/sh/esrcgscp2...27my_ba/Latest

You don't really need to be the maintainer to push a new package to Devel and, honestly, nobody gives a damn about the whole extras-testing-devel anymore.

So please, do not hesitate to push your updated package.