LWJGL 0.5 Released

OpenGL Development
#21

Ok then, as I said, there’s now 2 possibilities:

  1. Your card can’t do alpha - the most unlikely option
  2. The driver is lying and can do alpha but doesn’t report it
  3. We are doing something wrong when selecting modes

to rule out 1. you have to find a demo doing alpha blending - maybe a nehe dome in C++? Ruling out the other is not that easy - if the native demo can do alpha you might want to find out how it created the modes. Or dump the GL info like you did for the succesful lwjgl modes to see if the driver still reports no alpha.

To rule out 3 we have to use an opengl extension to query the supported pixel formats, but noone has implemented it yet :/. I might do it myself someday, but that’s not going to help you now.

  • elias
#22

Okay, I’ve just added a few 50% transparent quads to a test application, and they work fine. This is with requesting a 640x480, 0Hz, 32bpp, 8-bit depth, 0-bit alpha and 0-bit stencil DisplayMode. There was a drop in frame rate from about 150fps to 110fps, although I guess this is just my dodgy graphics card?

I’m afraid S3 are (“allegedly”) terrible at providing OpenGL support, and their chipsets never perform well in OpenGL apps. I’ve noticed them bending the OpenGL spec in such a way that the driver I’m currently running won’t even pass OpenGL 1.0 certification due to a deficiency in subpixel precision.

Anyone got a clue what may be going on? Once again I’m beginning to suspect not LWJGL but S3 - it looks like LWJGL is just doing the best it can with what’s available. However, it remains to be seen how I can ensure I have an alpha-buffer if both the driver and the hardware deny its existence.

#23

Elias,

I’ve just found an OpenGL extension viewer. In the one screenshot on the website it appears to have a “Display Modes” tab. Downloading now… :slight_smile:

http://www.realtech-vr.com/glview/

#24

Weird, I’d think it was the other way round, that is a requested feature is advertised but either broken or implemented in software or something. Doing alpha but lying about it is simply stupid, IMHO. But yes, it sounds more and more like the driver is pulling your nose. Are your drivers the most current?

  • elias
#25

Hmmm… I thought that the “alpha” indicates presence of alpha component in framebuffer’ pixel format and it does nothing with the blending capability. You can do regular blending operations without having alpha in the framebuffer… 8)

#26

The extension viewer doesn’t break the colour depth down, so while it reports 32-bit colour, it doesn’t say whether that involves any alpha-bits at all. Nice app though.

Found another app that does list alpha values (http://www.benchmarkhq.ru/files/glinfo_bin.zip), but I think it’s working in software mode.

Edit: Hi Alex, I think you’re right. I’m going around in circles here… The presence of alpha-bits in the DisplayMode should only affect the presence of an alpha-channel on the display surface, not the ability to perform blending operations themselves.

Thought I was going mad there for a moment! :-X

So my code was working before because 0.4 didn’t check alpha values, and doesn’t work now because 0.5 does but my hardware doesn’t support them. Okay, I’m happy now! ;D ::slight_smile:

Elias, I’m running pretty much the latest display drivers. They were last updated mid-2001 and I’ve got drivers from somewhere about that period. S3’s (“allegedly”) dodgy OpenGL support coupled with Toshiba’s (“allegedly”) snail-like driver release cycle is a force to be reckoned with. :wink:

#27

And I think his wrong, the framebuffer alpha is exactly used to blend the incoming pixel with the one already stored in the framebuffer. If not for blending, what’s the use for alpha in the pixel format of the framebuffer?

  • elias
#28

Everything works fine here…i just had to change the call to Display.create() to make jPCT work again. Even the performance is around 10% higher for me. The window-support is much better now, albeit i can’t move the LWJGL-window around!? (Windows XP Home, Radeon 9700pro, Catalyst 3.2)

#29

[quote]albeit i can’t move the LWJGL-window around!?
[/quote]
Bugger, thats a bug then - I had problems with that too, but thought it was because I was using themed XP … - looking into it… it used to work ;D

#30

HAHA! <-- the evil kind

Found the bug - now to locate the perpetrator…

#31

[quote]HAHA! <-- the evil kind
[/quote]
Ah, that’ll be a “Muhaha” then! ;D

Yeah, I can’t move the window around either. But then again I don’t have a mouse cursor when the window is focused, so how would I do so anyway? ???

#32

[quote] Yeah, I can’t move the window around either. But then again I don’t have a mouse cursor when the window is focused, so how would I do so anyway?
[/quote]
I already fixed it, and committed it…

Since the window steals the cursor (as it should do) - you would have to alt+tab to loose focus, and you can then hold and drag the window. As soon as you let go, it will steal back the cursor - like any other app.

#33

[quote]And I think his wrong, the framebuffer alpha is exactly used to blend the incoming pixel with the one already stored in the framebuffer. If not for blending, what’s the use for alpha in the pixel format of the framebuffer?

  • elias
    [/quote]
    I think if there is no alpha channel in the framebuffer the destination alpha is always 1 in the blending equations (BTW for widely used additive blending only incoming alpha counts).

And why do you need framebuffer with alpha channel? To blend it with underlaying windows (the original purpose for this, which came from SGI stations, IMO)?
For the gaming rendering to a texture with alpha channel is enough (to generate procedural fire texture, for instance)… That’s why framebuffer with alpha channel is a rare thing for the modern game-oriented cards… or am I mistaken? 8)

#34

Using alpha in the framebuffer is a rare specialist case. I used it in the terrain demo to do some clever blending tricks. You basically don’t need it for 99% of anything you do and you can’t have it on 16 bit colour modes anyway in any cards available today, so it can have a bit of an impact on performance.

Cas :slight_smile:

#35

Well then it makes much more sense that cfmdobbie don’t have alpha on his card. I simply assumed that alpha bits were required to get any meaning from the blending equations.

  • elias
#36

Matzon; I guess the fixes you made aren’t in the 0.5 release? So in order for me to get them (I’m as lazy as they come) I’ll need to download some files specifically and recompile? (I know jack-shyt about CVS, apart from being this lazy) My co-developer’s computer (W2K, Matrox G200) freezes every now and then when he’s LWJGLing, and I figured this fix just might easy some of his rear entry pains… So! What do I do to get the latest?

/M

#37

[quote]I guess the fixes you made aren’t in the 0.5 release?
[/quote]
correct, however we will most likely do a 0.5.1 release soon

[quote]So in order for me to get them (I’m as lazy as they come) I’ll need to download some files specifically and recompile?
[/quote]
You need to download the source archive, get the latest org_lwjgl_display.cpp from CVS, setup a project to compile the files - all in all not 1 minute work - might want to wait for 0.5.1.

[quote]My co-developer’s computer (W2K, Matrox G200) freezes every now and then when he’s LWJGLing, and I figured this fix just might easy some of his rear entry pains…
[/quote]
Well Matrox isn’t know for the best OGL support… but I really don’t know why he is getting freezes (Garbage Collection?)

#38

i have linux box with c/c++ compiler can i do
cross-platform build to windows with it?
i hate installing visual studio again and possibly download service packs

#39

I don’t think that’s possible - and even if it is I’d reckon it’s much more painful than installing vs and service packs.

Btw, remember to install the latest SDK from microsoft, or else some of the lwjgl files won’t compile! At least, that’s what happened to me with visual studio 6 (probably not a problem on the .net version).

  • elias
#40

[quote]Well then it makes much more sense that cfmdobbie don’t have alpha on his card. I simply assumed that alpha bits were required to get any meaning from the blending equations.
[/quote]
Yeah, that was my assumption too. The reality (as Alex says) is that alpha bits requested when opening an OpenGL rendering context are only requesting alpha bits on the display surface itself.

I guess the side effect of this is that I won’t be able to do things like pull RGBA data from the framebuffer with gl.readPixels - there’s no transparency data there.