[Game Programming Galaxy]
[Logo]
[Zelda III Specs]
Preface
This is one of the most interesting rec.games.programmer threads, regarding
tile based games. It aims primarily to those implementing RPGs, but most
concepts can be adapted easily to other genres.
Here it comes
Date: 19 Nov 1996 00:19:30 GMT
From: cmartin@freenet.edmonton.ab.ca
Newsgroups: rec.games.programmer
Subject: ZELDA III SPECS
Hey, I've been messing around with tile games for a few months now, so I'm
quite new to some of the concepts. I got my game running, about 80 tiles
drawn, where I started thinking. I absolutly love the Zelda 3 engine (for
Super Nintendo, older game) it's graphics were absolute top down (as in,
you can see all corners of the map) and it looked 3d. If you look closly
at the game, you will notice a bunch of sprites, but, it's impossible
(well almost) to figure out what size the sprites are. Obviously, they
are not all of the same size, some may be 8x8, other may be 32x32.
How would you handle that? What types of structures would you use? What
kind of math would that need? What size of sprite would be ideal for a
minimumin a 320x200 enviroment?
I am working on an rpg at the moment, but right now I'm using up about 57k
out of 64k of data space, the way I figure it right now, I could do the
zelda engine and only use up around 8k! But how?
Does Zelda give each tile an x, y, xsize, ysize variable?
------------------------------------------------------------------------
Date: 19 Nov 1996 04:59:01 GMT
From: cmartin@freenet.edmonton.ab.ca
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
Jan Kroken (jankr@delling.ifi.uio.no) wrote:
: cmartin@freenet.edmonton.ab.ca () writes:
:
: > Does Zelda give each tile an x, y, xsize, ysize variable?
: I think the NES have both 8x8 and 32x32 hardware sprite registers.
: I think the best think for you to do is to write sprite routines
Already done.
: and sprite classes(structs) which can handle sprites of any size.
Could be easily done.
: Or you could use 18 sprites together as a 32x32 sprite:)
The problem I am having is the theory of it's maps! The tiles are all
over the place, and the tiles are huge and small! The player is not
restricted to tile by tile movment (except for water, where in water, the
player can easily inturupt the move)
so how does it do it?
+---------+
|\---o---/|
| | | |
| O | |
| | | |
|/-------\|
+---------+
Like that, those are the walls (|,\,/,+) and thats the doors (o).
Plus the ground, has tiles all over the place. How does it do this?
Obviously it does it effeciently (I could guess a few messy, bad ways of
doing it) I would really like to make a game like this, but I need to
know how it works first!! (It seems not many want to use the game format,
why! IT RULES!)
------------------------------------------------------------------------
Date: Tue, 19 Nov 1996 12:09:25 -0800
From: Takamoto Miura
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
> The problem I am having is the theory of it's maps! The tiles are all
> over the place, and the tiles are huge and small! The player is not
> restricted to tile by tile movment (except for water, where in water, the
> player can easily inturupt the move)
Tiles are huge and small? I don't think so... I think all the tiles
are the same size. I also think the character is restricted by tile by
tile movement. It's not a simple yes or no, but it's probably yes, no,
diagonal, top half... etc. Or they could have an array of bits which
specifies which part of the tile can be walked into. Well, I don't know
how SNES works, so I'm just guessing...
-Takamoto Miura
------------------------------------------------------------------------
Date: Tue, 19 Nov 1996 13:22:53 -0801
From: gau
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
On 19 Nov 1996, Jan Kroken wrote:
> > Does Zelda give each tile an x, y, xsize, ysize variable?
>
Okay, each sprite on the SNES can be set to use either 8x8 or one of
32x32, 16x16, 8x16 or 16x32, dependant on the setting in a global graphics
register (8x8 is always available, plus one larger size set by the global
register which affects all sprites, flippable by a bit in what's called
the OAM which is essentially a sprite information array implemented in
the SNES hardware) it contains: x-pos, y-pos, image_no, size-bit
(8x8/MxN), h-flip bit, v-flip bit, and "x>255" bit (making xpos==256+xpos)
On the PC you could use:
struct {
int width;
int height;
int xpos;
int ypos;
int bits;
} sprite;
just a small revision if you wish to simulate an OAM list:
typedef struct {
int width;
int height;
int xpos;
int ypos;
int flags;
} OAM;
OAM sprites[128];
==============================================================================
Gau of the Veldt
"Draped in monster hides, eyes shining with intelligence.
A youth surviving against all odds..."
===== Email: gau@netbistro.com ===== WWW: http://www.netbistro.com/~gau/ =====
------------------------------------------------------------------------
Date: Wed, 20 Nov 1996 13:13:45 GMT
From: Shawn Swift
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
cmartin@freenet.edmonton.ab.ca () wrote:
>The problem I am having is the theory of it's maps! The tiles are all
>over the place, and the tiles are huge and small! The player is not
>restricted to tile by tile movment (except for water, where in water, the
>player can easily inturupt the move)
Actually, from what I recall, it looked vey much like ALL squares in
the game WERE indeed the same size. If you want a building, you have
one square for each corner of it, and one for bottom, sides, top, and
those with a door. A tree always has grass behind it. The corners
are ALL aet up so that the section of the floor that the player can
walk on is squares...
Hope you have non-proportional fonts on:
____________
|\
| \
| \ ______
| |
| |
| |
There is a corner in one of your rooms. That corner _I_ would make
using 4 blocks of equal size. One for the corner, one for the wall
going down, one for the wall foing across, and one for the floor the
player could walk on.
Sone of the stuff in zelda is done with layers. There's that mystical
forest, which has just pictures of tree tops and then they have trees
just where the edges are to make it look like they are all trees.
Just more evenly spaced squares.
Practically EVERY game out there uses maps with all the same size
suqares... There's usually no need to make one that allows odd
sized tiles, becuase as you have noticed, allowing odd sized tiles
would make map creation a horrible headache with trying to fit tiles
into all the little gaps left by your odd shaped blocks.
------------------------------------------------------------------------
Date: Wed, 20 Nov 1996 15:21:54 -0801
From: gau
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS (fwd)
I'm working on an RPG graphics engine to do a similar view so I'll share
my observations.
Zelda III uses object space and tile space graphics, that is, there is the
basic background, defined by the tiles (trees, pyramids, walls, etc) and
then on object map that tells the system where to place sprites. Most
often this is implemented by having sprite positions stored as positions
in the virtual map, rather than on the screen. The alogrithm for deciding
what sprites to show do bounding checks to see if all or part of a sprite
should be on the screen based on the current "scroll window" position and
if it's to be drawn, does so by subtracting the top and left scroll
positions to arrive at a screen position. If you scroll the screen, the
sprites appear to move on the screen since the "scroll window" is now
looking at a slightly different section of the virtual screen. If you had
a 128x128 tilespace comprising of 16x16 tiles, you'd have a 2048x2048
pixel object space (virtual screen). The rocks and whatnot in Zelda III
that can be picked up or moved are implemented as objects at certain
locations in the object space. When the screen scrolls to a location such
that those objects are shown, you see them. Collision checking is done by
comparing one object's bounding rectangle against another's (or objects
can be represented with bounding linedefs which are checked for
intersections with another object's bounding linedefs)
You might have noticed at some points in Zelda III that there is parallax
scrolling, particularly in the Lost Woods and Dark World Tower. This is
achieved with multiple tilespaces drawn at differing scroll offsets. You
write tile routines that implement transparency then use Painter's
Algorithm to draw everything correctly depthed (farthest back plane is
drawn FIRST, frontmost is drawn LAST)
Objects in Zelda III are pseudo 3-d and Z is based on y position so z
buffering is done by sorting objects top-down (0-2047 in above example) in
the object space so that Painter's Algorithm draws them at correct
priorities. Then an object as placed at the correct location when moved,
sparing time-consuming resorting of the object list.
Any other questions, bring them forth.
==============================================================================
Gau of the Veldt
"Draped in monster hides, eyes shining with intelligence.
A youth surviving against all odds..."
===== Email: gau@netbistro.com ===== WWW: http://www.netbistro.com/~gau/ =====
------------------------------------------------------------------------
Date: Thu, 21 Nov 1996 03:34:56 GMT
From: Rob Reiss
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS (fwd)
Thanks Gau for the tips!
Do you have any recommendations on how to keep the objects ordered by
there y value. I will have objects all over a large map continualy
moving. I was playing with the idea of not using an ordered list but
instead use the objects tile/grid location as an ordering. That way I
can just run through the visible tile/grid cell from bottom to top
inorder to get all visible and ordered objects. (Does this make
sense?) The idea is that an object has a tile location and also a
pixel location. (i.e there is an array the size of the map with a
linked-lists of objects in each cell and each object has an x,y
virtual pixel location)
Is this crazy? Is there a fast way to keep an ordered list of
currently visible objects.
Thanks for any help,
Rob Reiss
------------------------------------------------------------------------
Date: 21 Nov 1996 00:16:04 GMT
From: gau
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS (fwd)
On Thu, 21 Nov 1996, Rob Reiss wrote:
> Do you have any recommendations on how to keep the objects ordered by
> there y value. I will have objects all over a large map continualy
> moving. I was playing with the idea of not using an ordered list but
> instead use the objects tile/grid location as an ordering. That way I
As long as you start with an ordered object list, using an algorithm to
place objects at the correct location for objects that move will keep
everything looking proper and not wasting your CPUs time with stationary
objects. If a *LOT* of object move (perhaps everything) then the
searching process needs to get unrolled by indicing based on world Y
coordinate:
Sprite *zbuffer[WORLD_Y_HEIGHT];
then ordering becomes taking the sprite out from its current location and
replacing it into the new location by index, the draw routine then follows
this list from (Y_SCROLL_OFFSET) to (Y_SCROLL_OFFSET+SCREEN_HEIGHT-1) to
get everything correctly drawn on the screen for that frame..
For small numbers of moving objects it's easy enough to use a linked list
of objects that is sorted and moving objects relocate themselves to the
correct location in the list to get drawn correctly.
If this is too rambled, let me know and I'll see what I can do for code
snippets.
==============================================================================
Gau of the Veldt
"Draped in monster hides, eyes shining with intelligence.
A youth surviving against all odds..."
===== Email: gau@netbistro.com ===== WWW: http://www.netbistro.com/~gau/ =====
------------------------------------------------------------------------
From gau@vortex.netbistro.comMon Nov 25 11:22:05 1996
Date: Fri, 22 Nov 1996 16:09:27 -0800
From: gau
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
On 21 Nov 1996 cmartin@freenet.edmonton.ab.ca wrote:
> : ____________
> : |\
> : | \
> : | \ ______
> : | |
> : | |
> : | |
Tiles *CANNOT* be oddly sized on the SNES. The hardware does not allow
such things (it'd be next to impossible to support). The above is done
with tiles. Drawing larger in a bitmap editor, then reducing it to tiles
with special programs designed to do that.
The flowers and whatnot are being done with *objects* (that way they can
be picked up. The stumps are very likely done with very similar 16x16
tiles that have the positions slightly different (giving the illusion of
8x8 accuracy). The worlds scroll contigiously too far in any direction
without redrawing (when it stops and redraws) to be using 8x8 tiles since
8x8 tiles would only have half the possible scrolling distance in the
SNES's VRAM.
==============================================================================
Gau of the Veldt
"Draped in monster hides, eyes shining with intelligence.
A youth surviving against all odds..."
===== Email: gau@netbistro.com ===== WWW: http://www.netbistro.com/~gau/ =====
------------------------------------------------------------------------
Date: 23 Nov 1996 07:24:29 GMT
From: cmartin@freenet.edmonton.ab.ca
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
gau (gau@vortex.netbistro.com) wrote:
: On 21 Nov 1996 cmartin@freenet.edmonton.ab.ca wrote:
: Tiles *CANNOT* be oddly sized on the SNES. The hardware does not allow
: such things (it'd be next to impossible to support). The above is done
: with tiles. Drawing larger in a bitmap editor, then reducing it to tiles
: with special programs designed to do that.
I was just thinking of making a few programs that would do that. It would
releave a few headaches for me if all the tiles are the same size! 8x8!
: The flowers and whatnot are being done with *objects* (that way they can
: be picked up. The stumps are very likely done with very similar 16x16
You can pick up flowers?? OH, those are bushes. But do you agree with me
that the bushes are just 4 8x8 tiles simulating a 16x16 sprite? Because
with that in mind, it makes perfect sense to me now! I just got to make a
"special" map editor for it. Maybe I should make it a universal editor
thatcould be configured for **ANY** tile game.. humm..
------------------------------------------------------------------------
Date: Sat, 23 Nov 1996 08:42:12 -0800
From: gau
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
On Fri, 22 Nov 1996 cmartin@freenet.edmonton.ab.ca wrote:
> > Hmm. Ok. I'll make them available on the "Sailor Moon RPG" page since
> > the game I'm making the engine for at the moment is a SM game my
> > landlady's kids wish to work on.
>
> Downloadable please, I use a text browser :(
I'll make it available both inline and hotlinked to itself so it can be
downloaded.
> Question, walkability. You can walk behind the leaf's but not behind the
> trunk, because the trunk takes up space and the game is not 2dish.
the trunk would be indicated as the portion of the tree that detects
collisions with the player when restricting movement (or triggering the
"bash the tree" effect). One way to do the impenetrability independant of
the background (promoting tile reuseability and less duplication of images
just to change tile flags around) is to use line vectors based on object
space coordinates. Where you want inpenetrability you draw a line there.
Further, each line can be given flags to indicate exactly what that line
can block the movement of (maybe some lines won't restrict "ghost"
objects, perhaps)...
> WHOA! You seem to know ***ALOT*** about this. I'm currently putting
> together a magazine called Silence 2, it's a programming only mag, it's
> offline and has a really cool viewer (will have a really cool viewer,
> since I am making it right now). If you want, you should do some sorta
> faq on how to make this type of game! It would help alot of people!
I'll consider this possibility. I'm focussing on actually implementing a
game (I now have a satisfactory engine) to get everything I've done over
the past few years to come together, and, to finally have something I can
call a "decent sampling" of my programming abilities. This is one of
those things needed to get my foot into the door of the computer games
industry.
==============================================================================
Gau of the Veldt
"Draped in monster hides, eyes shining with intelligence.
A youth surviving against all odds..."
===== Email: gau@netbistro.com ===== WWW: http://www.netbistro.com/~gau/ =====
------------------------------------------------------------------------
Date: Sat, 23 Nov 1996 08:57:59 -0801
From: gau
Newsgroups: rec.games.programmer
Subject: Re: ZELDA III SPECS
On 23 Nov 1996 cmartin@freenet.edmonton.ab.ca wrote:
> It still doesn't make sense to me! I know maps are 2d arrays, that's the
> problem though! As I said in another post, that I noticed little peices
> of grass all over the place, and "carpets" layering ontop of normal
> floors. How does it handle this? If they were all 8x8 sprites (just a
> special mapeditor was used to give ease to the level designers, where it
> combined certain smaller sprites to be bigger then normal) ooooo. that
> could explain it...
The carpet could be implemented as an object comprising of multiple
sprites (many games use this concept, including my own engine - it makes
animation a bit easier since it can be localized to parts that actually
move, optimizing the amount of animation necessary). The "carpet" would
be placed in the object space at a location the coincides with the floor.
Since the objects usually are set to show ahead of the background tiles,
the carpet neatly layers itself over the flooring.
==============================================================================
Gau of the Veldt
"Draped in monster hides, eyes shining with intelligence.
A youth surviving against all odds..."
===== Email: gau@netbistro.com ===== WWW: http://www.netbistro.com/~gau/ =====
[Image] [Image] [Image]
------------------------------------------------------------------------
| What's New? |
| Design | Tutorials | Projects | Tools | Genres | Tile based |
| Link Page |
------------------------------------------------------------------------
Designed and maintained by Lennart Steinke
lennart_steinke@bigfoot.com
Hosted by GeoCities
[Welcome to GeoCities!]