At the moment, in FreeBasic it's possible to set OpenGL mode, but no FreeBasic graphic command work on it; having the option to use them would be very useful (i.e., in a 3d game it could be used to display the score).
About ten years ago, the topic has been discussed:
http://www.freebasic.net/forum/viewtopic.php?f=3&t=2763
http://www.freebasic.net/forum/viewtopic.php?f=3&t=2745
At time, it was considered unnecessary, but many things changed since then.
Actually, there are two ways to build an OpenGL backend: the first one is to remap every graphic command to the equivalent OpenGL command (that was the solution proposed in the link above): it has never been officially implemented, but some "unofficial" solution have been made, like this one: http://www.freebasic.net/forum/viewtopic.php?f=3&t=72 (by the author of fbgfx) or this: http://www.freebasic.net/forum/viewtopic.php?t=10607; in 2006, a solution like this seemed ideal: it is hardware-accelerated at every level (from PSET, to LINE, to GET/PUT) and can maintain compatibility with older syntax. Unfortunately, it would have required a rewriting of every graphic command (to check if it had to use classic fbgfx, or opengl) and this would have bloated and slowed down the fbgfx library, plus breaking a lot of existing code; also, some fb commands (like PAINT) have no equivalent in OpenGL.
Today, this solution looks inadequate: it relies on immediate mode, that is sub-optimal on modern video cards, and is being deprecated (glBegin...glEnd have been removed in OpenGL 3.1, as far as I know).
The second solution is to render the image in software, on a buffer (just like you do when you use DirectX, or X11: the graphic buffer is sent to the driver, and copied on the screen) , and then use OpenGL to render it, by converting it into a texture, and rendering a full screen rectangle with that texture. A proof of concept is this: http://www.freebasic.net/forum/viewtopic.php?t=11214, and the file "2d.bi" included with OpenB3D is based on it. Implementing it in fbgfx should not require heavy changes: OpenGL would work just like any other driver, displaying on the screen the standard screen buffer (maybe, a ScreenLock command could be used to disable this behaviour, if somebody need the "pure" openGL context to use with external libraries).
In 2006, a similar solution would have seemed pointless: most of the rendering still happens in software, on the internal buffer, and using OpenGL would only add one more step (copy the image on a texture, then copy the texture on the screen).
But today, it makes sense: many graphic engines don't render on the screen, but on a texture, because it's the simplest way to use GPU shaders for post processing an image (even in 3d engines that already make use of shaders, every 3d object must have its own, different GPU program, and this trick allows using the same program on the whole scene). And having support for post processing in fbgfx would unlock a lot of new possibilities (HDR, bloom, underwater effects, convolution filters, upscaling with HQx...); also, fbgfx is often used in retrogaming, or in remakes, or in emulators: there are a lot of shaders that can emulate CRT monitors/tv, improving the overall feeling (and, since fbgfx already emulates things like CGA palettes, or VGA fonts, it would be the next logical step)
So, my question is: developers could consider adding in fbgfx an OpenGL backend?
I'd love to hear other user's opinions, too.
Feature request: OpenGL backend
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Feature request: OpenGL backend
Sounds like it would be a cool idea.
I guess my personal responses as a non-expert would be:
- very short answer: we accept patches.
- longer answer: if someone wants it badly enough to become the implementer, their best approach might be just to start asking questions. If there are people here who know OpenGL, and people who know the FBGFX internals, or who wouldn't find it too hard to get into them, then hopefully it should be possible to bridge the two, and the discussion may be educational for people who read along, potentially bringing about more people who feel able to collaborate.
I guess my personal responses as a non-expert would be:
- very short answer: we accept patches.
- longer answer: if someone wants it badly enough to become the implementer, their best approach might be just to start asking questions. If there are people here who know OpenGL, and people who know the FBGFX internals, or who wouldn't find it too hard to get into them, then hopefully it should be possible to bridge the two, and the discussion may be educational for people who read along, potentially bringing about more people who feel able to collaborate.
Re: Feature request: OpenGL backend
My first question is: is there some documentation about how to compile the fbgfx lib? A tutorial, or something?
And does exist some "template" for graphic driver (a sort of "null" driver, to use as a base to add functions)?
I guess OpenGL has to be loaded dynamically, so if there is no OpenGL library installed on destination computer the driver will just fail to initialize and FBGFX will be able to use another driver as a fallback (with no post-processing). I found the "glad" tool that creates loaders for that:
http://glad.dav1d.de/
Or in FBGFX there already is a dynamic loader, and it should be used?
And does exist some "template" for graphic driver (a sort of "null" driver, to use as a base to add functions)?
I guess OpenGL has to be loaded dynamically, so if there is no OpenGL library installed on destination computer the driver will just fail to initialize and FBGFX will be able to use another driver as a fallback (with no post-processing). I found the "glad" tool that creates loaders for that:
http://glad.dav1d.de/
Or in FBGFX there already is a dynamic loader, and it should be used?
Re: Feature request: OpenGL backend
Well, the gfxlib2 is part of FB, even the same makefile in recent years, so check out DevBuild.
We have a bit of documentation on gfxlib2 internals specifically here: GfxLib, GfxInternalFormats
It does indeed already have some code for loading OpenGL functions at runtime, just search for fb_hGL_Init() in the gfxlib2 source files.
We have a bit of documentation on gfxlib2 internals specifically here: GfxLib, GfxInternalFormats
It does indeed already have some code for loading OpenGL functions at runtime, just search for fb_hGL_Init() in the gfxlib2 source files.
Re: Feature request: OpenGL backend
I did some experiments, and I managed to get a rendering each time the command "flip" is called. Both real and paletted colors work. I am unsure if it would be better to have the rendering on the screen at regular intervals, as it happens in the other drivers, or not. I would like to hear other points of view.
Another question is: at this point, it would be easy to implement upscaling of an image, but how should the SCREEN syntax be used to activate it? Perhaps an extra flag?
Another question is: at this point, it would be easy to implement upscaling of an image, but how should the SCREEN syntax be used to activate it? Perhaps an extra flag?
Re: Feature request: OpenGL backend
Looks like it is possible to use the OpenGL mode even without using the "flip" command, but only one thread at time can access the OpenGL mode. So, if the graphic thread used to show the window takes care of the GL mode, the FreeBasic program wouldn't be able to use any openGL command, since the context is used by another thread. A command to switch between the two modes would be needed: in automatic mode, OpenGL would work like any other graphic mode, with no way to use the 3d mode; in semi-automatic mode, the screen will be rendered by the "flip" command (that is already need for 3d graphics)