Spring RTS Engine

Nope - nothing...

Well... that's a giant wtf. This just keeps getting weirder.

Hrmm. OK, try this. Solid alpha background. Renders as white circles on my hardware.

No - nothing...

So do I get it right that it has to be something about the FBOs which breaks it? I did some noobish search about that and read a vague but interesting comment from someone who fixed a FBO problem by sort of un- and rebinding the FBO before reading it out by the shader (don't know if this is in any way applicable here)...

Another comment was about explicitly saying what kind of "texture" something gets written into. In the given case it seemed like when not saying so the driver might pick a 16bit image where the following operations want a 24bit one (again I don't know if this is in any way useful)...

I also stumbled upon this - maybe it contains some ATI specific magic...
http://developer.amd.com/media/gpu_asse ... bjects.pdf

No, it seems to be reading the various FBOs OK, or you would never see anything. It's failing on the very last stages of a fairly complex chain of events, using several FBOs and textures.

Moreover... I can't emphasize this enough... every single one of these runs over here as described. The problem's very specific to either your particular hardware, or to ATi's drivers for GLSL / OpenGL, which we all know are pretty flaky (but this is ridiculous, imo- this whole series could be used as nVidia propaganda at this point).

However, your theory that it has something to do with the depth of the textures might have merit. So here's a version where I've excluded the floating-point texture, it no longer gets even picked up by the fragment shader. It wasn't getting used before... but perhaps even having a reference to it causes the problem.

Nope - still no particles visible at all...

Hmm. Out of ideas atm. This version produces white squares, yes?

If yes, then the problem is that the texture being read must have an alpha that comes out zero. Which means that there should be all sorts of other major problems with the behavior of the particle system.

But if they're all drifting upwards, then that's all working, which means that the whole situation is impossible, unless the problem's with textured point objects in general- you've several times reported solid squares when you should have seen non-solids.

Does the snow Gadget work on your hardware?

Yeah - I get white, upwards drifting squares...

OK. Well, that means that there's a pretty fundamental bork here. I'm looking at the options for what can be done with point objects.

Hrmm. Let's try this one. What I changed shouldn't matter. But the only other thing I can think of is that the texture coordinates for the particles are getting screwed up... in which case, I guess I can force that when building the display lists, see if that works.

This is the first version that has worked for me argh.

Hardware??? Please, just tell me it's ATi, preferably HD series.

Sorry, nvidia 9600 GT. Driver version: 8.15.11.9038

Okay - tested it on a PC with a HD4830 now but still no visible particles...

I would choose a new accronym, preferably one that doesnt stand for partners of prisoners, or a class of extremely toxic pollutants.

OK, one last try with pure point objects. I'm passing some additional OpenGL state stuff before firing up the particle system, which may cure the problem (after all, ATi folks reported that the snow code works, and this is about the only thing that's different). If this doesn't work, I'll implement a quad billboard version as a safe fallback for ATi hardware.

Hmmm no - doesn't work...

Well, that's that, I'll have to write a quad billboard fallback for ATi, then.

Well, hmm.

Kinda got the basics of doing billboarded quads working, but there are several serious problems to work out:

The final transformation matrix is wrong, if I turn gl.Billboard on.

What should be Y is being treated as Z (and negative, to boot), dunno if X and Z are similarly crossed. The behavior of the particles is technically correct up to that point in the process. If anybody knows what's wrong, please fix it, or explain really thoroughly what's wrong- the matrix stuff is still very confusing to me, especially when it borks this badly, and I am not sure how to proceed here, other than it's apparent that I need to rotate the resulting matrix before outputting a final gl_Position.

Other than that... on my hardware, it's working again, after 5 hours of work, and seems to be operating correctly- stuff like scale, etc. is working again, which was all lots of fun.

If I can get billboard working... and it works on ATi... then this is almost as fast as points, because it's still using the same GPU-driven physics, etc., and frankly, after hearing Forb's tale, my inclination is to say screw it and dump the points, it's been so much trouble, and the only hardware it's been a massive speed boon on is mine

Anyhow, if anybody wants to look at the billboard issue, it's commented out at the very end of the application. I would really appreciate some help on that, I still only vaguely understand how the transforms work.

24 works, but it doesn't even come close to looking as remotely nice as 23 did.

THe bubbles in 24 act like sprites, but the thing is, if I make the camera top down 90 degrees, I can't even see them hardly. If I move the camera horizontally, they look real good again.

looking at 23, I can see why you were excited about this. I had shittons of particles on screen and not even a hint of a slowdown.

I'd call it a success... I'll try to have a look at your code later as I know matrix calculations in principle. Maybe I can sort out how to rotate them towards the camera...