The testing process took a lot of time to go over all relevant aspects of the project with a fine-tooth comb and to attempt to ensure that all errors can be catered for. My testing was carried out in two ways :
• Whitebox testing
• Blackbox testing

- Whitebox testing
This was performed entirely by myself, The way i undertook the testing was to ensure that all aspects of my project worked. This does not mean searching for bugs, but rather the opposite, and just ensuring that the program did what it was supposed to do. This means :
• Generating an accurate terrain
• Making sure terrain textures looked correct
• Ensuring water movement gave off a realistic effect
• Comparing the current weather over SW Ireland with that in the program
• Testing the flight simulation, and pondering whether or not any sort of realism was achieved.

- Blackbox testing
With the blackbox testing, I was able to create 2 events. The first one involved myself searching through the program and trying to find errors (for example : poor collision detection, or clipping plane errors). As I coded the project, I am most likely to know where errors could possibly reside. The second type of testing involved 3 subjects; my brother, my sister and my cousin. I asked them to play the game, and give me feedback based on :
• Their perception of the project
• Learning outcome of it
• Overall enjoyment
• Amount of errors/inconsistencies they spotted

The results were as follows :
Sarah| Adam| Sean
Perception 6 7 4
Learning 2 3 4
Enjoyment 4 1 1
Errors* 5 7 7
Table 6.1 – Grading
*Scores are inversely proportional; 1 is a high amount of errors, 10 is low

As visible from above, my subjects have a low understanding of the work that goes into creating a game such as this. I think they were expecting a game more along the lines of Microsoft Flight Simulator, Or Call of Duty. So overall they weren’t hugely impressed and seemed to get bored of the game after a matter of minutes, but I’m happy enough with the grading as this is a one man project.

Over the course of the last 2 weeks I’ve made a great change to my project – Multi textured terrain. This makes the terrain look far more realistic and I’m very happy with the outcome.

So what has been changed?

- 4 elements of terrain surfacing : sand, grass, rock and snow

- Ripple effect water from the effects API

- Sky dome added

- Light Source from effects API

- Spritebatch problems – needs to be fixed

- Reflection & Refraction of water

Info found here : http://wright.nasa.gov/airplane/lifteq.html

Might even be overkill, I will look further into it though and see what I need and what I can ignore

I’ve began using SVN to keep source control over my project :

Ok, So at this stage, after a good bit of work over Christmas, I have the terrain rendering, a moveable camera, and now i have implemented weather as text. What this means is that when the program is in the current weather will be displayed on the screen as a text string. The next step is to properly analyze the strings so the program understands what type of weather we can see.

This will mostly involve interpreting text which is just going to be done by searching for regular expressions in the text file which contains the weather data that gets retrieved from an online source

Seeing as this project is a game, i figured it needed a Heads Up Display. So I made one. This can be further edited to suit the flight simulator. I also made a few tweaks with the camera, as you can see in the video. ALSO – I have it working now so that the user controls the game with the Xbox360 Controller, where vibrational Feedback is given.

Continuing from my previous post, The camera is an essential element of my terrain rendering. It is important to ensure that it is dynamically defined each frame, to give the user the ability to freely rotate and move around the screen. Research into this topic has shown me that there are 3 essential matrices needed to perform this :

• World Matrix
• View Matrix
• Projection Matrix

The World Matrix transforms 3D elements of the model into “world space”. This needs to be calculated prior to the rendering of each element of our 3D world,

The View Matrix transforms from “world space” into “view space”. This is how the user can see the 3D world on what is essentially a 2-Dimensional screen. This needs to be calculated every time the camera moves.

The Projection Matrix transforms the “view space” into “screen space”. This is calculated at the start of the program. This is like saying, draw everything within the cameras viewport. It can be viewed here

It is important to note that the coordinate system being used is known as left-handed cartesian coordinates

I will write 3 new posts after this going into further detail about each matrix we use

The implementation of a quad tree algorithm was a concept i looked at while researching my project. Although i will not be implementing it, I find the ideas behind it very interesting. I feel it’s good to try and get a grasp of all different aspects of terrain rendering. Anyway, this is a good read up on the concept of Quad Trees. Moving onto business though. After playing around with the code I have begun to get the camera functioning as desired. There are a few problems with getting the matrices working, so they will have to be worked on. In most of Bryan’s labs, he used cameras in the games worlds, and they all employ a the same concept. The below code is based on Bryan’s work :

Normalize Look Vector
Cross product look and right vector to change the up vector
Normalize the up vector
Cross product up and look to change the right vector
Normalize the right vector

float x = Dot product right vector with position
float y = Dot product up vector with position
float z = Dot product look vector with position

(_viewMatrix)(0,0) = _right.x;
(_viewMatrix)(0, 1) = _up.x;
(_viewMatrix)(0, 2) = _look.x;
(_viewMatrix)(0, 3) = 0.0f;
(_viewMatrix)(1,0) = _right.y;
(_viewMatrix)(1, 1) = _up.y;
(_viewMatrix)(1, 2) = _look.y;
(_viewMatrix)(1, 3) = 0.0f;
(_viewMatrix)(2,0) = _right.z;
(_viewMatrix)(2, 1) = _up.z;
(_viewMatrix)(2, 2) = _look.z;
(_viewMatrix)(2, 3) = 0.0f;
(_viewMatrix)(3,0) = x;
(_viewMatrix)(3, 1) = y;
(_viewMatrix)(3, 2) = z;
(_viewMatrix)(3, 3) = 1.0f;

I handed up my interim report on friday. I was happy with the content of it so from here on I’ll be doing some *real* work! The christmas I’ll be very busy with college work, but I’ll have to be sure to delegate time between FYP and exams. I currently have 3 projects to be completed by Friday so I will be concentrating on them this week. Then back to working on RTITR!