I keep getting questions regarding some of the more technical aspects of my 2.5D shading implementation in my earlier YouTube videos like, so I want to dedicate an entry here to explaining a little bit what's going on behind the scenes there and fielding questions. First things first, the original codebase at the moment is very outdated (still on XNA 3.1) and very tangled. It was one of my first projects, it's very badly organised and, at the same time, I do have plans for it in the future, so I won't be releasing the whole source code for the time being. That said, let's take a look at the basics. Overview The idea was very simple - to do away with drawing polygons for the most part and, instead, deal with geometry in screenspace, as an extension of the sprites you'd normally use in a 2D engine. Cons: Right off the bat, I'll come out and say that this isn't necessarily as great a performance-saving idea as it seemed to me back then. You're still doing a lot of work across the whole screen with pixel shaders, which is where the majority of the computation time comes in anyway.

Moreover, you're essentially loading every sprite three times over, so you have a pretty high memory usage too (and unlike in 3D rendering, where you can easily have much smaller resolution normal textures with high-resolution diffuse maps, you can't really do that here without sacrificing quality dramatically). I'm pretty sure something similar could implemented in say, Unity3D, with the right scripting and customised shaders, but I don't think this approach will ever be much of a performance saver - certainly not as much of one as I thought back at the time, when my understanding of computational expenses was still very limited. And while on more modern handheld devices you could probably get something like it to run, it'll probably need to be a fairly pared-down version due to restraints on how much per-pixel computation you can do and due to memory restraints. Pentagon Vst Rapidshare.

Zelda 2.5D Game engine on Scratch by zelda456. Mico Espejo R311 Manual. A game engine based on the BASIC language, with support for 3D using DirectX 7.

Bear in mind you could easily get a very similar effect with a fully 3D engine, rendered out with an isometric perspective. If you don't make the geometry too complicated, your memory usage would likely be significantly lower as you'd be able to share textures between objects, while the per-pixel computation overhead would be the same as with the 2.5D engine, if not lower.

Screeching Weasel How To Make Enemies Rar. By going 2.5D you give up quite a few things that would come naturally to a properly 3-dimensional engine - things like having a proper zoom function. Pros: With that in mind, here's what I see as some of the advantages. The main reason to go down this route, I think, mostly comes down to content creation and stylistic considerations since, as I've pointed out above, there's no real reason to do so for performance or graphics, with one exception. I think, graphically, the only real advantages here are the potential capacity for dealing with really huge polycounts by baking them into your sprites and getting a limited sort of multisampling for free, as your assets are likely going to come out of 3DS Max nicely antialised (I say 'limited' because geometrical intersections are not going to antialias themselves and, indeed, can end up looking quite rough).