// This saves the main window in the app delegate so event callbacks can do stuff on the window.
// This assumes a single window application design and needs to be fixed for multiple windows.
[SDLUIKitDelegate sharedAppDelegate].window = window;
[SDLUIKitDelegate sharedAppDelegate].uiwindow = uiwindow;
[uiwindow release]; /* release the window (the app delegate has retained it) */

return 1;

}

The question is why does sdl have this limitation.

I'm thinking if I try to use a navigation controller model or the like I will short circuit sdl's event handling.

But what about opening a uiwebView, to me that seems like it could be done with little damage.

library implies a usable collection of methods that let you perform the function, not a library that thinks its an enviroment and literally takes over the runloop.

On the other hand , it is fairly easy to port a linux app to the iphone. ie. some video apps.

Fine but than what can you do, without a lot of effort you can't pass data to it, it can't interact with its environment except for the few states the library support. Come on that may fly on other platforms linux, xbox, nes but really is any iphone developer going to embrace that.

I set up a thread on the official forum for suggestions how we can provide some hooks to normal sdk functions, like gps etc. only get tons of stuff back from fanboys how that would break with the philosophy behind the environment. this girl doesn't care about design philosophy , I just want a product that actually has some potential for sale.

Well, certainly if it is fighting with you about what you're trying to accomplish on iPhone, then yes, I'd say you should go your own way. It's not hard to set up the environment on iPhone anyway. As much as I like what SDL has to offer, I personally see no benefit to using it on iPhone.

Skorche Wrote:I don't really see the benefit of it on the iPhone either. It's really not well suited to the iPhone's inputs, and it doesn't have much else to offer that makes it useful like it is on the desktop.

came up with an iphone specfic solution, Not sure if there is a way to make it generic.

The iphone actually DOES let you create multiple windows, there are a few apps I know of in the app store that take advantage of this fact but not sdl, there are one or two apps that would like to get appstore approval that use this fact to display tv out, ie. display an image on the screen with overlays and everything but another to the tv out cable. Alas, they use undocumented api's so the authors just have to sit an wait.

But the the fact that the iphone can have several uiwindows but can only have one window as keywindow is an advantage.

You can create the sdl window and the coaca window, complete with tabbars , navigation anything you want . You have to do some notifications and set some keys to try to make it generic but basically each window just takes turns becoming the key window.

There is a game api that uses a similar method,UNITY what it does it when it launches it shows the users a menu system, after the user does the initial setup and is ready to play the game the menu relinquishes control to Unity . When the player is within the unity system and decides to return to the menu system clicking a button sends a notification and sets a key . The notification is handled and the menu frontend once again becomes the key window.

My solution is quite similar to this, but SDL is not quite the black box Unity is, so I have more control over when to swap windows.

I still don't really understand why you'd want to do this. Using SDL on the iPhone really only saves you a couple hundred lines of code that you can grab from the OpenGL template. I especially don't understand it when you are trying so hard to work around SDL's shortcomings.

Skorche Wrote:I still don't really understand why you'd want to do this. Using SDL on the iPhone really only saves you a couple hundred lines of code that you can grab from the OpenGL template. I especially don't understand it when you are trying so hard to work around SDL's shortcomings.

We are porting programs already written in sdl.

Aside from that in theory we should be able to take the code and run it on an Android device.

And giving developers one more option doesn't hurt, I don't see much of a performance lost or gain either way.

Skorche Wrote:I still don't really understand why you'd want to do this. Using SDL on the iPhone really only saves you a couple hundred lines of code that you can grab from the OpenGL template. I especially don't understand it when you are trying so hard to work around SDL's shortcomings.

to put this is a little more perspective.

Lets say I wanted to model for a game for instance the effects of time dialation as you approach the outer event horizon of a Schwarzschild blackhole.

I could start by building the code from stratch. But its well possible something like this already exists on another system , maybe linux based.

If its written in SDL than in theory I should be able to take the SDL code and move it to the iphone. Only taking into account the differences in some of the methods for that particular environment. (most common sdl methods get mapped to audio, video and pthreads just fine).

My problem with SDL was its lack of direct support of the iphone ui, but it turns out that the problem is only in how the library is packaged. They tried to hide the entire implementation. Once I got around that it wasn't an issue.

Anyway, Now I should be able to take this simulation and again with only marginal changes move it to a supported platform android (sdl 1.2, almost works ok), psp , xbox etc..

trades time for a slight decrease in performance, sometimes made up by optimizing the code.