Doom3 Source Code Released (GPL licensed)


Yeah it sure creates a lot of atmosphere, but sadly dynamic shadows are not exactly easy on the CPU/GPU... though we still could have static shadows of immovable objects, which are baked right into the level file and then depending on performance can see where to go from there.


But that is assuming we get a working port and we are far from that ;)
Someone should give Carmack a Pandora and see what happens... ^^


Funny:


http://twitter.com/#...189212519792640


:D
You cant blame him when he's right, right?
 
If reimplementations were safe, we'd have no problems; the whole patent issue in software is that _algorithyms_ (approaches) are patented, so you can implement 10 different codebases, but as long as the approach is similar, they're in violation. That is the danger -- that if there is only one good way to do something, and some idiot patents it, the whole industry suffers.
That was my thought, too, from what I read on Phoronix. It's always odd as 'mathematical algorithms cannot be patented' and then we see it patented here.

Both funny and sad. One would think four lines of code couldn't be patented. On the other hand MS is suing Barnes and Noble for putting a progress bar in a web browser. Such innovation.
 
Think of open implementations of MP3 and similar codecs... in some countries it's iffy due to weird patent laws, but generally it's accepted as ok...
They do not refer to the differences in pantent law at all, they use a completely different loophole to shift the responsibility to those who use it. Check out the LAME Wikipedia article:

Distributing compiled binaries of LAME, its libraries, or programs that derive from LAME in countries that recognize those patents may be patent infringing. The LAME developers state that, since their code is only released in source code form, it should only be considered as an educational description of an MP3 encoder, and thus does not infringe any patent by itself when released as source code only. At the same time, they advise users to obtain a patent license for any relevant technologies that LAME may implement before including a compiled version of the encoder in a product.
 
PokeParadox, I hate to say it but you're incorrect regarding the patent system and so on (especially in the US.) Just want to clarify, so you don't get into hot water someday. (And I may be misinterpreting what you wrote, you might well mean the same thing, or maybe I am wrong, so feel free to correct me :)


If reimplementations were safe, we'd have no problems; the whole patent issue in software is that _algorithyms_ (approaches) are patented, so you can implement 10 different codebases, but as long as the approach is similar, they're in violation. That is the danger -- that if there is only one good way to do something, and some idiot patents it, the whole industry suffers.


The issue here is there is a patented alg, and Carmack independantly solved the problem before patent was released; he has a specific arrangement with the patent holders, so he can use the alg indefinately and gives free advertising to Creative or whoever. But he cannot then go releasing this to the public, since that is not the agreement he has. (See the BS? He has independantly coded something, at the same time as others, but they own the patent, so he is their slave.)

Well I never said I was a lawyer... but basically we are barking up the same tree. My point is that Carmack's hands are tied, by that agreement with Creative, so that he can do nothing except change the code, or get into a legal dispute.


Open source devs can find a loophole... somehow.


And I can't see getting myself into hot water, any time soon... I barely have time to code recently :/
 
I'll add $200US to the bounty... for a reasonably working port.
 
Your lack of specificity will be the port's downfall, especially since you're offering that much. If you're gonna offer $200, be sure to let potential recipients know EXACTLY what you want.
 
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 maybe video ram it's ok in pandora to run. <_<


If you look at quake 3,it port well but still had graphics problems,just look at some walls there go invisible when you get close to the them. :D
 
Last edited by a moderator:
Feel free to link this for future bounties, and I encourage anyone to reference this when porting applications with or without a bounty.


I will hereby establish reasonable port parameters for what could be considered a "high-quality" port.


Take special note of careful wording like "should", "must", "encouraged", "major", etc. Some of these points are mixed between guidelines and absolute rules, like "rendering must be true" does not mean "justification can't be used to decrease quality". Consider all of the points and how they work together, and use personal judgment. If your port feels great to yourself, beta testers, and the bounty posters, you don't need to let anything on this list (except maybe the licensing one ;) ) slow you down.

  1. A port must run consistently on the Pandora, and a user should be able to play through all game modes just as well as the unported game without observing crashes or gameplay-breaking bugs added during the porting process.
  2. Porters are encouraged to improve the game experience from the original when necessary. This includes fixing critical bugs, adjusting camera view/FOV to be more appropriate for a handheld, removing unneeded settings (for example, resolution switching and fullscreen toggle can be removed if they cause any problems), and editing menus and ingame UI to better suit a handheld.
  3. Visuals must be true to the original. Justification needs to be made for any rendering techniques removed, and compensation or new techniques must be adapted to restore balance when removing or breaking anything greatly affecting atmosphere. Major rendering bugs or gameplay-breaking rendering bugs will invalidate a port so long as they exist.
  4. Aforementioned port should run smoothly. At a minimum, a consistent 15-30fps and a *feeling* of smoothness should be present. Framerate spikes in either direction can affect this, so applying framerate limiting to average the experience could be worth a try.
  5. Controls should be adapted to the Pandora, and an official control scheme for each port should be established and near-perfected by the porter. Make as much use of the Pandora-specific controls (nubs, dpad, buttons, start+select, triggers, and touchscreen). This includes adapting methods like bicubic smoothing and snapping to a circle (I can provide algorithms and/or C/psuedo-code for either of these to anyone interested) on the joystick nub data if they're a primary method of input and feel rough whatsoever. As a porter, play the game and make sure your controls feel natural, then release for beta testing and ask the general community if they think the controls warrant customizability or improvement.
  6. Packaging must be acceptable. This includes documentation on how to apply required data files, a quick overview of all controls required for the game, the required overclock to achieve quality gameplay, and an appropriate screenshot+icon. The package should also have clear file structure. "appdata/" on the SD should be used for all game content, savegames, preferences, and anything else persisting between game sessions (if for the only reason of being able to remove the card, reformat the NAND/boot drive, replace the card, and resume with zero problems).
  7. Licensing should be well-defined. All source licenses should be specified in the PND and linked for any separate groups of software included. Links to modified source should be provided as well if the license requires. I recommend tracking your code in a local git repository and uploading to github upon release if you need an easy place to host it. Absolutely no content should be included unless licensing allows for it.


Finally, any bounties and exceptions to any of the points above are at the discretion of a bounty's poster. Maybe they don't need to play UltraDeathMatch IPX NULL MODEM multiplayer SUPER mode, so that's okay to communicate and potentially leave out of a port. In all cases, try to make them as happy as possible. If you make a half-hearted port that "barely compiles", don't expect to rake in the love.
 
Last edited by a moderator:
As a side note, I've examined the source and *may* be considering a port. It's definitely possible to scale Doom 3 down to run on the Pandora without destroying the rendering pipeline so much it looks like Doom 1.
 
I actually think 1-4 are a little bit harsh. Some things will never be 100% true to the game and a port may be possible that is just beyond the pandora's capabilities without some neutering. For example, it may only be possible to play it without sound or without shadow effects or something and really, at what point do you draw the line when it is still technically a big achievement and the porter has done as much as they can. Really, I think the main thing is to not take the piss rather than expect near perfection.
 
  1. Visuals must be true to the original. Justification needs to be made for any rendering techniques removed, and compensation or new techniques must be adapted to restore balance when removing or breaking anything greatly affecting atmosphere. Major rendering bugs or gameplay-breaking rendering bugs will invalidate a port so long as they exist.
  2. Aforementioned port should run smoothly. At a minimum, a consistent 15-30fps and a *feeling* of smoothness should be present. Framerate spikes in either direction can affect this, so applying framerate limiting to average the experience could be worth a try.
If you keep these 2 conditions, you wont have your port no matter own many money you put in the pot, here is the reason :


Doom3 minimum hardware requierement are _far_ over what the pandora can do :


* the game requiere a CPU power you cannot reach even with maximum overclocking


* the game requiere a GPU far more powerfull than the SGX


* the game requiere far more main memory than the pandora have (about 400M for the games, 250M of textures, so it's a "more than 600M" needed, the pandora does only have 256M, and the OS have to fit too)


So if a port is ever done, the porter will need to disable the shadow mapping, reduce the poly count of every models, reduce texture quality which goes against your #3.


Your #4 make it mandatory to a) rewrite half the engine to use fixedpoint math or write neon-asm to speed-up the floating point math behind the engine.
 
Those conditions are not realistic.


In the specific case of Doom 3, I expect a significant impact on the visuals of the game when ported, especially with regard to the lighting, shadows and texture quality (condition 3).


The first condition is not even guaranteed for games on their original platform and there is little a porter can do to improve that.
 
If you keep these 2 conditions, you wont have your port no matter own many money you put in the pot, here is the reason :


Doom3 minimum hardware requierement are _far_ over what the pandora can do :


* the game requiere a CPU power you cannot reach even with maximum overclocking


* the game requiere a GPU far more powerfull than the SGX


* the game requiere far more main memory than the pandora have (about 400M for the games, 250M of textures, so it's a "more than 600M" needed, the pandora does only have 256M, and the OS have to fit too)


So if a port is ever done, the porter will need to disable the shadow mapping, reduce the poly count of every models, reduce texture quality which goes against your #3.


Your #4 make it mandatory to a) rewrite half the engine to use fixedpoint math or write neon-asm to speed-up the floating point math behind the engine.
Those conditions are not realistic.


In the specific case of Doom 3, I expect a significant impact on the visuals of the game when ported, especially with regard to the lighting, shadows and texture quality (condition 3).


The first condition is not even guaranteed for games on their original platform and there is little a porter can do to improve that.
I said *justification should be given* and not to break the game+feeling. Downscaling polygons + textures is a very good way to reduce requirements while maintaining quality on a smaller screen and should not be discounted.

These points should all be considered together, and they were NOT specific to a Doom 3 port. A Doom 3 port *is* possible, will definitely not be easy, and shortcuts+optimizations will need to be added. They can be added without breaking the game, and without ruining the experience. How long this takes, and how much effort, remains to be seen.


My original post was edited with a few clarifications, but I still strongly stand by all of my points. Nothing I can say will make a port any more or less possible, and my word absolutely isn't law. My list may help clarify what exactly makes a good port, and help a porter understand what to aim toward when starting/finishing a project or filling a bounty. I'd say getting 75% of the list right could still make for a pretty decent release, but filling all the points could make for a near-perfect release.


That said, I appreciate the feedback.
 
Last edited by a moderator:
I said *justification should be given* and not to break the game+feeling. downscaling polygons + textures is a very good way to reduce requirements while maintaining quality on a smaller screen and should not be discounted.

these points should all be considered together, and they were NOT specific to a doom port.
you seems to realy underestimate the reduction in polycount and texture quality requiered. We are talking of (at least) dividing by 5 the number of poly and dividing by 4 each axis for texture size.


That _will_ have a visual impact even if the screen is smaller


Also dropping shadows will have a significant impact on the visual, some might even say that it wont be the same game anymore. Yet it would be requiered if you ever want to have it playable.
 
I said *justification should be given* and not to break the game+feeling. Downscaling polygons + textures is a very good way to reduce requirements while maintaining quality on a smaller screen and should not be discounted.
If you remove shadows and lighting effects, which will probably be necessary, then the game will look more like http://www.youtube.com/watch?v=nUVXAl0dgYY. I would call that a different game, but this is what you should expect. Anything better than that is bonus, just don't have unrealistic hopes.
 
I have reports of Doom 3 running at 10+ fps on max settings + higher resolution (than the Pandora) on an Intel GMA 945, which (on paper) can only push about 3x the pixels of the SGX 530 afaict. It remains to be seen what exactly will need to happen for reasonable performance on the Pandora.
 
Last edited by a moderator:
The thing is quake 3 graphics aren't good as doom 3 graphics,the thing is graphics weren't perfect and the support opengl drivers are limited for on pandora console,i just want to know why wasn't the q3 port perfect,play this game and look at it the graphics go invisible and how you suppose to make doom3 which has much powerful graphics seems like a joke.


Forget about iphone port of doom game doesn't look nothing like pc version,look really basic graphics,pandora does have good hardware,which the games do look good as pc graphics,especially albion look perfect and warcraft on pandora look like you playing on a desktop computer,it is that good.


I wonder if you can play albion and warcraft using a mouse that will be pc experience.
 
Back
Top