+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Programs (https://qb64phoenix.com/forum/forumdisplay.php?fid=7)
+---- Thread: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! (/showthread.php?tid=3058)
Pages:
1
2
OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - SMcNeill - 09-20-2024
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!!!
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - SMcNeill - 09-20-2024
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!
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - TerryRitchie - 09-21-2024
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.
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - SMcNeill - 09-21-2024
(09-21-2024, 12:19 AM)TerryRitchie Wrote: 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.
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - Pete - 09-21-2024
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.
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - TerryRitchie - 09-21-2024
(09-21-2024, 01:36 AM)SMcNeill Wrote:_PUTIMAGE needs to be updated in the wiki to reflect this.(09-21-2024, 12:19 AM)TerryRitchie Wrote: 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.
This should be mentioned in the hardware images section too: https://qb64phoenix.com/qb64wiki/index.php/Hardware_images
I'll also be updating the tutorial to add this new functionality to hardware images.
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - RhoSigma - 09-21-2024
(09-21-2024, 02:46 AM)TerryRitchie Wrote: _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.php/Hardware_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.
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - RhoSigma - 09-21-2024
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?
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - SMcNeill - 09-21-2024
(09-21-2024, 11:13 AM)RhoSigma Wrote: 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.
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - RhoSigma - 09-21-2024
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?