Screen + Keyboard problem on my Sharp WS011SH

[tetzlaff]

Hi. Thank-you for the great port. I am amazed at how smoothly MI2 runs on my phone. Although I have found 2 very obvious problems, I am able to work around them.

Screen. My screen is 800x480. I am running in 2x mode. The mouse offset is wrong on 1 on the 2 of the 2 land scape modes. It happens to work correctly upside down with respect to my slide out keyboard. It appears to be offest 160 pixels, which makes sence if the program does not compensate for the screen shift.

Keyboard. This is a Japanese phone and the default input of Japanese may be causing a problem. There is a function to force the langauge input behavior of the keyboard. That may fix the problem.

Thank you.

[knakos]

Hello,

Screen. My screen is 800x480. I am running in 2x mode. The mouse offset is wrong on 1 on the 2 of the 2 land scape modes. It happens to work correctly upside down with respect to my slide out keyboard. It appears to be offest 160 pixels, which makes sence if the program does not compensate for the screen shift.

I'm guessing you meant the mouse is OK for the portrait mode and one of the two landscape modes; in the other one it is offset by some amount. This problem is often a broken implementation in the phone's firmware. Please check if any official updates or fixes exist for your phone model. (I am also guessing that your device also supports a stylus pointer, and it is not simply a smartphone)

Keyboard. This is a Japanese phone and the default input of Japanese may be causing a problem. There is a function to force the langauge input behavior of the keyboard. That may fix the problem.

ScummVM interprets directly the scan codes of each device, so a different input method *should* not do anything bad. There may be complications where text is entered directly (such as in savegame names, or AGI games).

Kostas

[tetzlaff]

After reading your reply, I took a quick look at the code. Thinking about what you wrote, and what I saw in the code, I am starting to think that the problem is most likely in the SDL layer. Either that or it is a BIOS issue. I have not tried updating the BIOS since I got the phone.

I just realize that everything being done with the screen, cursor, and keyboard is wrapped by the SDL, and there do not seem to be any direct calls to the wince api. The ImmSetConversionStatus() api call is supposed to the keyboard IME input mode, and that may fix the keyboard problem, but I think it would be best to try and apply it to the SDL layer.

[knakos]

After reading your reply, I took a quick look at the code. Thinking about what you wrote, and what I saw in the code, I am starting to think that the problem is most likely in the SDL layer. Either that or it is a BIOS issue. I have not tried updating the BIOS since I got the phone.

Assuming you're talking about the mouse code, it's true that this is handled inside SDL. But since we're maintaining a custom SDL branch this code is not, like, out of reach. In the patch, mouse translation is is handled by transform() assisted with calls to InitializeDisplayOrientation(), deRotate() and a couple of others. Building instructions etc. in the wiki. Even though the code cannot be certified to be 100% correct (not by a fault on our part) it has been shown that most similar problems have been caused by semi-broken implementations of the firmware, and scummvm was not the only app to get confused about it.

The ImmSetConversionStatus() api call is supposed to the keyboard IME input mode, and that may fix the keyboard problem, but I think it would be best to try and apply it to the SDL layer.

OK, but what is the problem exactly with the keyboard input?

[tetzlaff]

Assuming you're talking about the mouse code, it's true that this is handled inside SDL. But since we're maintaining a custom SDL branch this code is not, like, out of reach.

OK, but what is the problem exactly with the keyboard input?

The phone is running Windows Mobile 6.0 Japanese. The input defaults to the Japanese IME input. On average it takes 2 key strokes to make 1 Japanese character. The IME buffers all of the key strokes and gives me a list of Japanese characters or phrases to choose from. I do have a shortcut key to change between direct input and ime input, but that key does not do anything in ScummVm, as well as the rest of the alpha numeric keys. When I tried to write a test program, I had problems with the key input myself. I don't actually know how to use that function I posted correctly yet, it just sounds like its the right thing to use.

The screen works correctly in 1x mode in all orientations. The screen is always centered. I noticed that in 2x mode the screen is not centered but edged to one side. When that side is the top, the mouse works correctly. When it is edged at the bottom the mouse is off exactly by the black space from the top to the edge by 160 (800-640) pixels.

I realize that I do not need these problems to be fixed to enjoy the game. The on screen keyboard works great. I just think that since I have all the assets, it would cool if they all worked.

It's actually a really slick phone. Here is the link.

[Hades32]

Hi,

I have a Toshiba G900 which, too, has a resolution of 800x480 and I'm experiencing the same problem as you. But what really bothers me is that ScummVM only uses such a small portion of the screen.
When I hide the toolbar the picture doesnt strech, there is just another black bar. Is this supposed to work like this?
Would it be (easily) possible to set the toolbar to appear on the left or on the right for wide-screen devices like ours?

Regards

[tetzlaff]

I think the way to fix the keyboard problem is to run these 2 lines of code after you create the window. This will turn off the IME completely.

HIMC hIMC = ImmGetContext ( hWnd );

BOOL bResult = ImmSetConversionStatus ( hIMC, IME_CMODE_NOCONVERSION, IME_SMODE_NONE );

[knakos]

OK, thanks, nice tip. I'll try to include it in future versions.

[tetzlaff]

I did some testing and it looks like this is the keyboard fix.

Add this to line 517 (after the CreateWindow), of the SDL_dibevents.c

ImmSetConversionStatus ( ImmGetContext ( SDL_Window ), IME_CMODE_NOCONVERSION, IME_SMODE_NONE );


I am looking into the WVGA problem now. I noticed that on the Microsoft WM 6.1 Professional 480x800 Emulator, this WVGA Mouse problem also exists. So I am not sure if this is a Hardware issue.

[tetzlaff]

SDL_sysevents.c from line 351

case SDL_ROTATE_LEFT:
if (!SDL_VideoSurface)
break;
*x -= padHeight;
*y -= padWidth;
rotatedX = SDL_VideoSurface->w - *y;
rotatedY = *x;
if (displayProperties.cyHeight > SDL_VideoSurface->w) // patch
rotatedX = displayProperties.cyHeight - *y; // to fix wvga
*x = rotatedX;
*y = rotatedY;
break;


The problem is the video surface is smaller than the device screen, so the mouse calculations are off. Since I don't fully understand the SDL code, I isolated the patch to only work when the screen is wider than the surface, and its rotation is SDL_ROTATE_LEFT.

[knakos]

Great. Some comments:

1) The input method stuff: The 2 syscalls are present in the wince 3.00 SDK too (which is baseline for us). The documentation is a little off/misleading/confusing/whatever. My guess is that they'll work, but they will also add one more explicit dll dependency.

2) The video stuff: I cannot readily verify that this will have no adverse effect on other screens. In fact, you mention that the screen is not centered vertically which leads me to think that there might be a problem at the dimensions your phone is reporting.

I would like to include these patches in the next version. Can you please enter an item at our patch tracker and assign it to me? We can run a couple more tests to clarify the screen issue. Be sure to also include the scummvm_err/out files with dignostic output so I can check out what resolution is reported.

Thanks,
K.