Opened 12 years ago

Closed 9 years ago

Last modified 12 months ago

#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
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 SF/knakos, 12 years ago

Owner: set to SF/knakos
Summary: Cursor error in new ScummVM versionWINCE: Orientation detection wrong in ScummVM 0.11.0

comment:2 by SF/knakos, 12 years ago

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.

comment:3 by SF/thestampede01, 12 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 SF/knakos, 12 years ago

Status: newpending

comment:5 by SF/knakos, 12 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 SF/knakos, 12 years ago

Priority: normallow

comment:7 by SF/knakos, 12 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 SF/thestampede01, 12 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 SF/thestampede01, 12 years ago

Status: pendingnew

comment:10 by fingolfin, 12 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 SF/knakos, 12 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 SF/knakos, 12 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:13 by sev-, 11 years ago

What is the status of this item?

comment:14 by fingolfin, 9 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 fingolfin, 9 years ago

Resolution: outdated
Status: newclosed

comment:16 by digitall, 12 months ago

Component: Port: WinCE
Note: See TracTickets for help on using tickets.