+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: QB64 Rising (https://staging.qb64phoenix.com/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://staging.qb64phoenix.com/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://staging.qb64phoenix.com/forumdisplay.php?fid=10)
+---- Thread: Having screen blinking issue using Hardware Images (/showthread.php?tid=1277)
Having screen blinking issue using Hardware Images - Dav - 12-14-2022
I started working on the QB64 video+audio format maker I shared at the old forum, adding playback controls, etc. I want to load images as Hardware images because they seem to display much faster, will allow better frame rates, but when doing that the screen blanks horrible. Not sure why and what can fix the blinking. Hoping to discover a solution or I will have to stick when the slower regular way.
I've attached the code and a test QBV file. As is the video displays ok, but if you comment out line #53 and use #54 instead (hardware images) the screen will blink very badly. The video is a low resolution one for testing purposes, me playing a short Christmas song on the piano.
Thanks for any help.
- Dav
[attachment=1221]
RE: Having screen blinking issue using Hardware Images - SMcNeill - 12-14-2022
Here's the glitch:
Code: (Select All)
_Display
If _ScreenIcon = 0 Then _AutoDisplayHardware images only stay in your GPU buffer for a single call of _DISPLAY, and then they flush themselves clean. What you're doing here is basically:
_DISPLAY the Hardware Image
IF ScreenIcon = 0 THEN _DISPLAY ... umm... a blank screen. There's nothing in the buffer now. We just cleared it!
Image, Nothing, Image, Nothing, Image, Nothing.... <-- And there's the old style film projector flashing that you're seeing in your code.
If you're going to use hardware images, stick to _DISPLAY and let the one call update your whole screen at once. Adding in the _AUTODISPLAY with the _DISPLAY ends up giving you multiple calls to display, resulting in the issue that you're having.
Unrelated note: There's really no need to have that KILL in there. While the program is running, it's going to create and overwrite that file repeatedly. Save a little disk wear and just reserve that KILL for when the user exits the program.
Unrelated note2: Since these are all so small, I'd honestly just make an array for my images, load them all once at start-up, and then forgot about them. One disk access to read and extract your images, and that's all you'd ever need. From then on, you just run through the array. (I wouldn't do a whole movie in such a manner, but a small array of just a few dozen images? Why not?)
RE: Having screen blinking issue using Hardware Images - Dav - 12-14-2022
That's it, Steve! Thanks . Yeah, I'm not sure 100% what Hardware images are to be honest. But now that the glitch is gone I can make higher quality videos without dropping frame rates. Loading images into an array does make sense for small clips.
Thanks again!
- Dav
RE: Having screen blinking issue using Hardware Images - SMcNeill - 12-14-2022
The biggest differences in the software and hardware images are these:
1) Software images are the screens and images which we build stuff on. We print to them, PSET them, use LINE, circle or whatever else onto them. They're in the CPU and easy for us to change at a moments notice.
Hardware images, on the other hand, tend to just be complete textures that your GPU is ready to push out to the screen and then be done with them. You don't really do any reading from them, or plotting to them. They're more or less set in stone and waiting for your GPU to make use of them as they already exist.
2) Software images tend to be persistent. Draw to your screen and that drawing stays on the screen. That's why you could have multiple calls to display and not have any issues with the software image -- the screen was still there to display whenever you wanted it to!
Hardware images, aren't like that. You _PUTIMAGE them into the GPU buffer, they get pushed to the screen with a _DISPLAY, and then they flush themselves from memory. As you see in your code here, multiple calls to _DISPLAY ends up getting you undesired results, because of this feature. Your GPU doesn't tend to hold onto information sent to it for VRAM, like your RAM does. Think of it almost in terms of RAM Drive vs Hard Drive. What goes there is temporary. Sure, it's a lot faster, but it's definitely not persistent! In the case of hardware images, they display once and then are gone. You'd have to putimage them back for them to display once again.
3) Software images require a destination when using _PUTIMAGE with them. _PUTIMAGE ,(what), (where) <-- If that (where) is left blank, it defaults to your current _DEST.
Hardware images have their own layer, and you can't put them anywhere else. _PUTIMAGE ,(what), (BLANK) <-- Where you'd normally specify a _DEST, a hardware image just completely ignores that. We have a software layer to work with, and a hardware layer, AND an OpenGL layer, all in QB64. Each of these is completely independent of the other -- thus, thanks to this layering, you can use a HARDWARE layer with a SCREEN 0 SOFTWARE layer.
YES, it *is* possible to put images and graphics onto the display, all while running a SCREEN 0 program, if that's what one so desires.
4) If you use _MEM and _MEMIMAGE, I don't *THINK* they work with hardware images. Hardware images are made to basically be Read-Only, so they're not generally available for us to edit, read, or work with. Basically, if you need to be altering the image at all, then you need to be working with a software image. Do the _COPYIMAGE(handle, 33) once you're ready to convert your software image into a hardware image.
And, unless someone else can think of something to add or clarify, I think that's basically the differences in the two. Hardware images are, at their heart with how we use them, read-only GPU textures that get pushed out onto the display once and then are gone. Software images are CPU mem blocks of image information, that hang around and with which we can change and edit to our hearts contentment.
If there's any other particular questions anyone has regarding the two, feel free to ask, and I'll answer as best as I can for you guys.
RE: Having screen blinking issue using Hardware Images - Dav - 12-14-2022
Very clear and understandable. This would make a good addition to your book. The wiki mentions hardware images, but I never recall seeing an explanation on what they are, or why/how to use them. Thanks so much.
- Dav