ScummVM: “1.2.0 preview 1” for the OpenPandora.Posted on October 3rd, 2010 5 comments
EDIT: This release has been superseded, please get the latest release.
This post is to announce the release of a testing preview of the upcoming 1.2.0 ScummVM release for the OpenPandora handheld.
It is a little later (and a bit close to the final 1.2.0 release date) than I would have liked but that’s real life for you, always getting in the way of perfectly good hacking time .
This release supersedes any recent ‘SVN’ builds you may be using and should provide a very good indication of what to expect in the final 1.2.0 release for the OpenPandora.
Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this site.
This helps me ensure that users always have the most recent versions.
Also note that these test releases are not officially (or unofficially) supported but I will help if I can.
I am hoping to get at least another preview release out for the OpenPandora before the final 1.2.0 release as I carry on fixing bugs. This is why it is important to provide feedback, patches, fixes etc.
Please give these releases a go and provide feedback.
Below are the main features and fixes added with this new release since the unofficial 1.1.1 preview.
Performance improvements over earlier releases.
Add support for Touchscreen ‘Tap Modes’, Left Click, Right Click and Hover and ‘Trigger Tap’ .
Small tweak to the touchscreen to stop the cursor ‘drifting’ when outside the game area.
Revised the button layout (please read http://wiki.scummvm.org/index.php?title=OpenPandora for more info and controls), feedback on the button layouts is appreciated.
Add support for a proper ‘Left Handed Mode’ (the current setup supports left handed use but is not IMHO optimal).
Make the ‘Trigger Tap’ configurable by the user.
Anything on the TODO may not happen in time for the 1.2.0 release, it is all rather dependent on my free time and that is at a premium at the moment.
These releases feature support for all the game engines enabled for the upcoming ScummVM 1.2.0 including support for the SCI engine (early SCI games) and adding Fascination support in the Gob engine (remember, it’s really not a children’s game).
Full details of what you can expect to see in 1.2.0 can be found in the testing news post.
If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.
- Bug Reports (ScummVM’s Sourceforge bug tracker)
- Feature Requests (ScummVM’s Sourceforge feature tracker)
To install just download and extract the contents of the archive and copy the resulting scummvm-op.pnd to the following folder on your SD card (or USB2 stick):
/pandora/menu –> This will cause the ScummVM app icon to show up in the Xfce menu sorted by category.
/pandora/desktop –> This will cause the ScummVM app to appear as an icon on the Desktop of Xfce.
Either folder will also ensure the application icon shows up in MiniMenu.
To run, just select the icon as normal, the ScummVM GUI will start up and you can add games as you would normally do with any other ScummVM release (including Mass Add).
Review the documentation (added to the Documentation menu in your launcher when the PND is loaded) and http://wiki.scummvm.org/index.php?title=OpenPandora for more information.
5 responses to “ScummVM: “1.2.0 preview 1” for the OpenPandora.”
jonlad1 October 4th, 2010 at 09:58
Does this release support 2/3x scaling or fullscreen?
The last release has it in the menu but doesnt do anything….
Define what you mean by scaling?
I have chosen to keep the OpenPandora release full screen and by default scale 320*xxx game screens to 640*xxx (using a very nice ARM ASM 2X scaler). I am not supporting windowing or running the games on a 320*xxx non-scaled surface. Games with odd resolutions should scale up to 2x IF they fit inside the LCD resolution, if not they will run at 1x with borders.
That said ‘Aspect Ratio Correction’ scaling should be working fine (well there may be an issue clearing the overlay from the bottom few pixels if it is turned off actually). You can set it globally or in each games options and it will respect the choice if it is appropriate for the game in question (not all games have a 320*200/640*400 game area so correction is not always applicable).
By default ‘Aspect Ratio Correction’ is always on and games will be scaled as originally intended (on CRT screens with non-square pixels) if applicable.
One small cosmetic bugfix I need to do is just change the options displayed in ‘Graphics Mode’ to just state ‘Fullscreen (Auto)’ rather than the current list of scalers as I ignore them anyway (well if you pick a scaler that will result in a surface bigger than the 800*480 screen ScummVM will crash ).
jonlad1 October 5th, 2010 at 00:18
Sorry for not making myself more clear, I’m certainly no expert in this
I’m basically asking for full screen stretch for games? I love the fact that the Pandora has 800×480 and see it as a waste when all the available screen real estate isnt being used.
Is that something you’re planning?
Anyway, great work! Glad you are still pumping Pandora stuff out!
Ok, below is what I posted in reply to your comment on the GP32x forum, it should explain how the scaling works and why you can’t currently ‘stretch’ scale .
I realise there is wasted screen space but the complexity of a non liner scale and the fact it looks horrid (it really does ) mean I don’t plan on investing a great deal of time on such a feature.
Sorry about that, if I can think of a simple way to do it so be it but I don’t plan to invest a lot of time working it out, esp. as the hopeful direction of the port will be towards OpenGLes making such a ‘stretch’ feature trivial to add then.
No, not unless the game originally worked with that aspect ratio (so scales to 800*480 1:1).
I do not support scaling games in a non liner fashion. Sorry, that’s just the way it is, at the moment I scale the screen 1:1 to get close to full screen.
If someone wants to hack in a non 1:1 scaler then by all means submit a patch but I won’t be doing it .
This may well change in time when the backend moves to OpenGLes (not a short term goal) as just scaling the surface to whatever may be needed is somewhat easier (I can just offer, “Full Screen (aspect)”, Full Screen (stretch)” and “Unscaled (borders)” and be done with it , let OpenGL worry about the specifics.
What I do plan to offer in time (i.e. not soon and maybe never ) is support for running the GUI on the full 800*480 screen (actually, this works but is disabled in the 1.2.0 releases as there are bugs). I may also add support for scaling games with ‘Aspect Ratio Correction’ off to more of the screen (i.e. 320*200 would have an option to get scaled to something like 768*480 rather than 640*400 with boarders at the bottom and sides).
None of this will get done with the 1.2.0 release.
jonlad1 October 6th, 2010 at 11:44
Thats fine John, just thought I’d ask
I am (and the whole community) more than grateful for this.
Looking forward to seeing what else you have up your long coding sleeve!