[SDL] SDL 1.3 now banned from the iPhone?

[michelleC]

Already working on that and I think I have Sam's blessing.

I doubt a fork will be necessary the iphone portions of 1.3 will never fly with iphone developers. Hopefully when I do publish some actual library mods we can sit done as a community decide what we like and what I need to change.

As I've mentioned to Sam, right now the priority is to get the app done, when I have that completed, I plan to look at my mods and see what would be appropriate as a permanent 1.3 patch and what won't work. 

Hopefully sdl won't get caught in this backlash about 3.3.2. I've asked for clarification on the official forum but haven't gotten a reply yet.

But understand that sdl and the iphone WILL never be a perfect match, the Iphone UI methodology will just never allow that.

I don't know if you can class iphone as with any other phones other than maybe android. And the real gaming platform is ipad not iphone. Its a beautiful device to work with.

BTW 

You are totally off base about hackers, I know from experience some very good and important developers who don't know a thing about how OS's work, that is ok, trouble is there are people out there like me who can probably hack any system I wanted to if I actually wanted to. I've had to do some of that legally for a client so I know.

Something about morals keeps me from doing anything further. OH Well.


Nathaniel J Fries wrote:
> 
> michelleC wrote:
> > You know SDL might not be banned but the way some people are discussing it it might just prompt apple to include it in the ban.
> > I usually go along with Apples decisions, most are logical and trying to keep with good programming practices even though I don't agree with then. Such as not using private 
> > api's but this 3.3.1 clause seems like a knee jerk reaction aimed at flash which could have a ripple effect.
> 
> I'm the same way. Usually, although I greatly dislike Apple's policy, I do see how they can be a very simple way of "controlled computing" -- a principle I will never agree with.
> However, it's the way Apple decided to run with it, so let them.
> 
> This time, though, I don't see how it can be "controlled computing". Like you said, their target was flash, but they took out with it many great projects like Unity3D and MonoTouch. :(
> 
> 
> michelleC wrote:
> > This stuff about cross compilers producing inferior code is garbage, Back in the day when I was in engineering schools, we use to write our c and pascal compilers (yes I wrote compilers they are not some mystical beast like a unicorn) then compile the compiler code with the new compile which produced tighter optimized code. We also used to build intermediate little "Control" languages and interpreters into our code.
> 
> Well, certainly, flash sucks on ARM processors.
> MonoTouch didn't, though, and neither would Lua, Python, or the like.
> 
> 
> michelleC wrote:
> > Todays systems with all their complexity are more vulnerable than ever to hackers, why , because so many programmers only know how to program at a high level that they don't know how to guard against old school programmers  who are going to come in thru a very low level back door. I might spot it but I promise you 70% of the coders out there won't.
> 
> I disagree with that, basically. It's not the high level programmers not understanding old school programmers -- although I've done a tiny amount of low-level programmer, I'm really just a high level programmer with lower level interests. Even before I learned programming (granted, 6+ years ago, but still), I never found myself vulnerable to such attacks.
> It has to do with the fact that people just don't know how to protect themselves and are too lazy to learn, and thus have learned to rely on firewalls and other such things that will let many things slip through the cracks. Even then, some people with firewalls installed find them irritating and frequently turn them off... bad move on their part, but that's okay because they probably already got something anyway.
> 
> 
> michelleC wrote:
> > SDL for iphone is not and never will be a compatibility layer, for safety any reference to that terminology should be removed. The licensed version of sdl is just a statically linked library of c and c++ code. 
> > 
> > Any so called compatibility level is simply achieved by a jump table that translates sdl methods to iphone api methods. if Steve jobs considers that a violation of 3.3.1 then opengl itself is guilty too.
> 
> You're right, it isn't an "iPhone compatibility layer", it is a "system UI compatibility layer". It's not just a compatibility layer for iPhone, it's a compatibility layer for OS X, Linux, Windows, *BSD, and any other operating system that may find itself an SDL port in the future.
> 
> 
> michelleC wrote:
> > 3.3.1 is clearly aimed at tools such as montouch, freepascal and adobe cs which interpret foreign code such as actionscript or c# into objective-c compilable code. clearly that should be the demarcation if there should be one at all.
> 
> But what's wrong with that...? That's what I want to know.
> Sure, Flash on iPhone pretty much blows and has probably been ruining the platform, but monotouch and freepascal? I think they're fine...
> Honestly, I think that if Apple has a problem with the third party doing it, they should port Mono and FreePascal themselves. Mono and FreePascal through Xcode would be great.
> And, just to satisfy my own suspicions, I think the fact that those great projects were affected along with flash is really just their way of taking a poke at F/OSS again. :(
> 
> 
> michelleC wrote:
> > SDL on the iphone works because it is a layer between sdl and open gl, it is almost a one to one, sdl commands map to opengl commands or a set of sdl commands, you can get the exact same effect building your own methods, its just someone already took the time to do it for you.
> > 
> > SDL's 1.3 implementation of open gl is so "Soft" in fact it makes it a pain to create anything resembling an iphone applications. understand I am not criticizing sdl and the overall package is much better than the "subset" intended for iphone and most importantly with abiet some extra work you can move games and other applications from other platforms WHICH DOES make it a powerful class library .
> > 
> > But the way sdl creates its windows and eagl views in code makes it harder to add common iphone ui elements like nib files and subviews. It can be done, but I am finding to my dismay it can't be done in a generic way, every app requires the code to tailored in a slightly different manner.
> 
> Eh, you might be right. But that's because SDL doesn't create windows in the iPhone way, it creates them in the PC way; which is proper because PC systems are SDL's biggest targets.
> If you want better iPhone integration from SDL, we already know you have the familiarity with SDL to do it.
> Make your own fork project; or simpler, write your own API to accompany SDL in performing these tasks. The great thing about F/OSS, the reason I love it, is that if you want to change how the product works to fit your wants and needs, it's very simple. You should take advantage of this fact
> 
> 
> michelleC wrote:
> > Trying to write portable code on the iphone platform is an observitiy, Maybe 3.3.1 is Apples's unique way of admitting they designed a system that is hostile to portable code, building apps on the iphone is all about customizing view controllers and stacking views and subviews, you can do all that in code but than you have to go out of your way to mirror all the hidden initialization you get from using IB.
> 
> Well, I don't think it's that bad. The truth is, a phone is not and never will quite be a PC. They have different needs, different capabilities, and extremely different hardware (although ARM seems to think it can step into the PC market soon, but, they're not there quite yet). So of course writing code portable from a phone to a PC isn't easy, and SDL might not be the ideal answer for that.
> However, SDL is pretty much ideal for porting between PC systems...
> 
> 
> michelleC wrote:
> > Running sdl in the manner prescribed by the documentation would definitely feed an Apple argument to ban it, it uses no nib files (which isn't exactly that bad, Erica Sadun wrote an entire iphone "cookbook" full of examples that only use a main.m without any nibs. But nibs do help in loading and unloading view controllers which you will find is true when you try to convert an sdl program to use splitview controllers on the ipad. Like me you are going to have to reintroduce the mainWindow.xib at startup otherwise you might get the splitview to show with some trickery but you won't get the popoverview to work correctly.
> 
> So fork, or patch, or allow specification of your own nib files through a companion API. I don't really know how nib files work.
> I imagine it can't be too hard to make a companion library to SDL specially made for the iPhone that implements everything you've described. At least not for someone used to them.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20100412/a8728d65/attachment.htm>