Official SDK now partially supported

[Vinterstum]

ScummVM trunk now has an XCode project which you can use to compile your very own version for the iPhone .

Howto:
* Do an SVN checkout of: https://scummvm.svn.sourceforge.net/svn ... mmvm/trunk
* Download http://worldsmainorganization.org/scumm ... ibs.tar.gz and extract it to the dists/iphone folder.
* Open up dists/iphone/scummvm.xcodeproj
* Compile away!

Known issues:
* The build may fail the very first time you try (due to an autogenerated Info.plist file). The second time around should be fine, though.
* No handwritten ASM routines (i.e. it'll run a little bit slower).
* ScummVM trunk changes frequently. Files will be added, removed or moved around, which will break the XCode project temporarily. This is easy enough to fix by yourself, though, until I get around to it.
* No Simulator support (ScummVM still uses the CoreSurface private framework for graphics, which the Simulator doesn't support. An OpenGL ES version is on my TODO list, but if anyone wants to give it a go instead that'd be great . )

The last point means you NEED to be a part of the Developer program (the $99 per year thing) to use this. Unless you want to do the OpenGL ES rewrite .

EDIT: And no, this does NOT mean there'll be an AppStore version any time soon.

[Sherry Haibara]

Great news! Can't wait to try it

Sherry Haibara

[yonosoytu]

I have followed your instructions and they seem to work more or less (I have ScummVM working on my iPod touch "officially").

Things I think you have forgotten to explain:
- You have to create a config.mk in the source directory for Make to work. The file may be empty, but it have to exist.
- You obviously need a iPhone Developer account, and configure the signing certificate in the target you want to compile. If you want to do Ad Hoc distribution you have to also create a entitlements file with get-task-allow set to false for the application to install.
- Because I don't want to create a new Ad Hoc distribution profile, I have changed the Application Identifier in Info.plist.in.

Obviously there were changes between the source code tree and the Xcode project. Easily solved searching for the new location or renamed ones.

My questions are: I don't have a jailbroken iPod touch, so I can not move the game data to the iPod. Is there a way to "embed" one or two games with the application?

Why do you have to leave out the assembler code? Before finding this post I have been trying to compile the last stable version. The only thing the assembler barks about is .global pseudo-instruction. I have my assembler a bit rusty (and I haven't touched ARM assembler in my life), but didn't seem a hard thing to fix.

What should be done to make this work with OpenGL ES? I suppose you will have to exchange CoreSurface specific code with OpenGL code, but may be you also have to make the main loop OpenGL specific.

By the way, the point you say about the build failing the first time is because Apple process Info.plist before all the build steps of the target. If you want to preprocess Info.plist (or generate it) you can create another target with a Run Script phase, and add that target as a pre-dependency of the main one. That will process Info.plist before Xcode tries to find it.

[Vinterstum]

I have followed your instructions and they seem to work more or less (I have ScummVM working on my iPod touch "officially").

Things I think you have forgotten to explain:
- You have to create a config.mk in the source directory for Make to work. The file may be empty, but it have to exist.

Ahh yeah that could be. I (obviously) compile with the unofficial SDK as well, so I already had that laying around. I'll see if I can generate Info.plist directly instead, without depending on make.

My questions are: I don't have a jailbroken iPod touch, so I can not move the game data to the iPod. Is there a way to "embed" one or two games with the application?

Currently, the only way is to actually include the game data files in the XCode project.

When ScummVM runs like this, it's pretty sandboxed and can't access the other application folders (so using things like File Magnet and whatnot won't work).

Pretty much the only way to "solve" this would be something like embedding an FTP server into ScummVM :/. Or there may be some apps around that'll upload (over USB, using whatever protocol iTunes/XCode uses) files directly to the application folder, like iPhoneBrowser and whatnot. I'll look into this some more.

Why do you have to leave out the assembler code? Before finding this post I have been trying to compile the last stable version. The only thing the assembler barks about is .global pseudo-instruction. I have my assembler a bit rusty (and I haven't touched ARM assembler in my life), but didn't seem a hard thing to fix.

That's just the tip of the iceberg, unfortunately. The assembler Apple uses is based on an ancient, ancient version of the GNU assembler and supports very little of what you generally use for "handwritten" assembly. I'm sure it would be possible to convert the asm to pretty much what the compiler would output (which is all it's able to handle), but I haven't really seen the point yet. The speed loss isn't that big. And it would make the assembly source a lot less readable.

What should be done to make this work with OpenGL ES? I suppose you will have to exchange CoreSurface specific code with OpenGL code, but may be you also have to make the main loop OpenGL specific.

Not sure what you mean by "OpenGL specific main loop" . The iPhone supports the texture_rectangle_ARB extension (or whatever the name is), so you can pretty much set up a few 1024x1024 textures (or tile smaller ones), update subregions of that when necessary, and use that extension to do a direct draw (or set up vertices normally for the Simulator, which doesn't support that extension). One texture for the main screen, one for the overlay, and one for the cursor. This setup would save one layer of blitting (and can do the rotation on the hardware side) and may well be faster than the current code.

Doing most of this from the thread ScummVM runs in shouldn't be a problem, I'd think, but I haven't played around with it too much yet.

By the way, the point you say about the build failing the first time is because Apple process Info.plist before all the build steps of the target. If you want to preprocess Info.plist (or generate it) you can create another target with a Run Script phase, and add that target as a pre-dependency of the main one. That will process Info.plist before Xcode tries to find it.

Ahh nice, thanks . I haven't been working with XCode for too long, so I don't know all the tricks yet .

[yonosoytu]

Ahh yeah that could be. I (obviously) compile with the unofficial SDK as well, so I already had that laying around. I'll see if I can generate Info.plist directly instead, without depending on make.

If you don't want to depend on Make, and if you only need it for Info.plist.in it would be easy to make a shell script for that (instead of the Run Script phase with the invocation to Make):

Code: Select all

VERSION=`cat $SRCROOT/../../base/internal_version.h | cut -d" -f2`
cat $SRCROOT/Info.plist.in | sed -e "s/@VERSION@/$VERSION/g" > $SRCROOT/Info.plist

Having $(SRCROOT)/Info.plist.in as input file and $(SRCROOT)/Info.plist as output.

Currently, the only way is to actually include the game data files in the XCode project.

When ScummVM runs like this, it's pretty sandboxed and can't access the other application folders (so using things like File Magnet and whatnot won't work).

Pretty much the only way to "solve" this would be something like embedding an FTP server into ScummVM :/. Or there may be some apps around that'll upload (over USB, using whatever protocol iTunes/XCode uses) files directly to the application folder, like iPhoneBrowser and whatnot. I'll look into this some more.

Yeah, including the game files inside the app worked. It has been hard finding the application using the GUIDs, but I have found it. Maybe I can make some kind of first-time initialization that copies the embedded game files to the document folder of the application (or maybe symlink them), or even create the config entries for each of the directories included in the application.

That's just the tip of the iceberg, unfortunately. The assembler Apple uses is based on an ancient, ancient version of the GNU assembler and supports very little of what you generally use for "handwritten" assembly. I'm sure it would be possible to convert the asm to pretty much what the compiler would output (which is all it's able to handle), but I haven't really seen the point yet. The speed loss isn't that big. And it would make the assembly source a lot less readable.

I have tried inlining the assembly code, but unfortunately it do not work (it crashes, obviously). But as you say, I really don't see the need for optimizing more the code (at least Monkey Island plays fine).

Not sure what you mean by "OpenGL specific main loop" . The iPhone supports the texture_rectangle_ARB extension (or whatever the name is), so you can pretty much set up a few 1024x1024 textures (or tile smaller ones), update subregions of that when necessary, and use that extension to do a direct draw (or set up vertices normally for the Simulator, which doesn't support that extension). One texture for the main screen, one for the overlay, and one for the cursor. This setup would save one layer of blitting (and can do the rotation on the hardware side) and may well be faster than the current code.

Doing most of this from the thread ScummVM runs in shouldn't be a problem, I'd think, but I haven't played around with it too much yet.

Sorry, I was thinking maybe in Glut or something like that. OpenGL do not have main loop.

From that point you "lost" me. I haven't touched OGL in many years (when all was fixed pipeline), but I'll try to look at the extension you are talking about. But I'm a bit behind here.

Ahh nice, thanks . I haven't been working with XCode for too long, so I don't know all the tricks yet .

Yeah, odities of Xcode.

Btw, if someone came across this thread and want to play its games on the iPhone using the official SDK, this is the process I have used to include a game ("monkey", from now on):

- Create a new top-level group name "gamefiles".
- Create inside it a new group named "monkey".
- In this group right click "Add > Existing Files". Search for your game files in your hard drive (can be anywhere, I have used my game files from ScummVM for Mac OS X).
- In the dialog do not check "Copy files", and do not add the files to any target. Path Type can be anyone, but Absolute will be the best (if you don't move your game files around).
- Add a new Copy Files phase to ScummVM target.
- In the Info window set Destination to Resources and Path to "gamefiles/monkey" (the first directory is only for organization pourposes).
- Drag the game files you have added to this new build phase.
- Compile and install the application into the device.
- Search inside /var/private/mobile/Applications for ScummVM application. There are no names, only numbers and letters, you will have to search one by one, until some directory have the gamefiles directory inside.
- Choose "monkey"

Another little thing: ScummVM icon already have the glare applied so it would be convenient to have UIPrerenderedIcon key set to false in Info.plist (at the bottom of Info.plist.in, before the clossing tags for dict and plist):

Code: Select all

<key>UIPrerenderedIcon</key>
<false/>

Have fun.[/code]

[Vinterstum]

I just updated the project with the suggested changes (bit of a delay there).

Also: ScummVM will now start browing for files inside the application bundle (in Documents, under it), so no need to search through obscure GUIDs.

[yonosoytu]

Thank you, that's a great solution.

Btw, I screw up before, UIPrerenderedIcon must be true, not false. Sorry about that. It's not really that important.

Compiles fine (I have yet transferred the binary to my iPod, but it should be fine).

[Vinterstum]

Btw, I screw up before, UIPrerenderedIcon must be true, not false. Sorry about that. It's not really that important.

Yep, I noticed . Made more sense too!

[KingLir]

Hi Vinterstum,

Any progress on the OpenGL version ?

I want to start working on that an would like to know if you already made progress so I can offer my help with the known issues

Many Thanks!

[Vinterstum]

Hi Vinterstum,

Any progress on the OpenGL version ?

I want to start working on that an would like to know if you already made progress so I can offer my help with the known issues

Many Thanks!

Not from my side, unfortunately.

However, someone PMed me a few days ago asking pretty much the same question. So I'd encourage anyone who makes a go at OpenGL ES support to upload patches to the tracker frequently to avoid any duplicate work .

[KingLir]

Hi Vinterstum,

Any progress on the OpenGL version ?

I want to start working on that an would like to know if you already made progress so I can offer my help with the known issues

Many Thanks!

Not from my side, unfortunately.

However, someone PMed me a few days ago asking pretty much the same question. So I'd encourage anyone who makes a go at OpenGL ES support to upload patches to the tracker frequently to avoid any duplicate work .

OK, Thanks.

I encounter a real problem reaching a good frames per second. Any suggestions ?

[Vinterstum]

Hi Vinterstum,

Any progress on the OpenGL version ?

I want to start working on that an would like to know if you already made progress so I can offer my help with the known issues

Many Thanks!

Not from my side, unfortunately.

However, someone PMed me a few days ago asking pretty much the same question. So I'd encourage anyone who makes a go at OpenGL ES support to upload patches to the tracker frequently to avoid any duplicate work .

OK, Thanks.

I encounter a real problem reaching a good frames per second. Any suggestions ?

PBuffers and the texture rectangle extension might be alternatives. And since we know which rectangles have been updated, we don't need to upload the full texture each frame.

[KingLir]

PBuffers and the texture rectangle extension might be alternatives. And since we know which rectangles have been updated, we don't need to upload the full texture each frame.

Do you mean using "texSubImage2D" ? But, it's as slow as uploading the full texture.
What am I missing ?

[joostp]

PBuffers and the texture rectangle extension might be alternatives. And since we know which rectangles have been updated, we don't need to upload the full texture each frame.

Do you mean using "texSubImage2D" ? But, it's as slow as uploading the full texture.
What am I missing ?

No, the GL_OES_draw_texture extension, which is supported on the iPhone (but not the simulator). Don't know if it will make a dramatic difference though...

[yonosoytu]

First I want to thank Vintersum and others for the work they are doing in the iPhone port, it's great.

Second, when I come back (from time to time, unfortunately) to see what progress you guys have made, I always found the Xcode project out of sync with the source code. Do you use any kind of automatic procedure for updating the Xcode project or is all by hand?

And third, as far as I know, right now, to install new games (in a non-jailbroken device) you have to be a iPhone program developer and "compile" the games into the application itself. Not the best way.

What if... we implement a URL handler in the iPhone port of ScummVM? this handler will take a zip file using HTTP from the given URL and uncompress it on the Documents folder of the device. We will then add this new folder to the ScummVM system (the zip file will be the game folder contents directly, not a zip file with a directory inside, that way we can uncompress in a directory and we will know the directory name).

Parts I know (more or less) how to do:
- Define and implement the URL Handler.
- Download the file from Internet (it will be great to have a progress bar, but that part will be, probably more complicated, I don't know).
- Unzip a zip file and copy it to the filesystem (using NuZip, http://github.com/timburks/nuzip/tree/master, which is Apache 2, so I think there will be no problem).

Parts I am not sure how to do:
- Ask ScummVM to show the add game screen for the unzipped directory.

Do you think is (technically) possible?

I think it will be a good thing to have (and I think the main ScummVM source code have not to be touch at all), because not every one have a developer account and that way I can distribute (AdHoc) the same binary and my friends and family can include themselves their own games (provided they have access to a webserver... in Mac OS X Personal Web Sharing will do).

I also think that this mechanism allows us to be nearer to the possibility of being able to offer ScummVM iin the App Store (yes, I know the clausule about the interpreted content, but Tap Tap Revenge 2 includes Lua and nobody say nothing about their "interpreted content", because they treat it as game assets).

If you tell you are interested I will try to implement the URL handler, downloading, and unzipping part. But I need a little help with the last part.