Archive for the 'Developer’s Cave' Category

Java Click Count: Windows vs Linux

Developer's Cave, Island Forge Comments Off
Mouse events from Java Swing report the click count. When mouse events are generated within some click threshold (which should be an operating system setting), the click count increases. One common problem is processing single- versus double-clicks. Java does not hold back the single-click event (click count of 1) even when a double-click (click count of 2) may be forthcoming. This is for good reason: As well designed of a programming language that it is, Java cannot see the future. There are techniques (documented elsewhere) for dealing with this aspect of mouse processing in Java. The impetus for this article is mouse event inconsistencies between platforms. Particularly, click counts seem to be reported differently for different events on different platforms. Read the rest of this entry »

Usability, Performance, Scalability

Developer's Cave, Island Forge Comments Off
As of this month, I have transitioned from adding gameplay features into improving usability, performance, and scalability. Usability includes improving the game's user interface, as well as streamlining client behavior and server operation. For instance, the in-world shops and character inventory have been given a face lift. More technical issues include client network behavior and server configurability. Performance testing measures CPU and RAM utilization on the client and server, client-server network requirements, server database/disk read/write, and graphic processing capability of the client. Performance tuning will allow the client to run smoother and reduce server-side bandwidth, CPU, and RAM requirements. Scalability is related to performance, dealing specifically with the capability of the client, server, and network to handle increasing numbers of players (and therefore islands, creatures, battles, items, etc.).

Using JTextArea in a JList

Developer's Cave 5 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 »

Swing Model-View-Controller

Developer's Cave Comments Off
It's old news that Java's Swing GUI toolkit follows a deficient Model-View-Controller (MVC) architecture. In most cases, Swing fuses together the notion of the View and Controller, but offers a separate Model. At least, that's what the naming convention implies. For example, JComboBox should be a View-Controller to a ComboBoxModel. This particular case failed me today. Read the rest of this entry »

Comparable Max Function

Developer's Cave Comments Off
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;
}

Java AWT-Shutdown Thread Refuses to Die

Developer's Cave, Island Forge Comments Off
The cleanest way to close a Java GUI application is to dispose of all top-level resources (JFrame instances, for example) and allow the AWT/Swing thread to close itself. Calling System.exit(0) or Runtime.getRuntime().halt(0) is often prescribed, but not recommended, as it could preempt proper shutdown procedures in your application. If your Java GUI application uses DISPOSE_ON_CLOSE mode, check that your process is exiting cleanly. If it is not, the most likely culprit is that the AWT Event Dispatch Thread is still active. This is well-known AWT/Swing behavior, but there is a scenario in which Java will refuse to shut down this thread, even with all resources closed and disposed. Read the rest of this entry »

Java Font Changes (in Ubuntu)

Developer's Cave 2 Comments »
I updated my development platform to Java 1.6.0_18 and noticed a disturbing font alteration in all Java applications. I'm developing in Ubuntu 9.10, which currently bundles Java 1.6.0_15 (in the sun-java6-jdk package), so I manually installed the latest for testing. I have yet (since yesterday) to investigate whether this is Ubuntu specific. Font configuration changes were noted in the Java 1.6.0_18 Release Notes, associated with a particular bug. Preliminary investigation implies that Java's attitude toward font consistency has changed over time. Early Java 1.3 Physical Fonts documentation makes clear that:
The SDK's physical fonts offer ... Consistent Look and Feel: Your applications will look the same on all platforms because they will be using the same fonts. This makes testing, deployment, and support easier in a cross-platform environment.
In contrast, a more recent bug submission was thoroughly thrashed for suggesting that fonts should remain consistent across platforms and versions. This seems to contradict one of the primary tenets of the Java platform: "Write once, run anywhere" In the future, I'll be looking into explicitly loading a specific font set, possibly by embedding custom fonts within my application.

Hacking-and-Slashing (my Code)

Developer's Cave, Island Forge Comments Off
Today's SLOC count is 96,060 (4,237 less than my 100k analysis and 3,501 less than yesterday). While adding several new gameplay features, I was able to streamline the implementation in several places. This SLOC drop results from isolating (and removing) a good chunk of legacy logic, rules, and display code, which was impeding the integration of new features. Most importantly, playtesters should notice more direction in the gameplay, just as soon as I can deploy the next incremental Alpha release.

100k SLOC

Developer's Cave, Island Forge Comments Off

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 »