Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1393528 Posts in 67079 Topics- by 60015 Members - Latest Member: Faller

July 25, 2021, 02:05:40 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Isometric drawing order
Pages: 1 [2]
Print
Author Topic: Isometric drawing order  (Read 16658 times)
droqen
Level 10
*****


View Profile WWW
« Reply #20 on: July 23, 2009, 07:32:08 AM »

Is it just me... or is the whole problem not really a problem at all? Even in the case of the rather happy flesh golem, EVERY PART OF HIM is drawn behind the four 'front' blocks, in front of the five 'back' blocks... and he shouldn't overlap with the blocks on the same line ______ this way as him.

If his sprite DOES happen to overlap with those blocks, you use the same principles as in a side-view game when the sprites overlap. You figure out 'I want entities drawn behind' or 'I want blocks drawn behind'.


To solve the first flesh golem problem, all you have to do is draw all entities on each row behind/before all blocks on each row.


In short, I still have yet to see why all this splitting and over-complication is necessary.


---> Also somehow I missed Gauss Jordan's post right before mine. But, still. Dealing with tiles on the same 'row' as you is the same as dealing with simply overlapping sprites in a side-view game: You just pick what you want to draw first.
( I misread the first flesh golem example. I thought it was just a really huge sprite for a 1x1 character )


-----> ahaheh. I'm slow to the party. Anyway, yeah, drawing based on the 'rightmost' tile or based on the middle point of the base is how to go about doing this... even though it's already been figured out :]
« Last Edit: July 23, 2009, 07:42:30 AM by Droqen » Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #21 on: July 24, 2009, 01:43:47 PM »

The problem is you guys don't even know what you want. It isn't obvious to me that a 1.01 units wide golem standing horizontally from a single piece of wall (a column) should go either behind or in front of it. You've just drawn a wall which swoops in front of the golem, so you expect the golem behind, but you could easily have drawn a wall slanting the other way. And you are expecting to make the decision on a tile by tile basis, so this is basically impossible.


It sounds like the only full solution is to assign a depth value to each pixel (when drawing the original sprite), and then draw to the screen based on that. Kadoba's 'solution' is essentially that, only assigning depths somewhat granularly.
Logged
Kadoba
Level 3
***



View Profile
« Reply #22 on: July 24, 2009, 01:52:47 PM »

Well I'd draw another elaborate example to illustrate why the unit should be drawn behind the wall but the problem has already been solved. My way was actually over complicating it. Drawing a large unit on the last rendered tile in its middle row actually solves everything. Shrug
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #23 on: July 24, 2009, 02:39:13 PM »

That's because you changed the problem - the purple one fits width-wise entirely within the area he takes up (a 3x3 square). Not so the original brown golem.
Logged
Gauss Jordan
Level 2
**


This world!


View Profile WWW
« Reply #24 on: July 24, 2009, 11:35:40 PM »

That's because you changed the problem - the purple one fits width-wise entirely within the area he takes up (a 3x3 square). Not so the original brown golem.

The small golem was defined as taking up a 2*2 space. Actually that was part of the solution on the problem with the golem sprite intersecting the walls. But that got a little problematic as well.
Logged

Lefty-concepty, righty-pixley, but bothey programmey.
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #25 on: July 25, 2009, 01:15:17 AM »

The small golem was defined as taking up a 2*2 space.
Oh yeah, didn't notice that. Sorry.
Logged
bengarney
Level 0
**


View Profile
« Reply #26 on: July 27, 2009, 08:16:52 PM »

-----> ahaheh. I'm slow to the party. Anyway, yeah, drawing based on the 'rightmost' tile or based on the middle point of the base is how to go about doing this... even though it's already been figured out :]

This is the one true way to solve it. Everything else is just mental masturbation.

If you want to support altitude, just offset the base point vertically (and sort it by the same rule).

Do not draw by walking the tiles in order. This will never work.

In a larger sense, this is an implementation of the painter's algorithm, which will break down if you have large/oddly shaped objects. Just don't do that. If you really do have something like a line, clip it along tile boundaries and sort the pieces. Or you can do an exact sort by treating everything as planes and then clipping the line against them. But you could probably fake it and save yourself the trouble.

At a certain point you just have to give up and go with a z-buffer. But Diablo got pretty far with these limitations, so I bet you can, too.
Logged
Pages: 1 [2]
Print
Jump to:  

Theme orange-lt created by panic