Fabien Sanglard's non-blog

  




Build Doom3 on MacOSX with XCode4.



November, 25th 2011

Introduction


The source code of Doom3 has been released three days ago :) ! I have started to read it and I will probably write a code review if enough people are interested.

According to the README.txt the source code is building well with Visual Studio 2010 but it is not building at all on Mac OS X with XCode 4.0 ( it is actually very broken :( !).

Here are the instructions to get it to run.

Note : If you do not want to redo all of this and just want to download Doom3 source code for Xcode 4, a fork of the original release is available:

github repo with Xcode 4.0 support.

Edit : This post describes the entire process for educational purpose only. If fixing the PowerPC intrinsic sheader was trivial ; Fixing linker's ld: bad codegen or ld: illegal text-relocoation were more difficult and I hope some will learn something in the process.

Edit : Thanks to John Carmack for tweeting about my website .

1. Fix Architecture and Target SDK.


Open the project in neo/sys/osx/Doom3.xcodeproject:

You should see this:



The first thing to notice is that all the Target SDK are missing:

In all 5 projects:

Note: There are two targets in the idlib project, make sure you update the architecture and target SDK in both.


2. Fix all broken framework references.




Redefine the broken OpenGL.framework reference in the idlib's two targets:

You should now have something that look like:




Now is time to fix the missing Carbon.framework, IOKit.framework, OpenGL.framework, CoreAudio.framework references in Doom3 project:




3. Fix ppc_intrinsics.h.


Since PowerPC are a thing of the past we need to remove all references:

Try to build Doom3 Project:





The build will fail. It is because PPC_INTRINSICS is automatically defined if MACOS_X is defined (old times when all Macs were PowerPC). The fix is to be more subtle in neo/idlib/math/Simd_AltiVec.h



    #define PPC_INTRINSICS


to



   #if defined(MACOS_X) && defined(__ppc__)
     #define PPC_INTRINSICS
   #endif


Tip : Double click on the error, it will take you right to the line you need to comment.


4. Fix ld linker options.


Try to build: It will fail again with this cryptic error message:


    ld: bad codegen, pointer diff in __ZN10idAnimator11CreateFrameEib to global weak symbol __ZN6idCVarD1Ev for architecture i386
    Command /Developer/usr/bin/clang++ failed with exit code 1

For some reason the five projects don't have the same linker flags and this is confusing ld:

For all five projects, make sure:






5. Fix C++ code.


Let's try to compile again. Surprise it still doesn't work:







    /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-
    1559777/neo/sys/osx/../../tools/compilers/aas/../../../idlib/containers/VectorSet.h:151:2: error:
     use of undeclared identifier 'Append' [3]


The template code is not liked by LLVM, you need to change VectorSet.h:



    Append( v );


to



   this->Append( v );



6. Fix more C++ code.


Try to fail at building again: Yea !!!





This time it is a bunch of miscast and impossible implicit conversion from long to GLint:







First batch:



   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/macosx_glimp.mm:412:26:{412:26-412:54}: 
   error: cannot initialize a parameter of type 'GLint *' (aka 'int *') with an rvalue of type 'long *' [3]


   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/macosx_glimp.mm:413:26:{413:26-413:54}: 
   error: cannot initialize a parameter of type 'GLint *' (aka 'int *') with an rvalue of type 'long *' [3]


   /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:117:28: 
   note: passing argument to parameter 'vals' here [3]



Change macosx_glimp.mm:



	[pixelFormat getValues: (long *) &glConfig.colorBits forAttribute: NSOpenGLPFAColorSize forVirtualScreen: 0];
	[pixelFormat getValues: (long *) &glConfig.depthBits forAttribute: NSOpenGLPFADepthSize forVirtualScreen: 0];
	[pixelFormat getValues: (long *) &glConfig.stencilBits forAttribute: NSOpenGLPFAStencilSize forVirtualScreen: 0];


to


   
   [pixelFormat getValues: (int *) &glConfig.colorBits forAttribute: NSOpenGLPFAColorSize forVirtualScreen: 0];
	[pixelFormat getValues: (int *) &glConfig.depthBits forAttribute: NSOpenGLPFADepthSize forVirtualScreen: 0];
	[pixelFormat getValues: (int *) &glConfig.stencilBits forAttribute: NSOpenGLPFAStencilSize forVirtualScreen: 0];






More errors:



   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/macosx_glimp.mm:1271:8:{1271:8-1271:28}:
   error: no matching function for call to 'CGLQueryRendererInfo' [3]


   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/macosx_glimp.mm:1283:9:{1283:9-1283:28}: 
   error: no matching function for call to 'CGLDescribeRenderer' [3]


   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/macosx_glimp.mm:1295:10:{1295:10-1295:29}:
    error: no matching function for call to 'CGLDescribeRenderer' [3]


   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/macosx_glimp.mm:1303:10:{1303:10-1303:29}:
    error: no matching function for call to 'CGLDescribeRenderer' [3]


   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/macosx_glimp.mm:1313:10:{1313:10-1313:29}:
    error: no matching function for call to 'CGLDescribeRenderer' [3]


Change macosx_glimp.mm:



    long rendererInfoIndex, rendererInfoCount = MAX_RENDERER_INFO_COUNT;
    long rendererIndex, rendererCount;
    long maxVRAM = 0, vram = 0;
    long accelerated;
    long rendererID;
    long totalRenderers = 0;


to


   
    long rendererInfoIndex;
    GLint rendererInfoCount = MAX_RENDERER_INFO_COUNT;
    long rendererIndex;
    GLint rendererCount;
    long maxVRAM = 0;
    GLint vram = 0;
    GLint accelerated;
    GLint rendererID;
    long totalRenderers = 0;






Some more errors:



   /Developer/SDKs/MacOSX10.6.sdk/usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, 
   and require _XOPEN_SOURCE to be defined [2]



Change DoomController.mm:



  #import <ucontext.h>


to


   
   #import <sys/ucontext.h>






Still more errors:



   /Users/fabiensanglard/raid/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/DOOMController.mm:474:8:{474:11-474:121}:
    error: assigning to 'cpuid_t' from incompatible type 'int' [3]



Change DOOMController.mm:



   cpuid_t Sys_GetProcessorId( void ) 
   {
     cpuid_t cpuid = CPUID_GENERIC;
 	
     #if defined(__ppc__)
       cpuid |= CPUID_ALTIVEC;
     #elif defined(__i386__)
       cpuid |= CPUID_INTEL | CPUID_MMX | CPUID_SSE | CPUID_SSE2 | CPUID_SSE3 | CPUID_HTT | CPUID_CMOV | CPUID_FTZ | CPUID_DAZ;
     #endif
 	
     return cpuid;
 	
    }


to


   
   cpuid_t Sys_GetProcessorId( void ) 
   {
     int cpuid = CPUID_GENERIC;
 	
     #if defined(__ppc__)
       cpuid |= CPUID_ALTIVEC;
     #elif defined(__i386__)
       cpuid |= CPUID_INTEL | CPUID_MMX | CPUID_SSE | CPUID_SSE2 | CPUID_SSE3 | CPUID_HTT | CPUID_CMOV | CPUID_FTZ | CPUID_DAZ;
     #endif
 	
     return static_cast<cpuid_t>(cpuid);
 	
    }






Finally

Change macosx_glimp.mm:



   common->Printf( "%8d kB total OpenAL audio memory used\n", ( alGetInteger( alGetEnumValue( (ALubyte*)
   "AL_EAX_RAM_SIZE" ) ) - alGetInteger( alGetEnumValue( (ALubyte*)"AL_EAX_RAM_FREE" ) ) ) >> 10 );


to


   
   common->Printf( "%8d kB total OpenAL audio memory used\n", ( alGetInteger( alGetEnumValue(
   "AL_EAX_RAM_SIZE" ) ) - alGetInteger( alGetEnumValue( "AL_EAX_RAM_FREE" ) ) ) >> 10 );



7. Fix the compiler.


Try to build: Fail.



   ld: illegal text-relocoation (direct reference) to (global,weak) __ZN6idMatX11InverseSelfEv in
    /Users/fabiensanglard/TTimo-doom3.gpl-1559777/neo/sys/osx/build/Debug/libidlib_nopic.a(Matrix.o) 
    from __ZN6idMatX11InverseSelfEv in /Users/fabiensanglard/TTimo-doom3.gpl-1559777/neo/sys/osx/build/Debug/libidlib_nopic.a(Matrix.o) 
    for architecture i386

It seems all the projects did not use the same compiler, some defaulted to Apple LLVM compiler 3.0 while some other did default to LLVM GCC 4.2. Set them all to LLVM GCC 4.2 (don't forget there are two target in the idlib project: idlib_pic and idlib_nopic).


8. Fix the OpenAL weak reference.


The Doom3 project features a weak framework reference:



   -weak_framework OpenAL



Remove this flag and add the OpenAL.framework instead.


9. Remove the old curl lib reference.


Delete the curl project reference and add libcurl.dylib to the list of framework in Doom3 project. This will make the build process much faster.


10. Don't build unused architectures.


Optional: For all projects: Set "Build active Architecture only" to Yes.


11. Add libraries to linker.


The build will still fail at this point since the linker is missing the game.dylib and the libidklib_pic.a libraries. Add them to the project:









12. Get the assets.


Dust out your Doom3 CDs:





If you haven't bought it yet: it is available on Steam ;) ! Place the base folder just next to Doom3 executable. Copy base/defaut.cfg from the source release to the base folder from Steam.







13. Link game.dylib.


If you try to launch the game now it will crash at startup:



   Dyld Error Message:
   Library not loaded: /usr/local/lib/game.dylib
   Referenced from: /Users/dev/TTimo-doom3.gpl-1559777/neo/sys/osx/build/Debug/Doom 3.app/Contents/MacOS/Doom 3
   Reason: image not found


  


Two solutions possible:


14. Enjoy !


Let's try one last time:
















Happy Hacking guys ;) !


Add a comment



Name Homepage
E-mail
(Will not appear online)
Comment



Comments (64)


#1 - Ville Krumlinde - 11/25/2011 - 03:52
Great job! Look very much forward to a code review too. In fact id should have hired you to write it before release, then it would have had good documentation from the start :-)
#2 - Alfredo Di Napoli - 11/25/2011 - 04:15
Wow, finally a programming post full of screenshots! Thanks!
Alfredo
#3 - Paul Betts - 11/25/2011 - 04:16
Great work, but why did you rename the project instead of just forking it and sending the Pull Request back? You could've saved this entire long blog post rant and just fixed the damn thing for everyone, instead of making them find your copy.
#4 - Aleks - 11/25/2011 - 04:21
Hi,
Just an comment for step 12.
You can copy the game.dylib to Doom 3.app/Contents/Frameworks and then
install_name_tool -change /usr/local/lib/game.dylib @executable_path/../Frameworks/game.dylib Doom 3.app/Contents/MacOS/Doom 3
it will change the reference relative to the app bundle so you have a self contained app (no need to copy game.dylib anywhere on the system).
Other than that, a great fix, thanks.
#5 - Fabien Sanglard - 11/25/2011 - 04:28
@Paul Because:

Usually id release the source code and stop maintaining it. Your approach would have been valid if we had some guaranty that someone on the master GIT will actually make sure the fork doesn't break anything on the other platforms builds and actually merge it back.

If not, the fork will remain buried as a Pull Request with no visibility at all.


IMHO it is already too late, the source code is all over the web and I don't think the gitHub one will be monitored in order to achieve a figure of authority.

Fabien
#6 - Mikki - 11/25/2011 - 04:49
Thanks Fabien!

For OS X Lion with Xcode 4.2.1, I started from your project but then also had to:

1. Set the SDK to 10.6 because a bunch of deprecated Carbon era graphics code has been stripped from the 10.7 SDK.
2. Change the Deployment Target for all the projects to 10.4

And curiously, I didn't have the problem with it trying to load game.dylib from /usr/local/lib.
#7 - Víctor M. Muriel - 11/25/2011 - 05:15
"I have started to read it and I will probably write a code review if enough people are interested."

Yeah, interested !

... And thanks for the fix.
#8 - Sylle - 11/25/2011 - 05:43
I would be very interested for a code review too. Nice job, great work!
#9 - Franck - 11/25/2011 - 05:53
>The source code of Doom3 has been released three days ago :) ! I have started to read it and I will probably write a code review if enough people are interested.

I'm interested, please !!!
#10 - stef13013 - 11/25/2011 - 06:00
Great jobs !
Thanks for theses tips ;)
#11 - Hernan - 11/25/2011 - 08:09
Thanks Fabien! I was stucked in the linking part. I look forward for your review of the Doom 3 code
#12 - Gustavo De Micheli - 11/25/2011 - 08:54
I would be very interested in a code review of the source. The reviews from the previous installment were awesome. Keep up the good work
#13 - metheguy - 11/25/2011 - 08:55
Review da code mofo!
#14 - Samuel - 11/25/2011 - 09:25
Bravo superbe travaille Fabien! je te kiff! Sam.
#15 - Steffen Itterheim - 11/25/2011 - 10:05
Great job!!!

Can't wait for your next tutorial: How to build Doom 3 for iOS. :)
#16 - Newlog - 11/25/2011 - 10:27
Awesome work!

I'm also interested in the review ;)
#17 - Bad Sector - 11/25/2011 - 10:28
I made some modifications in the codebase to make it build under the latest SDK and Xcode (4.2.1):
https://github.com/badsector/Doom3-for-MacOSX-

Also a DMG with precompiled "release" binary is available in the Downloads tab :-).

There are two bugs: fullscreen mode doesn't seem to work and due to a linking problem (similar to the one mentioned above, but apparently not due to the same reasons since all projects do use the same compiler) the UI interpolations are disabled (i commented out the code that caused the issue). When i find some time i'll try to fix these - unless someone else beats me to it, of course :-P. Whatever the case, i'll try to update the DMG when these two are fixed :-).
#18 - Matt - 11/25/2011 - 10:30
Can you upload the base folder as well?

I don't understand why all the media isn't included?

Do I have to buy doom 3. Then how is that open source?
#19 - Fabien Sanglard - 11/25/2011 - 10:31
@Matt

This is standard procedure for id software now: The source code is open but the assets remain proprietary.

>>Do I have to buy doom 3. Then how is that open source?

This way we can play and learn from the technology while id is free to keep on commercially exploiting their creation.

>>Can you upload the base folder as well?

This is still the property of id software, this would be illegal. It is only 10$ on steam.

Fabien
#20 - Fili - 11/25/2011 - 11:49
Great article! I appreciate that you took the time and showed how to compile it. Most of the fixes were trivial, but I might have abandoned the task if the app didn't compile from the first try. Now everybody knows it's possible with a few changes :)
When I saw the Doom 3 sources online I immediately opened your page to see if there's the source review. I loved the Quake 2 rasterizer analysis and can't wait to see what you can explain us about the D3 engine!
#21 - Paul - 11/25/2011 - 12:43
Fabien thanks for your awesome work. You should still have created this project as a github fork of https://github.com/TTimo/doom3.gpl . It is easy to consider that repo the "authority" as it now has 2,000 watchers and 200 forks. Even if you don't plan on submitting a pull request, it will make life easier for everyone if your project is in the same Network and has the same name as the other Doom3 forks. It's not too late to recreate your github repo as a proper fork (you won't even have to delete your local github repo.. just add the newly created github fork as a remote). Please consider it!
#22 - Brian - 11/25/2011 - 13:03
Damn this is awesome man! Should definitely consider @Paul's advice about making a fork. It's no extra work on your part once it's setup, but allows everyone else to more easily track your upstream changes from the original repo. There are plenty of projects that have forks that end up being the canonical repo. Please consider that for the sake of everyone else who'd like to fork and send *you* changes (yes I realize they can do that now, but having yours as a fork means a much nicer paper trail back to the original sources).
#23 - trg - 11/25/2011 - 13:34
We are waiting patiently for the code review.
Thanks and nice article.
#24 - Pete - 11/25/2011 - 15:43
Thanks!
Would love a code review!
#25 - SR - 11/25/2011 - 16:34
Hi, first of all thanks for all this.

Second I would point out that your guide does not mention how one can upgrade the Doom 3 assets taken from one's old install CDs. I'm still confused as to how to do it from OS X. From your instructions it appears that you simply use the non-updated assets from the original retail release of the game without applying any updates, which seems like the wrong thing to do (the source code readme even specifically mentions this, ie. the game should be updated to the latest version).

(Quick semi-related rant: I love id Software but I think they're being total douches for having never bothered to update any of their games on Steam to be Mac-compatible. Even those that are just DOSBox-contained DOS games, I mean how hard can that be?)
#26 - Moons - 11/25/2011 - 19:03
Please do a code review. Will be eagerly looking forward to it. Great blog and great articles.
#27 - jbriguet - 11/25/2011 - 19:14
Nice work ! A code review would be very interesting as well ! Thanks :)
#28 - Geenz - 11/26/2011 - 01:14
Awesome post, I've actually updated my repo with some of the stuff here!

I do have one question, have you by chance figured out how to get any game.dylib working with Doom 3 without having to link it to the executable its self?

This is something that's kinda baffled me; without linking the game's dylib with the executable, the game will certainly get to the title screen, but trying to actually load a game seems to cause it to crash completely.

Any ideas?
#29 - G Troupel - 11/26/2011 - 09:13
How does it feel to be tweeted by John Carmack ?
Keep the good work ;)
#30 - G Troupel - 11/26/2011 - 09:15
I meant "Keep *up* the good work" ;)
#31 - Andrey K - 11/26/2011 - 09:17
PVS-Studio: analyzing Doom 3 code - http://www.viva64.com/en/b/0120/
#32 - Jason Hunter - 11/26/2011 - 11:43
Fabien,

Please count me among those interested in a code review!

Thanks
#33 - Justin Meiners - 11/26/2011 - 11:44
A code review would be awesome!
#34 - Fabien Sanglard - 11/26/2011 - 12:55
@Geenz

I just updated the page: In order to avoid linking issue you can set "Dynamic Library Install Name" to "" in the "game" projects, this will make Doom3 search for the dylib locally
#35 - Fabien Sanglard - 11/26/2011 - 13:15
@G Troupel

>>How does it feel to be tweeted by John Carmack ?

I am going to print and frame the tweet :) !
#36 - Pavel Shevaev - 11/26/2011 - 14:49
It's really interesting to know your opinion about Doom3 sources. Doom3 migrated to C++ and I wonder whether it was a good move in the long run.
#37 - Geenz - 11/26/2011 - 15:05
@Fabien Why yes I am! I'm the maintainer of the repo you linked above. I actually came across this page when I saw John Carmack tweet it.

I used the OpenAL fix, the game.dylib fix (which would lead into my own fix), and the CGL fixes (which weren't necessary for me under LLVM GCC 4.2, but were necessary to get it compiling with Clang).

Regarding the linking bits, I moreso mean getting it working to the point that you can just load any game.dylib (i.e., one from a mod) without having the game crash on loading a map. I've done a little bit of investigation into why it crashes between vanilla Doom 3 and Doom 3 RoE, but I haven't found anything particularly useful yet.
#38 - gavlig - 11/26/2011 - 16:18
I'm very-very-very interested in the code review! Can't wait to see it!
#39 - emaaaa - 11/26/2011 - 17:09
Hi Fabien,

on github there's a 404 error for your page,
there's some problem ?
#40 - Bruce - 11/26/2011 - 18:09
Please write a review!
#41 - ViNDi - 11/27/2011 - 01:55
I just cloned the repo, and it builds fine without the fixes required above. So I'm guessing these changes were fixed in the repo. I actually get a "Build Succeeded" without changing anything. Cool! Although, I grabbed my PC CD-ROM discs and have no idea how to "dust them off". On the disc, I'm seeing the PC installer, then a Setup/Data/base/ dir with some PK4 files.. which should be just ZIP files. do I use this dir? What abou the other two discs?
#42 - Fabien Sanglard - 11/27/2011 - 02:08
@Vindi

All the changes are in the git fork, it is normal that you did not have to do anything.

With regard to the asset, you need to install the game with the 3 CDs. Then download the latest Doom3 patch (this will patch the assets as well). Then just copy past the "base" folder just next to the executable generated in the "build" folder.
#43 - ViNDi - 11/27/2011 - 03:03
Thanks Fabien, I got it running.
#44 - Florent_ATo - 11/27/2011 - 12:32
Amazing Job, well done !
#45 - Adam Robinson - 11/28/2011 - 03:14
Anyone have any luck running the expansion? I have ID_ALLOW_D3XP defined to 1 and I am able to get to the menu with a "/Applications/Doom\ 3/Doom\ 3.app/Contents/MacOS/Doom\ 3 +set fs_game_base d3xp". When I select new game though, it starts to load and then the console pops up with "ERROR: Function 'map_erebus1::main' not found in script for 'call' key on worldspawn"
#46 - Simon - 11/28/2011 - 06:08
Just want to show my support for the great code reviews you've done with Q1 & Q2, and would love to see the same for Q3 and Doom3!

Keep up the good work.
#47 - Ed - 11/29/2011 - 19:30
What a great job, congrats.
And pleaaaase, yes, a code review would be so great :)
#48 - gpimp - 12/07/2011 - 23:13
Man I love you website. I was just introduced to it. Just to let you know I would love if you reviewed the Doom 3 code man !!!
#49 - Tommy - 12/09/2011 - 17:19
Great! You should do a review on D00M 3 source code.
#50 - Tommy - 12/09/2011 - 17:20
Love this website! Do a D00M 3 Source Code review man
#51 - Nicky Weber - 12/13/2011 - 06:13
Sweet! This is one of my favourite sites. Keep up the awesome work, and I am really looking forward to a Doom 3 code review.
#52 - Varun Pant - 12/23/2011 - 11:25
Which mac do you use ?
#53 - Raymond - 12/24/2011 - 13:03
Doom 3 code review would be nice. :)
#54 - CvJ - 12/27/2011 - 13:16
Tip1: Doom 3 is compiled as debug. I switched the schemas to release and got +10 fps average in the timedemo demo1.

Tip2: When you got the Windows CDs like me, to patch the base folder to version 1.3.1 (necessary to play) , download the doom 3 linux patch and change the target folder to a temporary folder, then copy the files in the base folder of the temporary folder to your base folder.
#55 - CvJ - 12/28/2011 - 06:51
Doom3 doesn't exit normally though, when build as Release.
#56 - Tigrou - 01/08/2012 - 19:10
Hi,

I just discovered your website. Your reviews on ID software engines are very nice. I already check source of these engines long time ago but didnt know about your articles.

A doom 3 source review would be very nice. I already check it by myself and discover lot of stuff but i have to admit it takes times. i'd like to post what i have found somewhere but dont know what the best (create a blog ? use wikipedia?)
If you ever decide to create something here are some hints :
What would be very interesting is to know is general architecture (how engine is designed, different main parts). This would help to understand main code structure and know where to go. Some parts could be more described in details (like the renderer (especially those shadows), event/entities system, networking or the virtual machine. Would be also good to know if engine differ a lot from previous id software engines (especially idtech3)
#57 - zero - 02/02/2012 - 04:15
you are very great! and great articles, i am also writting an engine, hehe, i like 3d
#58 - munish - 03/14/2012 - 05:12
Great work!
Would be nice if you can review the Doom 3 source code
#59 - iceman - 06/30/2012 - 07:42
I am a n00b... and am using XCode for the first time. I downloaded the project by badsector and it compiled successfully. However i have no clue as to where the executable goes after building the code... pls help
#60 - Stefan von der Krone - 09/23/2012 - 13:43
Hey,
thanks for this great How-To. I could fix many problems, but I still cannot completely compile the sources. I'm running Mac OS X 10.8.2 with the latest Xcode 4.5. With the Apple LLVM Compiler 4.1 I get 3 Errors in the glext.h at lines 2786, 2787 and 2793. When I use the LLVM GCC 4.2 Compiler, there are about 50 more errors. I'm not that experienced in C++ and OpenGL, so I have no clue how to fix these errors. I think I have done all the steps in your How-To. I hope you have a hint.

Thank you very much! :)
#61 - StringBuffer - 10/05/2012 - 02:09
This is amazing, but can we use original graphics or do we need to create our own graphics, than it would be not as effective as this
#62 - Bradamante - 11/27/2012 - 09:48
I just tried Bad Sector's build. As others noted, it doesn't run in fullscreen and the menus are sloppy. The app crashes/hangs on quit when you run the brightness up too much. More importantly, the performance is - as I hoped - approx. 30-50% better than the official last patch (v1.3 b2847), which runs with 20 FPS avg., and only 5-10 FPS in some action-packed scenes on my Mac. Yeah sure my Mac is not the latest, but it sure is better than the hardware when the game originally came out. That's comparing 1920x1200 px (fullscreen) with the official build and 1920x1080 px (windowed) with Bad Sector's. I really wish the open-source builds would be improved so we can all enjoy a more fluid experience. Hardware: iMac (early 2009), OS X.8.1, NVidia GT 120.
#63 - Fei - 03/13/2013 - 07:48
Is it possible to build Doom 3: BFG Edition on Mac OS X using Xcode? It is probably similar to doing the original Doom 3. But how would that be done?
#64 - Fei - 03/14/2013 - 06:19
Is it possible to build Doom 3: BFG Edition on Xcode? And how would it be done? The source code seems similar so the process should be similar to building the original Doom 3.

 

@2011