The Blender source for the iPac hasn’t been released/ freed and probably will never be. It was a tech demo AFAIK. An iPac port would also need a lot of work because the opengl calls have to be converted for the iPac framebuffer device - means: writing a opengl driver for the iPac. Also would the performance be pretty bad because all of the rendering has to be done by the software. This might change when PDAs will be equiped with 3D chips.
Yep, you’re right it’s there. I was pretty sure that wasn’t released at all.
Well, anyway.
It’s still no official Blender release, it’s a proof of concept, a demo to show how tiny and portable Blender is. It wasn’t supposed for productive use. I’m not sure if it will run on recent models of the iPaq. You might have to do some to make it work - but it might also not work at all.
The screen resolution of the iPaq is 240x320 with 16 bit color IIRC - maybe that has changed now with the new models. But it would be acceptable.
The CPU is very limited. And all drawing has to be done with software.
It’s only version 2.04 - so it uses Enji as game engine. It lacks of some features of the current game engine such as python support - but the rendering it faster than Ketsji’s rendering due to the sort of culling with sectors (- but unfortunately the Blender game engines are slow compared to others). So you should use an older Blender version to create an appropriate .blend and you’ve got to make it the Enji way (setting up sectors which contain the objects).
You can’t lock, sign or export runtimes with it. Games are only able to run within Blender - means people will have to install iPaq Blender first to run your game.
You can use textures (I know you said that you don’t want to), but for the iPaq I would keep 'em as small as possible. Keep in mind that you don’t only have a compressed image in memory but also an uncompressed representant for rendering the output. Might not matter on the desktop too much (today PCs usually are well equiped with RAM - or at least should be sighs - or they have the uncompressed image in the texture memory) but it does matter on a handheld computer.
The iPaq version is not being maintained. So everything you’re going to do optimized for the iPaq, will not have a secure future - not to say ‘none’ (Perhaps some one starts a framebuffer Blender in the future. But it would better to wait two or three years - there are already 3D chips that can be built into handhelds, now it’s time for the manufacturers).
For me that are already too much reasons not to waste any time in it. But maybe not for you!
Hehe! Yep, but it’s not impossible! The iPaq Blender proves that actually it is possible. I’m pretty sure that in the next years things will improve a lot on that field - means 3D geometry chips built in handhelds and real 3D applications running on them. Blender has proved that its portable architecture and small size probably already has an advantage. So the game engine could (if improved, especially the performance) be a real killer-“application” on handhelds and no one would really care about a game boy advanced or something like that anymore.
The iPaq Blender proves that actually it is possible. I’m pretty sure that in the next years things will improve a lot on that field - means 3D geometry chips built in handhelds and real 3D applications running on them. Blender has proved that its portable architecture and small size probably already has an advantage. So the game engine could (if improved, especially the performance) be a real killer-“application” on handhelds and no one would really care about a game boy advanced or something like that anymore. 