[Superspace-discuss] Re: SuperSpace

[Richard S. <rt...@dc...>]

I hope you don't mind me replying on the list.  No-one ever seems to want
to post on the list, and I'd like to tempt some lazy second-years into
replying.

On Wed, 21 Feb 2001, Tim Brown wrote:

> Hi, I had a look at your project and wouldn't mind joining it. My
> sourceforge user name is TKBrown44, if you want to add me to your
> project.

I'll add you, but don't go changing anything!

> Looking at your project, i've done a couple of similar things before,
> although mostly i've been working with MS visual c++ in windows with
> directx/opengl, and i'm not familiar with the Allegro libary.

OK, I'll fill you in on my/our experience.  We are Java programmers.  I've
just started learning C++, this is my first C++ program.  Tom and Justin
haven't really learnt any C++ but they say they intend to.  The main
purpose of doing this game is learn C++.  Also, it's simply not possible
to do decent games in Java.  The reason the game is 2D is that 3D is a lot
more complicated and not suitable for a first project.

I better explain a bit about the philosophy behind my programming.
First, I'm a Free Software bigot and I don't like Windows for moral
reasons.  Second, I think Windows is pretty shit, and I wouldn't use it
even it was Free Software.  Therefore I decided to make a game for Linux.

Now, there are several graphics libraries available for Linux.  Most Linux
games either use X windows directly, or else via the SDL library.  Tom
pointed out that most people will only a play if its available for
Windows.  He is quite right; XShipWars for instance is Linux-only, and
hence no-one plays it!  X windows code is not portable.  SDL and Allegro
are both portable.  I took a look at both of them and Allegro looked
nicer, so that's what I chose.

DirectX was never an option, because it's Windows-only.  The game *does*
use DirectX, but it does it via Allegro, so you only have to learn the
Allegro interface.

OpenGL is something I would like to learn, but 2D openGL is not very good,
and as I said, this isnt a 3D project.

You can supposedly use Allegro on MSVC.  Rather embarrassingly, I actually
paid money for a copy of MSVC 5 back when I was a naive schoolboy who
didn't know about the wonders of open source.  I did try and see if I could
get Allegro to work on it, but I couldn't.  So I decided the Windows
version would use the same compiler as the Linux version, GCC.  The
MingW32 port is probably the best, and I have a fully working installation
of it in the BitBucket which you can download and use at home.

XEmacs a is better IDE than MSVC anyway :)

> I looked through the source code and have a couple of questions:
>
> What is the final game going to be like? Do you have a list of specs or
> design doc or something i could look at.

When you get into the second-year you will get all the design docs and
requirement specifications you can stand.  If you get Professor Fenton as
a lecturer, you will spend about 15 weeks on nothing BUT design docs.
Therefore we are deliberately doing as little planning as possible.

The project page contains this summary:

"Think of Asteroids. Now add a bit of Thrust. Now imagine the multiplayer
aspect of Sub Space. But with high-colour graphics. And finally, imagine
there is a game of Scorched Earth going on at the same time. There you
have Super Space War."

If you have played Thrust, Sub Space and Scorched Tanks then this is
pretty clear.  If you havent, you might need a little more explanation.

> You seem to be using fixed point math for the stars and the body
> positions etc, why are you doing this?

Cos we need to be able to move fractions of pixels.  The alternative is to
use ints and divide them by 1000 before plotting to screen, but fixed
point is faster than that and the code looks cleaner.

> Fixed point math isn't any faster
> than floating point math on most modern processors. I think
> multiplication may be slower using fixed point math than with floating
> point, certainly if the operators aren't written in inline assembly.

Fixed point is simply bit-shifted integer.  I find it very hard to believe
that integer operations are slower than floating point.  Maybe a 3D
graphics card has more FP units than Integer, but I doubt an x86 does.

I dont see how writing inline assembly for (int * int) is going to produce
code that is any faster than the compiler can produce itself.  Okay, so
one of the operands will have to be bitshifted before the multiplication,
but that wont slow it down much.  Plus, we use a lot of trig functions.
These are implemented using Allegro's fixed point lookup tables, which are
surely faster than the C library's floating point trig.

Your 'default' variable type should always be int.  Only use float when
there is a need for it.  And in this case, there isn't.

>
> Is there any reason why you are drawing the stars using the circle()
> function.

Mainly that was because Tom thought the single dots were too small!  He is
right though, a single pixel at 1280x1024 is not very visible.

> This seems rather inefficent, the circle drawing algorithm
> isn't particularly fast. Personally i think that plotting single points
> of different colours of grey looks quite nice for stars, or if you want
> larger stars you could draw them to a sprite and blit it for the stars,
> which would be faster than the circle routine.

If you check the TODO list you will find it on there.  We just need
someone to draw the sprites.

-- 
Richard

"Things need not have happened to be true.  Tales and dreams are the
shadow-truths that will endure when mere facts are dust and ashes, and
forgot."
 - Neil Gaiman, 'The Sandman'