Comments (8)
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!
from junkbot.
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!
from junkbot.
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?
from junkbot.
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
from junkbot.
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?)
from junkbot.
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.
from junkbot.
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...
from junkbot.
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?
from junkbot.
Related Issues (20)
- Implement progress tracking
- Target to get in-game - scaffold actors
- Fix window aspect ratio on resize
- Level list is off by one
- Bin should be removed from the scene when Junkbot collects it
- Update level status upon completion
- Implement move counter
- Track par move count
- Implement Jump Brick actor
- Implement Movable Jump Brick actor
- Implement Shield Brick actor
- Implement Fan Brick actor
- Implement Fire Brick actor
- Implement Switch actor
- Implement Drip actor
- Implement Gearbot actor
- Implement Climbbot actor
- Implement Flybot actor
- Implement Eyebot actor
- Implement level begin and end dialogs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from junkbot.