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:

<p><span class="kwrd">public</span> <span class="kwrd">class</span> NiceTextBox : System.Web.UI.WebControls.TextBox
{
    <span class="kwrd">public</span> <span class="kwrd">bool</span> UseNamingContainer { get; set; }
</p><p>    <br />    <span class="kwrd">public</span> <span class="kwrd">override</span> <span class="kwrd">string</span> ClientID
    {
        get
        {
            <span class="kwrd">if</span> (<span class="kwrd">this</span>.UseNamingContainer)
                <span class="kwrd">return</span> <span class="kwrd">base</span>.ClientID;
            <span class="kwrd">else</span>
                <span class="kwrd">return</span> <span class="kwrd">this</span>.ID;
        }
    }
}
</p>

Now our NiceTextBox works even during post-back scenarios

Here is an early screenshot from the game I’m working on. Obviously all the programmer art you see is temporary and will be replaced by something better

…and I’m going to document the whole process on this blog

It will be a 2D mario-style platformer, whith a twist: the game is set on a physically realistic world. More details to come soon!

I also have a very cool productivity (“serious”) application to release. Testing is complete, I just need to get the boring part done (creating setups, writing web pages…).

It’s finally out! Go get it!

I have updated gljakal’s ToDo to fix a nasty bug that occurred when you tried to create a new to-do list with the AdvancedStatus plugin disabled and the AutoBackup plugin enabled.
This was actually a kind of weird situation, since I always have both the plugins enabled all the time… Turns out that many ToDo users prefer to disable AdvancedStatus while leaving the backup feature enabled….
Anyway, thanks to the kind people who sent the error report! (yes, I do actually read them!)
Also, if any of you happen to send an error report, please do include your email address. This way I can contact you once the problem is resolved. (And you won’t say “this program sucks!” )

You created a database for your application. You designed the perfect table structure, added some smart views and created the coolest stored procedures that make your application work like magic.

But now, you want to back them up together with the code of your program, using subversion or CVS. Afterall, they are part of the application logic.

Better yet, you would like to automate the extraction procedure so that you only need to launch a batch file and your backup is done.

Gljakal’s Sql Exporter does just that: it extracts tables, views, stored procedures and triggers from your database and saves them as individual text files.

Used together with a source control software, you can have a precise idea of what changed between the various releases, just like you do with your applications’ source code.

You can do that with the interface version (shown in the picture) as well as with the command line version, that you can automate to run whenever you want.

Plus, it’s a free download!

Finally!
Today I am releasing the new, improved version of gljakal’s ToDo:




New version highlights:

• Stable, documented plugin support:
  Now adapting ToDo to your needs is easier than ever. Plugin support is great for custom exports and imports, intranet integration, even synchronization with online services!
• New, nicer user interface, with famfamfam’s famous icons.
• AdvancedStatus plugin
  Now you can set a task as 50% (or any %) complete!
• Copy & paste inside the details window
  You could already do this with CTRL-C and CTRL-V, but now there are also cut-copy-paste buttons inside the details window
• Help file
  Now you can press F1 inside todo and actually see something
• All the new features in the preview release

Comments & critics are welcome!

More information at http://www.free-burma.org.

Lately I’ve been playing around with asp.net 2.0.
One of the new "features" of asp.net 2 is the introduction of Naming containers.
While using naming containers can be really useful when using databound controls and standard asp.net coding, they can be a real pain to work with when making extensive use of javascript.
This is because a control declared as

<asp:TextBox ID=”TextBox1” runat=”server” />

will be rendered as

<input name=”ctl00$ContentPlaceHolder1$TextBox1” type=”text”
    id=”ctl00_ContentPlaceHolder1_TextBox1” />

on the client side, thus breaking any script referencing TextBox1 with, for example, getElementById(’TextBox1′).
This behavior is built inside asp.net and is triggered not only when using databoud controls (where it would be necessary to prevent having multiple controls with the same name, for example inside a datagrid), but it is also triggered when using Master Pages, where having multiple controls with the same name is almost impossible.
So, how do we code around it?

The client-side hack

Luke Foust, in his article Using JQuery to Make Asp.Net Play Nice with Asp.Net, explains a couple of client-side methods to let your javascripts select the right element in this situation. I recommend you to read it, because it contains some nice ideas and it also shows off some of the power of JQuery.
While these methods will work for most projects, they still present a couple of issues:

• Generally quite hard to mantain, especially the first hack
• Code bloat. While bandwidth is costantly becoming less of an issue, the generated page will have elements with horribly long declarations
• It breaks existing scripts. You’ll have to re-check and re-code most of the scripts that should already work
• Extra workload on the client. Todays PCs are fast, so this is less of an issue, however it is something you should consider if you have a lot of asp.net controls in your page.

The Solution

Let’s face it: the problem is really on the server, not on the client. Asp.net should not generate those horribly long IDs in the first place, unless we want to. So the best solution is a server-side hack.
How does asp.net know whether or not it should generate a unique id for our controls?
Every WebControl in asp.net exposes a property called (I’m sure you guessed it) NamingContainer, which tells asp.net what’s the parent control for our textboxes, labels and so on. All we have to do in our code is create a new class that will inherit the control we want to "sanitize" and hide that property from asp.net. Better said in code than in words:

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

namespace wtd
{

    /// <summary>
    /// A TextBox control without ugly IDs
    /// </summary>
    public class TextBox : System.Web.UI.WebControls.TextBox
    {
        public override Control NamingContainer
        {
            get
            {
                return null; 
            }
        }
    }

}

Then, in our pages, all we have to do is register our new set of controls, like this:

<%@ Register TagPrefix="wtd" Assembly="app_code"
     Namespace="wtd" %>

and replace every instance of the default asp controls with our own set of controls (a simple find&replace will do the trick), so

<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>

becomes:

<wtd:TextBox ID="TextBox1" runat="server"></wtd:TextBox>

And that’s it! Our textbox will now be rendered like this:

<input name=”TextBox1” type=”text” id=”TextBox1” />

Not only this method won’t break your existing javascript, it also works nicely with your existing server-side code

Update

As pointed out by some of you in the comments, this method does not work in a traditional post-back scenario. See my new article for a possible solution to this problem.