Any way to use transparency in SCREEN 0?

[madscijr]

Pete, what is it with you and Screen 0? LoL! 
I know you've talked about it before, but why? 
Are you still running that old 486/dx 66 & need to conserve system resources? 
Is it the challenge? For the benefit of those who are new to QB64PE, tell us what's so great about Screen 0 one more time!  

[SMcNeill]

Pete, what is it with you and Screen 0? LoL! 
I know you've talked about it before, but why? 
Are you still running that old 486/dx 66 & need to conserve system resources? 
Is it the challenge? For the benefit of those who are new to QB64PE, tell us what's so great about Screen 0 one more time!  

Built in blinking text.
Small memory footprints.
Perfect character recognition/recall.
Speed and efficiency.

[Kernelpanic]

That's not possible, as QB64(PE) supports only one physical window per program. However, as finally the contents of a window is just an image, and we can create as many images as our memory allows you could simply go a master/slave approach.

You have a master program which creates and manages the images and react to inputs and a slave program which can be run multiple times . . .

Thanks for the explanation! The master/slave thing is too complicated for me, so it doesn't work.

[madscijr]

That's not possible, as QB64(PE) supports only one physical window per program. However, as finally the contents of a window is just an image, and we can create as many images as our memory allows you could simply go a master/slave approach.

You have a master program which creates and manages the images and react to inputs and a slave program which can be run multiple times . . .

Thanks for the explanation! The master/slave thing is too complicated for me, so it doesn't work.

It's isn't THAT complicated, because your child windows only do one thing: display whatever the parent tells them to. If you look up my multi-mouse Pong, that uses multiple QB64PE programs in a similar parent/child setup where one sends info to the other using TCP/IP. This same system could be used to have a QB64PE program that displays different stuff in multiple displays, i.e., a multi-monitor setup.

However, I went back to your original post

Can one define windows in QB64 that are stacked on top of each other but completely independent of each other?

and I think what you are looking to do doesn't need multiple QB64PE programs.
Instead, you can define "virtual" windows by simply declaring an array of images and coordinates and z-order,  something like:

Code: (Select All)

Type VirtualWindowType
    image as Long
    x as Long
    y as Long
    z as Long ' zorder (for stacking windows, higher values are on top of lower values)
End Type
ReDim arrWindow(1..5) As VirtualWindowType
Dim index%
For index% = 1 to 5
    arrWindow(index%).image = _NEWIMAGE(320, 240, 32)
    arrWindow(index%).x = index% * 10
    arrWindow(index%).y = index% * 10
    arrWindow(index%).z = index%
    _DEST arrWindow(index%).image
    print "WINDOW #" + _TRIM$(STR$(index%))
Next index%

screenImage& = _NEWIMAGE(800, 600, 32)
screen screenImage&

'have your program do its thing, including manipulating windows:
'update window contents for each image handle (.image attribute),
'move windows around by changing .x , .y attributes
'move windows forward or back by changing .z attribute

'then to display,
'first sort arrWindow in order of .z attribute,
'then do something like
_DEST screenImage&: CLS , _RGB(255, 255, 255)
for index% = 1 to 5
    _PUTIMAGE (arrWindow(index%).x, arrWindow(index%).y), arrWindow(index%).image, screenImage&
next index%
_DISPLAY

'^^^and so you display "windows"
'   that can be placed in front of one another
'   in whichever order you like

...(program continues)...


'then at the end of your program, do cleanup:
screen 0
_FREEIMAGE screenImage&
For index% = 1 to 5: _FREEIMAGE arrWindow(index%).image : next index%
_AUTODISPLAY

[madscijr]

Built in blinking text.
Small memory footprints.
Perfect character recognition/recall.
Speed and efficiency.

Thanks, that's what I figured. Google says 

In QB64PE's SCREEN 0 mode, you are limited to a text-only display with 64 colors (including 8 background intensities), no graphics capabilities, and a default text size of 25 rows by 80 columns.

But in this thread our resident Screen 0 champion @Pete concludes

In short, SCREEN 0 does it all. What the hell is hard to understand about that?

but our arcade game wizard @Terry says QB64 can break the limitations, but concludes _NEWIMAGE is all you need:

QB64 can break the limitations of all legacy screens including SCREEN 0.

Personally I think all the legacy graphics screens are useless unless needed for legacy source code that relies on them. You should be creating all your screens using the _NEWIMAGE statement, including SCREEN 0:

So I guess my question is, if SCREEN 0 can do it all, and QB64 can break the limitations, why are we even having to have a giant thread about how to do transparent colors in SCREEN 0? It sounds like there ARE still limitations, and SCREEN 0 can't do it all? I'm just wondering why all the fuss, if we need transparency and all the fancy stuff that _NEWIMAGE gives, why go through all the trouble hacking SCREEN 0 when you can just use _NEWIMAGE? Is it just to prove a point that your manual saw can do everything that power saw can without needing to plug in? 

[SMcNeill]

So I guess my question is, if SCREEN 0 can do it all, and QB64 can break the limitations, why are we even having to have a giant thread about how to do transparent colors in SCREEN 0? It sounds like there ARE still limitations, and SCREEN 0 can't do it all? I'm just wondering why all the fuss, if we need transparency and all the fancy stuff that _NEWIMAGE gives, why go through all the trouble hacking SCREEN 0 when you can just use _NEWIMAGE? Is it just to prove a point that your manual saw can do everything that power saw can without needing to plug in? 

Think of it like this:

CHEAP, FAST, AND GOOD -- BUT WE CAN ONLY DO TWO OF THEM FOR YOU!!

We do it all, but there's always a trade-off. Want it cheap and fast? It's not going to be so good. Want it cheap and good? It's not going to be a priority, so don't expect it fast...

That's the same with screen modes.

Want blinking text? That's native to SCREEN 0. Just add 16 to the color value you want.. COLOR 20, for example is COLOR 4 (red) + 16 (blinking) for red, blinking text.

*CAN* you do that in 32-bit screens? Sure!! Just not natively. Expect timers, loops, manual color changes, ect... Write it yourself! It *can* be done, but not natively as a built-in feature of the screen mode.

---

Want 32-bit color images in a 32-bit screen? Just _Putimage them there. Done and done.

Want 32-bit color images in a screen 0 text screen? Make a hardware copy, layer them, display them... That's not a native built-in feature to the screen mode.

---

Want to grab a character at POINT (10,10) on the screen and know if it's a space, a non-breaking space, or something else? Screen 0 has you covered. 32-bit screens... Nope!! Best start writing an array or some other way to track those characters! You're not getting that specific information back from a graphic screen -- EVER.

---

Pick and choose. What do you need and what works best for you.

Pete is just fiddling around, I think, seeing what he *can* do. It's not a standard part of the built-in features, but he's working his way around them and experimenting to see what the limits are; ergo the questions of, "Can I do this?" And, "What's the easiest way to work around this?"

Very few things are 100% impossible. The trick is trying to find the best and easiest way to work your square into the round peg, when it's not really designed to go there.

[madscijr]

Thanks for explaining - that was the kind of answer I was looking for. Makes perfect sense.

[Pete]

@SMcNeill

Oh I get the transparency part for software over hardware, which is this...

Code: (Select All)

$Color:32

Screen 0

_PaletteColor 5, 0

Cls , 5

' Make a software button

x = 50

Locate 12

Color 1, 5: Locate , x: Print String$(17, 220)

Color 1, 5: Locate , x: Print String$(17, 219)

Color 1, 5: Locate , x: Print String$(17, 223)

Color 15, 1: Locate 13, x + 1: Print "Software Button";

t& = _NewImage(17 * _FontWidth, 3 * _FontHeight, 32)

_Dest t&

Cls , _RGB(255, 255, 255)

Color Red, White: Locate 1, 1: Print String$(17, 220);

Color Red, White: Locate 2, 1: Print String$(17, 219);

Color Red, White: Locate 3, 1: Print String$(17, 223);

Color White, Red: Locate 2, 2: Print "Hardware Button";

img& = _CopyImage(t&, 33)

_FreeImage t&

t& = _NewImage(_Width * _FontWidth, _Height * _FontHeight, 32) ' Make a duplicate size screen and add a white background.

_Dest t&

Cls , _RGB32(255, 255, 255)

hardwarebackground& = _CopyImage(t&, 33)

_FreeImage t&

_Dest 0

_PutImage (0, 0), hardwarebackground&

_PutImage ((x - 1) * _FontWidth, 100), img& ' Put the hardware button on the screen.

Color 1, 5: Locate 17, x: Print "Text: ";: Color 14, 0: Print " Hello World! ";

_DisplayOrder _Hardware , _Software

x = x - 10

Color 2, 5: Locate 8, x

For i = 1 To 9

    Locate , x: Print String$(18, 219)

Next

Color 15, 2

Locate 11, x + 5: Print "Software"

Locate 13, x + 6: Print "Popup!"

_Display

Sleep

I'm looking for what I now see as impossible, software over software with the same transparency ability.

To put it another way, the challenge here is to add a shadow to the popup that would look the same as if we did this entire routine in graphics....

Code: (Select All)

$Color:32

Screen _NewImage(600, 400, 32)

Cls , _RGB32(255, 255, 255)

x = 50

Locate 8

Color Red, White: Locate 8, x: Print String$(17, 220)

Color Red, White: Locate , x: Print String$(17, 219)

Color Red, White: Locate , x: Print String$(17, 223)

Color White, Red: Locate 9, x + 1: Print "Graphics Button";

Locate 12

Color Blue, White: Locate , x: Print String$(17, 220)

Color Blue, White: Locate , x: Print String$(17, 219)

Color Blue, White: Locate , x: Print String$(17, 223)

Color White, Blue: Locate 13, x + 1: Print "Graphics Button";

Color Blue, White: Locate 17, x: Print "Text: ";: Color Yellow, Black: Print " Hello World! ";

x = x - 10

Color Green, White: Locate 8, x

For i = 1 To 9

    Locate , x: Print String$(18, 219)

Next

Color White, Green

Locate 11, x + 5: Print "Software"

Locate 13, x + 6: Print "Popup!"

' Add shadow effect

Locate 9

For i = 1 To 8

    Locate , x + 18: Color _RGBA(127, 127, 127, 220): Print Chr$(219) + Chr$(219)

Next

Locate , x + 2: Color _RGBA(127, 127, 127, 220): Print String$(18, 219);

_Display

Sleep

@bplus

Yes, I have used the method you posted in other menu applications. Without buttons or many colors, it does the job, but the inability to control color intensity and transparency or 'overlapping' software text and images is a drawback. Because of this I am left with only two possibilities.

1) Make the popup a hardware image and keep the default display order. I explained earlier this is a pain because with even just one menu, you have to make and assemble multiple parts to get a color difference as the menu item are sometimes usable (normal black text) or not usable (grey text). Now if you are also making multiple menus, like the QB64 IDE, this would get tedious and time consuming, fast.

2) And this one I either don't know how, or it can't be done, but somehow copy the screen with both the hardware and software images first, next save that combined copy to memory, and put it to the screen so now everything in the background is a hardware image. Now we just make a regular software popup and then we can use Steve's transparent palette method.

@SMcNeill
So Steve, do you think method 2 is even possible? I don't know how we can get both the software and hardware images, displayed on the screen before the popup gets opened, to copy as a single combined image to memory.

Pete

[Pete]

@SMcNeill 

No luck getting _copyimage to work in SCREEN 0 to pick up a screen with both the hardware and software images present. So no way to make  copy into a hardware only image. If I could do that, situation solved.

What I did find was _SCREENIMAGE doesn't have any issues doing exactly that, except it is hard to manage, because you have to have not only the window coordinates exact, but you also have to cut out the title bar...

s2& = _CopyImage(_ScreenImage(8, 30, 80 * _FontWidth + 8, 25 * _FontHeight + 30), 33)

Now provided you use _SCREENMOVE 0, 0 the line above seems to be pretty damn close.

I mean maybe I should be putting this up as a developers request, to just get _putimage doing this for SCREEN 0, so only the screen contents are copied.

Code: (Select All)

Dim As Long t, img

_ScreenMove 0, 0

_PaletteColor 5, 0

Cls , 5 ' It is necessary to clear the screen first, with the transparency.

img = _LoadImage("activate-hover.png", 33)

_DisplayOrder _Hardware , _Software

t = _NewImage(_Width * _FontWidth, _Height * _FontHeight, 32)

_Dest t

Cls , _RGB32(255, 255, 255) ' Bright white graphics screen.

HardwareBg = _CopyImage(t, 33)

_FreeImage t

_Dest 0

Color 6, 5: Print "Hello World!...................." ' Transparent background lets hardware screen underneath show through.

_PutImage (0, 0), HardwareBg ' Apply bright white page with any software text.

_PutImage (100, 0), img

_Display

_Delay 2

s2& = _CopyImage(_ScreenImage(8, 30, 80 * _FontWidth + 8, 25 * _FontHeight + 30), 33)

_PutImage (0, 0), s2&

_Display

Sleep

If you don't have the png _LoadImage("activate-hover.png", 33) just use an image of your own or copy it from https://qb64phoenix.com/forum/showthread...3#pid31503

Now _SCREENIMAGE my have a bug. Get rid of _SCREENMOVE 0, 0  and change s2& = _CopyImage(_ScreenImage(8, 30, 80 * _FontWidth + 8, 25 * _FontHeight + 30), 33)  to s2& = _CopyImage(_ScreenImage, 33)

You should notice that the copy replicates "Hello World!........" part in the correct place, but ALSO at the top right of your desktop. Go figure.

Pete

[Sprezzo]

I can't believe Pete doesn't know all this by now and when the hell do we get a demo of whatever he's working on?