They are places where "Z axis" does not exist, only YX reign, the word is unknown 3D, games are simple but should be played, many of them will make us having a good time

Post news Report RSS Black of Space Update June 14 2010

Black of Space is coming along quite nicely. I spent some time redoing some of the camera code, as well as making the program usable on windows (you see, Java does not like the \ in c:\ and prevented some of my absolute path code from working).

Posted by on

Introduction
Black of Space is coming along quite nicely. I spent some time redoing some of the camera code, as well as making the program usable on windows (you see, Java does not like the \ in c:\ and prevented some of my absolute path code from working).

Centered Jumps
Now, I would like to present something that should have been done a long time ago: Good-looking jumps. In my development version, jumping to an object with the camera placed the object in the upper left corner of the screen (because it was jumping by lining the object's edge up with 0,0). Now, I have implemented code that centers the object in the screen during a jump. Now when you zoom to a frigate, you don't have to manually line the camera up with it.

The jump code takes zoom factor into account when calculating the offset. This means that whether you're zoomed down to a meter or 1/4 of an AU, you can count on the object you jumped to being centered.

Mutithreading (CUDA Integration?)
One of the serious hangups in BoS is the scaling of 2D images. This takes up considerable CPU resources, and hangs up the rest of the game. For example, while zooming outward the entire game freezes waiting for the job to complete.

So, I intend to isolate the main thread into some smaller components that can run side by side and report back when the job is done.

  • Main - This thread is the one that has control over all processes.
  • Render - This thread is responsible for drawing objects on the screen.
  • Sound - This thread will produce sounds for the game.
  • Scale - This thread will take care of all the zooming work, so that the entire game does not freeze waiting for a single image to zoom.

But that's not the best part. That work will definitely be done, but I may even be able to integrate it with CUDA. CUDA is NVidia's technology for using their GPUs as additional processors and allowing the allocation of jobs to them. If I could have each thread running on a different part of the GPU, performance would be accelerated significantly. jCUDA would be used to integrate my game with CUDA.

The worst that can happen is I brick my source code and have to restore an older revision, but if this works I can boast GPU acceleration (and in a 2D game it would pretty much guarantee continuously fluid gameplay).

Music
My good friend and video game art enthusiest Stephen Marro is working on a musical score for the game, which will be posted when it is ready. Currently, the game produces no sound what so ever, because I have been working mainly on the graphics and logic aspects of the game.

Fitting
I have been writing a Module class that handles importing modules from a file (much like how units are imported) and can isolate a module from that file. Module.java will be used by Main.java to store information about what each module does, but Units will use an array of strings to store their modules by name (this makes sense, so that a copy of the entire module file does not have to be used by each Unit).

Feedback
This is HARD work, and I'm doing it all for a game I will make no money off. Reason 1 is that I want to make a high quality, free, space rts. The other reason is that NASA images cannot be used for commercial applications (trust me, reason 1 is more important otherwise I'd make my own planet textures).

If you have any feedback, masternerdguy@yahoo.com is the preferred way of contacting me.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: