So, more work on the Mac port today… XCode is so full of weirdness… Maybe for a Mac-head, it all makes perfect sense, but for me, it seems it goes the most roundabout way possible to do simple stuff like linking projects (with dependencies), etc…
So, small list of issues today (and solutions, in case someone trips into the same issues):
– Linking a project (Cantrip) to another (the game): Just need to drag the Cantrip .xproj file INSIDE the game project, and add the dependency and output binary in the Build Phases menu…
– Some symbols in the Cantrip library missing… This just ended up being the fact that if you drag a directory with some source files, you can see the source files in the file explorer on XCode, but they aren’t added to the actual library… To do that, you have to add the directory with the “Create Groups” checkbox, instead of the “Folder Reference”
– Some stuff you can add to the “Link Binary With Libraries” directly, but other stuff you have to add to the actual linker options with “–L” and “–l” (stuff that gets “installed” to /usr/lib).
Anyway, except for a last error that I don’t even understand what it means, I have the game linking… Now I just need to be able to setup where to it gets built, and set the debugger/run parameters and I can start hitting actual bugs…
Now listening to “Hybrid Theory” by “Linkin Park”
So today I started the Mac port… Half of it was lost updating the company’s Mac (I haven’t used it in ages), another 25% loading up my repository (almost 2Gb of data off-site), and then the rest in trying to figure out how the Mac actually works…
At first look it seems like a Linux system, but there are a series of subtle distinctions that makes a newbie lose some time…
So, this is my current setup at my DayJob™, where I’m working on the Mac port, since I don’t have a Mac at home:
Thankfully, Synergy helps me manage the number of keyboard/mouses (I really hate the Mac mouse and keyboard)! 
So now I got the engine library compiling, but that’s probably the easy part… Now, step 2 is getting the main game code to compile, and then the hardest part: linking!
Now listening to “Descent” by “Dawn of Tears”
Never thought this, but considering the next (logical) step in the game development is to make the Mac build of the game, I decided to take the day to do some bug fixing, since it seemed a bit more relaxing than going for the iMac… 
Anyway, most of the bugs were simple stuff (and some can hardly qualify as bugs):
– Sound now fades out/in when you skip a cutscene (or else you’d hear all the cutscene sounds)
– Removed the object occlusion effect during the cutscenes (kind of spoils the cutscene if you can see the enemy behind the walls!)
– Title screen now fades in after logo screen
– Game now autosaves before each cutscene (mostly so I can have a resume point later, to record the movie for trailers, or to add sounds, or just general testing).
– While skipping cutscenes, the “loader” screen appears (so the player isn’t stuck looking at a black screen)
Maybe tomorrow I’ll start the Mac port, if I can’t find anything else to do!
Now listening to “Awakening” by “Winter In Eden”
What seemed like a simple issue to solve (lack of performance on low-end card because of ambient occlusion) ended up being much more complicated than expected!
So, yesterday I decided to add a new system to be able to customize the level of ambient occlusion (in terms of resolution)… I added the system, but while testing it I found a flickering on the logo, which seemed weird…
Of course, I assumed the problem was the ambient occlusion code I just added, but it turned out was a Z-buffer precision issue that was present for some time, but I never detected it… Basically, if I ask GLFW for a 24-bit Z-buffer on my ATI card, it returns me a 16-bit Z-buffer, so the resolution is terrible and makes the flickering…
I didn’t notice it before because I usually don’t start the game by the logo, and when I did the tests on Linux, the Z-buffer given had 24-bit!
So, silly issue, simple to solve, but it took me forever to track down…
At least the game runs nice on Linux fullscreen, as it should!
The measurements being 0 means the game runs as fast as possible, only locked by my frame limiter (VSync is not turned on). In the above screenshot, ambient occlusion is running at 512×512 (instead of 1920×1080, which was causing the issues)… The quality isn’t as good, but if you’re not looking for it, you probably don’t notice it…
Now tomorrow I can fix some other minor bugs before moving into the Mac port (another headache, I expect!).
Now listening to “Crimson Thunder” by “Hammerfall”
Link of the Day: This game looks neat, if it has a storyline besides just mechanically doing this over and over again:
Today I was trying to test the game in fullscreen under Linux and I found a weird performance issue…
In the initial cutscene, the game was running very slow (about 30 FPS), but when I moved the player to the left a bit (so more geometry on screen), the game jumped to the normal 60 FPS… Going back to the initial position, I got the same result again (30 FPS)…
First, I suspected the multithreading (the initial position is on the boundary of the area, which could cause trigger a parallel area generation), but I turned off multithreading and the results were the same…
Then I tested some stuff, and found out this only happened when the game was running at 1920×1080… At 1600×900 it didn’t happen! Doing some more fine-grained performance measurement, I identified the problem was in the “SwapBuffers” call, which is when the CPU/GPU are forced to go hand in hand…
So, maybe it’s the resolution? But a 30% increase in resolution shouldn’t loose me over 75% frame rate!
This is when I tried using gDebugger to narrow down where the slowdown was happening, but I couldn’t get it to work, leaving me with the only viable solution: start to turn off stuff…
When I finally turned off Ambient Occlusion, I got rid of the performance hit… I was not expecting that, so I tried reducing the resolution of the ambient occlusion (it’s being done at the same resolution as the screen), and it still was gone, so it’s the size of the render targets! For some reason, my video card (a nVidia GTX460) struggles with such big render targets, so I’ll have to change the code to switch the resolution on those cases…
The “shadow” you’re seeing on the render above was some error I introduced on my tests… 
Now listening to “Griefshire” by “Elis”
Link of the Day: I love good physics simulations… although not real time, it’s still impressive:
And after a lot of tears, blood and sweat, I got a Linux build of the game working 100%!
Even sound is working perfectly!
Now I’m feeling the urge to get this working on the Mac as well, but I’m not sure if I want to fight that battle just yet… Maybe I’ll look into fixing some bugs before tackling this huge task…
Now listening to “Antares” by “Sybreed”
Finished today the 64-bit windows build… This was a bit more work than I expected, since there was small stuff that wasn’t prepared for that, bugs to sort out, linkage issues, etc…
Anyway, got it up and running and now I can pass those changes to the Linux version, and see if that works properly now…
Now listening to “Illumination” by “Tristania”
Finally finished the 64-bit porting (syntax/compile-wise), and after a couple of hours, all libraries are linked!
So now, time to run the game for the first time:
Bah, more issues with .SOs… Most of the stuff I actually compiled as a static library (or is included with the system), but this one I can’t… So after copying it to the proper directory (/usr/lib):
That distorted looking thing is the game window! So the game started, but failed miserably to startup… Still, small victory!
Looking at the generated logs, it’s a problem with reading the textures… I even know what it is… I’m reading the DDS header with code like:
fread((unsigned char*)&(magic_number),sizeof(unsigned long),1,file);
Problem is that “unsigned long” under 32-bit compilation used to be a 32-bit number, and under 64-bit compilation is a 64-bit number, so that means that I’m reading more data, so everything screws up… I need to change all of that to something like:
fread((unsigned char*)&(magic_number),sizeof(uint32_t),1,file);
Which will take some time to do on the whole of the codebase…
The advantage of this is that I can do it under Windows, by compiling the game in 64-bit, since the same problem applies!
Now listening to “Forever is the World” by “Theatre of Tragedy”
So today I finished compiling the main game code, and I stepped into linking, and I started having issues, mainly mismatches between 32-bit and 64-bit libraries…
I was trying to compile the game in 32-bit (don’t need the memory space of 64-bit), but after some soul-searching (about 10 minutes of it), I decided to go for a 64-bit distribution on Linux (and probably the other platforms as well). If I need the 32-bit I’ll think about it later, mainly because it’s hard work making Linux compile 32-bit applications when it is a 64-bit install. The way .SOs work makes it very hard to understand exactly what’s getting compiled and where the conflicts are… And nowadays, I’m guessing there’s no big need for 32-bit systems…
So I’m porting the code to 64-bit, which carried a fair amount of small problems (just from the compiler point of view, complains about size of entities, etc), since the code wasn’t exactly prepared for that circumstance. Nothing is very hard, it’s just time consuming (especially because the IDE I’m using isn’t nearly as good as Visual Studio, even in terms of raw performance).
Now listening to “Seventh Son of a Seventh Son” by “Iron Maiden”
Got the main game library to compile, so now it’s time to tackle the actual game code…
This went fairly well, considering I’m using a lot of external libraries, that needed to be compiled or installed:
– FMOD: For audio support, supplied with binaries that worked with no issues (which was surprising, binary distributions on Linux tend to be a bit twitchy)
– GLEW: For OpenGL extension management. This was easy to compile and install afterwards
– GLFW: For input and window management. This was easy to compile and install afterwards
– GLSL-Optimizer: Only provided with code, was a bit hard to compile until I understood I was missing some other libraries (the MESA implementation, for example)
– Lua: For scripting, I’ve done this in the past a fair amount of times, so it was easy enough
– Recast: For navigation mesh generation and path-finding. Also simple to compile
Although most of the libraries went fairly well, this is all very time consuming, and I expect problems will start hitting me on the linking phase…
Now listening to “Use Your Illusions” by “Guns’n’Roses”
