Those who know or follow me should know by now I focus a lot on Microsoft tech. Not really that I only love their tech and go tell the others to fuck themselves, but I’ve had the opportunity to go into details professionally, and not much on concurrent stuff. I also specialize in 3d, that’s why you can read some stuff about that on my blog, and I’ve done a bit of MS 3d tech : XNA, DirectX/SharpDx, HLSL, Babylon.js (it’s done by my MS mentors <3 ), etc…

Anyways, once in a while, I get to do other stuff, like Polycode, or even Löve2D when I feel I need a laugh. More recently I’ve been hired on a mission involving iOS and a whole bunch of 3d stuff. I can’t really describe it, but I get to do realtime opengl on an ipad as a daily basis. That said, you might like to know I’m a total ass concerning opengl and iOS in general. I’ve got a 1st gen ipad that’s so slow we mostly use it for Spotify OH SORRY, YOU NEED iOS6 FOR THAT (ever since my Nexus 7 died out for no reason and said app shows no interest whatsoever in Windows RT (YEAH I’VE GOT A WRT TABLET, DEAL WITH IT)), and a 2009 Macbook pro that’s got a broken screen, no battery, and no charger. Soooo for the iOS part, I’m totally lacking the experience. Regarding OpenGL, I can’t say I’ve done much. Back in the days (that would be around 2006-2008) I used to fiddle with C templates in Code::blocks without having an idea of what I was actually doing. Yet, I felt like I could overcome this : I’ve seen the fires of DirectX, and have returned to say “lolnope”. So yeah, I took the mission.

Anyways, a week or so later, I can say I’m pretty surprised : GLKit is really good! Basically, GLKit is a set of helpers for OpenGL ES 2 on iOS. This includes blazing fast vector and matrix math, full integration with UIKit (iOS GUI framework), predefined constants for operations like vertex layout and base shaders that work like a charm! Of course, you still have low level gl stuff to handle, like buffer upload and manual VAO management (even though the concept of VAOs has got to be the best thing in the world), but you can setup a simple OpenGL program in not much lines of code. So yeah, GLKit gets my thumbs up. Only sad thing is that it’s exclusive to iOS, and I’d be doing a lot more of OpenGL if you could use it on other platforms. I suppose there are equivalents out there, but as always, finding time for something new is kind of a luxury nowadays.

Anyways, to show you what I mean by simplicity, let’s code a fairly simple program that outputs a quad with uniform color. If you’re an opengl/iOS expert, please insult me on twitter if I’m doing something wrong. First things first, everything included with Apple’s GLKit is prefixed with GLK, and everything that belongs to opengl directly is prefixed by gl.

We’ll start by making a new xcode Cocoa touch project, with a single view template, because the point is to show you how few lines are enough to get you doing opengl. Since I’m working exclusively for ipad, my project is not universal, so that’s up to you. Once we’ve created the project, we’ll go into the storyboard(s) and modify the base view class to GLKView. This ensures GLKit encapsulates the view to make it available as a canvas to draw on. Next, we’ll go into the ViewController.h to add a call to GLKit headers and define our controller as a GLKViewController. Your ViewController should look like this :

That’s all we’ll do in the header file, let’s head over to the ViewController.m ! We’ll add the most important stuff : the context, of type EAGLContext. This is the object that will bind OpenGL to our view and tell OpenGL to draw on it. So in your ViewDidLoad, you will initialize this context and attach it to the view :

You’ll notice the drawableDepthFormat in these lines. To make it simple, this is the depth format OpenGL will use for the render target, aka our view. If that’s not clear, Apple has a lot more to say about this. Now, let’s draw something! We’ll start by clear the screen with a horrible magenta color to ruin your eyes. As a reminder, the principle of clearing is to make sure you draw/render your calls on a clear frame. If you don’t do it, you’ll be drawing over the previous frame. And unless for some unknown reason this is what you are looking for, you want to clear your frame before drawing anything. It’s like an automatic background color. The color can be anything in the RGB + Alpha domain (limited by float precision in general), so you can get creative. So, we’ll start by overriding a method GLKViewController implements : -(void)glkView:(GLKView *)view drawInRect:(CGRect)rect. This convenient method is automatically called at regular intervals to draw a new frame. It’s 30 frames per second by default, and you can set this higher or lower with self.preferredFramesPerSecond in your controller. Aim for 60 FPS, your customers’ eyes will thank you. In this method, we’ll set the clear color and clear our main buffers : color and depth.

The glClear method takes flags with specific masks to tell the GPU to clear specific buffers. Fortunately OpenGL is provided with a whole set of defines so that you don’t have to remember these masks. You can launch your app, and you should by now be screaming “DEAR LORD MY EYES”. Don’t thank me, it’s normal.

Okay, so that was fun, what more can we do? Let’s draw something! A quad! With indices (elements in opengl, don’t ask) to make it funnier! So like I said, GLKit provides a ton of math helpers, and we’re going to take advantage of 3d vectors to define our vertices in space. We’ll also define a bunch of indices to order our draw calls and send all of this to our GPU. Let’s add all of this inside the ViewDidLoad method, right after setting our context. Here’s the code as I explain it through the comments and bellow (scroll for more) :

That’s a lot of code, but it’s pretty straightforward. The first 3 variables are identifiers to GPU buffers and the VAO, don’t worry about them now. First we create 2 arrays to store our vertex and index data. For vertices, we’re using GLKit’s implementation of a 3d vector, GLKVector3. It’s a C struct, so init is old school style with C functions. Indices use a base type of GLuint which is an alias for a platform unsigned integer. It’s easier to read and indicates this part of your code is opengl stuff. Every lib does it in 3d anyways, so get used to these aliases. The fun part begins just after that : we create a VAO and use it. VAOs are kind of hard to explain, but basically, they’re memory addresses that act like containers to a set of buffers. So the point is, you create and bind a VAO first to set its data, and at render time, you bind it back to automatically get the buffers you defined in it. And this, kids, is why it’s awesome. This is pure opengl though, it’s present in ES 2 and recent opengl implementations for computers, so enjoy. You might notice a difference on other platforms : here we call glGenVertexArraysOES which is specific to ES 2. Just remove the OES suffix and it’ll work just fine on your computer. The point of our 3 variables at the start is that we store the identifiers for reuse (and disposal). Next, we create our index and vertex buffers GPU side and upload our data. The steps are always the same : create the buffer, tell opengl to use it as a specific buffer (using the defined masks), upload our data. The upload method takes a few parameters : the mask for which buffer we’re aiming, the size in bytes of the data we’re sending, the actual data, and its usage. Usage is how to specify how the GPU will act with the data regarding CPU : if you plan to update your vertices often, you might want this to be dynamic. That’s not the case here, so we’ll set it as static. More info on the official docs for glBufferData. This operation is exactly the same for indices and vertices, appart from their specific masks.

The next part is kind of where I consider black magic usually happens with DirectX : layout. The point of layout is to tell your GPU how to interpret the vertex data you send. In DirectX, this gets me going all “wat” as it is totally counter intuitive. OpenGL in raw is a bit better, and GLKit makes it pretty simple. So first of all, we tell OpenGL that we want position activated for our shaders with glEnableVertexAttribArray. We use a GLKit define to simplify this, so it’s clearly too easy. The tricky part is defining which part of your data is actually position. As you should have noticed, we uploaded GLKVector3 on our GPU. It’s a structure made of 3 floats, and we didn’t normalize it, and all of our vector defines the position. So when we define our data structure with glVertexAttribPointer, it’s pretty simple : first, what we are defining (position), then the number of values defining our position, the type of value (using a gl define and not an alias type), a boolean to tell if it’s normalized data, the size in bytes of 1 vertex (aka the stride, since we are in a flat array GPU side), and the offset to the start of our data in the structure we sent the GPU. That’s it (yeah, that’s already a lot of stuff). We close the VAO so that OpenGL knows we’re not writing into it anymore.

So, how do we draw? We need a shader, or else nothing will ever show on our screen. But right now, I don’t feel like writing GLSL, doing a shader program structure, compiling stuff and uploading it to the GPU, etc… fortunately, GLKit provides a helper shader that’ll do most of what you’re looking to do with a shader : GLKBaseEffect. Right after our previous code, let’s define one (make the variable on the instance level, we’re going to need it later) :

So, initialization is easy : create an instance of the class, and have fun with the properties. There’s a ton of them, including 3 lights, texture management, diffuse, emissive, specular color, etc… we’ll just be using a constant green color for the sake of simplicity. We’ll also set up our “camera” so that we can view our render from a certain distance. We make use of another GLKit structure : GLKMatrix4. There are many helper functions to create the projection and view matrices (google it if you don’t know what it means), so basically we set our projection to a 60° FOV, with the aspect ratio of our screen, and a near/far to [0.1f, 100.f[, which is totally arbitrary. Small fact that can save you five minutes of rage : during ViewDidLoad, view’s width and height don’t take orientation in account. So if you’re in landscape like I am, invert width and height for aspect ratio math. This is fixed during runtime, so it’s just for the sake of having a perfect square on the screen for this example. So now, to draw our stuff, we’ll go back to our draw method and right after the clear order, add this:

As I said previously, loading our VAO allows us to specify to the GPU we want to use all the associated data (index and vertex buffer). We spool the effect to prepare all the shadery stuff in the back (legend wants it that shader is actually generated realtime depending on the properties used) and draw our indexed elements : first we specify what we are drawing (triangles max, no quads for ES 2, sorry), how much indices we’re reading, the kind of data the indices are, and the offset, useless thanks to the VAO. We then unbind the VAO to prevent memory leak GPU side (it’s a best practice, it doesn’t necessarily happen). Run it, and you should see some ugly green square which a magenta background burning your eyes. Success! One last thing though : unsetting all the data. Add this override to ViewDidUnload :

This is important because you need to remember OpenGL is C and not Objective-C. Meaning that resources don’t get automatically released and GPU side can keep the garbage for a long time. So save your iDevice, release OpenGL stuff.

Well, that’s it. It might seem like a lot of code, but if I showed you the same thing with DirectX, you’d be screaming most probably. Anyways, this is just an introduction, and it covers approximately nothing of what kind of benefits GLKit brings. It’s really a great piece of code for fast app development, and the great part is that you don’t have to use it if you don’t want : it’s pure helper over OpenGL ES 2, and sweetens the stuff without making it dependant! I’d recommend you have a look at Jeff Lamarche’s code if you want to get started and also the book “Learning OpenGL ES for iOS” which is an excellent way to go way deeper into this tech.

You can find the full code for ViewController.m on this Gist !

Have fun, code safe.

Tuxic

I’ll be honest : after yesterday’s rant, I really thought about if I should sell you this code through the asset store or not. But hey, I’m not such a bitch, the trick’s pretty simple.

So here’s a nice way to get an acceptably precise metronome, with custom BPM and signature. The purpose is to create a MonoBehavior that you can stick to an entity to count your beats. Let’s start by creating a new C# script (javascript should be straight forward, but I don’t use it, sorry). I named it metronome, because that’s what it is. We’ll add in a few fields that will make sense soon enough :

First 3 fields should be straightforward if you know a little bit of music theory : signature represented by its base and step amount, and Beats Per Minute. CurrentStep and CurrentMeasure just let us keep track of what step/measure we’re on. Now this is where the trick starts in order to be as precise as possible : interval is the absolute amount of seconds there should be between 2 beats. nextTime is the relative moment of when the beat will actually occur.

I see the guys in the back of the room going all “WTF man”, but it’ll make sense in a second : we are going to use Unity Coroutines. Unity uses Mono, which supports a great load of C# thread operations, including Tasks. The problem is, Unity is not thread safe, and tends to go all “NOPENOPENOPE” when you use threads and Unity objects. This is were the coroutines come in : they are a sort of bastard “multitask” technique that consist in watering down heavy operations between frames. That’s the important word : frame. Basically, a coroutine is a yield return method that disperses its executions on a frame to frame basis. On its simplest form, it works much like a simple component update, as launched coroutines are each called by default once per frame until they are over. The interesting part is the kind of value you can send to your yield return.

UnityGems did a great article on coroutines, and this is what you can send as a return value (shameless copy from their article) :

• null – the coroutine executes the next time that it is eligible
• WaitForEndOfFrame – the coroutine executes on the frame, after all of the rendering and GUI is complete
• WaitForFixedUpdate – causes this coroutine to execute at the next physics step, after all physics is calculated
• WaitForSeconds – causes the coroutine not to execute for a given game time period
• WWW – waits for a web request to complete (resumes as if WaitForSeconds or null)
• Another coroutine – in which case the new coroutine will run to completion before the yielder is resumed

I highlighted the one we are going to enjoy very much : WaitForSeconds. It’s straightforward, give it an amount of time and it will execute when that time is consumed. Let’s write a first coroutine with that!

Simple coroutine : infinite loop that increments CurrentStep and CurrentMeasure. It works pretty fine, but the more discerning readers will have noticed that we never set interval. I’m going to do a simple public method for that, to be able to reset and change my coroutine :

This goes a bit more into music theory, but I suppose you can deal with that if you’ve read this far. So we get the absolute interval between each beat and store it in our field. You’ll notice I use StartCoroutine and StopCoroutine with a string of the coroutine method name. This method is more expensive but allows us to stop the coroutine at will, which is appreciable. You can call StartMetronome() in your Start(), create an entity and attach the script as a component, and set for example Base and Step to 4, BPM to 120 and launch. In your debug log, you’ll have a nice timed “bop” appearing in an endless loop. Mission accomplished.

Wait, we still have something to fix : on usage you’ll realize that this is precise but not enough. It tends to desynchronize pretty fast (at 120bpm, it’s be off tracks in less than 4 measures) and that’s bad if for instance you’re making a musical game. The reason is simple : coroutines are balanced by frames, and frames have a delta that you don’t really control. The problem is that your interval is fixed, but the WaitForSeconds might just decide that it’s too late to execute at this frame, let’s wait another one or two. Thus the wibbly wobbly bullshit the metronome outputs. This is where nextTime comes in. The purpose is to resync the metronome with effective time scales. The wait interval will thus never be constant. Let’s modify our methods :

This very simple trick allows you to fix this sync problem, as the wait delta will be fixed depending on actual time and expected time. Of course, this is far from perfect, but it does the trick : beats are really precise, even after 20 minutes of play. The rest is up to you. I decided to implement events on tick and on new measure, and you can find my code sample on this gist. Output is as follows with a visual thingy:

Anyways, have fun, code safe.

Tuxic

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!

Tuxic

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

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 :
     Polycore_d.lib
     zlibd.lib
     freetype_d.lib
     liboggd.lib
     libvorbisd.lib
     libvorbisfiled.lib
     OpenAL32d.lib
     physfsd.lib
     libpng15_staticd.lib
     opengl32.lib
     glu32.lib
     winmm.lib
     ws2_32.lib
   • For Release Configuration :
     Polycore.lib
     zlib.lib
     freetype.lib
     libogg.lib
     libvorbis.lib
     libvorbisfile.lib
     OpenAL32.lib
     physfs.lib
     libpng15_static.lib
     opengl32.lib
     glu32.lib
     winmm.lib
     ws2_32.lib
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)) {
               TranslateMessage(&Msg);
               DispatchMessage(&Msg);
           }
       } 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!

Tuxic

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 :

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 :

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?

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.

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.

Tuxic

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.