Sunday, December 15, 2013
Sunday, November 24, 2013
The burst panel is a small panel that pops up at the bottom of the terminal window when you press Ctrl-B. The combo box will allow you to input a new burst or select from a configurable number of bursts that were previously sent. You'll be able to send the burst as many times as you like, either by pressing enter or clicking the "Send" button repeatedly, or by setting the number of repeats in the spinner. The burst panel will be hidden when you press escape.
I'm combining the burst feature with a SWATH-like "quick macro" recording feature. If you press Ctrl-R while the terminal has focus, it will display the burst panel with a blinking "record" icon but keep the focus on the terminal. Any keystrokes sent to the game will also be appended to the combo box. To stop recording, press Ctrl-R again or focus one of the widgets in the burst panel using the mouse. The burst panel will then behave as though it had been shown with Ctrl-B.
Sunday, November 10, 2013
This is what it looks like in action:
I still need to add methods to copy the selection out of the control. I also plan to provide a means of converting the selection into various useful formats, such as ASCII bytes or the Unicode characters that correspond to the glyphs of IBM code page 437.
Sunday, October 13, 2013
The maintainer of DockingFrames does not want to maintain a Maven repo, so I forked it and deployed docking-frames-core, docking-frames-common, and docking-frames-ext-glass in my own repo. I also deployed Steffen Kux's glasslib. Dark Matter can now be built with Maven, but I haven't written the assembly module yet, so the resulting jars cannot be run without a bunch of dependencies on the classpath. Soon!
Saturday, October 5, 2013
I'm finally getting around to working on the new version of Weapon M that I mentioned back in July. It doesn't do much yet, but I'm really excited about it. It's going to solve a lot of the problems that prevented the original version from achieving its full potential. And it's going to look super sweet, which is critically important. The early code is up on GitHub.
Tuesday, September 17, 2013
I've made two decisions regarding the database. First, as much as I'd like an excuse to learn how to use a graph database, Weapon M isn't it. I can't see any benefit to it when the entire graph of POJOs is already accessible to scripts, and serialization works just fine for persistence. And second, I've decided to simplify the synchronization to a single lock shared by the entire database.
Crazy, you say? A huge performance bottleneck? That's what I initially assumed. But the simplicity of a single lock was so alluring that I had to write a simulation to test my assumption. It consisted of two small programs, each of which starts and then joins with two threads. One thread writes random values to the fields of mutable objects in an array, while the other reads them. In one program, the threads contend for a single lock. In the other, they synchronize on the individual object they are reading or writing.
Each program performed one million reads and one million writes on one hundred objects. The program in which the threads were contending for a single lock consistently runs in 140-170 ms; the other runs in 90-100 ms. That's a pretty significant difference, percentage-wise. But remember, we're talking about two million field accesses in a fraction of a second. Things do not happen that fast in Trade Wars! And this is on a G555 Celeron, a fairly low-end processor by today's standards. When the programs are modified to perform only ten thousand reads and writes, the performance difference is completely lost in the overhead of setting up the threads. And increasing the number of objects being manipulated to decrease the lock contention and give the program using individual locks more of an advantage does not significantly affect the results.
My conclusion is that there would be no significant performance penalty to using a single lock. The benefit would be significantly simpler code, eliminating the possibility of any lock-order bugs that could lead to deadlock.
Monday, July 1, 2013
I'm actually thinking about a lot more than a UI overhaul. I've started planning a complete rewrite to incorporate lessons learned from 1.x. Version 2.0 will be a single, modular Maven project including the scripts and zip assembly. It will have a unified parser-to-UI event system, as suggested by a user. And it will address weaknesses like issue #22.
The biggest decision I have yet to make is whether I should replace the crude serialized object graph with a real embedded database. If I do, it'll be an OODBMS or a NOSQL graph database, but I've only barely started comparing the available options.