Monday, June 10, 2013

Quick update on Java port

I'm getting there, and since I already have all the functions I need to draw things (I just need to port them) I don't really expect any trouble.

Sunday, June 9, 2013

Fully fake-3D rendered 3D world.

I'm pretty happy that I can report some more progress:

However, I am running into performance issues that I cannot properly address as long as I am using Game Maker.
The trouble is, I need to do a lot of math in Game Maker, whereas in Java I only need a few lines of code.
So I'll be busy getting the exact same thing to work in Java right now and then I'll be continuing from that.

Friday, June 7, 2013

Demo


Explanation of isometric mechanics.

Quick explanation of how I drew the dotted grid last post.


xlocation = ((xi-xorigin)*cos(degtorad(rotation))-(yi-yorigin) *sin(degtorad(rotation)))*blocksize+room_width/2;

ylocation = ((yi-yorigin)*cos(degtorad(rotation))+(xi-xorigin) *sin(degtorad(rotation)))*blocksize/2+room_height/2;

Wow, that seems quite complicated. Let's dissect this.

Remember we had a little array going?

the indexes are displayed along the axes.

Blue is the X-axis, yellow the Y-axis.
The origin is the point the grid will be rotating around. It is, in fact, the position of the player on the grid.
It has an X and Y value too. Here, both xorigin and yorigin are 1,5.

The location to draw a tile in is calculated for each tile.
That leads us to the nature of our loop straight away: a FOR-loop.
FOR-loops work with indexes, and that's exactly what xi and yi are.

then we have some vars that are meant to display it properly:
blocksize is the size of the displayed blocks, or rather, the blocks that would have been displayed if I had finished the drawing of primitives for this build. If I didn't use it, each block would be 1 pixel wide and half a pixel tall.
room_width and room_height are built-in variables to get the size of the 'room'. For now, that's simply the screen size.
rotation is the current rotation around the character.

We want to draw the origin exactly at the center of the screen, because we are following the game character, LAG.

As you can see here, if we draw LAG at the origin that is calculated, he will stand invariably in the middle.
Whereas the origin on the grid was at x1.5 y1.5, the origin on the screen is displayed at x(rW/2) y(rH/2).

If we now dissect the original formula:

(xi-xorigin) is the location of the tile to be drawn relative to LAG, our character.
Therefore we could say: {xRelative = (xi-xorigin);}
The same goes for the Y location: {yRelative = (yi-yorigin);}

If we do the same for the calculations needed to display the tiles properly, we get:
{xDisplay = blocksize+room_width/2;}
{yDisplay = blocksize/2+room_height/2;}

And finally we can take care of the rotation:
{cosOfRot = cos(degtorad(rotation));}
{sinOfRot = sin(degtorad(rotation));}

If we now fill this into the function it looks easier.

xlocation = (xRelative*cosOfRot-yRelative*sinOfRot)*xDisplay;
ylocation = (yRelative*cosOfRot+xRelative*sinOfRot)*yDisplay;

As you can see, the part between the parentheses is simply Matrix algebra.
I don't exactly know how that works, but I might update you on that later if I can find the time.

Thursday, June 6, 2013

Build 2: Full rotation


Isometric? Check.
Fully rotatable over 360 degrees? Check.
Character movement? Check.

I think it's about time to call Indev version 0.02.
You may notice that the tile textures are gone, but that's because I'm still switching to primitives for drawing them.
But that's going to be in Indev version 0.03.

Wednesday, June 5, 2013

Implementing theory into the game

Sorry that it's taking a while, I am busier than expected with other projects.
However, that does not stop me from making progress with this one:

Still need to transform the tiles themselves, but I'm getting there.