Java Jet Fighter

A game in progress

[themakingofagame]

Just a fancy pic to let you guys know that i have stopped the development of this game. It is nice to show and to have someone try out, but there are too many design flaws that would take time to fix that i’d rather work on something else.

A new game of course!

[themakingofagame]

I haven’t uploaded in forever, but i know there is (at least) one guy watching... this one’s for you @thefartingknight

[themakingofagame]

6*6*6 cubes bouncing around

This is rendered at 5 fps and replayed in 60 fps, because screen recording takes a lot of time.

[themakingofagame]

Previously, the collision detection would check every pair of objects. This would result in the number of objects squared checks. By this new change, the moving objects only check eachother if they are really close. checks with not-moving objects (the wall) are much cheaper, and even for that there is an optimisation possible. When a cube is marked by an rectangle, then it is close to - some - other cube.

[themakingofagame]

Who knows a good name for the game? Take a look at the first post of this blog for where the game is about.

I was thinking of something like “GLITCH”

[themakingofagame]

Testflight #0320

HUD: acceptable CONTROL: satisfactory AI: missing

note that the FPS is terrible (30 fps) because of the bad screen recording software used. That is also going to be a feature: recording replays

[themakingofagame]

Particles!

This is kind-of how an explosion in my game will look like. Currently, the calculations of these particles are done on the CPU, and i already have plans on moving it to the GPU; this will allow a lot more particles at once.

Next milestone: the projectile (this time for real)

[themakingofagame]

Colliding cubes: now with rotation!

here you go, 30 seconds of bouncing cubes.

The rotations resulting from bounces are reduced by 50%, or otherwise they would spin like crazy (which is quite common for complete elastic collisions). 

[themakingofagame]

Colliding cubes: a tad more advanced notice that the cubes do not rotate yet, i am still struggeling with dynamics.

Someone who can help me with the inertia tensor of a cube? that would be amazing, even if you’d just be answering a few questions

[themakingofagame]

trying to add rotation... The battle continues

[themakingofagame]

Collision works (almost) I think that one object does not influence another upon collision (only one of the two bounces off, the other goes unhindered) so i’ll try to get that done.

[themakingofagame]

Git reset --hard

well today was a fun day

Entire afternoon was spent on trying to make the (rather bad) structure of the vectors a bit better. 4 hours later, almost done, I found out it couldn’t work, missed its purpose and didnt increase anything of the structure. Reverted all of it.

Eventually I did make an optimisation that reduced trash generation to 50% so that is nice.

[themakingofagame]

Organizing Stuff

Mostly for myself, but also for *you* to follow progress a bit more actively, I decided to set up a trello board to track progress and to-do’s! https://trello.com/b/9JO5homl It is already quite stuffed now, but ultimately every detail will end up on the board

[themakingofagame]

Memory-leak

I just realized a rather interesting memoryleak in my program.

Input (keyboard, mouse) is centralized by a KeyTracker and a MouseTracker, both of which exists only one. The input are wired into these Trackers as soon as the window is created.

When a certain object (a listener) wants to receive direct input, It registers itself at the Tracker. Whenever there is input, the Tracker will tell its listeners. 

The camera is able to switch between two stances, and this switching is done by calling the camera-object that implements the desired stance. One camera-object is for instance controlled by the mouse (and there is where the problem starts).

In Java, destroying an object is done by forgetting about it, you basically replace it and the garbage collector will eventually clean it up. However, the Tracker will always keep a reference to each of its listeners, and thus the camera is never forgotten/cleaned. Result: switching the camera often will pile up obsolete camera’s in memory.

A solution would be to let registering and unregistering be dealt with by the caller of the cameras (and all other listeners) -> this adds complexity. Other option is using a “weak reference” in the Tracker, but i doubt that is good practice.

Other option, the one I aim at, is making a Listener manager, that restricts the usage of every listener, such that a memory leak is no longer possible.

[themakingofagame]

fixed a problem with normalvectors, now the lighting actually works.

Next i’ll be working on Projectiles (like bullets and rockets) so that’ll be lees visual stuff.

[themakingofagame]

much better.

Still not perfect, but this already gives a good impression how the flat shading will work out!

[themakingofagame]

Currently experiencing issues with the shader, but at least the rendering completes without fatal errors  ¯\_(ツ)_/¯