Depth sorting - almost solved

This forum is currently in read-only mode.
0 favourites
From the Asset Store
A very simple to set up ZElevation based depth of field system for your game. Fully commented.
  • Holy crap... it works!

    IT WOOOOOORKS!

    http://dl.dropbox.com/u/529356/isometric.cap

    I can't believe it. After a thousand years and a million sleepless nights, it actually, really works. In-friggin-credible.

    Now I just have to make collisions work, heh

    Awesome job, guys .

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • It's pretty good hey!

    I've got my little iso demo to almost exactly where yours is.

    It's still not 100%, if you sit halfway between some blocks and raise the height, there's a bit of overlap

    Once I work out a few more things I -might- be able to fix that

    I've nearly got some crappy collisions done too, but I'm just using 8 direction behaviour lol

    Collisions should be reasonably easy for you, because you got the cool 4 directions going, I would just 'invert' the currently active movestate if overlapping an obstacle, assuming the zBottom and zHeight variables fall between the obstacle's respective variables too.

  • I also got a more accurate ratio type thing

    Now my sorting code is:

    + System: For each Layers ordered by Layers.Bottom + Layers.Value('ZHeightBottom') + (Layers.Value('ZHeight') * (1 - (35.264 / 54.736))) Ascending

    -> Layers: Send to front

    For a 2:1 ratio like pixel art isometric, it would be:

    + System: For each ObjectName ordered by ObjectName.Bottom + ObjectName.Value('zBottom') + (Layers.Value('zTop') * (1 - (30 / 60))) Ascending

    -> ObjectName: Send to front

    The (1 - (30 / 60)) can just be replaced with 0.5, I just put it in there to show how it works.

    The difference between the two is that I'm trying out using a true isometric view angle.

    Still working on this overlap issue when standing between two blocks....

    Still hating this family bug....

    EDIT: Actually, with a bit of testing, this formula has a bit of overlap when walking on top of things hmmm......

    EDIT 2: Ironically, I'm using a different view angle to 2:1 iso, yet the 2:1 iso sorting formula works perfectly?!

  • I can't make collisions it's veryhard

    I will try again later

  • Here's my little Isometric attempt

    http://dl.dropbox.com/u/1289341/IsoDemo.cap

    I've got some collisions going but they're not 100%

    I stole your movement code

    Coincidently, everything else wasn't copied, just happened to be incredibly similar to yours, even down to the tinting

  • Awesome work guys!

  • http://dl.dropbox.com/u/1010927/isometric%20engine3.cap

    platform movment!

    i need to implement your wonderful depth sorting into my engine

    also guys, remember if you want your stuff to move properly within the iso grid, you have to make movements across the Y axis 1/2 speed of the x axis movements and the trig gets complicated having to work on this flattened grid.

    i have that and jumping working here, but it uses simple depth sorting.

  • In pixel art isometric though, instead of 0.53125, you would probably just use 0.5

    in TRUE isometric images you would use 1, as isometric means all axis are equal, there's no "squashing" on any of them. Then again, most "isometric" art is not really isometric, as it does look a bit weird.

    In my system I allow an angle, so this factor starts at 1 but it will be set to the cosine of a view angle (press Q and W), and objects get repositioned accordingly (so at 90? it's ISO, at 60? its 0.5). It seems to go weird below 45, but that probably depends on the source art.

    Speaking of which, Deadeye, our stickmen shall do battle XD

    wooo Construct going ISO!

  • Here's my little Isometric attempt

    http://dl.dropbox.com/u/1289341/IsoDemo.cap

    I've got some collisions going but they're not 100%

    I stole your movement code

    Coincidently, everything else wasn't copied, just happened to be incredibly similar to yours, even down to the tinting

    I used your .cap to make jumping:

    http://dl.dropbox.com/u/529356/isojumper.cap

    It jumps! In isometric! I kinda cheated, it uses Platform behavior, but the platform player sprite is off the screen. The iso player sets it's height to the platform player's height, basically. And I used your collision code to set some blocker objects in the platform area to simulate the ceiling/floor.

    A couple of problems:

    1. I don't know why but the sorting is no longer working 100%. Maybe because I moved some events around, I don't know.

    2. The player teleports down a floor instead of falling when you walk off an edge, this is because the platform behavior wants to "stick" to a moving platform, and the floor blocker is only moving a small 16px at a time, so the platform behavior thinks it's just a really fast moving platform. This could be fixed with a workaround.

    3. Sometimes the player suddenly flies off the screen, I think this is because the platform player is somehow getting squished and glitching outside of it's walls. (Edit: Actually, I think I fixed this by making the walls thicker)

    Edit:

    Oops, either I didn't see the next page of the thread or it got longer while I was working on mine... I'm gonna try Quazi's .cap now...

    Edit2: Tooooo Floooooaaaattyyyyyy . I like the 360 degree head movement though, very Excorsist.

  • > In pixel art isometric though, instead of 0.53125, you would probably just use 0.5

    >

    in TRUE isometric images you would use 1, as isometric means all axis are equal, there's no "squashing" on any of them. Then again, most "isometric" art is not really isometric, as it does look a bit weird.

    In my system I allow an angle, so this factor starts at 1 but it will be set to the cosine of a view angle (press Q and W), and objects get repositioned accordingly (so at 90? it's ISO, at 60? its 0.5). It seems to go weird below 45, but that probably depends on the source art.

    Speaking of which, Deadeye, our stickmen shall do battle XD

    wooo Construct going ISO!

    mine allows 360 movement on the squashed grid, toward the mouse at the correct speed for any given angle, check it out

  • 1. I don't know why but the sorting is no longer working 100%. Maybe because I moved some events around, I don't know.

    The sorting seems to be working exactly how it normally does. The sorting code I came up with seems to have trouble when your player is sitting halfway between two blocks and when standing on the top corner of a box. I'm still not sure how to fix this.

    These iso demos are all looking awesome everyone!

    Any help on the sorting code would be greatly appreciated!

  • Anything come of this, guys?

  • With the help of a stranger on the internet, I've got the code to a point where its -almost- perfect sorting-wise, however, the loop is so long and convoluted that it slows the game down exponentially and i can't really have more than about 10 objects on the screen at once without any slow down.

    And yes i've tried only updating the sorting only when something changes, it doesn't work very well with the current loop. So i'm taking a little break from it until i can think up something better.

    I REALLY want a working iso engine

  • What about using layers for different elevation levels?

  • TL;DR = in most cases it wouldn't work

    I don't think layers for elevations would work from what I understand.

    For example, if the player is in front of two stacked boxes and jumps, on his way up, at one point he would have to change layers. Where would this change happen? in this case, most likely as soon as he jumps. That should look fine, but what if the player is standing -behind- the two stacked boxes? The change between layers would have to happen as soon as the player's bottom '3d' side cleared the top '3d' side of the box on the bottom of the stack, otherwise, as soon as he jumped, he would appear in front of the bottom box, even though he should be behind.

    And in both cases, if there was another sprite nearby on the first elevation layer overlapping the player in a certain way (depending on which scenario), the layer swap would screw up the sorting.

    The best way I've found for figuring out how one sprite should behave in relation to another is to use this kind of zone diagram I drew up:

    <img src="http://dl.dropbox.com/u/1289341/Help/IsoZones.gif">

    This is how another object should behave if any part of it is in any of the following zones: (the zones are infinitely long obviously)

    [Blue] = In front, regardless of height

    [Red] = Behind, regardless of height

    [Green] = In front

    [Orange] = Behind

    [None] = doesn't really affect sort order but -can- be ordered by (screen Y + height from ground) if you really have to

    Green and Orange override Blue and Red

    Naturally, you'd have to define front and back X edges, front and back Y edges and bottom and top edges all in variables for each object. When I say X and Y here, I mean as isometric X and Y, not screen co-ordinates

    With clever coding, since you've defined the '3d' bounding box, you could probably figure out a way to sort them regardless of size.

    I know this is a pretty long winded answer to your question, I mostly put this here as a resource for anyone else looking for insight into figuring out how to go about sorting, or maybe it will give someone an awesome idea on how to solve it!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)