Any chance of getting an updated version of SCUMMVM ?


PowerGod's problem also happens in King's Quest VI. I made a video of it several months back:


http://www.youtube.com/watch?v=nDmMOIOfClM


The problem is an SDL one; the click event returns the wrong coordinates, so a different source of coordinates needs to be used (e.g. mouse motion). I'm just surprised that so few developers using SDL are apparently aware of this.
 
Last edited by a moderator:
Actually,


Regarding the mixed location response issues. If anyone wants to test that would be grand. There are actually fixes (and some refractoring) that have gone in to help with this issue but it is not as easy a fix as one might imagine and is separate from the drifting touchscreen co-ordinates.


I am actually very aware of the cause but have had little desire to work on fixing anything since January (without much detail, lets just say lots of family members in lots of hospitals).


The root cause is actually mentioned in the thread that video is from http://boards.openpandora.org/index.php?/topic/5500-not-the-usual-scummvm-touchscreen-issue/. Some quick/hacky fixes would cause unacceptable backend/engine coupling and as such need some clean API pointers to be worked in to determine state.


Another pet peeve, if people are seeing these issues are are able to articulate them so well PLEASE raise bug reports. I don't spend all my time checking forums and if bugs are recorded at least any ScummVM developer can take a look and they can be used to spark debate between engine and backend teams etc. etc. - https://sourceforge....116&atid=418820. If you want it fixed raise a bug, even if I comment on a thread I get so much cruft that I am inclined to totally forget about random forum posts ;-).


One more thing, patches are of course VERY welcome and as we use GIT and GIThub forking and patching is reassuringly easy. It seems that some of you have a good handle on these issues, lets see some code with good backend/engine separation that puts the problem to bed once and for all.
 
Last edited by a moderator:
Had this bug too in a little game I wrote. The fix is relatively easy:


If we are using a touchscreen we need to grab the mousecoords again when a click-event happens before everything else.


The reason is that else we have x,y, of the ball for example stored and then a click-event triggers and uses those coords even though we clicked on the table because the click-event triggers before the mouse-move-event.


This has nothing to do with the touchscreen-drift, and should best be fixed either using a compile-time-switch or for all platforms since this changed behaviour shouldn't add problems with other input-devices.


Pseudo-code:



Code:
mousex,mousey= getmousepos()

do_some_logic()

if(mouseclick_happend())

    mousex,mousey= getmousepos() //<--add this line to fix

    do_mousestuff()

do_more_logic()

blit_or_something()
 
have had little desire to work on fixing anything since January (without much detail, lets just say lots of family members in lots of hospitals).
Hope they all return home safe and well.


Thanks for the updated build
 
Pseudo-code:



Code:
mousex,mousey= getmousepos()

do_some_logic()

if(mouseclick_happend())

mousex,mousey= getmousepos() //<--add this line to fix

do_mousestuff()

do_more_logic()

blit_or_something()

Thanks, that is not very far from what is currently done. The problem is due to some inconsistencies in the way different engines push event orders to the backend. In the case of the old build SCI and Lure engines. Hence the need for a little more clean API work in the ScummVM case to direct the backend or something like that psudo code directly in then engine.


That said, this may well have been sorted anyway, I just have not had a chance to test it ;) .

have had little desire to work on fixing anything since January (without much detail, lets just say lots of family members in lots of hospitals).
Hope they all return home safe and well.


Thanks for the updated build

Cheers :) .
 
I am actually very aware of the cause but have had little desire to work on fixing anything since January (without much detail, lets just say lots of family members in lots of hospitals).

I hope they will get better soon.


You are right to see your relatives in good health first.
 
Good luck to all your family members djwillis, and thanks for your work :)
 
Had a quick look in Elvira 2 yesterday afternoon, and it seems to work fine (except that the "logo" tune at the very beginning stutters a little bit with a 800 MHz clocked Pandora)


Thanks for taking the time to give us a more current build !
 
Last edited by a moderator:
Played Lure of the Temptress for an hour and did't found issues except fot the previously mentioned touchscreen click problem
 
thanks!


does this mean all future autobuilds will work again ?

Of course.


But just to make it VERY clear auto builds (from http://buildbot.scummvm.org/) are built without optimisation and with debug symbols so are not really fit for anything other than confirming bugs or developer testing and don't represent performance of release builds in the slightest.
 
thanks!


does this mean all future autobuilds will work again ?

Of course.


But just to make it VERY clear auto builds (from http://buildbot.scummvm.org/) are built without optimisation and with debug symbols so are not really fit for anything other than confirming bugs or developer testing and don't represent performance of release builds in the slightest.
better than nothing - who knows when there will be the next timeslot in your life to gift us with the next release build of ScummVM.


Thanks again for your work (this also includes the OS work you have done for the Pandora).


And congratulations on the timing, it just spend nearly almost of my game budget for the rest of the year on gogs adventure promo => Simon 1&2 & Feeble files here I come :D
 
Back
Top