Finishing Touches

Pete and I found a problem with Missile Defense last week at university, whilst we were trying to get the game up to scratch for some beta testing we discovered that it was freezing at the end of the game, and either of could not figure out why. I have been busy with some other things lately so I hadn't had the time to sit down and look into it closely. But tonight I spotted the problem, it was almost a fluke and if I hadn't done what I did I doubt we would of spotted it before our presentation on Wednesday. What was happening was when all of the players cities had died, the code was attempting to send more tanks off to kill the cities, but the code was getting caught up in an infinite loop looking for an available city. To resolve this I changed around the code so that if all the cities are dead it would break out of the loop and continue on, this resolved one of the major issues we have been facing the past week. Horray.

I created a set of player head textures, they are designed for the Player Manager and allows players to see the progress of their competitors and to see who's still alive and who is sending you the events. Below are the head textures.


After doing some play testing with Pete, we've found that we are at the stage were the game is almost complete and were simply making superficial changes and tweaks to polish the game up. Pete's also done a make-over on the GUI, below is a picture of the java based GUI with a custom look and feel.


So, tomorrow Pete and I will be doing some more play testing and tweaking the game a little more to try and balance the play, and also start to put together our presentation for Wednesday.

Thats it for now.

Getting Close!

Missile Defense

Today after uni Pete and have been working our butts off in the hope that we can get the game ready for the scheduled Beta Test tomorrow. Pete has been working on the concept of Power ups, a Power up in our engine doesn't alter the game in any way it is designed to send events off to other players to increase their load. The reasons behind implementing Power ups was to give the player some incentive to move around whilst playing Asteroids, during our testing sessions the both of us found that most players would stay in the middle of the screen rotating around and not moving. By introducing Power ups we hope to break this pattern of behavior and reward risk.

I started putting together some new textures for Missile Command, but rather than following the same theme as Missile Command Pete and I both decided to change the game to be land based. The objective of the player is defend their bases from the onslaught of kamikaze tank drivers, hell bent on blowing up things. In that respect we opted to rename the game from Missile Command to Missile Defense, I think it suits the game much better. Below is a background texture I for Missile Defense, I drew this one myself in about 5 minutes.

Background I drew in Photoshop.

I also added the below turret texture, it is split into two parts so that we can have the turret move and rotate on the base. The texture might not look much like a missile launcher, but it was the best we could do in the time frame we were given. I coded it so the turret followed the location of the mouse, its small things like this that really make a game in my opinion.

Turret Textures.

I created a new Tank Game Object, this object is not much different from a missile, but it uses different textures. When a new tank is generated it randomly chooses a texture and tank type, to keep the game as random as possible.

Tank textures.

I created a new texture for the city object, I also make it randomly select one when the object was being created. Each city has two states, a normal state and demolished state.

City textures.

I made a helicopter animation, using a set of helicopter textures. Below is the method I used to get accurate texture coordinates so the animation flowed properly. The idea behind adding the helicopter was that when a large event occurred in Missile Defense, the helicopter would appear and begin shooting missiles at the players cities. It would be up to the player to shoot down the helicopter.

Working out the texture coordinates on a large poly.

I updated the blending mode for smoke particles, previously the smoke particles were looking very white but we want the smoke to look more gray like what the actual texture looks like. I used the glSandBox again to do some more tests to figure out the optimal blend mode. In then end I got the particles looking much better, so I can't complain.

GUI Tweaks

Its getting pretty close to the Beta test and I haven't heard a word from Pete since last Wednesday. I'm getting a little worried he's not going to show up or help me try and get the game to a beta test stage by this Wednesday. Ahhhhhhhhhhhhhhhhhhhhh.

I updated all of the asteroid textures today, I found that they had a black border around the edge of them because when they were being loaded into memory OpenGL is using a linear filter (Anti aliasing) and causing the alpha channel and edges of the asteroids to blend slightly. I think the problem could of been solved by increasing the alpha testing, but I'm not sure what other side effects that might cause, so I just did it by hand in Photoshop.


I also updated the GUI so that it started a count down timer when the host player begins the game. Earlier when we were testing the engine, we found that having the game pop up instantly would catch people off guard or they could be in the middle of typing a chat message and the game would take the focus. So to help with the problem I got the GUI to create a new thread and count down 5 seconds, whilst having the server distribute the message out to the rest of the players.

Another little detail I discovered was that it was impossible to know when or if a player had closed his window and was ready to play again. With all the testing we have done so far, I discovered that having more than one window/instance open at the same time can cause some problems with textures and different modules. On the contrary though the game can be run multiple times giving the player several game windows, its just that the engine doesn't like having two instances of the same game on the 1 client (GUI). To fix this dilemma I modified the networking code so that when a player closes the window the engine fires a trigger off to the server notifying the server that the player has closed the window. The server than makes a count of how many players have closed their window, if all the players have closed their window then the GUI will allow another game to commence, otherwise it will inform the host player that not everyone has closed their window yet. I guess its important to make the engine/game as stable as possible and take every precaution available, just in case these things do happen.



I'll leave you with this picture of the GUI, I'm not certain if I have posted it before or not, but it demonstrates the count down timer very well.

A Sound Manager

Today I added a new Sound Manager into the engine. I got a lot of the base code from a great Java Game development book (referenced below). The sound manager works by creating a pool of threads (16 in total) and when a sound is parsed to the manager it sends it off to the pool to be queued waiting for a free thread to execute the sound on. The manager also makes use of a Sound object class that allows you to store the sound information as an object making it highly reusable and eliminating the need to read the file more than once.

Whilst testing the new sound manager, I discovered that the sounds I was using all had different bitrates and sample rates, some were 22050Hz while others were 44100Hz. This was causing a problem because the manager only allows you to use only one audio format, so I downloaded a program called "EArt Audio Converter" it is designed to convert all sorts of file types (mp3, wav, etc) from one type to another. In this instance I only wanted to use it to convert my wav files into a new wav audio format and make them all the same. The version I used was only the trial version, and according to the interface it would only convert 50% of the file, but after converting a couple of files it seemed like it was doing the whole thing, maybe the files are to small to be cut short *shrug*.

Eventually I got all the sound files I wanted to test out to use 44100Hz at 16bit stereo, its pretty high quality I think, but I don't particularly care at the moment. So any of you developers out their, just remember that you have to convert all your sound wav's to this format or it wont work.

Lastly, at the beginning of the project I noticed that the original GLDisplay code used an FPSAnimator which is apart of the JOGL library. The FPSAnimator acts like a thread that executes a set of OpenGL functions which can be used to render things to the screen, their is another one just like it called Animator. Both of these objects do the same thing by making the java source code execute the OpenGL functions, but with the expection that the FPSAnimator is specifically designed to restrict the frame rate to a desired rate, the rate is not guaranteed but the FPSAnimator does try its best to limit the frame rate. The Animator is specifically designed to run at the maximum amount of frames per second, and this can be achieved by turning v-sync off (at the beginning of the project I was getting 3000 frames per second). Anyway, so at the beginning of the project I replaced the FPSAnimator with the a normal Animator because for some unknown reason it was acting strange and rather than limiting to 60 frames per second it was averaging about 40. It was only recently after doing some testing at uni that I discovered that having a faster frame rate increases the speed of gameplay and possibly makes it harder to play than we intended. So to counter this I put the FPSAnimator back in, and played around with some of the settings and worked out that by telling it to schedule at a fixed rate eliminated the early problems I had. It may have also improved the performance of the engine because the FPSAnimator attempts to avoid using all the CPU time.

Retro Wars on Linux

I got Super Retro Mega Wars working on Linux. I checked out the project using Eclipse, and got it to download all the files. It's pretty easy installing JOGL, but I did have problems actually getting it to run, I think Linux has some path problems because I couldn't get the JVM (Java Virtual Machine) to register/detect the JOGL .so (similar to dll) library files without forcing the IDE (Eclipse/Netbeans) to look in a specific directory. I believe Pete and I will both have to do some extensive testing on Linux to make sure users can easily setup and play the game, we might have to look into compiling the project with Ant and using someway of forcing the Jar file to look in a specific directory for the library files. But I'll do that when I finish university.

Below is a picture of SRMW on Ubuntu:

Week 11 starting to finish up

Winning display.

This week both Pete and I asked Matt if we could host a Beta Test during next weeks tutorial session. He was pretty enthused to have the opportunity and seemed pretty impressed that we had reached that stage. I think we still have a fair bit of coding to do, but we are definitely ready to get some real testing done, and it needs to be on a bigger scale.

We set about getting some serious coding done during our class, one the first problems and most sever was with the collision detection. We discovered that the collision detection system wasn't colliding with objects as they should. Both Pete and I attempted to rework the Collision Manager and put in as many debugging messages we could to help diagnose the problem. The problem seemed to occur after Pete had made changes to the Vector class turning it into a base class with two different types of vectors as sub classes (Cartesian and Polar). We end up spending most the day trying to fix this problem by optimizing our code and changing it around to be more modular, but none of this seemed to resolve the problem, but it did improve some performance in the game. In end after close to 5 hours of looking over the code, Pete discovered that it was actually a very small problem inside the Vector class were it wasn't comparing the location of the two objects being checked for collisions, the problem was fixed once Pete updated the code. This seems to be the problem the both of us are visiting more frequently lately, the more complex and large the code gets the hard it is to find and debug these problems no matter how big or SMALL they are.

Pete's been talking about the Combo system for about a week or two, so we stepped back and started talking about how the combo system should work. To start with we both agreed that the combo system should be the main source for triggering events to other players, so depending on how big the combo was determines the strength of the event. Based on this theory Pete set about coding it all whilst I worked on other things.

I tweaked the GUI some more, this time I brought back the Listbox on the right side to list all the available games. At the moment, it is not possible to change which game you play unless you physically change it in the source code. So I setup the Listbox with both the games we have so far, and made it switch the active game each time you select one. The engine then gathers the active game and creates a new instance of it.






I added in a couple more triggers for the engine, this time to deal with when the player dies or wins the game. First of all I created a new texture in Photoshop that can be used for more than just 1 thing, by moving around the texture coordinates I can use the one texture to get all three words off it. I decided to update the "loading" texture as well because I have been using one specific font for everything else in the game, so I thought it would be fitting to use it here too to maintain the look and feel.

After doing some testing with Pete I found the winning triggers were not working accurately, the engine wasn't reporting the correct winner, in some cases reporting all players to be losers. I'm not sure of the problem at the moment I will have to trace the data flow to make sure everything is being set properly.

More Updates

The old blue bullet was beginning to annoy me in Asteroids because since changing the background (also blue) its become harder to see. It was also a little to big in comparison to the ship. So I hopped into Photoshop and put this new bullet texture together, its pretty small but it uses more predominant colours (red and orange) and stands out a lot more, I'm also happier with the size of it in relation to the ship.

Another thing that has been annoying me is the fire that comes out of the back of the ship. At the moment the emitter actually starts from the center point of the ship so a lot of it is actually rendered behind the ship, and also because it starts from the center point it turns/curves all wrong. I attempted to get the fire to sit at the back of the ship by applying some extra units to its location, but in doing that it was producing undesired results were the fire emitter would either not move from the center of the screen or it would move in strange directions around the screen.

Pete and I were talking about combo's and I suggested earlier that we should have a pop up when you complete a combo, weather it pop up were the combo ended or just somewhere on the screen. I made the below texture, nothing much to it at the moment.

Combo Texture.

I've been looking at Asteroids and having the ship firing just the one bullet doesn't look right, I decided to make the ship fire two bullets, one from each wing. The tricky part is trying to get the bullets to fire from the wings all whilst the ship is moving around and rotating. I'm lucky Pete wrote up some good vector classes for me, I made use of a Polar Vector to move out 90 degree's towards the wings, doing that seemed to work a treat.

Ship firing two bullets.

I've been trying to design some art for Missile Command, I am trying to use Illustrator as my starting point and try and gain some inspiration from the vector drawing, but my drawing skills are just to poor to be able to draw anything useable. I've been asking around at uni and in forums and all sorts of places for people that can draw and possibly help us with some art, but it feels like I'm hitting my head against a brick wall. Were going to have to figure something out soon once the desperation sets in.


I coded some health into the players ship, the idea being that when it reaches zero the player's ship explodes and he/she loses the game. If a player collides with an asteroid the velocity of the ship and the asteroid is taken into account when calculating the amount of damage the players ship will incur, so if the player is traveling really fast and collides with an asteroid they will die immediately compared to traveling slowly and tap the asteroid only causing slight damage. I got Pete to add an explosion effect to the ship when it died that turned out pretty good.

Pete asked me if I could update the networking code to include the strength of an event between players, so each client can interpret the strength according to the game style. For example, Missile Command wouldn't be able to handle a 100 hit combo from Asteroids because it would spawn to many missiles, whilst it would take to long to gather a 100 hit combo in Missile Command leaving Asteroids with nothing to do. Anyway I simply updated the current command for triggering an event and tacked on the strength, when the event is parsed into the client it is split down into sections allowing each part to be read separately. After writing it up and doing some basic tests it worked as expected, now Pete can continue to work on the scoring mechanisms for the game and make use of the strength.

When Pete was finished doing some work with the new event code we decided to some testing to see if it would work in a real situation and to check out the cause and effect of sending events down the network. After a couple of tests it proved to be a success, the games were reacting just how we had anticipated but with the exception being that we hadn't really written any code to normalize the incoming strength so we were experiencing a lot of asteroids appearing on the screen at once, which meant the average time spent playing a single game was around 20 to 40 seconds. But either way, our original concept of having old retro games in a new multiplayer environment is being achieved and I think its bringing new life to some old classics.

Lastly, I tried to export the engine into a jar (executable Java file) using Eclipse, but after testing it I discovered that the GUI wasn't reacting as expected. The buttons were not reacting at all making it impossible to even start a game. I looked over the files in the Jar notably the manifest file, which is designed to contain the base information and references for the Jar file to read. I compared the newly created manifest file with one generated using Netbeans and found that Eclipse was providing an almost empty manifest. I replaced the eclipse one with the Netbeans one and the game began to work, this is interesting considering I thought that I setup Eclipse properly, but maybe I haven't.

Mmm updates

Current build of Asteroids.

During today's tutorial at university, Pete and I had to compile a version to show our tutor to show him some of our progress. But to do that once again I had to change the GUI from Java 6.0 to 5.0, because I built the GUI in Netbeans it used all the latest components and even throws in a bunch of its own (netbeans) components. So I had to resort to using a Null layout and reorganizing everything manually in the code, I probably should of done this from the beginning, but I was lazy and just wanted to something quick to use as a prototype for testing. Besides the GUI will eventually be coded in OpenGL and be apart of the game. Anyway when I got that going, we showed our tutor and he was happy with our progress, he asked if we could have a working version of the events by next week and we assured him we would.

Later after university, I continued working on the game, I was observing a strange problem were when ever you moved the ship and smoke would be emitted, when the smoke finished rendering everything would disappear for a 1/4 of a second and then come back. I literally spent about 2 hours looking for the solution to the problem, I looked over just about every single line of code to do with smoke about 10 times over. It wasn't till the 2 hours were up until I actually discovered that the game was progressively setting the alpha value to 0.0 when all the smoke was gone, and OpenGL being the state machine, it was making everything else's alpha 0.0 and not reseting the colour properly. I simply made the emitter reset the colour and alpha values back to normal when the smoke was finished rendering. Problem solved.

Pete had been working with the smoke for a little while, and had all of the logic down pat but really has no idea how to draw and texture with OpenGL, so its my job to finish off the smoke with its texture and get it blending properly. Pete based what he put in our game off an example I sent him of another smoke emitter written in C++ (Note: I'll post the link at a later date, I don't have it available at the moment) which already had a smoke texture, so I grabbed that to use as my test texture. After a bit of playing around I got it working, but I found the texture I was using from the C++ example to be causing the smoke to become white when it was really dense, so I jumped into Adobe Photoshop and just dulled it down a bit so the center of it wasn't completely white anymore, this worked a treat. See below for my textures and some examples of the smoke in action.

C++ smoke texture.

Updated smoke texture

Examples of smoke emitter in action:

Lastly I updated the smoke particle class (object) to include a growth rate, the rate at which the polygon increases in size over time, so that way the smoke particle looked more realistic and gave the effect that it was dissipating.

Pete's been hassling me to change from Netbeans to Eclipse, so today I decided to give Eclipse another go. I had previously attempted to get Eclipse to work at the beginning of the project, but I encountered problems getting JOGL to run/work, but now I understand how to setup the libraries and have done it so many times that its become almost second nature, I found it pretty easy to get the project moved over to Eclipse. Another reason why I switched over was because Pete totally screwed up the CVS server and wound up putting the source another folder deeper, so now we have "RetroWars/retrowars/retrowars/". It probably looks pretty funny but I couldn't be bothered fussing over the CVS trying to get it right again, so I'm just going to use what ever setup Pete has. After checking out the source, Eclipse decided that I had about 500 errors, compared to Netbeans 0.0, being unfamiliar with Eclipse I wasn't aware that it was set to a lower source level than what the game requires, the source level is what version of Java Eclipse uses to correct your source. The default source level in Eclipse is 1.4.0 but todays JRE (Java Runtime Environment) is up to 6.0, so I so selected 5.0 the happy medium for now because not all people have version 6.0 yet, and that includes all the university computers. One thing Pete did tell me about Eclipse was that it gave a lot of warnings related to redundant references and code, so I routinely went through the 200 warnings we had and cut it down to about 40. The left over warnings are references to some pieces of code I don't want to touch just yet or they are saying that we are using static variables in a non static method.

Previously I had put together a group of asteroid pictures and its now time to implement them. At present the asteroid class is just using the one texture so I converted it to use an array of textures (the asteroid textures), because I had a couple of different types of asteroids I got the constructor to pick a texture randomly based on its size, if the asteroid was the smallest size it has about 5 textures to choose from. It was important to have a set of different textures so that the player will feel more immersed in the game. Another little thing I noticed was that none of the asteroids were spinning around, if the asteroids were spinning it would give the illusion that they were moving though space, so to counter this I threw in a couple of variables, below are the variables used and their purpose:

rotated - The angle the asteroid will be rendered at. This is updated each frame were the rotationSpeed is added to the current amount of rotation. OpenGL takes care of rotating the polygon so keeping the double within the bounds of 0 to 360 is not necessary.

rotationSpeed - This is the speed in which the asteroid spins. This speed is determined randomly when the asteroid is created and is between -1.5 and +1.5.



Now with all the asteroids setup and going, I thought I would give our first game (Missile Command) some attention, Pete set it up to have some fire and smoke trailing behind it but I don't think he put to much effort into getting it right. One thing I wanted was to have the missile leave a trail of smoke behind it so the player could use it to judge the trajectory the missile is on, just like in the real Missile Command you can see a line following the missile. I attempted to tweak all the settings in the hope of getting it just right, but in the end had to luck. I'll get Pete to take a look at it since its his area of expertise.

Ok, Pete and I have been talking about the scoring system for a few weeks now, we have been discussing how the game triggers events and keeping a record of combo's and scores so they can used to make up statistics at a later stage. Pete's been telling me he loves having statistics and wants to implement a handicap system, were if your a really good player the game will be harder for you in comparison to a newbie. I'm fine with all of this and Pete seems to be leading this section so I'm more than happy to let him write it up and test it all out. It's basically my job to write up the OpenGL code and make sure the thing looks good. So at the moment Pete has a score item, which is used to store the value of the score and where the score comes from (e.g. asteroid). Using this I coded in a render function designed to draw the score to the screen, and made use of the Score Manager to render each score as they were created. Firstly I jumped into Photoshop and started putting together a set of numbers, I went through a lot of fonts but there was one that stood out the most and I thought it would fit the look and feel of the game quite well. Below is the number set I put together, the reason it is drawn like that is because I want to make use of texture coordinates to point at a specific number, so rather than having ten textures in memory I only have one. As you can see below their are two versions, but this is only to illustrate what the scores would look like on a white and black background respectively. The actual texture uses the black background with alpha transparency so the numbers can be applied to any background.

White version

Black version

Now that I had my texture it was time to make use of it. I started out by drawing a large polygon to the screen and manually changing the texture coordinates to attempt to get the right number, but it was just talking to long. So I made use of the keyboard and setup a set of keys to alter the values of the texture coordinates at runtime, after each alteration it would output the texture coordinates to the console. Using this method I was able to easily move the texture around the polygon and get accurate coordinates, when I had each numbers coordinates I put together a 2D array containing all of the values so that the coordinates could easily be read and switched at runtime. After implementing the texture coordinate array into the score renderer it was just a simple matter of rendering the right numbers to the screen, I used some basic Java methodology to convert the value into an array of integers I could use with the texture array to pick out the right numbers and print the poly's to the screen. The above description is a huge simplification of the process, which actually took me til 4am in the morning to get working. I had to leave the eye candy stuff for Pete later that day.

Score overlay example.

Lastly I created this new ship texture, I nabbed it from a texture set available from "The Lost Garden" blog I mentioned in an earlier blog. The ship looks pretty cool, I'm not sure if it really fits in with the whole space ship feel, but meh, ill change if we have to later.

Ship texture.

Ok, thats it. Hope you enjoyed.

Music

I found this website today, I was sort of browsing the net for other old style games and I discovered that someone else made use of a music format I had never heard of before. He referenced to this address for music:

http://modarchive.org/index.php?ArticleIndex

From what I can gather its a type of music format that lets people pick a bunch of electronic instruments and allow them to compose music electronically, but the most important fact about this format is that the file sizes are really small in comparison to mp3's and other file formats. It can be compared to a MIDI but about 100 times better, the website mentioned above contains a large library of music all made by contributing artists. I haven't discovered if the music is royalty free or free to use else were, but from what I can gather it seems to be open for use since you can download any song you want and play it no problems. This gave me an idea about implementing something that can play this type of file in our game! Thats when a Google search provided me with this solution:

https://jmod.dev.java.net/

This website is for a Java API someone is developing designed specifically to play this type of music format. I haven't looked at the website throughly but from first glimpse I can tell it is exactly what we would be looking for if we were to implement this type of music in our game engine.

This is exciting, if we are allowed to use the music in our game without any license or royalty problems it means we can have good quality music and low file sizes and we wont have to suffer with crappy old MIDI's.

Collision Detection Hmmmmm

Well after all the effort I made in trying to thread the collision detection system it worked out to be pointless. In the end the actual thread was doing nothing more than looping and waiting, my original idea was to thread the actual collision checks so that it would check parallel to the renderer, but I found it was doubling or tripling up on the checks and causing more collisions than their really was. I want to be able to do something with it though, possibly have the cell purging and moving threaded, that might reduce the load, or should I thread the whole update process? leaving the engine just to render as is? Hmmmm I was thinking of slowing the thread to the frame rate (usually 60fps) but without testing it I cant be sure it would give accurate results.

I think I'll just dump it for now, so that way collisions are accurate. The only problem I'm having now is that some objects (notably the player ship) isn't colliding with some asteroids as expected. I think we will have to look into the collision detection much deeper to find the hole in our code.

More Tweaking

Right, in my previous blog I didn't go in depth about collision detection and left it for later, here I'll talk about it more and fill you in about what I've been doing. Previously I had explained that I threaded the collision detection, to be more accurate I only threaded the collision checking and not the rest of it that dealt with organizing game objects into their cells. Because more than one thread (The main thread and the collision check thread) was accessing the same lists I had to try and achieve some sort of synchronization, I don't want the engine to add an object to a collision list in the middle of a check and have it be missed or removed before it can be used or checked. Java's approach to this type of synchronization is were you nominate which object you want to use and that object becomes locked to all other threads until it has finished doing what its doing. This is a good method of keeping things organized but it can cause deadlocks, wereby if threadA needs to access an object ThreadB has a lock on, whilst ThreadB needs to access an object ThreadA has locked you end up in a pretty bad situation. I'm not sure if its possible to get out of a deadlock but by the looks of things its not. It took me sometime to get the code actually going, I was using a great book title "Java Threads 3rd Ed" to help me with some source and the ideas being threading and proper techniques. When I did eventually get the code working, for some reason when ever a collision occurred it would fire off 4-5 times (in this example I was getting about 10 asteroids appearing on the screen instead of 2) I believe this is because the game is only operating at around 60 frames per second compared to the collision checker which is probably running at triple that. I was also getting some deadlocking on occasions and the game was freezing completely. I'll have to keep at it, maybe I have the synchronization setup wrong.

Whilst coding the new collision system I decided to optimize the way the engine split objects up into cells and stored them in lists. After looking over Pete's code I discovered he was using ArrayLists to store each object, and then was using a very high iteration looping algorithm designed to retrieve objects that were needed for collision checks. The method "getObjects" is passed in a list of game objects and then its supposed to pick out any matching objects from the cells list, in theory this works but in practice it was horribly slow, Pete had used the "ArrayList.contains(Object)" method, which when looked into deeper just runs through a for loop checking for the passed in object and returns true if it has been found. Now if this method is looping through all of the objects in the input list (could potentially be in the hundreds) and then looping through all the objects in the cell list for each object in the input list it equates to A LOT of loops! e.g. 100 Objects X 10 Objects in Cell list X 9 Cell Lists = 9000 checks every time the engine needs to check for a collision. That is a lot of checks, to optimize this I looked at how the cell list operates and its general purpose. It's designed only to store objects contained in each cell but because objects have the potential to move out of their current cell the cell list is constantly being updated and objects are being moved from one list to another. The first data structure that popped into my head was a LinkedList, it is famous for its fast in and out processing and is just as fast at iterating through its contents as any other type of data structure (besides a binary tree) so remembering my old data structure techniques I converted the Cell class into a linked list that used a "cellNode" to store its data and references to the next node. After implementing this I immediately discovered a massive performance increase, which is exactly what I was looking for, previously with Pete's design I wasn't to happy to discover that if you placed more than 500-1000 objects on the screen it would start to chug and lose frames even on my PC which has enough power to run Neverwinter Nights 2 on full graphics at 1600x1050 resolution without losing a frame (A pretty good feat if you ask me) whilst our little game that is only 2D and uses basic primitives is chugging and grinding to a halt.

Another change I made was to the engine and the engine loader. Currently when you start a game a Loader is initialized and is setup to load all of the games textures into memory and build any display lists (currently not setup) for objects, when it has finished doing these things it then starts a new game/engine. But the problem with that is that it will make it harder down the track when we begin to have more and more games, and the need for a dynamic way of starting/loading games becomes necessary, I guess the main problem is, how do I tell the loader what game to load without having to change the code and recompile every time? This is why I decided to change the way it works. I want the engine/game to be started and then the engine starts its own loader, this in theory will actually allow developers to utilize this time frame to load any custom textures they need for their game, and this also solves the problem I described above because now it doesn't matter what game is started, they will all start a loader and load the game specific textures and display lists.

One thing thats been annoying me lately is the fact that all the objects related to a game (e.g. City, Turret, Missile - relate to Missile Command) are placed alongside the game class, inside a package specifically for that game. E.g. "retrowars.games.missilecommand". Whilst we have another package called "retrowars.modules.premade" which was actually designed to be the correct place to put all of these objects so that way other developers can use them for other things besides just that game. A lot of the functionality built into these objects is pretty generic and should be able to be used across all games. So I moved them all into the premade package and reorganised the game files to reside in just the "games" package, so we can have a list of more than one game. Netbeans did all the refactoring (changing of the code) for me.

Thats about it for today, their is probably a bunch of other little things I neglected to mention but its pretty difficult to keep track of everything you do whilst coding. I'm sorry but no pictures today.

Tweak Tweak Tweak

Today whilst at my studios tutorial I was doing some updates on my blog when I remembered the "Lost Garden" (the blog site for a game artist) and decided to take a look at his site a little closer. I hadn't looked at his website past the Sinister Clone graphics he posted but this time I discovered a whole bunch of free game art under his directory. All the art is very well drawn and designed exceptionally well with animations, etc. I skimmed over the many many pictures looking for something I could use as an asteroid and discovered this neat little set, I think their original purpose were to be rocks, but I don't see how they can't be used as asteroids. Check it out below.




I set about making a couple of them into textures while I was at university so I could test them out a little later tonight. After finding these graphic sets I'm really keen to do some more coding on the engine, but I have been holding off to give Pete an opportunity to do some coding. But if Pete isn't going to use the time I'm off doing other things its his own fault and it truly does reflect how much he is putting into the project. I do admit that the particle system is a great addition to the engine but I cant help but wonder if it was actually necessary at this point in time, I think we have bigger tasks to worry about at the moment like getting the game to a standard were we can present it and have it work effectively.

My asteroid set.

So when I got home from university I set about doing some coding, their have been a couple of issues on my mind and I asked Pete to take a look at them, notably the collision detection part which he coded, but nothing has been changed since, so I have taken the liberty. To start with I threaded the collision detection system so it runs parallel with the render loop to ensure maximum performance and frames per second. It wasn't an easy task, it required a lot of changes to be made over the whole engine and between the current games we have at the moment, for example the previous setup for collision detection was designed so that each game had their own list of objects that could collide and the developer would pass these two lists to the renderer telling it to check the collisions between them. This wasn't the ideal situation to me, essentially I don't want a developer to have direct access to the renderer and to be able to manipulate anything outside the scope of the engine. To resolve this I created a method that the developer can make use of titled "addObjectToRender(GameObject o)" which will pass the object straight into the renderer for processing. Now the more I kept at it, the more I found I needed to change elsewhere to make it fit in with what I was doing, so for now I'll leave the collision stuff and move onto some other things I added or updated and talk about all of that later.

Standing City.

Demolished City.

Soil Texture.

Most notably I added a Texture Manager, prior to this I was using the Loader to statically load each game object's texture and pass the object its texture id (a reference to the texture in memory). But what this meant was that the loader was holding onto the array of texture references forcing the objects to call back to the loader to retrieve that value, an example is below.

Loader:
public static int textures[] = new int[20];
...
int cityTexture = LoadTGATexture("images/city32.tga");
City.setTextureId(cityTexture);

LoadTGATexture:
gl.glBindTexture(GL.GL_TEXTURE_2D, textureArray[Count]);
return Count;

City Object:
public void render()
{
gl.glPushMatrix();
gl.glBindTexture(GL.GL_TEXTURE_2D, Loader.textures[textureId]);
gl.glTranslated(location.x, location.y, 0.0);
gl.glBegin(GL.GL_QUADS);
gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex2d(-30.0, -30.0);
gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex2d(30.0, -30.0);
gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex2d(30.0, 30.0);
gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex2d(-30.0, 30.0);
gl.glEnd();
gl.glPopMatrix();
}

The line I want to pay attention to is "gl.glBindTexture( GL.GL_TEXTURE_2D, Loader.textures[textureId]);" and how it refers back to the Loader. This is why I created the Texture Manager. I have made it a public object inside the Game Engine, so a developer can make use of it to load new textures and any game object can reference it. I created a method that a game object can use to retrieve its texture for binding titled "getTextureForBinding(int i)", this will retrieve the reference to the texture in memory based on the index given for the array. When a new texture is made the index is returned so that the object can store it for later use.

Now one of the other issues I wanted to check out, was if I could render primitives and textured objects at the same time. I wrote up a quick method for game objects so that it would draw its bounding circle (for collision detection) in red, and made use of the glEnable and glDisable functions to turn texturing on and off. Surprisingly it worked and its actually pretty handy being able to see the collision bounds for debugging purposes. The main reason I wanted to look into this was because Pete's particle engine ran a lot faster when it was using points which is logical and I couldn't imagine the load on the pipeline having to render a whole lot of textured particles, if I had to estimate it would be extreme! Below is a screenshot of Asteroids with bounding circles being drawn. One thing I notice in that picture is that all the asteroids are facing the same way, eventually I want to make them rotate and spin in different directions and speeds to break it up, shouldn't be to hard.



I also found this picture of space somewhere on the net, its actually much larger than this but I cut a 512x512 piece out and have pasted it below. It looks pretty good when applied to the asteroids background, but I'll have to get Pete's opinion too.



I'll talk more about how I'm going with the collision detection in the next blog. Thats it for now.

Particle System

It looks like Pete's been doing some work lately, I know that he said that he had been working on a Particle System a few weeks ago in our tutorial, but I wasn't sure if he had actually done anything yet, but he has. He sent me what he had done so far, which was almost a complete product but rather than using OpenGL he made use of Java's 2D capabilities to draw to the screen, he asked me if I could convert it into OpenGL because he was interested to see how fast it would run. I quickly jumped into Netbeans and grabbed some GL base code from a tutorial project I had used to learn more about texturing. The base code made use of a reusable GLDisplay class and makes the whole process of setting up a display almost effortless. Once I had a window working I started cutting pieces of Pete's code out and rearranging some methods to work in a OpenGL context. It took me roughly half an hour to get the engine working and acting exactly like Pete's example, I encountered a few minor problems during that time, but they were easily solved. The first problem I encountered was related to when an explosion occurred, when an explosion occurs a set of 200 particles are made to shoot out in all different directions and at varying speeds, but in this case I was getting all of the particles clumped together and moving as one. To fix this problem I told the matrix (3D space) to reset its identity (3D coordinates) after drawing each particle which would allow the engine to move each particle independently, as I write this it dawns on me that I could have simply put that in the display function instead and would of got the same result, anyway by doing this it gave the desired result.


After sending the code back to Pete, he said he was going to implement it into the actual game engine and do some more optimizations like replacing the data structures with Link Lists rather than Vectors and some other general optimizations. I began doing a bit of tweaking and testing to see what the limits of the engine were, I discovered some interesting results. Firstly I found that the engine doubled in performance when the particle was told to update at the same time as it was being rendered, prior to this Pete was updating each particle first and then rendering it. I think that Pete has this "update then render" mentality stuck in his head because gamedev.net told him to do it that way, in this situation I think it would be better suited to having this logic combined. I changed the update function inside the Particle System class (A particle system is for example a particle emitter or an explosion, the system deals with its own set of particles that relate to its purpose) so that it would update five (5) particles at once, from reading a few game programming books this practice usually improves performance noticeably and by my observation it did just that. Lastly I wanted to find out just how many particles can be placed on the screen before the engine began losing frames per second and becoming jittery and slow. To achieve this result I used 5 emitters on the screen and altered the amount of particles per second that were being emitted. After tweaking the value several times I discovered that the engine would begin to slow and cause a cascade effect (because the frame rate slowed the existing particles were not dieing as fast as usual and causing more particles to gather on the screen at an exponential rate) at around 1975 to 2000 particles and above, 395 particles per second appeared to be the peak amount without causing frame loss. This figure could be significantly lower when implemented into our game engine and both Pete and I will have to look into performance optimization very soon.