Doom3 Source Code Released (GPL licensed)


Doom 3 isn't good idea to port to pandora,most of the units can be overclocked to 1300ghz processor but doom 3 min requirement is 1500ghz processor,it will run slow
People really still fall for the Megahertz myth? <_<

Someone thinks most Pandoras overclock to 1300MHz? (no sorry.. GHz?!)
Of course it does,my unit can be overclocked to 1300mhz processor,even i was surprised it can go that far.


Most units just go between 1000-1030mhz which is good not bad at all.


Why are pandora clock with different speeds when the hardware is the same in all units,some units can clock to 950mhz that's weird.
It has to due with very minut differences in the chips themselves, same goes for x86 computer cpu some overclock better than others its just the luck of the draw
 
Last edited by a moderator:
I would love to see doom3 on the pandora, too.


Oliver McFadden is porting the engine to opengles 2 at the moment: http://omcfadde.blogspot.de/2012/04/doom-3-and-es2.html


He didn't release any source code yet, but he will when he fixed some bugs.


This will propably make the thing a lot easier, but I don't know a lot about porting and so on, so what do you think about this?
 
If they can manage to make better controlls than the current Pandora Quake 3 port, I really can imagine to play this game on the Pandora...of course the performance would be the most critical point.
 
I would love to see doom3 on the pandora, too.


Oliver McFadden is porting the engine to opengles 2 at the moment: http://omcfadde.blog...-3-and-es2.html


He didn't release any source code yet, but he will when he fixed some bugs.


This will propably make the thing a lot easier, but I don't know a lot about porting and so on, so what do you think about this?

I quickly wrote an N900 branch but the performance has been quite poor. I have not analyzed the possible problems, but I have my suspicions.


I am interested in OpenPandora as a platform, but not quite enough to spend ~400 EUR for the hardware. It'd be a lovely incentive to receive a device in the mail but I have serious doubts about that ever happening.


Really I like the idea of having an open platform without too many restrictions. It took me only a few hours to have a preliminary version running on the N900, because I can easily run native code on that hardware. About half of that time was installing the SDK. If I look at something like an Android tablet, running native code becomes an order of magnitude more difficult and frustrating, and neither the N900 nor Android tablets are ideal in terms of input controls.
 
I quickly wrote an N900 branch but the performance has been quite poor. I have not analyzed the possible problems, but I have my suspicions.
How is your confidence in improving it? I'm certain that a working and maintained Doom 3 port could be incentive enough to help fund your Pandora. I will personally put up $100 to see this happen.
 
I am interested in OpenPandora as a platform, but not quite enough to spend ~400 EUR for the hardware. It'd be a lovely incentive to receive a device in the mail but I have serious doubts about that ever happening.

Weclome Oliver, I was the one who posted the comment about the pandora on your blog. im looking forward to trying out what you have done.
 
one more step for a portable darkmod... ok i know, i'm dreaming...
 
Hi, I'll get a second Pandora soon (from Rebirth compo) and can offer it to you, if you want for 250€. It is a 256 MB RAM model, that currently gets the new LCD cable etc. from ED.


If you are interested, please PM me :)


Edit: I want to see doom3 run, too of course :p
 
Last edited by a moderator:
I quickly wrote an N900 branch but the performance has been quite poor. I have not analyzed the possible problems, but I have my suspicions.
How is your confidence in improving it? I'm certain that a working and maintained Doom 3 port could be incentive enough to help fund your Pandora. I will personally put up $100 to see this happen.

I'm fairly confident performance can be improved quite a lot; the Doom 3 code base is designed and optimized for x86, but the SIMD code is very modular, so it'd be fairly easy to add a new SIMD_Neon.cpp (for ARM NEON.) The real work then becomes writing new versions the "hot" functions in NEON assembly. I have not profiled anything yet, but I know from my previous work on Quake 3 for N900 that idMath::RSqrt() will be incredibly slow on ARM. Chris Lomont wrote a good paper (and test harness) on this method of calculating the reciprocal square root.


If I were to take on maintainership of an OpenPandora version of Doom 3 it would be a strictly free-time/weekend project because I do have a full-time job.


I am also in the midst of battle with a nasty cold, so don't expect too much in the coming days.
 
If I were to take on maintainership of an OpenPandora version of Doom 3 it would be a strictly free-time/weekend project because I do have a full-time job.
All the porters around here all do ;)


It's not as if it would be a good payng job to port theses games ;)
 
If I were to take on maintainership of an OpenPandora version of Doom 3 it would be a strictly free-time/weekend project because I do have a full-time job.
That's all anyone can expect. Everyone has things going on in their life, your free time is totally respected. :)
 
I can help with NEON code conversion if someone wants, but I think first the GPU burden needs to be assessed. Hard to be motivated to lower the CPU load if the game is heavily GPU bound at whatever is considered a minimum reasonable image quality.
 
I can help with NEON code conversion if someone wants, but I think first the GPU burden needs to be assessed. Hard to be motivated to lower the CPU load if the game is heavily GPU bound at whatever is considered a minimum reasonable image quality.

Indeed you're absolutely correct. I performed some preliminary profiling with oprofile on testmaps/test_box with an optimized release build and the CPU was sitting around 80% idle. Obviously the CPU will be doing more work when rendering complex single player game maps with dynamic surfaces where a significant amount of data must be recalculated every frame. However the point is that no matter how you look at it per-pixel lighting is computationally very expensive. Doom 3's renderer is designed to take the scene input, cull as much as possible, then hand-off the work to the GPU. This is where the bottleneck is going to be located; how fast can the GPU can render the interactions.


Currently I have some GL errors and they may be hurting performance. I've managed about 3 fps on average in test_box, which is substantially better than the <1 to 1 fps previously, but still not going to be playable. RGB565 and texture compression may buy a few more fps but unfortunately I am not sure that 30 fps is an attainable goal. On the other hand it's entirely possible that I am doing something silly and forcing the GPU onto a slow path, or the compositor is not being disabled (despite fullscreen and appropriate window hints being set.)
 
Back
Top