Archive for December, 2006

RTF to HTML converter

I tried to find a lightweight app that converts RTF text to HTML text, mainly so that I could post formatted code from Visual Studio on the web. Unfortunately, I couldn’t find one and doing the conversion through MS Word is way too time consuming, as I would have to save to an HTML page, then go and extract out the relevant HTML. So I ended up making my own …

Rtf2Html Version 1.00
(Requires .NET Framework 2.0)

Note: The only formatting options handled are: text color, bold, italic, underline, and strike-thru.

The namespace-enum trick

Enums in C++ can be a pain in the ass once a project starts to grow in size. Enums are typically defined globally or within a fairly wide scope such that there’s usually a pretty high probability that you’ll get name clashes between enums (remember that in C++ the enum block is not a scope, so enum members must be unique across multiple enum declarations) unless, like with the DirectX or Win32 APIs, you give your enum members names which are detailed, prefixed, and very ugly looking. For example here’s some of the enum members for Direct3D render states:

typedef enum _D3DRENDERSTATETYPE {
    D3DRS_ZENABLE = 7,
    D3DRS_FILLMODE = 8,
    D3DRS_SHADEMODE = 9,
    D3DRS_ZWRITEENABLE = 14,
    D3DRS_ALPHATESTENABLE = 15,
    ...

Truthfully, the DirectX enums aren’t that bad, and most programmers (including myself) have seen worse, but is there a better way?

Recently, I’ve discovered a cool trick that I’ve started using in most of my C++ code. Just wrap the enum declaration inside of a namespace. So, as an example, you might have something like:

namespace Color
{
    
enum Color
    {
        Red,
        Green,
        Blue,
        Orange,
        Purple
    }
}

… and, because of the namespace wrapper, it’s also perfectly valid to have the following within the same scope as the code above (note the Orange enum member in both declarations):

namespace Fruit
{
    
enum Fruit
    {
        Apple,
        Orange,
        Purple
    }
}

You access an enum member by simply resolving the namespace first:

Color::Red
Color::Orange
Fruit::Orange

Simple and elegant!

The only oddity is that to declare variables that are of the enum type, you have a declaration that looks like:

Fruit::Fruit

or

Color::Color

… but overall I think that’s a small price to pay.

I am very surprised that this little trick is not mentioned much and in the few places where I have seen it mentioned (such as here), it is glossed over and its significance is not really highlighted.

EDIT: Note that C++11 introduces scoped enums which renders this trick unnecessary, if you have a compliant compiler.

LCD monitors, resolution dependence, and aspect ratio issues

A few days ago I started thinking about 2d game engines and games that run at fixed (and typically lower) resolutions (e.g. Starcraft). Many older 2d games have no choice when it comes to running at a fixed resolution b/c if the game ran at a higher resolution one of 2 things must occur:

(1) a larger portion of the game world is rendered. This can break many of the gameplay mechanisms of the game and/or decrease the difficultly of the game as the player is able to see more of the game work w/o moving the camera. This can be especially disastrous for multiplayer games where different players may be running the game at different resolutions. Another downside here is that units (which are 2d sprites), although still in proportion with the game world, appear smaller. It should be noted however that some games (typically strategy games, where you have a fog-of-war, such as Age of Empires) have supported multiple resolutions in this way.

(2) The second option is that the game’s rendered output is scaled from its original resolution. The higher the new resolution and the lower the original resolution, the worse the game looks. This is what’s done by LCD screens, since they have a fixed resolution.

Well thinking about 2d games and the fixed resolution problem got me thinking about how a modern “2d” game engine (2d only in terms of gameplay), targeting contemporary hardware, could be designed so that it could run at any resolution? Well if all the units are 3d models, the sprites used are for things such as particle fx – which will typically scale well, and the environment is either a 3d terrain or scalable 2d tiles, the resolution issue seems somewhat solved, as you can go to a higher or lower resolution gracefully … well, yes and no, there’s one other thing you have to consider that will affect any type of rendering engine …

As LCD monitors continue to grow in popularity, the new models have a certain oddity about them; they don’t conform to the historically popular 4:3 aspect ratio that many developers have depended upon. The popular resolutions now seem to be 1280×1024 (5:4) and the wide-screen resolutions such as 1920×1200 (16:10). Of course if you want to target, or eventually target, output to an HDTV you also have to worry about the HD resolutions, 1920×1080 or 1280×720 (16:9). The problem with multiple aspect ratios is that, unlike multiple resolutions at a given aspect ratio, you can’t gracefully go from one aspect ratio to another and retain the look of what your rendering, you have to letterbox/pillerbox the output, stretch the output, or modify the field-of-view (FOV).

Modifying the FOV seems to be the “right thing” to do, but this can lead to problems similar to (1) above, where players with wide-screen monitors can see more of the game world than those with normal monitors, giving them an unfair advantage.

So what’s the solution? I’m not sure. I came across this forum thread a while back (the only one I could find thru google) where 2 posters reply that the stretching really isn’t noticeable (I don’t have a wide-screen monitor, so I can’t give an opinion). FOV may or may not be an issue. Some people find letterboxing and pillarboxing annoying (pillarboxing does annoy me, but I’m comfortable with letterboxing).

Finally, one solution not mentioned is smart stretching. The HDTV my parents have does a smart-stretch on standard definition content, where it, I think, stretches the pixels further away from the center more than it does the pixels that are closer to the center. It actually looks really good and greatly minimizes (to the point where it’s not noticeable) the “squashed-down” look you’d get from running a standard stretch algorithm on a 4:3 picture.

That’s all for now 🙂