(Updated again 2012-05-07: Doom 3 is nothing without stencil shadow volumes!)
(Updated 2012-05-07: I discovered and fixed a little bug in the modelViewProjection matrix...)
Saturday, April 28, 2012
Doom 3 and ES2
I spent some time hacking on Doom 3 adding support for EGL and OpenGL ES2.0; obviously there is still a significant amount of work to be completed before this looks even remotely like the game. Some of you might make out the text console in this image, rendered with the incorrect shader. :-) Phoronix, go nuts... :-)
(Updated again 2012-05-07: Doom 3 is nothing without stencil shadow volumes!)
(Updated 2012-05-07: I discovered and fixed a little bug in the modelViewProjection matrix...)
(Updated again 2012-05-07: Doom 3 is nothing without stencil shadow volumes!)
(Updated 2012-05-07: I discovered and fixed a little bug in the modelViewProjection matrix...)
Subscribe to:
Post Comments (Atom)
I want to be able to run this game on an ARM and/or MIPS based computer with normal controls like the keyboard and mouse. How fast does the CPU and the GPU have to be to run the game? Although I did play Doom 3 on an Intel Celeron 440 with the Nvidia Geforce Go 6150 IGP and it was playable.
ReplyDeleteI cannot give you any definitive figures, because I do not know. Obviously the more horsepower (CPU and GPU) you can throw at it the better. The renderer is designed in such a way that it's basically preparing everything for the GPU and saying "Go!"
ReplyDeleteThere are some exceptions, such as the skeletal animation pipeline which performs skeleton construction and transformation on the CPU, and because it's a dynamic surface the normal, tangent, and bitangent attributes must be recalculated every time the mesh animates (typically every frame.) It's not strictly speaking part of the renderer, but they are tied very closely together.
Then there is the issue of actually compiling Doom 3 for ARM or MIPS... Sorry I can't give you a better answer than "try it and see."
Sorry to ask so late but where do I find the source code to compile for Opengl-es on ARM Linux? I will try it and see I can't wait.
DeleteSir really love and appreciate the work you do ............
ReplyDeletethe consequences are immense .........up until now there wasnt anything for linux that would allow games or anything graphics related that would allow it to shine.
With the release of the source code and your work, linux and maybe freebsd, android etc might never be the same..... its like there was no video player for linux and then came vlc/kaffeine/mplayer/xine etc.
Games like rage, mw3, bf3,TF, skyrim etc might just get easier to install and play stably...........sooner than far reaching the 10th year mark.
My game playing days are long gone and just reminisce playing doom95, pitfall,freedoom, doom3, quake4 etc over half a decade ago and just build gaming systems.
Wish you the best of luck...
Oliver, is this code available? I would love to try this on the pandora (arm,sgx) and help with getting it run best it can on gles 2.0.
ReplyDeleteNo, the code is not available online yet. I still have several bugs to fix and shaders to implement before I would consider the code release worthy. When it's done. :-)
DeleteI'm eager to help get this working well on a Pandaboard. As soon you feel happy to release the code I'll be digging in trying to help out bughunting etc.
ReplyDeleteCheers,
Dingo_aus
I wonder whether the OpenPandora developers would supply me with a device...
ReplyDeleteI am quite interested in this hardware, even to the point of making it the primary development platform for Doom 3 ES 2.0, but I am unwilling to spend 440€ for what is essentially a weekend project.
Contact EvilDragon (Michael Mrozek, his email address is: EvilDragon@openpandora.org) about the Pandora, probably you could come to an agreement.
DeleteOliver could you please release renderer code, because I just wanna start porting code for ARM and if I will start porting renderer to OPENGLES (which you already doing) it will be waste of time for me. I'd like to focus on other things in source code
ReplyDeleteOnce I get a chance to finalize the code, yes, it will be released. The problem when releasing code that doesn't implement everything is that everyone complains and expects those things to be fixed immediately.
DeleteUnfortunately between work, and more work, I have little free time at the moment. I hope to get a repo online "soon" but that could be anything from a few weeks to a few months from now.
Btw, "porting" to ARM amounts to about a few dozen lines-of-code (including the build scripts.) I know, since I did it already for the N900.
Juhannus (public holiday) is coming soon. Perhaps I'll have some time and motivation to tidy up the code and write the rest of the GLSL.
There are currently 138 TODO's in the renderer (however not all of those are unique tasks.)
I am trying to port it for android (I am writing android's native makefiles and no sdl framework at all), I know that quake3 engine is almost same like this engine, but I have fear that this engine will be pretty hungry against quake3, but on high end devices it should work. I don't expect that everything will be fixed in renderer (I can help). I have very small amount of time too.
DeleteYou wouldn't have to worry about SDL. I think it's not a good solution and I will not add SDL support.
Delete