Archived

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

Objects bigger than one tile...

This topic is 6024 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

Hello, I work on ISO engine and now I have basic functional engine with animated sprites, layered maps, map editor and so on... Now I want somehow implement objects that are larger than one iso tile. Can You give me any sugestions? Thanks

Share this post


Link to post
Share on other sites
Are you using DirectDraw or OpenGL or Direct3D?

If you''re using DirectDraw the best way is just break down the large objects into single tile pieces or use offsets.

If you''re using any variation of 3D you''ll need to use the z-buffer.

Ben
http://therabbithole.redback.inficad.com

Share this post


Link to post
Share on other sites
Kalvin is right - or at least I haven''t figured out a better way yet. With sprites bigger than one tile you''ll run into all sorts of drawing order problems, for a game that suffers badly from this see fallout tactics (graphics that should be hidden overdraw other parts. even worse: frame coherency is lost, i.e. one frame it''s correct, the next it''s wrong, so you get bad flickering).
In 2D, splitting up bigger tiles into smaller pieces is the only correct solution I know of. But that is a pain to handle internally, even if it looks correct afterwards. I''ve implemented a Jagged Alliance2-like dither system for objects hidden behind walls, and that helps the situation a bit, since the dithered sprites can always be drawn last, on top of everything else. Unfortunately that doesn''t nearly solve all problems.
In a 3D iso engine you could use the z-buffer, but then you''d need proper z information for all your graphics, which requires quite some work and memory. Michael Duffy of studio blue tried the z-buffer approach and advised against it.

So I''m not aware of an all around satisfying solution. Anybody else know an answer? Tanstaafl?

regards,
BuschnicK


Life would be much easier if I had the source code.
blackfish.sourceforge.net

Share this post


Link to post
Share on other sites
I work in DirectDraw.

You said, that I must divide bigger objects into small pieces, but my graphics told me, that this is imposibile.

All graphics is rendered in 3D Studio.
How can they fast divide graphics into pieces that is one tile big?

Share this post


Link to post
Share on other sites
Or you can make a way for your engine to consider sprites to be completely independent from the tilemap. That''s what I''m doing for any moving sprite. It makes physics a little more challenging, but I think it will be worth it for what I''m doing.

[Resist Windows XP''s Invasive Production Activation Technology!]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
NULL and VOID

- That way is my opinion. I tought, that I can have big sprites and I can store them as one sprite and problem about dividing them into small pieces is solved.

BUT !!! If I have big sprite, how I implement it into map?
- I know that I must code some special algorithm for colision and (pseudo) physics, but how I can investigate how much tiles this big sprite occupie?

P.S. I must apologize for my english. All of us are''n from US or UK...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
NULL and VOID

- That way is my opinion. I tought, that I can have big sprites and I can store them as one sprite and problem about dividing them into small pieces is solved.

BUT !!! If I have big sprite, how I implement it into map?
- I know that I must code some special algorithm for colision and (pseudo) physics, but how I can investigate how much tiles this big sprite occupie?

P.S. I must apologize for my english. All of us are''n from US or UK...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Sorry for my double response....

Martin Kaspar

Share this post


Link to post
Share on other sites
We''re missing some information about your engine. I don''t know why somebody asked what API you''re using, because it doesn''t matter. (I could make a 2D isometric engine using Direct3D.) Here''s what we need to know:

1. Is your engine 2D or 3D?

2. When you say "object," are you talking about scenery or moving entities?

3. Is movement confined to tiles, or can your entities freely move anywhere on the map?

4. Are you using a tile-based path-finding algorithm for AI?

Once we have this info, we can start helping you out.

As for breaking your objects into smaller pieces: I''m sure KalvinB didn''t mean for you to slice up your models and re-render each piece. He meant take the final renderings and break them into multiple sprites, a laughably simple task to do in any image editor. I would also suggest this.

Share this post


Link to post
Share on other sites
1. My engine is 2D.
2. I tought object as some sprite (static or moving entites)
3. Movement and colision isn''t my problem. Now I want know how implement bigger objects into map array in memory. This is my top priority problem.

Share this post


Link to post
Share on other sites
As I said, the way I did this is to assume sprites have no relation to the tile map(s). The sprites are stored in a linked list. Their position (center of the bottom of the sprite) is stored as X,Y with no attention paid to what tile it rests on. When they move they are tested against one or more tilemaps which I have loaded using lots of line segment tests (and some other stuff for optimization, but that doesn''t matter ). I still haven''t implemented sprite to sprite collision detection, so I''m not sure exactly what I want to do with it yet (still going over my options ).

[Resist Windows XP''s Invasive Production Activation Technology!]

Share this post


Link to post
Share on other sites
If the ascii picture below looks messed up go
to notepad and paste it:


/\ /\ /\
/ \ / \ / \
/ \/ \/ \
/ X X X \
/ \
/ \
\ X /\ X /\ X /\ X /
\ / \ / \ / \ /
\/ \/ \/ \/

/\ /\ /\
/ \ / \ / \
/ \ / \ / \
/\\ X //\\ X //\\ X //\
/ \\ // \\ // \\ // \
/ \\// \\// \\// \
\ X / \ X / \ X / \ X /
\ / \ / \ / \ /
\/ \/ \/ \/


Is that your problem?
If you have one big object occupying fo example
7 squares break the bitmap up so you have 7 single
sprites for the one object.

The clipping problem can be solved by simply
drawing from the upper left to the lower right
corner of the screen. This way your new objects
hide the older objects.

I have no idea how to solve the clipping problem
with moving sprites however.

--::[Madhed]::-

Share this post


Link to post
Share on other sites
Sorry, I forgot that HTML cuts spaces.
This time it will work:

If the ascii picture below looks messed up go
to notepad and paste it:


...../\..../\..../\
..../..\../..\../..\
.../....\/....\/....\
../..................\
./....................\.........1 Sprite
/......................\
\..../\..../\..../\..../
.\../..\../..\../..\../
..\/....\/....\/....\/

...../\..../\..../\
..../..\../..\../..\
.../....\/....\/....\
../\..../\..../\..../\
./..\../..\../..\../..\..........7 Sprites
/....\/....\/....\/....\
\..../\..../\..../\..../
.\../..\../..\../..\../
..\/....\/....\/....\/


Is that your problem?
If you have one big object occupying fo example
7 squares break the bitmap up so you have 7 single
sprites for the one object.

The clipping problem can be solved by simply
drawing from the upper left to the lower right
corner of the screen. This way your new objects
hide the older objects.

I have no idea how to solve the clipping problem
with moving sprites however.


--::[Madhed]::-

Share this post


Link to post
Share on other sites
I think your best bet is to split the sprites up if you
do not want to get into Z-buffers,Span-buffers,c-buffers
and so on.

At runtime you have to find out what screen tiles your
sprite is going to intersect (Or do this ahead of time for
static sprites). Now you have to split this sprite. Basically
the painters algorithm has an advanced stage that splits
polygons in much the same way but you are dealing with rectangles
(I assume) so the splitting process is much easier in your
case. Knowing that these "sub sprites" are now in a
manageable state you can work out the rendering order.

Get yourself some graph paper and draw a rectangle on the paper
now work out how you would split this in code. I find it helps
a great deal when you can visualise the problem rather than
trying to do it in your head. Your brain will pick up patterns
and will crunch this problem in a matter of nano seconds.

Your visual system is very,very advanced use it!





Share this post


Link to post
Share on other sites
This is a clipping problem. Your sprite has to be clipped
to the ISO tiles it is going to intersect.

Your sprite is like a small window overlaid on the ISO
tiles. I am assuming Diamond shape ISO tiles here. Basically
it doesn''t matter but calculate the four slopes of your
tiles (Actually two slopes with a Diamond)

Now your sprite will intersect a region of the screen. You
need to find the tiles that the sprites bounding box intersects.

Now you need to clip your sprite to each tile it intersects.
You are actually clipping the tile against your sprite window
except you are storing the clipped coordinates rather than
clipping the tile.

Sorry but this is real difficult without a diagram I will
try and post one.

You have two options here depending on how you want to blit
them.

If you want to go through the blitter then you will need to
create bitmaps on the fly and apply a masking region to the
clipped parts.

Other option is to turn your sprite into a series of clipped spans and blit them yourself.

Sorry I do not have any code. All of the stuff I do these days
is 3D and I use span buffers/Z buffers for these kinds of
problems.














Share this post


Link to post
Share on other sites
After thinking about this problem some more it could get
very messy doing all these clip tests.

(I think somebody pointed that out already)

When you blit a tile on the screen that tile occupies a series of horizontal spans.

So for Y=0 you will have a set of spans going from left to
right (Depending on how you want to do it). The span will occupy a starting X and have a width and also a unique reference to
that map position.

Do not draw any of your map yet. Just build up a span list.
Note there are a lot of optimisations to be had because all
your tiles are regular so you can precompute span coordinates
and cache them.

By the end of this pass you will have a list of spans for
each scan line sorted in X with associated tile numbers.

So at Y=0 loop through the spans on that scan line and check
if your sprite intersects anything in X. This has broken the
problem down into a simple horizontal overlap test. Now keep
track of the tile number in the span list. If this tile number
changes then you can clip your sprite to the overlap.

Let''s say scanline(0) has two spans and two tiles A and B
Your sprite intersects this line...

AAAAAAABBBBBBB
SSSSSSSSSS

Now you need to create a split on your sprite because it is
overlapping two tile positions Store it against the map location ,linked list whatever. Essentially each map position has a list of sprite spans on that tile.

Now render your map/splits.

So to recap:-

1. Break your scene down into a series of sorted spans
2. Clip your sprites against these horizontal spans
3. Blit the map/spans

This will work for moving sprites as well.

I was also tempted to suggest a Z buffer but not a traditional
one. ISO engines can take advantage of constant Z.

I hinted at optimisation. Your tiles can be prescanned before
hand. Take a tile and loop through it and store a span list
against this tile.

This is very much how compiled sprites work. Basically you
are storing drawing commands. So this will help speed up your
span building.




















Share this post


Link to post
Share on other sites
lately, i''ve been working in d3d8 on iso3d methodology. this has required me to think "outside the rhombus" about some things.

what i have discovered:

setting up a iso3d view with a 3d api is rather simple. you concatenate a translation matrix(for scrolling), a rotation matrix(45 degrees for a traditional iso view), and an uneven scaling matrix to make your view matrix(i.e. scale 64 for x and 32 for y). you concatenate a special matrix to make your z add to the y coordinate and a scaling matrix to make your projection matrix. you can also just concatenate all of these matrices into the projection matrix for lighting to work a little better if you want to use the lighting engine.
the world itself should be based on x,y values. tile (0,0) in the map is bound by the world coordinates (0.0,0.0)-(1.0,1.0), so each tile spans the coordinates (x,y)-(x+1,y+1). we get to treat the map as though it were a square tiled overhead view. we say that z always points up, so a z coordinate adds to the y coordinate after most of the other tranformations take place.
z buffering works just fine in this schema. you can easily set up a range for allowable z values in the projection matrix.
mousemapping is a little harder. so far i''ve made something that will apply the inverse of the scaling matrix, rotation matrix, and translation matrix to give me the world coordinate, and this works, but it will only work for flat maps. for non-flat maps, it at least gives us an approximate location so we know where to start looking.
when z-buffering, the order of drawing things becomes totally unimportant (sure, we''ll get some pixel redraw, and we really should sort front to back for rendering, but it''ll look fine if we dont.)
so, really, a larger object is a non-problem. you just use a model that is larger than a tile.

Share this post


Link to post
Share on other sites
So you advocating going 3D eh :-)

I must admit that I prefer worrying about the game now
since going full 3D. Writing fancy rendering routines
is all well and nice but it seems about the right time
to let the hardware sort this stuff out.

The next generation of cards are going to take out the
whole overdraw problem as well with occlusion buffers
and such like.

ISO has X,Y and Z. Let''s embrace the fact



Share this post


Link to post
Share on other sites
I''ve been using DrawPrimitive for a while and the biggest problem is overdraw. But I use tiles that don''t take up the entire cell and have foreground and background tiles. Large objects still don''t draw properly as a result.

Getting the orthogonal view took a quick change to d3dutil.cpp

Mouse mapping is no different than what you would use with regular ISO unless you allow the view to be user set.

The mouse routine I use doesn''t look at the screen really. It knows where the camera is located in the map array and shoots a ray down through the array at the view angle until it hits something. That''s where the user clicked. It can go through windows and doors that are open as well.

If I decided to adjust the view angle, I''d just have to refigure out the math for the ray. If I could generalize it, then I could allow a user changable view.

I think the best solution is full 3D using 3D tiles. I''m sure there''s a way to have more than one z value for a primitive (I mean on a per pixel basis) but I doubt it''s easy to use. 3D tiles (like Sim Theme Park) would eliminate that. It would also get rid of the math since you''re using pure X, Y and Z values instead of X,Y and Z values converted to X and Y values.

Ben
http://therabbithole.redback.inficad.com

Share this post


Link to post
Share on other sites