Friday 8 July 2016

Realtime Editing of C++ via Runtime Compiling and HotLoading


Once upon a time, I was introduced to a scripting language called Lua, which promised to improve my productivity by reducing my edit-iteration times in return for a small share of my cpu time.
While trying not to sound like a fanatic, this did sound appealing, and in time I discovered that the promise was true - I could indeed expose my C/C++ code to the scripting environment, move some part of my code operations into the script world, and take advantage of the fact that we can edit scripts, save them, and reload them, without ever needing to close and restart our game application.
 Given my background as an Assembly language programmer, I had always known that it was possible to compile new code, import it into a living application, and execute it - essentially, the same promises can be made for C/C++ or any other compiled languages, there is basically always a way to introduce hot code into any environment, within user permissions - while this sounds 'hacky', and it is, dynamically-loaded libraries are certainly not new, and represent perhaps the most legitimate way to achieve the 'impossible dream' for C/C++ programmers: hit save, and see the changes appear in the still-running host application.

Sounds like fantasy? Not at all - runtime compilation of code is the happening thing as far as I am concerned - basically there are three required pieces to this puzzle.
1 - our application needs to be able to monitor a set of (sourcecode) files for changes
2 - when changed files are detected, our application needs to be able to trigger a recompile/relink of any code modules which depend on the affected files
3 - our application should be able to detect when compilation completes, whether it was successful, and if so, be able to dynamically reload the newly-compiled code module.

There's nothing in there which is particularly difficult,  however the Devil is in the Details.
I've got all the pieces working, and should soon have them integrated - and I have several contributing authors to individually thank for that, in addition to my own work, thanks guys, your names have been added to the credits. I am humbled by those who choose to do the impossible things, as much now as I was back when the hardware limits of the commodore 64 were overcome via timing glitches by a rank amateur. Game the system!

Saturday 2 July 2016

CubeMap Visualization/Preview


I decided it would be very handy if I could actually inspect various textures at runtime from within the engine, and chose to use a gui approach to displaying them.
Of course, that's fine for 2D textures, but other types, not so much.
My CubeMap textures, for example, would appear blank, when treated as 2D textures, which they are not. So, how would one go about displaying them, short of applying them to a skybox?
OpenGL does not give us easy access to the 6 individual 'face textures' of a CubeMap texture - we can do it, but it involves copying the image data into a new texture or textures, which is very slow.


A nice fast approach was presented a while back by Scali, whom I credit for my implementation of his solution.





He suggests that we create a flat geometry which happens to have 3D texture coordinates to suit a cubemap, and render it using a shader that samples a cubemap.
Since I was  already using a gui widget to display 2D textures, I decided to take a 'render to texture' approach, and noted immediately that since the projection is orthographic, there is no need for 3D positions - 2D positions with 3D texcoords is what I have used to render the tile geometry to a regular 2D texture, which is then handballed to the gui system for display.
In retrospect, given that the geometry is presented in NDC Space, there's no need for a projection transform either, so there is still room for some optimizing and polish, but it works well enough for the purpose, I'm happy, since it performs well on dynamic cubemaps - I'm now able to view both static and dynamic cubemaps in realtime :)