ScummVM for PNAs/PNDs

[shurlogg]

With the huge and ongoing success of WindowsCE-based Personal Navigation Assistans (PNAs, also sometimes called Personal Navigation Devices), it sounds tempting to have ScummVM support these devices (at least to me it does ). Unfortunately, there are some differences between PNAs and PocketPCs that prevent the current PocketScumm versions from running on PNAs.

First and foremost is the dependency on GAPI, which is not supported on virtually all PNAs currently on the market. Of course, there is always the GAPI for HPCs, but it supports only a limited number of mostly old devices - if you're the happy owner of a current-generation PNA, you're pretty much out of luck. Question to the developers: Is it possible to optionally use a different graphics API that is also supported by non-PocketPC CE devices without deep structural changes to the ScummVM architecture? If so, how much of an effort do you think it would be?

Another point is display size and orientation. While PocketPCs mostly use QVGA or VGA portrait as the default resolution, QVGA landscape is very common among PNAs - but 480x272 occurs more and more often. A truly PNA-compatible ScummVM would need to support this resolution and either scale games to it, or use the remaining display space for something sensible, like a menu bar or keyboard.

Maybe I'm the only one that believes this would be an interesting project - what does everybody else think?

[DrMcCoy]

Maybe I'm the only one that believes this would be an interesting project - what does everybody else think?

I for one think it's an interesting project, too. When do you start?

[clem]

another poll that sounds as if it's by a ScummVM project member *sigh*

voting no on principle since such polls are about as surprising as "Do you want to have taxes lowered?"

[PsYcO]

on like a satnav? that is indeed interesting, i voted yes, to conform to clems prediction.

though, as DrMcCoy stated, coders don't come out of the woodwork though will alone - so its likely that you'll have to do it yourself... and if you ask for help im sure someone will provide(probably the pocket pc/win ce porter)

also, there's no way of knowing if it will be made official till its complete

good luck!

[shurlogg]

though, as DrMcCoy stated, coders don't come out of the woodwork though will alone - so its likely that you'll have to do it yourself...

That is actually what I had in mind when I started the poll - I dare say I have enough experience with C++ development for Windows CE (it's part of what I do for a living), so that should not be a problem - I just want to be sure that if there is going to be a PNA version of ScummVM, some people are going to use it. In my eyes, it does not make sense to develop a feature for a community project like ScummVM if you're going to be the only person that wants to have it.

[PsYcO]

well in that case, i think you should start, even if the poll doesn't get the support you anticipated, ones its there people with them will use them, just cause they can.

also its always nice to see new ports coming into the scummvm universe

[knakos]

Just to clarify, ScummVM works an any wince arm based (post 2002 to be safe) device out there including "PNA"s. In fact, I'm pretty sure I had a report somewhere where it works ok on such a device, but can't find the reference right now (either the bugtracker or the forums). Of course it runs at 320x240 centered on a 480x272.

First and foremost is the dependency on GAPI, which is not supported on virtually all PNAs currently on the market.

ScummVM does not require GAPI to work. Provided of course that the "undocumented" ExtDriverEscape function works as it is undocumently documented.

480x272 occurs more and more often.

This is only a matter of coding in a 3/2 horiz, 9/8 vert scaler (setting aside for a moment the "exactness" issues the scaler subsystem has). This scaler does not keep the aspect ratio so the image will be slightly distorted, in comparison with the original. Take a look at CEScaler.cpp.

[shurlogg]

Just to clarify, ScummVM works an any wince arm based (post 2002 to be safe) device out there including "PNA"s. In fact, I'm pretty sure I had a report somewhere where it works ok on such a device, but can't find the reference right now (either the bugtracker or the forums). Of course it runs at 320x240 centered on a 480x272.

I am aware of this. I saw the report you are talking about (here in the forums I think), but that one used the GAPI for HPCs, which is device-specific and not available for many PNAs.

ScummVM does not require GAPI to work. Provided of course that the "undocumented" ExtDriverEscape function works as it is undocumently documented.

Right now, ScummVM depends on GAPI, because the WinCE port of SDL requires it. If you try to run any ScummVM release on a device without a gx.dll, it does not start. But I agree to you in this respect, that this would have to be changed in SDL, not ScummVM. The other option would be to try and use the official WinCE version of SDL instead of Arisme's unofficial port, which may or may not depend on GAPI - I haven't had a chance to check yet.

Btw, where would I find documentation on the undocumented ExtDriverEscape function?

This is only a matter of coding in a 3/2 horiz, 9/8 vert scaler (setting aside for a moment the "exactness" issues the scaler subsystem has). This scaler does not keep the aspect ratio so the image will be slightly distorted, in comparison with the original. Take a look at CEScaler.cpp.

I will, thanks for the advice.

[knakos]

Right now, ScummVM depends on GAPI, because the WinCE port of SDL requires it. If you try to run any ScummVM release on a device without a gx.dll, it does not start.

This is not true and can be shown easily either by Makefile inspection or directly through inspection of the binary. WinCE ScummVM does not require the presence of GAPI to launch. Furthermore, WinCE ScummVM does not use the official WinCE SDL port because (last time I checked) I simply do not find it up to par with what I want ScummVM to perform like on my device, and also for compatibility reasons across the whole spectrum of devices. We maintain a custom branch of SDL 1.2.6 for our purposes. I have not had the time to prepare a proper patch for submission to the SDL project.

Please refrain from making authoritative-looking comments with false claims on the forums which confuse the users.

[shurlogg]

Okay, message understood. Sorry. I mistakenly thought that adding "I believe" to every sentence would have made my comments a bit tedious to read.

Thank you for the clarification, I will try to check which other DLL I was missing. You have certainly spared me a lot of work trying to remove something that isn't there.

[babybambula]

@shurlogg
Did you solve the problem yet? Because I have the same right now I guess.
This is what scummvm_stderr.txt says:

SDL: Version $Rev: 41 $ bootstrapping GAPI device
SDL: Device is portrait, OS version 5.0 build 1400
SDL: orientation 0
SDL: GAPI_RealizePalette NOT IMPLEMENTED
SDL: Starting video access detection --->
SDL: System 480x272
SDL: Checking for GAPI
SDL: Trying Ozone
SDL: Running on Ozone
SDL: Ozone unknown screen format

Do I need to update Ozone (whatever that is)?

[knakos]

SDL: Ozone unknown screen format

This is a severe error, so you need to install GAPI (see the related bug report).

Even though it isn't mentioned in the report, my guess is that wincesoft's or microsoft's is used. Let us know which one works.

[babybambula]

Thanks for the info!
Unfortunately the WinCESoft GAPI doesn't support my device yet (Medion GoPal P4410 MD96404).
And somehow I'm too stupid to install the Microsoft dll. When I just copy it to the WINDOWS directory it doesn't work.

[knakos]

Just copy gx.dll in the same folder where scummvm.exe is. They should probably both work alright.

[babybambula]

Nope, the Microsoft one doesn't work at all (fatal application error). The WinCESoft dll kind of works, since there pops up a menu where I'm supposed to choose my device. My device isn't listed yet, though. I wrote an email to WinCESoft to get further information regarding my device.
Still, thanks!