For my school project, we're working with 2D, and I am currently in the long and arduous process of modefying a pre-existing engine that's nearly garbage into something workable for my group.

I am taking a 2D side scroller using Directx11 and some 3D features, and completely remodeling it into a 2D engine that's making use of prerendered isometric sprites.

Naturally the camera angle is looking down at 30, and to the side by 45 when the sprites are rendered to maintain a 2x1 pixel ratio of width to height.


After taking a break and nearly completing the rendering and animation code that my group will be using. I decided to play a bit of Diablo 2 to relax and get some inspiration.


That was when I ran across a neat little trick that I couldn't quite wrap my head around very well.

A game made back in 2000 and was fully 2D, actually did an amazing job at faking a perspective projection with parallax.

Image courtesy of Simon Schreibt

After reading his blog... it didn't seem right to me.


It felt like there was quite a few details that were missing.

The most I know about perspective really came from art classes that I was forced to take in University. Which requires a horizon line, which is normally marked by the viewer's eye position and several focus points.

Looking at this you really couldn't see the horizon line... but another image later....

Shows that the horizon line is somewhat under the character, So it's top focused.

Judging by the angle, I can only say that the the actual focus points are far off in the distance, with some additional data to tell the engine what focus point to use.

But I'm not very sure on how this was done... and everything was still tillable.

Hell the ground stumps me.

Does anyone have any insights?

All images are from this man's wonderful blog.

https://simonschreibt.de/gat/dont-starve-diablo-parallax-7/

The page on SNES Mode7 he links to early on gives a clue in the section on transformations:

However, many games create additional effects by setting a different transformation matrix for each scanline. In this way, pseudo-perspective, curved surface, and distortion effects can be achieved.

They alter the scaling of the sprites depending on how far away from the view point each row appears on screen. Think about drawing the ground tile diamonds. The scale at the nearest point is going to be larger than the scale at the farthest point. Scaled in this way, the quad you use to draw your tile will look more like a trapezium rather than a rectangle. The good news is, if you are using 3D hardware to draw your sprites, you only need to work out the scaling at the corners and the hardware will take care of the rest.

The bit about sprite orientation for walls seems to be to allow different hacks depending on whether the left or right of a sprite is nearer the viewer.

Well the mode 7 is not the hard part. The hard part is trying to figure out how to handle the standing walls.

I saw that they are depending on information about the orientation of the sprites.

However it doesn't matter which side is nearer the viewer. Conceptually, the focus points always follows the viewer, with new ones being created and added as objects of different angles appear.

The problem is what determines how these wall tiles scale properly?

If you have a single long wall with every portion of it being the same height, than it's horizontal edges must shear to the respective focal point.

If it was just that, then you can take each corner piece and use them as end points. Vertically scale the corner pieces depending on how close they are to the camera. Scale every wall tile horizontally just slightly so they overlap to correct some error.

Find the angles between the focal points and the vertices of the corner piece. And then project each verticy of every wall to that.

The problem here is that a shader really can't get that kind of information. As far as I know of...

It is pretty much calculating the shear and scaling of the corner points.

It might help to think of what happens to the sprite's bounding box when it's transformed. Below is the sprite transformation animation from the blog with the bounding box of a sprite shown:



The steps it shows are:

1. Isometric view on isometric grid.
2. Move bottom right point to match distance (i.e. perspective distorted grid).
3. Scale height to match height of right edge at that distance.
4. Move bottom left point to match distance.
5. Scale height of left edge to match that distance.

Note the top and bottom edges are not parallel in step 5. This matches the following image from the blog:



Calculating the positon of the bottom right point and the height of the right edge are realtively easy. Calculating the bottom left point will be difficult since you really want to match the position of a point some way above it to a position on the ground. It might be easier to calculate the top left point and left edge height instead. (Adjust as appropriate for right facing walls.)

Whilst it might be difficult to implement all this in a shader I wouldn't bother trying, at least until you've got it working on the CPU. Remember, this game was released before GPUs had shaders and CPUs were much slower at the time too. You shouldn't have performance problems doing the maths on the CPU and passing all the quads to the GPU for rendering.