Hi all,

I've been searching for about 4 hours yesterdaynight to see why a 3D
model crashed while drawing on my laptop.
In the end, it came up to this, and then I got no further:

  // Use more efficient drawing
  if(flags&USE_ARRAY_ELEMENTS)
  {
    // Use glArrayElement(); less buggy on ATI laptop?
    int i;
    glBegin(mode);
    for(i=0;i<indices;i++)
    {
      glArrayElement(index[i]);
    }
    glEnd();
  } else
  {
    // Draw more efficiently
    glDrawElements(mode,indices,GL_UNSIGNED_SHORT,index);
  }

I've checked the arrays (checking sizes, checking all passed
parameters, checking for garbage coordinates), but on my ATI Ragepro
16Mb on my laptop, the glDrawElts() crashes (in ATIOGLXX.dll), and
when I do it explicitly with the glArrayElement() for loop, it runs
ok. I'm running Windows XP.

The same code runs ok either way on a Linux PII400/SuSE8.0/nVidia
GF2MX system, and I tested it as well on a PII400/Windows2000/nVidia
GF3 machine.

I'm running out of ideas how to check; should I assume graphics driver
bug, or is there something else I can try? Some facts:
- I'm only using a vertex & 1 texcoord arrays (no multitexture).
- Normal arrays are turned off, but lighting is on (just to minimalize
the situation). Doesn't matter if I turn them on though.
- It crashes when I compile in VC++6 in Debug mode. Release mode works
fine (it seems).

I don't know what glDrawElements() does that my loop doesn't; perhaps
some precaching of stuff or something?

Thanks for any ideas,

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

Dans l'article <3f3315fa.81863743@news.xs4all.nl>, "Ruud van Gaal"
<KILLSPAMruud@marketgraph.nl> a tapot� avec ses petits doigts:

>   {
>     // Draw more efficiently
>     glDrawElements(mode,indices,GL_UNSIGNED_SHORT,index);
>   }
> 
> I've checked the arrays (checking sizes, checking all passed parameters,
> checking for garbage coordinates), but on my ATI Ragepro 16Mb on my
> laptop, the glDrawElts() crashes (in ATIOGLXX.dll), and when I do it
> explicitly with the glArrayElement() for loop, it runs ok. I'm running
> Windows XP.

According to the OpenGL redbook, the third parameter for glDrawElements()
is the type of integer indices in your index array. GL_UNSIGNED_SHORT is
a 16bit index. Maybe your index array is int[], which is 32bits, and so
should be declared as GL_UNSIGNED_INT. This is the only bug that I see
(if you have not checked that already of course), provided you did not
declared your index array as an array of shorts.

-- 
Patrice Mandin
WWW: http://membres.lycos.fr/pmandin/
Programmeur Linux, Atari
Sp�cialit�: D�veloppement, jeux

On Thu, 07 Aug 2003 14:50:13 +0200, Patrice Mandin
<pmandin@caramail-NOSPAM.com> wrote:

>Dans l'article <3f3315fa.81863743@news.xs4all.nl>, "Ruud van Gaal"
><KILLSPAMruud@marketgraph.nl> a tapot� avec ses petits doigts:
>
>>   {
>>     // Draw more efficiently
>>     glDrawElements(mode,indices,GL_UNSIGNED_SHORT,index);
>>   }
>> 
>> I've checked the arrays (checking sizes, checking all passed parameters,
>> checking for garbage coordinates), but on my ATI Ragepro 16Mb on my
>> laptop, the glDrawElts() crashes (in ATIOGLXX.dll), and when I do it
>> explicitly with the glArrayElement() for loop, it runs ok. I'm running
>> Windows XP.
>
>According to the OpenGL redbook, the third parameter for glDrawElements()
>is the type of integer indices in your index array. GL_UNSIGNED_SHORT is
>a 16bit index. Maybe your index array is int[], which is 32bits, and so
>should be declared as GL_UNSIGNED_INT.

Unfortunately, I checked and it's 16-bit. I even printed out sizeof()
and it was 2. Even if it was, you'd expect a lot of 0's, which should
be relatively ok (degenerate triangles, but still).

Thanks for the effort though.


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

On Thu, 07 Aug 2003 17:21:07 GMT, KILLSPAMruud@marketgraph.nl (Ruud
van Gaal) wrote:

>On Thu, 07 Aug 2003 14:50:13 +0200, Patrice Mandin
><pmandin@caramail-NOSPAM.com> wrote:
....
>>According to the OpenGL redbook, the third parameter for glDrawElements()
>>is the type of integer indices in your index array. GL_UNSIGNED_SHORT is
>>a 16bit index. Maybe your index array is int[], which is 32bits, and so
>>should be declared as GL_UNSIGNED_INT.
>
>Unfortunately, I checked and it's 16-bit. I even printed out sizeof()
>and it was 2. Even if it was, you'd expect a lot of 0's, which should
>be relatively ok (degenerate triangles, but still).

To follow up on myself; I've added floating point exceptions.
Even if I limit things to:

glDrawElements(mode,1,GL_UNSIGNED_SHORT,index);

(so just 1 elt, not a bunch), I get a 'floating point exception:
invalid number'. Putting 3 in there also crashes (the '1' isn't even
enough for 1 triangle).
Doing the for loop:
glBegin(mode);
for(i=0;i<indices;i++)glArrayElement(i);
glEnd();

Works perfectly... :(

I'll try a slightly newer gfx driver...
Nope, still the same. Giving up for now. :(


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

KILLSPAMruud@marketgraph.nl (Ruud van Gaal) writes:

>
> I've been searching for about 4 hours yesterdaynight to see why a 3D
> model crashed while drawing on my laptop.
> In the end, it came up to this, and then I got no further:
>

> - It crashes when I compile in VC++6 in Debug mode. Release mode works
> fine (it seems).

This sounds funny, it sort of makes me suspect you have something fishy
in your code....


        Eero

"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
news:3f3315fa.81863743@news.xs4all.nl...

> The same code runs ok either way on a Linux PII400/SuSE8.0/nVidia
> GF2MX system, and I tested it as well on a PII400/Windows2000/nVidia
> GF3 machine.

> - It crashes when I compile in VC++6 in Debug mode. Release mode works
> fine (it seems).

    You say the same code runs fine on those two other machines. Was it
Relaese mode as well? I am asking, because you say that it runs fine in
Release mode on your laptop. Does it run fine in Debug mode on the other
machines? Does running it inside the IDE make a difference?

    If the Release mode would not work fine, I would say that it is a driver
bug -- if the ATI card is in fact the only one crashing. But as it is, it
does seem like there is some glitch in your code, that is only noticed in
Debug mode (note that VC++ allocates data a bit differently in the two build
modes) *but* nVidia drivers/cards can cope with it.

hth
--
jb

(replace y with x if you want to reply by e-mail)

Ruud van Gaal wrote:
> - It crashes when I compile in VC++6 in Debug mode. Release mode works
> fine (it seems).
> 

Whenever you see this, suspect your program.

Think uninitialised variables.

Think uninitialised memory.


-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    Why isn't there mouse-flavored cat food?

On Thu, 07 Aug 2003 23:02:21 GMT, fungus <openglMY@SOCKSartlum.com>
wrote:

>Ruud van Gaal wrote:
>> - It crashes when I compile in VC++6 in Debug mode. Release mode works
>> fine (it seems).
>> 
>
>Whenever you see this, suspect your program.
>
>Think uninitialised variables.
>Think uninitialised memory.

Right, although I ran Purify and it can't find anything (and I've seen
that catch many obscure uninitialised stuff in the past). Although
some things even Purify doesn't catch.

I've come to the point where I get the problem too in Release mode,
and on my Windows/GF3 combination. Although now I catch FPE's.

I'll muddle on, it seems the error is caused elsewhere, not at the
point of crashing... But almost impossible to find.

Thanks,

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

On Fri, 8 Aug 2003 00:34:06 +0200, "Jakob Bieling" <netsurf@gmy.net>
wrote:

>"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
>news:3f3315fa.81863743@news.xs4all.nl...
>
>> The same code runs ok either way on a Linux PII400/SuSE8.0/nVidia
>> GF2MX system, and I tested it as well on a PII400/Windows2000/nVidia
>> GF3 machine.
>
>> - It crashes when I compile in VC++6 in Debug mode. Release mode works
>> fine (it seems).
>
>    You say the same code runs fine on those two other machines. Was it
>Relaese mode as well?

It seems now to also crash on my regular release version in Win2K/GF3.
It disappears in debug mode on my laptop (ATI) once I turn the texture
coordinate array off, and also when I do this in the release mod
Win2K/GF3 environment.

It looks like something's fishy with the texture[coord]s. I can come
up with the following possibilities (I only use 1 layer):
- texture ID is invalid (glIsTexture)
- mipmapping is turned on, but not all levels are defined (how do I
check this?)
- texture coord array is invalid still (although I checked it to be
ok)

Any others anyone can come up with?

Thanks,

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

"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
news:3f34a7c2.184720353@news.xs4all.nl...
> On Fri, 8 Aug 2003 00:34:06 +0200, "Jakob Bieling" <netsurf@gmy.net>
> wrote:
>
> >"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
> >news:3f3315fa.81863743@news.xs4all.nl...
> >
> >> The same code runs ok either way on a Linux PII400/SuSE8.0/nVidia
> >> GF2MX system, and I tested it as well on a PII400/Windows2000/nVidia
> >> GF3 machine.
> >
> >> - It crashes when I compile in VC++6 in Debug mode. Release mode works
> >> fine (it seems).
> >
> >    You say the same code runs fine on those two other machines. Was it
> >Relaese mode as well?
>
> It seems now to also crash on my regular release version in Win2K/GF3.
> It disappears in debug mode on my laptop (ATI) once I turn the texture
> coordinate array off, and also when I do this in the release mod
> Win2K/GF3 environment.
>
> It looks like something's fishy with the texture[coord]s. I can come
> up with the following possibilities (I only use 1 layer):
> - texture ID is invalid (glIsTexture)
> - mipmapping is turned on, but not all levels are defined (how do I
> check this?)

    Did you use gluBuild2DMipmaps? In this case you should have all mipmap
levels. Otherwise, you should check your own code. You probably should
reduce your image until it is 1 pixel in width and/or height. So starting
with a 128*64 image, the next one would be 64*32, then 32*16, then 16*8,
then 8*4, then 4*2 and the last one is 2*1. This should include 'all' mipmap
levels.

> - texture coord array is invalid still (although I checked it to be
> ok)

    You could take a break from that part (or from programming altogether),
do something else, and look over it tomorrow. It always helped me when I was
stuck like that.

hth
--
jb

(replace y with x if you want to reply by e-mail)

On Fri, 8 Aug 2003 16:01:37 +0200, "Jakob Bieling" <netsurf@gmy.net>
wrote:

>"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
>news:3f34a7c2.184720353@news.xs4all.nl...
....
>> It looks like something's fishy with the texture[coord]s. I can come
>> up with the following possibilities (I only use 1 layer):
>> - texture ID is invalid (glIsTexture)
>> - mipmapping is turned on, but not all levels are defined (how do I
>> check this?)
>
>    Did you use gluBuild2DMipmaps?

Yep. Perhaps something with the texcoord array still, although it
tends to vary whether it crashes or not at some points.
Now when I allocate a BIG texcoord array, things seem better. I'll dig
on.

>> - texture coord array is invalid still (although I checked it to be
>> ok)
>
>    You could take a break from that part (or from programming altogether),
>do something else, and look over it tomorrow. It always helped me when I was
>stuck like that.

I know. :) Though it's getting weekend, and it just gives such a bad
feeling having to walk around in the entire weekend thinking about
what it might be. I just can't resists, not as this point yet.
But it certainly now & then helps. It's just that the whole thing
crashes, which means the app's useless at this point.


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

On Fri, 08 Aug 2003 17:08:03 GMT, KILLSPAMruud@marketgraph.nl (Ruud
van Gaal) wrote:

....
>>> It looks like something's fishy with the texture[coord]s. I can come
>>> up with the following possibilities (I only use 1 layer):
>>> - texture ID is invalid (glIsTexture)
>>> - mipmapping is turned on, but not all levels are defined (how do I
>>> check this?)
>>> - texture coord array is invalid still (although I checked it to be
>>> ok)

Getting closer there. Checking the glTexCoordPointer() stride with
glGetIntegerv(GL_TEXTURE_COORD_ARRAY_STRIDE) reveals that it is 2
after I set it, then 4 just before drawing.

That explains why if I allocate big buffers it goes ok, but the
narrow-allocated original texcoord buffers don't.

Weird though that the default stride is 4, I'd expect 2 (UV mapping).
Now on to detecting WHEN stride reverts back to 4. I'll report my
findings (as it happens on both ATI and nVidia it seems, and it's
quite a dragon).


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

On Fri, 08 Aug 2003 17:39:02 GMT, KILLSPAMruud@marketgraph.nl (Ruud
van Gaal) wrote:

....
>Getting closer there. Checking the glTexCoordPointer() stride with
>glGetIntegerv(GL_TEXTURE_COORD_ARRAY_STRIDE) reveals that it is 2
>after I set it, then 4 just before drawing.

I'm sorry, that should've been GL_TEXTURE_COORD_ARRAY_SIZE.
Meaning #coords per array elt.

Stride stays 0 as it should.


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

On Fri, 08 Aug 2003 17:41:51 GMT, KILLSPAMruud@marketgraph.nl (Ruud
van Gaal) wrote:

>On Fri, 08 Aug 2003 17:39:02 GMT, KILLSPAMruud@marketgraph.nl (Ruud
>van Gaal) wrote:
>
>...
>>Getting closer there. Checking the glTexCoordPointer() stride with
>>glGetIntegerv(GL_TEXTURE_COORD_ARRAY_STRIDE) reveals that it is 2
>>after I set it, then 4 just before drawing.
>
>I'm sorry, that should've been GL_TEXTURE_COORD_ARRAY_SIZE.
>Meaning #coords per array elt.

Found it!!!!

It wasn't the texcoord array size, that was just because I was reading
the wrong texture unit (the code is multitexturing, turned off all
texture units beside texunit 0, and right after that I mistakingly got
the texture coord array size of texunit 1).

Then I found that a glLockArraysEXT() was giving problems. First it
looked like perhaps it was an APIENTRY missing (giving such nice
unpredictable stack trouble), but it turned out I was feeding a count
like:

glLockArraysEXT(0,geob->GetVertices())

But GetVertices() actually returned the number of vertices being
drawn, not those in the array! So it was quite a bit high, and at
glDrawElts() time, it gave errors, sometimes, depending on whether a
page fault appeared.

So that was it, phew. :)

Thanks everyone for the help. Sometimes it's hard to keep going.

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

"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
news:3f35eca7.202356913@news.xs4all.nl...

> So that was it, phew. :)
>
> Thanks everyone for the help. Sometimes it's hard to keep going.


    Coolies, glad you got it fixed. Was it for Racer? Just curious ;)
--
jb

(replace y with x if you want to reply by e-mail)

On Fri, 8 Aug 2003 21:15:22 +0200, "Jakob Bieling" <netsurf@gmy.net>
wrote:

>"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
>news:3f35eca7.202356913@news.xs4all.nl...
>
>> So that was it, phew. :)
>>
>> Thanks everyone for the help. Sometimes it's hard to keep going.
>
>
>    Coolies, glad you got it fixed. Was it for Racer? Just curious ;)

Yep. :) The new rendering engine kept crashing with varying models,
varying computers etc. It's all still chunky but I might just release
a super-alpha test-your-shaders thingy (quite a lot is still in
shambles because of the new graphics engine working quite
differently).


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