#3619 closed defect (outdated)
WINCE: Orientation detection wrong in ScummVM 0.11.0
| Reported by: | SF/thestampede01 | Owned by: | SF/knakos |
|---|---|---|---|
| Priority: | low | Component: | Port: WinCE |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
I put the latest version of the SCUMMVM (version 0.11.0) port onto my ppc, which runs WindowsCE 4.2 referencing SirDave's manual.
When I run it, the cursor is not where I touch on the screen, so I have to restart because I can't click any of the on screen buttons. When in portrait mode, I drag my stylus down and the cursor moves left and vice versa. When I drag it left, the cursor goes up and vice versa. Same effect in landscape.
I enabled the diagnostic output and received the following lines in the error file:
SDL: Version $Rev: 41 $ bootstrapping GAPI device SDL: Device is portrait, OS version 4.20 build 1088 SDL: orientation 4 SDL: GAPI_RealizePalette NOT IMPLEMENTED SDL: Starting video access detection ---> SDL: System 320x240 SDL: Checking for GAPI SDL: GAPI OK, 240x320, H=2 V=480, 16bpp, landscape false SDL: Trying Ozone SDL: Running on Ozone SDL: Ozone unknown screen format SDL: Ozone 240x320 SDL: Running true Ozone with stylus hack SDL: <----- Detection finished. Running on Ozone driver at 240x320 (real 320, 240), using ARM accelerated blitter SDL: orientation 4 SDL: Selecting no translation
Ticket imported from: #1891705. Ticket imported from: bugs/3619.
Change History (16)
comment:1 by , 16 years ago
| Owner: | set to |
|---|---|
| Summary: | Cursor error in new ScummVM version → WINCE: Orientation detection wrong in ScummVM 0.11.0 |
comment:2 by , 16 years ago
comment:3 by , 16 years ago
I have a Mio C310X device. Previous versions of ScummVM portable have worked, but this new version didn't seem to want to.
comment:4 by , 16 years ago
| Status: | new → pending |
|---|
comment:5 by , 16 years ago
can you try with this one and report? also include the new stderr file.
http://users.uoa.gr/~knakos/scummvm/binaries/scummvm_test230208.zip
comment:6 by , 16 years ago
| Priority: | normal → low |
|---|
comment:7 by , 16 years ago
additional comment:
actually I don't think this is going to work either. I'll be gladly surprised if you prove me wrong. Your device is clearly reporting wrong screen extents. In particular, both display access methods (gapi, ozone) report a portrait screen (240x320) but the system insists it's in inverse landscape orientation (4) and stays there. This is not a proper driver implementation (no surprises here, the documentation is non existant or at best not understandable, by vendors and sw developers alike). And I know that perhaps scummvm in the past used to work with your device but it was a lucky shot (for you perhaps, because for the majority of "proper" implementations it was screwed up). This *could* be kludged around in this case: The device reports the landscape orientation while the driver is clearly in portrait state. But this is far from OK. If the "inverse portrait" mode comes into being (which I think I've seen somewhere) f.ex. there is no way to know from the 240x320 numbers if the display is in portrait or inverse portrait mode. Also this fails if the system reports some landscape mode and the display is at another landscape mode (both inverse and normal landscape report 320x240).
I don't know what I'm going to do about this yet.
Note that a "proper" drive works like this: If the display is accessed in portrait mode and the system is in landscape, it directly issues a WM_SETTINGSCHANGED message to inform the change in orientation ** to follow the display access **. This implementation does not do that, so the mouse coordinates are formed for inverse landscape mode while drawing is carried on in portrait.
comment:8 by , 16 years ago
This version did not work either. Here is the error file.
SDL: Version $Rev: 41 $ bootstrapping GAPI device SDL: Device is portrait, OS version 4.20 build 1088 SDL: orientation 4 SDL: GAPI_RealizePalette NOT IMPLEMENTED SDL: Starting video access detection ---> SDL: System 320x240 SDL: Checking for GAPI SDL: GAPI OK, 240x320, H=640 V=-2, 16bpp, landscape true SDL: Dimensions after GAPI 320x240 SDL: Trying Ozone SDL: Ozone available SDL: Ozone unknown screen format SDL: Ozone OK 240x320, H=640 V=-2, 16bpp, landscape true SDL: <----- Detection finished. Running on GAPI driver at 240x320 (real 320, 240), using ARM accelerated blitter SDL: Falling back to compatibility blitter
On a side note (which you can probably tell from the contents of this error file), if I open Scumm in portrait, it opens in landscape, and when I open in landscape, it opens in portrait. I think we already knew that though, but just in case...
Thanks
comment:9 by , 16 years ago
| Status: | pending → new |
|---|
comment:10 by , 16 years ago
So, it seems in order to fix this, we'd need a list of devices known to be buggy (or maybe device-firmware version pairs?) and then implement workaround for these? Even then, I guess, it would not be perfect because one still couldn't distinguish the normal from the inverse modes -- but I guess that problem is not quite as severe, is it?
Of course a set of device specific kludges is *not* desirable, but it might be the only possible solution here, as I understand it. Or how else do other programs deal with this?
comment:11 by , 16 years ago
Yes fingolfin, other programs do deal with such incompatibilities by directly comparing OS info and madel/make of the device with a known bad list to implement workarounds. It is a black hole I don't want to fall into. In the case of scummvm, such code will be sufficiently hidden from the main source tree, as it should go into the custom sdl branch and will not clutter the codebase at all.
On the other hand, I have implemented at least one known (to me) case of driver workaround in sdl, and this instance can be probably solved by some generic screen layout <-> OS report comparison code. I'm inclined to give it a chance as it is such an obvious driver malfunction and also because these sorts of devices cannot handle at all fiddling with the firmware with patches and stuff.
So thestampede can expect another test build soon.
comment:12 by , 16 years ago
Wait! I noticed something that makes matters worse: Assume logfile 1 to be the original log file and logfile2 the one after the test.
GAPI is always reporting portrait dimensions (240x320) although in run (1) it is in portrait and in run (2) it seems to be in landscape. That makes the reported the reported issue virtually undetectable without assuming a predefined 16bpp screen layout (which M$ says one should *never* assume). Crap. I need to think about it more. Lowering priority.
comment:14 by , 13 years ago
Closing this item now. The WinCE port is currently almost unmaintained, and while this issue likely is still present in new ScummVM versions, it is not likely to be fixed by us, and will simply resolve itself by the affected devices becoming obsolete. Sad, but that's how reality is :/.
comment:15 by , 13 years ago
| Resolution: | → outdated |
|---|---|
| Status: | new → closed |
comment:16 by , 5 years ago
| Component: | → Port: WinCE |
|---|
Thanks for reporting.
For the record, can you state exactly which device you have (e.g. iPAQ XXXXX).
There is a small bug which I want to fix; you will be notified by the tracker when I have a test build ready.