QB64 Phoenix Edition
about Hardware Images and _DisplayOrder,Help! - 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: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: about Hardware Images and _DisplayOrder,Help! (/showthread.php?tid=4459)

Pages: 1 2

about Hardware Images and _DisplayOrder,Help! - qbfans - 02-10-2026

Hello everyone, I am working on a program about Go. Because the circle command doesn't produce good results, I am using SVG to draw the pieces and using loadimage. Here's a snippet of the code. During testing, software mode 32 works fine, but in hardware mode 33, some issues arise that I can't handle. I hope to get your help. Specifically, I directly putimage to the hardware layer and set _DisplayOrder _Hardware, _Software, so that the marks I drew on the pieces are visible. However, for my program, I need to draw something on the screen before putimage. In the code, I simply drew a filled rectangle. With this, the software layer is at the bottom by default, so the pieces are visible, but the marks on the pieces repeatedly do not show. If I set _DisplayOrder _Hardware, _Software with hardware at the bottom, the pieces are covered by the rectangle. What I don’t understand is that if I putimage without drawing the rectangle first, the marks on the pieces show up. By default, software is at the bottom in _DisplayOrder, so theoretically it should be covered by the hardware pieces. After repeated testing, I am getting more and more confused. How can I achieve the effect I want? My English is very poor, all translated by DeepL, so please forgive any mistakes. Thank you all.
Code: (Select All)
'$Console

$Color:32

Dim As String svgHeader, svgFooter, svgW, svgB

Dim As String svgBc, svgWc, finalSvgB, finalSvgW, svgDef

Dim As Long sImgB, sImgW





svgHeader = "<svg width='40' height='40' xmlns='http://www.w3.org/2000/svg'>" + Chr$(10) + "<defs>"

'white stone gradient

svgW = svgW + "<radialGradient id='simpleWhite' cx='50%' cy='50%' r='50%'>"

svgW = svgW + "<stop offset='0%' stop-color='#ffffff'/>"

svgW = svgW + "<stop offset='100%' stop-color='#dddddd'/>"

svgW = svgW + "</radialGradient>" + Chr$(10)

'black stone gradient

svgB = svgB + "<radialGradient id='simpleBlack' cx='48%' cy='48%' r='52%'>"

svgB = svgB + "<stop offset='0%' stop-color='#777777'/>"

svgB = svgB + "<stop offset='100%' stop-color='#222222'/>"

svgB = svgB + "</radialGradient>"

svgDef = svgDef + "</defs>" + Chr$(10)

svgBc = svgBc + "<circle cx='20' cy = '20' r = '20' fill = 'url(#simpleBlack)' />" + Chr$(10) ' black stone

svgWc = svgWc + "<circle cx='20' cy = '20' r = '20' fill = 'url(#simpleWhite)' />" + Chr$(10) ' white stone

svgFooter = svgFooter + "</svg>"

finalSvgB = svgHeader + svgB + svgDef + svgBc + svgFooter

finalSvgW = svgHeader + svgW + svgDef + svgWc + svgFooter

'_Echo finalSvgB

'_Echo finalSvgW

sImgB = _LoadImage(finalSvgB, 33, "memory")

sImgW = _LoadImage(finalSvgW, 33, "memory")

't& = _NewImage(800, 600, 32)

'_Dest t&

'Line (0, 0)-(799, 599), Peach, BF

'board_hw& = _CopyImage(t&, 33)

_Dest 0

'_FreeImage t&



Screen _NewImage(800, 600, 32)



'_DisplayOrder _Hardware1 , _Hardware , _Software

Do

    _Limit 30

    Line (0, 0)-(799, 599), Peach, BF

    '_PutImage (0, 0), board_hw&



    _PutImage (10, 10), sImgW

    _PutImage (10, 110), sImgB

    Line (25, 125)-Step(10, 10), Red, BF

    Color Black, 0

    _UPrintString (20, 25), "119"



    _Display

Loop Until InKey$ = Chr$(27)

Sleep

_FreeImage sImgW

_FreeImage sImgB

System


RE: about Hardware Images and _DisplayOrder,Help! - SMcNeill - 02-10-2026

Do
    Line (0, 0)-(799, 599), Peach, BF

    _PutImage (10, 10), sImgW
    _PutImage (10, 110), sImgB
    _Display
Loop Until InKey$ = Chr$(27)

Notice what I've highlighted here and you'll see the problem.  

The line statement is basically putting a solid color over the entire screen. layer.
You're then putting your images over the hardware layer.

Thing of these as two different sheets of glass.   Normally when layering sheets of glass, you'd use TRANSPARENT glass.  

Think along the lines of a piece of glass ten inches by ten inches in size, with a logo etched all nice and colorful on it that's three inches by three inches.

Now, think think of a second piece of glass that is solid PEACH color and layer those sheets of glass.

If your Peach sheet of glass is on the bottom, and the transparent piece with the logo is on top, all is fine.  When you look at that layered masterpiece, you'd see the peach background and then the logo would be visible over it.

But flip that order around.  Lay the transparent glass with the logo on the bottom and then put that solid peach sheet on top of it.  You can't see through that solid sheet of peach color and thus that logo is invisible and hidden completely.

That's what you've got going on here.   I don't know enough about SVG files to decipher the images you're making this early in the morning, so I don't know if they're full alpha images or not (solid colors with no background for layering), but the LINE statement *IS* creating a solid peach background image.   If it's on the bottom and the hardware images laid on top of it, then you should be able to see those hardware images.  But if it's on the top and the hardware images below it, you're not going to see anything.

And note that with your RED square, it's still on the SOFTWARE layer.  It's basically part of the peach background, like some kid stuck a nice red sticker to that layer of solid peach colored glass.  If you put that solid logo over it, like in the case of the black hardware image here, then you're not going to see it.

It's all a case of 100% alpha and solid colors working with those layers.  I seems like what you're looking for is something with three layers to it, and in that case you'd probably want that red box to be the THIRD layer.

redbox = _NEWIMAGE(boxWide, boxTall, 32) 'make a screen the size of that red box that you want
CLS ,RED, redbox 'color it red
redboxHW = _COPYIMAGE(redbox, 33) 'make a hardware version of that red box
_FREEIMAGE redbox 'free the software version as you're not going to use it for anything else.

LINE (....), PEACH 'put the peach background down
_PUTIMAGE (....), hardImage 'put your hardware image over it
_PUTIMAGE (....), redboxHW, 1 'put the red box on the second hardware image and lay it over the first.


All of these are solid alpha colors and non-transparent.  Layering is absolute and matters completely.  You can't just draw on your same software layer and then expect it to be BOTH below and above your hardware layer.  If you're looking for that effect, you need THREE layers.

_DISPLAYORDER Software, _Hardware, _Hardware1

Software on the bottom, the hardware circle on top of it, the redbox on top of that.

Drawing the redbox on the same screen as the peach background just isn't going to cut it.  You have two layers and since both are solid, whichever is on top is going to cover the other.  Either the peach background with a red box will cover the black circles, or the black circles will cover the peach background with the red box.  It's impossible to layer that black circle between the peach and red when they're both on the same sheet of glass.  You need three layers for this to work properly and you only have two.

RE: about Hardware Images and _DisplayOrder,Help! - SMcNeill - 02-10-2026

(02-10-2026, 10:43 AM)Unseen Machine Wrote: loadimage as 32 then copyimage as 33

BEEP
PRINT "John is still out of date with modern commands.  LoadImage works fine to load an image directly into hardware as shown.  The issue is layering as I described above."

RE: about Hardware Images and _DisplayOrder,Help! - a740g - 02-10-2026

@qbfans You may also want to check out the SVG graphics demo that James created: https://qb64phoenix.com/forum/showthread.php?tid=3555
It might come in handy.

RE: about Hardware Images and _DisplayOrder,Help! - qbfans - 02-10-2026

Thank you all for your replies.

I carefully read the response from expert smcneil and basically understood the issue. What I'm doing indeed involves three layers. If all software elements are on the same layer, then the code truly cannot achieve what I want. Now I either need to:

Code: (Select All)


t& = _NewImage(800, 600, 32)

_Dest t&

Line (0, 0)-(799, 599), Peach, BF

board_hw& = _CopyImage(t&, 33)

_Dest 0

FreeImage t&
Or make the red square into a hardware image as well. Only then will it comply with the display order and requirements.

@smcneil Also, may I ask the expert about the wiki explanation of _DISPLAYORDER? Does it mean at most one software image layer and two hardware image layers? Because when I tried to set hardware2, I got a syntax error.

@740, I had been searching for a method to draw relatively clear Go stones and tried both raylib and svg approaches you mentioned. After studying related posts, I decided to use the svg method because raylib relies more on external libraries, and all drawing needs to use raylib functions, which is more complicated. Thank you for your articles.

Thank you again. This has been very helpful to me.

RE: about Hardware Images and _DisplayOrder,Help! - SMcNeill - 02-10-2026

(02-10-2026, 05:05 PM)qbfans Wrote: @smcneil Also, may I ask the expert about the wiki explanation of _DISPLAYORDER? Does it mean at most one software image layer and two hardware image layers? Because when I tried to set hardware2, I got a syntax error.

All we have is two hardware layers -- _HARDWARE and _HARDWARE1.   To be honest, I'm not certain what those extra parenthesis and [...] are all about in the wiki.  Perhaps someone at one point at plans to expand to more hardware layers?  If so, they haven't been implemented yet, as far as I know.

What we currently have available is:

_SOFTWARE -- the main screen which most people draw and print and write to and such.
_HARDWARE --  the first hardware screen which you can use as one layer.  (I guess think of it like a 0-based array, if that helps?)
_HARDWARE1 -- the *second* hardware screen which is an independent layer from all others.  
_GL -- the opengl screen which can only be used if you use SUB _GL and call it from there with the _gl commands.

So basically, without using GL, you have 3 layers to play around with, and displayorder lets you set them in whatever order you like for your programs, starting from the background layer to the foremost layer.  

_SOFTWARE, _HARDWARE, _HARDWARE1 would place the _software layer on the bottom, then the _hardware layer on top, with the _hardware1 laying being the topmost layer.   In the case of your example, the peach background would be on the software layer, the black circles on the hardware layer, and the red box on the hardware1 layer.

If you want to arrange your parts differently, just swap the display order so they stack as you would expect them to.

RE: about Hardware Images and _DisplayOrder,Help! - qbfans - 02-11-2026

thanks ,SMcNeill
Steve the Amazing(tm)!! Big Grin

RE: about Hardware Images and _DisplayOrder,Help! - SMcNeill - 02-11-2026

(02-11-2026, 01:02 AM)qbfans Wrote: thanks ,SMcNeill
Steve the Amazing(tm)!! Big Grin

Darn tooting!  That’s worth a +2 rating there!  Big Grin

RE: about Hardware Images and _DisplayOrder,Help! - bplus - 02-11-2026

Go stone images: 
   
   

Might need some cropping and resizing.

RE: about Hardware Images and _DisplayOrder,Help! - qbfans - 02-11-2026

Thank you.@bplus. The visual effect of the stones is quite good. I haven’t used image files for two reasons:

I don’t want to rely on external files. The SVG approach yields fairly good results—it can generate stones based on my required radius, and the gradient effects can likely be fine‑tuned even further. Also, implementing it is relatively straightforward.

I’ve noticed that image quality degrades when using _PUTIMAGE for scaling, especially when downsizing. I’m still looking into this, so if you have any good techniques, please share them. If I can learn the trick, using $EMBED and _EMBEDDED$ would also be a viable option.