Video | kometbomb

09 Nov

Plenty of Room, Part II

This is the second part of the epic (~~two~~ three-part) series of articles about tiny intros, the previous part was an essay about 256-byte intros in general.

Ed. note: Since this article seems to take forever to finish, here’s the first half of it. The (hopefully) final part will detail more of the specifics.

rubba As stated earlier, tiny intros written in assembly language fascinate me. I have written a few in x86 assembly language, here’s one of them. I have tried to make the inner workings of the program as accessible — or, at least as thought-provoking — as possible even if assembly wasn’t their weapon of choice.

I’ve included the original DOS intro (you can use DOSBox to run it, it should also work on Windows XP) and a Win32 port of it, written in C while trying to keep the original structure intact. I’ll also try to explain the general idea of the effect in pseudocode where syntax can be an obstacle. The archive rubba_c.zip contains the source code, rubba_b.exe which is the compiled Win32 executable and RUBBA.COM which is the 16-bit MS-DOS executable. To compile the C program, you need the TinyPTC library (like SDL but even more bare-bones).

I won’t go into details about x86 assembly language, I suggest anyone interested first reads an introduction and learns some of the basics. However, I’ll try to make the code look interesting, explain some weird or obfuscated code and probably show some basic size optimization tricks.

The Effect

The intro, called rubba_b, shows one effect: a twisting bar drawn using primitive light-shaded texture mapping. The color palette and the texture are generated run-time. The texturing is done using linear interpolation and no vector math is used even if the bar looks like it is rotated. The lighting is an extremely simple approximation of the light source being exactly where the camera is located. That is, the length of the textured line directly determines the light.

If looked from above, the bar will be a tower of squares. If one of the squares is rotated around the center, the corners will move in a circular pattern. So, the X coordinate will be equal to cos(corner_number*(360 degrees/4)+square_rotation), the Z coordinate (why Z? Because it goes towards the screen) is equal to the sine but it can be discarded because we will not need it for perspective calculation. Remember, we’re short on bytes.

We then modulate the bar rotation for each square in the tower. If the amount of rotation changes when moving up or down the tower, the bar will twist. If the rotation stays the same for each square, the bar will rotate uniformly and look uninteresting.

The textured horizontal line is drawn from each corner to the next corner, from left to right. If the line would be drawn from right to left, we know it isn’t facing towards the camera, another line facing the camera will be drawn over it and we simply skip the line. The color value fetched from the texture is multiplied by the line length which makes short lines darker.

Still with me?

The Code

Initialization

First things first. We need to set the video mode before we continue. In the Win32 version we simply open a TinyPTC window, in the original version we need to tell BIOS to go in a nice 320x200x8 video mode (the de facto video mode back in the day).

C	asm
`ptc_open("rubba_b",320,200)`	`mov al,13h int 10h`

In the above code, the Win32 part is self-explanatory. The assembly bit probably needs some clarification: we put the number 13h (hex) in the 8-bit register al and we request for interrupt 10h. This is the BIOS video interrupt and since register ax (which consists of al – “low” – and ah – “high”) equals to 0013h (when the program starts, ax is always zeroed), BIOS will call the routine for changing the video mode (ah=00h) to 13h.

If above sounds complicated, don’t worry. It’s just a matter of memorization – similar to how you would memorize the function name for changing the video mode.

The next thing we need is some space for the texture, the sine table and the double buffer. In the Win32 version this is obvious, we just add a few arrays (although since TinyPTC only supports 32-bit video modes, we will also have an array for the palette). Again, in the assembly version we won’t use any fancy way to reserve memory to save some precious bytes: we simply decide certain areas of the memory will be used for whatever we want. The benefits of no memory protection and single tasking. ;)

C	asm
`short int sinetab[SINETAB]; unsigned char palette[2564]; unsigned char texture[256256]; unsigned char screen[320*200];`	`mov dh,80h mov gs,dx mov dh,70h mov es,dx mov dh,60h mov fs,dx`

The assembly version basically sets the register dx to 60xxh-80xxh (we set only the high byte, i.e. dh to save bytes, thus the low byte of dx is undefined – it won’t matter) and puts the value into various segment registers (es-gs).

This makes it so that if we use the different segment registers, we can access each of the three 64 kilobyte segments as a 64 kilobyte array. E.g. the sine is in gs, thus mov ax,[gs:2] would move the second word in the sine table in ax. In C, the equivalent would be short int value=sinetab[1] (note how the C compiler knows the fact that a word is 2 bytes but in assembly you have to take care of that yourself – all memory accesses are always by the exact location, not the array element!).

All this is because in 16-bit memory accessing you can see only 64 kilobytes at one time. You can’t have a 128 KB array, nor can you have two 64 K arrays in the same segment. It’s something comparable to having a flashlight and a big sheet of paper in a dark room; you can move the light to show different areas but you will never see more than what there is in the spotlight.

The next two parts calculate the sine table (back in the day you simply could not do trigonometric stuff real-time, even in hardware — although in the intro it’s there just for show) and set the palette. This is pretty straight-forward stuff across the two versions. The only difference is that in the Windows version we have to remember the palette has 8-bit color components and the original has 6-bit components (0..255 ~ 0..63). And of course, the Windows version simply puts the values in a palette look-up table (because 32-bit video mode doesn’t use a palette) and the original actually sets the video mode colors.

I won’t reiterate the source code for the sine table and palette change here, I think you should be able to figure it out by comparing the source code. But in theory, here’s how to change a color: first, write the color index in port 3C8h, then write the three color components in port 3C9h (hint: dx first contains 3C8h and it’s incremented to 3C9h to save bytes).

The sine routine increases the angle (st0 the topmost register on the FPU) by 2*PI/32768 (a full circle is 2*PI, the sine table has 32768 elements). You probably should check some FPU tutorial, arithmetic on the 8087 is pretty interesting due to the stack-based architecture. For example, you first push in two numbers and then do an add, which (in most cases) pops out the two values and pushes in the result.

The texture generation bit is interesting. It also was annoying to port to C thanks to the fact you have to emulate how some instructions work – there are no accurate analogies in the C standard. A big thanks goes to baze whose code I originally cannibalized for this (I think). To be honest the conversion doesn’t work 100 % accurately but does still produce a nice texture.

The algorithm uses addition, bitwise operations and other simple things to achieve complexity thanks to how processors do arithmetics. Mainly, the results from an earlier calculation is carried over to the next calculation — when an addition or a subtraction overflows, i.e. the result is too large or too small to fit in a register, the processor lets the result wrap over but sets the carry flag.

This is quite similar to how you would carry numbers when calculating with a pen and a paper. The flag affects the results unpredictably because it’s used across quite different operations; usually you would just use to to add big numbers together as in the pen and paper example.

The Main Loop

Here is the meat of the code. The C version has many variables that are named after registers in order to see the connection with the original code. Sometimes, as with the 8-bit registers, some code doesn’t work exactly as in the original because you can’t do things similarly in C. E.g. you can’t have two variables that also are a part of one big register similarly how al and ah form ax (well, you can with pointers or unions but that is besides the point, kind of).

Self Modifying Code

I use self modifying code (SMC) in a few places because it produces faster and also much simpler code. For example, if you have a variable that is changed in a few places but used by one instruction only (and the instruction performs arithmetic or otherwise accepts a constant parameter), it’s much faster to store the variable where the constant for the instruction would be. That way you don’t have to read the variable in a register and then use the register to do something.

E.g. Let’s multiply cx by the variable foo:

Original SMC

  push ax ; save ax
  mov ax,[foo] ; move variable foo in ax
  imul cx,ax ; multiply cx by ax
  pop ax  ; restore ax
  ...
  mov ax,123   ; set foo ...
  mov [foo],ax ; ... to 123
  ...
foo: dw 0

  imul cx,123
foo equ $-2
  ...
  mov ax,123   ; set foo ...
  mov [foo],ax ; ... to 123

We can exploit the fact imul (signed multiplication) accepts constant multipliers. If you looked at the code with a hex editor, you’d see 123 next to the opcode. You can change the constant run-time and you do that exactly like you would change a variable: if you just define foo as the address where the constant is (the above code defines it as the last two bytes (i.e. word) of the previous instruction: in NASM, $ is the current location and $-2 equals the address of the previous word).

To be concluded…

22 Sep

Introducing My Latest Projects

… Or, How to Procrastinate Productively.

I decided to make one of my current projects open source and post them on Google Code just for fun. The project is a tool chain that I’m using to remake Thrust. In reality, I decided to divide the project into two separate projects: the actual game engine (called klystron) and related tools, and a music editor that uses the engine.

Here are two videos I made a while ago that demonstrate the engine. The first is the music editor (called klystrack) — it’s much less ugly at the moment but the sound synthesis is the same, and that’s what matters:

The sound engine (“Cyd”) is basically a very simple software synthesizer with capabilities comparable to the SID or any 8-bit machine from the 80s. The editor is a fairly standard tracker, much like GoatTracker.

The graphics half of the engine is basically a wrapper around a quite fast collision detection system (pixel-accurate, or it wouldn’t be much good for a thrustlike) built on SDL. It also does background collisions and drawing as well. As you may have guessed, the whole point is to provide a limited but still helpful set of routines that are useful for creating 2D games not unlike what video games were in 1991.

And, here’s a proof I’m actually working on the actual game (the sound effects are created in real time by the sound engine):

A note on Google Code: it’s rather nice. It provides the standard open source development stuff like source control an such but I really like how clean and hassle-free it is. Adding a project takes a minute and after that it’s simply coding and some quick documentation on the project wiki. The project wiki is good example of how simple but elegant the system is: the wiki pages actually exists inside the source control as files, just like your source code.

Go check Google Code out and while you’re at it, contribute on my projects. :)

08 Sep

You Can Stop Programming Now

The above is puls, a 256-byte intro by ?r?ola. It’s basically a raytracer with screen space ambient occlusion (which makes it so much realistic and cooler). While tube — which I think was the best 256-byte intro until now (when design and code are judged together) — also did raytracing of a cylinders, and after that many other intros did similar tracing of more complex surfaces, puls simply crushes all of them with objects that are formed by multiple plane surfaces (e.g. a cube would be a combination of six intersecting planes), a very nice color palette and that delicious ambient occlusion.

Thinking it out in C and sketching it out in asm took about a week, byte crunching took another one… that’s like forty hours of full focus and eighty of playing.

It’s also really, really slow which is the only minus especially because you can’t run 16-bit executables on Windows 7, so you have to use DOSBox to watch it (or, use a boot floppy to run it or something). There’s now a Windows port including a screensaver, see the Pouet.net page for more. A big thank you to nordak5 who was kind enough to upload a video on Youtube.

?r?ola has also included source code with the binary that you can find over here. That said, I’ll be deleting all my own source code since perfection has finally been achieved and there is no need for programmers anymore.

18 Jun

Thrustlikes

Probably my most favorite video games are thrustlike games – as in roguelikes begat by Rogue (ADOM, Nethack, Angband, Moria et al.). What I mean with a thrustlike is a game derivative of Asteroids, Lunar Lander, Gravitar and Spacewar that feature a simple physics model, a rotating spaceship and a button for thrust. Hence, “thrustlike” and not “gravitarlike”. Also, mostly because I really like Thrust.

Here are some of the games I consider the best examples of this genre.

Thrust (1986)

What I think Thrust does that makes it so much better than Asteroids and other household names is that it takes the simple rule of motion and inertia, and adds another basic concept, counterforce. In Thrust, you not only maneuver the ship through narrow caves but you also have to lift a heavy load (a “klystron pod”) that swings under the ship. And, in most cases the roles are reversed when the heavy pod transfers its excess kinetic energy to your stationary ship, sending you both spinning towards the nearest wall. However, the whole gameplay doesn’t feel as random as it is with many modern physics based games that often require luck or endless trial and error. You are always in charge of the physics, if you are a good enough pilot.

Another thing that I like about Thrust is that the player is easily able to skip a few levels by activating the self-destruct sequence of the planet by shooting the power plant a few too many times. Why I like it is that in a way you feel like you cheated the game (although, you also lost a lot of bonus points). However, without a doubt this was added to make it easier to quickly get to and practice the later levels, it’s a very nice touch it’s built in the game world. It is also possible to get hefty bonus if you manage to both fetch the pod and also destroy the power plant.

Thrust has a reputation for being hard but I can’t really agree with that. The game has a handful of levels and the regular levels are quite easy to finish when you get the hang of it. However, after that the gravity is reversed and the levels loop from the beginning and after a successful completion, the walls turn invisible. And then I guess the game goes reversed-invisible¹.

Another proof of the game’s excellence is that it’s probably one of the most ported (officially or not) games, when it comes to radically different platforms. There are equally playable versions for the BBC (also the original version), the C64 (with a rocking Hubbard tune), the 8 and 16-bit Ataris and unofficial ports for Vectrex and Atari VCS². There also is a C rewrite of the game engine that is open source, which I guess ensures the game can be ported to any semi-modern platform.

There apparently was a sequel, that wasn’t so well received (proving more does not equal better) and I have never seen it.

Gravitar (1982)

Gravitar, on the other hand, does much of the same. Thrust (1986) was obviously very influenced by Gravitar (1982)³, which was probably influenced by Asteroids (1979) and Lunar Lander (1973, 1979). Both Thrust and Gravitar have planets to visit, fuel to be beamed up, enemy bunkers that shoot back and, of course, gravity. But to me, Gravitar doesn’t have as crystallized gameplay as Thrust. Thrust is as solid as, uh, Gravitar’s vectors are, umm, sharp.

https://www.youtube.com/watch?v=VZYW62S6TP0

What’s pretty neat in Gravitar is that you can select in which order you play the levels, the levels are simply presented as planets in a solar system and you have to fly the ship avoiding the star that is in the center of the solar system. This also gives another challenge (or a possibility to optimize your gameplay) since the star’s gravity can be exploited to save fuel. Each level also is quite different from the other levels.

Oids (1987)

Another game I really liked was Oids. It combines yet more favorites of mine with Thrust: Choplifter and Space Taxi, both outside the strictest requirements of the thrustlike genre. In Oids, the klystron pods are replaced with little guys (android slaves, or ‘oids) that you have to pick up, first of course having to land the ship carefully, and take up to the mothership. Oids is so loved that the Atari ST emulator Oidemu was made just to run the game, which wouldn’t run on other emulators — and Oidemu subsequently didn’t bother supporting any other games.

The saving the little guys idea is lifted from Choplifter (get it?) in which you use a chopper to demolish prisons and then land nearby and wait for the little men to climb aboard, making multiple runs as the chopper can carry a limited amount of men. The gameplay is much speedier in Oids, you constantly have to dodge incoming bullets and homing missiles and the levels generally are much more open than in Thrust or Gravitar. In all, Oids feels like very natural progression from Thrust.

Maybe one factor that made the game so special was the fact it shipped with a level editor.

Space Taxi (1984)

If we bend the rules what makes a thrustlike, Space Taxi is more than a worthy addition to the genre. Especially so, if you think Lunar Lander fits in the genre — both games have similar controls (thrust up, down and to the sides) and also the common goal of landing quickly yet safely.

There was a nice clone of Space Taxi on the Amiga featuring a caveman flying a stone-age version of a helicopter (think Flintstones). The game was called Ugh! and it was later ported to the PC (it’s great) and C64 (it’s crap).

While Ugh! looks gorgeous and is fun to play, what Space Taxi does infinitely better is that every level in Space Taxi is very different from the other levels, and that is not just the layout that changes (on top of that Ugh! uses the same tiles over and over, however nicely pixeled they might be). The rules of the game are often deviated slightly. For example, one level has a beanstalk that slowly grows leaves on which you can land (and the passengers start appearing on) and others simply have disappearing walls or teleports. I guess that still makes the game quite unique, since even now games rarely have radically different levels.

There also is Space Taxi 2, which is a legit sequel but the tiny voice in my head says it can’t possibly measure up. It’s worth a check, though, as it has the same level designs as the original.

Solar Jetman: Hunt for the Golden Warpship (1990)

Solar Jetman: Hunt for the Golden Warpship is pretty much exactly what Thrust was years earlier but with updated graphics. The only difference is that in each level you have to find a different object, each being a part of the Golden Warpship and various other items which upgrade the ship you pilot around. There’s also a bit of Oids in the game, as it features more shooting and has enemies that follow you around the level.

The game provides welcome variation to NES games and I can see why it wasn’t a success among the younger gamers despite the great graphics (got to love the smooth rotation of the ship). The controls are smooth but as all games of this genre, Solar Jetman can be a handful. Especially, if you are looking for more straight-forward action.

The game is the successor to Lunar Jetman (which shares only half of the name and virtually no gameplay elements, except for the little spaceman that you have to get back to the mothership when your probe is destroyed, see above video) — Solar Jetman was developed by Rare who in fact were called Ultimate Play The Game who developed Lunar Jetman for the Speccy (and loads of other very successful games). Solar Jetman was also going to be released for most of the home computers of the time but the ports were canceled and only the C64 port is available to the public.

“Caveflyers”

In the mid-1990s there was a boom for so called caveflyers (from Finnish “luolalentely”) here in Finland. The caveflyer genre probably owes more to Spacewar as it’s mainly about blowing up the other players. There were dozens of similar games that all featured hotseat multiplayer action (some even had computer controlled), various weapons and levels and most importantly destructible environments.

There had been a lot of similar games by hobbyists before the boom, the single game that started it all probably was Gravity Force on the Amiga. However, I think the flood of cavefliers (in Finland, at least) was triggered by Auts and Turboraketti on the PC. I am very sure different areas had a bit different ideas what was the hottest game but at least to me, Auts was it. After that more and more clones started appearing with constantly improving quality and broadening weapon arsenal. My favorite probably was Kaboom. On the Amiga, there was a bit older similar game called Mayhem (1993) which we played a lot. There’s an abandoned PC conversion that you can find in the linked thread.

This subgenre is still alive and there are many modern caveflyers that have Internet multiplayer features and so on.

3D thrustlikes and other oddities

There have been various Zarch (1987) on the Acorn Archimedes (ported later in 1998 as Virus for the Amiga, Atari ST, ZX Spectrum and PC) features similar controls for the player ship except that there now are two rotation axes. The gameplay however features minimal interaction with the landscape as there are no caves. Later in 1999, Psygnosis released Lander for the PC that featured closed levels, cargo hauling and teleporting fuel on the lander. So, Lander pretty much is Thrust in 3D.

—

So, were there any games I left out that you think should be here? Do leave a comment. Also, I’d like to thank the people who uploaded gameplay videos of Thrust, Gravitar and Oids to Youtube. I had only a NES emulator with AVI output handy.

ROM CHECK FAIL

News: Farbs interview added

Thanks to whoever uploaded this video — ROM CHECK FAIL is a bitch to capture

ROM CHECK FAIL is quite possibly the most original game I have seen in a while. That’s saying a lot considering the game is a mishmash of classic arcade and video games. The main idea is that, for example, at one moment you are playing Zelda and after a few seconds the game randomly switches to Super Mario Bros. Or Asteroids. Or Spy Hunter. While you might still be Link or the tank from Space Invaders.

While the game is ruthless in that there are impossible situations (imagine the invaders from Space Invaders suddenly turning into Goombas which of course fall down on you), it is constantly amusing in its insanity. It’s like trying to play a failed download of Wario Ware, Inc. ROM CHECK FAIL is one of the few instances of art games that deliver.

I also found the game really funny in that after playing it for about ten seconds, you immediately realize how much potential crossovers have. After you have battled against the balloons from Pang as Pac-Man, playing Alien vs. Predator or the likes won’t really impress much.

kometbomb

Programming and stuff.