Ripple Haxe Port, 1

Finally started on something I’ve been wanting to do for a very long time. A serious try to port Ripple Dot Zero to haxe, so I can compile it to c++, run it on Windows with full gamepad support and full, smooth framerate!

This is after a few hours of experimenting with openFLs new Tilemap API, and one day of porting (well… mostly rewriting) the tile rendering part of my old engine. Now it runs on a solid 60 fps after compiling to C++, even though there are tons of optimizations to be done.

Right now it renders all static tiles (no animated tiles, and no sprites) from an existing level, and lets the camera move in a huge sine wave over it.

A very promising first step!

Math - Triangle Rasterizer

Warning: lengthy post ahead! But lots of really cool stuff!

Been a while since I posted now. There are a couple of reasons for this:

• First of all, I decided to write my own software triangle rasterizer (I’ll get to explain what that is in a bit)
• It’s a lot of math involved. And a lot of diagrams with pen and paper. I has spent several hours to get it to its current working state
• My parental leave is getting close to the end. My kids are now almost 16 months and require a lot of attention! Have not gotten any computer time at all for the past three weeks

But now I finally have something to show, so lets show it!

READ MORE >>

Math - Backface Culling And Directional Lighting

Up to this point I’ve only drawn wireframes. To create colored 3d objects I need two things. Backface Culling and Z Sorting. Time to start with the first: Backface Culling.

• First of all I changed to using triangles instead of just points/lines.
• Then I calculate the cross product on two of the sides to get a normal vector.
• Compare the normal with your viewing vector (a line from the camera to the middle of the triangle) to see if the triangle is facing towards you or away from you
• Don’t draw if the triangle is facing away from you

Now you no longer see any lines “behind” the cubes. I also draw the normal vectors for each triangle.

From this point I just filled the triangles with a single color.

With the normal vectors already calculated on each triangle, I tried to implement some directional lighting as well. It went much smoother than I would ever have thought.

Pretty interesting! I made a spinning cube with lighting almost exactly ten years ago. However I did not understand much of it, and going back to that tutorial it seems to be full of weird tricks. This time however I did it all by myself =D.

Next up is Z-Sorting so we can have more than just one cube at once

Math - The Camera Matrix

I’m doing serious progress! Today I managed to get the camera matrix working!

The coolest thing about this is that just a few months ago I would have thought that this was too much math for me to ever be able to understand! Remember that I have written everything from scratch - except for the line render code, which is basically just a lineTo(x,y) function. Even the matrix implementation.

There’s no frustum culling in there yet (except for any z-values behind the camera) so pretty much everything gets drawn all the time.

Resources for camera matrix: Camera View Transform Matrix Faster Matrix Inversions

Math - 3D and Perspective

In our last blog post we used matrices to translate, rotate and scale vectors, but so far only in 2D.

Transforming vectors in 3D is pretty much the same thing. The only difference is that we cannot directly plot those vectors out on the screen since each vector will come in a triplet of {x,y,z} and the screen only consists of {x,y}.

We could just ignore the Z-coordinate, but that would look weird!

To get it to look right we need to apply perspective. Perspective means that an object that is further away from our eye will appear smaller than an object that is closer!

Applying perspective to 3D-points is something I’ve been able to do for a long time, but now we’re working with matrices, and of course there is something called a perspective projection matrix!

Another great resource I found on the subject is scratchpixel.com, here on Perspective Matrix Projection.

In the past when I’ve been playing with 3D, I’ve used trigonometry for all transformations. It works, but has several drawbacks!

• More computation heavy! Needs to do Sine and Cosine lookup for each point!
• Much more complex to nest parent/child-relationship!!
• Viewing from a camera… I don’t think so!

Using matrices is superior by far. The image below is just a couple of matrices combined, using vectors forming a cube and a pyramid. This would not have been possible using my old 2006 methods!

If you want to read up on this too, then check out:

Math for game developers youtube channel And http://www.scratchapixel.com/index.php?nocategory

Math - Matrices and Vectors

After my Shader Week I decided to try to re-wake the math part of my brain that feels like it has numbed of a bit in recent years of Android app development. I have actually been doing this for several weeks now, but have not had anything to show until now.

So I started reading up on Linear Algebra, and is currently writing my own custom implementation of Vector and Matrix-classes from scratch in Haxe. And it’s super interesting!

Rotation Matrix

If you have a 2x2 matrix you can put an up-vector in the first column and a right-vector in the second column. When multiplying a vector with this rotation-matrix it will transform the vector into that coordinate space! If you rotate the up and right-vector clockwise each frame you get a rotation matrix!

In this first image I multiply four 2d-vectors through a rotation matrix. The unmodified vectors are shown to the left.

---

TRS Matrix (Translate Rotate Scale)

Another interesting thing with matrices is that you can combine them! If you have one matrix for translation, one for rotation and one matrix for scaling, you can get a single matrix containing all those values by multiplying them! Just remember to multiply them in the correct order!

In this image I changed the four vectors to form a square instead of that cross. Then just multiplying each vector through my single TRS-matrix.

---

Parenting

If you have a TRS-matrix named M1, and another TRS-matrix named M2, you can move the transformation of M2 into the local coordinate space of M1 by multiplying M2 with M1! By doing this M2 will be “parented” to M1! It’s so simple!

The big square is rotating and the second, smaller square is parented to the big one, therefore inheriting its rotation. Same with the third square (it inherits both the rotation and scale of it’s parent before applying its own rotation).

The vectors (points) for all three squares are just a single unmodified array. All the transformations are done though a single matrix multiplication (for each point).

---

I will keep working through the math, so expect more posts on this. In the mean time, these two youtube playlists are really great resources:

Math for game developers Khan academy: Linear Algebra

TLDR - Part 4: Component filtering BLAZING fast with macros!

Made a huge optimization in the way Seagal filters list of entities that contains specific components!

Using the macro I’ve written two days ago as a base I now use bitflags instead of multiple for-loops and several Std.is(classA, classB). I now just use simple bit-flag comparison as the macro auto-generates a unique bitflag for each component class, and the result is stunning!

I actually had to go back to my old test and change the number of entities from 10,000 to 100,000!!!

Note 1: Both test 2 and test 3 took 0.001 seconds when running 10,000 entities. That’s why I had to increase the number of entities.

Note 2: Test 2 now takes only 0.007 seconds with that huge amount of entities!

Note 3: Running identical test 3 with 100,000 entities on Edge gives an approx time of 0.049 seconds, even slower than my own old solution…

High fiving myself

Haxe Macros, Part 1

When reading up on the Edge-entity system in the post about TLDR I got an idea on how to speed up my Seagal enging a lot using macros. The problem is that macros is a subject with few tutorials and resources online, and it seems a lot of people are afraid to look into it.

I will try to explain what macros are, some good places to start learning more, and a cool example that I’ll expand upon to improve the speed of Seagal!

READ MORE >>

TLDR - Part 3

I’ve downloaded and tried a new exciting ECS-framework called Edge. The interesting thing about it is that it relies heavily on haxe macros to generate code at compile time that will remove of the costly runtime type checking.

I did a similar test to test number 3 in my TLDR - Part 2. Only the third test was interesting to me.

And look! It’s taking between 4 and 5 milliseconds here as well! That was surprising, I really though you had to try hard to be slower than my current implementation.

However, using macros seems super interesting. and I just got an idea on how I could use macros in seagal that might speed the matching up quite a bit!

TLDR - Part 2

Starting designing my little game engine, I decided I wanted it to run on top of my existing ECS (Entity-Component-System) I made a few years back called Seagal. However - after started drawing a bit of system design on a piece of paper it became clear that I would require a HUGE deal of entities, components and component fetching. Looking at the code it became obvious that it was written for developer comfort and not the amount of speed that was required.

But that was just my gut feeling. What is better? Data! So I started writing a few performance tests:

My test suite consisted of

• 10.000 entities
• each having one TestComponent1 and one TestComponent2 attached
• the tests are run on a windows build in release-mode.
• on my stationary computer with an i5-4670 CPU @ 3.40 GHz, Win8.

So bootstraping the whole system, and adding the 10.000 entities with its components took 2 milliseconds. Not all to interesting, we will probably not add so many components during a game session. Rather during start-up.

My second test was to ask the system for an array of TestComponent1’s, disregarding which entity they belonged to. It took 2 ms for 10.000 entities.

In my third test I do three things: First I query a list of all entities that has both TestComponent1 AND TestComponent2 (in this test suite that means all of them). Then I iterate through all entities, requesting a reference to TestComponent1 and after that another reference to TestComponent2. That took 4 ms.

I was surprised to see the third test be only 4ms. I know I have a ton of possible improvements I can make. The look-up is not very efficient, and I do not cache the result so any subsequent calls would redo all that work even though nothing has changed.

Before I can go on I want to see if I can speed my ECS framework even more. Meaning that the next couple of posts will be about Seagal before continuing with TLDR!

Note to self: I found this existing ECS-framework for haxe that seems really interesting! https://github.com/fponticelli/edge

TLDR - Part 1

So, I’m currently on parental leave for 6 months. I hadn’t planned on doing any programming. I thought taking care of two twin girls 10 months old would take 100% of my energy, but I figured I get an hour here and there every now and then that I could devote to some programming.

I need a project!

TLDR stands for Tommys Ludum Dare Resources… or something. Not quite sure yet.

It’s going to be a 2d game engine built in haxe, on top of openFL and my previously built entity framework Seagal. A small engine, that I can leverage on when doing game jams such as Ludum Dare. And I’ll be starting from scratch.

Here is a list of some things I figure would be nice to have in the engine. I might add or remove stuff as time passes.

• I don’t want it to be tile based. I want everything to be freely placed and rotatable.
• For that I need to write some fancy collision system. Both broad and narrow phase.
• Need to work a lot on making this debuggable. A lot of places where stuff can go wrong.
• In-game level editor will be needed.
• Game objects and animations.

Wow, that’s a lot. I think I’ll stop there for now. We’ll see how this turns out. Today I’ll start on setting the project up.