Development on Mod Wars is now
On Hold!
I didn't want to have to do that but I simply found myself in a situation where I had so much going on in my life that I was spreading myself too thinly. I was logging the hours spent and I was literally only working on this for a couple of hours a week. That simply isn't enough for a project of this size.
Instead I've decided to focus my development efforts on just one thing, which is a web development project for the moment and I'll pick up Mod Wars only when I can spend at least an hour a day on it.
I've now put up a new blog about my development in general and I've split up another blog I had into several more specialised ones. Here they are:
Until next time... happy coding :)
Saturday, May 26, 2007
Sunday, March 18, 2007
Platform Specific Graphics Issues
Today I did a little more work on the grid. I thought the lines looked too thick before so I changed them to single pixel thickness lines and implemented them using the line drawing functions of the SDL_gfx library. Previously they had been drawn as filled rectangles.
I also realised today that I had a problem with colours. The red and blue components of my RGB colours were being reversed. So where I was trying to draw grid lines in a darkish blue colour, they were coming out as orange. I did some investigation to no avail so I logged it as a bug and put together a quick workaround.
At the end of my dev day, I checked in my changes, did an update on my linux box and checked the build. Its a good job I did as I found two problems. Firstly I'd hard coded backward slashes in a pathname - must always use forward slashes to be platform-independent. That was an easy fix. The second issue was that the display was completely screwed up. I show the two screenshots below.
I also realised today that I had a problem with colours. The red and blue components of my RGB colours were being reversed. So where I was trying to draw grid lines in a darkish blue colour, they were coming out as orange. I did some investigation to no avail so I logged it as a bug and put together a quick workaround.
At the end of my dev day, I checked in my changes, did an update on my linux box and checked the build. Its a good job I did as I found two problems. Firstly I'd hard coded backward slashes in a pathname - must always use forward slashes to be platform-independent. That was an easy fix. The second issue was that the display was completely screwed up. I show the two screenshots below.
Linux:
Windows:
Note that on Linix, you can just about make out that the colours are reversed. Hmmm, I got some weirdness going on, I'm not looking forward to fixing this bug! Oh well, no time to fix it now, I've logged a showstopper bug for another day.
To Be Or Not To Be? (Agile)
Over the last couple of weeks I've been doing some work setting up the tools I want to use and this weekend I had the chance to get back to coding. So far all I have is a very simple grid being displayed on the screen; there is no interaction with the player so the next step is to pick a starting position for the player and let him move around the grid using the keyboard.
Now this presents me with a slight problem. At the moment I am only working with a client application; there is no server so any navigation logic will have to be implemented solely on the client. However, one of the problems prevalent in any online game, especially a persistent one, is that of cheating. A common form of cheating is to hack client side data.
For example, lets say the grid contained obstacles that prevented player movement. Indeed later versions of the game will allow individual grid lines to be live or dead and players may only navigate live grid lines. If the client software contained data about the grid (which it must, otherwise how can it render it?) and a player was to hack that data, he may hack it in such a way as to make all the grid lines live. With all navigation logic on the client, this would allow the rogue player to access parts of the grid which he should not be allowed to reach. This of course could wreak havoc on the game.
A general rule to follow when developing an online game is to make the client code as dumb as possible and implement all logic on the server. Thus, one way in which I could do this in terms of navigation is to allow the client to handle keyboard input but once the player reaches a grid cell intersection, send a message over to the server asking if the player may move along that grid line. The server examines its own copy of the data (which of course must be secure) and sends back a response to the client.
Now the client does not necessarily have to wait for a response from the server before allowing the player to move. This would most likely cause a noticeable delay and sluggish experience for the player. A common technique is to have the logic duplicated on the client so the client assumes its data is valid, but once the response is received from the server, any necessary corrections are made. This is known as client-side prediction.
Now all of this sounds like quite a lot of work, and right now all I want to do is let a player move around my grid with the keyboard. I don't really want to implement the server right now. So here's my dilemma. Do I go ahead and just start coding on the client alone, knowing that the navigation functionality is going to change radically when the server is implemented (the agile choice), or do I just take the time now to write the server and do all of the work necessary to implement navigation properly (the traditional route)?
I've decided to go with the agile route knowing that I'll need to re-work lots, if not all of the code. I'm glad I made this choice as I ran into various niggly issues throughout the day so I still haven't finished yet! If I had started on the server code that would have caused even more delays.
As I only get to work on this project for the odd couple of hours here and there I think its important to try and keep the functionality moving forward so that I don't start to feel like I've been working for weeks and making no progress.
Now this presents me with a slight problem. At the moment I am only working with a client application; there is no server so any navigation logic will have to be implemented solely on the client. However, one of the problems prevalent in any online game, especially a persistent one, is that of cheating. A common form of cheating is to hack client side data.
For example, lets say the grid contained obstacles that prevented player movement. Indeed later versions of the game will allow individual grid lines to be live or dead and players may only navigate live grid lines. If the client software contained data about the grid (which it must, otherwise how can it render it?) and a player was to hack that data, he may hack it in such a way as to make all the grid lines live. With all navigation logic on the client, this would allow the rogue player to access parts of the grid which he should not be allowed to reach. This of course could wreak havoc on the game.
A general rule to follow when developing an online game is to make the client code as dumb as possible and implement all logic on the server. Thus, one way in which I could do this in terms of navigation is to allow the client to handle keyboard input but once the player reaches a grid cell intersection, send a message over to the server asking if the player may move along that grid line. The server examines its own copy of the data (which of course must be secure) and sends back a response to the client.
Now the client does not necessarily have to wait for a response from the server before allowing the player to move. This would most likely cause a noticeable delay and sluggish experience for the player. A common technique is to have the logic duplicated on the client so the client assumes its data is valid, but once the response is received from the server, any necessary corrections are made. This is known as client-side prediction.
Now all of this sounds like quite a lot of work, and right now all I want to do is let a player move around my grid with the keyboard. I don't really want to implement the server right now. So here's my dilemma. Do I go ahead and just start coding on the client alone, knowing that the navigation functionality is going to change radically when the server is implemented (the agile choice), or do I just take the time now to write the server and do all of the work necessary to implement navigation properly (the traditional route)?
I've decided to go with the agile route knowing that I'll need to re-work lots, if not all of the code. I'm glad I made this choice as I ran into various niggly issues throughout the day so I still haven't finished yet! If I had started on the server code that would have caused even more delays.
As I only get to work on this project for the odd couple of hours here and there I think its important to try and keep the functionality moving forward so that I don't start to feel like I've been working for weeks and making no progress.
Wednesday, March 14, 2007
Bug / Feature Tracking System
A couple of posts back I said that I wanted to setup various tools that could help me work like a professional dev shop. Incidentally I have since learned of the term "MicroISV" which is an Independent Software Vendor comprising less than 5 people, usually only one. Isn't that cool that there's a name for it now? There's even a book! (On my wishlist, oh yeah!)
Where was I? Tools! Yes, next on the list was a bug tracking system which I wanted to use not so much to track bugs but to track features. I want to keep my development agile which means that as I'm working I often find something I'd like to do, such as write a nice smart pointer to wrap an SDL_Surface pointer which will free it automatically. But nice as this sort of thing is, it is not essential to my goals right now and will only slow me down. But I don't want to lose the idea. So instead, I'd raise an issue in a tracking system and store it for later. When I'm doing new work I'll do a mixture of new features, infrastructure type work, refactoring and so on.
I thought finding such a system would be easy. It had to be free and I wanted it simple because I am the only person using it. I did a quick search and came up with a shortlist:
The first one I tried was Issue Tracker. I got this working reasonably easily but I had to use it within something called Zope which was a bit bizarre and it just didn't seem very configurable. When I entered some issues I couldnt see a number, only a list of the titles and I'd like to be able to easily see a reference number for hooking up to subversion for instance.
Next... Mantis. This thing is written in Php. They're not kidding. When I "installed" it I simply had a bunch of php files on my hard drive. The documentation left me clueless. I figured I could have persisted but the screenshots didn't inspire me with awe so I moved on.
BugTracker.NET. Ugh more dodgy pre-requisistes - I needed IIS installed and configured to ASP.NET 2.0. I just didn't want to go there so I searched again and found a nice list on Dmoz. After looking at about a dozen of obviusly highly commercial systems I noticed that my dmoz list I was looking at had a filter for free systems so I tried that :-)
I eventually found Roundup and installation was reasonably straight forward. The documentation was comprehensive and above all, correct. I managed to configure the database with my own preferences for Priority, Status etc and it works nicely and I also know that if I need to do more with it, it's highly configurable and I just have to invest more time with the documentation.
Here's a pic:
Where was I? Tools! Yes, next on the list was a bug tracking system which I wanted to use not so much to track bugs but to track features. I want to keep my development agile which means that as I'm working I often find something I'd like to do, such as write a nice smart pointer to wrap an SDL_Surface pointer which will free it automatically. But nice as this sort of thing is, it is not essential to my goals right now and will only slow me down. But I don't want to lose the idea. So instead, I'd raise an issue in a tracking system and store it for later. When I'm doing new work I'll do a mixture of new features, infrastructure type work, refactoring and so on.
I thought finding such a system would be easy. It had to be free and I wanted it simple because I am the only person using it. I did a quick search and came up with a shortlist:
- Bugzilla - industry standard giant: http://www.bugzilla.org/
- Issue Tracker - looked pretty: http://www.issuetrackerproduct.com/
- Mantis - looked simple: http://www.mantisbt.org/
- BugTracker.NET: http://www.ifdefined.com/bugtrackernet.html
The first one I tried was Issue Tracker. I got this working reasonably easily but I had to use it within something called Zope which was a bit bizarre and it just didn't seem very configurable. When I entered some issues I couldnt see a number, only a list of the titles and I'd like to be able to easily see a reference number for hooking up to subversion for instance.
Next... Mantis. This thing is written in Php. They're not kidding. When I "installed" it I simply had a bunch of php files on my hard drive. The documentation left me clueless. I figured I could have persisted but the screenshots didn't inspire me with awe so I moved on.
BugTracker.NET. Ugh more dodgy pre-requisistes - I needed IIS installed and configured to ASP.NET 2.0. I just didn't want to go there so I searched again and found a nice list on Dmoz. After looking at about a dozen of obviusly highly commercial systems I noticed that my dmoz list I was looking at had a filter for free systems so I tried that :-)
I eventually found Roundup and installation was reasonably straight forward. The documentation was comprehensive and above all, correct. I managed to configure the database with my own preferences for Priority, Status etc and it works nicely and I also know that if I need to do more with it, it's highly configurable and I just have to invest more time with the documentation.
Here's a pic:
Sunday, March 11, 2007
Client Architecture
Some time ago I was thinking about the client and how I was going to design with Gui flexibility in mind. I put together a little design diagram which used the bridge pattern to help me vary Gui libraries alongside variations in screens being rendered.
However, once I started looking at the code for wxWidgets I realised that this design would not be sufficient because Gui libraries such as wxWidgets are not just libraries of widgets that you plug into your existing applications - they are complete application frameworks within which you develop your code. What this means is that changing from say wxWidgets to Guichan (the one I used whilst developing Morde) is not just a matter of swapping out a few classes. It's involves reworking the architecture of the client code completely.
In addition to the possibility of supporting multiple Gui libraries in case I should want to switch at some time, I also want a front end that does not have any graphics and just outputs to a console. I could use this for unit-testing. For example, rather than manually testing my Gui by loading it up, moving a module around and checking it works, I can develop unit tests which will call functions that simulate the user having pressed navigation buttons to the same effect. Thus, I can automate the testing of pushing a module to the boundaries for example.
If I wanted to get really clever, I could put this kind of behaviour into a script, give it some basic intelligence and I have myself a 'bot' that can play the game according to its scripted rules. Now why would I want bots? Well, for starters I could create bots that perform a complex set of steps for more thorough testing. Secondly, but adding some randomness I may expose bugs that I hadn't uncovered via my hand-crafted bots. Lastly, it could form the basis for scripted NPC modules which will act as enemies in the game.
So, I need at least two completely different front ends. In the case of graphical one, no matter what Gui library I use, I want to use SDL for my underlying drawing code so any SDL code can sit in its own library and thus I can make my real client very thin in architecture. Here is a new diagram that I knocked up:
I've just made up names for classes here, none of them are in place yet. The common library is common to both server and client code.
However, once I started looking at the code for wxWidgets I realised that this design would not be sufficient because Gui libraries such as wxWidgets are not just libraries of widgets that you plug into your existing applications - they are complete application frameworks within which you develop your code. What this means is that changing from say wxWidgets to Guichan (the one I used whilst developing Morde) is not just a matter of swapping out a few classes. It's involves reworking the architecture of the client code completely.
In addition to the possibility of supporting multiple Gui libraries in case I should want to switch at some time, I also want a front end that does not have any graphics and just outputs to a console. I could use this for unit-testing. For example, rather than manually testing my Gui by loading it up, moving a module around and checking it works, I can develop unit tests which will call functions that simulate the user having pressed navigation buttons to the same effect. Thus, I can automate the testing of pushing a module to the boundaries for example.
If I wanted to get really clever, I could put this kind of behaviour into a script, give it some basic intelligence and I have myself a 'bot' that can play the game according to its scripted rules. Now why would I want bots? Well, for starters I could create bots that perform a complex set of steps for more thorough testing. Secondly, but adding some randomness I may expose bugs that I hadn't uncovered via my hand-crafted bots. Lastly, it could form the basis for scripted NPC modules which will act as enemies in the game.
So, I need at least two completely different front ends. In the case of graphical one, no matter what Gui library I use, I want to use SDL for my underlying drawing code so any SDL code can sit in its own library and thus I can make my real client very thin in architecture. Here is a new diagram that I knocked up:
I've just made up names for classes here, none of them are in place yet. The common library is common to both server and client code.
Saturday, March 10, 2007
Installer for Mod Wars
One of the things I want to do with this project is setup all sorts of tools that you'd expect to find in a commercial development shop such as version control, bug / feature tracking, automated builds, continuous integration, unit tests, and installers.
Setting up all of these systems will be a ttime consuming process because:
I looked at several tools:
1) Inno Setup: http://www.jrsoftware.org/isinfo.php
2) Nullsoft Scriptable Installer: http://nsis.sourceforge.net/Main_Page
3) MSBuild: http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx
4) WiX: http://wix.sourceforge.net/
5) Spoon Installer: http://sourceforge.net/projects/spoon-installer
Actually, after a cursory look at their respective websites the only tools I looked at in any detail were Inno and Nullsoft (NSIS). I looked at Inno first and quickly got a bit stuck due to lack of documentation. NSIS on the other hand came with a full manual and I found a whole bunch of tutorials on the web so I had a bash at that one.
An hour later I have a fully working installer with corresponding uninstaller. Cool eh :-) Here's the code:
Setting up all of these systems will be a ttime consuming process because:
- There are lots of tools available, so evaluation time is needed
- Whichever tools I pick, there will be a learning curve
- Will this tool / system affect the player?
- Will this tool / system become more difficult to implement as time passes?
- Installer for the client
- Bug / Feature tracking system
- Automated build tools
- Continuous integration system
- Unit testing
- Code coverage tools
- Logging
- Code verification tools
I looked at several tools:
1) Inno Setup: http://www.jrsoftware.org/isinfo.php
2) Nullsoft Scriptable Installer: http://nsis.sourceforge.net/Main_Page
3) MSBuild: http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx
4) WiX: http://wix.sourceforge.net/
5) Spoon Installer: http://sourceforge.net/projects/spoon-installer
Actually, after a cursory look at their respective websites the only tools I looked at in any detail were Inno and Nullsoft (NSIS). I looked at Inno first and quickly got a bit stuck due to lack of documentation. NSIS on the other hand came with a full manual and I found a whole bunch of tutorials on the web so I had a bash at that one.
An hour later I have a fully working installer with corresponding uninstaller. Cool eh :-) Here's the code:
; name the installer
Name "Mod Wars Setup"
;the install program
OutFile "mw_setup.exe"
;installation directory
InstallDir "$PROGRAMFILES\Mod Wars\"
; define a variable for the bin directory
;==============================================================================
; Install section
;==============================================================================
Section
; set install directory
SetOutPath $INSTDIR
;Files to install
File "/oname=modwars.exe" "..\..\bin\mw_client_wx.exe"
File "..\..\bin\SDL.dll"
File "..\..\bin\SDL_gfx.dll"
; create uninstaller file
WriteUninstaller "$INSTDIR\unins_mw.exe"
; create shortcuts
CreateDirectory "$SMPROGRAMS\Mod Wars\"
CreateShortCut "$SMPROGRAMS\Mod Wars\Mod Wars.lnk" "$INSTDIR\modwars.exe"
CreateShortCut "$SMPROGRAMS\Mod Wars\Uninstall Mod Wars.lnk" "$INSTDIR\unins_mw.exe"
; default section end
SectionEnd
;==============================================================================
;Uninstall section
;==============================================================================
Section "Uninstall"
; always delete uninstaller first
Delete "$INSTDIR\unins_mw.exe"
; delete all installed files
Delete "$INSTDIR\modwars.exe"
Delete "$INSTDIR\SDL.dll"
Delete "$INSTDIR\SDL_gfx.dll"
;delete shortcuts
Delete "$SMPROGRAMS\Mod Wars\Mod Wars.lnk"
Delete "$SMPROGRAMS\Mod Wars\Uninstall Mod Wars.lnk"
RMDir "$SMPROGRAMS\Mod Wars\"
; finally, remove install directory
RMDir "$INSTDIR"
SectionEnd
Saturday, March 03, 2007
Slow Progress?
I look back at this blog and I'm quite discouraged at just how little I have done considering how long I have been working on the project. But over the last couple of months I have been using a great little utility called Slim Timer to track all I time I spent on it. I ran some reports today and I was horrified to find that in both January and February I had only spent 13 hours working on Mod Wars each month! That's shocking! Ideally, I'd like to be working towards that kind of number on a weekly basis though thats probably overly ambitious right now. But still, I'm now making a concerted effort to do more!
Linux Build Fun - Part 2
At the end of last week I was at a stage where I was convinced that the reason that I could not get my code to build under linux was an issue with the code itself, and not an environmental problem.
I was right.
At first I thought I'd just try to get a really small tutorial program building and gradually build it up to what Mod Wars doing but then I took another look at my code and asked myself "what's the difference here?" Suddenly I saw it - all of my code is enclosed within namespaces and of course none of the sample or tutorial programs were.
The errors I was getting indicated that the wxWidgets classes were not being recognised. There is a macro that has to be used for each class such as DECLARE_APP(class_name) for the application class (which encapsulates main), and these macros lie outside of the class in most cases. In my code I had them outside of the class but within the namespace. I tried moving them outside of the namespace and the code built. Ahhhhh relief at last!
I still have one remaining issue on Linux but it's a minor thing. I am using one of the additional SDL libraries, SDL_gfx and I was lucky to find it already installed and built for me but the library file has a .so extension rather than a .a extension like the others. All these libraries are in the same directory yet the linker could not find the .so one. The only way I could get it to build was to put in the absolute path which is a little annoying but not the end of the world.
I checked in my code changes, updated my Windows version and re-built from there to double check everything. Until this point I hadn't even tried a release build and I had to fiddle with a few project settings which I had not set properly for release. I did encounter one odd problem though. Under windows, I use precompiled headers but using the same settings, it built fine under debug but not release - it spat out a lot of errors about the pch file. The only resolution to that problem was to change the release version to not use precompiled headers. Thats fine actually because whenever I check in new code I like to do a full build anyway, just in case of inconsistences.
So, finally I have working code building on two platforms, cool! Oh, and here's a pic of my crappy grid:
I was right.
At first I thought I'd just try to get a really small tutorial program building and gradually build it up to what Mod Wars doing but then I took another look at my code and asked myself "what's the difference here?" Suddenly I saw it - all of my code is enclosed within namespaces and of course none of the sample or tutorial programs were.
The errors I was getting indicated that the wxWidgets classes were not being recognised. There is a macro that has to be used for each class such as DECLARE_APP(class_name) for the application class (which encapsulates main), and these macros lie outside of the class in most cases. In my code I had them outside of the class but within the namespace. I tried moving them outside of the namespace and the code built. Ahhhhh relief at last!
I still have one remaining issue on Linux but it's a minor thing. I am using one of the additional SDL libraries, SDL_gfx and I was lucky to find it already installed and built for me but the library file has a .so extension rather than a .a extension like the others. All these libraries are in the same directory yet the linker could not find the .so one. The only way I could get it to build was to put in the absolute path which is a little annoying but not the end of the world.
I checked in my code changes, updated my Windows version and re-built from there to double check everything. Until this point I hadn't even tried a release build and I had to fiddle with a few project settings which I had not set properly for release. I did encounter one odd problem though. Under windows, I use precompiled headers but using the same settings, it built fine under debug but not release - it spat out a lot of errors about the pch file. The only resolution to that problem was to change the release version to not use precompiled headers. Thats fine actually because whenever I check in new code I like to do a full build anyway, just in case of inconsistences.
So, finally I have working code building on two platforms, cool! Oh, and here's a pic of my crappy grid:
Saturday, February 24, 2007
Linux Build Fun - Part 1
I was really daunted with the prospect of re-building my Linux box, and worse, having to build ModWars on it, especially since I had three separate projects and several source files contributing to my glorious green square!
I started simply by building my common library which was only a couple of files and didn't depend on anything. That was fine. My client library complained about a missing SDL.h file but luckily SDL has been installed along with Fedora so all I had to do there was find it and then point the compiler to that directory.
The tricky part was installing the actual client app which relies on wxWidgets. I had not built a wxWidgets app on my virtual PC so this was new ground. It didn't build of course - it complained about the wx header file. I searched the packages and couldn't find one for it so I downloaded it. Now how to build wxWidgets on linux? I looked through the files that began with "install" but couldn't see anything obvious but gtk seemed familiar so I tried typing in the instructions in there. It complained about the development files for GTK+ being missing *sigh*.
So, I thought I'd check the package manager for it and searched for GTK. I was confused to find wxGTK in there already installed even though I had searched the entire machine for the header file I needed. I found the gtk development files so proceeded to install that but I was really confused now - what is GTK anyway and if wxGTK is installed then why can't I find the header file?
Once I downloaded and installed the GTK files two things changed. Firstly, I found an installation of wxWidgets. That struck me as odd because according to my package manager it was already there. Unfortunately it was version 2.6 but I figured that would do for now. In there was the header file I needed. But I also found that the configure program for the 2.8 version of wxWidgets which I downloaded now worked so I thought I'd try building it anyway. That took a while...
I'll give the install file credit - the step-by-step instructions worked without a hitch once the GTK files were present so I now had a wxWidgets 2.8 installation installed. So I added the include file to my directory list in Code::Blocks and tried again. This time the setup.h file wasn't found. I remember having issues with this before, I really should blog my problems and solutions to those problems more thoroughly!
After searching wxWiki I found an article about the setup.h file and how the build process generates it for you. So I did a search and sure enough I found one lurking in the build folder I'd just built. I copied it to the correct location and re-built. It got further this time but hit a #error message of "No target! You should use the wx-config program for compilation flags!"
In all the examples for compiling wxWidgets they show a command line version using g++ and part of the command line is "wx-config --cxxflags" and "wx-config --libs". I had no idea what these did and no idea how to reproduce the same effect in Code::Blocks.
I took another approach and tried creating a wxWidgets project using the wizard. That worked so I then deleted the source files and added my own. This time it got past the weird errors and whined about my application class saying "expected class name".
Some further searching on the forums finally revealed the correct way to use the wx-config options. Under build options for the project, I had to select the Compiler | Other Options and type in 'wx-config --cxxflags' and under the Linker tab in the "Other linker options" type in "wx-config --libs". Performing these two steps got me to the same place as I had in my test project with the same compilation errors.
I then managed to find a tutorial video showing how to build a wxWidgets application in Code::Blocks and found that the wizard I had used was nothing like the one used in this video. Some further searching revealed that I was using an old version. Could that be the problem I wondered? In Fedora there is an automatic package update utility so I clicked on that and it found an update to Code::Blocks (along with a squillion other things) so I let that do it's thing.
A very long time later Fedora finished updating, rebooted and sure enough I had a new version of Code::Blocks with a new wxWidgets wizard. It still wasn't the latest version though so I registered on the CB forums so I could download the latest one. Now I just had to install the linux version of 7zip so I could extract it, and then figure out what to do with it.
Once I did this it seemed to take me a step backwards. The default project would no longer build, complaining once again about wx-config. Worse still, I had now lost my option to enter in linker options and it was complaining about that also.I figured I had screwed things up and at this point I could see no option but to re-install CB from scratch.
This got me back to where I was before I watched the video. I could build the sample app, but not Mod Wars. However, i managed to find the linker options and fixed the wxconfig --libs line and I was also able to figure out how to link in my mw-common, mw_client_lib and the SDL libraries so this reduced the errors down a bit. Now all I had left were an undefined reference to main, and missing vtables for the other wx classes. I'm assuming the remaining issues are down to code and not project settings. Unfortunately I've run out of time so I'll have to leave this issue until another day.
I started simply by building my common library which was only a couple of files and didn't depend on anything. That was fine. My client library complained about a missing SDL.h file but luckily SDL has been installed along with Fedora so all I had to do there was find it and then point the compiler to that directory.
The tricky part was installing the actual client app which relies on wxWidgets. I had not built a wxWidgets app on my virtual PC so this was new ground. It didn't build of course - it complained about the wx header file. I searched the packages and couldn't find one for it so I downloaded it. Now how to build wxWidgets on linux? I looked through the files that began with "install" but couldn't see anything obvious but gtk seemed familiar so I tried typing in the instructions in there. It complained about the development files for GTK+ being missing *sigh*.
So, I thought I'd check the package manager for it and searched for GTK. I was confused to find wxGTK in there already installed even though I had searched the entire machine for the header file I needed. I found the gtk development files so proceeded to install that but I was really confused now - what is GTK anyway and if wxGTK is installed then why can't I find the header file?
Once I downloaded and installed the GTK files two things changed. Firstly, I found an installation of wxWidgets. That struck me as odd because according to my package manager it was already there. Unfortunately it was version 2.6 but I figured that would do for now. In there was the header file I needed. But I also found that the configure program for the 2.8 version of wxWidgets which I downloaded now worked so I thought I'd try building it anyway. That took a while...
I'll give the install file credit - the step-by-step instructions worked without a hitch once the GTK files were present so I now had a wxWidgets 2.8 installation installed. So I added the include file to my directory list in Code::Blocks and tried again. This time the setup.h file wasn't found. I remember having issues with this before, I really should blog my problems and solutions to those problems more thoroughly!
After searching wxWiki I found an article about the setup.h file and how the build process generates it for you. So I did a search and sure enough I found one lurking in the build folder I'd just built. I copied it to the correct location and re-built. It got further this time but hit a #error message of "No target! You should use the wx-config program for compilation flags!"
In all the examples for compiling wxWidgets they show a command line version using g++ and part of the command line is "wx-config --cxxflags" and "wx-config --libs". I had no idea what these did and no idea how to reproduce the same effect in Code::Blocks.
I took another approach and tried creating a wxWidgets project using the wizard. That worked so I then deleted the source files and added my own. This time it got past the weird errors and whined about my application class saying "expected class name".
Some further searching on the forums finally revealed the correct way to use the wx-config options. Under build options for the project, I had to select the Compiler | Other Options and type in 'wx-config --cxxflags' and under the Linker tab in the "Other linker options" type in "wx-config --libs". Performing these two steps got me to the same place as I had in my test project with the same compilation errors.
I then managed to find a tutorial video showing how to build a wxWidgets application in Code::Blocks and found that the wizard I had used was nothing like the one used in this video. Some further searching revealed that I was using an old version. Could that be the problem I wondered? In Fedora there is an automatic package update utility so I clicked on that and it found an update to Code::Blocks (along with a squillion other things) so I let that do it's thing.
A very long time later Fedora finished updating, rebooted and sure enough I had a new version of Code::Blocks with a new wxWidgets wizard. It still wasn't the latest version though so I registered on the CB forums so I could download the latest one. Now I just had to install the linux version of 7zip so I could extract it, and then figure out what to do with it.
Once I did this it seemed to take me a step backwards. The default project would no longer build, complaining once again about wx-config. Worse still, I had now lost my option to enter in linker options and it was complaining about that also.I figured I had screwed things up and at this point I could see no option but to re-install CB from scratch.
This got me back to where I was before I watched the video. I could build the sample app, but not Mod Wars. However, i managed to find the linker options and fixed the wxconfig --libs line and I was also able to figure out how to link in my mw-common, mw_client_lib and the SDL libraries so this reduced the errors down a bit. Now all I had left were an undefined reference to main, and missing vtables for the other wx classes. I'm assuming the remaining issues are down to code and not project settings. Unfortunately I've run out of time so I'll have to leave this issue until another day.
Monday, February 12, 2007
Update on Inlines
Last night I discovered that it was inline functions that caused my linking problems though at the time I wasn't sure why. I've googled around a bit and now the cause has come clear. The process of inlining is usually done at compile time (not link time) and for the compiler to be able to inline the function it must be able to see its internal definition. In my code I just so happened to place these inline functions in the .cpp files. Had I placed them in the header file, it probably would have been fine. However, the reason I put them in the cpp file in the first place is that I specifically wanted to avoid any implementation code, no matter how minor, in the header file. So I'll leave it as it is, I'm sure the compiler will do a fine optimization job anyway.
Sunday, February 11, 2007
Inline Functions in Static Libraries
In a word - don't do it! Following my green block code, I wanted to render the grid and I figured I could do this in about ten minutes - ha! I put a couple of simple classes including a grid class in a library as this will be used by the server as well. The code compiled but would not link; I got the dreaded unresolved external.
I've had these before many times and I can usually fix them fairly quickly. Its usually a project setting in my case. I checked and rechecked all the project settings, I compared this project against Morde which used a similar setup but all to no avail. I wont bore you with the diagnostics. Suffice to say I eventually traced the problem down to the use of inline functions in the library.
I'm not entirely sure why you cant use inlines, and I'll read up on that to find out but the silly thing is that I never use inlines. I even read an article by Scott Meyers recently about why its generally a bad idea to use them so what on earth posessed me to start today? Well lesson learned I guess!
The grid doesn't render properly but I can fix that another day.
As a side note... usually I would have left this problem to another day. I was actually in the middle of watching a movie when it cropped up and I thought I could literally write this bit of code in 10 minutes. Usually if I hit a problem late in the evening I leave it and come back to it after some sleep but today something nagged me and I told myself that I simply had to fix it now otherwise it would hang over me. Sometimes you have to know when to call it a day. Other times you have to know when to just plough through a problem until it is resolved.
I've had these before many times and I can usually fix them fairly quickly. Its usually a project setting in my case. I checked and rechecked all the project settings, I compared this project against Morde which used a similar setup but all to no avail. I wont bore you with the diagnostics. Suffice to say I eventually traced the problem down to the use of inline functions in the library.
I'm not entirely sure why you cant use inlines, and I'll read up on that to find out but the silly thing is that I never use inlines. I even read an article by Scott Meyers recently about why its generally a bad idea to use them so what on earth posessed me to start today? Well lesson learned I guess!
The grid doesn't render properly but I can fix that another day.
As a side note... usually I would have left this problem to another day. I was actually in the middle of watching a movie when it cropped up and I thought I could literally write this bit of code in 10 minutes. Usually if I hit a problem late in the evening I leave it and come back to it after some sleep but today something nagged me and I told myself that I simply had to fix it now otherwise it would hang over me. Sometimes you have to know when to call it a day. Other times you have to know when to just plough through a problem until it is resolved.
Whoohoo We Have an Executeable!
Last time I managed to get a tutorial program running that nicely integrated SDL with wxWidgets. This weekend I started on the real dummy code for Mod Wars! What I mean by "real dummy" is that I know that anything I write at this stage will get rewritten or completely trashed at some point, but I'm at a stage where I want to start structuring my projects, thinking about naming conventions and that sort of thing.
So I started off by re-writing the tutorial program as if the output was what is desired for Mod Wars. One thing I did differently this time around is change my usual naming convention. Usually all my C++ code follows the Boost naming conventions of all underscore_separated lowercase_identifiers. However, wxWidgets doesn't use that kind of naming and my code just looked odd. So instead, for any code that works directly with wxWidgets including the classes I had to derive from those in their framework, I followed their naming conventions.
Furthermore, I had already decided to split out my client code into two parts - a generic library that wasn't specific to any particular Gui, and a Gui only portion that is. The reason for this is that (gosh did I already blog about this? I feel like I'm repeating myself! anyway...) I know that I want at least two front ends for the client - the real one with my Gui library of choice which is currently wxWidgets, and a console based front-end for running unit tests and hopefully for running scrips so that I can automate execution of the client code. The second reason is that Gui libraries are a pain in the a**! I tried at least half a dozen when looking for one for Mod Wars so if I tie myself into just one, I'm sure Murphy would see to it that I change it along the way.
Back to naming conventions then... in my library code I use my internal conventions and in Gui code I'll follow the conventions of the library I am using.
Wanna see the finished product? Here's a glorious screenshot for you!
What the **** is this you are probably thinking! Many moons ago when I first decided that I wanted to write games, I started to teach myself DirectX. I had no idea where to start and I found it very difficult. I was trying to recreate a block puzzle game that I had written in MFC years earlier. The screen was supposed to be filled with little coloured blocks and instead, after days of faffing around, all I managed to produce was a solitary green block in a very odd place! So now, whenever I start writing a game that needs any kind of graphics the first thing I do is just render a green block! It also fits nicely into the "do the simplest thing that could possibly work" mantra :-)
I'll render a grid next, honest!
So I started off by re-writing the tutorial program as if the output was what is desired for Mod Wars. One thing I did differently this time around is change my usual naming convention. Usually all my C++ code follows the Boost naming conventions of all underscore_separated lowercase_identifiers. However, wxWidgets doesn't use that kind of naming and my code just looked odd. So instead, for any code that works directly with wxWidgets including the classes I had to derive from those in their framework, I followed their naming conventions.
Furthermore, I had already decided to split out my client code into two parts - a generic library that wasn't specific to any particular Gui, and a Gui only portion that is. The reason for this is that (gosh did I already blog about this? I feel like I'm repeating myself! anyway...) I know that I want at least two front ends for the client - the real one with my Gui library of choice which is currently wxWidgets, and a console based front-end for running unit tests and hopefully for running scrips so that I can automate execution of the client code. The second reason is that Gui libraries are a pain in the a**! I tried at least half a dozen when looking for one for Mod Wars so if I tie myself into just one, I'm sure Murphy would see to it that I change it along the way.
Back to naming conventions then... in my library code I use my internal conventions and in Gui code I'll follow the conventions of the library I am using.
Wanna see the finished product? Here's a glorious screenshot for you!
What the **** is this you are probably thinking! Many moons ago when I first decided that I wanted to write games, I started to teach myself DirectX. I had no idea where to start and I found it very difficult. I was trying to recreate a block puzzle game that I had written in MFC years earlier. The screen was supposed to be filled with little coloured blocks and instead, after days of faffing around, all I managed to produce was a solitary green block in a very odd place! So now, whenever I start writing a game that needs any kind of graphics the first thing I do is just render a green block! It also fits nicely into the "do the simplest thing that could possibly work" mantra :-)
I'll render a grid next, honest!
Sunday, January 28, 2007
Development Finally Underway!
After my recent rethink on agility, this weekend saw me finally start to cut some code! Time was short so I had to really focus on what I wanted to achieve. I decided to start with something that would give me visual feedback - rendering of the grid but I actually started one step back from that.
I know I'm going to use SDL for rendering in general and wxWidgets for specific Gui elements such as buttons and text boxes. The tricky thing is that wxWidgets wants to take over your application (stop you having a main function) so combining the two libraries requires a little rework of the usual model. Thankfully, somebody wrote a tutorial on doing just that which I used as my starting point. It didn't quite work but I was able to fix it quite easily.
The main problem lies in the SDLApp class. The OnInit function creates a frame and makes it the top window. In the OnRun function which is invoked after OnInit there is a call to SDL_Init followed by some code to create an event to get the event loop running. The problem here is that the call to SDL_Init causes an infinite loop. SDL is used in the SDLPanel class which owns a pointer to an SDL_Surface used for the drawing. The SDLPanel::OnPaint function is called whenever the panel needs to be updated and if you look at the code you'll see that if the surface hasn't been initialised the function returns.
The problem is that because the frame has been made a top window in the OnInit function of SDLApp, this causes the panel class to try and paint itself, but SDL hasn't been initialised yet so it can't. So the window hasn't been drawn, OnPaint gets fired again and round and round we go. Thus the code after that to create the event never gets executed, no event is created, there is no event loop and the application hangs. To fix this, I got rid of OnInit and moved the frame initialisation code to OnRun after the call to SDL_Init. That fixed the problem but there were still issues.
I got two windows being displayed and the spurious one tried to take up the whole screen. The tutorial says that called SDL_SetVideoMode with zeros for the size suppresses the creation of the window. I don't know how old the tutorial code is but on my system it does no such thing - the window is created anyway. I simply removed this call and the app worked fine.
It worked fine on my Windows box anyway! Now that I have committed myself to doing this cross-platform I needed to try and build it on Fedora. Unfortunately I soon realised that I would have to build wxWidgets on that too (eurgh!) and I can't remember how I did it on Windows never mind on Linux! I should have blogged that bit in more detail!
Well that's enough for one day. At least I got some code working - I'VE STARTED!
I know I'm going to use SDL for rendering in general and wxWidgets for specific Gui elements such as buttons and text boxes. The tricky thing is that wxWidgets wants to take over your application (stop you having a main function) so combining the two libraries requires a little rework of the usual model. Thankfully, somebody wrote a tutorial on doing just that which I used as my starting point. It didn't quite work but I was able to fix it quite easily.
The main problem lies in the SDLApp class. The OnInit function creates a frame and makes it the top window. In the OnRun function which is invoked after OnInit there is a call to SDL_Init followed by some code to create an event to get the event loop running. The problem here is that the call to SDL_Init causes an infinite loop. SDL is used in the SDLPanel class which owns a pointer to an SDL_Surface used for the drawing. The SDLPanel::OnPaint function is called whenever the panel needs to be updated and if you look at the code you'll see that if the surface hasn't been initialised the function returns.
The problem is that because the frame has been made a top window in the OnInit function of SDLApp, this causes the panel class to try and paint itself, but SDL hasn't been initialised yet so it can't. So the window hasn't been drawn, OnPaint gets fired again and round and round we go. Thus the code after that to create the event never gets executed, no event is created, there is no event loop and the application hangs. To fix this, I got rid of OnInit and moved the frame initialisation code to OnRun after the call to SDL_Init. That fixed the problem but there were still issues.
I got two windows being displayed and the spurious one tried to take up the whole screen. The tutorial says that called SDL_SetVideoMode with zeros for the size suppresses the creation of the window. I don't know how old the tutorial code is but on my system it does no such thing - the window is created anyway. I simply removed this call and the app worked fine.
It worked fine on my Windows box anyway! Now that I have committed myself to doing this cross-platform I needed to try and build it on Fedora. Unfortunately I soon realised that I would have to build wxWidgets on that too (eurgh!) and I can't remember how I did it on Windows never mind on Linux! I should have blogged that bit in more detail!
Well that's enough for one day. At least I got some code working - I'VE STARTED!
Wednesday, January 24, 2007
Rethinking Agility
Back on December 1st I posted an outline of the plan I had for my first iteration. Wow, almost two months have passed and I haven't even started on that list! Anyway if you take another look at the plan you'll see a lot of stuff listed under "Framework" like configuration, logging, a state machine, an XML library, and on and on.
I figured I may as well lay the groundwork for all the stuff I'm going to need up front. But today I realise that this is not very agile! Remember my requirements for this first iteration is quite simply "allow a player to connect to the server and nagivate around the grid." I don't need configuration for that! I don't need to log anything, I don't need a state machine or an XML library. Yeah I'll probably need those things as I add more functionality but I don't need them now.
One of the XP practices is to do the simplest thing that could possibly work. And one of the principles of agility in general is to focus on working software. If I stuck to this plan as it is now I could spend six months on this stuff and have nothing demonstrable! And of course on a pet project for which I have hardly any time at all with nobody to drive me forward its really important that I keep myself motivated and the only way I can do that is to see the results of my progress visibly.
So I'm going to take a good hard look at this list and see what I really need. Well I do need data for the grid and the players but it will be very simple. The players wont even have a name at this point! I'll need a network protocol but it can be real simple at this stage with support for navigation only.
This is one of those areas where trying to do up-fron design is almost guaranteed to fail. Even if I knew everything that my game would want to do, I still wouldn't really know how to design a network protocol that could elegantly handle any kind of message that I would need. That's something I'm just going to have to figure out as I go along so it really would be counterproductive to try and anticipate what I'll need later. I know I'll have to refactor it later so why write any more than I need to now?
Not only do I not need a flexible Gui yet but I dont need a Gui at all!! I can just blit some real simple grid graphics and draw a rectangle for a player! I don't need any more than that right now. It would be much better to get working on a basic client and server, get some rubbish graphics displayed and let players move around. That will be far more satisfying for me than having fleshed out a complex state machine or XML library!
I dont have my project planning software available right now so I'll just jot down a quick list of what I think I really need to do after having rethought this stuff:
I figured I may as well lay the groundwork for all the stuff I'm going to need up front. But today I realise that this is not very agile! Remember my requirements for this first iteration is quite simply "allow a player to connect to the server and nagivate around the grid." I don't need configuration for that! I don't need to log anything, I don't need a state machine or an XML library. Yeah I'll probably need those things as I add more functionality but I don't need them now.
One of the XP practices is to do the simplest thing that could possibly work. And one of the principles of agility in general is to focus on working software. If I stuck to this plan as it is now I could spend six months on this stuff and have nothing demonstrable! And of course on a pet project for which I have hardly any time at all with nobody to drive me forward its really important that I keep myself motivated and the only way I can do that is to see the results of my progress visibly.
So I'm going to take a good hard look at this list and see what I really need. Well I do need data for the grid and the players but it will be very simple. The players wont even have a name at this point! I'll need a network protocol but it can be real simple at this stage with support for navigation only.
This is one of those areas where trying to do up-fron design is almost guaranteed to fail. Even if I knew everything that my game would want to do, I still wouldn't really know how to design a network protocol that could elegantly handle any kind of message that I would need. That's something I'm just going to have to figure out as I go along so it really would be counterproductive to try and anticipate what I'll need later. I know I'll have to refactor it later so why write any more than I need to now?
Not only do I not need a flexible Gui yet but I dont need a Gui at all!! I can just blit some real simple grid graphics and draw a rectangle for a player! I don't need any more than that right now. It would be much better to get working on a basic client and server, get some rubbish graphics displayed and let players move around. That will be far more satisfying for me than having fleshed out a complex state machine or XML library!
I dont have my project planning software available right now so I'll just jot down a quick list of what I think I really need to do after having rethought this stuff:
- Grid graphics (that's done actually whoo!)
- Game Data
- Grid
- Players (nothing but an ID!)
- Network Message for position update
- Basic Server
- Accept connections
- Basic Client
- Connect to server
- Render the grid and blocks for players
Sunday, January 14, 2007
Build Successes
After the frustrations of last weekend, I'm glad to report that I have managed to solve both of the outstanding issues that I had. First the IDE issue:
I tried out Eclipse and this was a little better as it allowed me to create an empty project and after a little searching I found a way to link the project to the source folder that I had already setup. However, when I tried to build the project nothing happened. I think the Linux way of doing things is to have a build target and build that but I couldn't figure out how to do it and I don't want to learn how to write make files right now.
I decided to post on the Gamedev forums as they have always been very helpful for me in the past. Sure enough the next day there was a post recommending an IDE called CodeBlocks. I had heard of it before but I didn't realise it was an IDE. This was exactly what I needed and very intuitive which is more than I can say for KDevelop and Eclipse. I created a new project, selected the "Empty Project" template and to add new files I just pointed it at the files I already had. I hit build and it just did its stuff, great!
I checked the CodeBlocks project files into Subversion and then added some more files under Windows. I then went back to Fedora, updated my working copy and built the new version. The benefits of cross platform development made themselves immediately apparent as there was a build error. I had to include a file which was not necessary under VS2005. When I next work on this I'll try setting up some more complex projects.
My second success this weekend was getting a (very simple) wxWidgets project to build. I had two problems. The first were missing libraries and eventually I figured out that the ones I needed were comctl32.lib rpcrt4.lib wxbase28d.lib wxmsw28d_core.lib . The second issue was that in VS2005 by default the character set selected will be unicode and this is not supported in wxWidgets so I had to change that to MultiByte Character Set. Once I did that my little Hello wxWidgets World application built and ran successfully. This will be a good one to try out under Fedora as the wxWidgets library actually uses native controls and so the underlying code being executed is different under each different OS.
I tried out Eclipse and this was a little better as it allowed me to create an empty project and after a little searching I found a way to link the project to the source folder that I had already setup. However, when I tried to build the project nothing happened. I think the Linux way of doing things is to have a build target and build that but I couldn't figure out how to do it and I don't want to learn how to write make files right now.
I decided to post on the Gamedev forums as they have always been very helpful for me in the past. Sure enough the next day there was a post recommending an IDE called CodeBlocks. I had heard of it before but I didn't realise it was an IDE. This was exactly what I needed and very intuitive which is more than I can say for KDevelop and Eclipse. I created a new project, selected the "Empty Project" template and to add new files I just pointed it at the files I already had. I hit build and it just did its stuff, great!
I checked the CodeBlocks project files into Subversion and then added some more files under Windows. I then went back to Fedora, updated my working copy and built the new version. The benefits of cross platform development made themselves immediately apparent as there was a build error. I had to include a file which was not necessary under VS2005. When I next work on this I'll try setting up some more complex projects.
My second success this weekend was getting a (very simple) wxWidgets project to build. I had two problems. The first were missing libraries and eventually I figured out that the ones I needed were comctl32.lib rpcrt4.lib wxbase28d.lib wxmsw28d_core.lib . The second issue was that in VS2005 by default the character set selected will be unicode and this is not supported in wxWidgets so I had to change that to MultiByte Character Set. Once I did that my little Hello wxWidgets World application built and ran successfully. This will be a good one to try out under Fedora as the wxWidgets library actually uses native controls and so the underlying code being executed is different under each different OS.
Sunday, January 07, 2007
Teething Problems
Linux IDEs
It's always exciting to start work on a new project but the downside is that there are always problems at the beginning. Yesterday I made good progress with the Linux work by getting the virtual PC up and running so today I spent some time trying to get some sample code building under a Linux IDE.
The first one that I tried was KDevelop as everybody says that's the best. With Visual Studio, I can setup an empty project and manually add files to it which allows me to keep platform-specific build files away from source files. But I could find no way to do that using KDevelop. It came with a multitude of project templates but no empty project. The simplest project I could set up was a 'hello world' application but I was shocked to find that this created about 20 files! This would have been okay as long as I could add my own files to the project but alas I could only do that if I placed the files in a specific directory, which of course did not fit in with the directory structure I had created.
I googled around and it would seem that only an earlier version of KDevelop allows project creation to be truly configurable. Oh well, so much for progress. I'll try out Eclipse next time.
GUI Libraries
I didn't want to spend my entire day wresting with Linux IDE's so I turned my attention to coding issues. When developing Morde at Uni, I spent a long time trying to find a GUI library that would work with SDL. Most of the ones I investigated provided not just widgets, but a complete application framework. This did not suit me as I already had my framework in place (I didn't think about Gui work until quite late into development!) Eventually I found one called Guichan which seemed ideal as as it is designed specifically for SDL games and wasn't intrusive. Unfortunately it just wasn't up to scratch.
I will need a GUI library for Mod Wars too so the hunt is on again but this time I'll be thinking of it from the outset so this opens up my options. One library that I have my eye on is wxWidgets. This is a very mature, cross-platform library that has a lot of documentation available. But these things can have their downsides too; wxWidgets has been around for such a long time and there are so many tutorials etc that there is a huge overload of out of date information out there and I have not yet managed to build the standard Hello World sample yet :-(
It's always exciting to start work on a new project but the downside is that there are always problems at the beginning. Yesterday I made good progress with the Linux work by getting the virtual PC up and running so today I spent some time trying to get some sample code building under a Linux IDE.
The first one that I tried was KDevelop as everybody says that's the best. With Visual Studio, I can setup an empty project and manually add files to it which allows me to keep platform-specific build files away from source files. But I could find no way to do that using KDevelop. It came with a multitude of project templates but no empty project. The simplest project I could set up was a 'hello world' application but I was shocked to find that this created about 20 files! This would have been okay as long as I could add my own files to the project but alas I could only do that if I placed the files in a specific directory, which of course did not fit in with the directory structure I had created.
I googled around and it would seem that only an earlier version of KDevelop allows project creation to be truly configurable. Oh well, so much for progress. I'll try out Eclipse next time.
GUI Libraries
I didn't want to spend my entire day wresting with Linux IDE's so I turned my attention to coding issues. When developing Morde at Uni, I spent a long time trying to find a GUI library that would work with SDL. Most of the ones I investigated provided not just widgets, but a complete application framework. This did not suit me as I already had my framework in place (I didn't think about Gui work until quite late into development!) Eventually I found one called Guichan which seemed ideal as as it is designed specifically for SDL games and wasn't intrusive. Unfortunately it just wasn't up to scratch.
I will need a GUI library for Mod Wars too so the hunt is on again but this time I'll be thinking of it from the outset so this opens up my options. One library that I have my eye on is wxWidgets. This is a very mature, cross-platform library that has a lot of documentation available. But these things can have their downsides too; wxWidgets has been around for such a long time and there are so many tutorials etc that there is a huge overload of out of date information out there and I have not yet managed to build the standard Hello World sample yet :-(
Saturday, January 06, 2007
Virtual PC's, Linux & Subversion
Back in September I concluded that I would need to develop the client and server code to run on both Linux and Windows platforms. I dusted off an old PC, installed Fedora on it and then pretty much did nothing for 3 months.
The problem is that I only have one monitor and I can't afford to buy a new one. To build the source on the Linux machine it needs to connect to the Windows machine so I need both up and running at the same time so I really need two monitors.
Well Santa didn't bring me a monitor for Christmas so I am still in the same situation now. However, last month at work I encountered a similar problem. For work I am developing a server called a MOS server which needs to talk to something called an NCS server. Because they are both servers they both need to listen on the same ports and you cannot have two programs listening on the same ports on one computer. So I told my boss that I needed a second PC :-)
One of my clever colleagues suggested I try out Microsoft Virtual PC which is now free. I had never heard of it before but now that I've tried it I love it! Basically it allows you to run a computer within a computer. So, I setup a virtual installation of Windows XP and ran my NCS server on it. Then on my main machine I can run and debug my MOS server which is connecting to the NCS server in my virtual PC. They both have independent IP addresses so it all works fabulously.
The reason for all this waffle is that Virtual PC allows you to install any operating system you like. Well pretty much anyway. Here's a website that lists all the OS' that work. So my cunning mind figured that I could use this solution at home to build a virtual Linux machine. After much faffing and fiddling it all works!
Here's a rundown of exactly what I did to get this setup working:
1) Downloaded and installed Microsoft Virtual PC 2004 from here.
2) Downloaded the ISO images of the Fedora Core 6 distribution from here. Note that a DVD image is also available and I downloaded that at first but Virtual PC works from CD images only! Oh, and this link is to the torrent files - Bit Torrent is GOOD, google it if you dont know what it is!
3) Created a new Virtual PC. Follow the prompts, select 'new hard disk' and then click 'Start'. You will get a message about having the wrong disk but that is because the hard disk does not have an operating system installed on it yet. That is step 4...
4) I dragged the ISO file for CD 1 of the fedora installation to the little disk icon in the bottom left of the Virtual PC window and then hit the enter key. This started the installation process.
5) Now I had some problems with the graphical version of this so I opted to install the text version instead by typing 'linux text' at the prompt. Click here for a nice guide. To fix my graphics problem I followed the instructions in this guide.
6) Once installed you'll get the login prompt so you need to login as root with whatever password you selected at installation. Here I stayed stumped for hours - how on earth do you get the nice graphical desktop when you've used the text based installer? You type 'init 5' at the prompt. Simple huh?!
7) I forgot to install a subversion client at the time so I simply downloaded one from the internet using the browser. I chose RapinSVN.
8) Now the tricky bit - setting up the Windows subversion repository to use Apache. Or is that the other way around? Guides, guides, guides. Here's the one that I initially used for this. However, I still encountered problems. Firstly, I had no clue what to use as my server name when installing Apache. I googled around and first tried using localhost and this worked but of course I couldn't access it from Linux. I had to fiddle with the httpd.conf to get something working.
I found out that you can use your IP address so here is what I had to change:
Listen 192.168.0.2:80
ServerName 192.168.0.2:8080
9) I started apache and nagivated to http://192.168.0.2/svn/using Firefox. This gave me a list of repositories. Note that I also had to do all the authorisation stuff mentioned in the guide linked in step 8.
There was also something else I misunderstood from that guide. When I first installed Subversion I just created my repository on the root of one of my drives but the SVNParentPath variable is to specify a parent for the ROOT of all repositories and it did not like me having just a drive letter so I created a root and some test repositories in there and that worked. I'll have to migrate my projects over later...
10) Now back on the Linux box, I was able to do exactly the same thing. I could load up my browser, type in the url from step 9 and I got my repository list. For RapidSVN, from the 'bookmarks' thing I right clicked and selected 'add existing repository' adding in the above URL but I had to extend it to include the actual name of a repo, and not just the root.
Viola! This worked! Here is a screenshot of the results of the above steps running in my virtual PC:
So, now that I've got that sorted I have no more excuses and I can get started!
The problem is that I only have one monitor and I can't afford to buy a new one. To build the source on the Linux machine it needs to connect to the Windows machine so I need both up and running at the same time so I really need two monitors.
Well Santa didn't bring me a monitor for Christmas so I am still in the same situation now. However, last month at work I encountered a similar problem. For work I am developing a server called a MOS server which needs to talk to something called an NCS server. Because they are both servers they both need to listen on the same ports and you cannot have two programs listening on the same ports on one computer. So I told my boss that I needed a second PC :-)
One of my clever colleagues suggested I try out Microsoft Virtual PC which is now free. I had never heard of it before but now that I've tried it I love it! Basically it allows you to run a computer within a computer. So, I setup a virtual installation of Windows XP and ran my NCS server on it. Then on my main machine I can run and debug my MOS server which is connecting to the NCS server in my virtual PC. They both have independent IP addresses so it all works fabulously.
The reason for all this waffle is that Virtual PC allows you to install any operating system you like. Well pretty much anyway. Here's a website that lists all the OS' that work. So my cunning mind figured that I could use this solution at home to build a virtual Linux machine. After much faffing and fiddling it all works!
Here's a rundown of exactly what I did to get this setup working:
1) Downloaded and installed Microsoft Virtual PC 2004 from here.
2) Downloaded the ISO images of the Fedora Core 6 distribution from here. Note that a DVD image is also available and I downloaded that at first but Virtual PC works from CD images only! Oh, and this link is to the torrent files - Bit Torrent is GOOD, google it if you dont know what it is!
3) Created a new Virtual PC. Follow the prompts, select 'new hard disk' and then click 'Start'. You will get a message about having the wrong disk but that is because the hard disk does not have an operating system installed on it yet. That is step 4...
4) I dragged the ISO file for CD 1 of the fedora installation to the little disk icon in the bottom left of the Virtual PC window and then hit the enter key. This started the installation process.
5) Now I had some problems with the graphical version of this so I opted to install the text version instead by typing 'linux text' at the prompt. Click here for a nice guide. To fix my graphics problem I followed the instructions in this guide.
6) Once installed you'll get the login prompt so you need to login as root with whatever password you selected at installation. Here I stayed stumped for hours - how on earth do you get the nice graphical desktop when you've used the text based installer? You type 'init 5' at the prompt. Simple huh?!
7) I forgot to install a subversion client at the time so I simply downloaded one from the internet using the browser. I chose RapinSVN.
8) Now the tricky bit - setting up the Windows subversion repository to use Apache. Or is that the other way around? Guides, guides, guides. Here's the one that I initially used for this. However, I still encountered problems. Firstly, I had no clue what to use as my server name when installing Apache. I googled around and first tried using localhost and this worked but of course I couldn't access it from Linux. I had to fiddle with the httpd.conf to get something working.
I found out that you can use your IP address so here is what I had to change:
Listen 192.168.0.2:80
ServerName 192.168.0.2:8080
9) I started apache and nagivated to http://192.168.0.2/svn/using Firefox. This gave me a list of repositories. Note that I also had to do all the authorisation stuff mentioned in the guide linked in step 8.
There was also something else I misunderstood from that guide. When I first installed Subversion I just created my repository on the root of one of my drives but the SVNParentPath variable is to specify a parent for the ROOT of all repositories and it did not like me having just a drive letter so I created a root and some test repositories in there and that worked. I'll have to migrate my projects over later...
10) Now back on the Linux box, I was able to do exactly the same thing. I could load up my browser, type in the url from step 9 and I got my repository list. For RapidSVN, from the 'bookmarks' thing I right clicked and selected 'add existing repository' adding in the above URL but I had to extend it to include the actual name of a repo, and not just the root.
Viola! This worked! Here is a screenshot of the results of the above steps running in my virtual PC:
So, now that I've got that sorted I have no more excuses and I can get started!
Subscribe to:
Posts (Atom)
