To start with, I jumped into Photoshop and started drawing up some images, even if they don't look very good they can be used as filler images until we get better ones later. Some of the pictures I put together are below.
Background
Missile
City
TurretThe Turret is actually not mine, while surfing the web I accidentally stumbled upon a blog website from some game programmer guy, and he had released a set of 8bit graphics he made for a game he was producing. Now he released the graphics in hope that someone would eventually build the game or make use of them in an active way. So they are Open Source and free to use, so in that case I am going to use them.
Lost Garden - Website of the blogger guy
Ok, so why the Phew? Well! I wrote up a couple of functions that allowed the developer to load textures (Note: only Bitmaps and PNGs at the moment) and got them to render on the screen relatively easy, It was how I had envisioned and was as I had seen before. But most of the day was spent tweaking and testing and tweaking and testing trying to find the right combination of commands to make OpenGL use alpha transparency. But I kept getting this messed up situation were the objects I'm trying to render to the screen would just blend together. Now I looked around on the net for a good 3 hours of those 9 (spread out over the total 9 of course) just looking for ways to get what I want, and just could not find a single thing. I tried anything and everything I could think of.
Then I had a break though, I found this little program titled "glSandbox". This is a program thats setup specifically for you to test different settings relating to blending and alpha testing, and it even let you import your own textures to a polygon. At first I still couldn't get what I wanted out of it, trying every combination I could in it to get the texture to be transparent.
When I was on the verge of throwing my hands in the air and quitting, I looked back at the glSandbox website and saw a picture of it, and on it was a polygon with a smiley face texture that was transparent. This is exactly what I want! And if this program can do it, their just has to be something going on that I don't know about.
So, I set about putting that exact texture into the program, and trying to duplicate the result. It didn't take me long before I discovered I had been doing it all wrong earlier, using the Blend when I should of been using Alpha Testing (which makes A LOT more sense now *slaps forehead*).
The next step I took was try to get my own texture to do the same thing. I had been using PNG's and Bitmaps during the course of my previous attempts and I thought I was getting really close when I was getting different alpha blends, but I couldnt' have been more wrong. The format that the smiley face is in is Targa, which is actually probably the best type of image to use for OpenGL (according to my OGL lecturer last semester) because it isn't compressed and it has an alpha channel. So I converted my texture into a 32 bit TGA and made my own alpha channel in Photoshop. Once I did this and tested it in glSandbox it worked immediately! Horray! finally getting somewhere. Now that I know that I have a working texture, I need to implement this into the actual game.
I found a control/class thats actually apart of the JOGL library, its titled "ImageTGA" and its been specifically designed and put in the library for the sole purpose of reading and writing TGA images, bonus! I quickly wrote up a function that used it, and tested this puppy out. Now I was getting proper transparency but something was up with the colours, It looks like its missing the colour red or its replacing the colour red with the blue, man I have no idea right now. I've looked up the glTexImage2D command on Google, this command sets up the texture, giving it its width, height, format, pixels, etc and saving it to the computers memory for use. Now I'm pretty sure its the "format" section that I need to work with here, at the moment I'm using "GL_RGBA" which stands for Red, Green, Blue, Alpha. According to the specification their are a whole bunch of different formats I can use like RGBA16 and so on. But after testing if these work, none of them gave me the right result, some might give me jumbled up pixels and other times the textures would still be blue. It wasn't until I looked into the javadoc intellisense inside netbeans that I discovered that the TGAImage class had a method titled "getGLFormat()" and inside the little popup box was written "Returns the OpenGL format for this texture; e.g. GL.GL_BGR or GL.GL_BGRA". Now I had heard of these two "formats" before, but that was last year in my OpenGL tutorials and what not and really didn't pay much attention. It obviously means that the colours are loaded in a totally different sequence, Blue being the first one. When I discovered this, I put the command in and just let the TGAImage tell the texture what format it is, seems to make sense also. After testing this everything is working as expected. YES! Texturing can now be ticked off the list.
Ok, now I that I have texturing sorted and perfected to a fine art, I've decided to try and help Pete's section (Collision Detection) along and write something up that records and sorts what cell/zone an object is in. Now the objects that require zoning are objects that can collide and enemy missiles, so I made a boolean for each object titled "isZoned" thats purpose is to tell the engine weather or not it needs to be sorted into a zone/cell. I broke the screen up into 9 sections so that when its time to check for collisions the engine is only making checks on other objects inside that zone/cell and therefore reduces the amount of processing required by the CPU.
So, in the Object Renderer I made use of the already existing Update function designed to update each objects movement information and or status, and got it to start sorting each object that made use of the isZoned boolean. I wrote a class that specifically did this sorting and add and removed objects from each zone/cell and attached it to a thread, so it would be processed independently rather than being apart of the main loop. The reason I choose to use threading in this way was to ensure that the main loop isn't sidetracked with processing a massive amount of sorting information and having the games frame rate drop to almost nothing. As it is, If you do produce a lot of missiles which create threads then it will slow your CPU and the framerate, so its a lose lose situation at the moment, either Pete or I will have to come up with a better concept later. But for now, I have successfully got it zoning each object in its correct zone which leaves Pete with a little bit of a headstart (I hope).
Thats it from me today.
Lost Garden - Website of the blogger guy
Ok, so why the Phew? Well! I wrote up a couple of functions that allowed the developer to load textures (Note: only Bitmaps and PNGs at the moment) and got them to render on the screen relatively easy, It was how I had envisioned and was as I had seen before. But most of the day was spent tweaking and testing and tweaking and testing trying to find the right combination of commands to make OpenGL use alpha transparency. But I kept getting this messed up situation were the objects I'm trying to render to the screen would just blend together. Now I looked around on the net for a good 3 hours of those 9 (spread out over the total 9 of course) just looking for ways to get what I want, and just could not find a single thing. I tried anything and everything I could think of.
Then I had a break though, I found this little program titled "glSandbox". This is a program thats setup specifically for you to test different settings relating to blending and alpha testing, and it even let you import your own textures to a polygon. At first I still couldn't get what I wanted out of it, trying every combination I could in it to get the texture to be transparent.
When I was on the verge of throwing my hands in the air and quitting, I looked back at the glSandbox website and saw a picture of it, and on it was a polygon with a smiley face texture that was transparent. This is exactly what I want! And if this program can do it, their just has to be something going on that I don't know about.
So, I set about putting that exact texture into the program, and trying to duplicate the result. It didn't take me long before I discovered I had been doing it all wrong earlier, using the Blend when I should of been using Alpha Testing (which makes A LOT more sense now *slaps forehead*).
The next step I took was try to get my own texture to do the same thing. I had been using PNG's and Bitmaps during the course of my previous attempts and I thought I was getting really close when I was getting different alpha blends, but I couldnt' have been more wrong. The format that the smiley face is in is Targa, which is actually probably the best type of image to use for OpenGL (according to my OGL lecturer last semester) because it isn't compressed and it has an alpha channel. So I converted my texture into a 32 bit TGA and made my own alpha channel in Photoshop. Once I did this and tested it in glSandbox it worked immediately! Horray! finally getting somewhere. Now that I know that I have a working texture, I need to implement this into the actual game.
I found a control/class thats actually apart of the JOGL library, its titled "ImageTGA" and its been specifically designed and put in the library for the sole purpose of reading and writing TGA images, bonus! I quickly wrote up a function that used it, and tested this puppy out. Now I was getting proper transparency but something was up with the colours, It looks like its missing the colour red or its replacing the colour red with the blue, man I have no idea right now. I've looked up the glTexImage2D command on Google, this command sets up the texture, giving it its width, height, format, pixels, etc and saving it to the computers memory for use. Now I'm pretty sure its the "format" section that I need to work with here, at the moment I'm using "GL_RGBA" which stands for Red, Green, Blue, Alpha. According to the specification their are a whole bunch of different formats I can use like RGBA16 and so on. But after testing if these work, none of them gave me the right result, some might give me jumbled up pixels and other times the textures would still be blue. It wasn't until I looked into the javadoc intellisense inside netbeans that I discovered that the TGAImage class had a method titled "getGLFormat()" and inside the little popup box was written "Returns the OpenGL format for this texture; e.g. GL.GL_BGR or GL.GL_BGRA". Now I had heard of these two "formats" before, but that was last year in my OpenGL tutorials and what not and really didn't pay much attention. It obviously means that the colours are loaded in a totally different sequence, Blue being the first one. When I discovered this, I put the command in and just let the TGAImage tell the texture what format it is, seems to make sense also. After testing this everything is working as expected. YES! Texturing can now be ticked off the list.
Ok, now I that I have texturing sorted and perfected to a fine art, I've decided to try and help Pete's section (Collision Detection) along and write something up that records and sorts what cell/zone an object is in. Now the objects that require zoning are objects that can collide and enemy missiles, so I made a boolean for each object titled "isZoned" thats purpose is to tell the engine weather or not it needs to be sorted into a zone/cell. I broke the screen up into 9 sections so that when its time to check for collisions the engine is only making checks on other objects inside that zone/cell and therefore reduces the amount of processing required by the CPU.
So, in the Object Renderer I made use of the already existing Update function designed to update each objects movement information and or status, and got it to start sorting each object that made use of the isZoned boolean. I wrote a class that specifically did this sorting and add and removed objects from each zone/cell and attached it to a thread, so it would be processed independently rather than being apart of the main loop. The reason I choose to use threading in this way was to ensure that the main loop isn't sidetracked with processing a massive amount of sorting information and having the games frame rate drop to almost nothing. As it is, If you do produce a lot of missiles which create threads then it will slow your CPU and the framerate, so its a lose lose situation at the moment, either Pete or I will have to come up with a better concept later. But for now, I have successfully got it zoning each object in its correct zone which leaves Pete with a little bit of a headstart (I hope).
Thats it from me today.
No comments:
Post a Comment