Packing it up

I got pretty busy last week trying to implement a tutorial on 2D text.  The experience was successful and I’ll be posting some results soon.  But the more I got into it, the more I saw possibilities to expand on it and I pulled out some old code from my OpenGL 2 library and started to geek out on an actual tool to map and pack 2D font textures (or any textures actually) into larger maps.

Discussing the “best” algorithm for packing is akin to Ukrainian mothers discussing their families’ Borscht recipe: everybody think theirs is the original and the best (or so I’ve been told by Ukrainian acquaintances).

There are different ways of naming the problem (whether it’s texture packaging or The Knapsack Problem), but pretty much everyone agrees that finding some kind of optimization to it is NP-Hard, which means that finding a fast solution to pack all your textures in the most efficient way will take more time that you’re willing to spare to code, test and execute this beast.  Which is why most lazy persons like myself use one that “just works” and move on.  One day, if the solution causes any trouble, then we put time and money on finding a better solution (and a chance of having a slightly better efficiency rate, say 3% like some guy I read earlier on Stack Overflow).

Basically, I like this developer’s solution.  It’s simple to understand and code and it gives great results, as you can see in the image below.  This was done with a set of 3 tiles ordered randomly; the recursive algorithm aborts when it meets it’s first tile that cannot be placed.  And I’m sure we could squeeze a few more green ones.  This was a simple test and already, this looks fine.  But in a real-life situation, tiles are first sorted from biggest to smallest before packing.  And for those that wouldn’t fit, it would be trivial to implement some sort of overflow tile.

See you next time when we discuss 2D text and see how all this fits together.

pack

Fiat lux

Unlike God in Genesis, I had to sort out my own chaos before summoning light.

Tutorials are not meant to do 100% of the job for you. But there are some aspects of OpenGL that remain puzzling even when they are are presented to you for the umpteenth time. In this tutorial, the “answer code” is filled with buffer creations and variables assignments that either

  • mimic more or less the flow of the tutorial.
  • are simply patched on the legacy code of previous tutorials.
  • have their own little section (in some sort of library) away for the main flow .

While the work is cut out for me in order to understand the math of lighting, it’s another business to actually create something that will be re-usable and useful in other circonstances without someone taking you by the hand every time. As I said before, since I’m not using most authors’ windowing system, I had built my own patched up version of their tutorials that fit my own window creation with mouse and keyboard control.  As I was failing this tutorial (and others for reason I’ll have to investigate)  I spent a couple of days just sorting out things in proper places for understanding how OpenGL ticks. And that bring me more satisfaction that an individual rendering (well, the rendering part is nice, too. 🙂 )

The code now looks more like the narratives I like to put in code when I create some class for future reading for myself or others.

  1. Generate all the necessary buffers for a given program.
  2. Set all needed Uniforms for this program.
  3. Collect data, bind it.
  4. Set the program as current and render.

The fact of creating buffer and setting all uniforms so early at this stage helps me understand the purpose of this program: what I need as resources, what to set, what to calculate and abstract that knowledge in a general point of view.

(FYI: programs, in OpenGL, are not individual binaries – like a program that you run on your computer – but a set of pipeline rules that objects – i.e. their vertices, normals and uv texturing coordinates  – go through before showing the final results on the screen.)

Enjoy the results featuring Suzanne, the famous Blender monkey.

no_lighting_thumb

no_lighting_wf_thumb

with_lighting_thumb

with_lighting_wf_thumb

Interfacing in 3D space

Nothingsdl_interface_thumb much today other that working on the interfacing.  Having mouse control (mouse move, wheel and button click) and windowing is not only necessary for a working game but the sooner you get it set up, the better the creative and debugging sessions go. SDL provides all this and more so that once you get the hang of it, you can’t live without it.  Lots of tutorials and demo rely of FreeGlut or GLFW, but it’s not hard to port them to SDL.  Even the OpenGL Superbible is using a custom event-driven application framework based on different tools, but I’m porting everything back.

Speaking of which, this book has a great tutorial on rendering thousands of  objects (say, a field of grass or a corona of asteroids) with few OpenGL calls.  Go check the video at their site to see the results.  Shaders are so über-powerful.  Today’s example is a similar lesson involving 4 quads (meh!) but it also demonstrates a simple Model-View-Projection with mouse control on both X and Y directions and mouse wheel for field of view (FOV) variation.

Baby steps.

I should be working on lighting soon.  Let’s just see where this leads to, first.

return top