Oolite Bulletins

Found this link:
http://www.touchgen.net/e3-classic-spac ... oming-soon

TEXT FROM LINK:

While browsing the booths at E3, we came across Elite Systems booth and discovered a poster announcing the upcoming release of Elite for iPhone.

Back in the day I remember spending hours on this game on my Acorn computer, flying through space, trading goods and engaging in epic space battles. It was also one of the first games to allow you to influence the type of gamer you are… Good or Bad! Allowing you to take out innocent passers by and get a pirate record, or simply be a good space fairing tradesman.

Look for more details soon, but as the developer was out to lunch when we passed by their booth, all we have is this spy shot to tease you with!

UPDATE: We have since heard from the developer that Elite is now not in development for iPhone. This is sad news indeed, as the game would have worked a treat on the iPhone hardware. I believe they are continuing on working on a regular mobile version… Boo!

well since my iphone is running darwin kernel and has 116mb ram with a 412 mhz cpu is there anyway to get Oolite or a tailored/stripped down version of it to work on it?

i guess there are some elite like games but i dont know if they r any good but here are ppl talking about it. and here is another related thread of such an iphone app.

wildstar wrote:

well since my iphone is running darwin kernel and has 116mb ram with a 412 mhz cpu is there anyway to get Oolite or a tailored/stripped down version of it to work on it?

Yes.

1. Learn to program.
2. Learn OpenGL, computational geometry etc.
3. Spend about three months’ full-time work on it.

Tell us when you’re done.

It would indeed be doable, and would only require (as Ahruman says) a few months to sort out.

But there's the rub.

I should point out that I was being quite optimistic. Meeting the memory constraints would probably require some fundamental changes.

Ahruman wrote:

I should point out that I was being quite optimistic. Meeting the memory constraints would probably require some fundamental changes.

if they can get elite to run on a 14k memory computer they can without a doubt get a nice version of it to run on an iphone. its not a problem for someone with a little time. and there already are versions out in their other named forms as the threads from the other forums point out however a stripped down version with no more than a few of the best mission oxp's included in the app of oolite would be best. from what i gather the other apps already produced have amounted to limited missions or no missions and limited worlds and or galaxies however they r referring to them as.

i just was speculating that since oolite is made on a mac natively that the code might be more easily made to work on a iphone since both the iPhone OS and Mac OS are based on the same core, which enables technology-sharing across the platforms,

wildstar wrote:

Ahruman wrote:

I should point out that I was being quite optimistic. Meeting the memory constraints would probably require some fundamental changes.

if they can get elite to run on a 14k memory computer they can without a doubt get a nice version of it to run on an iphone.

Yes, certainly. But the question was about Oolite, not Elite. Oolite looks a lot like Elite, but it works completely differently.

wildstar wrote:

Ahruman wrote:

I should point out that I was being quite optimistic. Meeting the memory constraints would probably require some fundamental changes.

if they can get elite to run on a 14k memory computer they can without a doubt get a nice version of it to run on an iphone. its not a problem for someone with a little time. and there already are versions out in their other named forms as the threads from the other forums point out however a stripped down version with no more than a few of the best mission oxp's included in the app of oolite would be best. from what i gather the other apps already produced have amounted to limited missions or no missions and limited worlds and or galaxies however they r referring to them as.

i just was speculating that since oolite is made on a mac natively that the code might be more easily made to work on a iphone since both the iPhone OS and Mac OS are based on the same core, which enables technology-sharing across the platforms,

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
have no doubt oolite could fit on an iphone it has oer 100megs of ram

wildstar wrote:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
have no doubt oolite could fit on an iphone it has oer 100megs of ram

As one of the non-developers here, let me say...

As my childhood pastor often said, "You have the burden, that means you get the work."

wildstar wrote:

wildstar wrote:

i just was speculating that since oolite is made on a mac natively that the code might be more easily made to work on a iphone since both the iPhone OS and Mac OS are based on the same core, which enables technology-sharing across the platforms,

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
have no doubt oolite could fit on an iphone it has oer 100megs of ram

You realize I’m the lead programmer, right? :-)

The “technology-sharing” thing is a red herring. Oolite is portable to practically any platform that allows natively compiled code, as long as it has the necessary muscle.

Looking into the actual numbers, the current in-development version of Oolite would just about fit into memory on a recently-rebooted iPhone without crashing very often.¹ (The iPhone doesn’t have memory paging, and apps that fill up physical memory crash with no opportunity for recovery.) That isn’t exactly what you’d call “quality assurance”.

The margin could obviously be improved by making all the textures smaller, but the fact remains: Oolite allows an essentially open-ended number of objects in the system, allowing effectively unconstrained memory growth. A game designed for a memory-constrained device should support a fixed number of game entities with strict memory budgets, and Oolite isn’t designed that way. This is what I mean by “fundamental changes”.

Another moderately fundamental change would be that all the scripting and AI state machines would have to be removed and replaced with hard-coded functionality.

Oh yes, almost all the graphics code would need to be rewritten from scratch, as it won’t work with OpenGL|ES.

Those things aren’t very difficult, just a large amount of drudgery. The real fun would be in the interface redesign: almost all the controls would need to be removed.

Edit: oh yes, there’s another thing: the chances of Oolite being preemptively rejected from the App Store as a potential copyright violation are quite high, and I don’t care to speculate how FrontierDev would respond if it wasn’t.

¹A “release” build of trunk (Mac, x86, 32-bit, no OXPs) idles at about 60 MiB of RSIZE and just over 100 MiB of VSIZE just after launch, which is about 10 MiB better than 1.73.4 even though the trunk build has textured planets and the 1.73.4 build does not. However, the memory spikes significantly every few seconds, which would be an immediate crash on an iPhone, so a heavy audit of temporary object management would be needed.

Ahruman wrote:

You realize I’m the lead programmer, right?

actually i didnt but AWESOME WORK~!

Ahruman wrote:

(The iPhone doesn’t have memory paging, and apps that fill up physical memory crash with no opportunity for recovery

so as in u r unable to use hard drive for swap space memory... that what u mean? so we need to wait for a bigger iphone or figure out a way how to make it use more memory? mines 8 gigs of ram in it but only a bit over 100 megs for os/app memory use. the rest is storage. i know i can use the iphone for hard drive space connected to my usb port i am able to transfer files using software. and if jailbroken probably has more capabilities but it would make sense for apple to make it natively capable of using the 8 or 16 and i think 32 gigs in European models capable of using as swap space. the funny part is all that probably would mean draining the iphone battery faster than the full length play of the 2001 space Odyssey song.

Ahruman wrote:

The margin could obviously be improved by making all the textures smaller, but the fact remains: Oolite allows an essentially open-ended number of objects in the system, allowing effectively unconstrained memory growth. A game designed for a memory-constrained device should support a fixed number of game entities with strict memory budgets, and Oolite isn’t designed that way. This is what I mean by “fundamental changes”.

undoubtedly it can be done only it would certainly mean limiting the game in several ways

Ahruman wrote:

Another moderately fundamental change would be that all the scripting and AI state machines would have to be removed and replaced with hard-coded functionality.

i dont know what u mean but ok XD

Ahruman wrote:

Oh yes, almost all the graphics code would need to be rewritten from scratch, as it won’t work with OpenGL|ES.

well of course it is not to say the app wont have to be rewrite in many ways

Ahruman wrote:

Those things aren’t very difficult, just a large amount of drudgery. The real fun would be in the interface redesign: almost all the controls would need to be removed.

yeah that one would be difficult to figure out. guessing u would have to have some touch screen buttons for some controls

Ahruman wrote:

Edit: oh yes, there’s another thing: the chances of Oolite being preemptively rejected from the App Store as a potential copyright violation are quite high, and I don’t care to speculate how FrontierDev would respond if it wasn’t.

that would suck. and thats a VERY good point and reason not to even try it because now u mention it i have no doubt they would have issues. would certainly need licensing permission in advance from whoever holds the copyrights currently. do you get any legal letters for oolite as it is ? is it infringing upon any of these rights? i know when tetris got popular there musta been 100 different YAT's (yet another tetris) games made on all platforms possible.

Ahruman wrote:

¹A “release” build of trunk (Mac, x86, 32-bit, no OXPs) idles at about 60 MiB of RSIZE and just over 100 MiB of VSIZE just after launch, which is about 10 MiB better than 1.73.4 even though the trunk build has textured planets and the 1.73.4 build does not. However, the memory spikes significantly every few seconds, which would be an immediate crash on an iPhone, so a heavy audit of temporary object management would be needed.

hey does that mean we wont need those extra oxp's that add different textures to the planets?

thanks so much to taking time to respond to this idea. it is very enlightening to learn from a programmers point of view what a project like this really means as far as challenges etc.

wildstar wrote:

Ahruman wrote:

Edit: oh yes, there’s another thing: the chances of Oolite being preemptively rejected from the App Store as a potential copyright violation are quite high, and I don’t care to speculate how FrontierDev would respond if it wasn’t.

that would suck. and thats a VERY good point and reason not to even try it because now u mention it i have no doubt they would have issues. would certainly need licensing permission in advance from whoever holds the copyrights currently. do you get any legal letters for oolite as it is ? is it infringing upon any of these rights? i know when tetris got popular there musta been 100 different YAT's (yet another tetris) games made on all platforms possible.

The question of what parts of Oolite might be infringing and to what extent come up every now and then, but the only real answer is that a court would have to decide. Since there’s no practical chance of us defending the issue in court, if Frontier wanted to shut us down they could do so at any time. So far, they’ve studiously ignored our existence.

wildstar wrote:

Ahruman wrote:

¹A “release” build of trunk (Mac, x86, 32-bit, no OXPs) idles at about 60 MiB of RSIZE and just over 100 MiB of VSIZE just after launch, which is about 10 MiB better than 1.73.4 even though the trunk build has textured planets and the 1.73.4 build does not. However, the memory spikes significantly every few seconds, which would be an immediate crash on an iPhone, so a heavy audit of temporary object management would be needed.

hey does that mean we wont need those extra oxp's that add different textures to the planets?

You don’t need them now. :-)

For quite some time, Linux and Windows versions of Oolite have had an experimental mode with dynamically generated textures. (This is disabled in Mac builds because it caused crashes.) An improved version of these dynamic textures will be used in future, and untextured mode will not be supported. OXP planets might still be prettier, though.

There more chance of the Risc PC version getting ported. The iPhone has an ARM processor.