Spellcaster Studios

Make it happen…

Linux Porting, Part 3–The Linkagening

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).

work_linux

Now listening to “Seventh Son of a Seventh Son” by “Iron Maiden”

Linux Porting, Part 2…

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”

Linux Porting, Part 1…

So now I’ve started porting the game to Linux… Most of the work I’ve done it before-hand (OpenGL, GLFW, GLEW, FMOD, etc), but of course there’s a miriad of stuff I’ve forgot, so now it’s mostly fixing small syntax issues…

work_linux

That also requires to compile/install a lot of libraries, making sure I don’t have mismatches, etc… So a lot of boring work, that I expect will take the next couple of days…

Now listening to “Once and Future King” by “Gary Hughes”

Updating Linux, Part 2…

After four hours of work today, I managed to get my Ubuntu working again, at version 14.04!

It took a lot of work… First I had to figure out why the installation wasn’t working…

That was due to some broken packages, that had to be removed by hand (thank you “apt-get remove”).

Then, after the update was done, Synergy (my software KVM without the V application) didn’t work anymore for some reason, so I had to delve into that topic and figure out why it didn’t work… Ended up being a difference between old window manager and the new one, which gets configured in different places)…

Then, installing the NVidia drivers was a bitch… When I installed them, it broke the UI and the system didn’t even start… So I had to go with SSH access and figure out why it didn’t start, ended up a kernel mismatch… Ended up being just a broken link to the NVidia drivers, but it took me some hours…

After this, I installed Steam and “The Talos Principle”, to test the 3d capabilities of this system (check how well it ran, and if everything was running properly). That went very good… The video card on that system is a nVidia GTX 460, not exactly state of the art, but good enough for my game (and for “The Talos Principle”, which runs rather well, if I don’t max everything).

Finally, installing NetBeans 8, C++ Edition… This one was fairly easy, for once!

So now I have a Linux machine ready to start development!

Now listening to “Night Castle” by “Trans-Siberian Orchestra”

Link of the Day: Now this is an awesome trailer:

Updating Linux…

This started off nicely… Disappointed smile

I started building my Linux project for Gateway, using Netbeans, and the first compilation error was the lack of an include file somewhere in the standard library…

Ok, looking in the net, I found I was missing a package… So install the package and find out I can’t solve the dependencies because my version of Linux is “too old” (13.10)…

So, since I think it might be a good idea to develop this on the latest version I can find, I decide to upgrade… So far, so good:

screen649

Then it fails because of… er… something:

desktop_error

So, now I’m stuck there… I don’t want to make a clean install, because I have stuff configured, etc, but I need to upgrade, so I’m guessing I’ll spend the next few hours/days trying to sort this out… Disappointed smile

Now listening to “Unreal” by “Sarcastic”

Link of the Day: Final E3 video, this is yet another sequel… The original game was nice, had a lot of good ideas, but the level/area/story design was a bit lacking, even if the graphics were quite cool, as well as some mechanics:

Platform-independent timers

Not much time for work on the game today, so I decided to tackle something boring, yet quick: platform-independent timers.

I already had high-precision timers for Windows, but for Mac and Linux I had no idea on what to do; yet, I decided to take the short-path to victory: strip that part of the code from GLFW… I could use it directly when under Mac and Linux, but then I could have divergent results from Windows to Mac/Linux (since it works slightly different from my own), so I decided to strip it out and use it directly, without having to initialize the whole of GLFW…

I will probably do the same with the joystick part, although I fear that one will be a lot more work, unless I wrap it nicely (keep all the joystick code in a single file, and just abstract around it).

Next step is maybe try to take the first steps in building the game under Linux… That should keep me busy for the rest of the week…

The reason for this step is the fact that the UI artist works only with a Mac, and I want him to actually play the game, get a feel for it, so he can start work on the new UI… and I have much more knowledge of the build pipeline under Linux than Mac (although they should be similar, at least conceptually)…

Now listening to “New Blood” by “Peter Gabriel”

Link of the Day: This looks nice, and it has lots of potential on the gameplay front:

More bug fixing!

As the title indicates, today was mostly dedicated to bug fixing… It was mostly small visual glitches I introduced in the last couple of big changes (GLFW integration, AABB culling), and they were mostly annoying to me… Smile

screen648

The worst was solving a bug with the occlusion system, but that ended up just being a simple matter of changing the Z-function from “GREATER or EQUAL” to just “GREATER”…

At least, the to-do list keeps getting smaller, and the biggest tasks there are already halfway done (like the porting)!

Now listening to “Dead End Knights” by “Katatonia”

Link of the Day: So, Deus Ex fanboy here:

Welcome detour

Had a welcome detour today… My artist finally finished the diagonal movements of the main player, so I had to see how that looked…

Before, I had only the 4 major directions, which translated in something like this:

player_animation01

Now, the sprite has eight directions!

player_animation02

It looks much better!

This required me to add a new “mountpoint” system, so that the shots gets out of the proper place, according to the image, but I’m really happy with the improved visuals!

Of course, in the process I found some bugs, so I’m going to get rid of those before moving on to the platform-independent timers (ripping off GLFW, so I can use that in DirectX as well).

Now listening to “Night Eternal” by “Moonspell”

Link of the Day: Soooooo cute:

GLFW and input

Today I managed to finish the input rewrite to use GLFW with the OpenGL renderer…

Got to admit that it went rather well, all things considering… It’s a bit “hacked”, and I might work it over again at a later stage (to make it more efficient, less DirectInput-like, since there’s no actual need).

screen646

Not noticeable on the screenshot, but all input is going through GLFW and rendering over in OpenGL, which means that the game is one (big) step closer of being portable… There’s still some amount on non-portable code, and probably one million bugs to sort on the other platforms, some more abstractions, etc, but it’s really close…

Now listening to “Paris Kills” by “The 69 Eyes”

Link of the Day: Microsoft knows how to make a presentation:

Never according to plan…

As I said yesterday, I’m currently using GLFW to help me in the future to port the game from Windows to Linux and Mac…

Of course, nothing goes according to plan…

Problem number 1: I thought I could use GLFW to handle all the window/keyboard/mouse events, both in OpenGL and DirectX, but that is not true… GLFW takes care of the OpenGL contexts and creates one for every window it creates, so I can’t use it with DirectX, which is too bad… That’s not too serious, I just have to add a “translation” between Win32 and GLFW messages.

Problem number 2: It was very hard to get rendering work… After a lot of debugging, testing, tweaking, comparison, and general snooping in the GLFW code, I finally found out that my OpenGL context (created by hand) was a 3.2 with backwards compatibility, while the OpenGL context generated by GLFW was a 3.2 without backwards compatibility and forward compatibility… Of course, part of this was my fault, I totally forgot I had the context generated with backwards compatibility (because I’m making GLSL 1.4 shaders, so I can pass them through the glsl_optimizer that can’t handle GLSL 1.5 shaders), but the API could be a bit more expressive in terms of errors… It also doesn’t help that gDebugger crashes because of a glDeleteShader command that doesn’t seem to have anything wrong with it…

All in all, this only solidifies my opinion that OpenGL as an API is a mess… It has too many things that can go wrong without any significant debug/error output, and setting up the contexts (without external libraries) is part of the problem…

screen645

The way this is setup currently, I have zero confident that this will work under Linux/Mac, since I don’t know if they’ll provide me with a compatibility context… If not, I’ll have to write all shaders in GLSL 1.5, and optimize them by hand, which is very hard to do with my system that uses über-shaders to generate all permutations!

Next step is to get the input working on GLFW, so stay tuned!

Now listening to “Tales from the Kingdom of Fife” by “Gloryhammer”

Link of the Day: Still on the E3 stuff, I liked the art-style and general concept of this one:

Next step is getting all the input working with GLFW…