Retrocrawl!

Slowly creating more UI components….. This is made painful due to apparently not being able to override the disabled text color of Swing widgets without reimplementing the low-level paint methods……

I spent most of the day working on motorcycles and playing D&D, so didn't write much code. >_>

However, finished the scrollbars and implemented a scanline effect over the whole game window using a glasspane. Keen.

I used to develop on Sun Java, but switched to OpenJDK a few months ago after hearing that java releases from Oracle from now on are going to be based on OpenJDK anyway.

When I first made the switch, I was displeased to find that alpha compositing (SRC_OVR) was extremely slow (on Linux; not tested on other platforms). The problem turned out to be that Sun java created hardware accelerated BufferedImages of the same format as the display by default, whereas OpenJDK doesn't.

So, solution if any of you run into the same problem:

1. Get your graphics configuration via

   GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration()

2. Use the

   createCompatibleImage(width,height,Transparency.TRANSLUCENT)

   method from the above when you need to create new blank BufferedImages.

3. If you load an image directly into a BufferedImage (with ImageIO.read, for example), use the above to create a new hardware accelerated BufferedImage of the same size as the loaded image and copy the loaded image onto it. This will greatly speed up image blitting.
4. When drawing translucent stuff to the Graphics context passed into paint() and paintComponent(), g.drawImage() is much, much faster than drawing points, lines, and other geometric primitives. If you're drawing a bunch of translucent stuff, it is much much faster to create a temporary offscreen BufferedImage (as above), draw all your stuff to it, and then blit the whole image to the graphics context that's been passed into your paint() method. The scanlines above draw about 100x faster when doing it this way instead of drawing lines straight to the passed-in graphics context. The reason for this has something to do with the BufferedImage being in hardware accelerated video ram, whereas whatever memory is drawn to by the passed-in graphics context for the component being painted is not.

So yea. Sun Java used to do all this for us automagically, via some native libraries that couldn't be open-sourced. OpenJDK doesn't. But other than that, I'm not seeing much (if any) of a performance hit after the switch.

Reskinning some Swing widgets to look more dungeon-gamey. It's rather slow going, as I've never written Swing LAF plugin stuff before, but it's easier than building them from scratch, lol.

No track on the horizontal scrollbar yet. Ima take a break and play some Legends of Grimrock. >_>

Which is an awesome new indy game in the style of Eye of the Beholder and Dungeon Master. Buy it and play it now! :P It even runs great in Wine, after installing some DDLs via winetricks.

Refactoring stuff, consolidating eclipse projects, refamiliarizing with the codebase…

The original plan was to keep the codebase proprietary, initially, and only release sources for the Property building library for use with the editor. Reason being that it would be nice to wait until seeing if there was any money to be made with an Android version, because as much as I like Open Source, it would be nice to be able to quit my day job and write cheesy games all day.

Now I think the whole thing will just get BSDed. Not entirely sure yet, but I think this game will only appeal to a niche market, so there's no money in it. And the split between the proprietary and open-source stuff was becoming a headache of interface indirection.

Also going to roll the single/multi-user/server packages into one package, with an option to just run the server on the commandline without firing up the UI.

The object tree is changing a little, too. Instead of having one list of children, objects will instead have a number of arbitrary “inventories”, keyed by String, and accessed by the object's Properties. This will let us differentiate between what is where in/on the object, and calculate scope appropriately. For example, consider a table with a locked drawer and a long tablecloth. Objects in the drawer are not visible and not accessible (scopeable). Objects under the table are accessible but not visible. Objects lying on the surface of the table are both visible and accessible.

Current issues:

The dungeon blueprints are currently XML and as such are stupidly large, even gzipped (but the code only took a few minutes to write). Probably switch to a binary format, since the files are large enough that hand-editing is not really feasible anyway. Perhaps native java serialization of data classes that will not change, even when the code that they provide the blueprint to build things from does.

The UI is ugly. Well, not ugly, but the “feel” of it isn't appropriate for this sort of game. I might experiment with writing a handful of Swing widgets that look nicer, for the core UI, and pop the editor up in a different window that still uses the regular Swing widgets, since it has a complex UI.

The single player UI↔Engine link pulls images over the UI↔Engine link instead of reading them directly. The result is that you get the “Image Loading” placeholder images for just a split second, even though it's a single-player build.