🔒 Locked

Rendering - Particle Phenomenon on Windows 7

Started by Catmull Dog Aug 27, 2012 at 5:48 PM 5 replies 1.2k views

Original Post

Aug 27, 2012 at 5:48 PM

I noticed that when I render without calling glClear on each frame I get a flickering strobe-like effect in Windows 7. I took a snapshot which seems to show what is happening - it looks like it's using sprites with logical AND instead of XOR. It might be the graphics card (nVidia Quadro 2000M) or a setting of some kind.

I noticed I had to change my rendering slightly to accomodate Windows 7 originally (namely, to save the DC when the window is created and not use the one returned by glBeginPaint), but never knew for sure what changed between that and XP.

Do you have any idea what this observed effect is or how to restore smoother rendering? It looks ok in normal mode and is only an issue when I try to let objects trace out a path by not clearing between frames.

Thanks in advance,

CRD

Seabolt

Aug 27, 2012 at 6:39 PM

This is because you're outputting to a surface without clearing that surface.

First make sure you're actually calling glClear with a valid clear color, second try using InvalidateRect on the client rect (GetClientRect()) to force a change.

Catmull Dog

Aug 27, 2012 at 6:44 PM

Thanks Seabolt. I thought InvalidateRect was GDI but don't have the code in front of me. Wondering why the behavior is different on different cards/OS.

In this case I want the particles to leave smooth trails versus having it staggered by its own border not being invisible so I'm intentionally not calling clear.

Seabolt

Aug 27, 2012 at 9:07 PM

if you're looking for smooth trails you have a couple of steps that you need to do, and you should still call clear

First when you emit a particle, clip it straight to world space. This way as the emitter moves, the particle will remain where it was emitted and not "attached" to the emitter.

Second, you need to depth sort your particles to remove the border from the pixels. What's happening is that the alpha in particle image is overlapping the previous particle, but because it's being drawn before the particle that should be under it, the alpha blend will blend with the color before it, which in this case, is the screen.

swiftcoder

Aug 27, 2012 at 10:59 PM

I noticed that when I render without calling glClear

The big question in my mind, is 'why?'

You should be calling glClear every frame. In a modern double-buffered (or even triple-buffered) world, it is almost impossible to guarantee that you are rendering to the same buffer every frame, let alone doing so while syncing to the refresh rate.

If you want to maintain short trails, just keep track of a few past locations, and draw objects there as well. For image-based trails, maintain your own compositing buffer in an FBO.

Catmull Dog

Aug 28, 2012 at 1:39 PM

For years I've had a user-controlled boolean that wraps around the call to clear.

I'm not here to debate whether this is right, I'm wondering why behavior has changed on Windows 7 and/or with my graphics card.

It may indeed be Alpha-related.

swiftcoder

Aug 28, 2012 at 7:58 PM

I'm not here to debate whether this is right, I'm wondering why behavior has changed on Windows 7 and/or with my graphics card.

*shrugs* undocumented behaviour often changes behind the scenes - which is why you shouldn't rely on it.

If you can find a written guarantee in the documentation that this should work the way you are used to it working, then Windows 7 or your GPU driver introduced a bug. Otherwise, they merely changed implementation-defined behaviour, and your program didn't conform to the standard to begin with.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.