[Patch] Rendering of FreeBasic graphic on OpenGL

For other topics related to the FreeBASIC project or its community.
angros47
Posts: 1267
Joined: Jun 21, 2005 19:04

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby angros47 » Sep 13, 2017 22:45

Then, adding those lines:

Code: Select all

CONST AS INTEGER OGL_MANUAL_SYNC = 1, _
                             OGL_AUTO_SYNC = 2


to fbgfx.bi would solve
Imortis
Posts: 1386
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby Imortis » Sep 14, 2017 20:49

As soon as I get back to my machine, I will submit a pull request for this to be included in freeBASIC.

EDIT:
Pull Request
angros47
Posts: 1267
Joined: Jun 21, 2005 19:04

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby angros47 » Sep 15, 2017 9:29

Thank you!

I also noticed that, while in 32 bit mode any resolution is supported, in 16 bit mode horizontal resolution has to be a multiple of 2, and in 8 bit mode it has to be a multiple of 4. Otherwise, the image will be deformed.

The reason is that each line of pixel, in FreeBasic, is supposed to be accessed as a sequence of UNSIGNED LONG. Since this data type is made of 4 bytes, if a line contains a number of bytes that is not a multiple of 4, the remainder will shift the next line, if it is accessed using an ULONG pointer. To prevent this, some bytes are added at the end of each line to keep it aligned.

Unfortunately, in OpenGL, the command glTexSubImage2D (used to copy the buffer to a texture) does not expect those bytes to be here, and so it will consider them as part of the next line, shifting it, and shearing the whole image. It can be prevented by ensuring that each line contains a multiple of four bytes.

In 32 bit mode each pixel uses 4 bytes: so, it does not matter how many pixels are in a line, the number of bytes will always be a multiple of 4. In 16 bit mode, each pixel uses 2 bytes, so as long as the number of pixels per line is even the number of bytes will be a multiple of 4. In 8 bit mode the number of pixel per line just has to be a multiple of 4.

Since OpenGL is a true color mode, the most useful mode is 32 bit; the only reason to use 16 bit or 8 bit is to port old code... that would likely use a legacy screen resolution (and all those resolutions are multiple of 4, horizontally). So, in theory this should not be an issue, but perhaps it might need a warning in documentation
D.J.Peters
Posts: 7019
Joined: May 28, 2005 3:28
Location: Germany

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby D.J.Peters » Sep 15, 2017 11:23

angros47 wrote:...if a line contains a number of bytes that is not a multiple of 4, the remainder will shift the next line...

...In 32 bit mode each pixel uses 4 bytes: so, it does not matter how many pixels are in a line, the number of bytes will always be a multiple of 4...
Independent from mode (BPP 8,15,16,24,32) fbgfx every scanline used 16 byte alignment not 4 byte.

Joshy
marcov
Posts: 2334
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby marcov » Sep 15, 2017 16:04

One can use glpixelstore() to set the alignment of a texture being uploaded

https://www.khronos.org/registry/OpenGL ... tore.xhtml
dkl
Site Admin
Posts: 3145
Joined: Jul 28, 2005 14:45
Location: Germany

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby dkl » Sep 20, 2017 18:15

I've written some review comments on the Github pull request for this, but they're only about some minor formatting issues and such that would be nice to have fixed before merging.

Besides that I've looked at whether non-OpenGL graphics modes are affected, but no, it looked good. So we don't have to worry about this patch breaking anything else (which is typically a concern when making changes to FB). Also the new background thread for the new OpenGL mode looks good to me (it's much like other parts of gfxlib2 are implemented already).
Imortis
Posts: 1386
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby Imortis » Sep 20, 2017 19:05

dkl wrote:I've written some review comments on the Github pull request for this, but they're only about some minor formatting issues and such that would be nice to have fixed before merging.


How do I find those comments? I am still kinda new to github and had no luck googling it.
dkl
Site Admin
Posts: 3145
Joined: Jul 28, 2005 14:45
Location: Germany

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby dkl » Sep 20, 2017 20:22

Ahh yes, I missed the "submit review" button. Should be visible now.
Imortis
Posts: 1386
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby Imortis » Sep 20, 2017 20:37

Okay. I can easily make most of those changes.

The one for the module level vars and the __fb_gl context: I could make them static, OR add them to the context, but I did not write the code so I am not sure which would be best.

@angros47:
Here is the review comment.

Can you provide some guidance?
angros47
Posts: 1267
Joined: Jun 21, 2005 19:04

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby angros47 » Sep 20, 2017 22:08

I'll check them.

Luckily, the library was modular enough to prevent breaking other features when changing something.
angros47
Posts: 1267
Joined: Jun 21, 2005 19:04

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby angros47 » Sep 21, 2017 9:36

While I was applying the suggested changes, I fixed the bug that occurs when the width is not a multiple of 4; looks like the screen buffer has no alignment, and OpenGL expected a multiple of 4. It can be fixed with glPixelStorei(GL_UNPACK_ALIGNMENT, 1), and I added it (I had to add it to the declarations as well)
Imortis
Posts: 1386
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: [Patch] Rendering of FreeBasic graphic on OpenGL

Postby Imortis » Sep 21, 2017 15:40

angros47 wrote:While I was applying the suggested changes, I fixed the bug that occurs when the width is not a multiple of 4; looks like the screen buffer has no alignment, and OpenGL expected a multiple of 4. It can be fixed with glPixelStorei(GL_UNPACK_ALIGNMENT, 1), and I added it (I had to add it to the declarations as well)


Committed your changes.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest