by Joe Flood on 22 August 2015

25. Twenty-Five.

Damn, that's old. Really old. Like, a quarter of a century old!

I'm going to have to try really hard not to have a mid-mid-life crisis (quarter-life crisis?)! Kidding, I'm fine.

Thankfully, 25 is also my lucky number. So, with that in mind, let's make my 25th year* a good one. This year could well be the beginning of something big!

* Yup, I realise it's really my 26th year - bugger.

Another rant about MSVC++...

by Joe Flood on 09 February 2015

So today I came across a weird bug. On Mac, the game engine will happily draw stuff directly to the screen - i.e. for drawing HUDs, overlays, etc. For this test, I used a small red box, but anything would do really!

On Mac, red box appears. On Windows, not so much.

**scratches head**

All up-to-date on Git, check. Same code, check.

**scratches head**

Fast-forward 3 hours, and I've solved it. The reason you ask? Visual Studio's compiler gets it wrong.

The problem is simple. I have a piece of code which draws a VBO (basically, stored geometry, shapes) with a Colour. Here are a couple of methods that I can use to render a VBO object:



void Render(GLenum drawType = GL_TRIANGLES) const;
void Render(const mesh::Material &mat, GLenum drawType = GL_TRIANGLES) const;
void Render(const Colour &colour, GLenum drawType = GL_TRIANGLES) const;
void Render(Texture *tex, GLenum drawType = GL_TRIANGLES) const;

The one we're using is on line 3 - rendering with a given colour. The calling code is this:

Do you see it now? I didn't either! Looks like while the Xcode compiler (clang) is good enough to realise that my 0xFF0000 should be used to construct a Colour, MSVC decides that I'm talking about a Texture* (see line 4!). So rather than applying the red colour to the quad, it applies an invalid texture, which the engine apparently silently ignores (oops!) and draws a transparent box. Great.

Problem solved, though!

Great success!

by Joe Flood on 31 January 2015

So, I've been beavering away trying to get Equinox to work with Windows for the last 2 weeks or so, and I've moaned about how horrible Microsoft's compiler is.

I still think it's the worst compiler out there, not being able to do these things:
  • Use symbols (methods, classes, ...) from a library without having each one marked with __declspec(dllexport)... eugh!
  • Errors resulting from using debug runtime libraries vs release ones, which are not actually explained as such!
  • Having to explicitly tell it the template specialisations of a class at compile time (for a library), rather than allowing proper template instantiation
  • No constexpr!!!!!
  • Can't use static const vars inside a class (why not? Seriously MS, an error saying that the feature is "not implemented" is not good enough!)

But I do bring good news - it builds! And better than that, I can now convert an existing project for Windows in around 20 mins. New projects take about the same. If I now create a template project, I can cut those times right down to near enough zero! So that's the next task.

But, without further ado:

Atoms, running on Windows! Sound is also working, but you can't see that in the screenshot. Obviously.

Exciting times!!

Another change in direction...

by Joe Flood on 15 January 2015

So, I've taken a step to the side. A sidestep.

Work on the game engine itself (Equinox), and the games based on it, has effectively been paused, and put to one side.

Why? You thought I loved making games?

Well - I do! But I've realised I need to target my games to Mac AND Windows. And so, I'm now making the engine build and run with both the world's most commonly used OSes:

  • The Mac version will continue to use CMake, allowing me to build from Xcode, command line, or something like CLion.
  • The (shelved) Linux version should be workable very simply based from the Mac version.
  • The Windows version will build through Visual Studio only, using binary versions of the libraries. 

So, the next few weeks will be spent building a toolchain to use on Windows to build and run games! 

Just need to work around some of MSVC's shortcomings - lack of constexpr, no list initialiser syntax in member vars, and very, very strange variable rules - I can't implicitly convert ints to floats in some situations, because it's narrowing (?! - no it's not!) 

More Tech!

by Joe Flood on 22 November 2014

It's been 2 months and there's no word on the blog; what's going on?!

Fair point.

You'll recall last time I mentioned that I was adding in sound support to our game engine, Equinox right?

Well, we did it! And it all now works amazingly which is fantastic, but there was a much more important subsystem that needed writing - text support!

As a showcase for this, I decided to make a simple word game using Equinox - and of course to do that, I needed to support fonts and text. So, without further ado, behold! Text!

Text Test

Doesn't look too great though as you can see, each letter is rendered at the same width, and they overlap in places. The waveyness (not a word, but I'm using it!) is intentional though, this demonstrated a pretty nifty Mexican wave effect when running!

So fast forward a week or so, and I've cleaned it all up and got it all working perfectly. AND I've put together a quick prototype game to show it off, as shown below:

Final Product
So how does this work, you ask? Well, very simply actually! Thanks to a very nice piece of freeware, I'm able to give it any TrueType/OpenType font, and get it to create a bitmap of it, like this:

It also creates with it a file which describes where each character lives inside the font. Pretty neat, actually! You'll also notice it's white that's because the colour is added artificially using a shader program, so we can use any colour at runtime.

Okay, okay, but why didn't we just use something like opentype to render the fonts on-the-fly? Well, pretty much the only reason not to is just that it's simpler not to require another additional dependency, as this means more effort to port to other platforms. This is especially true since we're targeting everything from Windows to Mac to Linux to iOS and Android!

Phew - that was a huuuge blog post! So what's next? Next we'll be taking a very old 3D dungeon prototype and adding 2D GUIs into it! 

Why? Because the game engine doesn't support GUIs yet and we're going to need them!

Next Page

©2012-2015 Javawag. All rights reserved.