[RampantCoyote]

You've got it right a couple of times, but you generally misspell "rogue" as "rouge" - which is a color. The rogue may wear rouge, but the rogue can't actually be a rouge.

Sorry, pet peeve. My favorite class in RPGs is the rogue... ;)
_________________
Tales of the Rampant Coyote - Old-School Game Developer talks Indie Games, RPGs, and the Games Biz

[tcaudilllg]

Thank you. I've corrected them all.

[tcaudilllg]

I realized that I had neglected sports games completely. I'm going to give it some token attention.

Football games used tracking algorithms. Offense players move into their play positions first, then begin moving to the ball's coordinates. The defense uses plays to assign an offensive player for each defensive player to track. The plays themselves are apparently association scripts which correspond defensive players to offensive players.

The offense uses last-position tracking; the defense uses a seek tracker method which repeatedly re-acquires the offense's position. This method appears to have first been used in the arcade game JAWS.

I'm getting tired of this already. I had thought there to be more variation in games than I had imagined... but now I see they are mostly retreads of the 70s.

I'm going to tackle DQ now.

[tcaudilllg]

Dragon Quest was the great revolution, or was it? What Dragon Quest did was add glitz. Really, DQ is Ultima with random enemies that you can't see before they attack. DQ's biggest innovation was the dialogue window, which gives us all fits to this day. Of all the (non-mathematical) tasks faced with hobbyist programmers, perhaps none is more mystifying than understanding a dialogue box.

The real problem with dialogue menus is understanding where they fit in the program, though even their design can be a pain. Menus are probably the least reproducible aspect of a game -- most every project on RPGDX uses menu systems made from scratch just for that game, or so it seems. Broadly speaking, this seems to be the rationale for the "build it from the ground up" philosophy and the idea that "every game is different" -- people just don't understand how to reuse their menu code, apparently.

The trick to making an effective menu is evident in the way that DQ makes its own: minimal use of measurements and maximum use of tiles, tiles, tiles. DQ uses four corner tiles and four border tiles. It measures its windows by tiles, not pixels. In structure, the DQ dialogue system is complex, particularly for its use of cursors. DQ allows users to interact with the game by selecting choices offered in the dialogue box. The mystery of the dialogue box lies in its illusionary nature: although it seems on the surface that the programming is associated with the choice presented, in reality this is not so. Rather, the text of the choice is drawn to the window and an internal matrix is set up for the cursor to move in. The text is just "there": there is absolutely no connection between the cursor and the text, although there might seem like one. Rather, the cursor just "teleports" between positions: there is a small logical map on which the cursor moves, and each position on the logical map has a corresponding position on screen. One peculiar aspect of the NES' tiling system was the way in which it forced designers to think aesthetically: everything was box-like and essentially well-spaced, which made it difficult to get away with making anything too small to see or even overly complex.

A function is associated with each position in the cursor's space, and when the button is pressed the offset of the position in the cursor space is passed to a function. This function has all the possible choices coded in a switch statement, and the number passed indicates the choice to process.

In DQ there are three kinds of dialogue windows:

• choice selection windows
  
• scrolling text windows
  
• non-scrolling text windows
  

Each of the windows uses the interior region for text, and this region is always of dimensions window height - 2 and window width - 2. It uses a word-wrapping algorithm, and sends entire passages of dialogue to the text blitter. The word wrapping algorithm is complex: a count is kept of the used tiles on the line, with the length of each new word added to it. The new length of the line is calculated before the word can be added: if the new length is beyond the tile row length, the text is "wrapped" by deferring the new word to the beginning of the next line.

Here's the setup. Each tile window is treated as a map in its own right, which has its own set of tiles.

• Draw a grid of solid-color tiles over a rectangular region of the screen. This is the window map.
  
• Draw the borders of the window map.
  
• Blit text to the window word by word and letter by letter, at a set rate.
  
• Fill each row of tiles with text for as many rows of text as are required for the input text. Keep a running count of the number of tiles used by the text for the working line. If the tile length of the next word exceeds the tile row's length, reset the output position to the first column of the next row (windowTileX = 0, windowTileY = next row).
  
• If the output position is on the lower border of the window, place the scroll signal sprite and wait for input. When the input comes, displace the existing text upward as new lines are written to the window. Put as many as rows - 1 lines of text, displacing all but the last line of the previous
  
• If a new speaker takes over, clear the dialogue window with blank tiles before outputting the new text.
  

The trickiest part is the text blit timer; however, the blitter routine also deserves mention.

[toturi]

You make it seem like programmers working on the NES (and other consoles around that time) actually had a choice in how they build/drew their UI.

Graphics on the NES (and SNES, GameBoy, GBC, GBA and even now on the DS and DSi) are all tile based. This means that to make something appear on the screen, you copied data in 8x8 pixel chunks into VRAM and then told the hardware what tiles to draw and where by writing values into memory-mapped IO addresses.

Severely limiting? Perhaps if you're accustomed to texture-based rendering. But it's incredibly fast because none of your precious CPU cycles (and you didn't have much, like just under 2MHz) are spent pushing pixels; when you wanted data in VRAM, you DMA'd it during the V-blank and voila, it shows up on screen the next frame.

The setup you describe is quite different from how you'd actually do it on an NES. There is no "blitter".

[tcaudilllg]

I am aware they didn't have a choice.

How did they do the text if not with a blitter?

[Hajo]

If I understood Toturi right, you told the hardware which vram block to read for certain screen locations. So the screen was divided into 8x8 pix areas, and for each area you have a memory cell, which determines what kind of tile will be displayed there, and the tiles were read from vram.

A bit like old computer systems had a font bitmap in rom, and each byte in graphics memory told which character to display there - just that instead of characters it's 8x8 tiles, and they are not in a rom, but the vram, therefore mutable by the program.

This needs no blitter, just a graphics chip that can read tiles through the tile lookup table.

[Jinroh]

[tcaudilllg]

But you still need some means of associating the tile graphic with bytes. That's the blitter system I was talking about. Something reads the text in the ROM and determines which tile graphic to use for each character therein.

[Jinroh]

[tcaudilllg]

[toturi]

[tcaudilllg]

In DQ and in Final Fantasy both, you can change the text speed before starting the game. I'm talking about the window text speed, where it appears character-by-character in the window with an associated noise of "beilei" for each character.

"Beileileileileileileilei...beileileileileileileileileilei....beileileileilei"

[Jinroh]

[tcaudilllg]

How exactly is collision detection done on the NES?