Build Doom3 on MacOSX with XCode4(fabiensanglard.net)
fabiensanglard.net
Build Doom3 on MacOSX with XCode4
http://fabiensanglard.net/doom3_macosx/index.php
9 comments
> Also, instead of forking it on GitHub, he just reuploaded the whole thing again
He responded in his comments:
> If not, the fork will remain buried as a Pull Request with no visibility at all.
Which is loads of bullshit. By design git is decentralized so upstream is a mere convention, where usually the closest to upstream is either the original author's repository or the most active repository.
He responded in his comments:
> If not, the fork will remain buried as a Pull Request with no visibility at all.
Which is loads of bullshit. By design git is decentralized so upstream is a mere convention, where usually the closest to upstream is either the original author's repository or the most active repository.
I was actually writing a blog post on this issue as we speak. GitHub's approach is broken to how they handle forks. It's a long post but I updated it to mention your comment here.
http://zbowling.github.com/blog/2011/11/25/github/
http://zbowling.github.com/blog/2011/11/25/github/
A fork is a mere 'git clone'. The brilliance and simplicity of SHA1s makes linking repos as trivial as a git remote add. I venture it would be quite costly to actively look at every commit of a new repo to match it with every other commit in every other github repo (unless they start maintaining a global index of all SHA1s->repos). So for now Github merely records that one cloned a repo, and I seriously won't blame them for that.
If the guy did things properly, although inconvenient we could just do that to merge back, but apparently what he did was rewrite or recreate history in some way, so that SHA1s changed so it's not even possible to add remote[0]. I guess that even with no common ancestor SHA1s one could still use rebase --onto to replay some part of his history.
Either way I can't tell because the repo is 404 now and I did not have a chance to browse it, let alone clone it.
[0] http://news.ycombinator.com/item?id=3277181
PS: I like some of your ideas, like hiding forks that can be fast-forwarded (i.e they have no changes i.e their HEADs are members of the parent repo), and detecting that one has pushed a repo that is obviously a clone of another, although I'd rather have it be manual (like a message on the github's console saying "we detected that this repo could be a clone of that repo, do you want to mark it as a fork?")
If the guy did things properly, although inconvenient we could just do that to merge back, but apparently what he did was rewrite or recreate history in some way, so that SHA1s changed so it's not even possible to add remote[0]. I guess that even with no common ancestor SHA1s one could still use rebase --onto to replay some part of his history.
Either way I can't tell because the repo is 404 now and I did not have a chance to browse it, let alone clone it.
[0] http://news.ycombinator.com/item?id=3277181
PS: I like some of your ideas, like hiding forks that can be fast-forwarded (i.e they have no changes i.e their HEADs are members of the parent repo), and detecting that one has pushed a repo that is obviously a clone of another, although I'd rather have it be manual (like a message on the github's console saying "we detected that this repo could be a clone of that repo, do you want to mark it as a fork?")
[deleted]
They can easily merge those changes. You just have to use the git command line. It's possible to merge in a separate repo. Like so:
git remote add d3mac https://github.com/fabiensanglard/Doom3-for-MacOSX-.git
git fetch d3mac
git merge d3mac/masterNo, you cannot do that easily the way you described:
$ git fetch d3mac
warning: no common commits
$ git merge d3mac/master
[ many many conflicts ... ]
CONFLICT (add/add): Merge conflict in neo/ui/Winvar.h
Automatic merge failed; fix conflicts and then commit the result.Here's the original repo with Fabien Sanglard's patch applied on top of it.
https://github.com/uxp/doom3.gpl
Just like his concern, I haven't tested building this on windows (VC 2010), so this repo needs to be cleaned up before it should be merged back into the main repo.
https://github.com/uxp/doom3.gpl
Just like his concern, I haven't tested building this on windows (VC 2010), so this repo needs to be cleaned up before it should be merged back into the main repo.
As someone who isn't familiar with game development, could someone explain what exactly is and isn't free? What happens if I try to run the game without the Doom3 media?
How might one go about making their own media for the game? Does it even make sense to do so? How tightly coupled is the released source code to the media?
How might one go about making their own media for the game? Does it even make sense to do so? How tightly coupled is the released source code to the media?
could someone explain what exactly is and isn't free?
The source to the game executable (rendering, script interpreter, physics, pathfinding) is free and released under GPL. The assets, however, such as scripts, textures, shaders are still under the original commercial license.
It is certainly possible to make your own media for the game; it will be a lot of work, but arguably less work than writing your own game engine AND making the assets. It makes sense because the Doom3 engine is very flexible and you can do a lot with it, some of which has already been done in the form of mods (as the SDK has been available for a long time).
The source to the game executable (rendering, script interpreter, physics, pathfinding) is free and released under GPL. The assets, however, such as scripts, textures, shaders are still under the original commercial license.
It is certainly possible to make your own media for the game; it will be a lot of work, but arguably less work than writing your own game engine AND making the assets. It makes sense because the Doom3 engine is very flexible and you can do a lot with it, some of which has already been done in the form of mods (as the SDK has been available for a long time).
Thanks.
So if I wanted, theoretically, to modify the mechanics of the game, how would I do that with "assets"? For example, if I wanted to add "magic" or something (like mana from diablo 2), and perhaps change the way "score" is calculated, is that part of an asset as well?
Do engines provide a DSL for making games? I guess that's my question. It seems like media assets only allow you to reskin Doom instead of making a new kind of game.
So if I wanted, theoretically, to modify the mechanics of the game, how would I do that with "assets"? For example, if I wanted to add "magic" or something (like mana from diablo 2), and perhaps change the way "score" is calculated, is that part of an asset as well?
Do engines provide a DSL for making games? I guess that's my question. It seems like media assets only allow you to reskin Doom instead of making a new kind of game.
In iD games, there's a clean division between game-specific logic (which is usually in a separate DLL, haven't looked too closely at Doom3 yet), and framework/engine code.
On Quake 2, you could replace the DLL to switch between the regular game and capture the flag. An expansion with new mecanics could, theoretically, be done with only DLL code and new assets. You'd need to change the engine code only to add new kind of effects that it didn't support yet.
So yes, if you don't change any code, you'll only reskin Doom by creating new assets (it's usually called Total Conversion). If you want to add new game mechanics, you have to write some code.
On Quake 2, you could replace the DLL to switch between the regular game and capture the flag. An expansion with new mecanics could, theoretically, be done with only DLL code and new assets. You'd need to change the engine code only to add new kind of effects that it didn't support yet.
So yes, if you don't change any code, you'll only reskin Doom by creating new assets (it's usually called Total Conversion). If you want to add new game mechanics, you have to write some code.
The scripts are written a C++-like DSL, and are part of the assets. There's map scripts, weapon scripts, AI scripts etc. They process high-level triggers and events to handle the storyline, different behaviours, and so on.
So you could make a magical weapon writing just scripts, for example. But yes there is a limit in the flexibility, if you want to make a completely different kind of game you probably have to change the C++ classes as well...
So you could make a magical weapon writing just scripts, for example. But yes there is a limit in the flexibility, if you want to make a completely different kind of game you probably have to change the C++ classes as well...
ID has released the source code to idtech1-3 and it has done wonderful things for the open source company. Take a look at warsow, which is based on the idtech2 engine (engine used for quake II): http://www.warsow.net/
There are also a variety of games using idtech3 (quake 3 engine) such as UrbanTerror, OpenArena, and Nexuiz (http://www.urbanterror.info/home/ http://openarena.ws/smfnews.php http://www.nexuiz.com/).
I'm not sure idtech4 is as suited for fast multiplayer gaming like the idtech2/3 engines were, but who knows what the open source community will come up with.
There are also a variety of games using idtech3 (quake 3 engine) such as UrbanTerror, OpenArena, and Nexuiz (http://www.urbanterror.info/home/ http://openarena.ws/smfnews.php http://www.nexuiz.com/).
I'm not sure idtech4 is as suited for fast multiplayer gaming like the idtech2/3 engines were, but who knows what the open source community will come up with.
id Software is, to no small degree, in the business of making game engines, not just games. Their engines are quite deliberately decoupled from data so they can license them to other companies for their own games.
You'd use a combination of general-purpose tools (Maya, Blender, Photoshop, GIMP), and more specialized tools (like Radiant for map making) to create original media assets.
Custom gameplay is achieved with a combination of a built-in scripting language and modifying a separately-loaded C++ library that encompasses most of what really constitutes the "game" beyond the core graphics engine. The game library appears to be included in the GPL3 release, and was previously available as part of the publicly-available SDK for modders.
You could take this code base and start adding your own custom models, textures, and maps, and have a workable game as-is.
You'd use a combination of general-purpose tools (Maya, Blender, Photoshop, GIMP), and more specialized tools (like Radiant for map making) to create original media assets.
Custom gameplay is achieved with a combination of a built-in scripting language and modifying a separately-loaded C++ library that encompasses most of what really constitutes the "game" beyond the core graphics engine. The game library appears to be included in the GPL3 release, and was previously available as part of the publicly-available SDK for modders.
You could take this code base and start adding your own custom models, textures, and maps, and have a workable game as-is.
Thanks, this was a great explanation.
PVS-Studio: analyzing Doom 3 code: http://www.viva64.com/en/b/0120/
Does the Doom3 source code includes RoE? There's no Mac port of RoE so now it could be possible to port it.
It includes the source code for the expansion pack game dll (in d3xp). You'll still need the original RoE assets (when I went to install them on Windows, the installer crapped out because I wasn't on Windows 2000 or XP, but you can just copy them from a directory on the CD- they're in a d3xp directory or something like that).
The idtech4 source code release does not include any game data whatsoever (only the game engine source code), so the short answer to your question is "no".
The slightly longer and more correct answer is the source release contains the game engine source and the Doom 3 and RoE game DLL source. The Doom 3/RoE game data is still required.
"brew install doom3" would be sweet.
No idea what brew is but be aware that the game media is not free.
Sure. Linux distributions used to deal with this all the time, you could install the old doom, quake packages, etc., and you'd have to provide your own game-media - but the package manager would install the linux-native game binaries for you.
Sorry to hijack, but has anyone been able to do similar for wolfenstein: enemy territory (on OS X Lion)?
My main issue is that I don't see why he's using a Das Keyboard with the letters on the keys. Doesn't that defeat the point?
cool job！
Also, instead of forking it on GitHub, he just reuploaded the whole thing again (https://github.com/fabiensanglard/Doom3-for-MacOSX-) so that others cannot easily merge these changes. And neither in his repo nor in his post, there is a reference to the original repo (https://github.com/TTimo/doom3.gpl).
Also, on the original repo, there were already a few fixes for Xcode4 and there is also a pull request with further fixes (https://github.com/TTimo/doom3.gpl/pull/13). I haven't checked it myself but it might actually work already.
Btw., further development is probably going on here: http://www.iodoom3.org/ (http://news.ycombinator.com/item?id=3277150) (https://github.com/TimeDoctor/iodoom3)