Question Regarding Isometric Rendering

[EyeBallin]

Hey! Firstly, just wanted to say that I'm really happy to have discovered this repo - Junkbot was one of my favourite web games all those years ago, to the point where I'm currently making a game with similar mechanics.

Something that's currently stumping me, though, is the isometric rendering of all the game elements. Obviously, elements to the right and to the top render above elements to the left and bottom, but how does the game code achieve this with the objects that are greater than 1 block in length/width? We see Junkbot still being behind blocks to his right, and the 8-stud-long bricks being above other bricks directly below.

How does the game code achieve this rendering? I've scoured through it but can't see anything yet. Is that specific code in the repo yet?

[rozniak]

Hello!

I am not sure if the code is in this repo yet, I did write a little test application separately when I was reversing the level file formats to make sure they loaded and rendered correctly though. Not that I extensively tested it through gameplay, but if I remember right, rendering is pretty easy - I'm pretty sure just running through the grid, rendering objects left-to-right, bottom-to-top will result in the isometric view looking correct.

I hope this makes sense!

[EyeBallin]

Hey, thanks for the response!

That explanation does make sense, yes, and it's what my system currently uses. However, it runs into a layering issue when it comes to rendering the player character (or anything more than a single block tall).

Take the scenario of: Junkbot/PC, directly surrounded by two columns of 4 blocks to the left and right.
Doing a LtR, BtT rendering system, it'll render, in order: The floor brick, the lowest block in the left column, Junkbot/PC, lowest block in the right column, then alternating back and forth between the columns for the remaining 6 blocks. What this ultimately means is that the top 3 blocks in the left column, being rendered after Junkbot/PC, would appear in front of him instead of behind him like the bottom block does.

Thoughts on what the system might do to get around this?

[rozniak]

Ah you are quite right, I don't think that has been taken into account - I don't think any of the levels I tested would've shown that bug.

I can think of two ways of fixing it:

• Divide tall sprites into 1-block height individual sprites and render as usual (I actually think this is what the game does - Junkbot is separated into 4 pieces, I did wonder why this was the case - you may have noticed he's been stitched together in this repo)
• Do not render tall sprites until encountering the highest block - this could work as well, this repo uses a 2D array of cells for the board so it wouldn't be hard to skip rendering the sprite until checking that the block above is a different piece/actor

[EyeBallin]

I had a feeling that Junkbot might've split up the sprites, but that still wouldn't cover the full picture - when Junkbot moves up and down thanks to air vents and springs, there are split seconds where each individual part would be behind/in front of blocks on two different columns at the same time.

As for that second idea, I might be missing something, but I'm not fully seeing how that'd fix things - if you waiting until you were above the tall entity before rendering it, would that not then cause it to render over the blocks on the right? (Given that they'd be rendered first?)

[rozniak]

As for that second idea, I might be missing something, but I'm not fully seeing how that'd fix things - if you waiting until you were above the tall entity before rendering it, would that not then cause it to render over the blocks on the right? (Given that they'd be rendered first?)

You're not missing anything, that is exactly what would happen - woops. 😅 I may have to have a rethink over having stitched the sprites together...

I had a feeling that Junkbot might've split up the sprites, but that still wouldn't cover the full picture - when Junkbot moves up and down thanks to air vents and springs, there are split seconds where each individual part would be behind/in front of blocks on two different columns at the same time.

I'm not entirely sure what you mean... you able to conjure up a screenshot or something? Might make more sense with an image of the problem.

[EyeBallin]

I just analysed some Junkbot video frame-by-frame and I've realised that Junkbot's vertical movement is also always cell by cell - fans, for example, move him up one cell every 4/60 seconds (4 frames if the game runs at 60FPS, 2 if 30, whatever). So... That's totally how the developers got around that issue - splitting all tall objects into sub-images, and making sure everything was always grid-aligned. Can't say I can use that for my game I'm making, but it's good to know that we've solved how they did it!

... Now to try and figure out how to do it with my game...

[rozniak]

I actually get what you mean now - if Junkbot moves up by a pixel amount rather than a complete cell, he will be overlapped by bricks above to his left? Might've been why I couldn't picture it because I don't think that ever occurs in the game.

That is a tricky thing to fix thinking about it... if I had to solve it I'd probably use the z-buffer/depth-buffer in OpenGL (or whatever renderer it is) and let it do the job of clipping things whether they're in front or behind, similar to 3D code. That's just my theory anyway, I haven't done it in practice but it might be something to look into as a starting point?

[EyeBallin]

Yeah, I'm 99% certain it never has objects misaligned in the grid - and if it does, it happens far too quickly to notice.

I've been discussing this with a few people in parallel, because I'm developing with GameMaker Studio - which is really, really not good with isometric stuff. We've come to the conclusion of separating the 'background' elements of sprites (the tops and sides of all isometric objects) with the foreground elements (the front-facing sides), and simply drawing the background elements first and the foreground elements second. It'd be a bit of work, but I think it'll be a good solution.

Thanks for all your help with this, by the way! It's been really interesting discussing the technical side of one of my favourite childhood games. 100% going to be following this repo closely - I hope it all goes smoothly!