Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Tiles and objects

This topic is 6279 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

When drawing the screen in a 2D iso game, would it make a lot of sense to have 3 layers -- 1st for tiles, 2nd for objects, 3rd for sprites, rendered in that order? I read somewhere that it is a good idea to treat objects as tiles, because its faster that way. However I like it more this way for organization. Unsliced objects such as rocks and buildings can then be placed on any kind of tile (except for water surfaces, maybe). More object reusability. Unless there''s something I''m missing that I should take into account, I would like to go for it. Otherwise, please post and explain what it is that I am missing.

Share this post

Link to post
Share on other sites
3 layers, each one rendered?

heres some thoghts on that, since i did it in my own game:

1. you put buildings on top of ground layer, do you really
need to render the tiles that it covers?
believe me that adding an If to that loop will save you
the drawing time of those tiles. tile rendering takes a lot
more time than putting if's.

2. just added this modification to my engine. my FPS jumped from
50 to 100, so listen close. putting a large sprite takes a LOT
Quicker than putting several small ones.
what i did? the ground&building&Trees layers were rendered into
an offscreen surface only when the user scrolls . the rest
like units and the things above it you have to draw separatly.
so each time i draw a frame, i blit the large "pre rendered" map
and tha units over its.
man, 50FPS is alot to save here!

3. u dont have any alternative to the description of tiles,
but since it consumes a lot of space, use as little properties as u can.
even use only a char to define a tile in a lookup table. saves megs
of memory. (do the math, its a one megabyte to use a 128x128xInt map)

4. in order to save your unit, the best way is to organize them in
a linked list. also with ptr to the lookup table which has its sprites.
you DONT want to load for each 70 same (lets say Footmen) the sprites
all over again...

thats what i can think about in this moment.


Edited by - GilZu on September 9, 2001 8:32:30 AM

Edited by - GilZu on September 9, 2001 8:33:50 AM

Share this post

Link to post
Share on other sites
Gilzu, thanks for your tips.
I''m sure they are of great help to me.

If you don''t mind, I have a question to ask.
When you use "if"s to check if the tiles you are about to render is covered with buildings and objects, how do you determine it?
Should I make a linked list or an array that tells the tiles that have buildings and objects on them? The "if"s will then consult this linked list or array to see if you need to render the tiles. Am I correct?

Also, what''s the benefit in drawing the ground/buildings/objects layers in an off screen surface prior to loading them on to the visible screen? My guess is that it distrubutes the loading process, so you can achieve higher FPS?

Thanks again!

Share this post

Link to post
Share on other sites

when your loop is:
loop {
calculate place of tiles
print tiles

you actually blit lots of little tile sprites.
what you also do is spend time on calculating
the place of the tile.

but when your loop is:
loop {
if scrool happend {
calculate how the back map should be
blit the back map to the back buffer
blit back map to back buffer
blit units to back buffer

what does that help you?
you dont need to calculate the back layers every time,
you only need to render them when a screen scrolls.

so that saves you time in caculation,
but the best time consuming thing, is blitting
a lot of small tiles.

two reasons:
a. you keep passing over the blank spaces (color keyed)
so youre using small surfaces to create a big screen, but u pass over a
lot of dead area in the process (color keyed for transparancy)

b. the blitter is way much faster to use when you use a big sprite to blit
rather than a lot of small ones. smting with the calls for the func and

as i said before
itll add you a bunch of megabytes to the memory that
the program uses -> major slowdown.
use a linked list.
each time you need to draw the screen, pass over the linked list
to see whose on the screen and then draw it.
u need to use dynamic lists to save memory, youll find out
that its easier that way.
you can organize your list for it using quad trees.
just look at the tutorials.

thats all for now

Edited by - GilZu on September 9, 2001 7:16:27 PM

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!