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.
