ScummVM on Smartphone (QTek 8310)
Moderator: ScummVM Team
Hi guys. Seeing that there's much interest in a patch for this issue, I give you an update:
Getting scummvm to detect properly smartphones w/ QVGA res was relatively easy. BUT, it turns out that the SDL port by Arisme (at least the pre-built one I'm using) get confused and acts weird. The net effect is that I've a version which work OK with this particular smartphone type but messes up the graphics. So if you hold on for a little longer, I need to patch the SDL library and we'll be fine.
So, let's say it'll be ready this weekend (if nothing else goes severely wrong!).
Best,
Kostas
Well, that's still good news...having in mind this port is around now for several months and noone felt like fixing it.knakos wrote:
Hi guys. Seeing that there's much interest in a patch for this issue, I give you an update:
Getting scummvm to detect properly smartphones w/ QVGA res was relatively easy. BUT, it turns out that the SDL port by Arisme (at least the pre-built one I'm using) get confused and acts weird. The net effect is that I've a version which work OK with this particular smartphone type but messes up the graphics. So if you hold on for a little longer, I need to patch the SDL library and we'll be fine.
So, let's say it'll be ready this weekend (if nothing else goes severely wrong!).
Best,
Kostas
Would it by the way make sense to work with Arisme to get this fix into the 'official' port?
Thanks very much for all your effort!!!
-
danieljackson
- Posts: 1
- Joined: Fri Jan 20, 2006 1:26 am
Detecting Platform Type
If you want to detect the platform type, I'd recommend using:
SystemParametersInfo(SPI_GETPLATFORMTYPE, ...);
An override in the INI file would be good, but it'd still be great if it just auto-detected it.
The function should return one of the following strings:
SystemParametersInfo(SPI_GETPLATFORMTYPE, ...);
An override in the INI file would be good, but it'd still be great if it just auto-detected it.
The function should return one of the following strings:
- "HPC" = Handheld PC
"HPC Pro" = Handheld PC 3.0
"Palm PC" = Palm-size PC 1/2 and Pocket PC/Pocket PC 2000
"PocketPC" = Pocket PC 2002/2003
"SmartPhone" = Smartphone
Hi Daniel,
The device gets recognized OK, but the low level screen blitting though SDL fails. Unfortunately, in a way, Microsoft has done a bad job in providing user access to low level drivers. For example the function you mention fails on older smartphones and IIRC on older pocket pcs as well (<2002).
In order to access the screen mem directly normally you'd use GAPI. But in newer devices (>=2003) you're dropped on an emulation layer prohibiting the use of the extended resulotions. Getting the device caps thru GAPI on a 2003 QVGA smartphone, reports 176x220 resolution. But using getsystemmetcrics it reports correctly 240x320. So then you try out the "undocumented" extescape call to get the framebuffer and drop GAPI altogheter (arisme calls this "ozone" mode). So that's where we are. The SDL port mistakes the framebuffer for a pocket pc device and doesn't use the ozone workaround for QVGA smartphones.
K.
The device gets recognized OK, but the low level screen blitting though SDL fails. Unfortunately, in a way, Microsoft has done a bad job in providing user access to low level drivers. For example the function you mention fails on older smartphones and IIRC on older pocket pcs as well (<2002).
In order to access the screen mem directly normally you'd use GAPI. But in newer devices (>=2003) you're dropped on an emulation layer prohibiting the use of the extended resulotions. Getting the device caps thru GAPI on a 2003 QVGA smartphone, reports 176x220 resolution. But using getsystemmetcrics it reports correctly 240x320. So then you try out the "undocumented" extescape call to get the framebuffer and drop GAPI altogheter (arisme calls this "ozone" mode). So that's where we are. The SDL port mistakes the framebuffer for a pocket pc device and doesn't use the ozone workaround for QVGA smartphones.
K.
-
splinter98
- Posts: 1
- Joined: Sun Jan 22, 2006 4:42 pm
Hey guys,
The good news is that I've patched the sdl library to work correctly with qvga smartphones. Also, the code in scummvm which recognizes qvga smartphones is in place. The only thing left is to have scummvm use landscape mode. I'll do it today or tommorow night. Please, stand by the binary is on the way!
K.
The good news is that I've patched the sdl library to work correctly with qvga smartphones. Also, the code in scummvm which recognizes qvga smartphones is in place. The only thing left is to have scummvm use landscape mode. I'll do it today or tommorow night. Please, stand by the binary is on the way!
K.
Hey, SEHR gute News!!! *freu*knakos wrote:Hey guys,
The good news is that I've patched the sdl library to work correctly with qvga smartphones. Also, the code in scummvm which recognizes qvga smartphones is in place. The only thing left is to have scummvm use landscape mode. I'll do it today or tommorow night. Please, stand by the binary is on the way!
K.
Das Landscape einstellen, ging das nicht schon von vornherein in der ini, mit Landscape=yes oder so in der ScummVM section? In irgend nem Thread hier stand das glaub ich auch...
Oder hat sich durch das Patchen u die neuen Routinen hier was geaendert?
Hmmm, well that all greek to mePa9an wrote:Hey, SEHR gute News!!! *freu*
****etc.etc.***
But anyway, I think I get what you mean. It would work but the menu would still be in portrait and the key-mouse the wrong way round. But I've fixed it anyway (mit patchen!). Go for it.
Hope it works,
Kostas
Ooops, completely forgot that was (is) an english forum...well, probably because I've been too overwhelmed about that great newsknakos wrote:Hmmm, well that all greek to mePa9an wrote:Hey, SEHR gute News!!! *freu*
****etc.etc.***
But anyway, I think I get what you mean. It would work but the menu would still be in portrait and the key-mouse the wrong way round. But I've fixed it anyway (mit patchen!). Go for it.
Hope it works,
Kostas
I'm going to test that version tonight - will let you know tomorrow!