Category: Software

I made a quick YouTube video of my graphics test program. Whee, it’s like the space age.

The neat thing (at least to me) is that the cutter beam from the game is actually a texture that is stretched and rotated to the location of the mouse. That solution seems to work really well.

Java has some cool features, but one thing I really like are enumerations. For my project I need a damage type, so I made a base class for it:

public abstract class Damage
{
    public enum Type
    {
        NORMAL("NORMAL"),
        FIRE("FIRE"),
        COLD("COLD"),
        AIR("AIR"),
        EARTH("EARTH"),
        POISON("POISON"),
        CORROSION("CORROSION"),
        ELECTRICAL("ELECTRICAL"),
        BLUNT("BLUNT"),
        PIERCING("PIERCING");

        private final String desc;
        private final String user;

        /**
         * Construct the enumeration with the description given
         * @param desc The description of the type
         */
        private Type(String desc)
        {
            // save the description in all uppercase
            this.desc=desc.toUpperCase();

            // the user first character is upper case
            // make the characters after the first lowercase for the user description
            this.user=Character.toString((Character.toUpperCase(this.desc.charAt(0))))+(this.desc.substring(1).toLowerCase());
        }

        /**
         * Get the description of the type
         * @return A string describing the type
         */
        public String getDesc()
        {
            return desc;
        }

        /**
         * Get the user-readable description of the type
         * @return A string for users describing the type
         */
        public String getUser()
        {
            return user;
        }

        @Override
        public String toString()
        {
            return user;
        }

    }

    /**
     * Get the damage for the damage type
     * @return The damage caused.
     */
    public abstract int getDamage();

    /**
     * Get the damage type for the damage
     * @return The damage type
     */
    public abstract Type getType();

    /**
     * Get the type of the damage given a string describing the type
     * @param desc The description of the damage type
     * @return The type of the damage
     * @throws IllegalArgumentException if the description has no match to a damage type
     */
    public Type getType(String desc) throws IllegalArgumentException
    {
        // if the description is empty, then make this normal
        if(desc.isEmpty())
        {
            return Type.NORMAL;
        }

        // loop through the values in the damage type enumeration
        // using the enhanced for loop after changing the enumeration to an array
        for(Type damageType : Type.values())
        {
            if(desc.equalsIgnoreCase(damageType.getDesc()))
            {
                // matched the damage type, return this type
                return damageType;
            }

        }        

        // no match
        throw new IllegalArgumentException("Cannot match damage type to description "+ desc);

    }

}

This base class is really just two things:  an interface to get the damage amount and type, and a container for the enumeration I use for the damage types. The neat thing I find is how I can match the damage type easily to a string by using Java’s enhanced for loop form and converting the enumeration to an array with the values() call.

That enhanced for loop may be old hat to Java programmers, but coming from a C++ world it is very cool. I am sure it boils down to the same-old-thing I would write in C once it goes through the byte code, but it is much more readable. Why not be able to iterate through the values in an enumeration? It is just intuitive and very usable.

But the really neat thing is how enumerations aren’t just for numbers anymore. I like being able to attach multiple data to the values in the enumeration. So it makes the enum type name a misnomer, but it is really useful. Just about every beginner Java book starts with an example of this a few sections in, and I believe that this is so they can show off this powerful capability to any C programmers delving into the language.

Well, I’m convinced. Programmer jealousy is a wonderful thing…maybe this will show up in C++ sometime? Strongly typed enumerations are not enough!

I always thought that using the cookbook method was an odd approach to programming. The idea is to abstract some of the difficult things to do at the low level so you can get on with the making instead of reinventing string stuff for the tenth time or whatever. This is done on grand scale with things like DirectX and OpenGL or even more intensely with something like BlitzBasic. Who wants to deal with low-level graphics programming when you could be making your games?

The main drawback of programming like that to me was that you can end up not understanding anything about the topic you used the cookbook for. It makes weird problems you inevitably encounter nearly impossible to debug. But for some things, you can’t avoid that; I certainly don’t understand how OpenGL triangle strips end up making nice objects on screen, and I never will. But now I find myself with an entire language apparently devoted to cookbook programming for nearly everything. That is, Java.

At least to me it seems like cookbook programming. You could (and people do) approach C++ the same way, for instance, by using a thing like Boost or wxWidgets (especially cross-platform). But I always found the documentation to be either so hard to understand (in the case of Boost) or so chaotic (in the case of wxWidgets) that I ended up having to really look at the examples and classes I was using and really understand them to use them anyway. Don’t believe me? Take a look at one of the coolest things in Boost:  the multi-index container. Awesome piece of code, but it is hard to get the hang of. The examples don’t cover the things it is really useful for; the examples are mostly for things that other lists already do, or too simple. So you have to dive deep in the tests and the source code to find out what is going on. That’s not really cookbook-style to me; it just saves me the trouble of actually writing the code, but I still have to know what’s going on.

Well, Java may not have a multi-index going for it, but it has a ton of stuff. And the kicker is, it is basically all built in, especially if you use Eclipse (see red squiggly, hover over, import the missing bits). One of the big hurdles to Boost or any other C++ library is shoehorning it into your project and build workflows. It can be a real pain to do. Java is just…there. And Boost/wxWidgets/Poco/etc. are all missing big chunks because trying to do academic things mixed with GUI seems to be a no-no. This is compared to Java, which is a pretty complete solution.

So by having a ton of stuff, you can Google even weird problems and the solution is there. Just cut and paste, and you are cooking up a new program. This is definitely a good thing, just like Boost is; no need to reinvent the wheel. But I feel like I am missing out on the nuts and bolts of Java, which I guess is the idea. It is worrying, because I feel a bit like I am working without a net.

That is the big drawback to me so far: when something doesn’t function as expected or is just too limited. I always had the opportunity to dive into the other open source libraries if I needed to see exactly what weirdness is going on or see the lack of functionality, and often I could fix the problem and submit the bug or modification to the project for a change. Bureaucracy aside, the fix or enhancement would eventually get in, but I could patch things on my side for our next release (I only ever used licenses that allowed that for obvious reasons) and everything was good to go.

I don’t know of a parallel in Java. If something doesn’t do what I need, then I don’t have a way to add in a modification that will do it, and bugs mean you just have to wait. Today’s issue for me is how the java.awt.Color object works.

Basically, it lacks the ability to multiply the color contained therein by either a scale factor or another color. To do that you have to release the previous instance and make a new one, which in my case could mean a lot of references tossed to the garbage collector, and it is slow way to do such a simple thing for thousands of color nodes anyway. That means the object is useless for things like color shifted bitmaps or lightening/darkening the color. There is a function to brighten or darken the bitmap, but it is by a fixed factor; you can’t specify the scaling yourself.

This is a nuisance, because what I would like to do is declare my own bitmaps that are arrays of Color objects, and then write their RGBA values directly to a BufferedImage and then blit said image to the screen. Instead, I either have to use arrays of integers for my bitmaps or make my own flavor of Color and use that.

Well, I chose the second path, and for my own purposes named it FastColor. It didn’t take long to write it, but it seems inelegant. Java gives so much, but when you are out of luck the improvisation feels tacked on. You don’t have a net with Java, and I don’t know where I will go if something doesn’t exist, and I can’t find a way around it. I always had the option to rewrite things at low levels if I needed to. It makes me want to rein in my ambitions when working with Java. I suppose that working low level in C/C++ is what the JNI is for…but I usually only need to tweak something, not rewrite the whole thing!

Oh, and I made good chili this weekend. The analog type. From a real cookbook.

I suppose all programmers have code that they have carried with them for a long time. I have a bit of code that I have been developing for decades, from nearly the first programs I wrote.

I don’t remember where I got the idea to make this kind of library, but I remember when things started to look like the current version. I ordered a program called OpenDoors from a programmer named Brian Pirie in Canada. I hope that’s his name…this was a long time ago.  To wit, the purpose of OpenDoors was to abstract the modem/BBS interface so you could write software to work with old school bulletin boards. Definitely pre-everyone-has-it Internet.

Anyway, to work with OpenDoors I couldn’t really have much debugging output on screen, since I had it filled up with all of my awesome ASCII art.  So I took some code that I had been using while learning Pascal and C that wrote printf-formatted text to files for debugging and adapted it to OpenDoors.  Now I had code that would write to a file given print statements with a macro called dpr(), and it would even transmit that over the modem! An even nicer touch I had was that this macro was only a print statement if I had a #define DEBUG in the file it appeared in.  Otherwise, it was a C-style line comment. This meant that I could completely remove the printing from the runtime version of the code by taking out #define DEBUG in whatever files I wanted.

Over the years, this facility evolved, mostly in my professional applications in my old job. I added capitalized versions that would print regardless of the #defines around, versions that would print out the line number, file, and time, and a version that had logging levels (plus bunches of other neat features). The log levels were nice to have too; you could take out the printing at only the cost of an if comparison to the current log level.

But all of these previous versions started as Pascal, then evolved to C, and eventually evolved to use C++.  I spent a lot of today making a Java version.  Unfortunately Java doesn’t really have conditional compiling as far as I can tell, but I want to find a way to easily take the printing out (I have some ideas).  I always thought of that as the nicest feature of the fdebug library.  For Java I think I will have to be satisfied with log levels.

I went ahead and named the package project Logbook, but I didn’t really want to. I always wanted to keep the name of the library fdebug (that’s file debugger, btw) but for various reasons we changed it to logbook later. What a boring name…no abbreviations or hidden meanings or anything.

Java has a lot of conventions about capitalization/camel case, and I thought Fdebug looked silly.  So Logbook it is. Oh, fdebug, we hardly knew ye.

I should mention that I basically recreated Logbook from scratch in Java in about 2 hours. I was a little ashamed, or scared maybe? Eclipse can write a lot of code for you, which seems to work a lot better than the last time I did anything significant with Eclipse. It is really awesome to have the compiler warn you that you forgot to handle a particular exception, but to make the Twinkie completely fried in luscious batter the editor will let you surround the offending area with a try/catch in one action.  That’s neat, and it works better than something like Visual Assist X.  That’s a great program, but C++ keeps it from doing the awesome things that Eclipse can do when you are using it for Java.

Completely off topic:  I have never loaded up a game that is so playable, and yet so rife with bugs as Dead Island. Generally when a game has this many problems there are intrinsic flaws in the design that make it all around a stinky affair. But Dead Island is fun, and it is double, triple, or quadruple fun in multiplayer. If you can get the program working…and then if it is working, there are lots of little weirdnesses and problems that can be frustrating.  I am glad people have kept with it, because the game is a really cool thing and the more people keep playing it the more fixes the developers will upload. I just hope that the rage out there keeps simmering until they can fix the game. But there are too many good things coming out in the next few months for me to keep my hope alive.

XML is a powerful tool.  Having the ability to store data in a text file using a method that resembles the way you would do the same thing with data structures and containers in code is a big deal.

Or, at least I see it that way.  Before I heard of XML, every implementation of data storage or retrieval involved me writing up some code (hopefully cutting and pasting from some other similar program) and writing binary to the data files.  This inevitably includes writing some sort of viewer program, which takes even more time.  I am not one of those people who can look at a hex dump and see the blondes in the Matrix.

With XML technology, your text editor is your viewer.  And it’s quite simple to think in terms of XML.  I can visualize the database I need and the XML layout and support code is nearly already written in my mind, since the technique lends itself to hierarchies of data. Hierarchical databases are nearly all I use anymore, and that makes me wonder.

I tend to fall in that group of people who finds a new toy and proceeds to try to solve every problem with it.  Just like the old Maslow’s Hammer: “if all you have is a hammer, everything looks like a nail.”  I usually have lots of tools in addition to that hammer, but I use the hammer anyway.  Because it’s new, and it rules.

I think I am falling into that trap with XML.  I can’t really remember what I did for database design before I got the hang of XML.  Now everything I come up with is a big top node that contains a series of nodes that themselves have a bunch of nodes, ad nauseam. So the software that parses that collection of nodes looks just like the XML:  a map of the first tier, and then that tier is whatever container fits it best until I get to the bottom of the DOM tree and find that nugget of data I am looking for.

Are relational databases so far behind me? I think that I may need to step back sometime and think if XML is a good solution for everything (or perhaps anything).  I am probably permanently infected; as soon as I typed relational database I tried to think how I would write XML that could describe a relational database.  But those tend to be better stored in flat files, and I know a relational database can be described in XML, but relational databases are flat.  Describing a relational database with XML is like putting tighty whities on a horse.  Horses don’t need underwear, don’t like underwear, and they really stretch out the leg holes. How about a nice saddle?

The problem I am tackling is like this:

A Maze consists of Floors that each contain one or more Pieces, each of which consists of one or more Chunks, where a Chunk has various numbers of Rooms, Corridors, and Vaults.  So I lay this out mentally in XML like:

<maze>
    <floor>
         <piece>
             <chunk>
                 <corridor/>
                 <room/>
                 <vault/>
             </chunk>
         </piece>
     </floor>
</maze>

It seems logical, and I know what attributes I need for each type of element, what data structures I would parse those XML elements and attributes into, and what containers would give me the fastest search times for each element type given how I will be using the data.

But I worry when I see a hierarchy in my mind these days.  Am I just whacking the problem with my hammer?  Maybe there is a crowbar around here somewhere…