OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!!

[SMcNeill]

Well, now I know it in conjunction between the different speeds of software vs. hardware layers. Not a big surprise TBH, but how fast is the opengl layer compared to both and what happens when I code:

_DISPLAYORDER _SOFTWARE, _GLRENDER
_GLRENDER _BEHIND

so _DISPLAYORDER makes the software layer the 1st and the gl layer the 2nd, hence the gl layer shall be ON TOP off the sofware layer.

But _GLRENDER instead says render the gl layer behind the software layer, so what has precedence?

The last called or what?

No idea.   I've never found the GL implementation in QB64 to be useful enough for me to sit down and learn more than just a few raw basics about it.  I've certainly never tried to time test it or anything else.

From what little I know about _GLRENDER, I always *assumed* it was on its own little independent thread and didn't interfere/interact with the rest of our code on a normal basis.  (Kind of like an ON TIMER routine calls to that other routine every X seconds.)   I thought the _FPS command was what was used to set the speed for _GLRENDER...

And how that all bleeds together to affect performance with _Software and _Hardware, and such, I just simply have no clue.   Does anyone around here actually use SUB _GL enough to have tested it and benchmarked speeds and various things with it?  Is anyone actually enough of an expert on how it's *SUPPOSED* to perform to answer such details questions as "Which of these commands take precedence:  _DISPLAYORDER or _GLRENDER?" 

I, personally, don't have a clue.   My GL experience is closer to a "Hello World" type example with it, than anything impressive like mapping, rotating, and shading a globe of the earth as it revolves around the sun.  I left it out of my answer above simply because I don't know enough about it to say anything definitely about it one way or the other.

[DSMan195276]

so _DISPLAYORDER makes the software layer the 1st and the gl layer the 2nd, hence the gl layer shall be ON TOP off the sofware layer.

But _GLRENDER instead says render the gl layer behind the software layer, so what has precedence?

The last called or what?

_GLRENDER is just a fancy _DISPLAYORDER, they modify the same thing. They have this correspondence:

Code: (Select All)

_GLRENDER _BEHIND -> _DISPLAYORDER _GLRENDER, _SOFTWARE, _HARDWARE, _HARDWARE1
_GLRENDER _ONTOP -> _DISPLAYORDER _SOFTWARE, _HARDWARE, _GLRENDER, _HARDWARE1
_GLRENDER _ONLY -> _DISPLAYORDER _GLRENDER

As far as performance goes, the only real one to consider would be `_Software` because the screen image always gets rendered even if its blank (IE. If you're drawing the whole screen with OpenGL, the blank software screen still gets rendered below it first and that wastes some minimal amount of time).

`_Hardware` and `_Hardware1` aren't a huge concern if you're not using them as if there's nothing in the queue to be drawn then that code doesn't do anything. There is no blank 'hardware screen' that always gets drawn as there is with`_Software`.

`_GLRender` also doesn't really matter - if you don't have a `SUB _GL` in your code then that rendering section is empty (and if you do, then presumably you want to be using it).

[RhoSigma]

so _DISPLAYORDER makes the software layer the 1st and the gl layer the 2nd, hence the gl layer shall be ON TOP off the sofware layer.

But _GLRENDER instead says render the gl layer behind the software layer, so what has precedence?

The last called or what?

_GLRENDER is just a fancy _DISPLAYORDER, they modify the same thing. They have this correspondence:

Code: (Select All)

_GLRENDER _BEHIND -> _DISPLAYORDER _GLRENDER, _SOFTWARE, _HARDWARE, _HARDWARE1
_GLRENDER _ONTOP -> _DISPLAYORDER _SOFTWARE, _HARDWARE, _GLRENDER, _HARDWARE1
_GLRENDER _ONLY -> _DISPLAYORDER _GLRENDER

As far as performance goes, the only real one to consider would be `_Software` because the screen image always gets rendered even if its blank (IE. If you're drawing the whole screen with OpenGL, the blank software screen still gets rendered below it first and that wastes some minimal amount of time).

`_Hardware` and `_Hardware1` aren't a huge concern if you're not using them as if there's nothing in the queue to be drawn then that code doesn't do anything. There is no blank 'hardware screen' that always gets drawn as there is with`_Software`.

`_GLRender` also doesn't really matter - if you don't have a `SUB _GL` in your code then that rendering section is empty (and if you do, then presumably you want to be using it).

Aah, thanks Matt, now I've all the informations needed to properly rework the respective Wiki pages with all the required interactions and cross references.

[Gets]

And since forever and ever and ever ago, I have asked everyone from users to devs to my local priest, *HOW THE BLEEP DO WE USE HARDWARE1*???

I remember answering a few times.

Since my posting rate is bimonthly, I checked every post I ever made ever. 

Here's me telling you about it in 2018:

Set the destination for a hardware image to 1 and it will be displayed on that screen, I think. I don't remember anything else

https://qb64forum.alephc.xyz/index.php?t...54#msg4354

and how to use it from 2020:

Most graphic/text commands have to be done on the software layer, so I think it's just there for when you need to sandwich those between hardware images

https://qb64forum.alephc.xyz/index.php?t...#msg121275

Looks like each post was one line long, so maybe not too useful. Now I have a few HARDWARE versions of SOFTWARE graphic commands to handle drawing on the HARDWARE layers

First, I create a palette map: this one is 16 shades of Red, Green, and Blue with full alpha because it was created for transparent gradient overlays:

Code: (Select All)

Sub LoadGradient

    Dim R As _Unsigned _Byte
    Dim G As _Unsigned _Byte
    Dim B As _Unsigned _Byte
    Dim A As _Unsigned _Byte


'Sets image dimensions to store colors. Square root of R*G*B*A. (16*16*16*256)
    ysize = 1024
    xsize = 1024

    Pal = _NewImage(xsize, ysize, 32)
    Dim m As _MEM
    m = _MemImage(Pal)

    _Dest Pal


    For y = 0 To ysize - 256 Step 256

        For x = 0 To xsize - 1

      

'Gradient layout: R changes every pixel, G every 16th pixel, B every 256th pixel,so (0 to 15,0,0), (0 to 15,1,0),(0 to 15,2,0)...(0 to 15, 15, 15)

            R = (x * 17)
            G = (Int(x / 16) Mod 16) * 17
            B = (Int(x / 256) + Int((4 * y) / 256)) * 17




            For h = 255 To 0 Step -1

'You have to place the transparent colors with MEM. If you use PSET, they'll blend with black

                          _MemPut m, m.OFFSET + (x * 4) + ((255 + y - h) * ((xsize) * 4)), _RGBA32(R, G, B, h) As _UNSIGNED LONG
            Next h

        Next x

    Next y


'Part of a global variable that holds all of the gradient data
    Gradient.Image = _CopyImage(Pal, 33)

    _FreeImage Pal



End Sub

Then I can stretch a column over the entire screen  with _Putimage for the gradient overlay effect, or stretch a single pixel to draw filled boxes and use as a replacement for LINE BF.

Code: (Select All)

Sub HDBox (x1, y1, x2, y2, R, G, B, A)


    If A <= 0 Then Exit Sub
    If A > 255 Then A = 255


    'only 16 shades of R, G and B respectively, so those values have to be between 0 and 15. Then it picks out the correct pixel based on the gradients layout

    x = Int(R + 16 * G + 256 * (B Mod 4))
    y = Int((256 - A) + 256 * (Int(B / 4) Mod 4))


  'Draws to HARDWARE1

    _PutImage (x1, y1)-(x2 , y2 ), Gradient.Image, 1, (x, y)-(x, y)


End Sub

Added a few comments and removed unnecessary code so that it's hopefully easy to follow even if they can't be run as is.






For text I've recently taken to copying it to a HARDWARE image and then pasting that on HARDWARE1. If I try copying and freeing images every frame then the program crashes, so for now my text command keeps track of what string it has and only copies/frees once.

[SMcNeill]

And since forever and ever and ever ago, I have asked everyone from users to devs to my local priest, *HOW THE BLEEP DO WE USE HARDWARE1*???

I remember answering a few times.

Since my posting rate is bimonthly, I checked every post I ever made ever. 

Here's me telling you about it in 2018:

Set the destination for a hardware image to 1 and it will be displayed on that screen, I think. I don't remember anything else

Man, I wish you would've posted an example of that all those years back!  For some reason, it just didn't sink in what you were saying, without any sort of example to work from, or go by. 

That ",I think" made the answer seem uncertain, and the mention of set the destination to 1 made me think of it as something like:

_DEST 1
_PUTIMAGE ,hardwarehandle

(I wonder if that even works with the above, or is that as wrong as my brain screams at me that it's wrong?   I'm so used to PCOPY 0, 1 that I think of 1 as being a screen page and not a hardware destination layer...)

At least now it appears that we're finally sorting out the details on it and getting it all properly documented for folks, so they won't have to go another six years without understanding it.  Many thanks for trying to tell us Gets.  Apparently we just didn't listen enough to learn what you were saying all those ages ago. 

[SMcNeill]

Just tried it, and it's got to be in the _PUTIMAGE command itself.  It doesn't work if you try and set _DEST to 1 outside of that putimage.

Code: (Select All)

Screen _NewImage(640, 480, 32)



Red = _NewImage(200, 200, 32)

Green = _NewImage(200, 200, 32)



Cls , &HFFFF0000, Red

Cls , &HFF00FF00, Green



RedHW = _CopyImage(Red, 33)

GreenHW = _CopyImage(Green, 33)

order = -1



Do

    k = _KeyHit

    Select Case k

        Case 32 'space will toggle

            order = Not order

            If order Then

                _DisplayOrder _Hardware , _Hardware1

            Else

                _DisplayOrder _Hardware1 , _Hardware

            End If

        Case 27

            System

    End Select

    _Dest 0

    _PutImage (100, 100), RedHW

    _Dest 1

    _PutImage (200, 200), GreenHW 'The comma 1 here says to put that hardware image to Hardware 1!



    _Display

    _Limit 30

Loop