multi ships

Now there's another spaceship.

Better lighting

been busy

Been busy with other things, so I haven't done much work on this the last couple weeks.

BUT...

I've found I can have many many many more asteroids on the screen at once by using a very simple trick:  Any asteroid further than a certain distance is now just a sprite.  Simple, stupid, but effective.

Next steps

Where am I going with this project? Well, I'm developing three areas of the 'game engine' seperately, but all three using the same common graphics framework:

• Open space: This mode is a very sparsely populated 3 dimensional space. This is suitable for 'outer space' situations. This is the mode used in my Asteroids test application. This is pretty much a flat scene graph: A list of objects.  Status:  It works.

• Indoor: This mode is for tightly closed spaces with lots of complexity. This is for mazes, for inside building, dungeons, etc. The scenegraph here is actually a graph: it is a list of sectors interconnected by portals.  Status:  Mostly works.  There is a critical bug I need to fix.

• Terrain: This mode is underdeveloped. I have old (really old) code that supports this, but only in a very basic way. I currently have implemented geomipmap patches: These are quad (well, square) arrays of quads that can be drawn at different levels. A 256 by 256 quad, can be drawn at 128x128, 64x64, 32x32, etc all the way down to 1x1, which is a single quad.  This way, the geometric detail for each square region of terrain can be varied based on distance.  This is a very common solution to the problem:  Status: Not close to finished.  I can draw a small list of patches at various detail levels, but have not made the jump from geomipmapping a couple patches to geomipmapping a large scale piece of planet.  

Next Steps:

I can do two things:  1)focus on the graphics code, and fix the indoor bug and finish terrain or 2) I can make a simple game with what I have now and get my code out onto the internet

I am going with option number 2.  In the Asteroids test, or whatever you want to call it, you can fly through space and shoot at asteroids, just like the classic Atari game.  The open-space portion of the engine works just fine, so these are the next steps:

1. Add sound
2. Add simple powerups and score system
3. Add an alien spaceship to shoot at the player (remember the stupid UFO noise from old Asteroids?)
4. Clean up the portions of the graphics code that are exercised by this simple game
5. Put it up on github.

Hopefully this will all be happening in the next few weeks.

Ok a test video

Here is a video showing some 3d gameplay.

welcome to my asteroid field

 So, as a short term goal for this project, I've decided to work on a 3D asteroids clone:

This is in 3D!  So what does this do at the moment:

• 6-DOF 'spaceship ' camera control
• Each asteroid geometry is randomly generated  [(although I reuse the same texture :(  ]
• Each asteroid moves with a constant intertia, and rotates, independently of each other
• Background starfield is randomly generated.  Stars are infinitely far away.

Limitations:

• Asteroids are drawn without lighting at the moment.  (There's no 'sun' present yet)
• Can't shoot
• Asteroids don't do anything when they hit each other (yet)

How am I generating an asteroid?  I'm starting with a cube, and randomly moving vertices around.

I need a scenegraph

I need a simple scenegraph for projectZ.  The graphics portion (gx) can already do a lot of basic graphics tasks, and I think that gx itself should be just a renderer that draws what its told to, when its told to. It is the business of the game engine to determine which things are/n't visible.  Where the camera is, which sector it is in, which other sectors are visible, etc should all be determined by not-the-renderer.

I'll make another post soon with details of what the scenegraph will do.

(Does anyone read this anyway?)



The graphics portion of projectZ can do this:

 
files:
load OBJ models from disk (supporting v, n, vt and f directives)
load 8-bit, 24-bit and 32-bit TGA images from disk, to use as textures or heightfields.


2D rendering:
draw lines, circles, arcs, polygons of varying color, thickness, with alpha blending
draw sprites scaled and rotated, with alpha blending
render text in various sizes from bitmap font texture (of course with alpha)
 
3d rendering:
Render models with ambient, diffuse and specular light.  Multiple lights supported (up to the hardware limit)
Texture mapping, with multiple textures supported at once (up to the hardware limit)
Alpha blending
Z-buffer  (render objects in any order without having to sort by distance)

misc:

Full 6 DOF camera movement (simultaneous up/down, left/right, forward/back, yaw, pitch, roll)
Mouselook
Keyboard input

experimental portal system

we have OBJ file loading and some crappy light

I have a very lighting working.  (Nothing special).

I can now load OBJ file meshes.  This is something created using MakeHuman, exported to OBJ and loaded/rendered inside ProjectZ.

Short term projectZ goals:

-Add better lighting support (multiple lights)

-Fix portal rendering. (It is very hacky at the moment.)


Not-so-short projectZ goals:

-Implement basic skeletal animation (yikes!, probably)

Misc 2d:


-Write a small demo game showing the 2D sprite portion of the library working.

Non-graphics related:

- Any game, 2d or otherwise, will need a sound layer.  I have some old win32 wavout code left over from an old project.  It is current sitting in projectZ's misc-other-code-to-review-and-rewrite folder.  (Ok, its not called that; that folder is called projectZmaybe.)

back to work

Ok, I've returned to this project.

 
Added:

A simple line-drawing API that can draw colored lines, circles, arcs and regular polygons.  And it does not use immediate mode!  Why make this?  So far, the 2d graphics API has been sprite-only.  Sprites are nice, but vector games like the original Asteroids or Lunar Lander can't be done well with sprites. 


In development:

The 3d portion of the renderer has been able to draw textured meshes for quite a while.  These meshes are created programatically by the application.  I need one built-in file format for my graphics library to read.  I'm choosing obj.  Why?  It's a text format, its easy to parse, and I already have old code to look at to read it.  I probably won't use my old code, but at least I have some working reference material to look at when my new code doesn't work!



Under thought:


I need a simple default lighting model.  Yes, yes, the library should let the user load GLSL shader scripts from text files.  That's easy; the graphics driver parses the language and its just a pass through.  BUT the idea of this whole library project is to be easy to use.  I need a simple, basic lighting model that's activated by default so a new user, who hasn't set up lights, will actually see shading as soon as they load and render a model.  An advanced user will set a shader. The entire library so far has been designed so that you just turn it on and draw right away.  All the common stuff is taken care of.  By default 3d has depth buffer on.  By default alpha blending is enabled.  Etc.