The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Take a look at this:

http://forums.libsdl.org/viewtopic.php?t=7596&sid=a27489538cb3fe3018ed1511bb60bb81

I've gotten around to this part in dim3, and it's a problem. What
basically needs to happen is my app needs to go dead; it doesn't need to
run a loop polling the SDL event loop (which isn't supposed to be
legal.) It needs to be sent away as quickly as possible and be dead
until it receives an event to wake up.

Also, there's no way to get the memory low, "please unload everything"
event.

You need to respond to these events in a timely fashion and one misqueue
and your app will crash (it catches GPU usage in the background).

That said, I understand how tricky or hacky this kind of change could be
as right now SDL is a polling model, and I'd also *assume* android might
need or could benefit from the same thing.

While the original reply is fine, I wouldn't mind a single "catch all"
callback mechanism to handle these special cases. An API that like is
generic and therefor more future proof. An API like:

void SDL_SetSystemEventHook(SDL_SystemEventHook handler);

And basically you'd define:

void myHandler(int event,void *data) { // do your stuff }
SDL_SetSystemEventHook(&myHandler);

"event" could be:

SDL_SYSTEMEVENT_WILL_RESIGN (data = NULL)
SDL_SYSTEMEVENT_DID_RESUME (data = NULL)
SDL_SYSTEMEVENT_LOW_MEMORY (data = NULL)

(or maybe something less iOS-ie.) Obviously, the data is for structs or
whatever if some calls require it in the future.

What do you guys think?

[>] Brian
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I like it, and the changes are badly needed. I've been manually hacking every version I pull. The API you present is general and, as you said, future proof.

I support this addition, or one like it. Regardless of the form it takes, we need to add something to keep SDL relevant in the mobile era.

I am not an expert on iPhone and Android but have dabbled in them and stared blankly at the app guidelines a few times, the following information is unreliable but I believe it to be in the right
ballpark...

As I understand it both iPhone and Android use a start/shutdown/foreground/background/suspend/resume set of events and states when it comes to managing applications, in general applications are
expected (if not forced) to suspend to disk (in their own way) when in the background for even a short time, this may be tied to low memory states.

So to put that another way, a proper app must be able to dump its basic UI and game state to disk and restore it later, it also must have a background state where the graphics context is destroyed
(and hence all GL calls = crash, etc) and CPU usage must be minimized for a good user experience.

NVIDIA's mobile resources page has a *very* good video lecture about how Android manages application state, and how many different states there are and the transition events and things to consider
when designing an application for Android.

I don't know if there's an equivalent lecture for iPhoneOS but it would be worth a quick search to see if there is.

I believe there are responsiveness time limits (but probably very lax) on all of this.

It would be beneficial if someone with the time can summarize the states that SDL needs to be aware of on each platform so that we can continue discussion on how to achieve this, finding the
middleground and edge cases, the overall status change flow would be key to designing a proper behavior here.

At the very least we need more SDL event types for these special status changes, but I am more in favor of handling them via a callback handler rather than attempting to deliver them as events.

So I propose something along the lines of an SDL_SetShutdownCallback(eventtype, func, data) API call which would associate custom handlers with specific "big important events" in the life of the app
that are called by the glue code outside the main event stream, such as shutdown/background/suspend, and having start/foreground/resume delivered as callbacks as well (these could wait until the first
poll event occurs however, to let the app get to its main loop).

Probably a lot of discussion to go on the best way to hook these callbacks, or alternative, but the longjmp we're doing right now to deliver an SDL_QUIT already gives me the creeps.

Suggestions?

On 11/07/2011 10:50 AM, Brian Barnes wrote:


--
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Forest Hale wrote:


On iOS, resume/suspend and "dump your state" are different calls, and
it's not optimal to dump your state if unnecessary (somebody jumps out
to check a tweet and then back in to your game, you don't want to have
to stall and reload everything.)

I can't speak for Android, but because of this iOS will need separate
events. If android wants you to unload (and I'd find this weird there,
too, but I have no ideal) the Android version can push a "memory low"
right after the "suspend" message.

If I had my way, I'd stick with one callback routine that passes the
event type. It's a bit cleaner in code, requires only one new API and a
list of event types, and is a bit more future proof for adding new
events without changing the base API. The poll event loop works that
way, and it's consistent.

Right now, to use SDL on iOS, you'll need the suspend/resume/low memory
events. Check the original message I linked to earlier for a bit more
information.

Hopefully an Android guy/gal can chime in, but I can't really imagine an
API like this won't cover that (and WP7 and whatever else the future holds.)

[>] Brian
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org