Jump to content

  • Log In with Google      Sign In   
  • Create Account

dave j

Member Since 11 Oct 2002
Offline Last Active Oct 19 2016 09:45 AM

Posts I've Made

In Topic: (bad practice ?) Pointers for having better variable names

19 October 2016 - 09:45 AM

Thanks, i'll use union to save memory

For the variable names, should i declare them all in the unions (so I have to decide here which can overlap, all the variables names for all objects will be declared into unions... )

You should have a union of structures not a union of unions. The latter will put all the variables in the sample space.

In Topic: (bad practice ?) Pointers for having better variable names

19 October 2016 - 05:43 AM

Kylotan's suggestion of using unions is the way to go. You can see an example of how to use them for the sort of thing you are wanting to do by looking at SDL's event handling - specifically SDL_events.h. Look at the SDL_Event union typedef at line 525.

In Topic: Does anyone know how to achieve this?

12 October 2016 - 10:49 AM

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.

In Topic: Does anyone know how to achieve this?

11 October 2016 - 04:44 AM

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.

In Topic: What a game programmer should know about GPUs

29 September 2016 - 06:04 AM

It's worthwhile understanding the differences between immediate (usually desktop) and tile based (usually moble) GPUs and how they affect performance. Even if you are only targeting desktop systems, it's still useful because desktop GPUs are beginning to implement some tile features and techniques that work well on tile based GPUs may be able to take advantage of Vulkan's renderpasses.