Apple iOS Port WIP

Place all meeting requests / announcements here...
Post Reply
JeremyAgost
Private
Private
Posts: 4
Joined: Thu Jan 06, 2011 5:51 am

Apple iOS Port WIP

Post by JeremyAgost »

Hey. I'm working on porting the latest SVN bzflag to iOS 4.2. I understand what you're saying about the OpenGL ES predicament. For the moment I've mostly isolated the core and server from anything requiring OpenGL (by following the Makefile guidelines). So far the majority of my effort has been in getting the various dependancies to build for an iPhone target. I've gotten ares, cURL, ftgl, freetype, and SDL to compile as static libraries for linking into the target. It should be noted that due to the nature of the iOS platform, the configure/makefile script system really doesn't make sense. I'm doing all my work in an XCode project, using the makefiles as guidelines for build settings.

At present I've only really had to make changes to existing source in places where #ifdef guards are already used with the __APPLE__ definition. The biggest problem I've had is that due to the age of the bzflag Mac port, nearly all of the Mac OS X API calls already in place are useless as they're completely nonexistent on the iPhone platform. In fact, all of the iPhone API is Objective-C based, so I've been writing platform interfaces as Objective-C++, which allows the bzflag core to access API functionality with C++ functions masking the underlying Objective-C. Actually, I think that much of what I'm doing could and should be carried over into the Mac OS X port. Some of the API calls are so old (e.g. the sound functionality predating Mac OS X) that not only had I never seen them before but I could find no documentation (official or otherwise) to understand how they worked. Apple could remove these APIs at any moment and bzflag would be broken.

For the moment I'm just trying to get everything but OpenGL in place. While I'm experienced in both Objective-C and C++, my SDL and OpenGL experience is minimal. I should be able to get a good feasibility look at the graphics portion pretty soon. If anyone wants more info or maybe even to help, shoot me a message. I'm leery about distributing any of the progress I've made, as I've paid no attention to licenses of the stuff I'm working on. If someone more familiar with the project could advise me, so far I've only recompiled existing dependencies of bzflag, though I stripped all the license files out of the source directories for cleanliness and I haven't been putting any license headers into the files I've added.

If you like this idea and want to help, but don't have much programming experience or whatnot, I'd love suggestions on how to go about reimplementing the control scheme. One method I've been thinking about is essentially using an analog pad in one corner (like the existing mouse movement square) and button controls in the other.
User avatar
Bambino
Private First Class
Private First Class
Posts: 1210
Joined: Mon Apr 21, 2008 10:27 pm
Location: Alberta, Canada

Re: Apple iOS Port WIP

Post by Bambino »

Wow, someone is actually trying to port it... Good luck!

As for controls you can shake to jump and yes a mousebox like control would be good with lockon/identify, fire, burst fire(maybe. Mod needed), drop flag, and various chat buttons. I wish you the best of luck and I hope you don't give up. You will face people who will put money down that you will fail.
"Anyone who has never made a mistake has never tried anything new." -- Albert Einstein
GU League | Ducati League | OpenLeague
User avatar
blast
General
General
Posts: 4931
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: Apple iOS Port WIP

Post by blast »

Even if you get it working, I wonder if it will even be allowed in the App store. I know there have been issues with GPL licensed software, and not sure if LGPL would be any better. I'm also not sure what licenses the various libs we use are under.

http://www.fsf.org/news/2010-05-app-store-compliance

Also, we don't really use the native mac platform code, assuming you're talking about the stuff in src/platform/. Our mac builds have been using SDL for a long time.

And overall development with the project is pretty much dead. There may never be a BZFlag 3.0 released. The latest SVN trunk has numerous critical issues (for instance, geno doesn't work, team flags disappear when you die holding it, etc) and nobody is working on it.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image
User avatar
macsforme
General
General
Posts: 2069
Joined: Wed Mar 01, 2006 5:43 am

Re: Apple iOS Port WIP

Post by macsforme »

What kind of OS X API calls are we talking about? SDL does a lot, and you mentioned you already had that built. The sound-related API calls make sense, as you mentioned... so do the calls related to extracting info/files from the application package (however that works). If you are speaking of the mac platform files in src/platform/MacOSX, that entire set of files has generally been replaced by SDL as far as the official builds, although I think they still work for the most part. Otherwise, if you can say more specifically what functionality you are looking to replace, we might be able to help more.
User avatar
Bullet Catcher
Captain
Captain
Posts: 564
Joined: Sat Dec 23, 2006 7:56 am
Location: Escondido, California

Re: Apple iOS Port WIP

Post by Bullet Catcher »

Even though we claim to require SDL on the Mac, I am able to build and run trunk on my 10.4.11 MacBook without it. In my limited testing it gives mostly the same player experience as it does on my Linux system (which does use SDL).

The best way to get your changes committed to BZFlag is to post patches to the project's SourceForge tracker. To streamline the process you should ensure that all relevant licenses are complied with. Pick a simple change to start with, and join the developers in the #bzflag IRC channel on Freenode for easy feedback.
JeremyAgost
Private
Private
Posts: 4
Joined: Thu Jan 06, 2011 5:51 am

Re: Apple iOS Port WIP

Post by JeremyAgost »

blast wrote:Even if you get it working, I wonder if it will even be allowed in the App store. I know there have been issues with GPL licensed software, and not sure if LGPL would be any better. I'm also not sure what licenses the various libs we use are under.
Yeah I thought about that. Recently, I've seen an influx of GPL software on the app store (e.g. numerous versions of Frozen Bubble) so I've figured that things have changed somewhat.
blast wrote:Also, we don't really use the native mac platform code, assuming you're talking about the stuff in src/platform/. Our mac builds have been using SDL for a long time.
Actually, this morning I was working on the display stuff and event handling when I realized just that. As it were, I'm still looking into how useful SDL will be for touch control events on the iOS, or whether I should just encapsulate the Apple APIs.
Constitution wrote:If you are speaking of the mac platform files in src/platform/MacOSX, that entire set of files has generally been replaced by SDL as far as the official builds, although I think they still work for the most part. Otherwise, if you can say more specifically what functionality you are looking to replace, we might be able to help more.
Yeah, this is the kind of help I need. A lot of this platform-specific stuff is poorly documented, and it's difficult for me to deduce where specific functionality is coming from. I need to know
•Where the default sound implementation is for Mac OS X.
•Where the actual functioning event handling is. I see lots of duplicate code in the SDL and Mac platforms.
•Where the viewport is generated and maintained. The Mac display platform code looks to be nonfunctional, so I'm guessing that's all handled through SDL now?
In many places I could probably just leave the SDL implementation with minor tweaks, but the performance and quality of the end result will almost certainly suffer.

As for the stability of the current trunk, since most of my changes don't touch the core, I could probably easily merge with a stable trunk. Also, as I get more familiar with the core engine, I may make an effort to fix and improve the trunk.
User avatar
mrapple
Sergeant Major
Sergeant Major
Posts: 460
Joined: Wed May 27, 2009 11:59 am
Location: Unknown
Contact:

Re: Apple iOS Port WIP

Post by mrapple »

Cool stuff.

Maybe before porting the entire game over, start with a simple BZAdmin client?

Also, if you do, make sure it has iPad support, please and thank you! :D

P.S. There are some nice iOS icons here -> http://my.bzflag.org/bb/viewtopic.php?f=43&t=16818
Image
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1052
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Re: Apple iOS Port WIP

Post by optic delusion »

Just to add my two cents... if you use SDL, stick with SDL 1.2.14, don't get any higher versions.
I say this only because I can't get BZ to compile on my mac with any higher version, your milage may vary.
Take a look at my Defender game mode concept.

Thinking is not an automatic process. A man can choose to think or to let his mind stagnate, or he can choose actively to turn against his intelligence, to evade his knowledge, to subvert his reason. If he refuses to think, he courts disaster: he cannot with impunity reject his means of perceiving reality.
JeremyAgost
Private
Private
Posts: 4
Joined: Thu Jan 06, 2011 5:51 am

Re: Apple iOS Port WIP

Post by JeremyAgost »

BZAdmin doesn't have much to do with the core, near as I can tell. The most work in bringing that to life would probably be in recreating the UI.

In regards to SDL, 1.3 is the only option due to 1.2 not having any iOS support whatsoever. So far I've only encountered a handful of problems in the version difference, which I've corrected. For the most part, 1.3 is backwards compatible with 1.2.
User avatar
blast
General
General
Posts: 4931
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: Apple iOS Port WIP

Post by blast »

Honestly, for BZAdmin, it's probably easier just to rewrite it completely. BZAdmin isn't that great of a program, and it doesn't need to handle much of the protocol (nor really any of the game logic). So I could see someone doing that as a separate project, maybe even one that supports multiple major versions of the game with a single app.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image
Anxuiz
Private First Class
Private First Class
Posts: 31
Joined: Fri Sep 05, 2008 3:38 am

Re: Apple iOS Port WIP

Post by Anxuiz »

A while back I spent some time reimplementing the BZFlag 2.0.x protocol in Python and C#. The Python version was functional enough for BZAdmin-style interface as I remember while the C# version had better code, but wasn't complete. You can check out the C# version at http://code.google.com/p/bzlib/ . The Python version is not hosted, but I can host it somewhere if anyone wants it.
JeremyAgost
Private
Private
Posts: 4
Joined: Thu Jan 06, 2011 5:51 am

Re: Apple iOS Port WIP

Post by JeremyAgost »

I've stopped work for the moment, due to the VLC app being pulled from the App Store. It would seem that with Apple and the EFF behaving as they are, GPLv2 is not compatible with the App Store EULA. While there are still other GPL apps on the App Store, it would seem that the official stance is that they are removed as soon as an issue is brought up. Given this, I don't see any sense in continuing work on this port at the moment as it cannot be published to the App Store. Hopefully, this will change in the near future. If anyone has any suggestions or legal clarification (perhaps I'm understanding this wrong) then I would love to hear it.
Post Reply