swixel dot net

After about a week of playing with code, I ran a test on my laptop: librocket broke, the shaders lagged, and my system came to life and killed everything in the room.

After an uneventful trip to the necromancer, I started looking at where it failed, and the Intel GPU was the first place I checked: that was it.  So I added a simple function to a class:

void DetectOGLAdv()
{
    OGLAdvEnabled = true; // Assume it’s good

    // PostFX disable (for those using SFML)
    if(!sf::PostFX::CanUsePostFX)
        OGLAdvEnabled = false;

    // Intel GPUs are horrible
    if(strcmp((const char *)glGetString(GL_VENDOR),”Intel”) == 0)
        OGLAdvEnabled = false;
}

As I find things that break my code I’ll add to it, but I thought it might be useful to point out the VBO fault exists even in the newer cards (at least on Windows).

The other workaround is, of course, finding a way to ship MESA drivers for Window to enable users to run it… the real difficulty will be in determining where the MESA drivers start, and DirectX begins (my understanding is that DirectX isn’t influenced, but it’ll be time to find out soon, woo!).

GWEN didn’t work out; sfengine didn’t work out; but LibRocket did!

So the engine is basically just SFML + LibRocket.

This may seem a bit weak, but you need to remember I have to interface everything, plug up my own stopgap solutions for things — SFML is just a compatibility layer between a bunch of really neat technologies (most notably OpenAL, libsndfile, and FreeType — all of which I was using before) and multiple platforms (I’m yet to actually start work on the Mac here to see how much needs love for GCC and/or Xcode).

LibRocket rocks, but if you’re going to use the included SFML layer, remember to invert the Mousewheel delta (i.e. throw a - before it in the switch), otherwise your mousewheel actions will go backwards ;)

Calling my SFML work an ‘engine’ is a bit of an exaggeration, simply because SFML does most of the heavy lifting for me, using most of what I was using before (including OpenAL, OpenGL, and FreeType), while still giving me the power to use OpenGL.

So the status is:

• GUI is GWEN (using an updated/fixed version of voodooattack’s SFML renderer);
• Input is working.

That’s really all for now. This is ~24 hours after I started an SFML version of my game…

While talking to a friend (who is using SFML, which is, for all intents and purposes, an engine in its own right), I stumbled across ‘sfengine’, which contains just about everything I want — except that it runs on SFML 2.0, which is still ‘unstable’ (read: under development). Given I run bleeding edge Gentoo, this isn’t really a downside…

For now I’m suspending work on my engine to have a look at it, as it may well resolve any number of issues I’ve had, including, but not limited to, managing scaling of certain objects.

I’ve had a few people ask me what exactly an engine is, and why it’s so difficult to make one.

First of all, it is not difficult to make an engine, it is difficult to make a good one (my current work should not be mistaken for a ‘good engine’, at least not yet).  The difference between something which works, and something which is both dynamic and clean, is that you can build an ‘engine’ which does precisely what you tell it (by hard-coding every possible outcome), whereas a dynamic/clean engine enables you to add things easily, externally, using an interface of some kind (usually an Application Programming Interface, like an API).

Secondly, to answer ‘what is an engine’ in brief: an engine is effectively a series of mechanisms (functions or methods, with the option for classes or modules, depending on your language).  These mechanisms perform logical tasks, like drawing a box, or detecting a mouse click.  There are different types or mechanisms (e.g. callbacks which fire when something is done, literally ‘calling back’).  There are different purposes (input from keyboard/mouse, audio output, graphical output).  Each of these parts require their own distinct components, usually external (unless you’re building the hardware too, in which case you probably have to do it yourself to some extent).

It is not difficult to build basic mechanisms, but it is time consuming to decide what you want.  Even though I entered this with a fairly good idea of what I wanted, I have already had to compromise when I found elements I chose to use don’t quite do what I want — and not wanting to have to modify them heavily, thus breaking ease-of-update later, I had to make minor changes (e.g. I now have a single global variable, and this is rather annoying).

I hope this provides an answer suitable to the question.  I might, at a later stage, run through building some trivial components in a non-OOP way, for those who are interested (feedback on this would be useful, either here or via IM/e-mail for those who have it, so I know I’m not wasting my time before I begin).

I’ve sat relatively silent in terms of communicating what I’m doing (that is, if you’re not on my “Steam Friends” list, or in IRC with me).

In my silence, I’ve been hammering away on an based engine, based on the following wonderful technologies:

• GLFW 2.7
• OpenGL 2.1
• OpenAL 1.1
• FreeType 2.4.4
• GLEW 1.6.0

And I’m considering rolling in the following:

• OpenCV (latest)

The primary purpose of this engine is to replace GarageGame’s Torque engine in the full version of Orbsphere.  The secondary purpose is to work on some smaller games that feel a bit hacky on other engines (not that this engine isn’t hacky).  And its tertiary purpose is to work on some academic software I’ve been meaning to play with for a while (mostly visualisation stuff — looking particularly at graphing in fun ways ;)).

There isn’t much to show at this point (okay, there is, but I haven’t implemented input, or properly hooked up the GUI objects yet), and a lot of it will be a case-by-case utilisation, so I’ll be keeping the test product under the hood until it’s ready for testing.

For those wondering ‘why OpenGL 2.1?’, the answer is simple: my laptop has an Intel GPU, and it has OpenGL 2.1, but not 3.x — I’d love to use something like the procedural shaders I’ve seen on other products, but if my laptop can’t play it, I’m not sure I’m a fan of my own game; I want to open doors, not lock it down so its only available on powerful Windows gaming rigs.

So I’ve decided to move away from GarageGames and Torque and write my own engine. I’m starting with a single tool: GLFW.

Everything else is raw C++ at the moment.

I am contemplating a scripting engine, using the following languages:

• Python (I would prefer this);
• Lua (Other people appear to prefer this);
• Erlang (what can I say, I need help);
• Something else magic.

I’m also looking at putting together a few simple elements like the console and what not, but the engine will be accompanied by a game (to test it).

Anyway feedback is welcome (as usual).

Orbsphere: Prelude has been released on orbsphere.net.

I’m presently working on an entirely different project, so the Orbsphere work is on hold at the moment.

As a less-than-subtle hint, I’m watching the moving `Hackers’ (from 1995) — it’s on iTunes and is probably a cult classic.

Since the potato hat release, there has been a renewed misunderstanding of how TF2 items are used.  I think it’s time I correct that.

(FALSE) Myth #1: Servers do all of the item handling

While this was once true, modifications like the “TF2 Equipment Manager” changed this for everyone. The change ensured that both client and server check the backpack.

(FALSE, unless they’re Valve) Myth #2: People can create items with console commands

For the modders who have found something to hook within the server binary, that does not work, and has not worked for a very long time (if it ever did — as far as I know, nobody tried).

(MOSTLY FALSE) Myth #3: People can create items with hacks and get away with it

While they could, and it’s become apparent to me in the last two months how they could, I have almost no doubt that Valve logs every single bit sent through the system in question, and therefore that abusing it would result in a VAC ban. The way to make items was only made public by Valve in what I could consider to be a mistake made in trying to optimise the game.

There is a lot of speculation in the opensteamworks community that someone malicious found out how to find out during the potato hat update. <REMOVED> Apparently the hole has been closed (I’d dare not test it, others haven’t either, but apparently it doesn’t work.)

(FALSE) Myth #4: tf2items hacks your backpack data

No. Asherkin’s TF2items extension does not hack your backpack data, it recreates items and gives those items to the player. It’s opensource, so go read the source if you doubt me.

(FALSE) Myth #5: The item system is easy to hack

While this isn’t so much a myth, it’s fairly difficult to actually do anything unless you found the vulnerability above. The opensteamworks project does have headers obtained/constructed through reverse engineering which reference the old item system. This system is no longer userd. Instead something called the ‘gamecoordinator’ is used. This system is connected to Steam itself, and it appears (from the tf2 server and client binaries) that tf2 has its own abstraction. I would suspect other games with items (DOTA2?) would likely use it too.

(FALSE) Myth #6: The GameCoordinator data is public, and opensteamworks made it possible to hack the game!

No. The opensteamworks project did not publish the leak. While they published a lot of information other than that particular leak, they showed incredibly good sense and character by notifying Valve about the issue, rather than making it public.

(UNKNOWN; why would you?) Myth #7: Debugging the game will always get you VAC banned

Try -insecure, or better yet, debug the server; chances are, there is no legitimate reason to mess with the client beyond skinning things. If you debug in secure mode, it’s your risk, and I wouldn’t blame them. I haven’t tried it, and I wouldn’t recommend it. Though apparently many modders run both server and client through VS2010; but without the source, or a client side plugin to debug, there’s no point anyway as you won’t catch anything.

(MOSTLY FALSE) Myth #8: I run a TF2 server, and have installed SourceMod, therefore I know everything

There are some exceptions where this is probably true, but I sincerely doubt it for most of you. I don’t know everything, but I have the good sense to go looking before I start spouting nonsense about how you can hack a game with a plastic whistle and a tinfoil hat.

If you want more information on the game coordinator, be aware that most of it has been published in relatively shady places which talk about techniques to violate software licences (rin.ru being one place), or have published information which many may consider questionable from a legal point of view (opensteamworks). I find that reading information doesn’t hurt me, but if you use it, it’s at your own risk.

As a final note, I do not participate in the reversing of data for use in the opensteamworks project, as I wish to publish a game on steam with steamworks and do not wish to upset Valve prior to that. If you have any questions about what is already available, the comments in the provided source should be enough; and I will probably answer simple questions regarding what is already in the public domain (regardless of source), unless in an agreement with Valve (i.e. they accept a submission of mine) I am requested not to do so.

For those who haven’t already seen it, Midgard’s name has been revealed, and any further interest should be expressed on the Orbsphere blog, Facebook, or on Twitter.

http://orbsphere.net