Transparent Window Demo

It seems like i’ve seen posts asking about this kind of thing for a long time, but with no resolutions. So I decided to try my hand at it.

It works nicely on the cards I have at hand. This is a Windoze 2000/XP only demo.

Sorry, there is no source with it yet. The source is still unclean.

Download

Let me know what you think :wink:

Regards,

Dude

Woah ! Superb !

Your splash screen is a bit misleading, first I though ‘hey, is that GL stuff ?’ :slight_smile:

Maybe I ask for too much, but is there any chance to actually blend the spheres above the windows desktop , like your ‘about’ screen ? The ‘transparent’ mode only make the mouse click trought the spheres.

Win2000, Gefore3ti200.

Very interesting, I would really like to see the sources, even if it is ugly as hell.

Congratulations !

Excellent work dude!!! How did you make it?

yooyo

Originally posted by yooyo:
[b]Excellent work dude!!! How did you make it?

yooyo[/b]
My guess: Render to an RGBA pbuffer, readback scene, blit with gdi and set colorkey/blend depending on the alpha channel or background color of the scene.

The splash screen is intriguing, though…

this thing really rocks!

really!

Originally posted by evanGLizr:
[b] [quote]Originally posted by yooyo:
[b]Excellent work dude!!! How did you make it?

yooyo[/b]
My guess: Render to an RGBA pbuffer, readback scene, blit with gdi and set colorkey/blend depending on the alpha channel or background color of the scene.[/b][/QUOTE]Not sure : you can even click through this window holes on the windows under it!

This rocks. I’m really interrested in seeing the source. :cool:

Very nicly done.

Originally posted by tfpsly:
[b] [quote]Originally posted by evanGLizr:
[b] [quote]Originally posted by yooyo:
[b]Excellent work dude!!! How did you make it?

yooyo[/b]
My guess: Render to an RGBA pbuffer, readback scene, blit with gdi and set colorkey/blend depending on the alpha channel or background color of the scene.[/b][/QUOTE]Not sure : you can even click through this window holes on the windows under it![/b][/QUOTE]That’s part of the normal layered window hit test behaviour:

Hit testing of a layered window is based on the shape and transparency of the window. This means that the areas of the window that are color-keyed or whose alpha value is zero will let the mouse messages through.
If the layered window has the WS_EX_TRANSPARENT extended window style, the shape of the layered window will be ignored and the mouse events will be passed to the other windows underneath the layered window.

I’m quite sure everything is just an RGBA pbuffer & a GDI blit, using colorkeying or blending, depending on whether you want fully transparent/per window translucency or per pixel translucent windows:

To use UpdateLayeredWindow, the visual bits for a layered window have to be rendered into a compatible bitmap. Then, via a compatible GDI Device Context, the bitmap is provided to the UpdateLayeredWindow API, along with the desired color-key and alpha-blend information. The bitmap can also contain per-pixel alpha information.

Probably right about about readback and blitting cause it runs slow for something really simple.
For sure it would work this way.

Great job, never seen anything like it before. I would love to see the source for it. I noticed i could click on a window behind the program even in the smalled hole inbetween the spheres… does this mean it uses the windows API for this type of stuff? (I know VB does something like this, not sure about C++/C)

Well, nice work regardless
Hope to see the source soon :wink:
-Zix

Originally posted by zix99:
I know VB does something like this, not sure about C++/C)
Pfff… If a vb interpreter written in C/C++ can do it, why a C/C++ program would not be able to do it ? :rolleyes:

Thanks for all the responses. :slight_smile:

My apologies on not having the source ready. I don’t have a lot of free time, even to work on demos like this. Perhaps I’ll be employed doing work that better corresponds to interesting things like this in the future.

Anyway, evanGLizr is almost dead on. I do use UpdateLayeredWindow and glReadPixels to achieve this effect. AFAIK this is the only way to do this cleanly, since Windows has issues with mixing layered windows and OpenGL. Perhaps Longhorn will bring a better solution. However, this is not really the clever part of this demo. I didn’t create any messy offscreen windows or use the desktop window to get an OGL context (since that doesn’t work on the NV cards I have).

I’ll try to get the source up soon.

Thanks again for the interest,

Dude

Man this really is sweet. When can we see the code? :smiley:

Very cute, very nice. It would be fun to have the source code to make my own little silly creations, like intermitent shooting stars when there’s no keyboard or mouse activity…

I would like to report that I can’t drag the cube to my second monitor. That’s not really a surprise, but just an FYI. They’re both being driven from the same card, an ATI FireGL X1 AGP Pro.

This looks like a resume’ to me. I just like to leave it running, it’s pretty cool I think…
Somebody get that man a job :stuck_out_tongue:

anyway, to be useful in my post:
I have noticed the issue with the second screen.
I can get it to work on both screens (ATI) if I load the program, then enable the second screen. I do not know why this is, but it just happens to work that way on my system.

Just thought I’d comment on an earlier post.

@V-man: I don’t think the slowdown you are experiencing is due to the readback and blitting. This demo uses a 400 x 400 RGBA pbuffer. Doing the math you get 640K per frame. I cap the demo at 60 fps, so the required bandwidth is only 38.4M/s, disregarding state change overhead. This is less than 1/4 the AGP 1x theoretical bandwith.

I believe the slowdown in your case is due to fill rate. I noticed this on my GF FX 5200 (notoriously fill limited). It’s easy to miss the fill requirements because the subject is so simple; it just renders some rotating spheres. However, I naively render the spheres without any depth sorting and I don’t render ambience and z first, so I don’t take advantage of early depth rejection. I also calculate all the lighting in the fragment shader, so performance takes a hit there too (on top of using ARB FP1).

I estimate that in the worst case the demo shades around 210K fragments per frame using this metric:

Estimated coverage of the closest plane of spheres when parallel to the view plane: 50% = 400 x 400 x 0.5 = 80,000 fragments.

Estimated coverage of the middle plane when aligned parallel: front coverage - 10K = 70,000 fragments.

Estimated coverage of the farthest plane when aligned parallel: middle plane - 10K = 60,000 fragments.

Leading to a rough estimate of total coverage in the worst case: 80K + 70K + 60K = 210K fragments per frame = 12.6M fragments/s.

I think that the fp shader and fill combination is much more substancial than the meger bandwidth requirements of the blitting, even given the coarseness of my estimation. Also, the demo renders smooth when using only fixed function, even though I bump up the LOD significantly. Perhaps I should add “Use Fixed Function” as an option when fragment hardware is detected.

In the little time I’ve had to clean up the code I fixed the problem on ATI cards where the window doesn’t render on secondary displays. A two character fix, thankfully.

So hopefully I’ll have some nice source for everyone some day soon. I appreciate everyone’s comments thus far and any feedback you provide me.

Regards,

Dude

Crashed instantly, no window appeared :frowning:
5200 & Windows 2000

yes, it crashes instantly on my computer as well:
vid card: FX 5900
os: XP
driver version: 56.72
running dual monitors

It works smoothly here : Radeon 8500/Win2000, with no fancy shading though.

What bugs me is the size of the executable (744KB). Ok there must be embedded resources (ttf, jpg or whatever), but still… Plus you must add two dlls : 856KB (cg.dll) +188KB (cggl.dll)

Anyway, it definitely looks good. I hope you’ll find a job soon.