Good thing I have a modular rendering system design

I might create an OGL render system after I’m finished with the D3D rendersystem to support the rest, but for now I’m using D3D.

Something that doesn’t make sense

Sometimes, to keep sanity working in your head you need to make something weird to test the good stuff out.

For example, I was testing my awfully looking but functional GUI system the other day where I needed to test if button clicking worked. So I made this little app:


And the actually functional part was after you click the button, which calls a function (user-defined) which in turn can perform the actions, I made it create child windows of the testwindow, resized the testwindow and deleted the button when the button was clicked. It looked like this afterwards:


That was it for today, as a side mention, this “demo” is made using DirectX which I’m learning as I go. So don’t expect it to run fast etc. (well, it actually does :)) since its my first time at dx.

Thanks for reading,


The Solution!

Hello Readers!

I’m working on a small TechDemo to show-off what I can in programming for internship purposes.

The TechDemo will use Ogre for rendering, but at an abstract way.

I made a class called EngineGraphicsLayer, which defines some virtual functions including DrawMesh, DrawTexture, CreateMesh and CreateTexture.

I then made a few abstract classes called EngineGraphicsMesh and EngineGraphicsTexture, which are implemented with render specific data too.

So for Ogre I’ve created a OgreGraphicsLayer, OgreGraphicsMesh and OgreGraphicsTexture which all three call their Ogre functions, but this makes it possible to just remove Ogre from the demo and use OpenGL or DirectX. The formats used aren’t ogre specific too, hence I created my own formats called pxa and px.

The pxa is the text version of the px format, which both can contain anything from maps to meshes. (its more an extendable format designed for the demo).

So now, I can just remove Ogre later on and switch to OpenGL/DirectX without the need to change anything else then the GraphicsLayer!

That was it for now,


OpenGL vs DirectX: Usability

Hello Readers!

I’ve been looking a bit into OpenGL and DirectX to see which of both is more usable and easier to learn.

I first choose OpenGL to be the winner on this field because of its not-object-orientated design, but soon found out I was wrong. Few points that I initially saw:

  1. OpenGL is much easier to initialize then DirectX and easier to use because of its no need to use vertex arrays.
  2. For 2D view the camera system is really easy to setup.

But then I realized that I’m a C++ programmer, so object-orientated design is probably better to use. So I looked into DirectX. DirectX seems to handle it much different then OpenGL, you need to create a “root” class and from there create a “device” class per DirectX device you are willing to use. This is pretty easy to use for basic setup, so I just used default parameters with my own HWND. It immediately setup alot of stuff like clear color (which I want to default to black anyway) and camera position. No more positioning the camera at -screenwidth and -screenheight to get 0,0 of the screen at 0,0 of the world. (2d view). One more advantage of DirectX over OpenGL is that it doesn’t use the extensions stuff opengl uses. DirectX has fallback methods when calling stuff thats not available, so it will always work. (The speed is another point).

Even though OpenGL is cross-platform, it does have the regular driver issues that directx doesn’t seem to have.

I’m now more in for DirectX, but if someone has some point I’ve missed, don’t hesitate to speak up!

Thats all for now,


Hello readers!

Long time no posting basically because I didn’t have anything to post!

But, lately I’ve been looking into the Google Android platform to see if it would be possible to port Ogre over.

I soon found out this wasn’t possible since the C++ runtime of android doesn’t support exceptions or RTTI. (exceptions are dependant on RTTI anyway).

So I started to look into how it could be possible, I found out that you could port over newlib as libc (instead of using the android libc) and use the regular libstdc++ then. First you need to compile the compiler so that it could even compile exceptions. So I did that (gcc 4.4.2 compiled as target = arm-none-eabi) and then I started porting over newlib. Since libc from android already defines the syscalls it wasn’t very hard, and with newlib compiled I could compile libstdc++! So I now have a fully featured android compiler with exceptions and RTTI! The only problem is that androids build system is kinda weird, so I’ll have to try to adapt my compiled toolchain to their system so that I can compile android applications to test it out. (I have no idea if its even working at this moment).

If anyone has some suggestions why this can or can’t work, or how to make it adapt to the android build system then please leave a comment. 🙂

Thats all for now,


VS 2010 and Ogre

Hello Readers!

In this article I’m going to talk about Ogre and VS 2010.

I recently downloaded the VC++ 2010 Express Edition beta 2 to try it out, however I got into some problems when compiling ogre. Those problems weren’t related to the Ogre code itself, Ogre has good code :). It were more linker issues, since I didn’t had the dependencies Ogre requires. (Freetype, Freeimage, zziplib (which requires zlib), OIS for the Examples and Ogre not-trunk uses still CEGUI). I’m using Ogre SVN Trunk for people who are wondering. Well, They all compiled very fast and good. (except CEGUI, that one took some time ;)). But I still had linker problems with Ogre, even after having the dependencies. So I started to look into those, it seemed that Ogre uses Freeimage statically and even though I compiled it for static use it didn’t work. So I recompiled Freeimage with different project settings and this time it seemed to do the trick. However, beside the Freeimage linker errors there were others too. zziplib caused a linker error too because the VS project files included with it is incomplete. Some files were missing, so I needed to manually add them to the project files and recompile zziplib. That seemed to fix those linker errors too. Ogremain finally fully compiled (Hooray!). After installing the DirectX SDK I didn’t had any issues with compiling the plugins included with Ogre. I tried running a sample included with Ogre and it ran! (Hooray!)

So, The conclusion here is that Ogre is fully supports VS2010. (Well, from 1.6.4 its fully supported. 1.6.3 didn’t include a patch reported here: Ogre tracker ticket)

Thanks for reading,



Created an Ogre SDK for VS2010, including CEGUI 0.7.1 + CEGUIOgreRenderer. Please note that this still use precomp. CG and DX SDK. So some dll’s might still require the VS2008 runtime.

Link: (Thanks goes to klaim for hosting)

Final layout



I think this will be the layout for the blog that I’ll keep. 🙂

It looks so clean and easy, just perfect.

Anyway, I have been working on a HTML/Flash rendering engine utilizing Mozilla 1.9.1 (Firefox 3.5.3 source)

I’m gonna make the first release + some screenshots soon, so stay tuned!

I hope I have more stuff to talk about later on, not much going on atm. (or much that I can share atm :))