Transperent shell window?

[ZyBeR]

Hi!

Does anyone know if there eaven exists a shell app with transperent window for classic? It would be so cool

[Karlos]

Transparency sucks :-) Or rather the lack of implementation support does...

Assuming you mean transparent as in magic menu, etc, no matter what graphics card you have, there is nothing in the graphics.library to support this kind of transparency directly, so no hardware acceleration. As far as I am aware, all transparent gimmicks on amigaos currently work by grabbing the hidden area and then doing the transparency in software and writing it back. In other words it's a CPU hog. It's also not realtime because of the calculation overhead (only recalculated when you move or resize). If something changes behind your window, you won't see it happen.

Anyway a transparent console would be confusing if it overlayed stuff with a lot of text on it already :-)

[vic20owner]

This is the same way it works in Linux, etc.

[pixie]

Unless for the porpose of showing it can be done, it isn't any good UI wise...

[SamuraiCrow]

When I used to run a custom copperlist on my Workbench screen everything drawn in the background color was transparently displayed as the copperlist.  It was very annoying that I couldn't see the text against the multicolored background so I had to change my shell-startup to produce a dark background color behind my text to prevent the transparency from interfering with the usability of the shell.  It was not cool.   :-(

[Merc]

@SamuraiCrow:

Here's a little trick if anyone's still using WBVerlauf; pick a colour at the end of the palette (one of the last 4 I think) and set it to all black but set one of the R/G/B values to 1 instead of zero.  

Then in the WBVerlauf tooltypes, set the colour index it uses to whatever colour number you chose.

Now you can set your WBPattern prefs to use that colour as
the pattern, and you only see your copper list on the backdrop or in windows, so it doesn't show up all over the screen in any window.

With the selected colour set to almost black, the chances of it getting picked for displaying a picture, etc. are pretty slim so you don't get random bits of copperlist in unexpected places

[Karlos]

vic20owner wrote:

This is the same way it works in Linux, etc.

You tend to have more powerful hardware then. Doing transparency on a 68K amiga in this fashion with a CPU to VRAM bandwidth of maybe 10MB/s and VRAM to CPU of 4 MB/s, it is no fun at all doing transparency calculations on things much larger than your average menu...

If you want that kind of thing, HW accelerated user interfaces are the way forwards IMO. Transparent shells in OSX etc work very well (speed wise I mean, I find transparent shells etc rather pointless if it decreases their readability).

[koaftder]

Karlos wrote:
Transparency sucks :-) Or rather the lack of implementation support does...

Assuming you mean transparent as in magic menu, etc, no matter what graphics card you have, there is nothing in the graphics.library to support this kind of transparency directly, so no hardware acceleration. As far as I am aware, all transparent gimmicks on amigaos currently work by grabbing the hidden area and then doing the transparency in software and writing it back. In other words it's a CPU hog. It's also not realtime because of the calculation overhead (only recalculated when you move or resize). If something changes behind your window, you won't see it happen.

Anyway a transparent console would be confusing if it overlayed stuff with a lot of text on it already :-)

Transparency is kind of a pain. On OSX you can make the terminal windows transparent, but it's a total pain to use because you see all the crap behind the terminal, making it hard to read.

[boing]

This is another example where engineers need to be working on implemention MORE sprites and playfields, not less. Fancy blitter engines are great, but not's let put all our graphics eggs in one basket.


Not TRUE transparency (gradient controls) as requested here but it is cool:

 I like "drag with window contents in realtime" but was unhappy with the programs out there that added this to the Amiga.  They used the  Blitter and I wasn't happy with the chipmem usage but most of all I was appalled at the number of bus cycles wasted.  That's where the idea came from for this...

I had planned on writing a program that would allow you to move/render public windows/screens to another playfield, which you could then overlay anywhere onscreen. Or underlay.  For OCS, ECS, and AGA.  Some color limitations apply- mostly on OCS/ECS.  I had planned options to render it's contents to the main screen (wherever you drop the window), and only use the playfield for dragging the window [so as not to suck bandwidth on older OCS/ECS machines].  In other words, the playfield would optionally only be in use during a drage or move.  This can reduce chipmem bus sage under many circumstances.

Anyway the cool thing is that you also get real-time window dragging along with it, virtually for free, sans the usual blitter/cpu bus load. Mind you, a large Shell on an A1000 in Hi-Res mode can mean you'd start to feel a bit sluggish (but not as bad as the current ways of creating "drag with content" windows for pre-AGA Amigas).

I never got to it, and have no IP or patent on the idea (software patents are evil) so if any of you want to build on it, go ahead.

Sprites and Playfields rule.  Adding tranparency in hardware is fairly easy if you already have genlock/sprite/playfield circuitry.  And... that ain't gonna happen.  We'll all be using off the shelf cards that lack sprites.

[SamuraiCrow]

boing wrote:
This is another example where engineers need to be working on implemention MORE sprites and playfields, not less. Fancy blitter engines are great, but not's let put all our graphics eggs in one basket.


Not TRUE transparency (gradient controls) as requested here but it is cool:

 I like "drag with window contents in realtime" but was unhappy with the programs out there that added this to the Amiga.  They used the  Blitter and I wasn't happy with the chipmem usage but most of all I was appalled at the number of bus cycles wasted.  That's where the idea came from for this...

I had planned on writing a program that would allow you to move/render public windows/screens to another playfield, which you could then overlay anywhere onscreen. Or underlay.  For OCS, ECS, and AGA.  Some color limitations apply- mostly on OCS/ECS.  I had planned options to render it's contents to the main screen (wherever you drop the window), and only use the playfield for dragging the window [so as not to suck bandwidth on older OCS/ECS machines].  In other words, the playfield would optionally only be in use during a drage or move.  This can reduce chipmem bus sage under many circumstances.

Anyway the cool thing is that you also get real-time window dragging along with it, virtually for free, sans the usual blitter/cpu bus load. Mind you, a large Shell on an A1000 in Hi-Res mode can mean you'd start to feel a bit sluggish (but not as bad as the current ways of creating "drag with content" windows for pre-AGA Amigas).

I never got to it, and have no IP or patent on the idea (software patents are evil) so if any of you want to build on it, go ahead.

Sprites and Playfields rule.  Adding tranparency in hardware is fairly easy if you already have genlock/sprite/playfield circuitry.  And... that ain't gonna happen.  We'll all be using off the shelf cards that lack sprites.

The reason sprites aren't used in PC-style graphics chipsets is that there is no left border available for the graphics chipset to load in oodles of sprites.  Most graphics chipsets support ONE sprite for the mouse pointer and not more for that reason.

I do agree, though, that blitter-based solutions waste bus cycles by writing everything to the framebuffer instead of piping the results of the blits straight to a queue on the video DAC.