1000 code commits

The project hits another milestone, this time one of existential kind. Code repository now counts 1000 commits!

For those who don't know, in software for tracking file versions (VCS - version control system), a commit is a single version increment. VCS when hosted on the internet or corporate network allows collaboration among multiple individuals who work simultaneously on potentially same files. Even for one man teams it offers a benefit of jumping to older versions and recovering files when an unfortunate disaster destroys a computer or when something gets deleted accidentally. In case of Stareater VCS mostly tracks changes in code files but sometimes it has to deal with binary files like images.

Long development not only brought multiple rewrites of the game but also saw multiple versioning systems. Hopefully whole history from the first system was retained in the current one. First iteration (WhyNot) was not tracked by any VCS but the second iteration was tracked with SVN on Google Project Hosting (GPH) about half way through. SVN was first VCS I learned to work with and it was a bit clunky. It worked well when there were ordinary file creations, deletions and updates. File renaming would pose it a problem and folder renaming would freak it out and require delicate order of operations to get it through. The project was only 53 commits in when a friend told me about Mercurial (or Hg as it was frequently referred) and that GPH can seamlessly convert SVN repository to Hg. This VCS was easier to work with, renaming was not a headache anymore which was proven 77 commits later when the time came for the second rewrite where, among other things, whole file structure got reworked.

It served me well for 283 more commits when Google announced they'll retire their Project Hosting. They were slowly killing the service by first removing very useful "Updates" page (code changes and issue reports overview) and later on preventing upload of new releases in "Downloads" page until in 2015 they informed their user to find an alternative. That's when GitHub got plenty of new users and I with Stareater was one of them. It's very similar to Hg in how it works conceptually but in practice I had to go outside my comfort zone: I had to learn command line.

With all shortcomings SVN had a good GUI client and Windows Explorer integration. GUI for Hg was on similar level too but Git client despite looking similar didn't click with me. One provided by GitHub was and still is, to put it mildly, a garbage. It has custom non-WinForms interface, uses unreasonable amount of resources (probably just to run fancy interface) and one "Sync" button mentality which only works in trivial cases. Fortunately in the mean time I learned to use Git from command line on the job (the real one) and I started to use "Open in Git shell" button as often as "Sync". And that's where the project is now, 582 commits on GitHub and 1000 commits in total. I hope to see version 1.0 in less then 2000 commits :).

New star

It's a funny story how drawing a star has bothered me from the very start of Stareater project to the recent days. I'm not good at drawing stuff by hand so did next best thing, I made program do the drawing for me.

First one was simple, it generated a texture (image) with each pixel painted according to a certain formula and displayed it. Any change in star shape or color required changing the code and rerunning the program. Actually using the resulting image in game was a bit complicated. Back in a day I didn't know about PNG so I did screenshots of each star color variant, pasted it in MS Paint, saved as BMP, loaded in GIF editing program (which name escapes me and) and marked black as transparent. This is how it ended up looking:

Bottom row is how it looks in the game, mostly OK but could be better. Edge between star color and darkness of space is too prominent especially in the case of red.White center is invisible in yellow star and too prominent in blue. Top row demonstrates functional problem with the whole thing, since GIF has so called key based transparency (all pixels with "key" color are treated as transparent) there was no way to make some pixels semitransparent and if the star was on top of something then the fake space darkness would become visible.

At the time it served the purpose and after a while I decided to fix those shortcomings. I've made a more complex program which could save usable PNGs and could change parameters on the fly. It had a little framework for making procedural images generators and star image was just one implementation of the framework. Each image generator had it's own logic and set of parameters on GUI and the best thing was that one of the supported parameter types was symbolic function. You could type "4*x+0.5*y" if x and y were applicable variables and it would work.

Above are examples of some image generators and as I said, star image was just one of them. I also used the program for experimenting and fine tuning Stareater algorithms like starlane generator (middle image) and star positioning (right image). It was great tool for making quickly visualization.

On the other end I was exploring vector graphics for drawing starships. Inkscape was the best and de facto the only good tool for the job but it didn't click with me. It's great for hand drawing, so to speak, but lacking for technical drawing which happens to be my way of thinking when it comes to drawing something bigger then 20x20 pixel art. So I started making my own program for vector graphics, it was no good so I made another with different approach, it was better but not up to a task and repeated the process a few more times. The thing evolved from clicking points on canvas to typing them in table to writing a sort of programming language. Seriously:

On the right side is code, a sequence of points and shapes made with those points and on the left side is resulting image. It was not the most polished tool but it had potential. Unfortunately it took a lot of effort to keep improving it and code editor was devoid of usual IDE (code editor) luxuries like autocompletion and syntax highlighting. As I was developing programs in SharpDevelop, an opensource IDE, I was pondering an idea of using their code editor for my vector graphics language. And then I took the idea even further, to use C# itself for drawing. On the one end I'd to develop image generator as DLL (much like other Stareater plugins for AI and map shapes) and on the other end was program which continually monitored if DLL has changed, loaded new version of image generator and displayed a resulting image.

It's kind of return to the first program I had back in 2008 but with much faster code to image loop and so far it's serving me well. There is a bit of initial setup overhead for establishing OpenGL logic (making texture, setting perspective, setting rendering flags and drawing textured rectangles) but once set up it really easy to adjust and experiment about. Especially when secondary monitor is available, put C# editor on main screen, image preview on the other and watch the image change as you type.

And there is one more important bit of the story. While I was making all those programs I was collecting images of real stars in order to figure out what to actually draw with my programs. The challenge was to find an image were star was not a simple globe of light and not overly distorted by atmospheric noise and lens. When I finally made a satisfactory program and picked a good looking star the real fun has began, analyzing how colors change from black to blue to white and how to make similar looking stars of different colors. That part might be too geeky so I'll just leave a picture without too much explanation:

Works on my machine

Every time I make Stareater release I find a new program breaking bug. Not just game breaking like improper behaviour of the game but bug that completely crashes the game's executable. Previous release turned out to be no different despite my effort.

Truth to be told I don't have much in a way of release procedure, there are no automated tests, nor alpha, beta and release candidate testing periods. Heck, there is not much in a way of installation package either, just zipped folder. But I do try to check by hand if the zipped stuff works at all before uploading it. And guess what, it did work on my machine. It also worked on the other machine I sometimes use for developing the project. I asked a friend to test it on his computer but Christmas was near, I couldn't wait so I uploaded it anyway. Couple of weeks later I met with him brought the topic up and he gave it a try. Main window appeared over the whole screen but main menu was not there. Second or two later the program crashed with only the most basic and generic "Application crashed unexpectedly" error message.

That puzzled me because I specifically made a logic for trapping run-time errors and displaying the error details in a manner which reasonably competent user could report to developers (me). Since there was no such error message I had to reproduce the problem in the environment where I have some debugging tools. Guess what, I could reproduce it on my own computer on which it worked before upload. Trick was to download a zip file from the Internet, not use the one I uploaded. No, it was not the case of GitHub or SourceForge (for some reason GitHub hosts Stareater releases there despite SoruceForge's shady recent history) injecting something in my file but the case of Windows not trusting downloaded files and .Net security. Such circumstances made the Stareater to reject loading DLLs for AI logic and map generator. These DLLs can be replaced by mods so they are not exactly known to the Stareater's EXE in advance and not trusted because of it. To be honest I'm not the best informed about security surrounding untrusted code but I've been educating myself on one previous projects and it turned out Mono doesn't support it. If I remember correctly Mono simply ignores security related functions, doesn't explode with errors but as we wanted to sandbox 3rd party code we dropped the concept and moved to something else. In the future I could spend more time researching the topic and make some sort of DLL trust checking but for now I'll just allow all.

Sorry for inconvenience, next build will be available when some visible part of space combats is implemented. Or sooner if there is an interest.

Stareater iterations

Before I move to the next topic I'd like to make a little intermission. Stareater is long running project, it's about 7 years old and yeah, still not done. I admit I have taken on very ambitious goal back then but instead of giving up when things got over my head I have started over. If you have been following this blog you'd noticed just that, the current programming effort is a rewrite of the previous iteration. What might have been lost to time is the fact that there has been one before that. Below is a short description of each iteration and names I made up just now so I can refer to them in future posts: 

• DIY or "do it yourself" was the very first incarnation of the Stareater where I have literately went by coding everything myself in C++. Only "others" work I took was OpenGL for graphics and GLUT for "windowing" (how application window is started and managed) and mouse and keyboard input. Unfortunately such ambition had to hit a brick wall somewhere and it was in GUI department. Making GUI engine from scratch is science for itself and I've spent more time on it then making an actual game. Since I didn't take robust enough approach it got really tiresome. DIY iteration ended with pretty beautiful galaxy map (stars only, no planets), map navigation and minimal GUI for starting the game.
• CroVar or "Croatian variables" began as GUI mockup project for DIY iteration. It was C# Windows Forms project and at some point I realized I'd be happier to spend more time on game logic and keep GUI effort to a minimum. So I filled in mockups with a actual game logic from DIY and somewhere along the line I've decided to use Croatian words for class and variable names. That's why I'd call this version CroVar. This iteration got pretty far, stars, planets and colonies were fully functional, planets could be colonized, ships could be designed, built and moved, foundation for AI was laid down and even space battles worked!
• WhyNot is the current iteration of the Stareater. At some point CroVar code got big enough mess to consider refactoring it. At first wanted only to make better separation of GUI logic and game logic but I figured I could fix many other wrong decisions made in CroVar. And it resulted in a total rewrite with good amount of why not this too additions? In all seriousness "why not" approach saved me a lot more trouble than it has brought me and it improved the quality of the code and final product. Mod files got more intuitive format, OpenGL graphics are back, it got easier to code new features and simplified changing and maintaining old features.

Silent fail and rage

I raged last Friday over a stupid designed choice Microsoft made for .Net framework. It all started with benign change, I changed folder where game settings were stored. When I tried to test the change the main window refused to close. I stabbed red "close window" button a couple more times but to no avail. It seamed as absurd as not being able to start a car because a house few street away has new door. So I paused the program through debugger and it turned out that "close window" event was being aborted for some reason. For those unfamiliar with MS Windows Forms, program can subscribe to "somebody requested to close the window" event. On such event the program is notified and can act upon it and even prevent closing. Stareater GUI code is subscribed to such event and naturally I checked it out:

A single line that saves settings. There is no code that cancels closing. With debugger tools I followed internals of SettingsWinforms.Get.Save() and it's execution wasn't as I expected. It was cut in a middle of execution. I spent some time trying why and it turned out there was an exception being thrown (sort of runtime error) inside Save. When a program doesn't handle an exception it usually crushes but proper programming tool catches it and presents plenty of information that helps programmer to fix it. Take a look at Visual Studio 2010:

It clearly says where the code broke and why. Other C# IDEs (programs for programming) also offer such good debugging tools so it's kind of expected that every exception will show on programmers radar. But no, Microsoft decided that in certain conditions window must not crush. If exception occurs in such situations, framework will catch it and "handle" it by not doing anything. That's called silent failure. This is how it looks like when it happens within "window is about to close" event:

Do you see it? I made similar divide by zero error like on previous image. Take some time. It's hidden in the last line in the "Output" window at the bottom. On top of that full message doesn't fit the window. Now I hope You can understand, dear reader, why I was furious.

Reasoning behind silent failure is usually that end user is see less crushes. In my opinion it's just giving the sense of false security for end user and as demonstrated makes job unnecessarily more difficult for programmer. There is absolutely no benefit from it in "debug mode".

And in the end, how did saving settings prevented window from closing? Destination folder didn't exist. Normally when non-existent file is open for writing it is automatically created. Apparently creating missing folders is completely different beast but it's OK as long as I get informed when my presumption turns to be wrong.