* 0.2 alpha – build 20130615
Posted on June 16th, 2013 by Alex. Filed under SpaceCoord 2.
Finally I managed to integrate an interactive tutorial into the game. I also added the option to choose a difficulty level for the professional combat pilots out there. Try it out!
What else is new in this version?
- added German translation
- improved controls
- several bug fixes
Download:
* spacecoord 2 tutorial
Posted on April 22nd, 2013 by Alex. Filed under SpaceCoord 2.
Menu

The first thing that greats you, is the main menu:
- New – Start a new game. If you played a game before, but have not finished yet. The new game will overwrite the state of the old game.
- Continue – Continue with a previous game. If you finished the previous one, this button is grayed out.
- Upgrade – Here you can upgrade your ship with new weapons and features. However it is not yet fully tested and will be added in a release later.
- Options – Change the volume of the music and sound effects
- Credits – The game would not have been the one that it is now without the help of numerous people willing to share their work under a license that allows the use. If you want to know, where the graphics, fonts, music and sound effects are coming from, click here.
- Exit – Save the current state of the game (if one is currently going on) and exit.
Game Layout

This image shows a scene in the game. On the left is the panel which allows you to enter another scene offering a different functionality each:
- FTL – Faster Than Light: In this scene, you can jump almost instantly to another sector in the galaxy. The farther away the sector from your current one, the more energy it costs. The energy display shows the energy that is left, after the jump was executed. Once the jump drive is engaged, it requires a huge amount of energy and cannot be interrupted. But you can leave the scene at any point in time.
- SUB – Sublight Scene (shown in the image above). Whenever you are roaming around in the sector, you use the sublight engines. They are not as efficient as the jump drive compared to the distance, but they allow a precise navigation. Weapons can only be fired while the ship is traveling below the speed of light. With the left control, you control the ship (“MOVE”). Be aware of obstacles and planets damaging or even destroying your ship.
With the right control you can fire your energy weapons and lasers. They require energy and as long as your reserves are filled, you can fire lasers. They are not as powerful as the torpedoes (see below). Hold the red marked button in the direction in which you want to fire. It takes a moment to charge the laser banks and to reload them.
TOR – This is your torpedo room. Torpedoes are very powerful, but slow weapons. However your stock is limited, so take care in aiming by moving the red bar in the radar circle towards the direction of the enemy. The selection field allows you to select an appropriate torpedo which differ in its capabilities. However this will be implemented later.- SHD – Your ship is equipped with the latest shielding technology preventing any other object or energy penetrating the hull and armor. Shields require energy and can be recharge by using the ship’s resources. A light blue circle around any object shows the state an strength of the shield. If it is depleted and inflicted damage is compensated by the armor. If the armor is lost, your ship explodes and the galaxy is taken over by the evil enemies.
Status
On top of the screen are displayed the time that is left to clear the galaxy, the energy level (TIME, ENERGY on the right), the state of the shields and armor (SHD and AMR on the left). The game is won, if all hostile ships have been eliminated. Or it is lost, if your ship exploded or you ran out of time or energy.
Space is vast. Fortunately your ship is equipped with a short range scanner localizing objects that are within the sector, but are far to see. Watch out for the little round indicators which are conveniently integrated at the boundary of the Sublight Scene (“SUB”) by your ship’s computer.
Hints
Warning, the following text may contain spoilers. To reveal it, mark the black gap below with your mouse.
Beware of planets. A crash landing on a planet destroys your ship immediately.
There are several objects that will harm you and your crew. But help is still available, but hidden in the galaxy. At space stations you can refuel your energy reserves and do some maintenance to repair your armor. However you have to park your ship not so far away from it to use the services of the space stations.
Download
* initial release (version: 0.1 alpha, build 20130421)
Posted on April 22nd, 2013 by Alex. Filed under SpaceCoord 2.
Introduction
The formerly peaceful galaxy has been taken over by evil enemies. Only one ship stands still in their path and fights back. But the time and resources are running short and every action needs to be planned ahead. Can you free the worlds and bring back the peace?
Permissions:
The Internet permission is for displaying Ads only. There are no ads shown during the game play.
Remarks
I uploaded the initial release of SpaceCoord 2 to Google Play. It is a reimplementation of classic game that I used to play in my childhood. Please note that this version is an early alpha and maybe full of bugs. Hence I would appreciate, if you report any trouble or bugs. Also suggestions and feature requests are most welcome. Over the coming days/months/years, I am going to add features and squash the bugs, so stay tuned!
Credits and Licenses
The following sound files used in this game, are from Freesound.org and licensed under the CC-Attribution License:
- “PolysixSlowingLaser3″ by JimPurbrick
- “1DistantCrack” by HerbertBoland
- “explosion4″ by sarge4267
- “System Background” by gcmax
- “Rocket Launch” by primeval_polypod
- “Metal_Creek_Crash_Smash” by klangmanufaktur
- “Syyyymphonica” by digifishmusic
- “Nine Lies the Heart ed 4″ by ERH
- “string 1 loop” by ERH
The following sound files are royalty free and downloaded from Teknoaxe:
- “Planet Hopper”
- “Radio Silence”
- “Chariots of the Sun”
- “The Ruins of Megalopolis”
- “Chilling in Space Colony 1 (The Dance Remix)”
- “To Hiigara”
- “Mars Incorporated”
The following font files used in this game, are from Fontspace.com and licensed under the CC-Attribution Share Alike License:
- “2BR_SANS” by Total FontGeek
Download
* remember: right sided traffic only
Posted on March 29th, 2013 by Alex. Filed under Germany.
In Germany the traffic usually moves on the right side of the road. It was always like this and did not change in recent times. However it seems that the people working for the road department, do not trust the common driver. Maybe they think that sometimes the driver is in the need of being reminded of the traffic moving on the right side. No efforts are are too big and the money is well spend for that purpose. Otherwise the 30 signs on a stretch of 850m constantly reminding the drivers to pass the road divider to the right only, cannot be explained. The photo shows Von-Coels-Straße in Eilendorf, Aachen, Germany (click to enlarge). The map below the stretch shown in the photo marked in blue, the car is at the position where I took the photo from.
* libboost and read_graphviz_dp
Posted on March 20th, 2013 by Alex. Filed under CPP.
After describing, how graphs can be stored, the question arises, how can they be read? Again we use this graph as an example
which is represented in the file example.dot:
digraph G {
1 [op=2];
2 [op=2];
3 [op=2];
4 [op=2];
5 [op=0];
6 [op=2];
7 [op=2];
8 [op=0];
9 [op=8];
10 [op=1];
11 [op=1];
1->6 ;
2->6 ;
3->7 ;
4->8 ;
5->9 ;
6->10 ;
7->11 ;
10->11 ;
}
The vertices are a struct in my source code:
struct Vertex { //-- properties of a node
unsigned int id; // The ID of the vertex.
int asapTime; // The time index when this vertex can be scheduled EARLIEST.
int alapTime; // The time index when this vertex can be scheduled LATEST.
ops_e op; // The type of operation that needs to be performed in this vertex
};
ops_e in line 5 is an enum type:
enum ops_e {ADD, SUB, MUL, DIV, RSH, LSH, RSHR, LSHR, CMP, total_ops};
Based on the previous experience the operators << and >> for ops_e are already overloaded and added to the std namespace.
The graph itself is stored as an adjacency list:
typedef adjacency_list<vecS, vecS, bidirectionalS, Vertex, no_property> DFGAdjList;
To read the graph, the dynamic properties need to be defined:
dynamic_properties dpInput;
dpInput.property("id", get(&Vertex::id, dfg));
dpInput.property("op", get(&Vertex::op, dfg));
//-- open the file
string filename = argv[1];
ifstream fin(filename.c_str());
//-- Fill dfg with the content of the file
read_graphviz(fin, dfg, dpInput, "id");
Have a look at the directory libboost/read_graphviz_dp in the zip file which can be downloaded below, to see the whole source code used in this example. If you get an error message such as
$ ./main graph.dot
terminate called after throwing an instance of 'boost::exception_detail::clone_impl
what(): Property not found: alapTime.
Aborted
check the graph.dot, if all properties are included. As you can see, in the source code, the property alapTime has not been defined. It might also necessary to use a current library to run this code which has been tested with version 1.53. To update a newer version, please refer the installation manual in the section "Option 2: write_graphviz_dp()".
Download
The source code can be downloaded here: libboost.tar.bz2
* libboost and write_graphviz(_dp)?
Posted on March 20th, 2013 by Alex. Filed under CPP.
Currently I am working with the boost library to handle graph operations. A requirement is to read and write the graphs from and to a file, which caused me a lot of head ache and time consuming searches for examples, how other developers implemented it. The found examples were somewhat not applicable to my problem. Hence I am summarizing here what I found out to write a graph to a file, so that other may simply copy and past most of the code. In another posting I am going to show, how I read the graph from a file. The code for the whole program can be downloaded at the bottom.
Lets assume I have the following graph which is used for all examples.
Probably you will recognize this graph from the paper “Force-directed scheduling for the behavioral synthesis of ASIC’s” by Pierre G. Paulin and John P. Knight.
This graph is a data flow graph (DFG). The vertices of this graph contain some properties such as operations to be executed and some integers for the sake of an example. The edges show the dependencies between the operations. The properties of each vertex are defined in a struct:
struct Vertex { //-- properties of a node
unsigned int id; // The ID of the vertex.
int asapTime; // The time index when this vertex can be scheduled EARLIEST.
int alapTime; // The time index when this vertex can be scheduled LATEST.
ops_e op; // The type of operation that needs to be performed in this vertex
};
ops_e in line 5 is an enum type:
enum ops_e {ADD, SUB, MUL, DIV, RSH, LSH, RSHR, LSHR, CMP, total_ops};
For the graph I am using a adjacency_list. As you can see, I am using the struct Vertex to define the vertex properties. I do not care about the edges, so they have no_property. Apart form that I am using a bidirectional graph so that I can nicely walk through outgoing and incoming edges.
typedef adjacency_list<vecS, vecS, bidirectionalS, Vertex, no_property> DFGAdjList;
Now the graph needs to be filled to get the example:
// the definition of Vertex, ops_e and DFGAdjList are omitted here
enum nodes_e {N1, N2, N3, N4, N5, N6, N7, N8, N9, N10, N11, N12, N13, N14, N15, total_nodes};
typedef graph_traits<DFGAdjList>::vertex_descriptor VertexDesc;
int main(void) {
VertexDesc curVertexDFG;
DFGAdjList dfg;
//-- Fill the verices with operations
ops_e operations[11];
operations[0] = MUL;
operations[1] = MUL;
operations[2] = MUL;
operations[3] = MUL;
operations[4] = ADD;
operations[5] = MUL;
operations[6] = MUL;
operations[7] = ADD;
operations[8] = CMP;
operations[9] = SUB;
operations[10] = SUB;
for(int i=0; i<11; ++i) {
curVertexDFG = add_vertex(dfg);
dfg[curVertexDFG].id = i;
dfg[curVertexDFG].asapTime = -1;
dfg[curVertexDFG].alapTime = -1;
dfg[curVertexDFG].op = operations[i];
}
//-- Add the edges
add_edge(N1, N6, dfg);
add_edge(N2, N6, dfg);
add_edge(N3, N7, dfg);
add_edge(N4, N8, dfg);
add_edge(N5, N9, dfg);
add_edge(N6, N10, dfg);
add_edge(N7, N11, dfg);
add_edge(N10, N11, dfg);
return EXIT_SUCCESS;
}
So, now this graph needs to be stored. There are two options: Using a writer class telling write_graphviz() how this graph is stored. This option works at least in libboost 1.41. Or using dynamic properties by using write_graphviz_dp(). For that I have to update the library, which is quite an easy job. I would like to show you both options:
Option 1: write_graphviz()
A writer class is quite simply implemented. You do not need to understand the whole thing, just the places that you need to adapt to work for your graph. In this example the helper class looks like the following one:
template <class GraphType> class myVertexWriter {
public:
myVertexWriter(GraphType _graphType) : graphType(_graphType) {}
template <class VertexOrEdge> void operator()(std::ostream &out, const VertexOrEdge &v) const {
out << "[id=\"" << graphType[v].id << "\", " <<
"op=\"" << graphType[v].op << "\", " <<
"asapTime=\"" << graphType[v].asapTime << "\", " <<
"alapTime=\"" << graphType[v].alapTime << "\", " <<
"label=\"" << graphType[v].id << "\\nop:" << graphType[v].op << "\"]"; // for dotty
}
private:
GraphType graphType;
};
As you can see, the class is templated so it can be used for all kind of graph types (DFGAdjList) in this example. So it tells the function write_graphviz() how the graph is stored. The main program is extended to call the function:
//...
add_edge(N7, N11, dfg);
add_edge(N10, N11, dfg);
myVertexWriter<DFGAdjList> vw(dfg); //-- instantiate the writer class
ofstream fout("graph.dot");
write_graphviz_dp(fout, dfg, vw);
return EXIT_SUCCESS;
}
The files are located in the directory libboost/write_graphviz in the zip-file. After compiling the code by executing make in the console, a new file “graph.dot” is created with the following content:
digraph G {
0[id="0", op="2", asapTime="-1", alapTime="-1", label="0\nop:2"];
1[id="1", op="2", asapTime="-1", alapTime="-1", label="1\nop:2"];
2[id="2", op="2", asapTime="-1", alapTime="-1", label="2\nop:2"];
3[id="3", op="2", asapTime="-1", alapTime="-1", label="3\nop:2"];
4[id="4", op="0", asapTime="-1", alapTime="-1", label="4\nop:0"];
5[id="5", op="2", asapTime="-1", alapTime="-1", label="5\nop:2"];
6[id="6", op="2", asapTime="-1", alapTime="-1", label="6\nop:2"];
7[id="7", op="0", asapTime="-1", alapTime="-1", label="7\nop:0"];
8[id="8", op="8", asapTime="-1", alapTime="-1", label="8\nop:8"];
9[id="9", op="1", asapTime="-1", alapTime="-1", label="9\nop:1"];
10[id="10", op="1", asapTime="-1", alapTime="-1", label="10\nop:1"];
0->5 ;
1->5 ;
2->6 ;
3->7 ;
4->8 ;
5->9 ;
6->10 ;
9->10 ;
}
which is the representation of the example graph in .dot format. dot -Tjpg graph.dot > graph.jpg in the console converts graph.dot into graph.jpg:
Option 2: write_graphviz_dp()
This function call uses dynamic properties (dp) to store the vertex properties. As far as I remember this function was introduced into libboost with version 1.44. Hence if you are running on an Debian stable system or another one, which does not have a current libboost, the road does not have to end here. A new version of libboost is easily installed and can be done, if you do not have root access to the system. Without using graphviz functions, nothing has to be compiled anyway. Here is a short description of the commands that I executed to get the libraries compiled to allow me to use write_graphviz_dp():
- Download the latest stable boost library from here. There is a “Download” link in the gray box.
- Download the .bz file and save it somewhere, where you have space and where you find it.
- Execute
tar xfj boost_1_53_0.tar.bz2in the console to unpack the files. As you can see at the time of writing this post, version 1.53 was the current release. - Change into the newly created directory with
cd boost_1_53_0, execute./bootstrap --prefix=YOUR_DESTINATION_DIR --with-libraries=graph,regex - It takes around 10 seconds, till the command prompt comes back. After that execute
./b2 -j6 install, which compiles the required parts using 6 cores (-j6) and copies everything toYOUR_DESTINATION_DIR. - Now we have to tell the compiled programs using the graph and regex library to use the new library:
export LD_LIBRARY_PATH=YOUR_DESTINATION_DIR/lib/:$LD_LIBRARY_PATH. - And we have to tell the compiler to use the new header files (.hpp) during compilation and linking process by adding
-IYOUR_DESTINATION_DIR/include -LYOUR_DESTINATION_DIR/lib/ -lboost_graph -lboost_regexto thec++command. Have a look at theMakefileinlibboost/write_graphviz_dpin the zip-file which can be downloaded below.
After the new library is installed, the main file is modified to
//...
add_edge(N7, N11, dfg);
add_edge(N10, N11, dfg);
//-- what is stored?
dynamic_properties dpOutput;
dpOutput.property("id", get(&Vertex::id, dfg));
dpOutput.property("op", get(&Vertex::op, dfg));
dpOutput.property("asapTime", get(&Vertex::asapTime, dfg));
dpOutput.property("alapTime", get(&Vertex::alapTime, dfg));
//-- save the graph in a file
ofstream fout("graph.dot");
write_graphviz_dp(fout, dfg, dpOutput, string("id"));
//-- send it to the console
write_graphviz_dp(std::cout, dfg, dpOutput, string("id"));
return EXIT_SUCCESS;
}
and the writer class myVertexWriter is removed, since there is no need for it anymore. If this is compiled, the compiler throws a long list of error messages at you. Somewhere down in these lines is the following is written:
YOUR_DESTINATION_DIR/include/boost/lexical_cast.hpp:1513: error: no match for ‘operator<<’ in ‘((boost::detail::lexical_stream_limited_src
and
YOUR_DESTINATION_DIR/include/boost/lexical_cast.hpp:1899: error: no match for ‘operator>>’ in ‘stream >> output’
So something could not be stored. Since the struct of Vertex only uses mostly primitives (integers here), it has something to do with the enum type. If line 8 in the code above is commented, it compiles. But how to include the enum type into the output? By overloading the << and >> operator:
enum ops_e {ADD, SUB, MUL, DIV, RSH, LSH, RSHR, LSHR, CMP, total_ops};
std::ostream& operator<<(std::ostream &os, const ops_e op) {
os << (int)op;
return os;
}
std::istream& operator>>(std::istream &is, ops_e &op) {
int operation;
is >> operation;
op = static_cast<ops_e>(operation);
return is;
}
Unfortunately this does not work and the error messages do not change at all. On Stackoverflow a user reported the same error message. The problem is that the overloading << and >> operators are defined globally, but the function lexical_cast only looks into the namespaces of std and boost and hence cannot find any of these defined operators. Hence they need to be added to std:
enum ops_e {ADD, SUB, MUL, DIV, RSH, LSH, RSHR, LSHR, CMP, total_ops};
namespace std {
std::ostream& operator<<(std::ostream &os, const ops_e op) {
os << (int)op;
return os;
}
std::istream& operator>>(std::istream &is, ops_e &op) {
int operation;
is >> operation;
op = static_cast<ops_e>(operation);
return is;
}
}
Now it compiles and works. The question is, why should somebody go through the pain in choosing option 2? The answer is that this can be easily read in by read_graphviz_dp().
Download
The example code can be downloaded here: libboost.tar.bz2
* the dumping lane for snow
Posted on January 21st, 2013 by Alex. Filed under Cycle Tours.
Finally: Last week it started snowing. By the 15th of January a layer of around 5cm (2 inches) covered the country side. I always looked forward to ride in snow and to slide around. Especially I have not seen any snow in the last years while staying in India. Cycling on snow or ice covered roads is very interesting. Nothing will happen as long as nobody jumps just in front of you and you can go straight all the time.
The snow came right at a time, when my new job started to which I cycle around 22km (one way) every day. The snow plows with attached salt dispensers were out all night to remove at least a little bit of the cold cotton from the roads for the rush hours every morning. I have to admit that I thought about the danger coming from slippery roads, but not about the one coming from the traffic. Most of the drivers believe that they are running on railway tracks. In addition the snow plow removes the ice and snow from the road and dumps all of it on the right side of the road and sidewalk. Local residents are obligated to keep the side walk clean. In case of an accident, it is their fault and they can be sued otherwise. So they throw the ice and snow back onto the road. After some time the whole dump piles up between the side walk and the road where the cyclists usually go. Since this forces the cyclists to ride closer towards the middle of the road, dangerous situation occur quite often. All concentration is required by the cyclists to observe the road and its condition. They do not even have the time to take a sip from the already frozen water in the bottle.
* bangalore, yelagiri, bangalore
Posted on September 24th, 2012 by Alex. Filed under Cycle Tours.
Abhijit, Mustafa, Nirmal and I started the Yelagiri tour on Friday night at around 11PM. The aim was to beat the heat during the day while riding on the highways. Since it is mostly downhill, Bangalore, Hosur and Krishnagiri were left behind within the first few hours. In between we had the time for a little bit of star gazing till the view was denied by upcoming clouds. In the early morning hours we reached Krishnagiri. Since we also wanted to do a recce for the upcoming 400km Brevet, we headed south till Karimangalam to find a suitable spot for a control. After having breakfast we started back to Krishnagiri. In the meantime the sun came up and gave us a taste what to expect during the day.
In Krishnagiri we took NH-48 towards the east while the sun was preparing to turn the highway into an well preheated oven. The next 45km were hot, bright, and kind of boring. At the turn off towards Yelagiri we found shade and took some rest at a coconut tender supplying us with one of the best coconuts I have had so far. After an hour of dozing in the shade, we turned towards the village roads leading to the base of Yelagiri. These roads are excellent, in a very good condition and covered by trees. At the base of Yelagiri we split. Two of us wanted to have lunch before starting the climb, whereas I still had the experience from one of the last rides in mind. We went to Anchetti and had lunch there. Unfortunately this town is located in a valley and the way back to Bangalore is obstructed with a long climb towards Denkanikottai. Full stomach and climb do not always go hand in hand. So Nirmal and I started towards the challenge of the day: 14km from base to Yelagiri on top. 12km climb from an elevation from around 350 to 1017 meters above mean sea level. Each of the hairpins is marked with a number. In total there are 14 of them and most of them are 50m apart in height and 1km in length. In the beginning this numbering is very demotivating. In addition youngsters coming down on their bikes, teased us and wished us good luck. But during the climb and with it the increasing number of conquered hairpins, the teasing is slowly turned into awe and respect. After around one hour we reached the top and dropped ourselves in the first chairs of a restaurant that we found. After we finished our belated lunch, we went to a ice cream stall and enjoyed several rounds of ice cream. While the second part of the group reached and we took rooms in a nearby hotel. Without the luggage and an hour of daylight left, there is not much that could be done. So we decided to visit the lake.
After the sun set, we took dinner, went back to the rooms, took a bath and called it a day. The idea was to get up early next morning, which obviously was foiled. So we woke up at around 8AM and started our journey back. Yesterdays climb turned into joyful and long descent which was over in a fraction of a few minutes. We again went back through shady village roads until we hit NH-48. Again the sun was merciless and did its best. Here Mustafa had his flat and we stopped Vaniyambadi. Form there we took village roads towards Kuppam. Although the roads were in an excellent condition and the traffic was very less, the sun scorched us. Mostly the only traffic that we encountered were tractors transporting Ganesha idols followed by villagers who dance to the drums played loudly.
From Kuppam we continued towards Bethamangala. After reaching Bethamangala we had some masala cucumber/pine apple and a friendly guy sponsored us even more. Shortly after the refreshment we continued towards Kolar while the sun set. Somewhere in between, in the middle of nowhere and in the pitch black darkness, Abhijit had a flat. A thorn of around 1.5cm in length went vertically through tire and tube. The tube was deflated so fast that the stuck thorn also pierced through the other side of the tube. Around half an hour later everything was fixed and inflated again and we continued to Kolar. Near Kolar we found a bottling plant in which drinking water was processed. With unlimited water supply at hand, we filled our bottles up to the brim.
An uneventful ride back to Bangalore on a highway was ahead of us. We reached Pavillion (an eatery in IISc) after a total of 407km (210.72km Bangalore -> Yelagiri, 196.27km return) at around 1AM on Monday morning where we ordered the first 5 items on the menu card and simply doubled the quantity.
Distance of the tour: around 211km + 196km = 407km total
GPX files
- YelagiriBangalore.gpx (red)

- BangaloreYelagiri.gpx (blue)






