vbo+point sprites+ati=need for valium

yet again many wasted hours trying to figure out why a simple demo works fine and the same code wont work for me.

the problem: point sprites refused to be sprites and instead remained a solid color picked from a corner of the texture. so it seems that texture coordinate replacement was simply not working. after a long time i wanted to try it with va instead of vbo, with the result of it freezing for a few seconds, followed by my monitor telling me about a lost signal. ups, guess it didnt like the color pointer with a value of 12 (one would expect a simple access violation). fixing that didnt really help and caused the same problem, which i didnt bother to track down further because rebooting after every test run is kind of time consuming.

anyway, using good old begin/end with gl_points resulted in the point sprites being displayed correctly.

using a radeon 9800 with cat 4.2

part of the code (without most of the point stuff, as its working in immediate mode that part is correct):

glTexEnvf(GL_POINT_SPRITE_ARB, GL_COORD_REPLACE_ARB, 1);

glBindBufferARB(GL_ARRAY_BUFFER_ARB, VBuffer);
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);
glVertexPointer(3, GL_FLOAT, sizeof(Particle), 0);
glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(Particle), (void*)12);

glDrawArrays(GL_POINTS, 0, numParticles);

the va version looked something like this (with particle being 3 floats + 4 bytes)

glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);
glVertexPointer(3, GL_FLOAT, sizeof(Particle), Particles);
unsigned char* PartCol=(unsigned char*)Particles;
PartCol+=12;
glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(Particle), PartCol);

that version as mentioned caused the program to freeze and a signal lost after a few seconds requiring a reboot (the usual alt+tab, shift+f5 combination didnt work)

can anyone confirm that point sprites are not working with vbo on ati cards? and if so, is ANYTHING working with vbo on ati cards, because i get the feeling that when it comes to vbo ati is screwing up at every possible opportunity. especially embarassing as it seems that the arb went more with their vao version rather than nvidias var.

Have you tried the same code on other hardware?

Mail me a runnable demo if you like, and I’ll try it on my work GF-FX, and GF4.

Nutty

hmm vbo is really working fine for me (radeon 9700pro…) running under cataclyst 4.2. and btw the rebooting can be prevented if VPU recover is enabled… (worked in most instances when i made some mistakes with the sizes of my arrays and indexing bad vertices… those errors formerly generated, what you did describe, before vpu recover was in the drivers)
btw have you tried your app without vbo (just normal vertex arrays)?

[This message has been edited by Chuck0 (edited 03-02-2004).]

hmm… vpu recover is one of the few features i have enabled. didnt seem to help here.

well, my problems with vbo are the point sprites and that vertex data thats not 4byte aligned is horribly slow. that sounds fine from a “it has to be converted/realigned” point of view, but thinking about it doesnt explain how it can be 100times slower than the same thing with vertex arrays. and as nvidia cards dont have that problem i cant accept it as “technically impossible”, unless nvidia has a special black magic dpt. doing occult rituals in the basement (maybe thats what the voodoo guys were hired for?)

anyway: http://festini.device-zero.de/Programming/Downloads/JSFramework.zip

using vbo for the particles per default. as texture coords dont work you will most likely see nothing (alpha at the corner is 0). pointmode in the console will change between immediate mode and vbo to draw the points.

console (depending on your layout) should be ^ or ~. config.cfg contains more keys and console commands are listed (page up/down to scroll).

Just a comment about point sprites.
I experimented them with Cat 3.9 and I had serious problems when I used ARB pixel programs : the ATi card crashed (especially when the sprites were near the border of the viewport).
Maybe, this “point” is corrected in Cat 4.2 ?

Paul

Originally posted by Sernine:
[b]Just a comment about point sprites.
I experimented them with Cat 3.9 and I had serious problems when I used ARB pixel programs : the ATi card crashed (especially when the sprites were near the border of the viewport).
Maybe, this “point” is corrected in Cat 4.2 ?

Paul[/b]

or maybe not. i assume you meant fragment_programs? though they have been disabled at this point in general im using them for other parts. maybe later i’ll feel more like rebooting a dozen times and experiment with that a bit more.

which reminds me, that even my old nvidia hard some weird behaviour with vbo and vertex_program (basically normal pointer would only work if i DIDNT enable normal pointer, else it simply crashed).

how bad have ati drivers been before they got “much better”?

edit:
ok, i just dropped the color pointer and tried again. same result with va, so it is NOT just failing with vbo, but plain arrays too. so i checked the point_sprite spec if it says anything like “this only works in immediate mode” and if there is such a passage i missed it. then i checked if its just luck and the driver officially doesnt support point sprites at all. it does (or rather: it should).

so now im back to suspecting a mistake in my code, that explains why immediate mode works and va/vbo wont generate correct tex coords. why? simply because a bug like that cant possibly get past QA (if it does that would definitely be my first and last ati).

[This message has been edited by Jared (edited 03-03-2004).]

well, my problems with vbo are the point sprites and that vertex data thats not 4byte aligned is horribly slow. that sounds fine from a “it has to be converted/realigned” point of view, but thinking about it doesnt explain how it can be 100times slower than the same thing with vertex arrays. and as nvidia cards dont have that problem i cant accept it as “technically impossible”, unless nvidia has a special black magic dpt. doing occult rituals in the basement (maybe thats what the voodoo guys were hired for?)

It’s not a question of “technically impossible”. It’s simply one of the limitations that ATi built into the hardware to make implementing various pieces of it simpler. You can either ignore it and run slowly or you can deal with it on your end. Complaining about a hardware problem that clearly isn’t going to be fixed until new hardware comes around (and possibly not even then) isn’t helping anyone. And, if you feel the need to complain, complain to ATi, and maybe they will make more capable hardware in the future.