Thursday, March 31, 2011

C64's Graphical Capabilities

Like many older computers the C64's graphic capabilites are a little more complex then the simple random-access framebuffer you get today, so just saying it has 320x200 at 16 color doesn't quite capture it, as there are numerous limits one has to deal with and tricks one can use to get around some of those limitations.

Resolution and Colors

At its core the screen of the C64 has a resolution of 384x272, however only the central 320x200 pixels of that area are usable in the normal sense, the rest is a colored border, which color one can change, but that otherwise remains fixed. The central 320x200 area is where the action happens. This area can be switched to five modes:

* Standard Character Mode
* Multicolor Character Mode
* Extended Background Color Mode
* Hires Bitmap Mode
* Multicolor Bitmap Mode

The first three are character modes, that are used for either the regular text output or tile based games. Each of the 256 characters in those modes is either a single color 1-bit 8x8 bitmap or a four 2-bit 4x8 bitmap (which gets scaled to 8x8 for display). The color of the character isn't determined by the character bitmap itself, but by a separate color map that allows to assign a different color to each 8x8 area of the screen. In the 1-bit hires mode one unique color is allowed and an additional one that is shared across the screen. In the multicolor mode one unique colors and three shared ones are allowed, as an additional complication that unique color is limited to only the first 7 of the C64's 16 colors, the remaining bit is used to decide if the character is in hires or multicolor mode. This little trick allows mixing hires tiles with multicolored ones on the same screen, which many games make use of. In Extended Background Color Mode the individual colors disappear and instead one can set four colors that are shared across the whole screen.

As one can see, the limitations of the character mode essentially break the 320x200 screen with 16 colors down to a 160x200 screen with four colors, in reality things aren't quite that bad, as some trickery and clever use of the palette can be used to overcome some of those limitations.

The bitmap modes of the C64 gets rid of the character based display and instead allow to address each pixel individually. Similar limitations as in character mode apply, i.e. only four colors in each 8x8 block are allowed or only two colors in hires mode. Unlike character mode however one has free choice of three colors per 8x8 block, instead of just one, and there is only one color remaining that has to be shared across the screen. Unlike a regular linear framebuffer, the memory layout of the C64 however is a little more complicated, as it doesn't store all pixel one after each other, but instead stores them in 8x8 blocks, so the math to find where exactly a pixel is stored becomes a bit more complicated.


The C64 also has the ability to handle eight hardware sprites. The sprites work independed of the graphics mode chosen for the main screen and are 24x21 pixels large. They again provide hires and multicolor modes, selectable for each sprite individually, and as with the regular screen the horizontal resolution goes in half when choosing multicolor mode. Sprites have one unique color each, two shared across all sprites and the final color acts as transparency.

Sprites can be scaled in horizontal or vertical direction by a factor of two. Ordering can also be adjusted via a priority bit, which can also be used to put them behind portions of the background screen.

The C64 also comes with build in sprite collision detection that will inform you when two sprites have collided.

Build in Palette

The C64 provides a set of 16 colors, these colors are fixed and can't be altered and as mentioned you only can chose o few of those for your image. While this looks quite limited at first, the palette is cleverly choosen so that so that one can build numerous color gradients out of a combination of a light color, a dark color and an intermediate grey value. This image demonstrates some of the possibilities.

Smooth Scrolling

Pixel by pixel smooth scrolling is possible on the C64 when using character mode. With the help of a scroll offset the screen can be moved by up to 7x7 pixels away from its regular position without touching the screen data itself, once that position is reached, the actual screen content has to be updated manually. Which in characte mode means copying 40x25 (1000) bytes around.

In bitmap mode that offset is available as well, but not really useful for scrolling, as the C64 isn't fast enough to copy the 10.000 bytes around that form the framebuffer and the color maps.

Parallax scrolling isn't possible on the C64 by normal means, as it can only do a single layer of graphics. Tricks with sprites or animated character graphics can however be used to get a bit of a parallax effect.

Sprites are not influenced by the scrolling registers, they have to be moved along manually.

Raster Interrupt

So far all the capabilities presented still have some problematic limits. If you wanna display a HUD along with a scrolling playfield, you can't really do that, as the HUD would move along with your playfield. Sprites also wouldn't be of much use, as you'd want to use those for the game itself, not waste them on the interface. The raster interrupt comes to the rescue, it allows to execute code on essentially each scanline. This can be used for a multitude of clever tricks, such as switching the screen mode or scroll offset while the screen is getting drawing to the TV. This thus allows to have a HUD that stays fixed at the bottom of the screen, while the playfield above scrolls around, you simply change the scroll offset at a scanline. That interrupt can also be used to allow two player split screen or to change the color palette on the fly to make more use of the limited amount of color the C64 provides. It can of course also be used by simple special effects, such as a water effect.


And here a little example of a multicolor bitmap mode image running on the emulator Vice (example code and explanation how that image was created might follow later):

Friday, March 25, 2011

Review: Outlaws (PC)

Outlaws is a wild west first person shooter released in 1997 by LucasArts. It uses the Darkforces engine, one of the last Doom-like engines, meaning it doesn't allow full 3D scenarios, but supports slopes, limited looking up and down as well as buildings with multiple stories and simplistic polygon objects. Enemies continue however to be represented by simple 2D sprites.

The game starts with an elaborate hand animated seven minute intro that portraits the death of James Anderson's wife and the kidnapping of his daughter, which in turn send him, the player's character, onto a tour of revenge and a search for his daughter. While the intro implies a strong focus on story, the game doesn't really follow up on that promise. Further cutscenes follow, but they are much smaller in scope and limited for most part to the final last words of the last boss enemy you fought. Transition from level to level in turn feel a little rough, as they are only sometimes outlined in the cutscenes and hardly ever explained by any kind of real story. Never the less, the cutscenes are well animated and do a good job of setting up the atmosphere and setting.

The music in the game comes in the form of 15 fully orchestral Audio CD tracks, spanning two CD. Just like the intro, the music is one of the strongest points of the game and does a great job of underlining the western atmosphere.

Mechanically the game follows for most part the traditions of Doom. The player is confronted with plenty of enemies which he has to fight over the course of the level. Like Doom, the levels rarely have a clear linear structure and instead are pretty open and require the search for keys and items which in turn unlock doors and allow further progress. While the game features an actual inventory for items, most of them serve the same purpose as the keys, a crowbar will open a stuck door and a shovel will allow you to dig into the ground in special places and give access to a new area that way. Truly creative use of the inventory items however doesn't really happen and thus most puzzles don't require much thinking, but only finding the right item to open up the next area. This can frequently turn into tedium, as the game only rarely gives a hint of where the next item might found or where you even have to go. In a few instances you can figure things out by looking at the level structure, but that happens far to seldom. The final goal in each level is a boss, which is marked on the auto-map, but that hint doesn't really help much in practice as levels are constructed in multiple floors, thus the actual direction to the boss might be completely different from what the auto-map suggests.

The action in the game on the other side works quite well. The ability to duck allows to take cover behind tables and objects and jumping allows creative level design that requires jumping to rooftops or perform other acrobatic acts. Enemy design is rather limited and only includes a few different kind of cowboys that mainly differ in weapons they posses. The game also features numerous special boss characters, but while they differ in design and health from the regular enemies, they don't really stand out and frequently you might end up killing a boss before even realizing that you where fighting one, as the boss fights do not take place in special areas, but just in normal parts of the level. AI in the game, while overall nothing special, is clever enough to occasionally take cover. The ten weapons in the game are a bit limited, even so knifes, dynamite and three kinds of shoot guns are offered, one spends the most of the time with the pistol and rifle, as they are the most effective, especially on long range. The three different forms of shotguns just feel redundant.

Aside from the nine levels that form the main story campaign, which take around six hours to complete an the easy difficulty, the game also features five historical missions that are supposed to take part before the main story and detail James Anderson work as Marshall. However as those levels don't follow any kind of story, don't provide cutscenes and can be accessed in any order and thus end up feeling a bit disjoint. There also exist an patch for the game, still downloadable from the LucasArts page, that adds another four missions. All that additional single player content combined takes pretty much as long as the games main campaign.

Overall I enjoyed Outlaws, especially given its western setting which isn't touched by first person shooters very often, but it is not without its short comings. Its story is a bit lacking, the atmosphere and music are however both very good and still hold up, the action is also very well done, big innovations are however missing. The non-linear level structure is a very welcome diversion to the more linear level structure of modern games. The hunt for missing items, keys and switches is by far the weakest point of the game, what might look like an opportunity for fun puzzles on the surface turns frequently into pure tedium and disrupts the games otherwise fast flow quite a bit. A walkthrough can help reduce that tedium a good bit, so I would recommend using one when needed.

Technical notes: Outlaws runs without problems in Windows Vista when using the software renderer, which goes up to 800x600. The Direct3D renderer, provided by an official patch, allows basically any 4:3 resolution, but failed to work properly and resulted in graphical glitches that made the game unplayable for me. The blur caused by the filtering also didn't really suit the games comic style, so the software renderer is the prefered choice. Sometimes, when switching back to the desktop, the games color palette will glitch out, simply going to the load/save screen will however fix that. Under Linux in Wine the game functions properly, but only until one enters the menu for the first time, after that the sound will simply stop and I haven't found a way to start it back up, thus I wouldn't consider the game playable in Wine, even so the graphics and controls itself work fine.

Wednesday, March 16, 2011

xboxdrv 0.7.3 released

  • fixed installation of xboxdrvctl
  • added special REL repeat value '-1' to avoid jaggy mouse emulation movement
  • added "rel-repeat:" axis-event for better scroll wheel emulation
  • added --no-dbus, to disable D-Bus support
  • added xbmc.xboxdrv, a config fine tuned for XBMC
  • added zsnes.xboxdrv, a config file for ZSNES
  • reenabled USBReadThread to work around ignored input events
  • '--daemon' is broken in this release

This release should fix the issue with buttons getting stuck and events getting lost of previous 0.7.x releases and bring it on par with 0.6.6, '--daemon' mode however is now broken and will require a larger code restructuring to get fixed.