Discrete Arctan in 6502

Gameplay in Star Versus is rotational in nature. Objects keep track of the direction they’re facing, and move that direction at each step of the engine. This situation requires a bit of trigonometry, most of which can be pre-calculated for efficient runtime performance, though some cannot. In particular, a couple of gameplay elements need to find arctangents, and need to do so quickly.

tangent

The definition of the arctangent is as follows: given a right triangle, arctan calculates one of the non-right angles using as input the length of the side opposite that angle divided by the length of the adjacent side. In the case of Star Versus, the triangle’s sides are the X/Y distances between two objects, like a projectile and a ship, and the angle is the direction the first needs to travel to reach the second.

sword-collide-hit sword-collide-miss

Arctan was first needed to figure out when one ship hit another with their sword. Swords don’t have their own collision information, they exist purely as rendering artifacts due to needing animation. Instead, they reuse the code that detects collision between two ships, with a larger hit box to account for the range of the sword. This lets the engine save precious CPU time by calculating the X/Y position deltas only one time. However, it does need to make sure the sword swinger is facing the correct direction, and not attacking away from the target, which is where arctan gets used.

Continue reading

Select Menu Graphics Analysis

select-menu_select-ship

In Star Versus’s two player mode, the first thing players see is a menu to select their ships, handicaps, and arenas. Although straight forward in concept, this menu actually maxes out the NES’s graphics in multiple ways. Specifically, it uses each available palette, requires all 64 sprites, and places 8 sprites onto the same scanline. Only by using a couple of clever tricks can it be rendered at all.

Continue reading

NES Graphics – Part 2

Part 1 discussed the components of NES background graphics – chr, nametable, palettes, and attributes. But this was only half of the story.

For starters, there are actually two nametables [1]. They each have their own attributes for determining color, though they share the same chr. Cartridge hardware determines their position, either side-by-side or stacked on top. Shown here are examples of games using each orientation, Lode Runner (1984) and Bubble Bobble (1988).

lode-runner-scrolling

bubble-bobble-scrolling

Continue reading

Stupid NES Tricks – Screen Wrap Detection

One particularly tricky problem encountered during the development of Star Versus was detecting screen wrap. The solution involved discovering a neat trick that exploits the NES’s 6502 processor.

Movement engine

screen-wrap

The core engine of Star Versus moves all objects every frame. Most objects, when they reach the edge of the screen, should wrap around to the other side. However, certain slow-moving or long-lived objects (such as asteroids, bonus items, or special attacks) are destroyed instead. In addition, the nebula level disables wrapping entirely, which prevents players from crossing the edge and destroys anything else. Essentially, the engine needs a way to detect when any object crosses a screen edge, and it needs to be very efficient since it’s potentially always needed.

annotated-coord

Continue reading

NES Graphics – Part 1

Released in 1983, the Nintendo Entertainment System (NES) home console was a cheap, yet capable machine that went on to achieve tremendous success. Using a custom designed Picture Processing Unit (PPU) for graphics, the system could produce visuals that were quite impressive at the time, and still hold up fairly well if viewed in the proper context. Of utmost importance was memory efficiency, creating graphics using as few bytes as possible. At the same time, however, the NES provided developers with powerful, easy to use features that helped set it apart from older home consoles. Understanding how NES graphics are made creates an appreciation for the technical prowess of the system, and provides contrast against how easy modern day game makers have it with today’s machines.

The background graphics of the NES are built from four separate components, that when combined together produce the image you see on screen. Each component handles a separate aspect; color, position, raw pixel art, etc. This may seem overly complex and cumbersome, but it ends up being much more memory efficient, and also enables simple effects with very little code. If you want to understand NES graphics, knowing these four components is key.

This document assumes some familiarity with computer math, in particular the fact that 8 bits = 1 byte, 8 bits can represent 256 values, and how hexadecimal notation works. However, even those without a technical background can hopefully find it interesting.

OVERVIEW

castlevania

Here is an image from the opening scene of Castlevania (1986), of the gates leading to the titular castle. This image is 256×240 pixels, and uses 10 different colors. To represent this image in memory we’d want to take advantage of this limited color palette, and save space by only storing the minimum amount of information. One naive approach could be using an indexed palette, with 4 bits for every pixel, fitting 2 pixels per byte. This requires 256*240/2 = 30720 bytes, but as you’ll soon see, the NES does much a better job.

Continue reading