iPhone 3g

Subforum for discussion and help with ScummVM's iPhone port

Moderator: ScummVM Team

Post Reply
Jojo Jr.
Posts: 16
Joined: Thu Jul 19, 2007 3:56 pm

iPhone 3g

Post by Jojo Jr. »

Okay, new iPhone is coming out - might this dramatically affect the Scumm port in any way?

Sorry if it's an obvious question/answer, but I'd still really like to know before (if?) I buy one.


Cheers,
Clark.
hippy dave
Posts: 127
Joined: Mon May 05, 2008 3:37 pm

Post by hippy dave »

my mostly uneducated guess is no, it won't change much for scummvm. the significant changes are to the actual phone functionality (ie making calls etc), and maybe more storage space, but not much to the basic system.
User avatar
Vinterstum
ScummVM Developer
Posts: 580
Joined: Sun Oct 16, 2005 6:59 am

Post by Vinterstum »

The iPhone 3G will come with firmware v2.0, so it might take some time to make everything compatible (But I'll be getting one on release day :P ).

I wouldn't expect any changes in functionality. Unless Apple has made it impossible to, for example, run processes in the background, due to the API changes. It won't be possible with the official SDK, for example.
fingolfin
Retired
Posts: 1452
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin »

Regarding running in the background:

Well, I invite you to push on scummvm-devel for us to add a suspend/resume capability to ScummVM. I am sure many hand helds would benefit from such a thing. Being able to "freeze" ScummVM at any given moment would be a big bonus.

For some games, this could be achieved by simply forcing a temporary save. Of course, this would not be perfect (e.g. in SCUMM games there are some spots where you just can not save currently, e.g. when a video is playing).

Of course, if "running in the background" just means: "Program is frozen, but stays in memory", then there is a simpler way out (which you maybe already implement?): Next time pollEvent or something is called, store the current time, pause all threads/interrupts (for timer manager, audio mixer, ...), then go to sleep. When resumed, restart all interrupts, and make sure that the time value returned by OSystem::getMillis() is offset, so that to the program it seems as if it continues seemlessly.

This way, it should be possible to completely freeze ScummVM, taking zero CPU resources, only requiring "some" RAM.
But again, maybe that's already what you are doing?
User avatar
Vinterstum
ScummVM Developer
Posts: 580
Joined: Sun Oct 16, 2005 6:59 am

Post by Vinterstum »

fingolfin wrote: Of course, if "running in the background" just means: "Program is frozen, but stays in memory", then there is a simpler way out (which you maybe already implement?): Next time pollEvent or something is called, store the current time, pause all threads/interrupts (for timer manager, audio mixer, ...), then go to sleep. When resumed, restart all interrupts, and make sure that the time value returned by OSystem::getMillis() is offset, so that to the program it seems as if it continues seemlessly.

This way, it should be possible to completely freeze ScummVM, taking zero CPU resources, only requiring "some" RAM.
But again, maybe that's already what you are doing?
Yup, that's pretty much exactly what I'm doing already :). Sleeping for 100ms, polling for the restore event, then sleeping again. Works pretty well.

The problem is that the official SDK doesn't allow apps to run in the background, at all. The process has, as I understand it, a brief window in which to store its state, and then has to exit.

So yeah, the alternative left is to force a quick-save and then check for that on startup. And since not all engines may be in a saveable state at any time (as you say), that could be a problem. I think I remember Kyra had issues there for example, when using the quicksave hotkey.

Some solution has to be found, since this happens when you receive a call for instance, and is incredibly annoying if you just lose everything :).
ovvldc
Posts: 21
Joined: Fri Aug 03, 2007 9:18 am
Location: Utrecht, NL

Post by ovvldc »

Perhaps it is possible to bluntly stop all active timers and dump the whole program memory to disc? Not very graceful, but perhaps easier to implement?

And then on restart ask whether you want to start a new game, or load the previously saved state?

Just thinking out loud here. ScummVM will be at the top of my list of applications for the iGadgets.

Best wishes,
Oscar
Post Reply