Textures are in

Posted on July 20, 2010 by Alex

Well, here it is, the game, complete with textures.  I’ve even whipped up a set for mouse cursor, ship, and default enemy.
A few things to note:
The textures themselves are in targa (.tga) format.  I chose that format because it has support for an alpha channel (and hence lets me stick big square textures on big square objects but have the transparency work easily).  I may switch to .png later

ver6

Posted in State of the Game | Comments Off on Textures are in

Projectiles with angles

Posted on July 17, 2010 by Alex

A fairly unimpressive addition today too, but I did one of the three things I said I’d do today.  I made projectiles into arrows that point in the right direction.  I built in the angle data when I was building the projectile class, so basically I just added a call to glRotatef in the drawing function.

ver5

Posted in State of the Game | Comments Off on Projectiles with angles

Very little progress, but decisions have been made.

Posted on July 16, 2010 by Alex

I’ve been going back and forth on whether the objects in this game need to be three dimensional, two dimensional but with polygons defined in OGL to handle transparency and shape, or two dimensional squares with their transparency and shapes just faked by having parts of the texture be transparent (which would require using an image source with an alpha channel, but that’s not really a problem).  Agonized about it for quite a while now.  After a couple of weeks trying to decide how to implement it in 3D so I could have pretty shadows and reflected light sources off the sides of ships, I’ve decided to go with 2D.  Pure 2D, and that’s it.  Also, when reading about OpenGL on the web, and probably DirectX too: I have discovered that if there isn’t a date on what you’re reading, or the date is old, to just stop reading it immediately.  I spent quite a while reading up about techniques which aren’t even supported in the current OpenGL, and ignoring other techniques because the consensus seemed to be that it was only supported on “bleeding edge” graphics cards.  After checking up on that, I found out that by “bleeding edge” they meant “The GeForce 2.”  So despite the red book’s occasionally frustrating habit of not providing any context for its extreme detail, it’s probably the best way to learn.
So now that I’ve finally made the choice to go 2D and got back to writing code, today’s update: Transparencies.  The colors now mix.  It’s a little hard to tell, but I’m pretty sure all the combinations blend together, according to their alpha value, which in this case is just 80% across the board for all object types.  Also, it’s now using transforms to move the dots around instead of drawing the dots in a different position.  That might not be an obvious difference, but it’s a pretty important change.
So basically, it looks almost exactly the same, but it works differently. Expect things to actually have shapes and point in the right direction soon.  Either that, or textures.  Or maybe I’ll implement beam weapons.

game4

Posted in Design, State of the Game | Comments Off on Very little progress, but decisions have been made.

Shaders

Posted on July 2, 2010 by Alex

I’ve started reading about shaders.  Ends up there’s a whole extra programming language, “openGL Shading Language”, even beyond what’s basically a programming language embedded in function calls in normal openGL.  Fortunately the syntax is mostly a subset of C.
But it can be confusing.  So, some variables can be of the “varying” type.  This is for when you want to pass data from a vertex shader to a fragment shader (It hasn’t yet explained why you’d want to do that, or what a fragment shader really is, which is part of the problem.  As far as I can tell actual “shading” is probably not involved.).  But apparently values can be a little different each time you run something due to order of execution.  So if your program for some reason requires that it be exactly the same for a variable, you can label that variable “invariant.”  And things can be both invariant and variable.  And something else on top of that, sometimes.  So you can have, and it seriously gives this as an example, a “invariant centroid varying vec3 Color;” variable declaration.
It’s weird, you pass the entire shader program text to be compiled in as an argument to an opengl function which compiles it for you, and gives you a handle on the program that results.  So you’re compiling all this stuff, at runtime.  At least, the first time through.

Posted in Design | Comments Off on Shaders

Combining weapons

Posted on June 22, 2010 by Alex

I’ve been reading the OpenGL blue book.  Reading hundreds of pages of dense technical data without much context is getting tedious.
I’ve also been thinking, you know what game was fun?  That kirby 64 game.  And it was fun not only because you could swallow almost any of the enemies and steal their powers, but because you could combine any two powers into a new one.  There was a huge number of combinations and it was fun discovering them all.  Why not have that in a shooting game?  So, take a beam weapon, and a missile weapon, and when you combine them, you get a missile which shoots beams at anything within a range when it explodes.  It’s just surprisingly difficult coming up with an entry for every combination of a large number of base types, considering a lifetime of playing shooters.

Posted in Design | Comments Off on Combining weapons

Collision detection added

Posted on June 16, 2010 by Alex

Another day of progress for the game- I now have collision detection, and I fixed the stupid problem with the projectile updating routine not deleting the last projectile.
Controls are the same as version 2, only now blue dots will appear at a random position every 3 seconds, and if you shoot them they go away.
Report any problems if you find any.
I think this will be my final gameplay update until I improve the graphics.  I’m tired of looking at these giant boxes floating around.
Now would probably be a fine time to talk about my concept fo this game:  I am going to try to target the music game market.  While a game like audiosurf lets you kind of play a race game where the race track is your song, I’m planning on making a kind of geometry wars style game, where the guys you’re fighting are kind of controlled by the music.  The bar for gameplay for this sort of game is apparently set pretty low, it’s more the music that’s taking the front seat, so incorporating the music into every facet of the game will be the key.

game3

Posted in State of the Game | Comments Off on Collision detection added

New and improved

Posted on June 14, 2010 by Alex

Well, the game is improving.  Closing in on “Atari” level gameplay.
Major accomplishments of the day:
Creating a solid coordinate system, then translating that into pixel coordinates, so things won’t be different on different resolutions. This includes a border that things can’t go beyond.  That took longer than you’d think, but resolution and everything are now constants that can be changed at will.
Changing control for the ship to keyboard based (wasd).  The mouse cursor is still around, but now it’s what you’re aiming at.
Set up a “projectile” class.  It appears to work, except the “update projectile” function sometimes gets some problem where it won’t deconstruct some of the projectiles that hit the edge.   Anyway, it still looks like it’s working to the user, because the projectile class knows not to make the display call, it’s just that the computer is still tracking some of the projectiles after they go off the screen.
So I didn’t get around to collision detection.  Maybe tomorrow.
Anyway, new features:
It’s now fullscreen.  Use Q to quit as usual- this is more important now that it captures your cursor.  RGB keys to change cursor colors has been removed.  Spacebar shoots!  The projectiles have random speeds.  – and = still adjust mouse sensitivity.

game3

Posted in State of the Game | Comments Off on New and improved

A new beginning

Posted on June 12, 2010 by Alex

I’ve unfortunately had to burn the previous effort to the ground.  Ends up SDLs native sort of graphics mode is simply not compatible with openGL, it’s more there to provide a weird sort of backup in case openGL can’t run.  It runs in software, pretty much, and can’t really do much beyond putting flat images and text on a screen.  Of course, that only makes sense for pretty basic stuff- the plan “B” for a game if it finds OpenGL can’t run is to say “Are you fucking kidding me?  I quit.” so I don’t really have to worry about that.  Anyway, that was a dead end.  So I pretty much started over, with “The Red Book”.  I’ve heard from a few sources that that is The Book for openGL.  I’m about 50 pages in and about at atari level graphics, so, I guess since it’s about 700 pages long not counting appendices, that’s on course to look pretty nice by the time I get to the end.
Anyway, attached is the .exe.
Mouse movement moves the pixel, q quits, r g b all change the pixels color, – reduces sensitivity, = increases it.
I plan on having turning the ship into a triangle that points the way it’s moving soon, and maybe add a projectile to shoot too.  Maybe some collision detection and some moving targets.  Then it will be time to read a bunch more.
Oh, and the text file it spits out is basically just counting how many milliseconds pass between getting to the top of the main loop again.  I know premature optimizations are considered bad form, but it doesn’t hurt just to keep an eye on where you are.  I figure I want to try to keep that below 16 if I want to have 60 frames per second.  Right now it’s mostly 0s, which means less than a millisecond passes between loop iterations, but then again, it’s hardly doing anything.

game2

Posted in State of the Game | Comments Off on A new beginning