Hey all, I’m working on a 2/3 perspective game (think Don’t Starve) and I’m wondering what the best method would be for managing the draw order of sprites? My naive solution would be just set their z-index to match their y position, but then you’re limited to a world size of 65534x65534 pixels which might be enough, but I feel like there must be a more elegant solution out there. Any thoughts?
You should only need to map the visible range to the z-index as everything outside of that isn’t visible. That would make the range 240 + your biggest sprite (for partially visible sprites).
Is there a way to iterate over just the visible sprites , or would I have to set every sprite every frame based on their offset?
These are good questions that I also need answered. Any wise guys out there?
I think you're overthinking it. If you want the 3D-ish effect of being able to walk in front of and behind things, having Z correlate with Y is exactly what you're looking for.
I have a hybrid solution in my game I'm working on. I have things "in-world" generally being Z'd by their Y and for like menus and other UX stuff I have just a bunch of hard-coded values in a table.
I think I'm now realizing you are talking about a game where the camera moves around with the player. I was like how the hell are you getting this massive grid... Okay so with that problem, I think the solution is largely the same? But you may want to write code such that it's doing "on-screen z-rendering" versus a global Z-rendering using the massive coordinate system.
As in have some relativistic approach, so that everything is Z-index based on it's position on screen, not it's position in the world. Does that make sense? Then you're able to just always have the top be 0 or 1 or whatever and the bottom be 240ish.
This should prevent that grid limitation you were talking about? Unless I'm totally off-base. Hope this helps.