Tile Based vs Non Tile Based

Tile Based vs Non Tile Based

Post by terence ta » Sat, 06 Jun 1998 04:00:00



Hi,

There has recently been two isometric based games that have stated they are
not using a non-tile based system(Diablo 2 and Baldur's gate to be exact).
Does anybody know what this means? I mean I have done a tile based game, and
probably the biggest difficulty with doing it is getting the graphics to
look nice(i.e. all that tile cutting doesn't making for smooth or realistic
looking graphics and really kills time). Cinematix has stated they are using
a tile based engine, and the graphics look pretty good.

I am now looking a the possiblity of doing a non tile based system that has
a 2D array of 'prop draw list boxes'. First I would have a bigger backbuffer
than my front buffer, and moving around in the map would mean 'blitting'
portions of the screen around, until the 'player' walked into the next prop
draw list box that would 'redraw' the entire back buffer. Sprites and
animation are handled on seperate draw list, and ony things that need to be
re-drawn and redrawn(rather than the entire screen).

The 'prop draw list boxes' would be a store linked list of items to 'draw'
in the game, layered, arranged bottom to top(i.e. objects that need to be
draw first on a layer at the bottom to the 'top most' layer). The 'entire'
graphic object would be stored and be able to be draw, instead of a tile
cutting.

Another 'big' problem I hope to solve with this approach is 'smooth'
loading, allowing you to have a large enough 'object' set of no repetitive
graphics and be able to load that graphics in memory, optimizing it to load.
WIth A good FIleMapping routine, I could cache graphics into a file,
allowing grouping close 'props' together.

Terence Tan
Web.Works Interactive (http://webworks.inet.net.my)
Come fufill your Destiny (http://destiny.inet.net.my)

Of course a good 'tagging'/dirty rect system needs to be implemented(i.e.
when a character walks behind an object how to we handle the layering of the
graphic objects).

 
 
 

Tile Based vs Non Tile Based

Post by dream » Sat, 06 Jun 1998 04:00:00


: There has recently been two isometric based games that have stated they are
: not using a non-tile based system(Diablo 2 and Baldur's gate to be exact).

Are you sure about Baldur's Gate??  I could have sworn I saw one of the BG
folks mention they were using a hexagonal tile system...

 
 
 

Tile Based vs Non Tile Based

Post by dream » Sat, 06 Jun 1998 04:00:00


Argh!  Never mind my previous response.  I'm confused...
it's 6 am...
I need to go to bed...
:)

 
 
 

Tile Based vs Non Tile Based

Post by Michael Duff » Tue, 16 Jun 1998 04:00:00



> >> Are you sure about Baldur's Gate??  I could have sworn I saw one of the BG
> >> folks mention they were using a hexagonal tile system...

> >Baldur's Gate is using Pre- Rendered screens.

> What exactly does that mean. Unless they do some graphics layering, they
> can't allow character to walking behind walls. Unless they keep some sorta
> of dirty-rect method of re-drawing the walls when a character passes behind
> it. I also read anyways that they don't scroll the screens per say, but run
> it much like the way Starcraft does it(i.e. have the entire 'map' in memory)
> and let you 'scroll' around the entire area(I suppose because different
> party member you control can move around independantly).

Baulder's Gate draws the graphics one screen at a time instead of one tile at a
time.  The movement system is based on an invisible hex (I assume hex) grid laid
over the graphic.  Passing behind walls can either be accomplished by breaking
individual scene elements out at different layers, and using them to overdraw
characters that pass behind them, or the engine can have a z-buffer for each
image and use that to composite the characters into the background.

I'm seriously considering implementing a z-buffered sprite engine that uses a
single image for the background (well, multiple non-overlapping tiled images),
and then z-buffers the character and object sprites in.  I've been putting some
thought into it since looking at how nice Final Fantasy VIII's screens are and
thinking that it will probably be easier to do good graphics as a single image
rather than in individual tiles.  Also, my artists are not too thrilled with the
entire tile idea, and tiles are tough to do in a 3D rendering package.

Hmmm...

Later,
Michael Duffy

 
 
 

Tile Based vs Non Tile Based

Post by John Mancin » Tue, 16 Jun 1998 04:00:00


Quote:>Baulder's Gate draws the graphics one screen at a time instead of one tile
at a
>time.  The movement system is based on an invisible hex (I assume hex) grid
laid
>over the graphic.  Passing behind walls can either be accomplished by
breaking
>individual scene elements out at different layers, and using them to
overdraw
>characters that pass behind them, or the engine can have a z-buffer for
each
>image and use that to composite the characters into the background.

>I'm seriously considering implementing a z-buffered sprite engine that uses
a
>single image for the background (well, multiple non-overlapping tiled
images),
>and then z-buffers the character and object sprites in.  I've been putting
some
>thought into it since looking at how nice Final Fantasy VIII's screens are
and
>thinking that it will probably be easier to do good graphics as a single
image
>rather than in individual tiles.  Also, my artists are not too thrilled
with the
>entire tile idea, and tiles are tough to do in a 3D rendering package.

I know exactly what you are saying. My 3D artist hasn't liked doing the iso
tiles at all either. Simply because you can't really dive into the details
as much as you can if you have more of a canvas to work on.

One thing I don't get about not using tiles is how is the scrolling of the
screen handled? (not even thinking about doing 'paged' scrolling... that is
pretty cheap looking IMO)
How would it work? Would you have the whole 'world' divided up into
1000x1000 sized "chunks" of images and then load these on the fly? Obviously
you can't load them all at once.

Can you elaborate a little more? Because I am very interested in doing this.
And it would be the perfect time to do it in my project.

Thanks,
jrm

 
 
 

Tile Based vs Non Tile Based

Post by Michael Duff » Tue, 16 Jun 1998 04:00:00



> >I'm seriously considering implementing a z-buffered sprite engine that uses a

> >single image for the background (well, multiple non-overlapping tiled
> images),
> >and then z-buffers the character and object sprites in.  I've been putting
> some
> >thought into it since looking at how nice Final Fantasy VIII's screens are
> and
> >thinking that it will probably be easier to do good graphics as a single
> image
> >rather than in individual tiles.  Also, my artists are not too thrilled with
> the
> >entire tile idea, and tiles are tough to do in a 3D rendering package.

> I know exactly what you are saying. My 3D artist hasn't liked doing the iso
> tiles at all either. Simply because you can't really dive into the details
> as much as you can if you have more of a canvas to work on.

> One thing I don't get about not using tiles is how is the scrolling of the
> screen handled? (not even thinking about doing 'paged' scrolling... that is
> pretty cheap looking IMO)
> How would it work? Would you have the whole 'world' divided up into
> 1000x1000 sized "chunks" of images and then load these on the fly? Obviously
> you can't load them all at once.

> Can you elaborate a little more? Because I am very interested in doing this.
> And it would be the perfect time to do it in my project.

> Thanks,
> jrm

Well, these have been my thoughts on the subject so far:

* z-buffering.  No matter how you look at it, software z-buffering is slow.
However, since you will only be z-buffering in a few sprites into a pre-rendered
background as opposed to 3D where you would z-buffer the entire screen, it
should be fast enough.  You will store your background image as a 16 bit color
image with a 16 bit z-buffer.   You'll probably want to keep these as separate
arrays (instead of packing the info in an unsigned long) because you may keep
the graphics in video memory.

I haven't written a z-buffer sprite routine yet, and the way you approach it
will depend on the flexibility you want and how you draw sprites.  You can
either store the z-buffer info for each pixel of the sprite, or give the entire
sprite the same z-depth.  The latter approach would be faster and would have
less memory storage requirements.  However by doing this you give up the
opportunity to do depth tricks like having your sprite merge through walls or
have some sort of fog effect where the farther pieces of the sprite dissolve
more into the fog.  Since these effects are not likely to be used all the time,
the tradeoff might not be worth it.  Of course you could always store the sprite
z-buffer info and then have your sprite routine draw either a per pixel or a per
sprite z-buffered sprite in different situations.  I'll likely just do a
per-sprite z value.

* paging in BG graphics.  My thoughts here are still a bit underdeveloped since
there are sooooooo many ways to approach this problem.  Here's what I'm thinking
so far:

You have a 640x480x16 DirectDraw surface with back buffer for page flipping, and
you store this in video memory (1,228,800 bytes).  Then you have a say
1024x1024x16 background image buffer in video memory for holding your background
(2,097,152 bytes).  This is a double axis buffer, which means the info in it
will be written to the actual back buffer with up to four block copies.  The
actual "tiles" of your background image are 128x128x16, so they tile 8x8 into
the background buffer.  You keep a duplicate of the background buffer in system
memory for when you have to look up colors for alpha blending.  You also have a
1024x1024x16 buffer in system memory that contains your z-buffer info.  Both
these buffers in system memory are double axis buffers, and they match up to the
background buffer in video memory.

So now when you build your scene you will decide where the upper left corner of
your visible image falls in the background buffer and blit from they video
memory background buffer to your back buffer with up to four separate blits.
Note these are not block blits, but rather line by line blits of up to four
different rectangles.  Then you draw your sprites into the back buffer (not the
background buffer), using the z-buffer in memory to decide how to z-clip the
sprites.  If you are doing blending effects with the sprites then you use the
colors in the background buffer copy in system memory to calculate the blending.

Now, how do you scroll this puppy?  Well, scrolling little amounts is covered by
using a different starting offset in the background buffer when you blit to the
back buffer.  Once you reach the edge of the background buffer, you will have to
copy in a new row and/or column of your 128x128 background image tiles.  The
worst case scenario is when you move diagonally through the corner of the
background buffer, in which case you will have to copy both a row and a column
of tiles.  A single 128x128 tile is 32k (32,768 bytes).  A single row or column
is 32k x 8 tiles, or 262,144 bytes (256 k).  Both a row and a column together
makes 491,520 bytes, which is still less than a 640x480 screen.  You can even
break this blitting job up over several frames if you use the next to the
last/first row/column as your boundary line for when to update the background
buffer.

Anyways, the new info you use to fill in these rows and columns can be stored in
memory compressed or uncompressed, read from disk, or whatever.  To scroll you
just update your axis in the double axis buffers, obtain the new info, write the
new info into the system memory z buffer, the system memory background buffer,
and the video memory background buffer.  If your data is compressed, you can
decompress into the system memory  background buffer, and then blit the
uncompressed image into the video memory background buffer.  If you don't plan
on doing any alpha blending, then you can eliminate the system memory background
buffer and just work directly with the video memory background buffer.

The fun part comes when you try to add animation to the background tiles.  I
haven't figured out exactly how I'm doing this yet, but it will likely entail
writing the sprites of animation directly to the back buffer from sprite data
stored in system memory.  This is only one of several ways to approach this
problem.

* tile based movement and collision detection.  Since your graphics will be
built from 2d panes of graphics instead of tiles, you will need to store the
tile and collision info separately.  Essentially what this means is creating a
separate tile map that contains collision info instead of graphic info.  This
will also be where you store your object info.

...

That's what I'm thinking of so far.  I'll likely take a stab at implementing it
after a week to a week and a half, and I figure it will take about three weeks
to convert my current tile based engine over to the new graphic approach.  Then
of course there are still other issues such as front wall removal, etc.  Also,
I'm considering storing the background graphics as large sprites instead of
128x128 tiles, and I will simply draw clipped sprites into the background buffer
when it comes time to create new columns and rows.  Don't know how well this
will work though...

It's late, I'm tired, and I doubt I'll make much more sense tonight (if indeed
the above makes sense to you in the first place (^_^) ).

Later,
Michael Duffy

 
 
 

1. Size of Tiles in Tile based game

  I'm getting ready to go full time into programming my game logic.  I've
already got the graphics engine running fast and smooth (A tile based game).
My question is, before I start coding, is:  Is there a reason why so
many people like the 16x16 size for tiles?  Right now I'm using 32x28.
I wanna make sure that this is ok and not some big no-no.  I can't
see any problems, but maybe someone out there can suggest to me why 16x16
seems to be the size of choice?

Thanks!


--
  "I can't see the lines I used to think I could read between." - Brian Eno

2. cannot load 2001

3. Tile based games...

4. CSMA/CD: P-persistent algorithm?

5. // Tile based or what?

6. Which CDPD modem for iPAQ?!?!!?!

7. DDraw slow for tile-based engine?

8. Jewel Case Creator and H-P 970 Printer

9. Tile-based mapping programs??

10. Tile-based game mapping question

11. isometric tile based games...

12. Tile based engine - WTB/Steal ;)