Can't add [..] in listbox items

[Armitage1982]

Hi

Is there any problem with 0.7.1 to add a listboxTextItem labeled "[..]" ?
I'm no more able to represent the recursive folder in my listbox window, the process of adding this item is completely bypassed.
Something related to TAG maybe ?

The same code was working great in 0.6.2

[CrazyEddie]

Hi,

Yes, this is related to the text control tags. You need to escape the opening bracket with a backslash, so "\[..]".

HTH

CE.

[Armitage1982]

It's working !
Thanks a lot

By the way, the current version of the wrapper still has some alpha weirdness (0.75 alpha windows too shady and transparent, or text less but still transparent too ).

Code: Select all

09/01/2010 21:21:28 (Std)    ---- Version 0.7.9999 (Build: Jan  9 2010 Static Microsoft Windows g++ 3.4.5 (mingw-vista special r3) 32 bit) ----
09/01/2010 21:21:28 (Std)    ---- Renderer module is: CEGUI::OpenGLRenderer - Official OpenGL based 2nd generation renderer module.  TextureTarget support enabled via FBO extension. ----
09/01/2010 21:21:28 (Std)    ---- XML Parser module is: CEGUI::TinyXMLParser - Official tinyXML based parser module for CEGUI ----
09/01/2010 21:21:28 (Std)    ---- Image Codec module is: FreeImageCodec - FreeImage based image codec ----
09/01/2010 21:21:28 (Std)    ---- Scripting module is: None ----

[CrazyEddie]

By the way, the current version of the wrapper still has some alpha weirdness (0.75 alpha windows too shady and transparent, or text less but still transparent too ).

Can you provide a couple of screen shots showing what you consider to to correct blending (presumably from 0.6.x) and the now incorrect blending?

I'm actually very confident that what I have now is correct, I have never been more pleased with the output; I get no bleed through, window fading appears to be as it should; I don't think the output has ever been so clean and crisp at any point in the past. This said, I will additionally test the BlitzMax wrapper using the 0.6 and current trunk versions of the wrapper to compare, though I will likely not get to that until Tuesday or Wednesday as I'm working on something else over the next few days.

CE.

[Armitage1982]

How it should appear at 0.75 alpha in 0.6.2


How things are with 0.7.1


Look closely to the white text, you can see the background through it.

Maybe the ceguiopengl driver from Brucey need a something more ?

It seem's that the new version is even slower than before (from 315 fps in 0.6.2 to 215 fps in 0.7.1). I really wonder where is the problem

Code: Select all

---- Version 0.7.9999 (Build: Jan  9 2010 Static Microsoft Windows g++ 3.4.5 (mingw-vista special r3) 32 bit) ----
---- Renderer module is: CEGUI::OpenGLRenderer - Official OpenGL based 2nd generation renderer module.  TextureTarget ----
---- XML Parser module is: CEGUI::TinyXMLParser - Official tinyXML based parser module for CEGUI ----
---- Image Codec module is: FreeImageCodec - FreeImage based image codec ----
---- Scripting module is: None ----

[CrazyEddie]

Yeah, I can see that's definitely wrong. Not the same results I get here at all.

I think what I'll do, is create a small test app and let you download it and see what results you get - this way we will both be able to take screenshots of the same app doing the same thing and compare. If I make 0.6.2 and 0.7.x versions we can also test the performance issue at the same time. Does this sound like a good approach?

[Edit]
I'll act on that additional info you have provided via PM also - since we posted those at the same time

CE.

[Armitage1982]

Yes no problem at all

[CrazyEddie]

Hello again,

I have been running some tests and can now confirm some differences with the BlitzMax wrapper regarding alpha blending when compared to the native C++ - the issues I have seen are not the same issues you have, but at this early stage of testing it definitely seems that something is affecting the rendering (and so could conceivably manifest itself differently on different hardware). I have to debug into this some more - initially I though it only affected me on Windows, but running the same tests back here on linux, I get the same results (I'm kind of annoyed I did not spot it the first time I ran some tests).

I'll report back once I have any additional information. Watch this space ---> ' '

CE.

[Armitage1982]

Aaah Interesting !
I hope for you that will find the last bit of problem this time once and for all
Dare I hope that this early response is related to the problem of speed?

I finally finish to tweak every layout around.
Would be cool if I could use this last version correctly at normal speed

[CrazyEddie]

The problems are more than we might initially think

The particular issue I identified last night was that alpha test is enabled somewhere by BlitzMax, and was not reset by CEGUI, hence the issue I saw. I have added this state setting to the 'extra' states option on the GL renderer - so to get advantage of that - and other - settings, you have to enable the extra states on the renderer, like this:

Code: Select all

myGLRenderer.enableExtraStateSettings( True )

(obviously to get the alpha test fix you need brucey to update)

I'm working on the test app I spoke of. I have identified that alpha is still affected by the use of rendering surfaces. Again, this is not the issue you demonstrate above - I get no bleed through on the text or anything, the alpha of a window with a texture based rendering surface is definitely lower than it is without the surface, however, in my test, the content has a higher alpha. Some images to demonstrate...

With RTT surface enabled and 0.75 alpha

With RTT surface disabled and 0.75 alpha


Notes:
- I borrowed a screen shot from your site for use in my test app, hope that's ok
- This issue is not specific to BlitzMax, it affects CEGUI itself.

With regards to the speed difference in BlitzMax, I still have to write a specific test for that, though alas, I can only work on one thing at a time

As a slight aside, I can't get a CEGUI event handler to work correctly in BlitzMax that responds to key presses (the handler is called, but the scan code or code point retrieved appears to be random garbage). Any pointers on how to do that correctly?

CE.

[CrazyEddie]

Ok. In respect of my own screen shots, there are a couple of issues at work.

The first one has to do with an incorrect blend setting for the RTT alpha channel, this is resulting in the alpha basically being applied twice (so instead of 0.75 opacity, you get (0.75 * 0.75) = 0.56), this is easily fixed and not a great issue.

The second issue (the fact it's darker) has to to with the fact that with RTT we end up with premultiplied colour values, which plays havoc with things when rendering back from the texture to the main display buffer (because the alpha gets multiplied in again). In and of itself, that issue is again easily fixed - we just use a different blend setting when rendering back the RTT content. However, due to the fact CEGUI currently makes no distinction between where the geometry has come from, there is nowhere to say "ok, change blend mode now" - so this will have to be added in order to address the issue. That's a slight pain, though we're lucky that we can do this on trunk if we have to, since it may require larger changes than we could safely make on the 'stable' branch!

Now, I still can't say why you have the issues that existed prior to my earlier fixes. Once I get the above issue fixed, I'll upload a test app which we can use to determine what's going on as far as that goes.

CE.

[Armitage1982]

The last tweak seems to be good
I see no more transparencies with text and the windows alpha look correct !

Thanks

[CrazyEddie]

Great! I'm glad these rendering issues are finally resolved (and I get to remind myself that sometimes things that 'look right' are not always right, and I should confirm that using more scientific methods ).

I can now move on to some of those other issues

CE.