RPGDXThe center of Indie-RPG gaming
Not logged in. [log in] [register]
 
 
Post new topic Reply to topic Goto page Previous  1, 2, 3  Next 
View previous topic - View next topic  
Author Message
RampantCoyote
Demon Hunter


Joined: 16 May 2006
Posts: 546
Location: Salt Lake City, Utah

PostPosted: Sat Feb 20, 2010 4:48 am    Post subject: [quote]

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
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Sat Feb 20, 2010 9:49 pm    Post subject: [quote]

Thank you. I've corrected them all.
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Sun Feb 21, 2010 4:14 am    Post subject: [quote]

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.
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Thu Feb 25, 2010 10:52 pm    Post subject: [quote]

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.
Back to top  
toturi
Pretty, Pretty Fairy Princess


Joined: 09 Feb 2008
Posts: 9

PostPosted: Fri Feb 26, 2010 6:09 am    Post subject: [quote]

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".
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Fri Feb 26, 2010 6:34 am    Post subject: [quote]

I am aware they didn't have a choice.

How did they do the text if not with a blitter?
Back to top  
Hajo
Demon Hunter


Joined: 30 Sep 2003
Posts: 779
Location: Between chair and keyboard.

PostPosted: Fri Feb 26, 2010 12:33 pm    Post subject: [quote]

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.
Back to top  
Jinroh
Scholar


Joined: 30 May 2008
Posts: 172
Location: U.S.A.

PostPosted: Fri Feb 26, 2010 1:14 pm    Post subject: [quote]

Hajo wrote:
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.


Yeah that's basically right. For the GBA you basically load your tiles into VRAM, then change the map data values RAM to have the map data then the Hardware takes the map data and draws the appropriate tile memory offsets based on the size of the map data in the map attributes.

It's pretty simple but a little different if you're not used to it.
_________________
Mao Mao Games
The wolf and his mate howl, taking solace in the silver moon. Pressing ever foreward to see what the future holds.
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Fri Feb 26, 2010 2:04 pm    Post subject: [quote]

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.
Back to top  
Jinroh
Scholar


Joined: 30 May 2008
Posts: 172
Location: U.S.A.

PostPosted: Fri Feb 26, 2010 2:19 pm    Post subject: [quote]

LordGalbalan wrote:
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.


Well you'd have to take the ASCII value of each letter and subtract it so it corresponds with your tilemap data. You usually set up your bitmap data to reflect this right? ^_^

You set a pointer to the tilemap data for the GBA 2D hardware. This is where the GBA hardware starts looking for the tile data. Then based on the values in your map attributes data memory locations it offsets the memory based on the tileNumber and the tileSize blah blah blah. Easy right?
_________________
Mao Mao Games
The wolf and his mate howl, taking solace in the silver moon. Pressing ever foreward to see what the future holds.
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Fri Feb 26, 2010 3:37 pm    Post subject: [quote]

Jinroh wrote:
LordGalbalan wrote:
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.


Well you'd have to take the ASCII value of each letter and subtract it so it corresponds with your tilemap data. You usually set up your bitmap data to reflect this right? ^_^

You set a pointer to the tilemap data for the GBA 2D hardware. This is where the GBA hardware starts looking for the tile data. Then based on the values in your map attributes data memory locations it offsets the memory based on the tileNumber and the tileSize blah blah blah. Easy right?


Easy enough.

The real question is the blit timer. I'm guessing that's done with an interrupt? We know that it had eight speed levels, so that would seem to mean that they used an interrupt timer to disconnect the symbol blitter from the VBlank, because it's pretty obvious they aren't dividing the VBlank interval itself to get the symbol blitter's rate. I guess they could be using a counter, but an interrupt seems much more sensible.
Back to top  
toturi
Pretty, Pretty Fairy Princess


Joined: 09 Feb 2008
Posts: 9

PostPosted: Sat Feb 27, 2010 8:48 am    Post subject: [quote]

LordGalbalan wrote:

The real question is the blit timer. I'm guessing that's done with an interrupt? We know that it had eight speed levels, so that would seem to mean that they used an interrupt timer to disconnect the symbol blitter from the VBlank, because it's pretty obvious they aren't dividing the VBlank interval itself to get the symbol blitter's rate. I guess they could be using a counter, but an interrupt seems much more sensible.


You can either wait for the V-blank interrupt or loop at the end of your game logic and just wait for the current vertical line to enter V-blank (the counter method). Both methods are acceptable and I'm not aware of either method being clearly better than the other

I'm not familiar with the concept of speed levels on the NES. The hardware is way simpler than the GBA and the GBA runs at one speed only, so I wonder if that actually refers to something other than CPU speed.
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Sat Feb 27, 2010 5:04 pm    Post subject: [quote]

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"
Back to top  
Jinroh
Scholar


Joined: 30 May 2008
Posts: 172
Location: U.S.A.

PostPosted: Sun Feb 28, 2010 6:33 am    Post subject: [quote]

LordGalbalan wrote:
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"


Most GBA coders I know use the VBLANK as a timing mechanism since the GBA has ~60 VBLANKs per second. So text speed would probably be just adjusted in code as you'd have to adjust the "textmode" tilemap to print each new character each frame to have the scrolling text.

Code:

Display Next Character Every (speed * textSpeed) Frames.


Basically that's how most people would do it, at least people I know.
_________________
Mao Mao Games
The wolf and his mate howl, taking solace in the silver moon. Pressing ever foreward to see what the future holds.
Back to top  
tcaudilllg
Dragonmaster


Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA

PostPosted: Sun Feb 28, 2010 10:38 pm    Post subject: [quote]

How exactly is collision detection done on the NES?
Back to top  
Post new topic Reply to topic Page 2 of 3 All times are GMT
Goto page Previous  1, 2, 3  Next 



Display posts from previous:   
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum