The title of this post should be taken with a truckload of salt: as far as I know there’s no way to boot a complete Linux distribution in one second. But it seems that General Software has developed a BIOS that can boot to LILO in one second - and that’s not bad at all! Basically, all the unnecessary things are skipped, such as waiting for the video card to load its firmware, detect devices, and so on. This enables the BIOS to boot incredibly quickly.
But heey… Wait a minute. If the hard disk isn’t detected yet, how can the bootloader start the OS?
Being both lazy and philosophically-minded I’ll try to speculate about the answer to that. My guess would be that all data that would be detected by a normal BIOS has to be hard-coded one way or another; the BIOS data has to be manually entered, or possibly the BIOS has a “detect everything now and then save the config” mode that’s not always run. That’s actually pretty neat…for embedded systems. It sounds completely useless for desktop environments where you change keyboards and mice and video cards and electrical pets (what?!) every now and then. But since the article mentions the medical device market, I’d wager that this isn’t a big deal for the target devices.
In fact, I wonder if this kind of optimized BIOS couldn’t be of value to a other embedded devices like home gateways and such as well.
But hey again, wait another minute or two. The slow boot times of home gateways is probably due to slow flash reading times rather than a second or two on the BIOS level. In fact, come to think of it, I don’t know if I’ve ever seen a BIOS on these devices. So, it seems like this optimized BIOS is only relevant to embedded devices of specific architectures - of which maybe the aforementioned medical devices belong. But what about non-embedded devices? Wouldn’t this improved BIOS be useful for desktop computers too?
Short answer: meh.
Longer answer: don’t think so.
Full answer: in all probability, optimizing the BIOS would result in minimal boot time improvements. Detecting new devices and loading the video firmware doesn’t take all that long - the biggest culprit is loading the actual OS itself.
But, and this is a big but, the article also mentions how they increase the Vista loading time from 74 seconds to 24 by adding a UDMA-capable driver to the BIOS. I don’t really see how they can group these two BIOS improvements into the same article - they seem to deal with wildly different things! Stripping the BIOS of unnecessary checks is quite different to adding a driver that increases efficiency a lot; the former isn’t very useful in most cases, but the second is incredibly useful!
And that got me thinking… The BIOS is often the bottleneck; wouldn’t it stand to reason to evolve a BIOS as much as possible to make the OS faster? If adding a UDMA driver speeds up the boot process by 300%, isn’t that the way to go for other bottlenecks as well - add improvements at the lowest level?
Oh wait. What this would end up as sounds suspiciously like a microkernel. I wonder if there’ll ever be a hybrid BIOS/microkernel.
This will be a very nerdy blog post describing some technical aspects of Spandex Force. Sorry in advance.
Many moons ago I complained about BlitzMax and 3D, and described how I solved that problem. Well, it turns out that I’m a moron and the solution described didn’t solve anything at all. This is essentially what I wanted to acheive:
Well, when I switched to a more detailed texture everything got jagged and crappy. Which I should have foreseen if I hadn’t felt so proud of myself for working around my limitations. I know, I suck. Anyway, I needed a better solution.
Someone in the old post mentioned that you can do 3D in BlitzMax by using textured polygons, but I don’t know if he’s ever tried. Using the common textured poly functions result in affine texture mapping, which is completely useless for depth effects. So, the only solution left was to go for proper 3D.
This is surprisingly simple in BlitzMax as long as you know how to do it. (Duh!) All you have to do is set up the projection matrix properly, and then do the primitive drawing commands. I won’t paste the dull code here, but it involves some trigonometry and a glFrustum() call (for OpenGL). That took care of the background itself.
But wait, that’s not all! What about the little objects on top of the background? Well, I wanted a billboard effect (the images should always face the screen) so I could either do a lot of rotations and draw everything in 3D…or draw the icons in 2D afterwards. I chose the latter approach and was thrilled when I noticed that OpenGL has a function called gluProject() which would let me find the screen coordinates from 3D space coordinates. Yay!
All for this little minigame!
Time for a short interlude. “Why are you mucking around with OpenGL like this,” the eager reader asks. “Isn’t DirectX the standard for Windows?” Sure it is, but I also want my game to run on Mac and Linux. So in my first approach I chose an OpenGL-only solution. But, as the experienced game developers out there could have told me, that just wouldn’t do. OpenGL works most of the time, but there are severe compatibility problems with out-of-the-box XP and Vista installations!
I was aware of this limitation, but I just didn’t know how to get around it. See, the magical gluProject() function has no corresponding function in DirectX. After a lot of messing around with matrices I managed to make the DirectX projection matrix similar to the OpenGL one, so the background could be drawn in both modes. But I still had no way to draw the icons correctly. I tried lots of various interpolative methods but everything looked pretty crappy.
Then it struck me like Mjölner from a clear sky.
In my old blog post I ranted about how old methods can be utilized to good effect even today, and there was one old method that I had overlooked. Can you see what I’d missed?
Lookup tables!
When running the game in OpenGL I could create a lookup table for the projected X and Y coordinates of the icons. This table could then be used for both the OpenGL and DirectX versions of the game to create identical results for the 2D icons. It worked perfectly, and this enabled me to have DirectX as the default renderer in Spandex Force from v1.1 and onwards.
Many times I thought about skipping the Catch ‘n Match minigame completely in order to have DirectX support, or shipping the game with compatibility problems. I’m happy that things worked out in the end!
Have you used Perl? Did you enjoy it? You strange bastard. I have a very simple criteria when it comes to programming languages: if I can comprehend the code of something I did a year ago, then it’s a good programming language. I like maintainability and intuitive naming; it’s pretty hard to mistake what int or float means for example. I can return to 6502 Assembly, Pascal, x86 Assembly, C, C++, Ada, Lisp, 68k Assembly, Scheme, BlitzMax, Java, HTML, PHP and a dozen other languages long after I’ve stopped using them, and I still understand decently what I wrote ages ago. But not so with Perl. Perl is the devil’s plaything.
Okay, enough Perl bashing - it’s not really a bad language at all. It’s devilishly efficient at text manipulation and everything else involving regular expressions, for example. But I simply can’t remember Perl syntax; it’s like a black hole in my mind. Everything I pour into it that concerns Perl gets swallowed up. I can look at Perl code I wrote a few years ago and have no idea at all what it’s supposed to do! So I guess Perl is a little like pearls before swine in my case. Perl before Karja could be a new proverb.
Incidentally, did you know that the Japanese have a similar expression? Similar to pearls before swine that is. Neko ni koban apparently means gold coins to a cat. Not that I’d know - I just know what neko means. I think the most advanced Japanese phrase I can put together is watashi no soseji wa ookii desu yo!
Aanyhoo, the reason I started ranting about Perl is this excellent article I found called You Used Perl to Write WHAT? It shows five good reasons for when you should use Perl…and some situations where it’s just not appropriate at all. I don’t agree with everything. Take number 3 of the good reasons for example:
A replacement for shell scripts: One of the worst things about shell scripting—whether in bash, sh or csh—is that the syntax of the scripts themselves is fairly hard to read. By using perl as a scripting language instead of a “traditional” shell, you can use much more C-like syntax without sacrificing functionality.
I may or may not be biased but I find shell scripts infinitely more useful than Perl scripts. For one thing, they are more maintainable. Even though sed and strange syntaxes are black magic, it’s possible for another person to decipher what shell scripts are supposed to do. Unlike Perl, which is made for supernatural gods!
Finally I can end with an amusing anecdote. A friend of mine went to a job interview where they asked him if he’d ever written some Python. “Python… Oh! Yeah, sure - I know that!” So they gave him some code to modify, whereupon he stared blankly for a few seconds before he realized “Damn, it’s Perl I know - not Python! I’ve never seen a line of this before in my life!”
He got the job anyway. He was able to understand Python decently based on the examples, and had made a good impression during the rest of the interview. See what I mean about code readability? Could you understand how to construct a new regular expression after having looked at some Perl code?
Mathematics is not one of my strengths; if I put my mind to it I can get by, but I lack the discipline to become skilled at it. I’ve read some calculus and algebra and combinatorics and statistics and whatnot, but in general I’ve just taken some courses only to forget everything I’ve learned shortly afterwards. The only maths I use regularly, except for simple arithmetic, is trigonometry. (It’s quite useful for 2D games.)
Logic is a completely different matter though. My job as a software developer at a Large Multi-National Corporation(TM) demands that I keep many of my skills sharp: the ability to juggle many ideas and projects, the ability to deal professionally and courteously with customers, and the ability to drink copious amounts of tea. Oh, and let’s not forget the ability to actually write code. Many non-programmers seem to think that maths is necessary for programmers, but in reality it’s logic that’s in high demand.
Speaking of skills at work, another thing that I tend to do there is solve sudokus. I find great comfort in spending my lunch breaks listening to the ongoing conversations while I solve a sudoku and - if something interesting pops up - add something to the discussion. Solving a sudoku is relaxing; you know that it’s solvable as long as you apply some logic, so you can take your mind off the possibly-unsolvable problems facing you in real life. At one time I did many sudokus per day, but now I limit myself to at most one for the sheer pleasure of it. A friend of mine mentioned that sudokus can be used to measure stress as well: if you find yourself taking too long on a standard sudoku, it might be an indication that you’re too stressed to think straight at the moment. True enough, but I find that if I’m too excited about something it also makes it hard to concentrate on the problem at hand. But then again, I suppose that that could be classed as stress as well, albeit of the positive kind.
Incidentally, speaking of sudokus, did you know that Benjamin Franklin used to amuse himself with mathematical puzzles similar in principle to sudokus when he was not busying himself with inventing just about everything you could imagine? Read the article and be amazed at the 16-by-16 magic square with bent rows that Franklin devised. You know about the magic square, where each line has to add up to 15? This is a magic square where each line has to add up to 2056. And all the coloured areas also have to add up to 2056. I’m just shaking my head at the complexity of the puzzle.
Read the article above to see more puzzles.
At one time I was pondering if I could devise a meta-puzzle game, where each puzzle mechanism would be unique, and one part of the problem would actually be to figure out the rules themselves. I started examining the sudoku to get inspiration, and quickly decided that it’s above my current skill to actually bring that idea to life. The idea is seductively simple: create a formal definition of the sudoku, and then expand that definition to encompass other mathematical puzzles. After you have created a suitable grammar of mathematics puzzles, you simply create a generator for new exciting puzzles. But in reality, this is much too complex for a layman in mathematics.
However, after having read about Franklin’s exploits in the puzzle domain, I wonder if this would have been something he would have enjoyed to create.
Today I browsed a DDJ article called C++ Hash Table Memoization: Simplifying Dynamic Programming, and I was immediately struck by a feeling of “why the hell didn’t I think of this!” If you’re not familiar with Dynamic Programming, here’s a very very brief summary:
When solving a problem you often encounter overlapping subproblems which - if you implement the solution algorithm naively - causes a sub-solution to be calculated many times. The most famous example of this is the Fibonacci sequence: 1, 1, 2, 3, 5, 8 and so on. Here’s an example pseudo code snippet stolen from Wikipedia which calculates a Fibonacci number naively:
function fib(n)
if n = 0 or n = 1
return 1
else
return fib(n + 1) + fib(n + 2)
From the code you’ll note that when trying to calculate, say, fib(5), you’ll calculate fib(3) more than once. Dynamic Programming is basically saying “hey, let’s stop being stupid! If we make sure that the result of fib(3) is only calculated once we’ll save a lot of time!” Quite so. Dynamic Programming may have the most idiotic name ever, but the idea is elegant and very efficient for certain problems.
The Wikipedia article then goes on to mention two DP approaches: top-down, and bottom-up. I’m getting all hot and bothered from mentioning both DP and bottom in the same sentence, but I’ll try to control myself. Bottom-up DP is essentially a way of restructuring the algorithm from a recursive solution to an iterative one, while top-down retains the recursive structure but uses an array for storing the calculated values. As the DDJ article mentions, arrays are most commonly used for storing values…and that’s where the real beaty of the DDJ article’s suggested improvement kicks in.
An array may be inefficient for some problems, so use a hash table instead!
In that short sentence I think I’ve summarized the whole DDJ article; the actual implementation of the proposal is irrelevant, and nothing else is particularly new or exciting. If not for this short addition to what’s already presented on Wikipedia I would’ve claimed that the article was dull and pointless - but now it turned from cow dung into gold! It’s amazing how a small idea can have such an effect. And of course, the fact that it’s such a small idea is what causes the I-Coulda-Thought-of-That reaction that’s oh-so-common.
To end on a high note, here’s a little fib for you:
Left
Right
Top-down
Bottom-up
I don’t give a damn
Just don’t waste any precious RAM
Jamie Fristrom has some opinions on Test-Driven Development after using it for a year, and it seems that they’re mostly negative. It’s quite interesting to compare this with his experiences with TDD after only a few weeks.
Some interesting observations:
After a few weeks:
TDD is forcing me to pay more attention to the code, and I’ve actually found bugs just from studying it.
After a year:
Frankly, I’m disappointed. I was hoping for a bigger, more obvious win.
The number of “false positives” - tests that break because my assumptions changed - greatly outnumbers the number of real bugs really caught.
Also, they say it improves your code quality. Frankly, my code quality is worse, as I frequently expose things I wouldn’t have exposed so I can get them under test more easily - and other abuses.
Quite a different story after a year, and I’m not really sure I agree with his final word. Code quality is subjective of course, but in my experience TDD often results in more clearly defined interfaces. Sure, sometimes one needs to expose methods and functions that could have been strictly internal, but they are often more well-defined and….well…functional, with a clearly defined purpose.
After a few weeks:
TDD seems very well suited to gameplay and AI programming. It’s hard to TDD graphics and sound, but in the virtual world that the graphics and sound are just a representation of it’s a good fit.
After a year:
And we still end up introducing lots of bugs into the code. Partly because we’re not covering everything (not only are we not covering cosmetic features, “is this sprite/menu item/whatever in the right place?”, we’re not covering experiments, “Will it be more fun this way?” even if those experiments end up sticking) and partly because you just can’t cover all the cases of all the functions, and partly because the tests don’t catch multithread problems.
Oooh… To me it seems like the engine/framework code was suitable for TDD, but when it comes to the artistic side things get worse. I agree completely with the latter sentiment: there’s no simple way to test these things using unit tests. I think the reason is hinted in the last part. Multithreading is a problem, but so is user input and everything that concerns subjectivity. They’re haphazard and volatile and other cool words that indicate that they’re inherently problematic because the system complexity increases in orders of magnitudes when you introduce these things.
I agree with his final decision that TDD is not for him; it might be useful for some parts of game development, but the biggest - and most critical - parts cannot be easily tested. At least I know of no simple ways to do so. However, TDD itself isn’t bad. It forces a functional structure; it captures stupid memory leaks and such; but mostly, it’s extremely useful for projects with multiple members.
Jamie mentions the fact that his understanding of the code has increased due to TDD, and this is iiiincredibly useful in some projects. “How did they intend this function to be used? I know - let’s check out the unit test!” Another benefit of TDD comes when you’re working with other people’s code, even if they have no unit tests for you to glance at: if you’re using valgrind or other tools of that crowd you’ll easily detect whenever you’re using a library incorrectly. Trust me, it’s not always obvious what exactly needs to be deallocated…but if you’re running a unit test for a specific function, you’ll know instantly when something was done incorrectly.
On a final note: have you noticed that I’m only mentioning unit tests and their benefits? There’s a simple reason for this: I like unit tests, but I hate TDD itself. Writing the tests first is cumbersome and a waste of time in my view. Maybe I’ll change my ways as I gain more experience, but my current (non-game development*) approach looks more like XP, with rapid iterations:
- Write a quick prototype
- Write unit tests for the most obvious functions
- Add more functionality and refactor if necessary
- Unit test the new functionality
- Repeat refactoring and unit tests until it’s good enough
I’m still undecided whether this means that I’m too unstructured and inexperienced, or if it’s actually a benefit to let code grow like this. Either way, I definitely think that unit tests have benefited in my work.
* The game development iterations look more like this:
- Write a quick prototype
- Sigh and re-write the prototype
- Add some graphics
- Re-design the game and re-write the prototype
- Sigh and re-design the game because the gameplay is dull
- Go back to the original design, modify it, and re-write the prototype
- Repeat for a while until all of the sudden I realize that the prototype is starting to look like a proper game
- Add music and graphics and make a final version
- Test the game
- Scream in frustration when I realize that the game sucks
- Re-design the game, add features, re-write parts, and repeat ad nauseum
I really don’t get one kind of coding mentality. Which one? I’ll tell you which one. The one where people insist that code should be written correctly from the start so that there’s no need for safeguards.
“What?”
Okay, I’ll elaborate a bit further with a theoretical example. Imagine that you have an embedded system of some sort, and a task needs to be kept running. The first thing to do is, of course, to ensure that the application is written properly, doesn’t crash, and handles errors in a proper way. Of course. I’m not against that in any way. But some people are of the opinion that this ought to be enough - that with enough unit testing and good programmers, this will result in an application that will not crash and will always run. In a perfect world I agree that this should suffice…but the fact is that people are stupid now and then and make mistakes.
Personally, I’m of the opinion that if a task is critical you need to write it securely and have a monitoring system that tries to jump start it again in case something happens. One of the most common questions I get when I propose things like that is: “What do you need that for? What could cause the application to crash?” I grind my teeth every time I’m asked that - if I knew what errors people might have made I would look for those potential errors instead! This is to ensure that the unknown factors are taken care of. Of course, a monitoring system can fail as well. But it increases the chance that things won’t crash and burn horribly - it just might work in some cases.
I know, I know: this is technically a bad approach to writing good software. If you have a safety net you might get sloppy in your implementation. Also, the point of not having a safety net might be that you want to find the errors, and the best way of finding them is to have the system crash. You’ll definitely know that something’s wrong then, and you can make a proper solution. But let me tell you a little story; a story about a couple of device drivers.
First there was device driver A. He was a strange beast, written by a team of Americans and then moved to India for further development. Not that that has anything to do with the issue - the Indian people are good developers and the same thing would have happened if another American team had taken over the driver development. The point is that I suspect that there was a distinct lack of understanding in regards to the driver’s internal logic, due to the new team’s relative inexperience with the code. This became very apparently when the driver received new functionality. The new functions were built on top of the old ones, and everything seemed hunky-dory until one day when a customer experienced serious problems.
“The device driver crashes,” said the customer to the friendly people in the middle who used device driver A in their products. “You suck! We will sue your asses and knit little sweaters out of your pubic hair.” This was a very strange threat, but it didn’t sound like fun at all. So the friendly people spent weeks trying to reproduce the problem. After many weeks of hard labour they finally reproduced it, and gave enough information to the device driver developers to fix the problem. Apparently it was caused by some internal states that were introduced; the driver could get locked up in one of these states, since there was no age timer that cleaned up those new states. But all was well, for a solution was found! Yayness!
But then there was device driver B, developed by a completely different team for a different set of products. Some time after the adventure with driver A, driver B started showing strange behaviours as well… Lo and behold - it appears that driver B has a problem that’s not completely dissimilar from driver A’s! The details differ, but the main concept of the problem (new functionality built on top of the old, but no safeguards were added) seems to be the same. If only there had been a general safeguard inside the driver, that examined the internal states and cleaned up strange states; maybe both driver beasts could have lived happily ever after, then! Sure, there would have been an error and this error would have had to be corrected. But the whole product would not have become useless in the meantime, risking potential deals with the customers who experience these errors.
Disclaimer: a safeguard mechanism might not have improved anything in these cases. It might have been completely useless, and provided nothing at all. But I’m firmly convinced that the damage could have been lessened immensely by a functioning safeguard, had it been in place…and that the mere chance of minimizing damage is worth the extra effort.
If you have an interest in agile development, take a look at this article: Pitching Agile to Senior Management. If you don’t care about agile development, have a look at it anyway - it brings up a few interesting points. To sum things up very briefly, the article goes something along these lines:
- Junior managers and up-and-coming engineers want to try agile development methods to increase productivity.
- However, they don’t understand the criteria upon which upper management decisions are made.
- This article explains that senior managers don’t have the same goals as engineers or juniors, and teaches the latter a few economic buzzwords to throw around.
- The end.
Despite appearances and my cynical summary, this is actually interesting! For example, the second page discusses the difference between introducing technological improvements and introducing economically beneficial improvements; this might be pretty obvious but it never hurts to get a nice summary of the different perspectives. Also, the third page has a very very important tip: you don’t always have to get permissions for everything. I seriously don’t know how I’d get anything done if I didn’t have both the initiative to make my own decisions, and the (grudging) acceptance from managers that it’s okay to do things my way. It’s an old cliche that you can’t get denied permission for something that you don’t ask permission for - but it’s also very true. As long as the results are good, no one will hang you for your slightly questionable methods.
Unless you work in bad companies, of course.
I’m a big fan of Dilbert, but I would never accuse my bosses of being pointy-haired. I often critizise their decisions, but I don’t think that they’re incompetent. Rather, as the article suggests, I think that they’re smart people who are making the best decisions they can based on the information they have…and the goals they want to achieve. Sometimes, when I read horror stories on the ‘net, I get the impression that other people either have completely moronic bosses or a complete lack of understanding for why decisions are made. I try not to be one of the latter people, and I’d never be able to work for the former. I don’t want to end up in…oh, the horror of this flawed and unhumorous pun…bad company.
And speaking of bad companies: time to bring up a bad thing about the article above. Take a look at this quote:
A few months ago I was educating a client about agile development and they told me that they weren’t interested in pair programming because of what they felt to be obvious loss of productivity in having two people do the work of one. I pointed out that with pair programming, when you’re doing it right, both pairs are exhausted after five to six hours.
This seems to be a prime example of bad management.
“Lesse, people who produce get tired. Thus, if a person is very exhausted he must be very productive. Let’s aim for exhausted people!”
Can you spot the errors in that line of thought? At a recent meeting I noted that my company doesn’t use the term productivity. The reason was that many people assumed that increased productivity was the same as more effort, so they exchanged produtivity for a different, more positive, term. At the time I was irritated at this obviously ridiculous attempt at giving productivity a more humane name in order to disguise it…but after reading this article I suspect that there really might have been good cause for it.
Finally, if you’re anything like me you might have wondered what Moore’s technology adaptation chasm that was mentioned on the first page of the article is. Wonder no more: I looked it up for you! To sum things up briefly, Moore divided people into Innovators, Early Adopters, Pragmatists and Traditionalists, and noted that there’s a chasm between Early Adopters and Pragmatists; a new technology must cross this chasm before it can become common practice.
Now, wasn’t that fascinating?
God had it wrong. The seven deadly sins aren’t wrath and sloth and whatever is in that list. He forgot a very important one: inefficiency. In fact, it should be made into a commandment:
Thou shalt not create a situation in which other people are waiting for you in order to be able to perform their tasks. This will only unnecessarily drain the company’s resources and make the waitees incredibly cross. So sayeth I.
Say, hypothetically, that a person is entering a new project and has taken upon himself the task to write a library. This project attempts to be agile and contains very little documentation. In fact, it is encouraged to store knowledge in people and not on paper. On Monday he proposes an API to the library in question but receives no response. On Wednesday he offers a more detailed description of the API and brings a few ambiguous situations into light. Still no response. He discusses the functionality verbally with some people, and then offers an even more detailed description of the API the following Monday. This is met by a short e-mail response at last: “Let’s discuss this tomorrow.”
Well.
Hypothetically, what’s wrong with this situation?
First of all, keeping little to no documentation may sound fine in practice, but it will lead to ambiguous interpretations and difficulties for new team members. Secondly, despite this it can function well if feedback is offered speedily; but it will cause unnecessary work due to unclear specifications otherwise. Thirdly, the lack of information in the response makes it totally useless: does the API need corrections; does it need to be re-structured totally; is it passable but needs to be understood by all parts - the e-mail response tells us nothing about that. It becomes the final nail in the coffin: it becomes impossible to perform any more work on the library because there’s no way of knowing if it will be useful or not. Many hours of productive time is lost because of this. The person responsible for the library will most probably rant about the situation on his blog instead of doing anything worthwhile - effectively losing the company money since a useful pastime is not possible to find.
I hate inefficiency. Or rather: I hate waiting for other people. I don’t care how others do their work, but I loathe being unable to do something productive when I want to. It just leads to frustration, cynism and irritation. The library in question could be written in a few days if the desired functionality was known and specified. In a perfect world projects would be agile, but there would be non-ambigous and thorough specifications for everything. A contradiction in terms? Maybe, maybe not: I fully believe that a team can work in an agile manner but still keep information readily available.
However, playing the devil’s advocate I have to blame myself as well. The information is readily available - it’s simply spread out over several people who have lots of other issues to deal with. If I were truly desperate to be productive I would hunt them down and demand instant feedback on my thoughts, and ask them to guide me to the ones who could offer constructive criticism if they weren’t able to give me feedback. Maybe that’s what’s expected and required in a situation like this. Personally, I would prefer it if people could offer these hints by themselves, without any external pressure.
Maybe I should think of that the next time someone is waiting for a response from me.
Final note: I used the term deadlock in the title, but that’s of course not applicable anywhere. This is simply a mutex that’s locked for too long. But I like the power and force of the word deadlock, so I used it anyway. Sue me.
2007. Taste the word. It hints of futuristic worlds and scientific advances unthought of just ten years ago. But at the same time it’s mundane and common - it’s simply the year we live in right now. And was ten years really such a long time ago? That’s what I asked myself when I found an old zip archive called FirstProg.zip. Granted, it’s definitely not a complete colllection of my first programming experiences: I dabbled with game and demo programming on the C-64 and Amiga before this. But some of my earliest PC projects were found in this archive! Let me show you a little bit of what I found. I’ll begin with a vague timeline:
- Pre-1996: I messed with C-64 and Amiga hobby projects of various types, such as an Amiga fighting game called Time Fighters. I actually received some praise for it - it had a much better control scheme than the over-hyped Body Blows. Not that that says much.
- Spring 1996: I bought my neighbour’s 40 MHz 486 PC. This was my first real experience with x86 computers, and I quickly learned the joys of having an incredible amount of RAM to use in Fast Tracker II, compared with the limitations of an Amiga. At first I had all of 4 MB RAM, but I soon upgraded it to a massive 16 MB!
- Autumn 1996: I heard rumours about an assembly programming group at my high school, and soon joined the four other students interested in diving into the mysteries of x86 ASM. Soon after I had gotten a copy of Turbo Assembler I created this:
I intended to do a very straight-forward Space Invaders clone, but due to sloppy coding I forgot to clean up the bullets when they had hit the bottom of the screen - it looked like a big pile of crap after a while. In addition, my horrible green UFOs had been turned sideways due to…erm…inexperience with x86 memory addressing, and almost looked like green bottoms instead. So the project turned into Shit Invaders. Oh yes, and as you can see I was childishly impressed by David Eddings when I tried to think of a handle to use.
I also experimented with Mode X scrolling. (Don’t ask what it is.) Childish humour resulted in the following scrolly effect:
The scroller starts small with the text “PEOPLE HAVE BEEN COMPLAINING ABOUT THE SIZE OF THE FONT IN MY SCROLLIES, SO…” and ends with a massively enlarged “BETTER?!”
I also worked on a platform game that I intended to call Satan Claus:
It may not look much, but there are actually three parallax layers: one background that simply were the gradient blue tones for the sky, one layer with the blue hills, and one layer with the foreground. I’m sure that it might even have looked pretty nice if I’d had a real artist to help me instead of making some crappy graphics myself.
Back to the timeline:
- Spring 1997: By now we were finishing high school and had to present what we had accomplished during our studies of the illustrious assembly language. This was one of the things I ended up showing to the teacher:
A simple demo effect with a generated flag (and its accompanying gradient colour table) and a bitmap manipulated by a sinus table in various ways. Simple enough, but it looked really nice. Go me! I did something that wasn’t just silly!
Of course, I compensated that brief bout of seriousness with making an action game inspired by Smash TV and Robotron, called Mega Brain Splashing:
A curious tidbit: this game sucked incredibly hard, and one of the reasons is that I had never actually played neither Robotron nor Smash TV - I had just read about them in video games magazines and imagined what the gameplay must be like. Curious tidbit number two: the title screen for Shit Invaders also featured a fire effect, but the difference was that by the time I made Mega Brain Splashing I had learned how to make it fast enough in real-time instead of just using a static picture.
More timeline business:
- Autumn 1997: I joined the Swedish military for 10 months of mandatory torture. Interestingly enough this led to a burst of creativity since I was located at the same place as one of the guys I’d been doing assembly programming with! Ka-ching! Touchdown! Together we experimented with many different subjects: 3D graphics, C programming, low-level optimizations of Bresenham algorithms, and so on. By myself, I continued making strange small games and proof of concepts:
I toyed with having enemies move in pre-determined paths, in something that would have been Mega Brain Splashing 2. This time there would have been a two-player mode.
I also started Mega Brain Splashing: The Medieval Interlude. This was going to be a gory action-RPG that combined exploration with lots of blood…and - as can be seen above - stolen graphics from the Exile II game. But most disturbing was probably this little game:
A Star Wars game completely written in assembly! I’ll spare you the text from the scroller, but I’ll note that involved mentions of homo saunas, epic dangers, and another trench run. Oh, and see how quirky it is - “Press Escape to play.” I must have thought that I was very clever and funny indeed. The game itself is quite simple: you pilot an X-Wing that has two shields - one to the left and one to the right. Hitting obstacles removes shield strength. If you shoot targets on the way you get points. And if you reach the end of a “level” you must fire off your proton torpedo at a specific goal. That’s it.
Eventually I was let out of the military and ended up studying computer science; that’s when I went over to the dark side - i.e. Windows programming. Many small games and projects emerged from that transition, one of which was in fact Mega Brain Splashing 3:
Ironically, many people found MBS 3 better than MBS 4 that I created later. There are no technical reasons for it: MBS 3 was in 8 bit colour, I used colour lookup tables to simulate transparencies, it just consisted of a single static map, it had a more basic gameplay, it had no bosses, the weapons weren’t very balanced, it wasn’t compatible with all graphic cards (due to the weird software rendering I used)… All of these things were improved on in MBS 4, but I just might have forgotten to transfer the most crucial part: the fun factor.
It’s often said that ideas are worth nothing, and only the implementation matters. However, this might really be just part of a bidirectional fact: ideas without implementation are useless, but implementations without a good idea results in a loss of this elusive fun factor. Maybe, in creating MBS 4, I concentrated too much on the technical aspects of the game instead of stopping to think: “Is this really fun? Am I basing the game on a good idea? Am I injecting my usual experimental mood and quirkiness into the game? Or am I just trying to improve the technical bits?”
Next Page »
