Unity2D : hail to the king, baby!

So yeah, like I previously stated on the blog, I’ve been testing Unity2D a lot these past days (and a bunch of other stuff, as always).

Overall impression is “GUDDAMITFINALY!1!!!11!”. And Unity delivers. So in the past I wasn’t the first Unity3D supporter, on the main purpose that 3D is not a subject to be treaded lightly, and a hell load of noobs and idiots would start making stuff with the free version. Eventually I got to work a lot with it this year and changed my mind concerning its raw power. I mean, just look at the time I lost on Kerbal Space Program, and this marvel of procrastination is being made with Unity. And workflow is really great, their Entity Component system is awesome. Always had problems dealing with Monodev, but as a MS tech dude, I redirected every single code line to VS. And I frantically never touched a line of Javascript. Still have to do some progress on my problems with this language, and Unity’s implementation is just… weird.

One of the things I’ve always regretted with Unity was the absence of real 2D support. It was until now a 3D tool, and you’d have to hack it to get things to show up in 2D. And the fucking asset store taking advantage of that : no sir, I’m not paying 60 bucks to show sprites on a free game making tool. So being limited to 3D is kind of drastic. Like I said, 3D is hard, people expect so much from it, you can’t just go around making 3D stuff without having previous experiences. Stuff like shaders, LOD and animations just give the creep to any dev that knows, and despite Unity3D being a very well conceived tool, you won’t escape these matters. And god I hate the asset store. This thing is evil. This thing should be held responsible for all the crap shitty mobile devs create. I’m exagerating of course, I just have a problem with these guys saying “oh, Unity doesn’t do that? Let’s go waste $150 on a plugin/asset/code library!” when it’s something as simple as post process shaders or block level design.

Alright, let’s stop ranting for a second.

To sum it up, Unity2D is Unity3D with one dimension less. This means you’ve got SpriteRenderer instead of MeshRenderer, that you’ve got 2D prefabs, 2D physics, 2D post process, 2D goodness! It’s freaking awesome, seriously. I’ve never tried other 2D alternatives like GameMaker, but I suppose they offer the same type of pleasure Unity2D sends your way. Drag&drop your sprites, add 2 or 3 entities, and you’ve got yourself a working prototype. The fabulous idea to natively support spritesheets and atlas textures is just enormous and fantastic, and the animation workflow is fan-tas-tic. Going back to physics, I was really impressed they were able to keep almost all of their 3D conventions, with the ease and simplicity it procured. Of course, basic primitive shapes like rectangles and ellipses are available, but the sprite based collider is art. Creating custom colliders has never been this simple! The greatest thing of this all will remain their 3D/2D mixing : a 2D scene is just an orthographic camera with a bunch of 2D components, but still in a 3D scene. The point is, you can easily merge 3D elements into a 2D scene, and the contrary too, because nothing stops you from using a SpriteRenderer in a 3D Scene.

So to try it out, I recreated the core gameplay of my SpaceShooterz game, and this took me.. at most something like half an hour : background parallax, player spritesheet, enemy + basic move routine, shooting and killing. 30 freaking minutes, and not even trying hard.

So this is great news for indie devs. We get an awesome tool for free and the raw power to create very complex 2D gameplays in no time. Since Unity exposes free exports to iOS and Android now, including the long-awaited Windows Phone and Windows 8, you devs have no excuse! Go make some games! This comes at a cost of course : Unity is heavy. In the last year only, the package went from 400megs to a whole freaking gig. The interface also is a marvelous work of the kraken, but you can get over that. I would recommend a computer with good perfs and a big screen though, your eyes will thank you.

Anyways, have fun!


Unity 2D in progress

Been testing out Unity3D’s new 2D features on the 4.3 update, I’ve got to say I’m quite impressed by the simplicity of the overall thing. Blogging on it really soon!

In the meantime, have a dogemon


Polycode Visual Studio setup

Setting up a Polycode project in Visual Studio is a royal pain in the ass. The fact that you have to use a Win32 project is the main reason. We can resume this in two dreaded words : HUNGARIAN NOTATION. God I hate this.

Of course, this is just for the entry point and fortunately, once this is done, you won’t have to face those horrible names in your code (unless you like this, which should be considered scary). Anyways, here’s a step by step on how to setup a basic Visual Studio project and get you running on trully interesting code in no time:

  1. First of all, we’re going to need a VC++ Win32 project. We’re going to make it empty (screw you, precompiled headers) so that we don’t get a load of files that we won’t need later
  2. We’ve got our neat empty project and I’m going to assume that you’ve got a release build of Polycode. The path for this example will be “C:\Polycode\Framework”. We’re going to go into project properties for our project and set your configuration to “All Configurations”
  3. Go to C/C++ > General and Edit on “Additional Include Directories”. Add the following folders
    • C:\Polycode\Framework\Core\include
    • C:\Polycode\Framework\Core\Dependencies\include
    • C:\Polycode\Framework\Core\Dependencies\include\AL
  4. Go to Linker > General and Edit on “Additional Library Directories”. Add the following folders
    • C:\Polycode\Framework\Core\lib
    • C:\Polycode\Framework\Core\Dependencies\lib
  5. Go to Linker > Input, Edit on “Additional Dependencies” and add the following after setting the Configuration to the correct value
    • For Debug Configuration :
    • For Release Configuration :
  6. Back in “All Configurations”, go to Build Events > Post-Build Event and Edit “Command Line” to add following command
    if not exist "$(ProjectDir)default.pak" copy "C:\Polycode\Framework\Core\Assets\default.pak" "$(ProjectDir)"

    if "$(ConfigurationName)" == "Debug" (
      if not exist "$(TargetDir)OpenAL32d.dll" copy "C:\Polycode\Framework\Core\Dependencies\bin\OpenAL32d.dll" "$(TargetDir)"
    ) else (
        if not exist "$(TargetDir)OpenAL32.dll" copy "C:\Polycode\Framework\Core\Dependencies\bin\OpenAL32.dll" "$(TargetDir)"

    What this does is it copies to build directory the OpenAL dlls so that the sound module runs correctly. Polycode author Ivan Safrin recently spoke about removing it for a more low level sound API, so keep that in mind for the future. This also adds the default.pak file to the project, which is not an obligation, but it contains starter resources to get you up and running a Polycode app directly, like fonts, default shaders, textures, stuff like that.

  7. We’re normally ready to code! Let’s add a file. I’ll name it main.cpp, because I like simple stuff, and if we could keep this file simple, it would be great. Anyways, let’s fill it with our entry point, that is, ugly Win32 code :
    #include <PolycodeView.h>
    #include "windows.h"
    #include "PolyApp.h"

    int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
        PolycodeView *view = new PolycodeView(hInstance, nCmdShow, L"My polycode app");
        PolyApp *app = new PolyApp(view);

        MSG Msg;
        do {
            if (PeekMessage(&Msg, NULL, 0, 0, PM_REMOVE)) {
        } while (app->Update());

        delete app;
        delete view;

        return Msg.wParam;

    So this is where your creativity comes in. Following the main wiki, you’re going to create an entry class (here, it’s called PolyApp) that is polled by the Win32 API for events (the do/while part) until you decide to shut it down. Protip : if you plan on doing something cross-platform, use the POLYCODE_CORE define that is defined at build depending on OS. You’re better off that way.

  8. Have fun with Polycode

So that’s it, don’t forget to change your Polycode build path, and you should have a project running. Hit me up on twitter if something’s wrong!


Polycode : create a code generated mesh

I’ve been working a lot with Polycode during the last few days, just to satisfy my curiosity regarding this easy to use C++/LUA framework. Despite the few problems on new Visual Studio editions, I got it running pretty easily and got to do a lot of fun stuff pretty fast.

Let’s be clear, Polycode is still young and is clearly oriented towards fast prototyping and intuitive realtime output, so I might just be pushing it in the opposite direction it is meant for. I also decided to disregard the LUA part, because I needed to get back into C++, and I like doing stuff the hard way. So that leaves me without any player, helper, or custom compiler of any sort. Despite that, Polycode is a real pleasure to use.

One thing I like to try on 3D frameworks is code generated meshes : define your vertices in code and create objects on the fly. What’s the point? Well for instance, take things like quadtrees that tend to evolve a lot during runtime, you can’t just load a model and expect it to change by itself. Polycode doesn’t really seem ready for this kind of stuff, as a lot of operations are done CPU side, and vertex creation is freaking slow. Anyways, to show the technique I used, we’ll create a simple face with a texture. It might not be the best way to do this, but since documentation is pretty sparse (not to say totally absent) on the matter, I interpreted the generated doc as best as I could.

I’m going to assume you already know how to setup a Polycode project with C++. There are 3 important objects we’ll be using to create our entity :

Polycode::Polygon *p = NULL; // the polygon that will hold our vertices
Polycode::Mesh *baseMesh = NULL; // the mesh that will hold the polygon
Polycode::SceneMesh *sceneMesh = NULL; // the object that will render the mesh to the scene

Polycode::Scene* scene = new Scene(); // the scene, duh

You’ll notice I explicited the namespace. This is because it conflicts with another Polygon class that Visual Studio forces on C++ projects. Now an important thing : when declaring a Polycode::Mesh instance, you get to choose the mesh type, and everything depends on that. For the most part, the type defines how the vertex list is interpreted and how it is drawn. There’s an awesome type called Polycode::Mesh::QUAD_MESH that takes vertices by groups of 4 and creates a neat quad. But in reality, wireframe is pretty horrible, and I wouldn’t recommend it for deployment. I tend to use the classic Polycode::Mesh::TRI_MESH that takes vertices by groups of 3 to create triangles. It requires more vertex definitions, but it’s more natural for the GPU, because remember kids, your GPU draws triangles in 3D, and nothing else. There are many more types, including dot and line renders, triangle strips and so on, so don’t hesitate to check them out depending on your scenario.

So, back to our vertices, because we still don’t know how to create them. It’s pretty straightforward, the Polygon class is neat :

p = new Polycode::Polygon(); // instanciate our uber polygon, no parameters
// add our vertices (x,y,z,u,v)
p->addVertex(-1, 0, -1, 0, 1); // there's also a Polycode::Vertex type, and this method returns a Vertex*
p->addVertex(-1, 0, 1, 0, 0);
p->addVertex(1, 0, -1, 1, 1);
p->addVertex(-1, 0, 1, 0, 0);
p->addVertex(1, 0, 1, 1, 0);
p->addVertex(1, 0, -1, 1, 1);

I used a counter clockwise vertex declaration, as this is the default culling option in most situations in 3D development. There is a backfaceCulling property on Polycode entities if you wish to decull the other side, but by default, it is set to false. So these 6 vertices define a quad object that I can assign to my baseMesh and render via my sceneMesh. Easy, right?

baseMesh = new Polycode::Mesh(Polycode::Mesh::TRI_MESH); // instanciate our mesh with our triangle type
baseMesh->addPolygon(p); // append the polygon to its structure
sceneMesh = new Polycode::SceneMesh(baseMesh); // instanciate our scene mesh with our mesh
sceneMesh->loadTexture("doge.png"); // we'll just load a texture to see if it's working, no shaders
scene->addChild(sceneMesh); // now the scene will render the scene mesh

That’s about all, if you’ve done everything right (that is, also setup the camera to a position and look at (0,0,0)), you should see a magnificent quad on your screen.

Doge Wireframe

If you got this far, I guess there’s not much else to say. No, seriously, for instance I haven’t seen any index buffer, which is critical in this case since vertex creation is way too slow. I suspect Polycode::Mesh::QUAD_MESH to make use of indices, but nothing is explicit so I cannot say for sure. The fact remains that this is all too slow and a bit cranky regarding workflow. So this is basically experimenting and definitely not ready for production of any sort. Stay safe, don’t do this at home.


Hello there

So yeah, I needed some space to talk about life, the universe and everything. Including bacon and a lot of code. So it’s gonna be an awesome blog written in english and talking about my dev experiences, mostly regarding 3D stuff and incredibly stupid things to do with a computer and a programming language.

Anyways, no format, no regular post date, only a free speech area with lots of rage and free taunts.

For starters : polydoge. Yeah, so old.