Re: how to add assembler?

[Erik <br0ke@math.smsu.edu>]

On 17-Oct-99 Rick Genter wrote:
> ----- Original Message -----
> From: Erik <br0ke@math.smsu.edu>
> To: <linuxgames@sunsite.auc.dk>
> Sent: Sunday, October 17, 1999 12:10 PM
> Subject: Re: how to add assembler?
> 
> 
>> but games like starcraft represent a 3d world, so it should be fairly easy
> to
>> do in true 3d, using opengl. It'd simplify things like faking altitude and
>> drawing by altitude so tanks don't appear over battlecruisers.
> 
> Every so often someone writes something like this and it makes my blood
> boil. Not to single you out Erik, because I see this a lot, both explicit
> and implicit.
> 
> There is NOTHING easy about a commercial game. Period. And, while on the
> surface, your statement makes sense, let me tell you that to do a game like
> StarCraft in 3D would be MUCH more complicated than to do it in 2D.
> 

never said commercial games are easy :) I find it easier to make 3d like things
using opengl than a 2d api. OpenGL was designed to simplify putting 3d things on
the screen, and I think it does an excellant job of it.  It's not a magic
bullet, you're still on your own for special effects, collision detection, and
all of those details, but it provides a way to put things on the screen. If
given the choice between implementing a 3d-ish environment in either OGL or as
a 2d framebuffer, I would pick opengl. I make a model, set its normals, tell
opengl to put my model there, and it does it. In 2d, I'd either have to render
a series of possable facings, figure out which one I need to draw, then blit
it in the right order (I can't blit a flying thing before a land thing or my
tank would be ontop of my battlecruiser), and obey the alpha channel. All of
these things are automatic in opengl.  The issues I mentioned are handled
automagically in OGL by zbuffers that are already in place. For lighting, you
need to calculate all the normals, then OGL handles that automagically (but
very crudely, most of the eye poppers don't use ogl lighting, the write their
own lighting routine, which can be an ugly nasty endeavor).

I'd imagine the internals of starcraft have all objects having 3 dimensional
placement coordinates, [x,y,z], and a facing. 

In opengl, I'd have a single list of my objects. I'd traverse this list and for
each object, I'd do something in the spirit of
        for(i=0;i<object_count;++i)
        {
                glPushMatrix();
                glTranslatef(obj->x,obj->y,obj->z);
                glRotate3f(obj->heading,0,1,0);
                glCallList(obj->model_number);
                glPopMatrix();
        }
Were I to render in a 2d api, I'd would do something close to this
        sortAltitudes();        /* re-arrange my list in ascending altidude */
        for(i=0;i<object_count;++i)
        {
                int facing = (int)obj->heading/10;
                blit(obj->x+(obj->z*sin(offset_from_z)), obj->y,
                        image[obj->model][facing],bitmask[obj->model][facing);
        }

Now I have to write a function sortAltitudes() for correct zbuffering, which
can be implemented fairly effeciently as a bucket sort or partition sort. I
also have to implement (or hunt down) a blit that likes bitmasks. And probably
the real killer is instead of generating one model with one skin, now I have to
make a model and skin, then I have to make 36 renders in full color with
lighting, save them all, make 36 renders of solidcolor to make the bitmasks,
and at startup, I have to load these 72 images into memory. And with only 36
rotations, there'll be a noticable quantitization of rotation. I think I'd
rather make 1 model, one skin, not sort, not write a blitter, and just use ogl
:)
        


> Why?
> 
> Because expectations would be higher. In a 2D game, you can get away with a
> single fixed light source, occasional graphics glitches (drawing order
> problems), and minimal effects. In a 3D game you HAVE to do colored

You're virtually forced to use fixed light source in 2d. You have that option
in 3d, but it'd be negligible to make the light source moving, the hard part
would be accuratly shadowing it :)
You can't get away with letting graphic glitches in. I'd rather play a game
without glitches than one with glitches. My understanding is that the glitches
seen today aren't because the people don't mind them or the coders don't care,
it's cuz the coders get put on unrealistic schedules, lesser glitches get
backburnered and eventually ignored because they got bad glitches and a
deadline.

> lighting, you HAVE to support full translucency, you HAVE to have killer
> special effects, or you don't have a successful commercial game. And even if

I'd sooner shell out money for a simple but bugless 3d game than an amazing but
buggy 2d game :) Full translucency, colored lights, special effects, those
don't mean jack to game play. They're just eye candy to grab attention, that
don't make the game worth playing.

> you don't tell anyone it's 3D, they'll know; you can't get the polygon count
> high enough for the models to have truly rounded edges like you can when you
> render for a 2D game. So you have to make up for the lower polygon count by

Not yet, but many games are remarkebly close. q3 has pretty curved surfaces, I
think by tesselating bezier surfaces or nurbs. UT demo is well crafted and
difficult to find where under-tesselation gives it that polygon feel.

> having such dazzling special effects that the gamer doesn't notice the
> unrounded edges.
> 
> I don't mean to jump down anyone's throat, but being a former commercial
> game developer, I feel the game developer's pains when someone says "why
> didn't you *just* do <feature X>?", knowing that <feature X>, while on the
> surface simple, probably means 6 person-months of work.
> 

I think for most 3d or semi-3d apps, using something like ogl from the
beginning reduces 'time to market'. :)

> Rick
> --
> Rick Genter
> Director, Software Development
> iBasis, Inc.
> <http://www.ibasis.net>
> <mailto:rgenter@ibasis.net>
> 

        -Erik <br0ke@math.smsu.edu> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.