OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - Printable Version +- 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
|
RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - SMcNeill - 09-21-2024 (09-21-2024, 02:27 PM)RhoSigma Wrote: 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: 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. RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - DSMan195276 - 09-22-2024 (09-21-2024, 02:27 PM)RhoSigma Wrote: 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._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 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). RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - RhoSigma - 09-22-2024 (Yesterday, 02:18 AM)DSMan195276 Wrote:(09-21-2024, 02:27 PM)RhoSigma Wrote: 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._GLRENDER is just a fancy _DISPLAYORDER, they modify the same thing. They have this correspondence: 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. RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - Gets - 09-22-2024 Quote: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: Quote:Set the destination for a hardware image to 1 and it will be displayed on that screen, I think. I don't remember anything elsehttps://qb64forum.alephc.xyz/index.php?topic=584.msg4354#msg4354 and how to use it from 2020: Quote: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 imageshttps://qb64forum.alephc.xyz/index.php?topic=2859.msg121275#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 Code: (Select All) Sub HDBox (x1, y1, x2, y2, R, G, B, A) 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. RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - SMcNeill - 09-22-2024 (Yesterday, 05:39 PM)Gets Wrote:Quote: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. 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. RE: OMG! OMG! OMG! I found QB64's lost HOLY GRAIL!! - SMcNeill - 09-22-2024 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)
|