Folks are, once again, struggling to understand and work properly with hardware images. Let's see if I can come up with a nice breakdown of the whole process from top to bottom, to help sort out whatever their problems might be.
1 -- First, Forget the FLUCK about _HARDWARE. Forget about hardware images. Forget even about QB64!! We're going to take a large step back and start at the very beginning by going back to The School of Steve(tm).
Now, in the School of Steve (SOS for shorthand), teachers don't talk to students at all. The only way they communicate is via writing stuff down and having the students read what they write. And another oddball quirk about SOS is that they don't use erasable blackboards. All the school board approves for them is unlimited paint (freely donated by the McNeill Paint Company), and a large sheet of glass and a few magic markers.
So how does the teachers communicate with these limitations, you ask?
Well, they can use paint and draw and print on the walls, or they can use the marker and scribble on the glass as needed. Two completely separate mediums, with two completely different rulesets for working with them. With the wall, if you want it to go back to being a blank canvas, you have to issue a command to one of the students -- "CLS"! This will cause that student to get up and repaint that wall white -- or whatever color you specify for the background color. With that glass sheet? It cleans itself! The marker is water based and evaporates quickly after use!
So obviously, it's plain to see that there's some major differences in the two mediums. The wall is more permanent and persistent, but it requires more work to draw to and erase, while the glass sheet is very quick to scribble on, but has no lasting sustainability.
Congratulations! You now understand one of the major differences in _HARDWARE and _SOFTWARE.
_SOFTWARE images are like that wall. You paint on them. Draw on them. Do whatever you want on them. And, when you're finished, the wall remains as you left it, until someone paints over it in the future.
_HARDWARE images are the glass sheet. Much faster in their simplicity, but impermanent. You make them. _DISPLAY them. They evaporate out of existence.
Two completely separate mediums, two completely separate rulesets for working with them. Toss out everything you know about _SOFTWARE images, if you're going to be working with _HARDWARE images. Once you've did that, then continue on below:
So, with your mind a blank slate, and with you now having no preconceptions of what a hardware image is, or what the ruleset is for working with one, let me give it to you:
1) A hardware image is an immutable image that can NOT change. You finalize it and _LOADIMAGE (image, 33) or _COPYIMAGE(image, 33), to make it a hardware image. You can't print to it. Draw on it. Or alter it in any way, shape, or form. It's a finalized image.
2) A hardware image can only be rendered onto one place -- the _HARDWARE layer. That's it. No need to specify a handle for where you want to put it. It either goes to the hardware layer for rendering, or else it explodes and melts your GPU. It's *REAL* picky about where you can use it...
3) A hardware image is rendered ONLY when _DISPLAY is called, and then it's immediately purged from the GPU.
And... honestly, that's it.
A lot simpler than software images, to be honest. All you can do with them is load them and display them. What's there to be confused about with that??
And with that said, folks *still* end up getting lost, as they're simply not used to working with such simple rulesets. You often see people write code like:
And then they end up saying, "Why doesn't this work? My hardware screen isn't drawing!! Or why is it flickering like an old 1930s movie?!"
It is! The thing is, it's drawing at the _DISPLAY after the call for the hardware screen, and then it's cleared out of the GPU. (Rule Three above!) When the print statements do their thing, they issue a separate _DISPLAY statement which has a blank hardware layer. What you're doing is:
Update software screen with X and Y.
_DISPLAY software, hardware (hardware is blank)
Update hardware screen with the putimage.
_DISPLAY software(it hasn't changed), hardware
See the flicker in there?
Steve's Rule of Thumb here? *Just use one _DISPLAY in your main loop. Do all your drawing/printing and putimageing first, and then _DISPLAY everything with a single call.*
Second problem which folks seem to have -- learning to use layering properly.
Now, let's take a moment and step back to the School of Steve. Did you know that we can do some very impressive layering with the newest paints that McNeill's Paint Company produces -- Invisible Transparency Z(tm)!
Now, we can paint our wall invisible, and then paint and draw on it where we want, so it looks like letters are just floating in midair!
And with the addition of our glass sheets, we can write on them with our markers and sit them in front of our walls!
Or, we can have our students carry our glass sheets and sit them behind our invisible walls! Either way, we can layer drawings now with our walls and our glass sheets!
Now, let's say I draw a big RED CIRCLE on my wall, and I draw a BLUE SQUARE on my glass sheet. If my glass sheet is in front of the wall, what are my students going to see?
The BLUE SQUARE! It's in front of the red circle and is going to block their view to it.
So what if I put my glass sheet on the other side and behind the wall? What will the students see?
A RED CIRCLE inside a BLUE SQUARE! The circle is in front of what portion of the square that it can cover, hiding that portion from view, with the rest of the edges of the square being visible to the class.
That's _DISPLAYORDER in a nutshell!
Hardware images and Software images are on independent layers. You decide which one you want on top with the _DISPLAYORDER command. Is the glass sheet on this side of that invisible wall, or is it on the other side and behind it?
And here's the most common glitch we see with folks with _DISPLAYORDER:
And the complaint here is, "Where's my debugging text?!!"
DUDE!! You took a sledgehammer to the wall, tore it down, and hauled it out of the classroom! You don't even HAVE a wall anymore! With your _DISPLAYORDER statement, you decided you were only going to use hardware images because they're so much faster, and now you're wanting to make use of the software layer which you tossed out!
You can't draw on the wall you no longer have in your classroom. I'm afraid that just doesn't work...
1 -- First, Forget the FLUCK about _HARDWARE. Forget about hardware images. Forget even about QB64!! We're going to take a large step back and start at the very beginning by going back to The School of Steve(tm).
Now, in the School of Steve (SOS for shorthand), teachers don't talk to students at all. The only way they communicate is via writing stuff down and having the students read what they write. And another oddball quirk about SOS is that they don't use erasable blackboards. All the school board approves for them is unlimited paint (freely donated by the McNeill Paint Company), and a large sheet of glass and a few magic markers.
So how does the teachers communicate with these limitations, you ask?
Well, they can use paint and draw and print on the walls, or they can use the marker and scribble on the glass as needed. Two completely separate mediums, with two completely different rulesets for working with them. With the wall, if you want it to go back to being a blank canvas, you have to issue a command to one of the students -- "CLS"! This will cause that student to get up and repaint that wall white -- or whatever color you specify for the background color. With that glass sheet? It cleans itself! The marker is water based and evaporates quickly after use!
So obviously, it's plain to see that there's some major differences in the two mediums. The wall is more permanent and persistent, but it requires more work to draw to and erase, while the glass sheet is very quick to scribble on, but has no lasting sustainability.
Congratulations! You now understand one of the major differences in _HARDWARE and _SOFTWARE.
_SOFTWARE images are like that wall. You paint on them. Draw on them. Do whatever you want on them. And, when you're finished, the wall remains as you left it, until someone paints over it in the future.
_HARDWARE images are the glass sheet. Much faster in their simplicity, but impermanent. You make them. _DISPLAY them. They evaporate out of existence.
Two completely separate mediums, two completely separate rulesets for working with them. Toss out everything you know about _SOFTWARE images, if you're going to be working with _HARDWARE images. Once you've did that, then continue on below:
So, with your mind a blank slate, and with you now having no preconceptions of what a hardware image is, or what the ruleset is for working with one, let me give it to you:
1) A hardware image is an immutable image that can NOT change. You finalize it and _LOADIMAGE (image, 33) or _COPYIMAGE(image, 33), to make it a hardware image. You can't print to it. Draw on it. Or alter it in any way, shape, or form. It's a finalized image.
2) A hardware image can only be rendered onto one place -- the _HARDWARE layer. That's it. No need to specify a handle for where you want to put it. It either goes to the hardware layer for rendering, or else it explodes and melts your GPU. It's *REAL* picky about where you can use it...
3) A hardware image is rendered ONLY when _DISPLAY is called, and then it's immediately purged from the GPU.
And... honestly, that's it.
A lot simpler than software images, to be honest. All you can do with them is load them and display them. What's there to be confused about with that??
And with that said, folks *still* end up getting lost, as they're simply not used to working with such simple rulesets. You often see people write code like:
Code: (Select All)
PRINT "X:"; X
PRINT "Y:"; Y
_DISPLAY 'print the software screen
_PUTIMAGE ,HardWare 'put the hardware screen in place
_DISPLAY 'show that hardware screenAnd then they end up saying, "Why doesn't this work? My hardware screen isn't drawing!! Or why is it flickering like an old 1930s movie?!"
It is! The thing is, it's drawing at the _DISPLAY after the call for the hardware screen, and then it's cleared out of the GPU. (Rule Three above!) When the print statements do their thing, they issue a separate _DISPLAY statement which has a blank hardware layer. What you're doing is:
Update software screen with X and Y.
_DISPLAY software, hardware (hardware is blank)
Update hardware screen with the putimage.
_DISPLAY software(it hasn't changed), hardware
See the flicker in there?
Steve's Rule of Thumb here? *Just use one _DISPLAY in your main loop. Do all your drawing/printing and putimageing first, and then _DISPLAY everything with a single call.*
Second problem which folks seem to have -- learning to use layering properly.
Now, let's take a moment and step back to the School of Steve. Did you know that we can do some very impressive layering with the newest paints that McNeill's Paint Company produces -- Invisible Transparency Z(tm)!
Now, we can paint our wall invisible, and then paint and draw on it where we want, so it looks like letters are just floating in midair!
And with the addition of our glass sheets, we can write on them with our markers and sit them in front of our walls!
Or, we can have our students carry our glass sheets and sit them behind our invisible walls! Either way, we can layer drawings now with our walls and our glass sheets!
Now, let's say I draw a big RED CIRCLE on my wall, and I draw a BLUE SQUARE on my glass sheet. If my glass sheet is in front of the wall, what are my students going to see?
The BLUE SQUARE! It's in front of the red circle and is going to block their view to it.
So what if I put my glass sheet on the other side and behind the wall? What will the students see?
A RED CIRCLE inside a BLUE SQUARE! The circle is in front of what portion of the square that it can cover, hiding that portion from view, with the rest of the edges of the square being visible to the class.
That's _DISPLAYORDER in a nutshell!
Hardware images and Software images are on independent layers. You decide which one you want on top with the _DISPLAYORDER command. Is the glass sheet on this side of that invisible wall, or is it on the other side and behind it?
And here's the most common glitch we see with folks with _DISPLAYORDER:
Code: (Select All)
_DISPLAYORDER _HARDWARE
PRINT "X:"; X
PRINT "Y:"; Y
_PUTIMAGE ,HardWare
_DISPLAYAnd the complaint here is, "Where's my debugging text?!!"
DUDE!! You took a sledgehammer to the wall, tore it down, and hauled it out of the classroom! You don't even HAVE a wall anymore! With your _DISPLAYORDER statement, you decided you were only going to use hardware images because they're so much faster, and now you're wanting to make use of the software layer which you tossed out!
You can't draw on the wall you no longer have in your classroom. I'm afraid that just doesn't work...