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.
iPhone 3g
Moderator: ScummVM Team
-
- Posts: 129
- Joined: Mon May 05, 2008 3:37 pm
- Vinterstum
- ScummVM Developer
- Posts: 580
- Joined: Sun Oct 16, 2005 6:59 am
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 ).
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.
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.
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?
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?
- Vinterstum
- ScummVM Developer
- Posts: 580
- Joined: Sun Oct 16, 2005 6:59 am
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.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?
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 .
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
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