For the curious, here is the test page that I was using to test it. Everything needed is on that page (scripts included). If you have any specific questions about what you find there, post a comment and I'll do my best to answer.

Oh, obviously you'll need to have JavaScript enabled. The page was tested in Firefox, IE7, and Chrome.

Right-click to set the green point, and shift+right-click to set the red point.

I came down, and he explained what he was trying to do. He had a date (08/14/2008) coming in as simple text, and needed to break it apart into month/day/year. So he took the first two characters of his date to get the month, the 4th and 5th characters for the day, and so on. He was then converting those smaller bits of text into numbers ("08" into 8, "14" into 14, etc.). Problem is, he was getting zero for the month.

Some of you may have already guessed that he was doing the following to get his numbers:

var month = parseInt(monthString);

Instead of eight, it was returning zero. As soon as I saw it, I remembered the last time that had snuck up and bitten me in the butt. I changed his code to:

var month = parseInt(monthString, 10);

...and it gave him the eight he expected.

Oddly, most examples of parseInt you'll find on the web completely skip the second parameter: the radix. The radix tells parseInt what number base to use. So a binary example might be:

var num = parseInt('010110', 2);

And of course you could use it to convert hexadecimal:

var num = parseInt('8AFA', 16);

But, you ask, why does "08" come up as zero when you don't specify a radix? Shouldn't it default to 10, like any human would expect?

What it actually does when you don't specify the radix is try to guess based on the text you give it. And when you remember that JavaScript takes quite a bit from C, it starts to make sense. In C, if you start a number with "0x", then it's read as hexadecimal. If you start with a zero, it interprets it as octal (base 8). Really, this is all a carryover from C. "08" has a leading zero, so it's treated as octal, but there is no "8" in octal...it only goes from zero to seven. So you get a zero back. You'll get the same thing from "09". Extra credit if you know what "010" will get you!

This is one of those sneaky things that can really bite you when you least expect it. Awareness can save you, but so can using a JavaScript framework like jQuery, or MooTools. They have helper functions to handle this for you in a standard way. Either way, you should now know how to keep this from biting you in your own code.

Carl is a graphic artist by trade, and a good one to boot. Look to the logo for proof...it's a Carl original.

BROTHER DALE (Most Unholy and Occasional Scribe)

Dale is supposed a tester, but we haven't gotten any testing out of him yet. He is at least partly responsible for the very existence of WordWars. A very random brainstorming session between him and Erryn resulted in a rough plan for the game.

BROTHER ERRYN (Head Technomancer of the Order)

Erryn is the lead programmer for Atomic Monks. In addition to developing for us, he is a full time software developer that uses C++, VB/VBScript, ASP, Javascript, Logo, Fortran, Cobol, and several other archaic languages he deems too painful to mention. At the moment, he is also the webmaster.

BROTHER GEORGE (Most Holy Verifier of Notions)

George is one of our testers, always willing to throw himself at the mercy of yet another computer game. He has a good head for what makes a game fun, so it's good to throw our ideas at him and see if they stick.

BROTHER JEFF (Most Holy Writer of the Holy Word)

Jeff is a debugger for Atomic Monks, and suffers the misfortune of working with Erryn on a daily basis. He is very helpful in tracking down strange bugs, and tests the game a lot. Mostly because he likes blowing things up. The development of WordWars saw him primarily as a tester, but it was also used to bring him slowly up to speed on game programming. He's a real whiz with SQL Server, and will be a primary developer on Rogue.

BROTHER JEFFY (Brother of the Unholy Rage)

Jeff is yet another springboard for our game ideas. He frequently resembles an ogre in a beserker frenzy...and likes it.

BROTHER JOHN (Most Holy Planner of Doom)

John is the "serious" wargamer of the group. "If it doesn't have hexes, it's not a real game" comes to mind. He also possesses the ancient ninja secret of invisibility. Go ahead, try and find him. He is currently serving his country somewhere in the Middle East, but we hope to have him back with us soon, safe and sound.

BROTHER X (Most Holy Monk of Mystery)

We're not sure who this is, but people seem to email him for general questions and comments.

In a previous article, we talked about different timers available to VB6. With the move to .NET, this needs to be updated...or does it. In this article, we'll take a look at timing options in VB.NET.VB.NET exposes some new timing methods: Environment.TickCount and System.DateTime.Now.Ticks.

TickCount is a virtual clone of the old GetTickCount API call and returns the "amount of time in milliseconds that has passed since the last time the computer was started."

Ticks gives you "the number of 100-nanosecond intervals that have elapsed since 12:00 A.M., January 1, 0001."

One could also use the old favorites QueryPerformanceCounter and timeGetTime via the standard "Declare Function x Lib y" format, but we like to do things .NET-style.

TickCount has millisecond resolution, while Ticks has 0.0001 millisecond resolution. One would think, therefore, that Ticks would be a wonderfully accurate way to go. But it, like every other timer except QPC, doesn't have the accuracy to match its resolution. That is to say, while Ticks specifies nanoseconds, its value is actually only updated every 15 to 30 milliseconds. Thus it really isn't any better. (Whidbey will include the System.Diagnostics.Stopwatch class, which looks promising.)

The way around this pitfall in VB6 was to call timeBeginPeriod and timeEndPeriod. With those, you could specify an accuracy of 1 ms to match the 1 ms resolution of timeGetTime. Interestingly, this article at Microsoft mentions that D3DPRESENT_INTERVAL_ONE actually sets timeBeginPeriod(1) "to enhance timer resolution". The catch is, timeBeginPeriod doesn't seem to affect TickCount or Ticks accuracy at all.

Our solution? We added these lines to our engine:

    Private Declare Function timeGetTime Lib "winmm.dll" () As Integer
    Private Declare Function timeBeginPeriod Lib "winmm.dll" (ByVal uPeriod As Integer) As Integer
    Private Declare Function timeEndPeriod Lib "winmm.dll" (ByVal uPeriod As Integer) As Integer

That's right, we're using the old multimedia API calls for our timing, and they're working like a charm. timeBeginPeriod(1) is called in the engine's New, and timeEndPeriod(1) in the Finalize. timeGetTime is used for timing in between.

Anybody else have other experiences with timing in .NET? Drop a comment.

When doing time-based animation, you have several options for tracking the amount of time that has passed between frames:

* Timer Control
* Timer object
* GetTickCount (API)
* timeGetTime (API)
* QueryPerformanceCounter (API)[/list]

The first four are not very precise, and the fourth has a tendency to suddenly jump ahead a few seconds to correct itself. So what's a programmer to do? Cheat.

You can set the timer control to an interval of one, but it's accuracy is at best 55 ms. The timer function only returns hundredths. GetTickCount reports ms, but is also only accurate to 12-58 (depending on OS) ms, and timeGetTime's resolution seems to vary by machine (15.625 ms resolution on my development rig, about 30 ms on another). QueryPerformanceCounter is incredibly precise...but can suddenly jump ahead several seconds to correct itself, and without warning.

On the surface, you might think GetTickCount or timeGetTime might be the way to go. After all, 15.625 ms should be plenty fast, right? Even 30 ms seems good. That is, until you do a little math:

1 sec / 15.625ms = 64 FPS 1 sec / 30.000ms = 33.333 FPS

Note that you might actually draw MORE than 64 FPS, but any animation will only be updated 64 FPS, which is actually noticeable. The discrepancy will cause strange hops and jumps in your animation, since you'll get numerous frames where the timers tell you that no time has passed since the last frame. If no time has passed, no changes are made and the exact same frame is drawn again.

Envision this scenario: 14 ms has passed since the last frame, so the timer tells you no time has passed at all (not up to 15.625 ms yet). The next time around, Windows took a little bit and an additional 18 ms has passed. The timer tells you that 32 ms has passed since the last frame, and your animation plays catch-up. On a slower machine (IE: 30 ms resolution...or even 58), this jump becomes REALLY noticeable. Given that on a decent machine a single frame could be handled in 2 or 3 ms, we're missing out on a lot of potential smoothness. What we really need is a reliable timer with 1 ms precision or so. Fortunately, that's what we have with timeGetTime.

What's that? I said that timeGetTime is only accurate to 15 ms or so? Well, that's true...by default. It's actually accurate to 1 ms, but is updated much less often! Happily, we do have a way to correct this.

    Public Declare Function timeBeginPeriod Lib "winmm.dll" (ByVal uPeriod As Long) As Long
    Public Declare Function timeEndPeriod Lib "winmm.dll" (ByVal uPeriod As Long) As Long

These two API calls were surprisingly difficult to find out about, and they're not in the API-Guide.

At the beginning of your code, you make this call:

    timeBeginPeriod 1

This sets the update period of timeGetTime to 1 ms.

When your program is exiting, you make this call:

    timeEndPeriod 1

This restores the update period of timeGetTime to whatever it was when you started.

Between these two calls, your calls to timeGetTime are actually accurate to 1 ms, and all is well. For most applications, this is more than enough.

In VB6, one way to store data has long been the elderly INI file. Since Windows 95, Microsoft has pushed hard to get rid of the INI file, and move that data into the registry. Many developers are wary of that approach, fearful of contributing to the "clutter" of the registry. So the INI file has survived despite Microsoft's best efforts.

And there are other advantages to an INI file. In Rogue, it holds video settings, key mappings, and more. It's much quicker to open Notepad and change an INI file than it is to modify registry entries. But INI support in .NET falls outside of managed code...so if you want a "real" .NET way of doing this, you need to go to XML.

Let's look at the video section of Rogue's INI file:

[Video]
Height=768
Width=1024
Windowed=1
TripleBuffer=0

And the XML file for the same entries:

<sections>
  <section name="video">
    <item key="Width" value="800" />
    <item key="Height" value="600" />
    <item key="Windowed" value="1" />
    <item key="TripleBuffer" value="0" />
  </section>
</sections>

The structure is easy enough to follow, and is modelled after the INI file structure (different sections, with numerous key/value sets). The hard part of dealing with the XML itself will be handled by the xmlDocument object.

Let's first take a look at the class declarations and the New procedure(s):

Public Class CXMLINI

    Private doc As New Xml.XmlDocument
    Private xmlfile As String

    Public Sub New(ByVal Filename As String)
        ' open xml file for use
        Try
            doc.Load(Filename)
            xmlfile = Filename
        Catch ex As Exception
        End Try
    End Sub

    Public Sub New()
        ' open default xml file for use
        Dim s As String

        s = System.AppDomain.CurrentDomain.BaseDirectory
        s &= Application.ProductName
        s &= ".xml"

        Try
            doc.Load(s)
            xmlfile = s
        Catch ex As Exception
        End Try
    End Sub

doc is the xmlDocument object for the class, which we'll maintain until the class is destroyed. This object stores the contents of the xml file we load in memory, where we can almost treat it like a dataset.

Notice that I've overloaded the New procedure. When given a filename, it opens that xml file. Otherwise, it defaults to Application Name.xml. In either case, if the file doesn't exist, it catches the error and goes on, but remembers the file name that it was supposed to use (for later use).

NOTE: This tutorial assumes you can handle the basic setup of a D3D/DX project. The code included here can be added to such a project for use. You will also have to work with the code a bit, as it is very much designed to work within our specific project.  Also, accompanying source is available in our downloads section.

During the initial development of WordWars, we were using the D3DXFont object; it's very simple and takes very little to set up. As we neared the beta release, the performance became a serious issue. DirectX actually creates multiple polygons per letter to do the text, and does so very inefficiently. This is fine for small amounts of text, but not for long messages (or interactive chat text). DrawText isn't much better.

The only real answer was a prerendered font, or bitmap font. Bitmap fonts have the advantage of being very fast, and they can be painted with whatever texture or mix of colors you like. The WordWars metal set uses a "liquid metal" effect for its fonts, as an example. Unfortunately, it can be tricky to draw them where their baselines align correctly, and manually calculating the width of each letter (much less applying that information when drawing them) can be a very trying experience. What finally made us decide to take the plunge into bitmap fonts was the discovery of an excellent free tool: Bitmap Font Builder.

This tutorial roughly covers the process we use for WordWars' bitmap fonts. Code is also available for download, although it will need a little modification to work in your own program. Our bitmap font engine supports standard D3DXFont alignments (left, top, center, etc.) and a few formatting tags (/COLOR, /NEWLINE). You are welcome to use the provided code for any purpose.

Bitmap Font Builder I stumbled across this on a C++ site, and it can be found at http://www.lmnopc.com/. The creator asks for an email telling him what you're doing with it...and that's the only cost. Seems fair.

Bitmap Font Builder gives you many options, but the only one truly important to this tutorial is the texture size of 512x512.

There is an option to create a bitmap with a full ASCII character set, but the default gives you all the characters you should need. WordWars sets use the latter, with Font 2 set to precisely half the size of Font 1. Create a font bitmap and save the graphic to a tutorial project folder. Record the font sizes you used for later use. Finally, save the font widths to an INI file (in the File menu. Put this file inside your project folder also.

Next, a look at the ATOMFont code module.