HW image version of this little stupid thing

[SMcNeill]

It's stunning that the documentation does not have a good example of hardware image use.

@SMcNeill

And a few more questions:

Do hardware images have to be 32bit? If so make sure that gets added to the docs.

I recalled a previous time when I was doing something and @a740g told me how I could still have all the benefits of pixel art and indexed palette (256 colors) but then simply `_PUTIMAGE` the 256 color image to the 32bit canvas, etc.

Mode 33 also needs more prominent mentions I think. It's an odd thing that no one would really consider.

Maybe add a hardware image example in `_COPYIMAGE` and `_PUTIMAGE`, call out mode `33` and also create a separate section in the wiki for hardware images which has SOS tutorials.

Thanks all!

Hardware images are unusual little beasts, just from the fact that they exist wholly inside their own little display layer.  With this odd trait in mind, let's take a look at something unusual which we can do:

Code: (Select All)

SCREEN 0 'I'm going to use a text only screen

tempHWscreen = _NEWIMAGE(64, 40, 32)

_DEST tempHWscreen

CLS , &HFFFF0000 'just color that little 64x40 block of screen RED

HWscreen = _COPYIMAGE(tempHWscreen, 33)

_FREEIMAGE tempHWscreen



xdirection = 1: ydirection = 1

DO

    CLS

    FOR i = 0 TO 16

        COLOR i, 8 - INT(i / 2)

        PRINT "Screen 0 Colors!  This is COLOR "; i, 8 - INT(i / 2)

    NEXT

    x = x + xdirection: y = y + ydirection

    IF x < 0 OR x > 640 THEN xdirection = -xdirection

    IF y < 0 OR y > 400 THEN ydirection = -ydirection

    _PUTIMAGE (x, y), HWscreen

    _DISPLAY

    _LIMIT 100

LOOP UNTIL _KEYHIT

SYSTEM

Run the above and notice what screen mode our program is in...   then look at the code a little closer...

We're in a SCREEN 0, text-only screen mode, and yet we're still displaying and animating a graphical box across the screen pixel by pixel!!

How the BLEEP is that possible??

It's because QB64 has a completely separate and independent hardware layer, than it has for any of the software layers.  SCREEN 0 is software.  HWscreen is hardware.   The two are 100% independent from each other.

Hardware layers are always the size of the visible screen (640 x 400 pixels in this case), and are always 32-bit color screens.  It doesn't matter if you _COPYIMAGE a 256-color screen into a hardware image, it's automatically converted up to 32-bit colors.  Draw on whatever software screen which you prefer; when you're ready to turn it into a hardware image, just call _COPYIMAGE and let it automatically handle the conversion for you.

[TerryRitchie]

It's stunning that the documentation does not have a good example of hardware image use.

@SMcNeill

And a few more questions:

Do hardware images have to be 32bit? If so make sure that gets added to the docs.

I recalled a previous time when I was doing something and @a740g told me how I could still have all the benefits of pixel art and indexed palette (256 colors) but then simply `_PUTIMAGE` the 256 color image to the 32bit canvas, etc.

Mode 33 also needs more prominent mentions I think. It's an odd thing that no one would really consider.

Maybe add a hardware image example in `_COPYIMAGE` and `_PUTIMAGE`, call out mode `33` and also create a separate section in the wiki for hardware images which has SOS tutorials.

Thanks all!

Hardware images are unusual little beasts, just from the fact that they exist wholly inside their own little display layer.  With this odd trait in mind, let's take a look at something unusual which we can do:

Code: (Select All)

SCREEN 0 'I'm going to use a text only screen

tempHWscreen = _NEWIMAGE(64, 40, 32)

_DEST tempHWscreen

CLS , &HFFFF0000 'just color that little 64x40 block of screen RED

HWscreen = _COPYIMAGE(tempHWscreen, 33)

_FREEIMAGE tempHWscreen



xdirection = 1: ydirection = 1

DO

    CLS

    FOR i = 0 TO 16

        COLOR i, 8 - INT(i / 2)

        PRINT "Screen 0 Colors!  This is COLOR "; i, 8 - INT(i / 2)

    NEXT

    x = x + xdirection: y = y + ydirection

    IF x < 0 OR x > 640 THEN xdirection = -xdirection

    IF y < 0 OR y > 400 THEN ydirection = -ydirection

    _PUTIMAGE (x, y), HWscreen

    _DISPLAY

    _LIMIT 100

LOOP UNTIL _KEYHIT

SYSTEM

Run the above and notice what screen mode our program is in...   then look at the code a little closer...

We're in a SCREEN 0, text-only screen mode, and yet we're still displaying and animating a graphical box across the screen pixel by pixel!!

How the BLEEP is that possible??

It's because QB64 has a completely separate and independent hardware layer, than it has for any of the software layers.  SCREEN 0 is software.  HWscreen is hardware.   The two are 100% independent from each other.

Hardware layers are always the size of the visible screen (640 x 400 pixels in this case), and are always 32-bit color screens.  It doesn't matter if you _COPYIMAGE a 256-color screen into a hardware image, it's automatically converted up to 32-bit colors.  Draw on whatever software screen which you prefer; when you're ready to turn it into a hardware image, just call _COPYIMAGE and let it automatically handle the conversion for you.

Now that's cool! I had not even considered this.

[grymmjack]

Run the above and notice what screen mode our program is in...   then look at the code a little closer...

We're in a SCREEN 0, text-only screen mode, and yet we're still displaying and animating a graphical box across the screen pixel by pixel!!

How the BLEEP is that possible??

It's because QB64 has a completely separate and independent hardware layer, than it has for any of the software layers.  SCREEN 0 is software.  HWscreen is hardware.   The two are 100% independent from each other.

Hardware layers are always the size of the visible screen (640 x 400 pixels in this case), and are always 32-bit color screens.  It doesn't matter if you _COPYIMAGE a 256-color screen into a hardware image, it's automatically converted up to 32-bit colors.  Draw on whatever software screen which you prefer; when you're ready to turn it into a hardware image, just call _COPYIMAGE and let it automatically handle the conversion for you.

Whoa...

OK So..you said that we can use a 256 color image and `_COPYIMAGE` that to a hardware image, except that it didn't work for me...

To get my 256 color image onto a hardware layer I had to:

1. Create the 256 color image
   
2. Copy the 256 color image to a 32 bit image
   
3. Copy the 32 bit image to a 33 mode image
   

Or maybe it does work as you say but the colors of the 256 image for me were all black when I did not do step 2 in-between to get 32->33 ... ?

See below, this does not crash but only renders black. I used the code we were discussing in discord to test and just changed one line (line 35):

`ALIEN_HW& = _COPYIMAGE(ALIEN_32&, 32)` -> `ALIEN_HW& = _COPYIMAGE(ALIEN_SPRITE&, 33)`

Code: (Select All)

OPTION _EXPLICIT



DIM AS INTEGER lim, st, x, y, w, h

DIM AS SINGLE d

DIM AS STRING FGC, BGC, T, M, B, F, ALIEN

DIM AS LONG ALIEN_SPRITE, ALIEN_32, ALIEN_HW, CANVAS



CANVAS& = _NEWIMAGE(320, 200, 32)

SCREEN CANVAS&

_FULLSCREEN _SQUAREPIXELS



d! = 0

lim% = 60

st% = 3

x% = 0

y% = 10

w% = 50

h% = 50



FGC$ = "12": BGC$ = "8"

T$ = "C" + FGC$ + " R10 E5 R20 F5 R10 BL50"

M$ = "D20 BR50 BU20 D20              BL50"

B$ = "D10 E10 U10 R30 D10 F10 U10    BL50"

F$ = "BU20 BF5 P " + BGC$ + "," + FGC$

ALIEN$ = T$ + M$ + B$ + F$



ALIEN_SPRITE& = _NEWIMAGE(w% + 1, h% + 1, 256)

_DEST ALIEN_SPRITE&

PSET (0, 10)

DRAW ALIEN$

_CLEARCOLOR 0, ALIEN_SPRITE&

ALIEN_32& = _NEWIMAGE(w% + 1, h% + 1, 32)

_SOURCE ALIEN_SPRITE&: _DEST ALIEN_32&: _PUTIMAGE

ALIEN_HW& = _COPYIMAGE(ALIEN_SPRITE&, 33)



_DEST CANVAS&

CLS , _RGB32(0, 0, 255)

DO

    x% = x% + st%

    IF x% <= 0 OR x% >= _WIDTH - w% THEN st% = -st%

    _PUTIMAGE (x%, y%), ALIEN_HW&

    _DISPLAY

    _LIMIT 60

    CLS , _RGB32(0, 0, 255)

LOOP UNTIL _KEYHIT = 27



_FREEIMAGE ALIEN_SPRITE&

_FREEIMAGE ALIEN_HW&



SYSTEM

[grymmjack]

Run the above and notice what screen mode our program is in...   then look at the code a little closer...

We're in a SCREEN 0, text-only screen mode, and yet we're still displaying and animating a graphical box across the screen pixel by pixel!!

How the BLEEP is that possible??

It's because QB64 has a completely separate and independent hardware layer, than it has for any of the software layers.  SCREEN 0 is software.  HWscreen is hardware.   The two are 100% independent from each other.

Hardware layers are always the size of the visible screen (640 x 400 pixels in this case), and are always 32-bit color screens.  It doesn't matter if you _COPYIMAGE a 256-color screen into a hardware image, it's automatically converted up to 32-bit colors.  Draw on whatever software screen which you prefer; when you're ready to turn it into a hardware image, just call _COPYIMAGE and let it automatically handle the conversion for you.

Adding `_DISPLAYORDER _HARDWARE, _SOFTWARE` above the `DO` loop is a great way to show that rendering z-order layers. This shows the software layer on top?

Switching to `_DISPLAYORDER _SOFTWARE, _HARDWARE` brings back the hardware on top?

Also should go in wiki.

[grymmjack]

I added a toggle for your example to make it a little easier to understand, @SMcNeill

Now it has a toggle and a message as well as the box is semi-transparent to demonstrate further the concept of "layers", also made the red block bigger and changed `_LIMIT` to `60`also added a `_BLEND` (default) and `_DONTBLEND` example to the box with the text "HARDWARE" like @TerryRitchie used in his example.

Press `SPACE` to switch the `_DISPLAYORDER`, `ENTER` to pause/unpause, and `ESC` to exit.

Code: (Select All)

 SCREEN 0 'I'm going to use a text only screen

mode = -1

paused = 0

tempHWscreen = _NEWIMAGE(64*2, 40*2, 32)

_DEST tempHWscreen

CLS , &HCCFF0000 'just color that little 64x40 block of screen RED

_BLEND

COLOR &HFFFFFFFF: _PRINTMODE _KEEPBACKGROUND: _PRINTSTRING (35, 25), "HARDWARE"

_DONTBLEND

COLOR 0: _PRINTMODE _FILLBACKGROUND: _PRINTSTRING (20, 45), CHR$(219) + " HARDWARE " + CHR$(219)

HWscreen = _COPYIMAGE(tempHWscreen, 33)

_FREEIMAGE tempHWscreen

xdirection = 1: ydirection = 1

DO

    k = _KEYHIT

    IF mode THEN

        _DISPLAYORDER _SOFTWARE, _HARDWARE

    ELSE

        _DISPLAYORDER _HARDWARE, _SOFTWARE

    END IF

    CLS

    COLOR 11

    IF paused THEN p$ = "Unpause" ELSE p$ = "Pause"

    PRINT "[SPACE]=Change _DISPLAYORDER, [ENTER]="+p$+", [ESC]=Quit";

    IF paused THEN PRINT "   * PAUSED *";

    PRINT

    FOR i = 0 TO 16

        COLOR i, 8 - INT(i / 2)

        PRINT "Screen 0 Colors!  This is COLOR "; i, 8 - INT(i / 2)

    NEXT

    PRINT

    COLOR 14

    IF mode THEN

        PRINT "_DISPLAYORDER _SOFTWARE, _HARDWARE (DEFAULT hardware on top of software)"

    ELSE

        PRINT "_DISPLAYORDER _HARDWARE, _SOFTWARE (software on top of hardware)"

    END IF

    IF NOT paused THEN

        x = x + xdirection: y = y + ydirection

        IF x < 0 OR x > 640 THEN xdirection = -xdirection

        IF y < 0 OR y > 400 THEN ydirection = -ydirection

    END IF

    _PUTIMAGE (x, y), HWscreen

    _DISPLAY

    _LIMIT 60

    IF k=32 THEN mode = NOT mode

    IF k=13 THEN paused = NOT paused

LOOP UNTIL k=27

SYSTEM

I have to ask.. why `_DONTBLEND` looks like it's blending, and `_BLEND` doesn't? Also, in a HW image it looks like when `_DONTBLEND` color 0 = transparent? why is that?

[mnrvovrfc]

Don't let Pete see that. He might like it for a moment, or he could get angry for "cheating" on his SCREEN 0. He might just go and convert all his programs to do the transparency.

Wow in early 16-bit days this is just unheard of. A chance to do it with 320x200 with 256 colors. Maybe somebody wrote a code library for it.

We're in a SCREEN 0, text-only screen mode, and yet we're still displaying and animating a graphical box across the screen pixel by pixel!!

How the BLEEP is that possible??

It's because QB64 has a completely separate and independent hardware layer, than it has for any of the software layers.  SCREEN 0 is software.  HWscreen is hardware.   The two are 100% independent from each other.

Galleon took the fateful decision to go away from console mode like most other language products, so we could have a SCREEN 0 that is unique. One that is inflexible to some people who would like to have scrollbars for their heavy use of PRINT. One time when I looked over many things in "libqb.cpp" I was trying to find the Win API console commands or something related. "But how is this programming system doing the text-mode screen?" I kept asking. I only saw a bunch of scary bitwise math repeated eight times LOL in the code. Oh yeah but that's for graphics, where's the handling for text?

Try doing that in ordinary "CMD.EXE" box! Maybe that's why many people on Linux are begging for Wayland to take the showing off in terminals to a new level.