Irrlicht on iPhone status...

[grafikrobot]

I know I've been MIA for a while... But I've been busy with some contract work doing console development to get back to the iPhone port. To answer some common questions that I've gotten both publicly and privately:

Can you send me the code?

Sorry, but no. The code that I used for doing the original iPhone games is in a terribly hacked state and is useless without also giving away proprietary code. Also be glad that I'm making a port available at all. It took some convincing of some of my business partners to get them to see the benefits of making the port public.

When will the port be available?

Real soon now. I'm using the usual game development holiday break to work on the port with the goal of having a set of patches for hybrid to apply to the "ogles" branch. My goal is to get one of my code bases working by New Years.

Does an iPhone port mean Irrlicht is ObjectiveC now?

No. It means that there's going to be a new iPhone device written mostly in C++. But some parts must be in ObjectiveC as Apple requires it for iPhone development. Hence there is some interface code between ObjC and C++.

Does an iPhone port mean I'll be able to immediately put my PC app on the iPhone

No. In particular the port does not contain any UI input event handling. And hence touch input code needs to be written on the application side. There is also additional code for interfacing between UIKit and Irrlicht that tends to be application specific. But I'll try and make that part as easy to use as possible. And, given time, add a wiki page for how to get started with the iPhone port.

Will there be a pre-built dyamic library for ARM+iPhone Irrlicht?

Not a public one, and not likely a private one either. Although selling a pre-built one with support might be something I do. The reasons for this are the way the Apple distribution contracts work. Only paid iPhone developers can compile native code and they can only distribute code to other paid iPhone developers. This is irrespective of the now lack of NDA for released iPhone OS tools.

Update:

Here's the first set of patches for those that are adventurous and know enough about iPhone development to put the missing pieces together.

https://sourceforge.net/tracker2/?func= ... tid=540678

[hybrid]

Oh what a wonderful new year's coming Looking forward for this new stuff

[anoki]

Great to see the port is coming !
Thanks.

[bitplane]

Hey grafikrobot, I recently got a Mac and an iPhone. I'm learning Objective C/Cocoa and have been toying with some OSX and iPhone apps, but haven't really messed with the ogles branch yet.
My main goal is to help Irrlicht become the weapon of choice for iPhone games development, and I will probably make a few mini-games and demos myself.
So as soon as you have something you want to release I'll be happy to begin using, testing and bugfixing the new device. Varmint will probably be interested too

I also have some input-

The iPhone uses a PowerVR MBX Lite chipset, so we may be able to save some valuable RAM by using PowerVR texture compression. I'm not sure if GL_IMG_texture_compression_pvrtc is supported in the iPhone's drivers though.

On the subject of imgtec, PVR and POD loaders/writers may also be a good idea, as they would open up the mobile graphics workflows (and possibly let interested parties hack around with old DreamCast games )

[grafikrobot]

So as soon as you have something you want to release I'll be happy to begin using, testing and bugfixing the new device. Varmint will probably be interested too

Help is appreciated

I also have some input-

The iPhone uses a PowerVR MBX Lite chipset, so we may be able to save some valuable RAM by using PowerVR texture compression. I'm not sure if GL_IMG_texture_compression_pvrtc is supported in the iPhone's drivers though.

It's supported, and this is certainly something on my list of things I want/need eventually. But I though loading compressed textures in general was a problem for Irrlicht? I also have some other tangentially iPhone related enhancements like: caching scene node transformations and a streaming zip reader. Basically a few things to deal with the slow CPU, IO, and RAM speeds of the iPhone.

On the subject of imgtec, PVR and POD loaders/writers may also be a good idea, as they would open up the mobile graphics workflows (and possibly let interested parties hack around with old DreamCast games )

Having a PVR writer would be awesome, as I hate being tied to the Apple tools.

[bitplane]

It's supported, and this is certainly something on my list of things I want/need eventually. But I though loading compressed textures in general was a problem for Irrlicht?

Yes... Looking at the at this it seems a bit trickier, as--

Having a PVR writer would be awesome, as I hate being tied to the Apple tools.

--this doesn't seem possible, I can't find any free code for PVR compression, all the tools seem to be binary only and they're probably protected by NDAs. It's going to be a pain to even load the compressed textures without modifying the API, and compressing arbitrary textures at load or low memory notification time is out of the question
The decompression code is freely available in PowerVR Tools though, and they have a whitepaper on how their algorithm works... perhaps given time some clever person will write some free compression code.

I also have some other tangentially iPhone related enhancements like: caching scene node transformations and a streaming zip reader. Basically a few things to deal with the slow CPU, IO, and RAM speeds of the iPhone.

Great! These are the kind of tricks that embedded development can really bring to Irrlicht, making it leaner and faster for everyone in the long run

[hybrid]

Here's a full list of supported extensions and stuff:
http://www.glbenchmark.com/phonedetails ... stgroup=gl

I'm currently working on the extension mechanism for ogl-es, but have some problems with the function pointers not being properly used. But the basics should work soon.
Compressed textures are on the Irrlicht roadmap, and I might put them into the ogl-es branch first, and then merge with trunk later on if all works well.
The special formats are also supported by the PowerSDK vom Imagination Tech, take a look there.

[Halan]

so as multi-touch comes to windows 7 and sooner or later also to X. Do you guys thing we will have handling for it in vanilla-irrlicht someday?

greets,
Halan

[bitplane]

The special formats are also supported by the PowerSDK vom Imagination Tech, take a look there.

The SDK only provides binaries for creating compressed textures, no source. To make matters worse Apple use their own texture format which doesn't work with any other mobile platforms.

so as multi-touch comes to windows 7 and sooner or later also to X. Do you guys thing we will have handling for it in vanilla-irrlicht someday?

I see no reason why not. How about a "touch id" or something similar in mouse events that allows users to track multiple cursor positions, a new touch id would be created on mouse-down and removed on mouse-up?

I think it would be really useful if we supported additional mouse axes and even sent keystrokes depending on the type of multi-touch input.
On the iPhone one finger is move and click, two are the scroll axis, moving together or apart is the zoom axis, placing two fingers apart and turning them is the rotation axis, three fingers means page up/down which could be sent as keystrokes. In OSX the same applies but CTRL+left mouse = right mouse. I'm sure there are lots more too.

[DtD]

I think multitouch adds a world of opportunity, to games and applications. Irrlicht should definitly have some kind of support for it. (But it should be plastered with warnings that it doesn't work with Linux/OSX yet, so we don't have people saying "Why doesn't the multitouch example work on Mac?!")

~DtD

[grafikrobot]

The special formats are also supported by the PowerSDK vom Imagination Tech, take a look there.

The SDK only provides binaries for creating compressed textures, no source. To make matters worse Apple use their own texture format which doesn't work with any other mobile platforms.

It's not entirely Apple, it's Imagination Tech. Although since Apple bought up a whole bunch of their stock I guess it's really Apple But if you get the Windows simulator SDK it includes some specific explanations as to the format of the PVRTC images. Enough to at least decompress the data. And in combination with the original image compression paper, also included in the SDK, it's theoretically possible to come up with your own compressor. Seems like a bunch of painful, tricky, work. But at least just being able to load the raw PVRTC texture data, directly into texture mem, would be welcome.

so as multi-touch comes to windows 7 and sooner or later also to X. Do you guys thing we will have handling for it in vanilla-irrlicht someday?

I see no reason why not. How about a "touch id" or something similar in mouse events that allows users to track multiple cursor positions, a new touch id would be created on mouse-down and removed on mouse-up?

That is certainly doable, and is similar how Apple handles the touch events. But...

I think it would be really useful if we supported additional mouse axes and even sent keystrokes depending on the type of multi-touch input.
On the iPhone one finger is move and click, two are the scroll axis, moving together or apart is the zoom axis, placing two fingers apart and turning them is the rotation axis, three fingers means page up/down which could be sent as keystrokes. In OSX the same applies but CTRL+left mouse = right mouse. I'm sure there are lots more too.

That strays into the application domain. I know it might be nice to provide such events to make things easier for some people. But it turns out it's rather hard, in that it's very context dependent, to handle touch events. Because of the display being the same as the input device one touch event can mean different things depending on what the touch event is over at the time. And a sequence of touch events can mean very different things over time. So it's not always that a pinch gesture equates to zooming. Hence if you want such synthetic events I would strongly suggest you make them optional, i.e. outside of the core engine.

[Sherry Haibara]

This is really a thrilling news! Can't wait to see how far can we arrive with such a small but powerful device. Great job!

Sherry Haibara

[yolanda77]

Apparent rumour in the news is that Apple are launching the next iPhone this summer- the iPhone 5.