Forem: Graham Long

Gamedevlog: Tilemap Part 3d

Graham Long — Sun, 01 Nov 2020 17:04:26 +0000

Generating a test map

The first thing I did for this development was to generate a test map, I created 4 new simple tiles in blender:

One with a straight path running through it
One with a T Junction path
One which had a crossroads
One which had a 90° Corner path

I then mocked up a simple map in Paint, see below:

And then updated the existing .VTF files and created the necessary new ones to bring this level to life in my game.

It immediately became apparent that to do this I would need to be able to rotate the base tile model, so I added a new line to the .vtf files, the new line used BR (Base Rotation) tags and had the possible values:

None - No rotation
Left - 90° Rotation Left
Right - 90° Rotation Right
Flip - 180° Rotation

I then needed to pass this to the Tile class and parse it to apply the correct rotation to the model.

Once this was done, The test map was recreated as expected in the game and I could walk around from one end to the next and back again.

Dealing with Diagonal movement between tiles

This was an outstanding issue from the Last development and was only a slight change compared to the already implemented single direction movements.
I started by calculating where the players trajectory would intersect both of the edges that the player crosses.

Then I calculated the distance from the start position to each of the intersection points.

Whichever point is the closest is the point that the player leaves the current tile, special consideration must be given to when the player leaves the tile at one of the corners i.e. when the intersection distance is equal for both edges, knowing this we can set the intersection point and adjust the tile accordingly.

The Calculations for each of the 3 possibilities is nearly identical so I shall just show one:

The intersection point is selected based on which point is closest and the next tile and offset are then set based on which way the tile map is shifting.

Finally, the currentTile is adjusted the same way as in the previous development.

Adding to the map

After a short period playing the demo map I soon grew tired of the look of the paths, and set all the tiles to have the grass base model.

I then decided to add the ability to add models to each of the tiles, to do this I needed to specify the following in the .vtf files:

The object to place on the map.
The position of the object relative to the tile.
The rotation of the object (only Y axis rotation for now).

The easiest way to implement this for now was on a single line, starting with a GO (Game Object) tag, followed by the x offset, y offset, z offset, rotation and a final closing GO tag.

I created two models to test this out, a new rock model and a tree model which I extracted from the previous tree base model.

Next I updated the VrTileFormatParser class to parse the Game Object definitions and pass them onto the generated tile class as an ArrayList called gameObjects.

Parsing the GO tags was slightly more involved than the other tags as there are multiple information points on the single line, but this is no more complicated than parsing the obj files.

Finally I needed to process the game object data in the Tile class, in the initialise method I added a loop to go through all the Triples passed into the class and create/modify objects based on their values.

Conclusions

This seems to work pretty well, I have one tile with a few trees and rocks dotted across it and it looks pretty cool so far, it does remain to be seen if there are any performance issues with this but that can be looked at in future.

One final thing, As this platform (dev.to) doesn't seem to have any other game development logs on it, I am going to move this one to somewhere more appropriate, when I decide where this will be I shall update this post with details.

Gamedevlog: TileMap Part 3c

Graham Long — Sun, 25 Oct 2020 20:29:54 +0000

Determining where the player leaves the tile

To continue where I left off last time I found the following formula on wikipedia, which can be used to determine where two lines cross, I used this to determine where the players trajectory and the edge of the tile cross and therefore the point that the player leaves the tile.

As I plan on using this in multiple places I created a function which takes the start and end points of two lines and returns the position that the two lines intersect.

Some future improvements (TODOs)

I know some people do not like putting TODOs in comments but for me it is a great way of keeping in the flow of coding without forgetting some of the smaller things which I can see will need tidying up or fixing.

As can be seen in the comments above, this function does not check if the lines are parallel, there would be a division by zero if they were, which would crash the application, but as the function is only called to get the intersection point after checking that the two lines intersect, I shall add a TODO in the comments to remind me that there should be a check in for 0.0 value divisor.

Also in the comments I have put a TODO to remind me that for this function it would make more sense to create a 2D version of Position3Float and use that instead of Position3Float.

Calculating where the player ends up on the tile map

This is where things got complicated, so far I have only catered for the player moving up, down, left or right and not diagonally in any direction.

The general flow of processing the player movement goes like this:

Setup

Hopefully the comments explain what each variable here is for, some additional things to note are:

distanceTravelled must be set to anything except 0.0f otherwise the next loop will never be entered.
endPosition is used to make up the returned position, setting it to the start position means if anything goes wrong the player will not move at all.

Checking if the player is still moving and has distance left to travel

This loop repeats while the player can still move and is still moving.

Calculating where the player would like to move to

This takes the remaining distance and applies the fluidity of the current tile to work out how far the player will travel along this tile, it then multiplies the distance by the normalised direction vector and adds it to the start position to calculate where the player would end up.

Does this take the player to a new tile?

This code is similar to the existing code for checking for tile changes.

Finalise where the player moves to on this tile

This is performed in a big when statement to allow each direction to be separate, at the minute, because I have not coded the diagonal transitions yet, the process is similar for each direction:

Calculate where the players trajectory intersects the edge of the tile.
Calculate the index of the tile the player is moving to.
If the tile the player is moving to has a non 0.0 fluidity value then the endPosition will be where the player intersects the tile edge - the tile size to wrap around to the opposite side of the tile like we did in the previous code. The currentTile is also updated as the player has now transitioned to this new tile.
Otherwise the endPosition will be where the player intersects the tile edge.

This does give a slight overlap between one tile and the next, e.g. any point at the edge of one tile is also technically on the edge of another tile as well.
Whether this is of any consequence remains to be seen.

Update the distances traveled and remaining

One thing that may be confusing is how endPoint and intersectionPoint differ, if the player is on the same tile then they both have the same value, when the player enters a new tile the endPoint is where the player entered the new tile and the intersectionPoint is where they left the old tile.

Updating the `TileMap` after applying the player movement

If the tile which the player is on has changed, the center tile is updated to be the new tile and all other tiles are reset based on this new center tile.
Then all the tile offsets are reset as before.

Conclusions

This update took me a while to get motivated to start but once I did it came together quite nicely.
I should now be able to create a complete level which the player can move around consistently.

The code at this point of the project can be found here.

Stay Safe and Happy Coding.
Until next time,
Graham

Gamedevlog: TilMap Part 3b

Graham Long — Sun, 18 Oct 2020 12:09:31 +0000

Building on Part 3a

This main purpose of this update is to expand upon the previous work to generate a level by adding the following features:

Create an empty tile which indicates the edge of a scene.
Prevent the player from entering the empty tiles.

The Empty Tile

For this I generated a simple tile model in blender and exported it as obj and mtl files:

Then created an empty tile file which can be reference by all tiles at the edge of the scene.

VTF File changes

The eagle eyed among you may have notice the new TF line in the vtf file.
I added this to set the fluidity of a tile i.e. how easily the player can move through the tile, this value will be multiplied by the distance the player wishes to move to determine how far they actually move.
Most tiles will have a value of 1.0 for this, but tiles which the player can't enter will have a value of 0.0 to prevent any movement within the tile, going forward this will also allow tiles which slow the player down e.g. quicksand or mud or even tiles which speed up the players movement.

Other changes

So far, as part of the process of using the fluidity value I have decided to revert back to using my Vector3Float classes along with a new Position3Float class rather than using Triples whenever this makes for more readable code, e.g. if the 3 values are simply related then I will leave them as a Triple but if the 3 values represent either a 3D Vector or position in 3D space, I think it makes the code more readable to use the custom classes, it also allows me to add operator overloads to make subtracting one position from another possible among other things.

The Plan for development

From here I need to brush up on my math skills to determine where the player should move in the TileMap based on the fluidity values.

Then I shall generate a simple level which I can use for testing, and develop more of a sense of where the gameplay is heading, my current thinking is a VR world building game where you can place trees, plants, fences etc to build up your own environment, to do this I foresee the following advancements in the design:

A HUD style menu, to select the objects which the player can place into the world.
Enabling transparency so the player can see where the object would be before they place it.
Updating the .vtf files when changes to the tile are made.
Some sort of collision detection so objects are not placed on top of each other and so the player can't walk through the objects they have placed.

Until next time, Stay safe and happy coding.
Graham

Bubble Sort

Graham Long — Sun, 11 Oct 2020 12:59:47 +0000

What is bubble sort?

This sorting algorithm is one of the simplest to understand, and is generally the first sorting algorithm taught to beginners.
It is rarely used in the real world though, as it is outperformed by almost every other sorting algorithm.
The basic idea of the algorithm is that, given an array of values, the larger (or smaller depending on the direction we are sorting the array) values are bubbled to their correct positions in the array by iterating through the values and swapping ones that are not in the correct order.

The algorithm step-by-step

Given an array of values 2, 4, 8, 3, 7, to sort in ascending order, we need to loop through the values comparing each one to the next and if the next value is lower than this one, we swap the two values in place.
This looks something like:
At index 0

original values = 2, 4, 8, 3, 7
This value = 2
Next value = 4
Next value is greater than this so do not swap
new values = 2, 4, 8, 3, 7

At index 1

original values = 2, 4, 8, 3, 7
This value = 4
Next value = 8
Next value is greater than this so do not swap
new values = 2, 4, 8, 3, 7

At index 2

original values = 2, 4, 8, 3, 7
This value = 8
Next value = 3
Next value is less than this so swap them
new values = 2, 4, 3, 8, 7

At index 3

original values = 2, 4, 3, 8, 7
This value = 8
Next value = 7
Next value is less than this so swap them
new values = 2, 4, 3, 7, 8

After one iteration through the array, the values are still not sorted, so we need to repeat this process again.
At index 0

original values = 2, 4, 3, 7, 8
This value = 2
Next value = 4
Next value is greater than this so do not swap them
new values = 2, 4, 3, 7, 8

At index 1

original values = 2, 4, 3, 7, 8
This value = 4
Next value = 3
Next value is less than this so swap them
new values = 2, 3, 4, 7, 8

At index 2

original values = 2, 3, 4, 7, 8
This value = 4
Next value = 7
Next value is greater than this so do not swap them
new values = 2, 3, 4, 7, 8

At index 3

original values = 2, 3, 4, 7, 8
This value = 7
Next value = 8
Next value is greater than this so do not swap them
new values = 2, 3, 4, 7, 8

At this point we can visually see that the array is sorted but our algorithm does not yet know that we have finished, we need to keep iterating through the array until no swaps are performed.

Performance of bubble sort

Hopefully at this point you can see why this algorithm is so inefficient, especially for larger arrays.

Time

The best case scenario is an array that is already sorted, even then we still need to iterate through it once to confirm it is sorted, this is why the best case big O notation for this algorithm is O(n), as all n values need to be checked.

For this small array we had to iterate through it 3 times, but for the worst case, a reverse sorted array we need to iterate through it n times, where n is the size of the array e.g. sorting the values 10, 8, 6, 4, 2 would take 5 iterations, this gives a worst case big O notation for this algorithm as O(n²), as all n values need to be checked n times.

Space

Because the values can be swapped in the existing array, bubble sort can be performed without allocating any extra memory (as far as big O is concerned) therefore the space complexity is O(1)

Stability

The stability of a sorting algorithm is whether the order that identical values were placed into the unsorted array is preserved after the sort e.g. if the input values are 3, 1, 1 then, if the sorting algorithm is stable, 1 will be before 1 in the sorted array, with an unstable sorting algorithm, 1 and 1 could end up in any order.

Bubble sort is considered a stable sort, as any two identical values will not be swapped.

Example Implementation

Below is an example implementation of this algorithm in python:

Running this produces the following output:

Summary

Despite this algorithm being used very rarely in the wild, I don't think I could have started a sorting algorithms series without including it.
If nothing else the bubble sort algorithm can be used as a benchmark to compare other algorithms against.

Stay safe & Keep learning
Graham

C coding quality tips

Graham Long — Sun, 04 Oct 2020 19:16:02 +0000

Introduction

In this post I shall be outlining some of the things that I personally apply to my C coding and the reasons why I apply them.
One caveat to this, which I feel is very important, when working in an established code base your code should follow the style of that code, consistency leads to easier to understand code than a mish-mash of styles.
So jumping straight in with....

Types

One thing which I do on every greenfield project is create a header file which defines custom types equivalent to the built in types but with the size as part of their name e.g.

I do this because not all processors use the same size for all built in types, if the code needs to be ported to a processor with different sized types, then it is only this header file that needs updating and all other modules should work as before.
This also makes it clearer what value range a variable has when you declare it which can make it easier to catch bugs related to integer values overflowing during a code review.

Prefixing

One thing which I’ve not done before is prefix these custom types with a lowercase t, I have seen this, or similar annotations done and think it is a nice touch which I’ll probably adopt going forward.

Enums

I am a huge fan of Enums, any time when a variable has a finite number of values then I would use an Enum, it allows you to restrict the range of values passed as a function parameter and the values returned from a function.
It also in my opinion makes code easier to read as values can be named to something meaningful e.g. rather than 0 for OK and any other value for an error, status codes returned from a function can be:

Prefixing

Again this is something that I haven’t done but think would be a good addition is to prefix enums with a lowercase e to indicate that the value is an enum.

Enum values

As a general rule when using an enum I do not care what value each enumeration is, but when the value of an enumeration is used, it should always be defined, even if the values are 0, 1, 2 etc, most compilers set the values from 0 but this can’t necessarily be guaranteed, therefore I like to declare the values of enums when the value will be used in the software.
e.g. If the status codes above were checked against the value 0 in the code then I would instead define the value of each enumeration like this:

Loops

These are minor things which I do regarding loops.
First, when incrementing a for loop index I use pre increment rather than post increment as this I have heard is minimally faster on most processors, the one exception I applied to this was when I worked with an msp430 processor, the compiler recommended I decremented the index as zero was easier to detect than non zero.

Secondly, when creating a super loop, instead of using while(1) I will use while(true), where true is non zero or for(;;), the reason for this is something i read which said while(1) could be confused with while(l), even as unlikely as this is I still prefer while(true).

Const

Whenever the value of a variable won’t change after it has been declared, I use the Const keyword to enforce its constant value, this has another positive in that it gives the compiler information that it can use to improve its optimisation of the code.

Another area where I use Const is with pointers as function parameters, it’s a great way of adding limits on changes to the data and address pointed to.
I can never remember the syntax for this so I always return to this post from geeksforgeeks.org.

Wrapping up

These points in this article are some of the things which I have picked up over my career, I’d love to hear your thoughts on these, and any other things that you apply when writing your C code.

Stay safe.
Graham

Gamedevlog: TileMap Part 3a

Graham Long — Sun, 27 Sep 2020 10:43:36 +0000

Building on Part 2

As mentioned in part 2 we need a way of converting the tile map to an actual level that the player can navigate around.

To start I added 8 Strings to the Tile class one to represent each of the adjacent tiles, when a Tile is then moved to the center, the Tiles which were not already part of the TileMap can be queried and loaded.

The Vr Tile Format .vtf file

I created a custom file format to hold the Tile data, the files consist of multiple lines, with one parameter, surrounded by opening and closing tags, on each line.
The initial tags will be:

BM: The name of the base model will be between these tags.
SU: The name of the .vtf file for the tile straight up from this one will be between these tags.
SD: The name of the .vtf file for the tile straight down from this one will be between these tags.
SL: The name of the .vtf file for the tile straight left from this one will be between these tags.
SR: The name of the .vtf file for the tile straight right from this one will be between these tags.
UL: The name of the .vtf file for the tile up and left from this one will be between these tags.
UR: The name of the .vtf file for the tile up and right from this one will be between these tags.
DL: The name of the .vtf file for the tile down and left from this one will be between these tags.
DR: The name of the .vtf file for the tile down and left from this one will be between these tags.

All the tags will be present but may be left blank if for example there is no Tile straight up from the one being defined.

To test this out I generated 9 files which will fill the tile map and will wrap around to create a continuous level e.g. the center tile, "Tile_0_0.vtf" looks like this:

Parsing the files

To parse the files I generated a VrTileFormatParser class which takes in a file name string of the file to parse along with the ModelLoader and application context.

I read all the lines of the file, populating function level variables with the parsed strings and then after reading the file, I created a new Tile Class which can be returned using a call to getParsedTile Function.

Setting up the scene.

When the TileMap class is initialised, I First load the Center tile, This is hard coded as "Tile_0_0.vtf" but in future could be whichever Tile the player was on when they saved or closed the game.

I then initialise all the other Tiles using the new strings defined for the center Tile.

Updating the scene.

When the play moves Tiles, we can now populate the new Tiles on the TileMap in the same way that we initialised the TileMap initially.

Any Tiles which were previously on the TileMap were simply moved as before, the only other small change is, when moving diagonally the corner tiles are now updated where previously they were kept the same, see the example below.

Conclusions

The game is starting to look more like a game, we are able to simulate a vast world using just 9 tiles at a time and we can link tiles to other tiles to make a consistent experience.

I have added some null and empty string checking but I know there is more to do on this front, also, I have set the adjacent tile strings in the Tile class as public values, I think I will change these to private values with getters which will allow me to check for null or empty string conditions.

The code at this point of the project can be found here.

Stay Safe.

Gamedevlog: TileMap part 2

Graham Long — Sat, 19 Sep 2020 20:37:58 +0000

Building on part 1

This will be a quick post this week, the next step on from part 1 is to move the tile that the player would have moved to, into the center and adjust all the other tiles accordingly.

To do this I modified the getPlayerPositionOnTileMap function, so that as well as adjusting the players position, I set bits in a moveDirection variable to indicate the direction to shift the TileMap, then using a when statement I shifted the tiles around based on the value of moveDirection.
Finally if moveDirection was set to anything apart from DONT_MOVE I needed to reset all the tile offsets to their new positions.

Building on this

Next, I wanted to spawn new tiles rather then just shuffling the existing ones, to do this I needed to ensure that the tiles were initialised within an OpenGL context, I couldn’t immediately see a clean way of doing this but in the end, I settled on adding a mModelsHaveNotBeenInitialised variable to the Tile class which was set to true until the initialise function is called, this allowed me to check the initialised state of the variables in the draw function (and therefore within an active openGL context) and if the models had not been initialised I called the initialise function, to make sure the offsets were correct, incase they had been set before the initialise function was called, I added calls to the setPosition function for each model to ensure it was drawn in the correct position.

Other small changes

I noticed that sometimes the new models were being drawn at the origin of the scene before being translated to their correct position, which caused a flickering effect, to fix this I simply added a call to GLES20.glFinish() in the reRenderTheScene function which waits until the rendering is complete before exiting the function.

Additionally I changed the old skybox textures to plain blue sides and a slightly modified cloud tile at the top of the scene.

Conclusion

This all seems to be going a bit too smoothly at the minute....
The next step forward is to make the tile map repeatable so the player can actually navigate consistently further than 2 tiles and back, I think this will be a big step so may be further broken into more than one blog post.

The final code at this point in the project can be found here

Stay Safe.

Gamedevlog: Tilemap part 1

Graham Long — Sun, 13 Sep 2020 12:47:19 +0000

What is a tilemap and why am I using one

A tile map is a method of creating a level from a grid of tiles, it’s a common method in 2D games and allows a small number of images (sprites) to be repeated to build up a level.

In the above image we can see that with only 3 sprites we can create a whole platformer level.

I am using a tile map to limit the size of the scene I need to render, instead of always drawing the whole scene.

Imagine the image above is a birds eye view of the scene, if the player is in the tile at 0,0 then we only need to render the surrounding tiles highlighted green, as the player moves to the next tile then the map can be updated to keep the players tile always in the center.

In future we can also use this to limit the number objects we need to perform collision detection on, but that is for another post.

The Tile Class

This class represents each tile that makes up the scene.
It holds an ArrayList of models which are static within the tile, to start, this will just be a single baseModel which is passed as a constructor parameter, but going forward will include other models like trees, houses, fences etc.

The TileMap Class

This class holds an array of 9 Tiles, the one the player is currently in and the 8 surrounding.

Putting this into action

To implement this I needed to pass the TileMap class the the VrRenderer so that the models can be initialised and rendered with an active OpenGL context, this would leak a lot of unnecessary implementation details to the VrRenderer when the only two functions it would need are an initialisation function and a draw function, to clean this up I created a DrawableInterface which only specified the two necessary functions, this was then implemented by the TileMap and Tile classes and a parameter of the DrawableInterface type was passed to the VrRenderer.

Once each tile is initialised, I needed to set the offset for that tile, to do this, and to allow me to move the tiles I created a setTileOffset function in the Tile class which removed the current offset (originally 0) and then applied the new offset to all models in the tile.

To try this out I created 9, alternating black and white tiles, with the numbers 1 to 9, added them to the model loader class and set each one as the baseModel for the 9 tiles.

The finishing touches

To finish this step of the development I wanted to see how it would look to move from the center tile and have the tiles adjust themselves.

To simulate this i added a function to the TileMap class to take in the players current position and target movement delta and return the new player position.

If applying the target delta would take the player outside the center tile i.e. more than half the tile size from the origin, then I subtracted or added the tile size to take the player to the opposite side of the tile.

This function is Called from the adjustPlayer function, I created a new interface to allow me to just pass in this function.

and it is then called from the body of the function like:

Running the game, this method looks a bit strange as the tiles are not updated at the same time as moving the player out of a tile but I think the principal seems to work.

Conclusion

This development is another step closer to a playable game and every step forward is a win, the next step will be to shuffle the tiles around when the player transitions from one to the next to give the illusion of continuous movement across a scene.

The code at this point of the project can be found here.

Gamedevlog: The First VR Test

Graham Long — Mon, 07 Sep 2020 10:51:16 +0000

Preparations for the first VR test.

To prepare for the first VR test I wanted to add the following features which I thought may be needed:

The ability to change the distance between the two camera positions using the xbox controller.
The ability to switch the point that each camera was looking between a common point or independent points directly in front of each camera.

Setting the distance between each camera

To achieve this I added a variable to the PlayerVision class to store the distance that each camera should be from the center mHalfCameraDistance, this was then used instead of the hard coded 1 and -1 values when calculating each camera’s position.
To modify this distance, I created two functions, one to increase the distance and one to decrease it by the passed in amounts.

Setting the cameras look at position

To achieve this I added a boolean variable to the PlayerVision class called mLookStraightAhead, if this was set to true then the cameras would look directly ahead of themselves, however if the value was false, then the cameras would share a common look at point.

This was done by calculating a common look at point which was in the look direction from the players position.

The look direction for each camera was calculated as the look position minus the cameras position.

Controlling these settings from the Xbox controller

To facilitate controlling these settings from the Xbox controller I updated the ButtonControlInterface and the XboxController and GameControlHub classes to allow detection and reporting of activity on the LB (L1) and RB (R1) buttons.
Then in the main game loop I checked for:

The action button pressed which would toggle between the two camera look at modes.
The L1 button pressed which would decrease the distance between the two cameras.
The R1 button pressed which would increase the distance between the two cameras.

The first test

With these changes implemented I placed the phone into the headset and pressed the L1 button to decrease the distance between the two cameras, this had the effect of increasing the distance???
It turns out that when calculating my look direction I had been using a positive z value instead of a negative z value as all my calculations in this test had assumed.
Fixing this issue by inverting the look direction, then highlighted the fact that all my controls had been set to work with this incorrect look direction, testing the values returned from the Xbox controller stick movements showed that these values were inverted (except the one used for Yaw) from what I had assumed, this was fixed by inverting the stick values in the XboxController class.

The first real test

With the above issues resolved, I once again placed the phone into the headset and my first impressions were good, while looking at objects close to the camera there was a kind of ghosting where you could see the difference between the two camera positions, decreasing the distance between the two cameras had the desired effect and at distances below about 1.0 (0.5 half distance) the image looked great.
One interesting thing I did notice was that when changing the camera at the lower distances, I could see the 3D models move and then my brain would compensate and they would merge back to a single model again, I am assuming that this compensation is not possible at the larger distances between the two cameras, so as not to stress the eyes / brain too much I have decided to work with the half distance set to 0.1 for now.

I did not notice any major difference when the two cameras were looking at a common or independent points but this may be something I notice as the scene grows.

Conclusions

All things considered, this update was quite productive, I got the chance to brush up on my blender skills, fixed some issues with the game and had a successful VR test.

The code at this point in the project can be found here.

Gamedevlog: Simulating day and night

Graham Long — Sun, 30 Aug 2020 20:10:05 +0000

All in a days work

To add some movement to the scene and make it more dynamic, I have decided to add a day/night cycle which will include.

A 3D model for the sun which will move across the scene.
The colour of the sun will change from white at midday, to a reddish orange at dawn and dusk and black at night.

The light source

To introduce a light source I created a new SunLight class which will:

Implement a simple form of the model rendering code to render the sun model.
Calculate the lights position and colour based on the time of day.

Calculating the suns position

To work out where the sun should be at any given game time, I will take the result of the mod of the current system time in milliseconds the total time per day and then divide it by the total time per day to know how far into the day we are, then multiply that by 360° to get the current angle.
At the start of the day (0 time) the sun shall be directly below the world so if we set a position directly down on the y axis and then rotate it by the current angle, this will be the position of the sun.

Calculating the suns colour

Again we can make use of the angle generated for the suns position to cycle the colour between black at the start of the day, reddish orange at dawn and dusk and white at mid day.

I was unsure how best to convert the angle into a colour but I started by setting the colour based on the angle using a when statement with ranges for each of the colours.

This was a good start but the transitions needed to be smoothed out and the skybox still looks the same throughout the day.

To fix these issues I created a simple interpolation function to gradually merge from one colour to the next, this function only works as expected because at most I am changing two of the 3 colour values each time.

This was used in the when block like this:

One final issue with this was that the sun always rotated around the scenes origin and not the player position, therefore the player could walk into the path of the sun, to fix this I passed the players position to the UpdateSunLight function and translated the sun position by the players position.

This gave the following Day/Night cycle which I am quite happy with at the moment.

Conclusions

The game now has some dynamic lighting in the form of a day / night cycle which is a great improvement on the previous static lighting.

The source code at this point in the project can be found here.

Simple object (.obj) and material (.mtl) file parser.

Graham Long — Sun, 23 Aug 2020 11:40:33 +0000

Why object files and material files together.

Object files and material files are both wavefront technology formats which are designed to work in combination.
I have described the basics of object files as a standalone file in part 8 of this series.
When combined with material files the object file contains a line detailing the name of the material file which starts with “mtllib”

and the faces are grouped by material, with each group starting with “usemtl” and the name of the material to use.

Modifications to the existing object file parser.

The first change will be to update the faceMap to include a material name as well as the vertex, UV and normal indices.

Next, we need something to hold all the material data, for this, I generated a data class MaterialData.

I then generated a function parseMtlFile which takes in a BufferedReader and parses the file to populate a hash map with the material names as the keys and a MaterialData classes as the value.

When the object file specifies a material file to use, I take the file name and generate an InputStream which I use to create a BufferedReader and pass it to the parseMtlFile function.

Taking a step back to detail the .mtl file format, each Material file can detail multiple materials, each material definition starts with a line with the word "newmtl" and the material name.

When we see a "newmtl" line we can generate a new MaterialData class and add it to the mMaterials hash map, I also store the material name so I can use it to populate the classes variables later.

Following the "newmtl" line there are the following lines which are of interest to us.

Ns - This value defines the Specular exponent of the material.
Ka - This value defines the Ambient colour of the material.
Kd - This value defines the diffuse colour of the material.
Ks - This value defines the specular colour of the material.
d - This value defined the dissolve (transparency) of the material.

Parsing each of these lines, we can populate the MaterialData variables similar to this:

Parsing the faces with this new material data

Now that we have the material data we continue parsing the object file as before until we get to the faces.
Before each section of faces there is a "usemtl" line which we parse to determine which material name to use for the following faces.

When I parse a face, I take this materialName and use it to get the material from the mMaterials hash map.

The remainder of the face parsing is the same as before except that for each new index, I also populate new FloatArrays for:

mFinalAmbientColour
mFinalDiffuseColour
mFinalSpecularColour
mFinalSpecularExponent
mFinalDissolve

If the material is not in the mMaterials hash map for any reason then default values are used to populate the arrays.

The new `ModelData`

To use all this new data I modified the ModelData class to be a Kotlin data class and include the new colour information.

Using the new data

Once we have the data, we need to update our shader code to use the values, this was pretty straight forward but did involve adding an attribute for each new value

and then passing it to the Fragment shader to be used in the lighting calculations

I also added a uniform variable to the fragment shader to pass the light colour in rather than having it hard coded.
Finally, For each new attribute I generated a FloatBuffer which is populated with the new material data in the same way as the Vertices and normal data was populated and then passed to the shaders in the draw function in the same way as the vertices and normals.

Conclusions

I now have different coloured models in my game which looks better than the monocolour models that I had before.

The final code for this update can be found here.
Until next time....

Loading multiple models

Graham Long — Sun, 16 Aug 2020 15:16:09 +0000

The Current Way

Prior to this development, if I wanted to load multiple different models I had to load each one in the VrRenderers onSurfaceCreated method and then pass the vertices, normals and indices to a GenericGameObject, there is nothing majorly wrong with this but I wanted to make the process a bit easier.

The New Way

model data

First I created a dto class (data transfer object) called ModelData which is used to pass the vertices, normals, UVs and indices for a 3D model between other classes. I changed the ObjectFileParser to return the parser data as a ModelData object and similarly I changed the GenericGameObject to take in a ModelData object.

Loading all the models

To load the model data I created a ModelLoader class which parses all the available models object files in its init function and puts the resulting ModelData objects into a HashMap with the file name as the key.
The ModelLoader class can then be used to get the ModelData object for any already parsed model.
In the event that a requested model is not in the HashMap then a default cube is returned.

Using the `ModelLoader`

I create an instance of the ModelLoader class in the MainActivitys onCreate method and pass it via the VrGlSurgaceView to the VrRenderer so I can generate GenericGameObjects with any of the parsed model data.
In anticipation of adding a tile based system into the game in future, I created a few basic 20x20 tiles which I added to the ModelLoader to be used in the game.

Conclusions

This development is a stepping stone to implementing a tile map style world and as such is only a small change from the previous version.
Now that I have a basic environment in the game, I have the following observations:

The SKyBox texture does not make sense with the scene now being all above 0.0 on the y axis.
Each "tile"s are one single colour each which is not ideal.
Similarly the floor is as reflective as the other parts of the models, again this is not what I want.
The specular lighting on the models is in a very different place from one eyes camera to the other, this indicates to me that the distance between each camera is too great, but I shall need to trial this in my VR headset to confirm.
A small observation is that the light is currently coming from directly above the player at the moment and it would be nice to have this orbiting the scene and maybe changing colour at "Dusk" and "Dawn".

Until next time, the source code at this point in the project can be found here.

Forem: Graham Long

Gamedevlog: Tilemap Part 3d

Generating a test map

Dealing with Diagonal movement between tiles

Adding to the map

Conclusions

Gamedevlog: TileMap Part 3c

Determining where the player leaves the tile

Some future improvements (TODOs)

Calculating where the player ends up on the tile map

Setup

Checking if the player is still moving and has distance left to travel

Calculating where the player would like to move to

Does this take the player to a new tile?

Finalise where the player moves to on this tile

Update the distances traveled and remaining

Updating the TileMap after applying the player movement

Conclusions

Gamedevlog: TilMap Part 3b

Building on Part 3a

The Empty Tile

VTF File changes

Other changes

The Plan for development

Bubble Sort

What is bubble sort?

The algorithm step-by-step

Performance of bubble sort

Time

Space

Stability

Example Implementation

Summary

C coding quality tips

Introduction

Types

Prefixing

Enums

Prefixing

Enum values

Loops

Const

Wrapping up

Gamedevlog: TileMap Part 3a

Building on Part 2

The Vr Tile Format .vtf file

Parsing the files

Setting up the scene.

Updating the scene.

Conclusions

Gamedevlog: TileMap part 2

Building on part 1

Building on this

Other small changes

Conclusion

Gamedevlog: Tilemap part 1

What is a tilemap and why am I using one

The Tile Class

The TileMap Class

Putting this into action

The finishing touches

Conclusion

Gamedevlog: The First VR Test

Preparations for the first VR test.

Setting the distance between each camera

Setting the cameras look at position

Controlling these settings from the Xbox controller

The first test

The first real test

Conclusions

Gamedevlog: Simulating day and night

All in a days work

The light source

Calculating the suns position

Calculating the suns colour

Conclusions

Simple object (.obj) and material (.mtl) file parser.

Why object files and material files together.

Modifications to the existing object file parser.

Parsing the faces with this new material data

Updating the `TileMap` after applying the player movement

The new `ModelData`

Using the `ModelLoader`