Archive for the tag: programming

Lost Animations Recovered from Hex

Developer's Cave, Island Forge No Comments »
I had inadvertently placed a hex upon my avatar animation sequences when I chose to number the frames in hexadecimal. Several avatar animations, including all of the attack and death sequences, had been cut short. The logic for loading animation frames counts in hex [00,01,...,09,0a,0b,...]. However, the external resources were numbered in decimal [00,01,...,09,10,11,...]. After frame [09], the loading logic didn't find frame [0a] (because it was numbered [10]) and stopped. Consequently, several frames of animation (up to 8 for some death sequences) were being ignored. Now that everything is numbered in hex, the attack and death sequences are a bit more ... animated.

Thread Monitoring with java.lang.management

Developer's Cave, Island Forge No Comments »
I recently delved into the java.lang.management package, in order to measure thread activity in my Potential RPG server application. Tools like VisualVM offer real-time probing, but I also like to have my applications produce their own statistical results. In this case, I'm logging CPU time (and a bunch of other stats) from my server application, which I use to produce performance charts (using the JFreeChart library). In java.lang.management, OperatingSystemMXBean reports the CPU time of your application process. The ThreadMXBean class reports the CPU time of each active thread. CPU time measures time spent being executed by the CPU. Contrast this with wallclock time, which may include time when your process is swapped out for other work. In addition, you can query user time, which is the portion of CPU time spent executing your application, as opposed to performing system time events such as disk I/O. Java tip: How to get CPU, system, and user time for benchmarking is an excellent article on using these classes. In particular, notice that ThreadMXBean does not report on threads that have died. To avoid missing thread activity, it is important to poll for thread activity at some granularity. I'm trying a 500ms polling rate, but my initial results imply that the thread I'm using to do this polling is using a significant percentage of the overall CPU time. Any thread activity missed by the polling granularity can be reported by subtracting the sum of sampled thread time from the total process CPU time. By increasing the polling rate, you can catch more short-lived threads, at the expense of more overall CPU time spent polling. In some cases, I'm using a thread pool (Executors.newCachedThreadPool()). By default, each thread will have a unique name, but this is not a requirement. By passing in a custom thread factory, I can name all threads that perform a similar service the same. In my thread polling routine, I add the CPU time of each thread by name. This way, even if several threads are actively performing some task, the CPU time is reported for the group. By monitoring my thread activity, I've found which parts of my application are working the hardest. I've also identified a few rogue threads (probably quick-and-dirty cases in which I extend Thread itself), which need to be wrangled. These might account for the CPU time not being captured by my polling. Overall, these thread monitoring results give me a good idea where to improve performance.

Using JTextArea in a JList

Developer's Cave 6 Comments »
JTextArea is a convenient Swing component to use when word-wrapping is needed. To display a list of multi-line messages, for example, the obvious solution is to use a JTextArea as the ListCellRenderer Component for a JList (within a JScrollPane). However, you will soon find that the text often does not end up word-wrapped as expected. After reading post after post of mystic incantations, none of which actually seem to fully work, I present my solution for using a JTextArea in a JList: Don't. Read the rest of this entry »

Comparable Max Function

Developer's Cave No Comments »
Here's a helpful method for returning the maximum of two Comparable objects. Do the Java APIs provide this somewhere?
/**
 * Return the <i>maximum</i> of the two arguments. If the arguments 
 * are <i>equal</i> (as defined by the Comparable contract), the
 * <i>left-hand-side</i> argument is returned.
 */
public static <T extends Comparable> T max(T lhs, T rhs)
{
    return rhs.compareTo(lhs) > 0 ? rhs : lhs;
}

100k SLOC

Developer's Cave, Island Forge No Comments »

This morning, I noticed that my SLOC (Source Lines of Code) chart (in the sidebar of this blog) has breached the 100k mark (100,297sloc to be exact). That count is due to drop with the pending removal of some unused tools, defunct data structures, and legacy logic. Still, I thought it might be interesting to do a quick breakdown of the basic components:

Potential Games RPG SLOC Breakdown

The categories are:
  • core: Networking, storage, and application framework libraries
  • gui: Graphical User Interface implementation libraries
  • client: RPG Client application (67% of which is client-specific GUI code)
  • tools: Development helper applications
  • server: RPG Server application
  • other: Data structures, rules logic, and other game-supporting code

Why is LinkedList.clear() linear?

Developer's Cave 4 Comments »
I was just perusing the Java source code (because I don't read the morning newspaper), when I discovered that java.util.LinkedList.clear() is implemented to operate in linear time. The documentation does not specify its order of growth, and I intuitively assumed that a linked list clear implementation would be a constant time operation. Could this be an artifact of early Java development, leaving a legacy of poor performance? The remainder of this article explores the potential to significantly improve application performance when using the LinkedList.clear() operation. Read the rest of this entry »

The Case of the BlockingDeque Misstep

Developer's Cave, Island Forge No Comments »
First: Unless you're a Java developer who enjoys weekend threading and locking studies, don't read this, unless you want your brain to melt. I'm primarily writing this for my own sake (because I am a Java concurrency junkie). Second: There is nothing wrong with LinkedBlockingDeque. It follows all the proper behavior of a concurrent collections class (of which I'm a big fan). The situation documented here boils down to a classic concurrency scenario I simply didn't take into account. The Exploit: The impact to my MMORPG was that a player could force his/her character to translocate over stretches of non-navigable terrain, such as bodies of water. This would constitute a major exploit. To add to the mystery, it only happened on my development platform, not on the alpha testing network (even over the same LAN). Read the rest of this entry »

Keyed Access Pattern

Developer's Cave 2 Comments »
In a previous article, I described a Concealed Controller Pattern, which allows Java classes to be packaged separately, while maintaining access control to certain sensitive methods. In today's article, I discuss the shortcomings of Java's package capabilities and present a simple pattern (the Keyed Access Pattern) for overcoming one case. Read the rest of this entry »

Happy No-Longer-So-New Year

Island Forge No Comments »
I just stopped coding for a moment and realized we were a month into 2009. I thought I'd better let everyone know that I'm still hard at work developing the brand-new old-school (so-far, so-called) Potential RPG. At the close of 2008, I evaluated and distilled my game design goals. My recent focus has been to solidify and enhance the core capabilities of my (so-far, so-called) Potential Platform, in support of these desired gameplay features. For example, a new map management capability allows maps to be either persistent (such as mainland continents) or instances (such as caves to clear). I'm looking forward to (the rest of) 2009 and plan to have something fun to offer soon...

Ripple Effect Subsides, Massive SLOC Drop

Developer's Cave, Island Forge No Comments »
In software development, less is more. Clean, lean code is easier to debug and maintain. Designing the simplest solution is the trick. Whenever I design a software component, I tend to over-engineer it the first time through. This produces a solid, well-designed, hand-crafted unit of code, which is usually terribly complicated for its intended purpose. It'll work well, but trying to explain it to someone else would be difficult. Some call that job security, but I'd prefer to find a more elegant design. Read the rest of this entry »