rec.autos.simulators

 No, I didn't know that! :0)

<snip>

  Great explanation, thanks.  I'm understanding it better now.

  I think I've got it***ed now for the most part.  I had this:
    glTexParameteri %GL_TEXTURE_2D,%GL_TEXTURE_MAG_FILTER,%GL_LINEAR
    glTexParameteri %GL_TEXTURE_2D,%GL_TEXTURE_MIN_FILTER,%GL_LINEAR

  This was causing the textures to do exactly what you just said.  By changing
the last parameter to GL_NEAREST (disable the texture smoothing), the problem
almost completely disappeared because it wasn't try to blend anything at all.
Now, there's an occasional flash once in awhile, but for the most part, the
problem's gone.  I'll get into the clamping and blending next and see how it
goes now that I understand much better how this works.  Thanks a ton :0)

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://www.racesimcentral.net/

My little car sim screenshots:
http://www.racesimcentral.net/

...

Heh, that's not clamping, that's the opposite. Try:

   glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_CLAMP

or if you're in luck:

   glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_CLAMP_TO_EDGE

Quite glaringly wrong. ;-)

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/

  Hehe...  I meant to post the GL_CLAMP version instead :-)  The
GL_CLAMP_TO_EDGE isn't in my header file though :-(

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

Very true. Great stuff.

Then you probably also have multiple GOB1 chunks; a GOB1 is a geob,
which is an object within the geode (the entire file, so to say).
Different materials often (if not always) use a separate GOB1 chunk,
which uses its own INDI chunk (which is just part of it all; you also
will have a VERT chunk for the vertex data etc).

So:
- A model = a geode
- A geode = 1 or more geobs
- A geob = vertex/normal/texcoord/index data

It gets worse with my own DOF files, as there may be multiple bursts
in one geob, but that seems unused in 99% (if not 100%) of the DOF
files out there.

It's really no different from good solid C coding, but a bit more
elegantly put.
myObject->function(x,y) is what you would write in C as:
objFunction(myObject,x,y)

It's just better coupled, so data and code are mixed in 1 object,
instead of leaving that issue up to the code.

It's not, not the basic stuff. Forget templates for a while, forget
multiple inheritance (I once wrote a compiler, studied multiple
inheritance, then forgot about it for ever more, since it is SO
complex to implement, it can lead only to bugs).

But if you do do single inheritance, use a virtual destructor in your
base class. Remember that. :)

You're welcome.

That was what I was talking about. Basically repeating (as you did
before) means just chopping of the integer part and using the decimal
part for the coordinates. Near the edges, it will wrap, which you
don't want, but you want it to clamp instead, so 1.001 would become
1.0, instead of 0.001.

DX and OpenGL are largely the same, DX just came about 10 years later
and took 8 versions to get up to speed. :)
After knowing OpenGL, reading a D3D book will almost get you started
on OpenGL things as well, since most parameters look the same, it's
just with D3D you have to type 2x or 3x more to get the same thing
done. And don't forget that for DX9 you'll have a ball converting your
stuff to the new API. ;-)

...

#define GL_CLAMP_TO_EDGE                  0x812F

I'm sure though you cannot just use this, even if it might work.
There's an extension you have to check for.

Since you created the dots yourself, why not do a triangle strip (if
you're not already doing so)? That will ensure you have correctly
shared vertex data.

It's really quite simple in fact; the basic problems are just twofold;
one is creating a shader sort key from the shader's properties, and
the other is making good use of multitexturing when possible.
Basically you have:
struct RenderData
{
  float *vertexData;
  float *normalData;
  //etc
  int sortkey;
You put everything you want to draw in a big list, quicksort on
sortkey, then render in passes. The passes are walked piece by piece,
and only flushed when a pass can't be added to the previous pass.

Works for Quake. :)

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/

And programs. :)

  Hmm....  Not sure how many GOB1's there were.  I haven't changed the loader
much from the beginning.  Just was trying to get the triangles drawn without
worrying about textures and all that (even though you told me it's easier to do
it all at once :-)).  I'm not too swift with data structures yet (just got some
vector functions running with pointers last night done as an experiment, pretty
cool stuff.)

 What I'm doing is scanning for nothing but INDI and VERT chunks.  Being a
rookie, I actually scan the file four times when loading it (slooowwww.....)
First pass is to find the number of INDI chunks.  Second pass loads all those
indicies, making sure to set them back to 0 (or 1?) at each chunk.  Once I did
that, some of the little test models with more than one INDI chunk would
actually load correctly.  The third pass finds the total number of VERT chunks,
and the fourth loads the vertices the same basic way.

 lol  If I try to load one of the Porche 911's from SCGT I get the rear plate
and exhaust pipes only :-)  The other cars turn into a big mess, so something's
wrong.  Still, I would think that even though the INDI chunks might be in
different geobs, they'd still have the same indice values.  Maybe not?  It's
possible that I'm resetting my "indice counter" inappropriately, but it's hard
to tell because the simple test models will load.

Actually, now that I think about it, there were some exceptions to that...
Seems that things would only work if the number of indicies was an odd or even
number (can't recall which), or something like that.

  Oh, ok..  Maybe it's something I can learn then (although I doubt I could
write a compiler!!! Geeze...lol)  I look at the C++ primer in Lamothe's "Tricks
of the Windows Game Programming Gurus" from time to time to get the (very)
basic gist of things in my head.  I'm just messing with pointers now for the
first time.  Maybe after getting a better grip of those along with data
structures and such, I could move on to C++.  Maybe....  Just maybe ;-)  

  >>Perhaps I ought to take up some basic C++?  Is

Ok..  LaMothe says the same thing in his book...  Over and over :0)  Otherwise
you don't deallocate the memory and get leaks, right?  (among a million other
GPF inducing reasons, probably.)

  Actually, I just turned the MAG/MIN_?? filters to GL_LINEAR for the skies.
That got rid of the seams pretty much entirely, save for an occasional flash.
I'll have to mess more with that to get it working as you and Jim described.

 Oh brother....  lol  

 Thanks..  I'll keep it around just in case.

  Ok, I'll try that.  Should be a touch faster than quads anyway, right?
Still, it seems to me that my quads would share vertices the same way, since
they're defined two vertices at a time...

 Man, I've got to catch up on data structures!  lol  Can you believe I don't
use ANY user defined types or unions in my stuff?  I've saved all this, will
have to come back to it when my brain catches up to this point. :-P

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

...

I would suggest that you use the chunk length to seek onto the next
chunk, but I won't; there are some old DOF files out there that have
bad chunk lengths for one of those ID's (GOB1 probably, being the most
problematic one).
Anyway, after 1 pass it should be in the cache anyway, so it shouldn't
be that bad; although MS-Word seems to take a LONG time loading just a
1K .cpp file. :( (but that's MS-Word; I have absolutely no respect for
Windows' caching scheme; when playing a game which requires a lot of
memory, my swap file grows; when letting it sit and do nothing all
night, the next day it didn't take the chance to clean up some of its
swap mess, sigh).

Should be ok, if every VERT chunk is tied to the
preceeding/postceeding INDI chunk. Printing out counts would give you
an idea why less polygons are painted than you expect (btw Modeler
will give you the #polygons with 'Information').

...

Pointers are nice but are also the source of why Pascal programs
generally crash less than C programs. It's so easy to have a pointer
to garbage. :)

There's no life without pointers (well, references are nice and can
avoid pointers, but to grasp that you need to be acquainted with
pointers).

A memory leak is no reason for a GPF, and memory IS deallocated (well,
the original class' memory), it's just that the destructor of the base
class(es) isn't called, like:
class A
{
  void *p;
 public:
  A(){ p=allocate_1Mb_chunk(); }
  ~A(){ free(p);
class B: public A
{
  B(){ }
  ~B();

Then if you do:
B *pB=new B();
delete pB;

Then ~A() won't be called; so you're left with unfreed memory in this
case (p). And sometimes worse is when A() allocates other objects that
do system-wide damage (opening DirectSound but not closing it on Win98
seems to be deadly).
Getting a bit offtopic here. :)

Yes, use linear; nearest filtering just looks like it was software
rendered; yugh! But wrapping should be turned of; use GL_CLAMP. At
least, that's mostly how these skies are modeled; tiling different
textures is quite a big field once you get into it; just try searching
for 'clipmapping'.

Ah, it's a quad list? Then it's ok too. It's just quads get converted
to tris anyway on today's cards.

Really, without these kinds of data structures it's like coding in
assembly; everything is just a location somewhere. Only divide &
conquer will help in reaching new heights in programming. Meaning data
structures are essential for complex programming, which car sim
programming obviously is, beyond RARS' force generation scheme
(however wonderful).

To stay ontopic; what a nice car just drove by! :)

Ruud van Gaal
Free car sim  : http://www.marketgraph.nl/gallery/racer/
Pencil art    : http://www.marketgraph.nl/gallery/