A little bit about me

So, who am I?

My name is Alex de Vries and I'm from the Netherlands, but I don't suppose anyone really cares.  I too read lots of stuff from the internet and I've seen plenty of interesting stuff, but don't ask me who made it. Sure, I read comics like those from xkcd.com, but don't ask me who the author is (sorry Randall). Probably when reading this sentence you already forgot my name and that's exactly how it's suppose to be. Don't look back at the first sentence to try and fool yourself into thinking you remembered, that only works when you are trying to impress somebody else. So why am I writing this, you ask? Well, I do have to start somewhere and just starting a blog without giving any personal background information is weird as well. Basically I'm writing this for it to exist and not to be read, just like an EULA I'm always forced to agree to before giving my expert opinion on Raptor related articles.

A passion for games

As a child, ever since my parents bought a computer, I was intrigued by games. Soon I dreamt of making my own games, without even thinking of how difficult it may be. When I got my own computer I finally could play around on a computer without having to worry that my parents got angry because I (again) managed to permanently corrupt Windows. It wasn't difficult to inadvertently destroy windows in that time, but creating virus-like batch files just to see if it works sure didn't help. Finally I got my hands on "DIV Games Studio" so I could finally build games, or so I thought. It turned out that you needed to have some programming skills to build games :P.

After about 6 months of trying to make a simple game and failing miserably (abandoning each project after a month or so) at least I could say that I learned to program in this Pascal - C++ like language. Learning a programming language while building a game you intend to keep and improve upon turned out to be a bad idea. While learning new techniques you will see how stupid your old code has been and soon it will take more time to refacture old code than it is to extend upon your existing code giving you the idea "It's better to start from scratch".

Learning to become system administrator

I was never a big fan of learning stuff just because "you had to". I really hated to learn things like French, German or Economics. Learning things like Mathematics, Chemistry and Physics were kinda 'okay' I suppose, but not fun enough to actually do my homework. Looking back at myself I sure was an annoyance to my teachers. I never really payed attention, never did my homework and I kinda understand why I wasn't welcome at the classes of Chemistry and Physics the last half year till graduation. I still managed to graduate somehow and continued to study for system administrator at a community college. (actually in the Netherlands it is called MBO, but who cares right?). I could easily have gone to a university for a bachelor degree if I actually opened my books from time to time, but I didn't really care.

Ahhh... the good years of community college... It gave me so much free time, I still remember it as a 4 year vacation giving me time to do whatever I wanted. I didn't learn much at school because well.. tinkering with my computers at home and playing around with different operating systems gave me plenty of knowledge to breeze through any exam. During this time I 'really' learned how to program (in my spare time), mainly using C/C++. I got interested in the .. hmm how should I call it ... "security-scene".. yeah that sounds legit :). This time I got into problems with some of the teachers, not because I didn't do what I was suppose to, but because I did a little bit too much. It turned out that an unannounced audit of their network security wasn't really appreciated so I got expelled for a month :(.

Learning to become a software engineer

Since community college was so simple and I had no intention to search for a job that required me to solve paper-jams, I started to look at possible bachelor degrees. During the previous 4 year vacation I learned that learning could be fun, as long as you don't have to learn of course. Learning to become a software engineer while I already knew how to program seemed like a good idea. I certainly made a good choice, finally there were some teachers that knew things that I didn't. I could extend my programming-tool-belt with stuff I previously had difficulties with. Learning stuff about multitasking, Big-O notation, advanced data structures, math with matrices and other stuff is quite difficult if the only knowledge-base you have access to is filled with all kinds of pornography (It's amazing what some Japanese women do in front of a camera, it's so ... how to put this ... weird, yeah, weird...). I was still toying around with interesting security stuff like devising ways to be anonymous on the internet (in a TOR-like fashion), using session-hijacking to get into e-mail accounts and by building rainbow tables with the botnet that I created on the schools computers.

I certainly did not forget about my passion for games, but my interest shifted more to the technical difficulties of building a game than actually making a real game. Building a game engine is fun because of all the difficulties lie in programming challenges and software design decisions. Creating a game involves making models, textures, sound, music, story, ... and it's not that I cannot do all that stuff (although certainly not an expert), it's just ...well... kinda boring. If I really wanted to make a game all by myself I would choose a simple concept in 2D or simplistic 3D, search for a good existing game engine (of which there are plenty) and download some free texture and sound packs. At my 3rd or 4th year during my bachelor I actually build a relatively simple 3D game-engine in C++/OpenGL and a simplistic game using it. It had some basic things like frustum-culling, collision-detection and ray tracing but it was still very basic (I didn't even create my own shaders for example).

Being a software engineer

After I got my bachelor degree, I worked as software engineer for a year at a company making business software. The software itself is kinda boring, but the way they made it wasn't. The finished product was actually a whole collection of configurable services that talked to each other. For example: Instead of writing a data structure that stores addresses that can be queried and filled using public functions they build a complete service around it. The service could be queried using WCF and be centralized somewhere instead of putting the code in every single client. Normally you would create a DLL or static link the code, but this idea of Software as a Service and Cloud Computing sure opened up some cool possibilities. The GUI for the clients used XAML which is an XML declaration of how the GUI should look like (so designers are able to create GUI's without the necessity to create source code). The XAML declaration is downloaded from one of the services so the client application is like a webbrowser that talks to the services in the cloud. Really awesome! Updating software could be done without any downtime and building a new product was as simple as putting a bunch of services together and configuring them. My job was to develop a scripting-language that was simple enough to be used by the people that give technical support, but powerful enough for software engineers to completely customize service behavior. It was a fun time in which I build my own Compiler-compiler, learned how to decently handle services talking to each other and of course building software that is actually going to be used somewhere.

Master's degree in Cognitive Artificial Intelligence

Even before starting my job as Software Engineer, I knew that I wanted to do another study, something to do with Artificial Intelligence. Besides games and security I also had a soft spot in my heart for fuzzy cute little programs with a mind of their own. I've chosen "Cognitive" Artificial Intelligence because studies in normal Artificial Intelligence will have more focus on existing algorithms and programming. This time I have chosen to deviate from my personal philosophic vision of not wanting to be forced to learn. I thought that if I chose a masters degree in the faculty of humanities, i'd encounter more new stuff, and right I was. Following courses on Filosophy and Neurophysiology sure was interesting (although the Linguistic courses reminded me of why I hated to learn French and German in highschool). It may not come as a big surprise, but there is a lot of common ground between artificial intelligence and gaming. Not only is artificial intelligence used in games, games are also used for research in artificial intelligence. Simple 'games' are often used as a test-bed for artificial intelligence in order to make reasonable comparisons between different AI-algorithms. 3D simulations also come in handy when we are trying to make a robots learn to walk. The simulation shown in the video below is not my own, but it sure is fun to watch :). It might not look like it, but that derpy looking sausage is doing something that is quite difficult to build.

I know that there are some people, usually movie enthusiasts, that are actually scared of robots taking over the world. I however think we have nothing to worry about and even if robots are capable of self reproduction, there are plenty of other extinction level events that are way more likely. Don't get me wrong, I do believe in the theoretical possibility of Strong AI, but that is probably not going to happen in my lifetime :(

Anyways, I typed a whole lot more than I set out to do and even referenced stuff that isn't even mine, but I also don't want to end a post with sad emoticon. To end this page with a smile, I'll just leave you with this picture

  1. link says:

    I don't even understand how I stopped up here, however I believed this put up was once good. I do not recognize who you are however definitely you are going to a famous blogger when you are not already. Cheers!

  2. Adrian says:


    first of all, thank you for your great articles. In fact, i read them all carefully line by line :-)

    I am really interested in the idea of multithreaded three state render engine since i am actually working/designing a software (scientific scope) where physics and rendering play a role. I studied the sample sources and the general idea is clear to me (i suppose:-).

    What i need is to adopt it to my software and that gives me some headaches. In my case i have three threads, the main application's thread (GUI thread), a rendering thread (which reads the current state from the GUI thread) and a physics thread, which reads and updates the states from/back to the GUI thread. Is it too much to ask you for a simplified sample (sources) which demonstrates how to use the three state concept on a simple object, which only provides a transformation, e.g.

    public class MyObject
    public Matrix4D transform;

    This object is instantiated in the GUI thread, its transformation needs to be read by the render thread and it is read and updated from the physics thread.

    Your help would be really appreciated

    Kind regards,

    • eierkoek eierkoek says:

      Hey Adrian,

      Sorry for replying so late (over a month, wow, so sorry!), so I hope it's not in vain. Let me start by saying that it is uncommon for having two separate threads for GUI and rendering. Usually this is one and the same thread for these reasons:
      - If separated in two threads you'll still need to synchronize them so the render thread is allowed to draw on a handle in the GUI. (e.g. for OpenGL's SwapBuffers(hdc) function). In Windows it is not allowed to access a GUI-handle from a different thread than the one it is created on (as it should be).
      - All functions on the video card are non-blocking (they return immediately), it only cues the job for the videocard. When VSync is enabled only SwapBuffers(hdc) will block to ensure all draw calls that are cued are processed.

      But that's not what you were asking. You are asking for a simple demonstration using the triple render state method that is simplified. This simplification will have a limitation to be aware of, namely:
      The size of the scene is static (we cannot dynamically add/remove renderable items), because it does not use the synchronized tree structure as described in http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part2/

      So I'll create a demonstration project that only bounces a smiley object around the screen. To keep the example simple, I'll program it in C# with OpenGL (using the OpenTK wrapper, to use OpenGL with C#). This way code should be more easily portable if another language/framework is used.

      The source and binaries can be downloaded here:

      Hope I'm not too late to still be useful to you.

      - Alex.

  3. Redee says:

    Hi, very nice site with a lot of useful information.
    I try to fix my lags render (simple interpolation...) by your buffer-rendering.

    Hopes I can understand this.


  4. MikeDX says:

    You may be interested in the re-birth of div and the latest version that is being developed. Also a number of games have been ported to modern systems at js.mikedx.co.uk

    If you have any of your old games (either as exe or prg) I can recompile them to modern systems and even give you the ability to play in a webpage!