gljakal.com – blog

At the moment, all the menu text in the game is stored in separated images – one for every menu item. For example, this is the “New Game” button:

Of course, storing each menu item as a separate picture is not very efficient, so I decided to add text rendering capability to the game.

My first choice was the OGLFT library. It’s a really easy to use and complete OpenGL text rendering library based on FreeType. I quickly added it to the project, and it worked perfectly, until I closed the application and got a nice “Access violation” exception 🙁

After hours of tinkering, I finally found out that the error was related to the FreeType library. For some mysterious reason, just trying to open a font file with FreeType caused the erroneous behavior.

So, since I couldn’t use FreeType, I decided to create a text rendering class myself, based on the font texture approach.

In order to create suitable font maps, I modified Irrlicht Font Maker to create non-irrlicht-specific font maps. I also added a couple of options and the ability to export the control points as custom text  or in a handy binary format:

But that’s only the first part of the story: once ready, I took my new text rendering class for a test drive and, with much surprise, I discovered that the program triggered the same exception it did before! OH MY!

After an hour or so of debugging, I finally found out the root cause of the problem: a single call to fopen to read the font control points was enough to send the program to C++ hell.

I have since replaced all the standard C file IO functions (fopen, fread, …) with the modern C++ equivalent (fstream) and now the program ends with no errors.

In the end, I’m happy with the new font rendering method, as it gave me a chance to clean up and improve Irrlicht Font Maker, however once again I feel like I misplaced my foot in the minefield that is programming in C++ 🙂

In my previous article, Getting rid of the Naming Container in asp.net 2.0, I explained a method to override the extended naming functionality provided by ASP.net in order to create client-side controls with better IDs.

I was however informed in the comments that by overriding the NamingContainer property the control loses the ability to read its value from the PostBack data.

Since the controls I developed were not meant to to be used in a postback scenario, this wasn’t a big problem for me.

Fast-forward a couple of years and here I am, wondering why post back does not work in one of my projects 😉

Anyway, I looked at the link provided by Alex, where Rick Strahl talks about overriding the ClientId and the UniqueId properties instead of NamingContainer.

In a standard web control, the two properties ClientID and UniqueID are mapped, respectively, to the id and name properties of the HTML control generated.

Since most (all? ) JS frameworks use the id property to access the varius HTML elements and the PostBack mechanism uses the name property, I think the “best of both worlds” solution is to only override the ClientId:

public class NiceTextBox : System.Web.UI.WebControls.TextBox
{
    public bool UseNamingContainer { get; set; }
    
    public override string ClientID
    {
        get
        {
            if (this.UseNamingContainer)
                return base.ClientID;
            else
                return this.ID;
        }
    }
}

Now our NiceTextBox works even during post-back scenarios 🙂