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

[SMcNeill]

OMG!

OMG!! 

OMG!!!

Are you guys as excited as I am??!!

OMG! OMG!! OMG!!!  WOOOOO!!!!

I has finally found one of the most baffling parts of QB64 that has been missing and lost and disappeared to us just like the Holy Grail has long been disappeared!!

I give to you....   Dum dum de dummmmm.....

HARDWARE1:

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

    _PutImage (100, 100), RedHW

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

    _Display

    _Limit 30

Loop

Forever and ever and ever and ever and ever and ever, if you look at the command _DISPLAYORDER, you see this:

Code: (Select All)

_DISPLAYORDER [{_SOFTWARE|_HARDWARE|_HARDWARE1|_GLRENDER}][, ...][, ...][, ...][, ...]

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*???

We have 4 screens to layer to and set in any sort of display order we want.  (Maybe even more than that, but I haven't worried with trying ,2 or ,3 or whatnot yet to see...)   

We have:
_SOFTWARE  <-- the software screen
_GLRENDER  <-- the SUB _GL stuff
_HARDWARE  <-- hardware image
_HARDWARE1  <-- a second hardware screen

By changing the _DISPLAYORDER, we can change which order things are drawn on our screen.  Think of a game:  Background (clouds and buildings), and then the character on one overlay with enemies, and then bushes and trees and such in front of him.  We can choose the way we want to layer those screens on top of each other.

But then, the question arises, like I've asked for ages, *HOW DOES ONE PUT ANYTHING ON HARDWARE1?????*

---

The answer to that is very simple:  _PUTIMAGE (x,y)-(x1,y1), hardware_image_handle, 1

See that comma 1 there at the end??

That's all it takes to put it on _HARDWARE1 instead of _HARDWARE.

WHO KNEW????!!!

I feel like I has found the long long lost treasure of QB64. 

Try the demo above and see if it makes sense how those two layers are being overlaid on top of each other.  Each is a perfectly independent layer, and has zero impact on the other layers.

WOOOW OH WOW OH WOW!!! 

[SMcNeill]

NOTE: Full credit to Matt, offbyone, DSMan195276. (Same great fellow, who has trouble using the same name in more than one place it seems. )

Matt's the one who dug the syntax out of the code. I just put together the demo and tested it via what he uncovered. Everyone give him lots of hugging and squeezing on this find as well!

[TerryRitchie]

Wow, how stupidly simple to implement. Kudos to @DSMan195276 for figuring this out.

Have you tested how many hardware layers can be implemented yet? I'm hoping the answer is as many as available memory allows.

[SMcNeill]

Wow, how stupidly simple to implement. Kudos to @DSMan195276 for figuring this out.

Have you tested how many hardware layers can be implemented yet? I'm hoping the answer is as many as available memory allows.

Only two as far as I can tell from testing.  

_DISPLAYORDER _HARDWARE2   <-- This, for example will error out

_PutImage (300, 100), BlueHW, 2 <-- This, will also error out.


So we only have 2 hardware layers with which to use -- but that's now twice what we had before, and FINALLY answers the question about how the heck to make use of the Hardware1 layer.

[Pete]

You guys better not have wrecked SCREEN 0 by implementing this non-sense, or you'll be hearing from my gardener. 

Seriously, in California they make as much as lawyers make in Virginia.

Pete  

- Making hardware easy.

[TerryRitchie]

Wow, how stupidly simple to implement. Kudos to @DSMan195276 for figuring this out.

Have you tested how many hardware layers can be implemented yet? I'm hoping the answer is as many as available memory allows.

Only two as far as I can tell from testing.  

_DISPLAYORDER _HARDWARE2   <-- This, for example will error out

_PutImage (300, 100), BlueHW, 2    <--  This, will also error out.


So we only have 2 hardware layers with which to use  -- but that's now twice what we had before, and FINALLY answers the question about how the heck to make use of the Hardware1 layer. 

_PUTIMAGE needs to be updated in the wiki to reflect this.

This should be mentioned in the hardware images section too: https://qb64phoenix.com/qb64wiki/index.p...are_images

I'll also be updating the tutorial to add this new functionality to hardware images.

[RhoSigma]

_PUTIMAGE needs to be updated in the wiki to reflect this.

This should be mentioned in the hardware images section too: https://qb64phoenix.com/qb64wiki/index.p...are_images

I'll also be updating the tutorial to add this new functionality to hardware images.

I'll look to clarify the respective wiki pages asap, that's a valuable find indeed.

[RhoSigma]

But how are these two playing together? Seems to me as they could badly interfere with each other regarding the software and opengl layers.

https://qb64phoenix.com/qb64wiki/index.php/DISPLAYORDER
https://qb64phoenix.com/qb64wiki/index.php/GLRENDER

EDIT:
And how's about efficiency? If I only use the software layer in my program, does it make sense to place a
_DISPLAYORDER _SOFTWARE on top of my program to disable the hardware and opengl layers for the sake to make the _DISPLAY refresh more efficient and maybe allowing for somewhat higher FPS rates?
Or is the refresh smart enough to know in which layers content was rendered and needs to be updated?

[SMcNeill]

But how are these two playing together? Seems to me as they could badly interfere with each other regarding the software and opengl layers.

https://qb64phoenix.com/qb64wiki/index.php/DISPLAYORDER
https://qb64phoenix.com/qb64wiki/index.php/GLRENDER

EDIT:
And how's about efficiency? If I only use the software layer in my program, does it make sense to place a
_DISPLAYORDER _SOFTWARE on top of my program to disable the hardware and opengl layers for the sake to make the _DISPLAY refresh more efficient and maybe allowing for somewhat higher FPS rates?
Or is the refresh smart enough to know in which layers content was rendered and needs to be updated?

I makes a helluva difference if you just use _DISPLAYORDER _HARDWARE and skip the software layer completely.  Like several thousand times faster.

But, with the speed which a blank _HARDWARE screen would be rendered, would it make any noticeable difference to use _DISPLAYORDER _SOFTWARE only?   Not that I've noticed.

Think of it like a fellow walking down the highway with a car keeping pace with them.   If that guy walking goes away, that car can zoom on down the road freely.   If the car goes away?  That's still just a fellow walking down the highway.

That said, It wouldn't hurt anything to just use a _DISPLAYORDER _SOFTWARE in your code.  Heck, after you average out the speed to draw 100,000 frames, you might actually save 0.001 seconds rendering or something.  It'd not going to make it any slower on you.  I just don't think it's going to make any sort of real increase in speed for you.  Any gains are going to be minimal at best, nonexistent at worst.

[RhoSigma]

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?