Welcome, Guest. Please login or register.

Author Topic: Layers.library V45 on the aminet  (Read 64627 times)

Description:

0 Members and 1 Guest are viewing this topic.

guest11527

  • Guest
Layers.library V45 on the aminet
« on: July 07, 2014, 01:43:07 AM »
With the kind permission from Hyperion, I recently uploaded the V45 version of layers.library to aminet.

Layers.library is responsible for the "slice & dice" operations required for window re-arrangements, computes cliprects, damage regions and provides the backing-store for "smart-refresh windows".  

Layers (up to v40, Os 3.1) was considerably ill-designed for rtg (regargetable graphics, graphics cards) and thus was heavily patched to avoid performance degrations.

The V45 release is an old code that collected dust here on my harddisk which was created as input for Os 4 - and in fact, is the Os 4 version is based on the V45 release.

Besides a major cleanup of the Os 3.1 version of layers (v40), the optimizations for graphic cards and the improvements in memory management, this release also provides new functionalities to hide and show layers, for example to allow window iconification with little or no extra efford from software. The uploaded archive contains a "tech demo" (amisnip) that demonstrates the functionality. Note that Amisnip is a technology demo, not a "good program". Sources are included to inspire authors.

V45 layers also includes support to automatically clip layers at layer_info boundaries, another new functionality. With a proper modification of intuition (which is of course not available), this would allow to easily drag out windows from the screen - something that was not possible before either. There is another technology demo in the archive that shows how to enable the feature (without enabling the drag-out of windows, which is as said something to be done in intuition).

Note well: This is all for classic Amigas. Os 4 has the features anyhow, and (partially) by the same author, and is based on the same code basis. Thus, you loose nothing with Os 4 - you already have it.
 

Offline klx300r

  • Amiga 1000+AmigaOne X1000
  • Hero Member
  • *****
  • Join Date: Sep 2007
  • Posts: 3244
  • Country: ca
  • Thanked: 20 times
  • Gender: Male
    • Show only replies by klx300r
    • http://mancave-ramblings.blogspot.ca/
Re: Layers.library V45 on the aminet
« Reply #1 on: July 07, 2014, 01:50:38 AM »
Thank you Thomas for this timely release as I'm just getting ready to set up my first RTG Amiga system in the upcoming weeks :-)
____________________________________________________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga 1000 & AmigaOne X1000 !
--- www.mancave-ramblings.blogspot.ca ---
  -AspireOS.com & Amikit- Amiga for your netbook-
***X1000- I BELIEVE *** :angel:
 

Offline nyteschayde

  • VIP / Donor - Lifetime Member
  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 643
    • Show only replies by nyteschayde
    • http://www.nyteshade.com
Re: Layers.library V45 on the aminet
« Reply #2 on: July 07, 2014, 07:23:55 AM »
I am often very impressed by the folks in the Amiga community. Many that remain are incredibly talented software and hardware engineers who are jaded and scorned over something that in a modern day of open source seems trivial but nonetheless their talents and in depth knowledge are the things keeping the platform in a slow but steady state of progress.

To you Thomas, I say thanks. If you are also familiar with making web pages, I say preach and teach your knowledge to others and give as much as you can when/if you find yourself drifting from the community so that it is not lost and can be used by you and others when you return.
Senior MTS Software Engineer with PayPal
Amigas: A1200T 060/603e PPC • A1200T 060 • A4000D 040 • A3000 (x2) • A2000 Vamp/V2 • A1200 (x4) • A1000 (x3) • A600 Vamp/V1 • A500
 

Offline Georg

  • Jr. Member
  • **
  • Join Date: Feb 2002
  • Posts: 90
    • Show only replies by Georg
Re: Layers.library V45 on the aminet
« Reply #3 on: July 07, 2014, 08:13:32 AM »
Quote from: Thomas Richter;768383

V45 layers also includes support to automatically clip layers at layer_info boundaries, another new functionality. With a proper modification of intuition (which is of course not available), this would allow to easily drag out windows from the screen - something that was not possible before either. There is another technology demo in the archive that shows how to enable the feature (without enabling the drag-out of windows, which is as said something to be done in intuition).


There is an (evil?) hack on Aminet called PowerWindowsNG (source code: PowerWinNG_Src) which allows dragging out windows from the screen. It includes a BlizKick module to disable some Intuition checks in ROM which usually block window dragging to area outside screen. The checks are disabled if bit 7 of LayerInfo flags is set (used by hack to indicate that screen/layerinfo allows out of screen windows).

You could use this or similiar with the V45 layers.

(The way the hack worked, was to put huge nobackfill layers around the screen and then patch things in layers in such a way that this special layers are alway in front of all normal layers. This way when a normal layer gets moved out of screen it ends up behind the special layers and the library handles damage/refresh/backing correctly all by itself without modification.)
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #4 on: July 07, 2014, 08:50:34 AM »
Quote from: Georg;768418
You could use this or similiar with the V45 layers.
 Well, V45 has all this functionality built-in, there is no "bit" for that, but instead a new "layer-info" based clipping region layers are optionally clipped to.   Everything outside this region goes into the damage region or the backing-store. It's transparently handled in V45, transparent to the program using intuition. But, as said, no bit, but a rectangle. Demo is included in the archive.  Problem is - as said - intuition. Intuition would a) need to setup the correct layer_info clipping, and b) enable dragging windows out of the screen.  As said, this is all done in 4.0 and above, no black magic. (Except the "how to compile intuition" magic since it's not SAS/C.)
 

Offline amigakit

Re: Layers.library V45 on the aminet
« Reply #5 on: July 07, 2014, 08:58:21 AM »
Thank you for releasing this Thomas
www.AmigaKit.com - Amiga Reseller | Manufacturer | Developer

New Products  --   Customer Help & Support -- @amigakit
 

Offline Georg

  • Jr. Member
  • **
  • Join Date: Feb 2002
  • Posts: 90
    • Show only replies by Georg
Re: Layers.library V45 on the aminet
« Reply #6 on: July 07, 2014, 09:29:15 AM »
Quote from: Thomas Richter;768420
Problem is - as said - intuition. Intuition would a) need to setup the correct layer_info clipping, and b) enable dragging windows out of the screen.


As said you can do something similiar to BlizKick module in PowerWindowsNG to do b) and regarding a) you can add an option to the V45 library to install the correct layer_info clipping rect itself (== set it to layerinfo bitmap dimensions, once they are known).
 

Offline Ancalimon

  • Hero Member
  • *****
  • Join Date: Apr 2002
  • Posts: 516
  • Country: 00
    • Show only replies by Ancalimon
    • http://www.myspace.com/orhunmusic
Re: Layers.library V45 on the aminet
« Reply #7 on: July 07, 2014, 09:37:10 AM »
Is it safe to use with Cybergraphx (CVisionPPC, BVisionPPC) too?
A4000T, 604e@400&060@66, 128MB+16MB+Zorram256, CVisionPPC, VLabMotion, Toccata, XSurf100&RapidRoad, Prisma Megamix

A1200, Blizzard060@50, 256MB, Blizzard IV SCSI, FastATA mk4
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #8 on: July 07, 2014, 09:57:40 AM »
Quote from: FaLLeNOnE;768427
Is it safe to use with Cybergraphx (CVisionPPC, BVisionPPC) too?

Yes, please read the readme. You need to use the "LayersAntiHack". Cgfx patches layers, and thus destroys the logic of the new lib, the above patch avoids the patches. (Sick). Works smoother with P96.
 

Offline Niding

  • Hero Member
  • *****
  • Join Date: Sep 2004
  • Posts: 566
    • Show only replies by Niding
Re: Layers.library V45 on the aminet
« Reply #9 on: July 07, 2014, 10:02:17 AM »
Thanks for the lib update :)
 

Offline rockape

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 383
    • Show only replies by rockape
    • http://lincsamiga.org.uk/
Re: Layers.library V45 on the aminet
« Reply #10 on: July 07, 2014, 10:33:04 AM »
Hi Thomas,

Many thanks.

Regards, Michael

aka rockape
"A veteran is someone who, at one point in their life wrote a blank check made payable to \'Their Country\' for an amount of \'up to and including their life\'.
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Layers.library V45 on the aminet
« Reply #11 on: July 07, 2014, 12:26:50 PM »
Quote from: Thomas Richter;768383

Besides a major cleanup of the Os 3.1 version of layers (v40), the optimizations for graphic cards and the improvements in memory management, this release also provides new functionalities to hide and show layers, for example to allow window iconification with little or no extra efford from software.


This is not real iconification. Hiding layer leaves screen locked preventing Workbench theme and screen resolution changes. It is useful to hide layer temporarily without disposing window but to support real iconification it should always use screennotify.library and CloseWindow() on demand.

Real iconification requires quite lot effort but is worth of it. It is quite bad when Workbench is complaining it cant adjust screen and asks user to close all windows but user cant see any.
My Amigas: A500, Mac Mini and PowerBook
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #12 on: July 07, 2014, 03:10:34 PM »
Quote from: itix;768448
This is not real iconification. Hiding layer leaves screen locked preventing Workbench theme and screen resolution changes. It is useful to hide layer temporarily without disposing window but to support real iconification it should always use screennotify.library and CloseWindow() on demand.
Which is, of course, quite impossible for applications that have not written with this use in mind. You probably don't understand the vision here: What it requires is an update of intuition and workbench to allow closing the WB screen *with hidden windows* on it. This is "in principle" no problem because the full window content is in the backing store in first place, so it can be re-rendered when necessary. Of course, lots and lots of things would need to be done for that, not saying that I would do that - I wouldn't. Like conversion between bitdepths (and conversion between screen organizations, but that's something rtg implements anyhow). But a first step needs to be taken, and it is practical to have this limited feature in first place.  
Quote from: itix;768448
Real iconification requires quite lot effort but is worth of it. It is quite bad when Workbench is complaining it cant adjust screen and asks user to close all windows but user cant see any.
 Then un-hide the windows in that case as a first step... (-:   It really makes no sense to request from existing programs that have not been designed with this application in mind to iconify themselves. As you say, it is a *lot* of work. ViNCEd, the 3.9 console, can do that. For that, it has its own "backing store" of the editor contents (ViNCEd is an editor), and it can even make shell output, scrolling, and control sequence handling without any type of window attached to it. It delivers screen sizes, cursor positions and everything to every program running in it. You can iconify the Shell with "list" running in it, and restore it later, seing the "list" being done and complete, it does not stop programs for being iconified (unlike the "ape shell" or whatever its name was).  But, remembering how much work this little feature was, just to get everything worked out correctly, I cannot realistically request that from any arbitrary application. It is the wrong way around. The Os needs to ensure that applications can render themselves to their windows, even if the windows are not "phyically attached" to any display. This is precisely the core functionality of what "HideLayer" does. Well, in essence. There are a couple of corner cases that would require a solution, but that's where the development should have gone should I have had more time and a working hardware to get things done back then.  It's all too late now, but you got what you got, and that's better than nothing.
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #13 on: July 07, 2014, 06:47:45 PM »
on an opportunity to thank thomas for another act of support towards amiga users i just would like to mention that powerwindows is a little patch that adds up a hell of functionality to a system where its probably most outdated and limited in its genuine shape. especially the relatively low res native amiga resolutions benefit from that feature imho, and it is one of yet not so many advantages of aros68k on genuine hardware. it would probably be worth to incorporate it properly into a system some day.

this said, the amount of reworked and improved libraries and patches has become overhelming these days. from my own experience with the maintenace of an improved kickstart in flash i start to wonder about some simple and unified possibility to dependably maintain and update the (remapped) kicksart, that would be easier for those inexperienced users for whom diassembling the rom image, applaying patches from command line or loading modules on startup remains a major showstopper. as example i wonder if a package could be created that automatically assembles and installs such a kickstart reading out the content of the original roms, applaying appropriate patches and properly modifying the startup sequence. i think an boing bag (4?) archive  along with an a little more sofisticated installation script might play that role.
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #14 on: July 07, 2014, 07:10:06 PM »
@wawrzon

to tell the truth probaby even someone like me might be able to prepare such a package if it doesnt yet exists. the requirement would be likely that doobrey tools could be used for the task ( if they can be run from console instead graphically from workbench) and also that all the components are available with a proper free license.

but this is an offtopic. sorry.