Static text on OpenGLContext

[ehj666]

That is good information. Here is how it is coming out when dropping a panel on the openglcontext. Not bad. If I could make the panel transparent, that would be a bonus.

[Handoko]

I have tried using your approach, same as you, I can't make the panel transparent.

[ehj666]

Poking around I found a couple of example that might work, but at the present time it is not at the top of my priority list.

[Graeme]

I have tried using your approach, same as you, I can't make the panel transparent.

I don't believe LCL allows "standard LCL" components to be truly transparent (independent of the top-level window transparency), so I don't think there is a solution for that. fpGUI and MSEgui on the other hand have true widget transparency support for all "standard" and custom widgets, so you are more likely to go a bit further.

Either way, I don't think that is a good solution. Your idea of using a alphabet image-map is by far the best solution. I've seen that solution used in many OpenGL games too - even Minecraft uses that.

[Handoko]

Can MSEgui+fpGUI uses Lazarus packages, like LazOpenGLContex and BGRABitmap?

I landed on MSEgui+fpGUI website many years ago. Very interesting, they have many nice features. Unfortunately, I don't have much time to learn about them. So I stick with Lazarus.

Basic image-map font (for OpenGL) has many limitations, the better alternative is signed distance font. I have tried to understand how it works, but still never really use it.
http://forum.lazarus-ide.org/index.php/topic,30556.msg194484.html

[Graeme]

Can MSEgui+fpGUI uses Lazarus packages, like LazOpenGLContex and BGRABitmap?

No you can't use Lazarus components directly in MSEgui or fpGUI projects. Saying that, MSEgui does have its own OpenGL components. fpGUI doesn't yet, simply because I have never been interested in OpenGL (that's until now).

As for BGRABitmap. I believe there is official support for fpGUI now - added by the author of that project. I've never tried BGRABitmap though, my preference is AggPas, because it generates amazing output, sub-pixel rendering and also has a user configurable graphics pipeline (just like "modern OpenGL").

Switching from Lazarus to fpGUI is very easy. Even porting whole components is quite a simple process. The usage is (writing applications and using components) are very similar between the two frameworks. MSEgui has a very different take on things (different, but not always a bad thing). I've also had quite a few developers tell me that the latency in fpGUI is *much* less than in LCL based applications, so sound processing and graphics applications actually run much better in fpGUI.

Basic image-map font (for OpenGL) has many limitations, the better alternative is signed distance font. I have tried to understand how it works, but still never really use it.

My other idea was to do in OpenGL the same as what AggPas does with text and fonts. AggPas extracts the vector information of each glyph, then renders it like all other vectors. Thus you get access to all kinds of transformations and effects (transparency, gradient fills etc), and can render text at any size. I'm pretty confident the same should be possible with OpenGL - if I have a moment I'll give that a try.

[lainz]

I made Kaaj Controls for fpGUI.

I made OpenGL controls (BGRAControlsFX) based on the OpenGLContext with BGRABitmap (using text also) so if he wants he can do something with it, implementing a label will not be as hard. 

If you don't like my way with BGRAControlsFX even with BGRABitmap there's a control that inherits from OpenGLContext (TBGLVirtualScreen) that supports text out, see examples that comes with the sources.

Panels inherits from TCustomControl, there has their own canvas and can't have transparency, for that you can place them in OpenGLContext. Controls that can have transparency inherits from TGraphicControl and uses the parent canvas, so you can't place them in an OpenGLContext.

[Handoko]

fpGUI doesn't yet, simply because I have never been interested in OpenGL (that's until now).

Good to know now fpGUI will add OpenGL components in the future.

Will you add Android support too? Or does it support LAMW?

I'm interested to do Android programming. I spent lots of time learning LAMW, unfortunately it has bugs with OpenGL ES. The 2D is working correctly but the 3D seems works incorrectly. I managed to improve the 2D performance, about 20% fps increase in my tests tested directly using my Android phone. But when I learn and use 3D in LAMW, I scratched my head, seemed to me those are bugs. I wanted to fix the bugs, but OpenGL ES is too complicated for me. The tutorials are easy to be found but all the codes are in C/C++, which I can't understand. So I just have a break, doing other things now.

If fpGUI supports OpenGL and Android (or LAMW), I will switch to it immediately.

@lainz

I guess the OP's project has time limit. He (or she) will use anything that is easy with least of effort. I personally won't overlap OpenGL with non OpenGL (TPanel) things.

[lainz]

I think the easy way is using something that already works, again TBGLVirtualScreen has BGRABitmap support that supports text out, in one or two lines of code.

Edit: AFAIK is compatible with OpenGLContext, is an enhanced version of it. All things I said are not panels, but controls that can work on top of OpenGL.

The thing I said about the panels is pure a technicality.

[Akira1364]

I think the easy way is using something that already works, again TBGLVirtualScreen has BGRABitmap support that supports text out, in one or two lines of code.

Edit: AFAIK is compatible with OpenGLContext, is an enhanced version of it. All things I said are not panels, but controls that can work on top of OpenGL.

The thing I said about the panels is pure a technicality.

As much as I love BGRABitmap and BGRAControls as a whole (been using BGRAVirtualScreens extensively in DeleD) the OpenGL-related portions of them lag FAR behind the rest in terms of performance and aren't really worth using, IMO. Try it for yourself: the "normal" BGRABitmap drawing functions will run circles around the OpenGL ones every time. This is of course because of the fact that the OpenGL drawing functions use immediate mode (which has always struck me as odd, since BGRABitmap does also contain reasonably extensive vertex buffer and shader-related capabilities. Why aren't they used everywhere?) Stop using glBegin/glEnd, people! You are wasting your time. They're not hardware accelerated, at all, and they're not even "just a little bit" outdated either. They've been outdated since 1997! (When glDrawArrays was introduced.)

[lainz]

I know is not hardware accelerated, afaik uses cpu and only the final drawing is hardware accelerated, so that's not fast. But I give that as a way to do it, since I don't know nothing about OpenGL I use that.

[Handoko]

Perhaps TBGLVirtualScreen (or BGRABitmap) can consider using full OpenGL in the future improvement.

But it may have its downside. Recently after I upgraded my Ubuntu, there was something wrong with my NVidia proprietary driver, all the program that using OpenGL can't run. I tried the Nouveau open source driver, not just games using OpenGL, my very simple OpenGL pascal code also can't run.

So it depends on BGRABitmap's strategy. Will it try to provide fast graphics library without hardware support (I mean OpenGL), or it's optimized for performance but sacrificing compatibility with machines without OpenGL (properly installed).

[lainz]

Actually has fast hardware for 2d, since it draws textures with OpenGL afaik.

Is not one or the other, everything is built now works and is not a good idea to delete that in order to support OpenGL only.

[Akira1364]

Just to be clear, I absolutely wasn't suggesting that the entire BGRABitmap library should be converted to use only OpenGL. I was saying that the parts that do currently use OpenGL are
actually slower than the parts that don't, because even though neither are hardware accelerated, the non-OpenGL drawing functions don't have to make external dynamic library calls hundreds or thousands of times per second (as in glVertex3F and such). So overall my point was just that in order for the OpenGL-specific classes to actually be worth using over the "normal" ones, they would need to use vertex buffers and shaders instead of immediate mode.

[circular]

There is room for optimizations regarding the computation of vertices and the way they are sent to OpenGL. I have been thinking about that. That said, it is still faster using OpenGL than not in my experience (except when OpenGL uses software rendering).

About the optimizations of vertices, a way would be to let OpenGL compute matrix transformations. For now, the OpenGL version of Scene3D is derived from the software rendering version that was doing all the matrix computations with the CPU.

That's also the reason vertex buffers are not used much. In fact, I've added them to BGRABitmap after I made the OpenGL version of Scene3D.