Very Computer

Hey guys,

I'm going to get to the point. I want to be a game programmer some day but I
don't know shit about it.
I need some tips from YOU as to where to get up on the learning curve. I
know a little C and C++(but I don't know enough to be kick ass at game
programming). Also do I need a 3D game engine first or should the game come
first.

Salutations,
Andrew T Phillips

Quote:

>Hey guys,

>I'm going to get to the point. I want to be a game programmer some day
but I
>don't know shit about it.
>I need some tips from YOU as to where to get up on the learning curve.
I
>know a little C and C++(but I don't know enough to be kick ass at game
>programming). Also do I need a 3D game engine first or should the game
come
>first.

http://www.geocities.com/SiliconValley/Vista/7788/qmap.htm

I apologize for geocities advertising silliness.  I think if
you turn off javascript you don't get pop-up windows.

Sean Barrett

I must admit, about 3-4 years ago I was into computer graphics and 3D.  I
was trying to find some text on the net about texturemapping.  I attempted
to make some of my own, was wondering of an efficient way to do it.  I
decided to forget graphics and persue windows programming (since it was more
likely to get a high paying job programming windows software).  Anyway, last
year I got a summer job at Matrox, which got me back into graphics.  After
finding out that you simply draw lines in texture space as you go across the
scanlines in screen coords, I figured out how to do it myself.  Pretty
simple, the problem was that I didn't know that, that was the way to go at
the problem.  I thought there was some "magic" method.

----- previous message ------
I agree about the texture mapping tutorials (sort of).  I have not found a
single tutorial on the net that does not have mistakes, and not one of them
explains the 'magic' cross products.  It took me weeks to get a texture
mapper working!  But I worked out what all the maths actually did!!!

The worst tutorial is at gameprogrammer.com because the author does not make
it clear that the routine only works on flat polygons.  He also complains
about the PCGPE article not explaining the 'magic' but he fails to explain
it too!

By all means read these articles for reference but you will have to
experiment a lot before you get a working texture mapper.  The PCGPE article
is definitely worth reading because it explains the optimizations quite
well, although you can do much better on a Pentium.  4 or 5 clocks is
possible, but I would doubt any less.

-ADRIAN-

Quote:>Hey guys,

>I'm going to get to the point. I want to be a game programmer some day but I
>don't know shit about it.
>I need some tips from YOU as to where to get up on the learning curve. I
>know a little C and C++(but I don't know enough to be kick ass at game
>programming). Also do I need a 3D game engine first or should the game come
>first.

>Salutations,
>Andrew T Phillips

I knocked around a raycaster for about a year.... and then I finally decided to
make a simplistic game out of it....

I suppose you could use a ready-made engine to create stuff with - but you
should understand how it works though....

The question of whether an engine of some kind should come first is a tricky
one though.... I mean, take music for example - you have to have some idea how
to play (even if you don't know you do) to be able to make a song....

The way I see it, there are alot of approaches you could take....

You could take the graphics coding you can do now.... maybe based on a demo for
something in a programming book... and, if you imagine changes you want to
make... like ways to make it "gamier" - go for it from that point....

Now if you have some kind of "vision" about a game you want to make, you should
keep in mind, that unless you've published a game before - you're going to have
to be pretty close to a finished product to get a company to publish it...

Learn what you can to come up with "reasonable facimilies" of the game ideas
that you have, maybe then you can recruit others to help you that have more
experience....

TRUST NO ONE!

Jim the loiterer

http://members.xoom.com/JimMcCue/index.htm

From what I remember, there was one minor bug in Sean's original code that
is easily spotted if you actually look at the code you're putting into your
project (I saw it right away, as do most other people). It's in the initial
calculations:

        a = Oa + i*Ha + j*Va
        b = Ob + i*Hb + j*Vb
        c = Oc + i*Hc + j*Hc

That's fairly obvious, most people have no trouble spotting it.

The vast majority of the problems people experienced were due to the fact
that Sean's original article uses the right-handed coordinate system. (I
remember a particularly memorable piece of mail from a guy who seemed to
think this was some kind of criminal offense because "no-one ever uses it
nowadays"). Sean was very clear about this in his article, it's the first
thing he mentions. I switched everything over to the left-handed system in
my article, I also explicitly state which one I'm using.

The next most common problem is that the screen coordinates people throw
into the equations are relative to the top-left hand corner of the
viewport. Sean explicitly states in his article that he works in "view
space", and then goes on to provide the equations from converting from 3D
space to view space. Anyone with half a brain can figure out it's relative
to the center of the screen. I also state the same thing very early on in
my article:

--- begin quote ---
Also the 3D origin point should be centered on the screen, so we must also
offset all screen points by the center point coordinates. For the
remainder of this article whenever I refer to "screenx" I mean "middlex +
screenx", and whenever I refer to screeny I mean "middley - screeny", where
<middlex,middley> is the location of the center screen pixel (ie <320,240>
for a 640x480 display).
--- end quote ---

I can't think of any way I could have been more clear about this.

The 3rd most common problem was that people didn't understand the
relationship between the so-called "magic number" calculations, the scale
value used in the persepective projection and the distance of the
projection plane from the view point (ie they all refer to the same thing).
Sean's equations assumed a distance value of 1, but he does explain how to
modify the equations to accommadate other values. I go into it in more
detail in my article, explaining how to derive this value from the FOV
value you want.

The bottom line is that people who cut and pasted code without actually
reading the articles were the ones who had problems, and so they damn well
should have. I've worked with quite a few people in the past who made
pseudo-careers out of doing nothing but this, and every single one of them
produced bullshit code.

Here's a challenge for you Herman. Presumably you tried implementing the
code in our articles before calling them "wrong" and "deplorable" in a
public forum, so howsabout you post your non-working code here. I'll have a
look at it and then point you to the parts in our articles that you didn't
read.

---------------------------------------------------------------------------

R&D Programmer                  http://www.geocities.com/SiliconValley/2151
Bullfrog Productions UK                                         ICQ:7876901
(...but I speak for myself)

[faggot whining cut out]

 >Here's a challenge for you Herman. Presumably you tried implementing  the
 >code in our articles before calling them "wrong" and "deplorable" in a
 >public forum, so howsabout you post your non-working code here. I'll  have
a
 >look at it and then point you to the parts in our articles that you  didn't
 >read.

Form what I glanced, there were several issues. You didn't specify where topy
and bottomy come from (in your horizontal-span renderer), you use the pmn
method to texturemap (who even uses that), and there was something else which
I thought was wrong. I'll go look at it and write what I found would be hard
to understand. Here's a tip though, provide some CODE?!

Here's some code I thought you might want to put in it.
Go through and remove the junk from it and put it in your tutorial (if you
want ofcourse). proper credit is due, however. Included is some gouraud
routines.

#include <stdlib.h>
#include <conio.h>
#include <math.h>
#include <allegro.h>

#define LEFT TRUE
#define RIGHT FALSE

  // for translucency
  COLOR_MAP *light_map;
  COLOR_MAP *trans_map;
  void LoadLightmaps()
  {
    PACKFILE *fp;

    if (!light_map)
     light_map = (COLOR_MAP *)malloc(sizeof(COLOR_MAP));

    fp = pack_fopen("lightmap.rgb", "r");
    pack_fread(light_map, sizeof(COLOR_MAP), fp);
    pack_fclose(fp);

    if (!trans_map)
     trans_map = (COLOR_MAP *)malloc(sizeof(COLOR_MAP));

    fp = pack_fopen("colormap.rgb", "r");
    pack_fread(trans_map, sizeof(COLOR_MAP), fp);
    pack_fclose(fp);

    color_map = light_map;
  };

/* _______________________________________________________________
  /                                                              /
 /   ScanEdgeAndStoreInArray:                                   /
/______________________________________________________________/ */
void ScanEdgeAndStoreInArray(int side, float TopX, float TopY, float BottomX,
float BottomY, int *Array)
{
  int FirstScreenY = (int)ceil(TopY);
  int LastScreenY  = (int)ceil(BottomY)-1;
  int y;

  if (FirstScreenY > LastScreenY)
    return;

  float DeltaX = (BottomX-TopX) / (BottomY-TopY);
  float x = TopX + (FirstScreenY-TopY) * DeltaX;

  if (side)
    for (y=FirstScreenY; y<=LastScreenY; y++,x+=DeltaX)
    {
      Array[y] = (int)ceil(x);
    }
  else
    for (y=FirstScreenY; y<=LastScreenY; y++,x+=DeltaX)
    {
      Array[y] = (int)ceil(x)-1;
    }

  if (FirstScreenY > LastScreenY)
    return;

  float DeltaX = (BottomX-TopX) / (BottomY-TopY);
  float GouraudStep = (float)((LastShade-FirstShade)/(BottomY-TopY));
  float CurrentShade = FirstShade;
  float x = TopX + (FirstScreenY-TopY) * DeltaX;

  if (side)
    for (y=FirstScreenY; y<=LastScreenY; y++,x+=DeltaX, CurrentShade
+=GouraudStep)
    {
      Array[y] = (int)ceil(x);
      Shade[y] = (int)CurrentShade;
    }
  else
    for (y=FirstScreenY; y<=LastScreenY; y++,x+=DeltaX, CurrentShade
+=GouraudStep)
    {
      Array[y] = (int)ceil(x)-1;
      Shade[y] = (int)CurrentShade;
    }

  Length = x2 - x1+1;

  if (Length < 0)
   return;

  NumColours = LastShade - FirstShade+1;
  Step = (float)NumColours/(float)Length;
  CurrentShade = FirstShade;

  for (x=x1; x<=x2; x++, CurrentShade+=Step)
  {
    putpixel(bitmap, x, y, color_map->data[(int)CurrentShade][Colour]);
  };

  // Sort verticies top->bottom
  if (y1 > y2)
  {
   int tx=x1, ty=y1;
       x1=x2, y2=y2;
       x2=tx, y2=ty;
  }
  if (y1 > y3)
  {
   int tx=x1, ty=y1;
       x1=x3, y2=y3;
       x3=tx, y3=ty;
  }
  if (y2 > y3)
  {
   int tx=x2, ty=y2;
       x2=x3, y2=y3;
       x3=tx, y3=ty;
  }

  // make sure polygon isn't abnormally thin
  if (x2 == x3)
   return;

  // scan-convert the edges
  if (x2 < x3)
  {
   ScanEdgeAndStoreInArray(LEFT, x1, y1, x2, y2, Left);
   ScanEdgeAndStoreInArray(RIGHT, x1, y1, x3, y3, Right);
   if (y2!=y3) // skip if it's a horizontal edge
     ScanEdgeAndStoreInArray(LEFT, x2, y2, x3, y3, Left);
  }
  else
  {
   ScanEdgeAndStoreInArray(LEFT, x1, y1, x3, y3, Left);
   ScanEdgeAndStoreInArray(RIGHT, x1, y1, x2, y2, Right);
   if (y2!=y3)
     ScanEdgeAndStoreInArray(RIGHT, x2, y2, x3, y3, Right);
  };

  // spanfil the the polygon
  for (int y=y1; y<y3; y++)
  {
    if (Left[y] <= Right[y])
      hline(bitmap, Left[y], y, Right[y], col);
  }

  if (y1 > y2)
  {
   int tx=x1, ty=y1;
       x1=x2, y2=y2;
       x2=tx, y2=ty;
       tx=c1, c1=c2, c2=tx;
  }
  if (y1 > y3)
  {
   int tx=x1, ty=y1;
       x1=x3, y2=y3;
       x3=tx, y3=ty;
       tx=c1, c1=c3, c3=tx;
  }
  if (y2 > y3)
  {
   int tx=x2, ty=y2;
       x2=x3, y2=y3;
       x3=tx, y3=ty;
       tx=c2, c2=c3, c3=tx;
  }

  if (x2 == x3)
   return;

  if (x2 < x3)
  {
   ScanGouraudEdgeAndStoreInArray(LEFT, x1, y1, c1, x2, y2, c2, Left,
LeftShade);
   ScanGouraudEdgeAndStoreInArray(RIGHT, x1, y1, c1, x3, y3, c3, Right,
RightShade);
   if (y2!=y3)
     ScanGouraudEdgeAndStoreInArray(LEFT, x2, y2, c2, x3, y3, c3, Left,
LeftShade);
  }
  else
  {
   ScanGouraudEdgeAndStoreInArray(LEFT, x1, y1, c1, x3, y3, c3, Left,
LeftShade);
   ScanGouraudEdgeAndStoreInArray(RIGHT, x1, y1, c1, x2, y2, c2, Right,
RightShade);
   if (y2!=y3)
     ScanGouraudEdgeAndStoreInArray(RIGHT, x2, y2, c2, x3, y3, c3, Right,
RightShade);
  };

  for (int y=y1; y<y3; y++)
  {
    if (Left[y] <= Right[y])
      GouraudHLine(bitmap, Left[y], LeftShade[y], Right[y], RightShade[y], y,
col);
  }

  LoadLightmaps();
  PALETTE pal;
  BITMAP *fuckyou = load_pcx("pal.pcx", pal);
  set_pallete(pal);

/*
     FlatShadedTriangle(screen, 160, 20, 200, 40, 120, 60, 25);
     getch();*/
//*
    GouraudShadedTriangle(screen, 160, 20, 255,
                                  200, 40, 0,
                                  120, 60, 0,
                                  25);
     getch();
//*/
/*  while (!kbhit())
   GouraudShadedTriangle(screen,
                      rand()%320, rand()%200, rand()%255,
                      rand()%320, rand()%200, rand()%255,
                      rand()%320, rand()%200, rand()%255,
                      0);

    getch();

  */
  textmode(C80);

Quote:>you use the pmn method to texturemap (who even uses that),

Actually, the only people who use P, M, and N are people
who read my article, 'cause I coined that terminology.
The truth of the matter is I worked out all of texture
mapping for myself algebraically, and solving the problem
using (u,v)s at vertices seemed like it would be very
clumsy.  (I would have just solved for PMN from the (u,v)s,
then substituted it into the PMN math, then propogated
it all the way through; the PMN math was clearly simpler.)
I know now that you can just multiply by w and divide by
it later, but that wasn't obvious to me when I set out
to derive it from scratch.

Besides, our software perspective texture mapper that takes (u,v)
values at the vertices then goes and finds three vertices
that aren't colinear, and computes the gradients, which
requires at least one divide.  The PMN method allows the
gradients to be computed without any divides, and without
having to clip (u,v) values during clipping.

Whether you want to _use_ u,v,w gradients, instead of
propogating u,v,w values down your edges, is up to you.
I find it much simpler.  It was apparently a great match
for Quake's span clipped polys in theory, except it turned
out they had to clamp the endpoints.

Gradients are also good if you're using regular screenspace
subdivision (e.g. 8 or 16 pixel scanline subdivision).  It
turns out there are some intermediate values you can
compute from the gradients to directly compute the next
8/16-pixel delta value without actually computing (u,v)s,
deltas, and then the shift by 3/4--in fact, it can support
non-power-of-two subdivision efficiently.

Thus, the gradient method is good for fast subdivided
perspective mapping, and the PMN method is, sofar as I know,
the least math to compute the gradients, especially assuming
divides are slow.

Quote:>and there was something else which I thought was wrong.

Quote:>I'll go look at it and write what I found would be hard
>to understand. Here's a tip though, provide some CODE?!

I consider my quake renderer, QMAP, to be a follow-on
educational product to my PCGPE article.  I wrote QMAP
entirely to provide sample code that actually puts it
all together and makes it work.  And I threw in the
derivation of the magic numbers because that's been
the most requested comment that made it back to me.

Quote:>Here's some code I thought you might want to put in it.

The whole point of the PCGPE article was that I derived math
that allows for perfect subpixel/subtexel rendering in a very
easy way (no weird setup at the beginnings of spans and the
top of the polygon), even though I didn't provide any solution
to rendering perspective spans efficiently.

Sean Barrett

Don't bother arguing with Herman, he's a *ing*.