Simple VERGE3 Map Viewer

I've thrown together a simple map viewer for VERGE 3 maps which uses the libraries I've been building so far. You can get it here.

Mu has updates, and I've added another library:

gameobjects

This demonstration will be the starting point for the simplest map editor imaginable, to kind of cover all the broad strokes of what's involved and one possible route to get there. I'm just gonna kinda throw some code at you every day and then ramble on about it for a bit. Isn't that exciting.

Curiously, Java 1.6 doesn't appear to render the contents of the scrolling pane correctly, so you'll want to compile with 1.5. This means they've either broken things while working on it, or they've decided to change a few rules in regards to how everything is painted. That'll bare bair bere bear some looking into. O bleeding edge, how sharp you are.

The gameobjects library provides classes which model actual game entities that you would use for an editor or an actual game. Right now, we've got the basics: a map, a map layer, and a tile.

Most of the action goes down in the GameMapFactory class. This class loads up a VERGE3_MAP and its associated VERGE3_VSP, takes what it needs, and packages it all up in a GameMap. At that point a simple call to to the paint() method and you've got a correctly rendered VERGE 3 map!

I included bumville.map for testing, and you'll notice at the top you can see magenta through the cracks in the waterfall. This is indicative of many games which were originally developed in 8-bit and then got ported to a higher bit-depth.

The "correct" way to fix this would be to either create a new tile intended for the base layer, which has no transparent regions, or to put a black tile on the base layer and the transparent tile on a layer above it.

Another more hackish way to fix it would be to render the base layer transparently, but initially fill the screen with a default color, such as black. Yet another would be to render base layer tiles in one of the compositing flavors where you specify a background color and transparent pixels receive that color. Both are slower than the aforementioned solutions though.

If you wanted to maintain speed you could generate duplicates of each tile, where one contains no transparent pixels, and another does not, and use the "solid" version for base layer rendering, but that eats up a lot of memory without cause!

Ultimately, if you are developing games in the higher bit depths, I'd say it's proper form to only use tiles with transparency on overlay layers.

I've kept up the interfaces-or-death mantra, and it leads you to some interesting places.The way I determine whether or not a tile in a layer is transparent for overlay layers is interesting, for example. You should take a look!

Similar shenaniganry ensues when rendering MuBitmap objects, since they have no persistent state, such as position. They are MuPaintable, and the paint method of that interface does not take coordinates, so they end up having to come from elsewhere. Using the translate method of Java's Graphics object was a stroke of pure genius. And also it seemed like the unlamest way to do what I wanted.

Back to the map factory, you'll notice that the GameMapImpl object does not take the rendering string into account. That's because I'm effectively "precompiling" the order when I use the factory to pump out a map. There's really no need to parse it out over and over, even if it is a trivial matter to do so. Removing that cumbersome logic from our rendering loop helps us focus on the rendering code alone.

It also speaks to the best practice of making methods, classes, or whatever tightly focused on a single operation so that you can achieve good "separation" between the various elements of your framework. A game map's painting method should be focused on painting the map only, not parsing the render string. This leads to clearer code, which is easier for others (and yourself) to maintain on down the road.

What else. The inner GameTileIterator class in GameMapLayerImpl was a fun little exercise. Interfaces get to be really fun once you start using them all willy nilly. It's great how you can just go to town on the guts of your various implementation classes, passing this one or that one to logic methods that deal in interfaces only. No crazy tweaking of said logic methods for each new incarnation. It all just magically works. Assuming of course your code isn't buggy!

Potential additions for tomorrow are tile animations and a faster renderer. You'll notice after loading some of the larger VERGE 3 maps that it gets pretty slow while scrolling around. That's because it's trying to render every single tile of every single layer at every movement.Even when the majority of them get clipped, that's still a lotta wasted cycles! Or maybe I'll discuss MuBitmap versus MuSprite...

The possibilities will vy for power... in a fight to the death!