I recently had a memory leak in my Trekwar game, and to find it (or at least confirm it’s there) I used the WeakReference object in Java..
This is how I proceeded in locating the memory leak, this method could easily be adapted to other programs.
Trekwar is turn based, so each turn the client downloads a Galaxy object from the server. There are many references to this objects inside action listeners, threads, etc..
WeakReference
To make a long story short, a weak reference is like a normal reference, except it will not prevent the object it points to from being garbage collected.
This means that is you have a normal and a weak reference to object A, the weak reference will be null if you remove the “hard” reference.
1) In the client main executable (the class that holds the method that updates the map from the server). Import, declare and make a list of weak references
2) Find the place in your program where a new object is being added, in my place this is the localGalaxy object. Create a weak reference to this object, and list all your weak references.
Now, this means that the object IS being garbage collected, and there is no memory leak.. If you run this and the object you are monitoring (in this example the localGalaxy object) is not GC’ed because of stray references, you can tell because none of the references will point to null.
I got all my websites checked into Subversion (SVN), and usually scp them from my desktop to the webserver. But sometimes I edit the pages directly on the server.
So to keep changes from being lost, I decided to just have a checked out version of the page (svn) on the server as well.. To keep things in sync
But for some reason I don’t want people to snoop in my .svn directory. I googled but did not find any immediate solution, so here it is, a quick fix for anyone who might have the same “problem”.
Hide .svn directory in resin webserver
(also works for cvs or anything else you don’t want resin to give those greedy users)
just add a rewrite rule for the host in the resin configuration file (resin.conf), this prevents the webserver from letting anyone into the directory (or viewing svn/cvs files).
I decided to add Deuterium as a resource in Trekwar, it can be collected from nebulas or by owning star systems that have gas giants in them. Ships also now need deuterium to move, and can run out of gas if you don’t plan your logistics.
Deuterium and maintenance has been added to the menu bar, and fuel to the temporary fleet box
I finally got around to implement the new ship system for the Trekwar game.
Ships are no longer static objects with fixed attributes (weapon, shields, armor, etc..).
All ships are no based on a specific hull, which has some base armor and crap, + X number of slots you can put equiptment in. Below is the starting ship of all factions in the game:
If you noticed that this is the design of a Maquis raider, give yourself a cookie!
I got lot of Starship components to add, and so far I’ve just added ‘Warp Core’, ‘Colonization module’, ‘armor’, ‘beam emitters’ (phasers) and ‘Shield emitters’.
One new thing I implemented today was ship speeds. Unlike in Civilizzation / Birth of the Federation, where units can only move 1 or 2 tiles each turn. Ships in Trekwar can have a speed of 1.0 (which lets it always move 1 tile each turn) or 0.7 like the colonization ship in the screenshot below:
The upper most ship is a scoutship with a speed of 1.0
The lower ship is a colonization ship with a speed of 0.7, that means when it starts moving it will generate 0.7 movement points.. this is not enough to move a full tile. The next turn it generates 0.7 more and then gets 1.4 movement points.. It can the move 1 tile, and has 0.4 movement points “to spare”.. On the third turn in this example it gets 1.1 movement points and can move again..
Ships with a speed below 1.0 will occationally “miss” a movement while moving a distance. Ships with speeds greater than 1.0 will occationally move 2 (or maybe even 3) tiles in a single turn.
Recently much of my spare time programming has gone to giving the Trekwar client a graphical overhaul.
Now I’ve managed to get most of what I broke, working again (Research and Starsystem Control), and I’ve added a glasspane that shows up and prevents the clicking of buttons (and thus creating a weird state of the client) while each tick is being processed by the server.
Currently the test galaxy is 100×100 tiles and takes about 0.5 seconds to load to client
Unlike the previous version of the game, it is now possible to have many windows active on top of the actual game map.
The system box (far left of the screen) has been changed to display more information, and next up is a complete redesign of the fleet box.
But before making the new fleet box and fleet management system, I’ll have to do some major rewrite of the internal ship system and logic, to support user created ship classes.
I’m looking forward to 8-10 hours of pure java and logic.. There is only so much Swing a man can take
Recently I’ve been continuing on my Star trek game, and doing part 2 of the GUI updates, I have to fix up the research view, as it was broken by the new UI.
I also made a new starship path system, and optimized some slow stuff in the drawMap() function
old design – aka: stupid dot system
new design – aka: ehm.. yellow lines?
After making the research view work again, it’s time to port the old starsystem administration UI into the new design. Followed by the new shipdesigner feature.
Since I fixed that annoying memory leak, I’ve been working on updating the graphical client of the trekwar game. Instead of having the map as a own internal window, the map is now always shown. I also made a new menu in Photoshop (thank Thor for photoshop tutorials )
old screenshot ( 0.2.X )
new screenshot (0.3.1)
Next up is implementing the new Shipdesigner system.
I finally got rid of that stupid memory leak in the Star Trek game I’m working on. It turns out when I optimized the use of JLabels I forgot about the action listeners, so the reference to the local copy of the game map was never removed from memory.
With a map update every 35 seconds, the client would go out of memory (200 MB) in 15 minutes, in where around 270’000 action listeners where in memory.
Now however the game can run smoothly for days:
Currently I’m working on a major overhaul of the GUI, and the game looks much better now. I’m gonna release the new screenshots when I get the client stable again and re-integrate the map window in a new way (soon)