iPod

[conorkirk]

Is this the right thread, as the following is probably challenging


Using Irrlicht's Software renderer as the renderer and port it to the iPod.

It would be cool for small things like some of the demos, nothing like a game.

iPod:

80MHZ (2) ARMt7DMI cores

32MB of ram

http://ipodlinux.org/generations

there you can find all the specs on every iPod.

[hybrid]

No, challenges has a different idea. But feel free to continue with this thread here
I had some very limited success with running Irrlicht on low-end machines (under 400 MHz, no hardware acceleration). But I'll continue with my framebuffer device sometime which might help to port to those machines. If you have an IPod with a decent display, and if you have some Linux knowledge I can send you the framebuffer patch and you might try on your own.

[conorkirk]

I'm not so much of a n00b when using linux, but then again, i don't know everything


I couldn't do it right now anyway, because I don't have a cross compiler set up right now ;(

[conorkirk]

I will get a cross compiler set up and try to compile it.


are there any flags to pass so you can make it compile with nothing but the software renderer?


such as:

Code: Select all

NOOPENGL=1
NODIRECTX=1
NOSOFTWARE=0

[hybrid]

Yes, because you will compiler for Linux (so it won't do D3Dx) and you can disable OpenGL in IrrCompileConfig.h. However, this still builds with X11 support. You can also disable that one and try the null driver first. That way you can check if the basic things work. Then I'll send you the fb driver (hopefully having its own device file instead of being piggy-backed with Linux device).
Choosing only one of the software drivers is not possible, yet, but should be soon.

[pinballwizard]

AFAIK (I've done some iPodLinux programming) the iPods have no floating-point computations, so you'll need to re-write every single line of code that does any floating point math, and make it use fixed-point math. Clever use of C++ operators can help reduce some of the tedious work in transforming floating-point to fixed-point, but you'll still be faced with the dreaded overflow errors which will require re-ordering of the computation or re-writing the algorithm to avoid overflow, which may be non-trivial.

I'd recommend very heavy use of assert()'s (as often as every line in some sections) to constantly sanity-check your fixed-point values to make sure they don't over/underflow.

I have my doubts about how well you can port an engine as complex as Irrlicht to fixed-point (based on my experience porting my own engine), but I'd love to be proved wrong. There is a port of Doom to the iPod, but of course Doom is 2.5D, not true 3D, which makes the math easier.

[conorkirk]

The iPod's can do floating point math, but it is slow as it is emulated...

[pinballwizard]

The iPod's can do floating point math, but it is slow as it is emulated...

You're right: I should have been clearer in my original post. Any platform can do floating point computations, even my old Atari 8-bit from 1983. The relevant question is if there is hardware support for floating-point computations.

Emulated floating point performance is very likely waaaaaay too slow for real-time applications. If you've ever done 3D programming for the 286 or 386, or 486SX, you'll probably recall that everyone was doing fixed-point math (search the web for some 3D tutorials from that era).

I haven't actually tested floating point performance on the iPod, but I strongly suspect that you will indeed be forced to switch all math to fixed-point to achieve reasonable performance. Remember you're translating hundreds or thousands of vertices, each with 3 elements, by matrices, each with up to 9 elements, at frame rates at least 10fps. For a small scene, assume 1000 vertices each being transformed only once (world space->screen space), at 10 fps. This is more than 90000 math operations per second - can you do 90000 software-emulated floating-point operations per second on the iPod?

Furthermore, you'll generally need to transform objects more than once (object space->world space, world space->screen space). Also you need translation operations (a 3x3 9-element matrix only contains rotation information), which will add more math operations for each vertex.

This is just for 3D geometry transformation. How about Irrlicht's software renderer? Does it use fixed point or floating point? For the iPod, the software renderer absolutely must use fixed point, as there is absolutely no possible way that a software rasterizer using software-emulated floating point can achieve interactive frame rates on a platform like the iPod. Quick proof: Assuming latest iPod 5G with 320x240, that's 76800 pixels. Assuming you have an indoor scene, then all pixels on-screen must be rendered. Rendering a texture-mapped pixel requires one divide operation to achive perspective-correct mapping. Also you need miscellaneous other increment/interpolation operations per pixel. (You can avoid some of these divides if you do scanline subdivision or ignore perspective correction, which looks terrible.) But at least you're talking 76800 divides per frame. At 10 fps, that's 768000 divides per second. Add that to the 90000 mathematical operations you need per second for the 3D geometry transforms, and you're up to 858000 math operations per second.

So... I suggest brushing up on your fixed point math Check out the Doom sources - though it's only 2.5D, they use a software renderer. The Doom techniques are almost useless for full 3D engines like Irrlicht, though. That reminds me, the game Descent has been open-sourced, and it contained a full 3D engine with software rendering (and fixed-point math). That might be a good way to see how a real game used fixed-point in practice. See this thread for more information http://www.emuboards.com/invision/index ... =25756/mhz

[conorkirk]

You lost me pretty quickly there

[pinballwizard]

Well, feel free to ask if anything I said needs clearing up - I'm certainly very interested in getting Irrlicht (or any good 3D engine) working on small, embedded devices. It's just that to my knowledge, this is not easy. The main reason is that Irrlicht was not designed with this in mind (being able to run without floating-point). Older engines (like Descent, Doom) were designed on lower-powered hardware, so they are easier to port to embedded devices, but aren't as general-purpose as Irrlicht.

Here's a kind of old tutorial (1992) about fixed-point

Original page (down right now):
http://www.gamedev.net/reference/articl ... cle380.asp

Google cache:
http://72.14.235.104/search?q=cache:98L ... nt=firefox

@hybrid: You said you got Irrlicht working on some embedded devices? Could you share some more details? With or without hardware FPU? Did you have to convert 3D transformations to fixed-point?

Blender was once ported to work in iPaq, but the developer had to write his own fixed-point subset of OpenGL (which is not available as open source, AFAIK). There is a TinyGL by Fabrice Bellard, but it uses floating point

[hybrid]

I tried it on an embedded PPC core and wanted to try with my DBOX (an even smaller PPC core). I think that both do not have hardware FPU support, but the former is on an FPGA board which could be used for hardware acceleration. However, I faced some problems much earlier due to lack of framebuffer support which is why I started there first. Later on I got some picture on the FPGA board, but not even near to real-time.

[pinballwizard]

fo

You lost me pretty quickly there

I just wanted to add one more comment in addition to the details in my other posts.

The comment is - in a software renderer, you have to recompute every 3D vertex and every pixel on-screen, for every frame you draw on-screen. Remembering that you have more than 10 frames drawn per second for interactive apps, you start to get an idea of the massive amount of computation that has to be done every second for 3D rendering.

Nowadays, with hardware-accelerated texturing, transforms, and lighting, and full-fledged computational support on the GPU, it's easy to forget just how much work the hardware is doing.

That's why I like this idea of Irrlicht on iPod or other small devices - it really tests how well Irrlicht can be optimized. I hope this idea goes somewhere, but realistically this will probably take several months or more, since I assume no one here (maybe niko excluded ) can work on Irrlicht full-time.

[hybrid]

I don't think that Niko's employer would be happy about Niko going full-time for Irrlicht At least if he still has to pay him.
I hope to get a student working on this for some month, but no luck yet. That could help due to several month continuous work on a specific topic. Maybe I get someone for fixed point arithmetics...

[devosbi]

Atmel ARM Micro's are my speciality, but chances are they bight barf...
unless you want to create a whole new irrlicht libary for Assembler or Crossworks... but would not be worth the effort...

[hybrid]

Hehe, I have to revive this older thread. But I now have a working framebuffer device available. As I said earlier in this thread I tested it on my DBOX settop box running a small Linux distro. It took me a while before I could get back to this topic, but now I got it running correctly. You can find a first view of the device running with a transparent background and thus showing the TV programme. This is basically example 4 with a different texture and without sydney (the yellow parts above the box are simply reflections of my window on the TV screen).

It might take some time until everything's fixed and I can commit the new device, though.