Page 2 of 2

Posted: Thu May 24, 2007 4:55 pm
by bitplane
wow, nice work :)
so this new device can be used as a base for devices on systems that don't have any real graphics hardware?
btw, I'm jelous of your DBOX!

Posted: Thu May 24, 2007 8:23 pm
by hybrid
Yeah, the new device uses the framebuffer device. That's basically a structured memory section which holds the graphics memory. You can sometimes set the dimensions or color format, but not much more. So I'm just converting and copying the IImage from the software renderer to this area which is presented on the screen.
Right now I can only display the graphics with different formats and sizes. No input device available yet, and also no extra features. so still much to do. Also the size of the apps is a problem. I only have 8MB free RAM, mos examples do not run due to space consumption.
The DBOX is a neat system. The Neutrino GUI offers nice features, DVB recording is quite cool. I am currently reconfiguring my home network to use a NAS to act as my movie server. Pretty cool is also that my VoIP router sends incoming calls to the LAN, the DBOX makes a reverse lookup on the internet and displays the name of the phoner on my TV :D

If anyone want to test the new device please contact me via PM. I'll send a patch per mail. Otherwise just wait until I have keyboard support working, then I'll commit to SVN.

Posted: Thu May 31, 2007 4:35 am
by BlindSide
Lmao I thought you were the white guy in the tv program and that was your reflection for a second there...

Good work :D Any idea what FPS you are getting? Sorry if I missed it.

Posted: Thu May 31, 2007 7:18 am
by hybrid
The software renderers are doing about 1FPS, both are almost equally fast (using 16bit, the 32bit did not work). Two places for improvements are in my mind: Memory transfer and FloatingPoint calculations. Right now I have to copy the rendered image into the framebuffer, it would be better to render directly into the framebuffer (IMHO even without double buffering). However, the software renderers don't allow that, yet. And since the CPU does not have FPU support the floating point calculations are emulated right now. This can be improved by replacing f32 by a fixed point class. I hope this works as expected...

Posted: Fri Jun 01, 2007 8:50 am
by BlindSide
I made some java games for mobile phones and they did not have floating point support so to get smooth movement between pixels I would just do everything at a greater number (1000 instead of 100) and then divide by a set number when comes drawing time (e.g. DrawCircle(my.X / 10, my.Y / 10)).

I am guessing this will be pretty damn hard to implement in irrlicht as a whole, maybe to make the process easier you can start stripping down some of the unneccesary parts of Irrlicht that shouldn't be needed in a embedded-ish enviroment anyway? I mean if you get this to a stable version you will probably need to strip it more to save memory, or have you already since you mentioned you were having trouble with memory space earlier?

Posted: Fri Jun 01, 2007 9:41 am
by hybrid
Yes, I'm currently trying to reduce the memory consumption. The statically linked binary is between 5 and 8 MB in size, that's most of the free mem... But it's also due to some problems with the current machine's setup as I have to link libc statically etc. And I did not yet strip any loaders or stuff, so it's still some non-required things in there. Nevertheless I still need more tweaking on Irrlicht's size before we really get a version suitable for tiny devices.
For the fixed point calculations (or even integer, that's basically implementation stuff, though you have to care for rounding error propagations) I'm not sure how it will work. Hope to have some results in the next weeks, though.

Posted: Wed Aug 01, 2007 6:26 am
by conorkirk
Sorry to bring back an old thread, but...

Descent uses a 3D software renderer as stated.

Though, it could be a hoax, someone has posted a screenshot on the iPodlinux Forums (pictures section) of Descent II.

Until we get some more proof, we are not sure what to believe, but we have seen some true 3D on the Nano before: http://pouet.net/prod.php?which=25857

Again, until we get some more proof, we won't believe it, but this could be seeing what is possible on the iPod platform.


One thing I have noticed with Linux on the iPod is that things seem to run slower with it (iPod is running a Linux kernel, what'dya expect?). There is another project called rockbox, http://rockbox.org

I noticed things are faster with RockBox (Mainly a common 3D cube demo runs at a higher FPS than in iPodlinux) which means if I or someone manages an iPod port, RockBox might be a good choice.

Of course, we aren't limited to oh, I don't know, maybe a very stripped kernel of some sort that could speed things up?


~Conor