Notices

sounds like familiar "feature", but just a guess
http://blogs.distant-earth.com/wp/in...abbing-issues/

Yeah, the patches disabled include tablet-mouse, right click and vertical sensivity. if you drag cursor into right border and top/bottom i can get in game cursor to line up correctly. i'm beginning to think it might be sdl_resize or relative mouse related. got some ideas to test.

Latest attempt. I've tried the suggestion by pythoneye2. I've changed the hide-cursor patch to remove instances of SDL_ShowCursor(SDL_DISABLE) and added a blank SDL_Cursor. Unfortunately I'm seeing no visible improvement. I have all other patches enabled as they don't appear to make any difference.

Under latest @
https://www.dropbox.com/sh/esrcgscp2...nGsD4o79U_6EMa

The thing linked by pythoneye2 is describing *exactly* the issue that we're experiencing. I wonder why workaround doesnmt help us - any ideas what may be wrong from code gurus? javispedro?

Also, the article mention that what is described is "one of the possible workarounds". Maybe someone would be able to find other existing ways, and one of them would help us to get rid of "drift" issue?

I've seen another suggesting you drop first mouse movement event. I'll give that a shot as well.

Edit: scrapped comment re fullscreen.

It seems to general consensus in other forums/platforms is it is SDL/Touchpad issue instead of an application level issue. iOS/Android Dosbox mouse code is, AIUI, unchanged from vanilla. They fixed SDL.

My thoughts yesterday was it was surface resize issue, but I too now think it is relative mouse vs absolute touchpad. Anyway, I'll try again later when I'm at laptop.

Breaking news - this version actually fixed the border drift issue! IDK why you haven't seen visible improvement, in everything that I've tried problem disappeared alltogether. No more mouse getting desynced with touch area near borders, hooray! Not to mention the awesomely improved performance your +svn versions caused (again: everybody remember to *never* use cycles: auto in Maemo's dosbox, ever. always provide cycles manually, for games that require max performance 5500 cycles is ideal on 900 mhz device).

From my perspective - make it way to extras ASAP. It's too awesome to hide from wide audience. Thanks you VERY much for your work, I haven't expected such improvements in Maemo's dosbox to be possible.

thanks for the feedback bla1

the problem i was seeing was that on start the mouse was already offset without going near edges. i had to drag it into edges of the used portion of screen to get it aligned correctly. i need a few more apps to try it with in case its app specific. think my brother has a copy of championship manager 97-98 somewhere.

my plan today was to add another patch to send a dummy mouse move event on init or ignore the first to see if that helped. unfortunately laptop / partition filled up so I've been clearing out that and making changes to prevent it happening again. that, along with other family+home issues today put a stop to my plans. might still get time later.

i could add a patch to set cycles: to a different value by default.

feedback from others on whether latest version mentioned above by bla1 fixes it for them as well and whether to make some changes to defaults would be much appreciated.

You should try with Win95 itself!??
I always had big offsets right from start.

I cannot remember if and how it was solved ( could be that it was just dumb ini ... )

Managed a couple of quick tests.

Command + Conquer: fine, no offset, no drift.
Theme Park: no offset or drift but hard to scroll left due to edge of screen. not tried fullscreen.

edit: doom loads much quicker using fixed cycles option.

On the different note - I wonder why cycles: max doesn't work as intended on Maemo. BTW, remember that:
...is something else than:
... if I got DOSBox manual correctly. Fixed 5500 is just that, no less (if device can handle given value), no more. 5500 without 'fixed' is "up to", depending on actual requirements of program. non-timered applications shouldn't require "fixed. Now, 'max' should automatically determine our non-fixed "up to", but fails miserably on Maemo, for some reason. No idea if it's setting up too much cycles that device can't handle (I guess so) and becomes slower, or much less cycles than we could use. Any ideas how to check it?
---

As for mouse drift - I found one game (M.A.X), where mouse doesn't get crazy drift near edges (upper/lower edge completely safe), but gets offset if you pull it outside of left-right edges. So, when you touch the edge, pointer remains at the visible screen border (obviously) during your to-the-edge-of-physical-screen movement, but as soon as you start moving back (still outside of view, on black bar area), cursor instantly moves on the visible area.

This way, It can become offset (on horizontal axis only) by up to 80 pixels (the size of "black border"), if using 800x480 screen (resulting in 640x480 game screen).

Hm, I wonder, if it would still be the case, if I put explicitly 640x480 in SDL section of dosbox config... going to check it, now.

Nevertheless, in some portions of the game (after missions start, but not in main menu, strangely), mouse cursor also starts completely offset (on both axises), and need "calibrating" it to correct corner. Just like you've described. Seems, like there is still a place for your improvements

// Edit

Bingo, setting 640x480 as fullscreen size into SDL section of dosbox config fixes the "black border" possible drift issue, at least for MAX, which was exhibiting the problem with 800x480. So, it seems like a fix for that portion of the bug (it may be good idea to replace 800x480 with 640x480 in default config that ships with dosbox installation for Maemo... Or was it "same as desktop"? Anyway, same as desktop is still 800x480, and we want 640x480 there). OTOH, I wonder why some programs/games (for example, Conquest of the New World, tiberian sun, etc) were not affected by the bug, even with 800x480 SDL screen.

Still, the problem with game starting with mouse located off the touch point (requiring to "run" it into the corner, to "calibrate") still persists. Android_808, your ideas sound like could be working to fix it.