A peek at my commit log reveals a flurry of development regarding character avatar animations. I am in the process of improving the system to support fully animated sequences, which have only been partially handled in prior Alpha releases.
Read on for more details… Read the rest of this entry »
I’ve been so busy improving the game world that I haven’t even taken time to write about it lately. There are several significant improvements that are almost ready for Alpha testing. For the moment, here is a glimpse at a new rendering capability: Terrain Edging.
The world surface is composed of hexagonal terrain tiles, which, despite the elevation in complexity they incur, I’m quite pleased with in general. In practice, they do tend to create rather pointy, unattractive edges. The purpose of terrain edging is to provide visually appealing (see artistic disclaimer below) transitions between terrain.
Inspired by the article Handling Terrain Transitions, the world now automatically computes where to place edge tiles where terrain types meet. The system can support general-purpose edging for each terrain type, as well as special-purpose transitions from one terrain type to another. For example, grass edging may include general-purpose crinkly edges, but provide an embankment when next to a lake.
To make this work, each terrain type must include a set of edge tiles. More to the point, all the terrain and edge tiles must be drawn, preferably by someone with more artistic capability than myself. The screenshot shows the potential for terrain edging, but Alpha testers will have to tolerate my graphics until I can procure better art. (Note: Trees not drawn by me.)
As mentioned previously, my current focus is to prepare the game to support improved graphics. At this stage, I’ve adjusted the way graphics are managed by the game, making it easier for me to add new terrain and scenery (and soon, creatures, items, etc.).
Alpha Playtesters should read this forum topic regarding broken maps. Other than that, today’s Alpha testing release (v0.6.3.5) includes a few tweaks. There are likely some new glitches due to the new tileset system, so, as usual, have at it intrepid Playtesters.
Technical tasks have momentarily waylaid gameplay integration. I’ve restructured the graphic rendering routines to make the entire painting pipeline more stable and efficient. Instead of independent timers and redundant repaints, world rendering is now driven on a single timed thread, which carefully coalesces all collected dirty regions to repaint as little as possible on each rendering cycle. Most of the rendering cycle is no longer performed on the Swing/AWT event dispatch thread (only the painting portion), making the client more responsive in general.
The immediate benefit is a reduction in (complete removal of?) some avatar blips and jumps I was seeing during world navigation. Any remaining graphic issues will be easier to debug in the cleaner pipeline. The improved design will allow for future performance testing and tuning, as more sprites and effects are added. In fact, aside from general improvement, the motive for these updates is to begin a graphics enhancement process, which will finalize the handling of sprites and effects in the rendering system, allowing integration of better graphics, with the goal of providing a richer world environment.
The previous article describes features of my world rendering engine. This article describes graphics engine techniques used to render the world. I highlight two competing approaches with which I’ve experimented.
The goal is to paint a picture of the world. This includes layers of terrain, characters, creatures, and other surface features, as well as special effects graphics. See the previous article for a small sample of the rendered world.
Under the hood, I’ve employed two approaches: (a) Off-screen, background-thread, pre-rendering vs. (b) On-demand, in-line rendering. This represents a classic memory-versus-speed tradeoff. Allocating the world image in memory, to be rendered by a background thread, should improve the speed of screen painting and overall client responsiveness. This is a theoretically reasonable approach, which is actually rather common (often used for double-buffering). However, the devil is in the details.
Due to Java’s painting architecture, my background rendering thread must be synchronized with Java’s painting thread. Ultimately, my background rendering thread becomes a tripwire to Java’s painting. (Tripple-buffering might overcome this, but would be memory prohibitive and even more complicated.)
The second approach embraces Java’s painting architecture, rendering the world on demand. Since all the painting calculations are now performed in Java’s painting thread, more careful optimization is needed to avoid stalling the application. Optimization adds complexity, but in this case I consider in-line rendering to be more straight-forward than off-screen rendering.
In my usual manner of over-analyzing and over-engineering, I’ve experimented with a hybrid approach. Terrain is pre-rendered off-screen, while characters, surface features, and effects are drawn on-demand. In this case, the Java painting thread still synchronizes with my background rendering thread, but is only grabbing part of the terrain layer, which rarely changes once drawn, thus avoiding the tripwire effect described above. This approach may provide the best of both worlds.
During alpha testing, I’ve tried all three techniques. The first technique is too cumbersome. The second technique is performance sensitive, but seems promising. The hybrid approach provides the best and worst of both worlds, at the same time solving and creating more subtle issues. From a software standpoint, I’d love to perfect the hybrid engine. Someday I will, but the on-demand drawing system is the simplest to pursue for my immediate needs.
From a performance standpoint, I do not have any hard statistics yet, but on-demand rendering seems to perform well on 5-year-old hardware, in Linux, in windowed mode (not full screen exclusive mode), with no accelerated hardware drivers. With further rendering optimizations and improvements promised for Java, my graphics engine should support Potential RPG and future projects.
Having never built a graphics engine before, I’ve found this to be one of the most challenging and interesting components of this project.
A big part of my Potential RPG project is to write my own software. I’ve spent a large part of my time (more than anticipated) developing the world rendering graphics engine. My personal goal is to increase my experience with graphics processing. My development goal is to produce a simple, tile-based rendering system, supporting some basic features.
Note: The rest of this article describes the current state of the graphics engine, primarily out of my own interest. Other software developer-types might be interested, too.
At this point, world rendering includes terrain tiling, avatar navigation, surface features, and sprite effects.
The engine can render either a rectangular or hexagonal tiled world. In either geometry the tiles can have North-South overlap, providing some basic perspective.
In conjunction with tiled terrain rendering, the engine can layer player character avatars, creatures, surface features, and effects atop the world. These features and effects can be static graphics or animated by the sprite driver.
Avatar navigation occurs on a rectangular coordinate system at finer granularity than the terrain tiles. This allows avatars to walk in natural N-S-E-W-NE-SE-SW-NW directions, rather than being tied to each hexagonal space.
While walking around, if an avatar becomes obscured by a surface feature (such as a tall tree), the engine allows the figure to be seen, as if through the obstruction.
This (very preliminary) image shows a small sample of the world rendering, with a character hiding behind a tree. The inset shows the minimap, which renders a larger geographic region of the world at a smaller scale. The minimap is actually drawn by the same rendering system as the surface, just with a smaller (one-pixel-per-coordinate) terrain tileset.
This article is mostly of interest to RPG Alpha Playtesters. Characters, creatures, some surface features (trees), and sprites are being painted as on-the-fly effects, atop the underlying terrain. The underlying terrain was still being background rendered to an off-screen image, rather than on-the-fly.
As a performance test, I’ve added an (internal) switch to paint the underlying terrain with the new effects system, short circuiting the (soon-to-be legacy?) background rendering altogether. The latest test release (labeled 2008-05-02-1442) renders the terrain in this fashion.
The concern is that the effects-based on-the-fly painting system will not be fast enough to handle painting all 256+ on-screen terrain tiles, plus surface features, characters, creatures, as well as other special effects sprites. Nonetheless, it seems to be working for me, on my non-graphics-accelerated Linux development machine.
There are some known issues and glitches. Items, towns, corpses, and other surface elements will not be drawn during this test (they’re still bound to the legacy rendering system).
The recent significant graphic performance improvement inspired me to tinker with a few new rendering tricks. Surface features (such as trees) now stand atop the underlying terrain. Characters and creatures
can walk behind these features. The goal is to provide a more dimensional perspective to the world.
For alpha playtesters: There are some known issues with the new feature rendering, but I’ve released a new alpha version anyway.
I’m often amazed how much processing can be performed in a few milliseconds, even in the face of sloppy algorithms. Graphic processing, on the other hand, seems to be another story. Any excess painting can be significantly detrimental.
For the record, I’m developing this game in Linux (Debian) with no accelerated graphics drivers, and I am determined for it to run well on my platform of preference. Sun promises a vastly improved graphic pipeline with its upcoming Java update release, but this only helps with DirectX in Windows.
It’s easy to unjustly blame sluggish graphics on Java or Linux. So far in my burgeoning graphics experience, I’ve found that performance problems invariably indicate that I’ve done something horribly wrong. Reading an article on Swing animation last week inspired me to vastly improve my graphic processing.
Without getting into the technical details (unless there’s an interest), the conclusion is that Java on Linux can certainly drive graphic content, as long as you’re meticulous in your implementation. While Java’s general software performance is exceptional, only so much graphic excess can be swept under the rug.
For those who enjoy design patterns, I’ve written a ProxyIcon for the MMORPG client. The reason is to decrease memory allocation in the client, which is due in large part to graphic images, under the theory that most are not needed most of the time. This article describes the ProxyIcon (implementation details are left as an exercise for the reader). First, there is already a central factory of Icons. So, integrating a new proxy pattern only involved changing the factory. ProxyIcon implements the javax.swing.Icon interface, so users are none the wiser.
ProxyIcon knows the source of the image to load. When any Icon methods are accessed, it makes sure the internal image is loaded. If not accessed for some timeout, the internal icon can be unloaded. The simplest implementation would have set the internal Icon reference to null, allowing the garbage collector to clean it up. Why the present perfect tense? Because there’s an even better approach:
ProxyIcon holds two references to the internal Icon: A hard reference and a soft reference. After the timeout, the hard reference is set null, but the soft reference is retained. Since the embedded icon is only referenced (never exposed) from the ProxyIcon object, this leaves only the soft reference. Java cleans up soft references (only) when memory is needed. If, however, the ProxyIcon is accessed before being cleaned up, the hard reference is reinstated. This provides the best of both worlds: Application logic can set policy on when to release resources but is backed up by the Java Virtual Machine’s garbage collection logic to avoid unhelpful cleanup.
The primary benefit, of course, is that unused icon resources can be deallocated. The software design benefit is that image users do not need to concern themselves with whether the icon is currently loaded or not. Notice that all ProxyIcon references stay in memory forever (in the factory). They could also be deallocated by using soft or weak references in the factory, but the objects themselves are (theoretically) miniscule compared to image memory consumption.
Another minor benefit is lazy image loading. Instead of loading upon construction, the internal icon is loaded lazily upon first access. There are a number of icons that are requested in the code, but not always used. This feature has the benefit that the code can greedily ask for icons from the factory (e.g., as static variables) without impacting memory if not needed.
One major gotcha is that Java itself may be holding cached references to the image data, which prevents garbage collection. I have not investigated this fully, but do not use Toolkit.getImage(), as it’s API warns of just this problem. Also read the code for javax.swing.ImageIcon, which makes (undocumented) use of Toolkit.getImage(). Instead, use Toolkit.createImage() or ImageIO.read() with ImageIO.setUseCache(false). Further investigation is needed to determine exactly who has access to underlying image data depending on how it is loaded.
For Alpha testers, look at $HOME/.potentialrpg/stat/IconFactory.stat, which shows:
timestamp, total, loaded, hard_referenced, average_ms_timeout, ms_stat_time
