farren@well.sf.ca.us (Mike Farren) (03/24/91)
NOTICE - this entire posting is Copyright (c) 1991 by Michael J. Farren. The only reproduction rights granted under this copyright are for electronic transmission between Usenet sites, and other sites connected to Usenet sites. Contact farren@well.sf.ca.us for reproduction rights other than the above. Level 3 - SPEED 'EM UP, MOVE 'EM OUT, RAWHIDE! In the last installment, I described the basic flow of the code for Lemmings. I went through a list of the functions which had to be done in order to make the game work, and talked a bit about why I believe that all of that functionality could fit nicely into the limited amount of memory available. In this installment, I want to examine that code in terms of some other criteria. This time, I'll look at Lemmings with an eye toward game speed vs. multitasking, and custom routines vs. ROM Kernel routines. For some games, particularly the "shoot-em-up" sort, the speed of the game is a valid consideration. Even the slight time penalty imposed by allowing Exec's multitasking kernel to continue to operate can result in perceptible jerkiness in the game, and there's little that's as irritating as a jerky shoot-em-up. For Lemmings, though, it's clearly not a criterion at all. Here's why: notice that in the list of functions I laid out in the last installment, nothing at all was said about needing to accomplish all of those functions in any given period of time. You just go through, doing everything you need to do to draw a screen, then you flip screens and do the same thing with the next screen, without worrying about the time it takes. In Lemmings, you don't need to switch screens every vertical blank time (1/60 or 1/50 of a second, depending). Instead, there's a minimum time between screens which looks, to my eye, as if it is about 3 vertical blanks long. Updating the screens every 20th of a second can work perfectly well, if there isn't any really fast movement on the screen (as there is not in Lemmings). A minimum time of three VBlanks is just fine. There is, however, no maximum time for Lemmings! Try this experiment: get to a screen with a lot of lemmings - 100, preferably. When the first lemming comes out, make him a builder, and listen to the rhythm of the "clanks" as he finishes his bridge. Crank the drop rate up to 99, and let all of the other lemmings out, and then make one of the pack a builder, and listen to the rhythms again. You'll notice that the clanks are a lot slower. That's because it's now taking so long to draw a screen that it's not completed in three vertical blank periods - it's taking four, five, or perhaps even six. And since the movement of the lemmings is a function of how often you redraw the screen, they will slow down if there are too many of them onscreen at once. This, by the way, also proves that off-screen lemmings aren't drawn. In the same situation as above, hit the "nuke" button, and wait for the explosions to start. Notice how they go pretty slowly? Now, move the map cursor so the exploding boys are all off the screen, and listen to how much faster those explosions happen. Drawing the explosions is the slowest thing that Lemmings does, so you can readily tell the difference when they are being drawn, and when they're not. So what does all this mean? Simple. It means that since the speed of the game is dominated far more by the time it takes to draw lemmings than by the time it takes the CPU to run, or the screen to update, any small time fluctations caused by multitasking would disappear into the noise. By my eye, it takes about 70 or so lemmings before you begin to see speed degradation. If the operating system took 10% of all the available time (a GROSS exaggeration), you'd see that slowdown happen at about 50 lemmings, and I doubt that anyone would call that an "unacceptable" level of degradation, or they would have already been complaining about it happening at 70! In real life, the OS is probably taking more like 1% of the time, if that, and you'd see the degeneration start at about 65 lemmings instead of 70, and I think that is the next best thing to no difference at all. This is also one of the arguments against eliminating multitasking, and in favor of leaving the decision strictly to the user. Consider what would happen if you were running another task, which uses up its entire time slice. Again, the Lemmings display would degrade - but it would still be able to deal with 20 or 30 lemmings without any degradation (it isn't a linear degradation - drawing in the background and objects is pretty much a fixed "expense"). Under those conditions, the game would run more slowly, to be sure, but might still be playable. And if you were doing something like a download to RAM:, where the actual time spent by the other process is mostly tied up in Wait loops, you might not see significant degradation at all. All in all, plenty of reason to keep the multitasking alive, especially since no one is ever going to force someone to multitask! And that brings up one final point about multitasking. If you can spare the resources to allow Exec to operate (as I have shown you can), then it seems only sensible to allow the user to decide what tradeoffs he wants to accept, and not decide for him. I'll give a concrete example: for the game which I did for SSI last year, STORM ACROSS EUROPE, there is a menu item titled PAUSE GAME. If the player selects it, I free all of the screen memory the game is using, create a small icon on the Workbench screen, and then close down the game, returning control to the user so he can do anything he sees fit. If he double-clicks the "Game in progress" icon, I rebuild the game and its screens, and resume play at the exact point that it left off. If, for some reason, there isn't enough memory available to restart (perhaps because another application has been launched), then I put up a window which allows the user to either quit, continue to pause until the memory is free again, or save the current game to a file which will allow the game to be restarted later. It's his choice - I don't enforce ANY of those choices. And, in the process, the user gains an invaluable thing - freedom. Lemmings, as it happens, has an ideal spot to do exactly the same sort of thing - the "Paws" button. Why shouldn't the player be able to hit the pause button, and then be given the choice of temporarily shutting down the game? If he did, then all of the buffer memory that Lemmings has taken (200K, if you remember the analysis in my previous posting) could be given back to the system, and there would be plenty of memory space available for real multitasking. Not only that, it would also suit the purposes of those who weren't willing to see any degradation at all in the game play, but who still wanted to, say, periodically check their email with a terminal emulator. It's possible, so it should be doable.