Thoughts on a more iphone friendly sdl

SDL Development
1

I am looking over the SDL base code. Its pretty impressive and deserves recognition.

However, it seems to be a straight port. That has no way to tap into the uikit, location or some of the other common api’s on the iphone.

That in my opinion makes it less attractive to the iphone developer.

Porting a game from another platform to the iphone would be easier.

But , how many applications can actually be ported that way. And creating games in opengles is not that hard.

Still there are many applications on the linux side that can be ported that are written in sdl. Some of these are video apps that are dearly needed on the mobile platform and have become highly optimized in there sdl over time.

My effort is to restore some functionality that sdl apparently had, that is the ability to tap into the iphone uikit for you can display either modal or non modal widows, (uiwebviews, uiimagepickers etc) , From what I seem so far providing multiwindows navigation views might be too difficult, but single subclassed window over the opengl window might be feasible.

I’ve set a simple proof of concept as my goal to expand on.

  1. open a uril to a webbased app.
  2. retrieve a list of players,users
  3. open a uiview of some kind (tableview, uiwebview etc)
  4. allow user to pick from list
  5. display on picked player on game screen

As a subgoal handle any uri passed through the handleOpenUrl method in the applicationsDelegate

I think from what I’ve seen so far in the sdl code the above is feasible.

If anyone has tried anything like this without resorting to third party libraries we would be interested in hearing about it.

We already are testing a proof of concept that gives us at lest point 1 and the subgoal by moding the uitappkitview and uitappdelegates in the sdl base code and adding methods to handle shared key chains.

One open question, would such a shared application be acceptable to apple reviewers remains to be determined.

2

Starting to identify code to change

The keyboard is handled here, this seems the obvious spot for our hook.

#if SDL_IPHONE_KEYBOARD

/* Is the iPhone virtual keyboard visible onscreen? */

  • (BOOL)keyboardVisible {
    return keyboardVisible;
    }

/* Set ourselves up as a UITextFieldDelegate */

  • (void)initializeKeyboard {

Obviously this needs to change too.

int UIKit_CreateWindow(_THIS, SDL_Window *window) {

/* We currently only handle single window applications on iPhone */
if (nil != [SDLUIKitDelegate sharedAppDelegate].window) {
    SDL_SetError("Window already exists, no multi-window support.");
    return -1;
}

/* ignore the size user requested, and make a fullscreen window */
UIWindow *uiwindow = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

if (SetupWindowData(_this, window, uiwindow, SDL_TRUE) < 0) {
    [uiwindow release];
    return -1;
}    

// 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;

}

3

i don’t agree at all
SDL helps you create and set up a SIMPLE directmedia layer.
in the definition of SIMPLE and of LAYER wrapping the various system calls
in single library functions is completely normal.
the main target of SDL is that you can create a single program and compile
it on every platform without any modification to the source, and it does a
pretty good job at this!

SDL on the iphone CAN and SHOULD be improved in many ways, like i pointed
out in a previous email (landscape, ipad, opengles2), but allowing custom
objc to be called directly goes beyond the scope of this library.
If you want to have custom view, a nicer multitouch and co., you always have
the source you can modify (quite easily)

bye
Vittorio

Mike Ditka http://www.brainyquote.com/quotes/authors/m/mike_ditka.html -
"If God had wanted man to play soccer, he wouldn’t have given us arms."On Fri, Feb 12, 2010 at 2:00 PM, michelleC wrote:

I am looking over the SDL base code. Its pretty impressive and deserves
recognition.

However, it seems to be a straight port. That has no way to tap into the
uikit, location or some of the other common api’s on the iphone.

That in my opinion makes it less attractive to the iphone developer.

Porting a game from another platform to the iphone would be easier.

But , how many applications can actually be ported that way. And creating
games in opengles is not that hard.

Still there are many applications on the linux side that can be ported that
are written in sdl. Some of these are video apps that are dearly needed on
the mobile platform and have become highly optimized in there sdl over time.

My effort is to restore some functionality that sdl apparently had, that is
the ability to tap into the iphone uikit for you can display either modal or
non modal widows, (uiwebviews, uiimagepickers etc) , From what I seem so far
providing multiwindows navigation views might be too difficult, but single
subclassed window over the opengl window might be feasible.

I’ve set a simple proof of concept as my goal to expand on.

  1. open a uril to a webbased app.
  2. retrieve a list of players,users
  3. open a uiview of some kind (tableview, uiwebview etc)
  4. allow user to pick from list
  5. display on picked player on game screen

As a subgoal handle any uri passed through the handleOpenUrl method in the
applicationsDelegate

I think from what I’ve seen so far in the sdl code the above is feasible.

If anyone has tried anything like this without resorting to third party
libraries we would be interested in hearing about it.

We already are testing a proof of concept that gives us at lest point 1 and
the subgoal by moding the uitappkitview and uitappdelegates in the sdl base
code and adding methods to handle shared key chains.

One open question, would such a shared application be acceptable to apple
reviewers remains to be determined.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

Its about revenue, not much more when it comes to apps.

I talk to a lot of developers and the central argument against SDL is , its a pain to use.

You have to go through hoops and loops to do what you can do in the native sdl easily.

And why, because sdl locks you out from using this functionality.

I’ve seen many attempts at designs like this, my day job is a web designer and my company sells software products. One of our products failed badly, why because the designers had some dream of a completely model driven environment that would do everything but wash your car.

If you want to have custom view, a nicer multitouch and co., you always have the source you can modify (quite easily)

Sure , define your definition of easy.

This thread was set up for suggestion how my development team can add features we want which as you already stated (can be easily modified and is allowed by the license) not to defend, criticize or expand on the merits of the enviroment. It may be fine for some people and not others.

Vittorio G. wrote:> i don’t agree at all

SDL helps you create and set up a SIMPLE directmedia layer.
in the definition of SIMPLE and of LAYER wrapping the various system calls in single library functions is completely normal.
the main target of SDL is that you can create a single program and compile it on every platform without any modification to the source, and it does a pretty good job at this!

SDL on the iphone CAN and SHOULD be improved in many ways, like i pointed out in a previous email (landscape, ipad, opengles2), but allowing custom objc to be called directly goes beyond the scope of this library.
If you want to have custom view, a nicer multitouch and co., you always have the source you can modify (quite easily)

bye
Vittorio

Mike Ditka (http://www.brainyquote.com/quotes/authors/m/mike_ditka.html) ?- “If God had wanted man to play soccer, he wouldn’t have given us arms.”

On Fri, Feb 12, 2010 at 2:00 PM, michelleC <@michelleC (@michelleC)> wrote:

  I am looking over the SDL base code. Its pretty impressive and deserves recognition.

However, it seems to be a straight port. That has no way to tap into the uikit, location or some of the other common api’s on the iphone.

That in my opinion makes it less attractive to the iphone developer.

Porting a game from another platform to the iphone would be easier.

But , how many applications can actually be ported that way. And creating games in opengles is not that hard.

Still there are many applications on the linux side that can be ported that are written in sdl. Some of these are video apps that are dearly needed on the mobile platform and have become highly optimized in there sdl over time.

My effort is to restore some functionality that sdl apparently had, that is the ability to tap into the iphone uikit for you can display either modal or non modal widows, (uiwebviews, uiimagepickers etc) , From what I seem so far providing multiwindows navigation views might be too difficult, but single subclassed window over the opengl window might be feasible.

I’ve set a simple proof of concept as my goal to expand on.

  1. open a uril to a webbased app.
  2. retrieve a list of players,users
  3. open a uiview of some kind (tableview, uiwebview etc)
  4. allow user to pick from list
  5. display on picked player on game screen

As a subgoal handle any uri passed through the handleOpenUrl method in the applicationsDelegate

I think from what I’ve seen so far in the sdl code the above is feasible.

If anyone has tried anything like this without resorting to third party libraries we would be interested in hearing about it.

We already are testing a proof of concept that gives us at lest point 1 and the subgoal by moding the uitappkitview and uitappdelegates in the sdl base code and adding methods to handle shared key chains.

One open question, would such a shared application be acceptable to apple reviewers remains to be determined.

SDL mailing list
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

5

I talk to a lot of developers and the central argument against SDL is , its
a pain to use.

I, and most other developers, find it quite easy to use. I suspect you meant
iPhone developers.

Unlike most who use SDL, I don’t develop games. Most of what I use SDL for is
mathematical applications (for my students), or development tools for
embedded systems programmers. I appreciate the “Simple” in SDL. Much easier
to use than Gtk+ or Qt (although there are applications for which Qt would be
a better choice).

Sure , define your definition of easy.

That’s recursive :slight_smile:

JeffOn Friday 12 February 2010 12:09, michelleC wrote:

6

michelleC wrote:

From what I’ve been reading it sounds like earlier versions of sdl 1.2 on mac osx had the ability to use the xib file and allow access to the uikit but this was removed because of incompatablilites with leopard or snow leporad.

I am going to start a new thread on, this is moving away from a discussion of roadmaps (sorry) and into a development path.

In fact intention was never to criticize because sdl looks like it was a huge undertaking. AND I have no intention to make a request and wait for it to be considered.

Rather I am going to pull as much info together as I can, create the functionality I need and IF the sdl providers want to include that in the base thats fine with me. If not than the code is just unique to my app.

Well, this project is pretty community driven. If you can make it in a way that doesn’t change the API, break cross-platform building of the same code, or completely break SDL on any other system; I’m sure it’ll be a very much welcomed patch (SDL doesn’t want to limit you, it just wants to work essentially the same on every system).

I would like to say, though, that you’re clearly talking about SDL from an iPhone-development-only view. SDL is not designed around a mobile device, it is designed around a modern PC. Sure, it is available on the iPhone, but it’s for the PC - the iPhone is a completely different piece of hardware. I can hardly speak for the actual developers and maintainers of SDL, but I take the iPhone port as a way for PC developers to put their pre-existing SDL-based product on a large new platform with minimal effort. It’s certainly not to help iPhone developers make an iPhone application a little bit easier, anyway.

Side note: realistically, most of what UIKit has to offer is available elsewhere. It’s unfortunate that the iPhone’s webkit headers are hidden away, unlike on the mac - this would allow you to do anything with your SDL window that you could with UIWebView anyway. Of course, it’s still there (UIWebView uses it internally), so you can always just make the headers public yourself (though it might not be the best idea, maybe they hid them for a reason? Or maybe Apple’s just a bunch of douchers. I really can’t tell sometimes).

7

nfries88 wrote:

michelleC wrote:

From what I’ve been reading it sounds like earlier versions of sdl 1.2 on mac osx had the ability to use the xib file and allow access to the uikit but this was removed because of incompatablilites with leopard or snow leporad.

I am going to start a new thread on, this is moving away from a discussion of roadmaps (sorry) and into a development path.

In fact intention was never to criticize because sdl looks like it was a huge undertaking. AND I have no intention to make a request and wait for it to be considered.

Rather I am going to pull as much info together as I can, create the functionality I need and IF the sdl providers want to include that in the base thats fine with me. If not than the code is just unique to my app.

Well, this project is pretty community driven. If you can make it in a way that doesn’t change the API, break cross-platform building of the same code, or completely break SDL on any other system; I’m sure it’ll be a very much welcomed patch (SDL doesn’t want to limit you, it just wants to work essentially the same on every system).

I would like to say, though, that you’re clearly talking about SDL from an iPhone-development-only view. SDL is not designed around a mobile device, it is designed around a modern PC. Sure, it is available on the iPhone, but it’s for the PC - the iPhone is a completely different piece of hardware. I can hardly speak for the actual developers and maintainers of SDL, but I take the iPhone port as a way for PC developers to put their pre-existing SDL-based product on a large new platform with minimal effort. It’s certainly not to help iPhone developers make an iPhone application a little bit easier, anyway.

Side note: realistically, most of what UIKit has to offer is available elsewhere. It’s unfortunate that the iPhone’s webkit headers are hidden away, unlike on the mac - this would allow you to do anything with your SDL window that you could with UIWebView anyway. Of course, it’s still there (UIWebView uses it internally), so you can always just make the headers public yourself (though it might not be the best idea, maybe they hid them for a reason? Or maybe Apple’s just a bunch of douchers. I really can’t tell sometimes).

Well active communities are good for projects, they usually encourage steady profit. I seem to be ruffling some features, maybe you just misconstrue my intentions. I want to be a contributor to this community not some radical that comes in and hacks the libs for my own nefarious purpose.

All I want to do is add a few iphone specific methods and to handle the runloop differently if the target is iphone, perhaps create an iphone specific template.

There is no point in adding features to a package if it breaks the functionality that is there and/or changes the “flavor” of the environment to look like something entirely different.

Basically I think I want to subclass some existing methods and isolate the main function from thise specific methods for instance if you call this method now

SDL_INIT (SDL_AUDIO_INIT)

you get duplicate symbol under _main,

Similarly if you call SDL_INIT_SUBSYSTEM (SDL_AUDIO_INT)

you get a similar message

If you call SDL_OPENAUDIO, the result is better but because that is a private function it expects some initiallization beforehand,

so maybe a method such as

SDL_Extetnal_Subsystem(audio,audioUnit)

Or something like that would be appropriate, similarly for other subsystems as well.

can’t see how that kind of mods would affect anything even overall design philosophy.

Also older versions of sdl had the provision for using the nib , I would try to put that back in which would open the possibility of including toolbars etc.

I’ve been a developer for a long time

started with c, smalltalk went to java was even on the mainframe for a while.

Spent most of my experience in java, started going back to c though when the iphone came on the scene, I;ve been an iphone developer since the program begun.

8

nfries88 wrote:>

michelleC wrote:

From what I’ve been reading it sounds like earlier versions of sdl 1.2 on mac osx had the ability to use the xib file and allow access to the uikit but this was removed because of incompatablilites with leopard or snow leporad.

I am going to start a new thread on, this is moving away from a discussion of roadmaps (sorry) and into a development path.

In fact intention was never to criticize because sdl looks like it was a huge undertaking. AND I have no intention to make a request and wait for it to be considered.

Rather I am going to pull as much info together as I can, create the functionality I need and IF the sdl providers want to include that in the base thats fine with me. If not than the code is just unique to my app.

Well, this project is pretty community driven. If you can make it in a way that doesn’t change the API, break cross-platform building of the same code, or completely break SDL on any other system; I’m sure it’ll be a very much welcomed patch (SDL doesn’t want to limit you, it just wants to work essentially the same on every system).

Or maybe I just had to copy some of the classes from sdl/video/uikit to my project and modify them there.

I guess because all the sdl uikit functionality .m files were hidden in the library I didn’t realize how much control I had over the environment .

Stupid me…

I would like to say, though, that you’re clearly talking about SDL from an iPhone-development-only view. SDL is not designed around a mobile device, it is designed around a modern PC. Sure, it is available on the iPhone, but it’s for the PC - the iPhone is a completely different piece of hardware. I can hardly speak for the actual developers and maintainers of SDL, but I take the iPhone port as a way for PC developers to put their pre-existing SDL-based product on a large new platform with minimal effort. It’s certainly not to help iPhone developers make an iPhone application a little bit easier, anyway.

Side note: realistically, most of what UIKit has to offer is available elsewhere. It’s unfortunate that the iPhone’s webkit headers are hidden away, unlike on the mac - this would allow you to do anything with your SDL window that you could with UIWebView anyway. Of course, it’s still there (UIWebView uses it internally), so you can always just make the headers public yourself (though it might not be the best idea, maybe they hid them for a reason? Or maybe Apple’s just a bunch of douchers. I really can’t tell sometimes).

9

I would actually love to see some interesting iPhone extensions for
people using SDL. Unfortunately I don’t have the time or the
knowledge to put them together myself, but I’d love to see what people
come up with.

See ya!On Fri, Feb 12, 2010 at 5:00 AM, michelleC wrote:

I am looking over the SDL base code. Its pretty impressive and deserves
recognition.

However, it seems to be a straight port. That has no way to tap into the
uikit, location or some of the other common api’s on the iphone.

That in my opinion makes it less attractive to the iphone developer.

Porting a game from another platform to the iphone would be easier.

But , how many applications can actually be ported that way. And creating
games in opengles is not that hard.

Still there are many applications on the linux side that can be ported that
are written in sdl. Some of these are video apps that are dearly needed on
the mobile platform and have become highly optimized in there sdl over time.

My effort is to restore some functionality that sdl apparently had, that is
the ability to tap into the iphone uikit for you can display either modal or
non modal widows, (uiwebviews, uiimagepickers etc) , From what I seem so far
providing multiwindows navigation views might be too difficult, but single
subclassed window over the opengl window might be feasible.

I’ve set a simple proof of concept as my goal to expand on.

  1. open a uril to a webbased app.
  2. retrieve a list of players,users
  3. open a uiview of some kind (tableview, uiwebview etc)
  4. allow user to pick from list
  5. display on picked player on game screen

As a subgoal handle any uri passed through the handleOpenUrl method in the
applicationsDelegate

I think from what I’ve seen so far in the sdl code the above is feasible.

If anyone has tried anything like this without resorting to third party
libraries we would be interested in hearing about it.

We already are testing a proof of concept that gives us at lest point 1 and
the subgoal by moding the uitappkitview and uitappdelegates in the sdl base
code and adding methods to handle shared key chains.

One open question, would such a shared application be acceptable to apple
reviewers remains to be determined.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

10

working on it, more of an addon extension than a mod.

I can understand the time issue.

In theory I have a implementation that should work, at least on paper. But making this work someone would have to have a lot of experience with how the sdl works. I guess I fit that bill, But I still do not have all the pieces how sdl works.

Check back in a couple weeks. I may have something interesting.

Sam Lantinga wrote:> I would actually love to see some interesting iPhone extensions for

people using SDL. Unfortunately I don’t have the time or the
knowledge to put them together myself, but I’d love to see what people
come up with.

See ya!

On Fri, Feb 12, 2010 at 5:00 AM, michelleC <@michelleC> wrote:

I am looking over the SDL base code. Its pretty impressive and deserves
recognition.

However, it seems to be a straight port. That has no way to tap into the
uikit, location or some of the other common api’s on the iphone.

That in my opinion makes it less attractive to the iphone developer.

Porting a game from another platform to the iphone would be easier.

But , how many applications can actually be ported that way. And creating
games in opengles is not that hard.

Still there are many applications on the linux side that can be ported that
are written in sdl. Some of these are video apps that are dearly needed on
the mobile platform and have become highly optimized in there sdl over time.

My effort is to restore some functionality that sdl apparently had, that is
the ability to tap into the iphone uikit for you can display either modal or
non modal widows, (uiwebviews, uiimagepickers etc) , From what I seem so far
providing multiwindows navigation views might be too difficult, but single
subclassed window over the opengl window might be feasible.

I’ve set a simple proof of concept as my goal to expand on.

  1. open a uril to a webbased app.
  2. retrieve a list of players,users
  3. open a uiview of some kind (tableview, uiwebview etc)
  4. allow user to pick from list
  5. display on picked player on game screen

As a subgoal handle any uri passed through the handleOpenUrl method in the
applicationsDelegate

I think from what I’ve seen so far in the sdl code the above is feasible.

If anyone has tried anything like this without resorting to third party
libraries we would be interested in hearing about it.

We already are testing a proof of concept that gives us at lest point 1 and
the subgoal by moding the uitappkitview and uitappdelegates in the sdl base
code and adding methods to handle shared key chains.

One open question, would such a shared application be acceptable to apple
reviewers remains to be determined.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org