Spring RTS Engine

Nope - particles still are too shy to show up...

Eek, that's not good. We must be getting a zero result for the alpha or something else is going horribly wrong, like the texture coordinates aren't available.

OK, let's try this. I see white circles.

Sorry - still nothing is visible...

OK, so it's not the alpha, so it's either the texture, or the texture coordinates. I'm going to try the texture theory first. You should see funny-looking things, I'm using the LOS texture, since I know that it's reading that.

Yup - I now get the white particles again...

OK. Are they all white, or funny shapes? Important.

It's just white squares again...

OK.

Let's try this, then, I have a theory. Perhaps mixing floating-point textures with standard ARGB is causing the problem... so, I just made losTex ARGB, with filtering still clamped because I don't want Spring to screw that up by trying to build mipmaps. If that works, then perhaps I need to re-write part of this and move all of the floating-point operations to the vertex shader... or blit all of the texturemaps to FBO'd textures with clamping and explicit color ranges. Either way, yuck.

It still works - still just white squares...

Hrmm. All white squares. OK, let's try this, I want to eliminate one possible wild-goose-chase before I make final changes. My working theory is that mixing floating-point textures with non-floating-point is a problem, or that it's caused by mipmap filtering. If it's mipmap filtering, all of the textures have to reside in textures built via FBO to be totally consistent... if it's mixed number ranges, then I have to move all floating-point texture reads to the vertex shader side, as LOS is now using ARGB instead of a float texture.

The squares should now be blue-green.

I looked, and I guess we can set the filtering up when the texture's loaded. So, here's one with it set to "nearest", just like the others. In theory, you should see bubbles now, because all of the textures use the same filtering settings and are all RGBA. In theory that might address the problem. In theory.

Argh wrote: BUBBLE_POPS14.sdz

Ok - I do get those turqoise squares but with a minor side effect:
After the game begins they aren't really squares but the right half of them is missing. Over a few seconds this part "fills up" though and in the end they become squares again and seem to stay that way (-> see the "bluerain" attachments)...

Argh wrote: BUBBLE_POPS15.sdz

Here the particles are invisible again. The LOS texture looks the same as for POPS14.sdz though...

OK, so basically, every time I try to access the main texture, rather than one of the FBO textures, things fail on ATi. Interesting.

OK, I wrote a FBO version, so now all of the color textures are stored in a FBO with precisely the same settings as the LOS texture. The diagnostic window should show a copy of the first texture I "blitted" to the FBO storing it.

did I forgot to tell you, that old ATIs fail if only either the vertex OR the fragment shader part is defined?

Master-Athmos is using a pretty new ATi, IIRC.

And yeah, I didn't know that, thanks for letting me know about this. I'll correct it for the next iteration. Is it OK to just leave the vertex shader empty, or will it fail if I don't provide a transform step?

[EDIT]Nevermind... yes, you must define gl_Position...[/EDIT]

OK, that issue is fixed.

Argh wrote:Master-Athmos is using a pretty new ATi, IIRC.

I guess he said that with manolo_ in mind...

Argh wrote:BUBBLE_POPS17.sdz

Well we've some progress. The particles still won't show up but the LOS "preview" now shows a bubble...

That's not really the progress I had in mind. It means that it's writing to the FBO, but can't read it in the shader. OK, let's try this... I put an explicit texture-coordinate step into the vertex side of the final shader.

Nothing new - no particles...

OK, let's remove the LOS stuff, and comment out that whole bit, and just load a simple textured point. Time to go backwards here, this is totally bizarro.