Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: Layers.library V45 on the aminet
« Reply #29 on: July 09, 2014, 08:14:38 PM »
Quote from: Chain|Q;768592
No, I didn't try these, however the archive on that page doesn't upgrade rtg.library, which is said to have the problem. BTW, where does the claim comes from about the PIP functionality fixes? I can't seem to find any kind of changelog for versions above 2.0.

I am not aware of a changelog. I found the bug fix myself. In the P96Developer.lha (SDK) archive in the examples directory, there is a program called OpenPIP which failed to open. After installing Gulliver's newer P96 libraries, it works for me. The problem was probably in the Picasso96API.library p96PIP_OpenTags() function but I did not investigate the problem further. It's been awhile too.

Quote from: Chain|Q;768592
In fact, the rtg.library I have installed is slightly newer than the one included in that archive. (I think it comes from some UAE-related update.) But I'll give it a try, one can never know.

Does the rtg.library have the same version number (40.3994) but a newer date? If so, I disassembled a version with a newer date and could see that it was patched (Christian Sauer's patch?) in a way that didn't impress me. It looked like a 3rd party patch job. I didn't figure out what the patch was trying to accomplish but Gulliver and I decided it was better to use the earlier dated (but same version) unmolested version if it didn't cause problems for anyone. You can ask Gulliver if there have been any problems since then. You could probably find the discussions on the amiga.org and/or the EAB forums if you search.

http://eab.abime.net/showthread.php?t=50410
http://aminet.net/driver/video/RTG403994p.readme

I couldn't find the the thread where I talked about disassembling the different rtg.library versions. I don't recall having problems with either of the new 40.3994 versions.
« Last Edit: July 09, 2014, 08:16:42 PM by matthey »
 

Offline utri007

Re: Layers.library V45 on the aminet
« Reply #30 on: July 09, 2014, 09:09:03 PM »
This is interesteing, but I have some questions. Solid Windows movin is possible with FBlit and it is over all big performance boost. So I wondering what will happen with FBlit? Will it work hapily with it?
ACube Sam 440ep Flex 800mhz, 1gb ram and 240gb hd and OS4.1FE
A1200 Micronic tower, OS3.9, Apollo 060 66mhz, xPert Merlin, Delfina Lite and Micronic Scandy, 500Gb hd, 66mb ram, DVD-burner and WLAN.
A1200 desktop, OS3.9, Blizzard 060 66mhz, 66mb ram, Ide Fix Express with 160Gb HD and WLAN
A500 OS2.1, GVP+HD8 with 4mb ram, 1mb chip ram and 4gb HD
Commodore CDTV KS3.1, 1mb chip, 4mb fast ram and IDE HD
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #31 on: July 09, 2014, 11:16:55 PM »
Quote from: utri007;768597
This is interesteing, but I have some questions. Solid Windows movin is possible with FBlit and it is over all big performance boost. So I wondering what will happen with FBlit? Will it work hapily with it?

I can't give you an answer because I don't use FBlit. All I can tell is that it hooks into the system at a completely different spot, and if the semantics of the Os interface does not change, I see no reason why it should not work.
 

Offline utri007

Re: Layers.library V45 on the aminet
« Reply #32 on: July 10, 2014, 08:33:45 AM »
I hope it works :) Need to test when I get to home. FBlit is one of saddest stories of Amiga land, it is  amazing it makes big diffrence with Workbench and many programs and games.
ACube Sam 440ep Flex 800mhz, 1gb ram and 240gb hd and OS4.1FE
A1200 Micronic tower, OS3.9, Apollo 060 66mhz, xPert Merlin, Delfina Lite and Micronic Scandy, 500Gb hd, 66mb ram, DVD-burner and WLAN.
A1200 desktop, OS3.9, Blizzard 060 66mhz, 66mb ram, Ide Fix Express with 160Gb HD and WLAN
A500 OS2.1, GVP+HD8 with 4mb ram, 1mb chip ram and 4gb HD
Commodore CDTV KS3.1, 1mb chip, 4mb fast ram and IDE HD
 

Offline Chain|Q

  • Newbie
  • *
  • Join Date: Jul 2014
  • Posts: 8
    • Show only replies by Chain|Q
    • http://charlie.amigaspirit.hu
Re: Layers.library V45 on the aminet
« Reply #33 on: July 10, 2014, 10:47:38 AM »
Quote from: utri007;768620
I hope it works :) Need to test when I get to home.
Just for the record, I run FBlit on my AGA machine, and I experienced no problems so far with v45 layers there.
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Layers.library V45 on the aminet
« Reply #34 on: July 10, 2014, 03:49:10 PM »
Quote from: Thomas Richter;768460
Which is, of course, quite impossible for applications that have not written with this use in mind.


It is not impossible. It takes some effort and no effort at all if you use some high level frame work. Using low level Intuition calls is deprecated anyway... nobody should be using Intuition window calls directly in this century.

Quote
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.    Then un-hide the windows in that case as a first step... (-:


No I dont understand this functionality that encourages developers to not develop properly functioning software. It is bad design.

Nobody is going to update Intuition. Not you, not anyone else.

Quote
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).


That is not much. Pretty common in every Amiga shell I have seen in this century.

Quote
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.


Trivial.
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Layers.library V45 on the aminet
« Reply #35 on: July 10, 2014, 03:54:40 PM »
Quote from: Thomas Richter;768502
I don't know why you should. I'm making an offer. Probably you start with the Readme, because it answers a couple of questions what is wrong with V40 layers.

To keep it very short, besides the new functions, it is much more efficient when depth-arringing windows. V40 had an algorithm that scaled like O(n^2) in the number of overlapping windows, V45 is only O(n). Given CPU driven memory copies in some situations on rtg, this makes a noticable difference.


That should give huge boost. Even on some vanilla A1200 if you had ten overlapping windows it was already crawling.

Btw is there still noticeable speed penalty when rendering to non-overlapped window that is not the top most one? That was another issue with the original layer code...
My Amigas: A500, Mac Mini and PowerBook
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #36 on: July 10, 2014, 11:41:17 PM »
Quote from: itix;768644
It is not impossible. It takes some effort and no effort at all if you use some high level frame work.
Apparently, you want to troll. Ok, you want it, you get it: Tell me how you can iconify a window of a program you don't have the sources for. There is no "framework" for this. There is only the binary. Actually, most Amiga programs are like that.  
Quote from: itix;768644
 Using low level Intuition calls is deprecated anyway... nobody should be using Intuition window calls directly in this century.
Just in case you did not notice: Nobody uses the Amiga in this century anyhow. Nobody writes new programs in this century anyhow. The majority of programs available for Amiga uses intuition and not a fancy framework. Which of the dozends of incompatible frameworks should I pick today, given that none of them is an integrated part of the Os?  
Quote from: itix;768644
No I dont understand this functionality that encourages developers to not develop properly functioning software. It is bad design.
There are no encouraged developers left - just to remind you. Nobody will rewrite old software. And no, it is not bad design. It keeps the existing functions working in a completely solid way, using the existing functionalities, even in a pretty trivial way.  
Quote from: itix;768644
Nobody is going to update Intuition. Not you, not anyone else.
Wisely said. But whose going to update the old programs then, to use the new fancy frameworks? Oh, right, nobody. In other words, you can have a partial functionality now, completing AmiSnip which is part of the archive, or you can never have anything. Make your pick. My offer stands.  
Quote from: itix;768644
That is not much. Pretty common in every Amiga shell I have seen in this century.
Nothing left in this century. The old broken ape-stuff I know was working on a blank console, and if that console went away, output was not possible.  
Quote from: itix;768644
Trivial.

If things are so trivial, I suggest you start rewriting the old applications using the new fancy frameworks. I wish you luck getting sources and redesigning software made over the last years.
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Layers.library V45 on the aminet
« Reply #37 on: July 11, 2014, 08:36:35 AM »
Quote from: Thomas Richter;768666
Apparently, you want to troll. Ok, you want it, you get it: Tell me how you can iconify a window of a program you don't have the sources for. There is no "framework" for this. There is only the binary. Actually, most Amiga programs are like that.

Of course those programs cant be fixed. I guess AmiSnip is some kind of commodity that can hide windows and inserts them to tools menu? It is perfectly OK. Applications having built-in faked iconify with HideLayers() is not. I just wouldnt want see anyone using it on new code.

Quote
Just in case you did not notice: Nobody uses the Amiga in this century anyhow. Nobody writes new programs in this century anyhow. The majority of programs available for Amiga uses intuition and not a fancy framework. Which of the dozends of incompatible frameworks should I pick today, given that none of them is an integrated part of the Os?    There are no encouraged developers left - just to remind you. Nobody will rewrite old software.

I dont know any incompatible frameworks.

Some frameworks do better than others but no any developer should be encouraged to use low level Intuition anymore. It is rude environment and crash prone if you make even small mistake. It was good in 80s but not anymore.

Quote
And no, it is not bad design. It keeps the existing functions working in a completely solid way, using the existing functionalities, even in a pretty trivial way.    Wisely said.

I have got enough with software that cant go away when I am adjusting Workbench screen. It is annoying especially if there is no visual clue which programs are preventing that.

Quote
If things are so trivial, I suggest you start rewriting the old applications using the new fancy frameworks. I wish you luck getting sources and redesigning software made over the last years.

I have done that couple of times. SnoopDos, Frodo and some text adventure game I cant remember right now. It takes some effort but can be worth of it as in result you can throw away old mumbo jumbo. Basically that is all low level stuff to manage windows, IDCMP ports, gadget definitions and many more I cant remember anymore. They take lot space in code yet there is only very rudimentary UI layout that is neither user or developer friendly.

Agreed we dont have developers left. If we had many old software could be modernized and often with relatively little effort.
« Last Edit: July 11, 2014, 09:00:04 AM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #38 on: July 12, 2014, 03:43:24 AM »
Quote from: itix;768705
Of course those programs cant be fixed. I guess AmiSnip is some kind of commodity that can hide windows and inserts them to tools menu?
It is a technology demo, and as such a small commodity which allows you to iconify arbitrary windows on the workbench. It is not particularly sophisticated, and was never supposed to be. I was actually hoping that somebody would pick up the source code and would polish it a bit.

Quote from: itix;768705
 It is perfectly OK. Applications having built-in faked iconify with HideLayers() is not. I just wouldnt want see anyone using it on new code.
I disagree completely. Again, the approach of hand-made support and an isolated iconification solution for every application is just wrong. It is too much code duplication. In fact, other operating systems (or rather, GUI systems) support that out of the box, and it requires some low-level support to allow rendering and interaction with "windows that are not there". A hidden window still has a size, a rastport, can be moved, resized... the full set of features remains available without even the program *knowing* that it does not show. In other words, this approach offers a transition pass to new features without program support that is consistent over the existing infrastructure. Integrating that into a "framework" will make it only available for programs that use this framework.
Quote from: itix;768705
I dont know any incompatible frameworks.
I know too many. Let's see... MUI, Triton, Reaction,... I believe there were a lot more. One looks different from the other, user experience differs... CBMs investment into establishing a higher abstraction layer on top of the intuition primitives came too late (boopsis) and offered too little. Do programs have a consistent L&F? Not beyond what intuition offers as standard L&F, namely window decorations and system boopsis. And no, thank you, I do not need another framework for another feature you can get independent of frameworks.
Quote from: itix;768705
Some frameworks do better than others but no any developer should be encouraged to use low level Intuition anymore. It is rude environment and crash prone if you make even small mistake. It was good in 80s but not anymore.
So what do you encourage to use? There is no established standard framework. And before I make my programs depend on a several 100K framework, or risk license incompatibilities, I'd rather stick with intuition. Yes, that's "back to the 80th", but Amiga *is* the 80ths. Nobody will change this anymore.
Quote from: itix;768705
I have got enough with software that cant go away when I am adjusting Workbench screen. It is annoying especially if there is no visual clue which programs are preventing that.
Actually, that's a design problem intuition has, and the mentioned V45 was a first step around that. Not a solution. Anyhow, I don't think it is was a very serious problem since I rarely changed the resolution or bit-depth of the workbench.

Given the many design problems AmigaOs has, it is actually not a very serious problem. There are definitely more serious ones. The bigger mess is actually gfx.
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Layers.library V45 on the aminet
« Reply #39 on: July 12, 2014, 07:09:47 AM »
Quote from: Thomas Richter;768776

I know too many. Let's see... MUI, Triton, Reaction,... I believe there were a lot more. One looks different from the other, user experience differs...


Okay I see what you mean by incompatible frameworks.

Quote
CBMs investment into establishing a higher abstraction layer on top of the intuition primitives came too late (boopsis) and offered too little. Do programs have a consistent L&F? Not beyond what intuition offers as standard L&F, namely window decorations and system boopsis. And no, thank you, I do not need another framework for another feature you can get independent of frameworks.  So what do you encourage to use? There is no established standard framework.


MUI is de facto standard. It has standard L&F if you like. If you dont then MUI programs dont have same L&F with Gadtools or Intuition BOOPSI classes but it is up to user.

If you dont like it then maybe ClassAct.

Quote
And before I make my programs depend on a several 100K framework, or risk license incompatibilities, I'd rather stick with intuition.


Instead you reinvent wheel and reimplement 100K framework to your application. Which is fine, memory is cheap. But my time is not cheap and I prefer to take any shortcut where possible.

Quote
Yes, that's "back to the 80th", but Amiga *is* the 80ths. Nobody will change this anymore.  Actually, that's a design problem intuition has, and the mentioned V45 was a first step around that. Not a solution. Anyhow, I don't think it is was a very serious problem since I rarely changed the resolution or bit-depth of the workbench.


I dont want my Amiga to look like 80s. I have Amiga 500 for that and is perfect for that task. I still have warm feeling when I see Kickstart 1.3 console prints. But for other purposes I want something better. It is good hobby still.

I recall there are many other occasions where Workbench tried to close its screen. But it is not important in this discussion.

Quote
Given the many design problems AmigaOs has, it is actually not a very serious problem. There are definitely more serious ones. The bigger mess is actually gfx.


Is it really so? It is little messy but from developer POV not too messy. To draw graphics primitives (in RTG) you use two different libraries (GFX and CGX API) and sometimes you mix it with some layers.library call to allocate clipped rastports. It is not very clean but as long as developer knows what functions to call it works well enough.

Internally it is bigger mess (in AmigaOS 3) where RTG subsystem must patch system. But that is not so much concern to developers.
My Amigas: A500, Mac Mini and PowerBook
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #40 on: July 12, 2014, 07:05:49 PM »
Quote from: itix;768786
MUI is de facto standard. It has standard L&F if you like. If you dont then MUI programs dont have same L&F with Gadtools or Intuition BOOPSI classes but it is up to user.
MUI never worked for me. It's license-incompatible. To remind you, I wrote freeware. Pay-nothing. If I would use it, users would have had to pay for the interface, but not for the software. Pay somebody else for my programs? I beg your pardon.

Anyhow, MUI doesn't solve the problem either. Consider a program that draws on the screen itself, preparing some kind of graphics. For the sake of the argument, consider your average Mandelbrot fractal generator. Now, how do you iconify this? Ok, you can create your *own* off-screen buffer and let the program render into that, and then always copy to the screen whenever there is one. But that's actually complete overshoot, and it also doubles the required resources. If you have a smartrefresh window, or even a superbitmap, this backing-store is already there, and transparently provided by the Os. So why not use it for exactly that, namely backing store while the window is not shown?  
Quote from: itix;768786
Instead you reinvent wheel and reimplement 100K framework to your application.  
Never did that. Gadtools worked nicely. Of course, that's fairly simple, but it was good enough for most cases. There was no need to go for the full-fledged 100K for MUI if I had everything I ever needed in ROM.  
Quote from: itix;768786
I recall there are many other occasions where Workbench tried to close its screen.  
As in? There is actually only a single Os call to do that. It could be called by programs that felt like it - in the beginning to save precious chip-ram - or for games to avoid screen-switching. Or to adjust the screen mode. It's non-crucial for the first applications since the memory situation improved. The latter is where it makes a difference, but this is typically not anoying since you do not adjust your screen every minute.

The purpose of iconification is not so much to get rid of the workbench, but to get a better overview on what's on the screen, and re-organize the windows. As soon as you have a couple of windows open, it becomes rather anoying to shuffle them around, and iconification is a solution.  
Quote from: itix;768786
Is it really so? It is little messy but from developer POV not too messy.  
Yes, it really is. Its entire design is too tightly coupled to the Amiga chipset (bitplanes, blitting) and hard to abstract from. A lot of code in P96 is just there to emulate the bitmap blitting. Gfx also documented too many of its internals and does not have a clean interface. So for example, the view and the viewport are entirely "open" structures, which led to the bizarre hack that gfx stores the monitor and viewmode information in the *colormap* because this one was *not* documented. And uses hacks like "GfxAssociate" to link external published structures that can be messed with by any user by its internal administration structures, simply because the documented structures became too small and unsuitable.

The entire monitor database is an extreme hack and has no clearly documented structure. Instead, it depends on a couple of Gfx-internal databases that were never documented.

Instead of using clearly defined "creation and destruction" functions like intuition does (OpenWindow/CloseWindow) - nowadays one would call this "constructors" and "destructors", gfx relies upon the user that he builds such structures "correctly", which is a nightmare for forwards compatibility - see above: Such structures cannot be extended.

Count for example the number of patches that go into gfx to make rtg happen - an entire hack-o-rama necessary for graphics cards, with a lot of emulation overhead due to the poor interface.

Ok, seriously: Gfx was slammed together, probably in a rush, without thinking and without any design. It's an excellent example for teaching people of how *not* to design a graphics primitives library.
 

Offline vxm

  • Jr. Member
  • **
  • Join Date: Apr 2012
  • Posts: 59
    • Show only replies by vxm
Re: Layers.library V45 on the aminet
« Reply #41 on: July 13, 2014, 12:23:10 AM »
Quote from: itix;768786
MUI is de facto standard.
As far as I remember, MUI does not support the 68000. I do not consider it as a standard.
AmigaOS has flaws but each correction affects third-party softwares. It is a pleasure to note that it is updated. Thanks.
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Layers.library V45 on the aminet
« Reply #42 on: July 13, 2014, 02:07:10 AM »
Quote from: Thomas Richter;768817
MUI never worked for me. It's license-incompatible. To remind you, I wrote freeware. Pay-nothing. If I would use it, users would have had to pay for the interface, but not for the software. Pay somebody else for my programs? I beg your pardon.


I dont have problem with that because I am also getting an advantage: I can write UI faster with MUI than without MUI.

Quote

Anyhow, MUI doesn't solve the problem either. Consider a program that draws on the screen itself, preparing some kind of graphics. For the sake of the argument, consider your average Mandelbrot fractal generator. Now, how do you iconify this? Ok, you can create your *own* off-screen buffer and let the program render into that, and then always copy to the screen whenever there is one. But that's actually complete overshoot, and it also doubles the required resources. If you have a smartrefresh window, or even a superbitmap, this backing-store is already there, and transparently provided by the Os. So why not use it for exactly that, namely backing store while the window is not shown?


I would use off screen buffer in *fast ram*. RAM is cheap and everyone is having more fast ram than chip/video ram. Rendering to fast ram is also going to be faster than into chip/video ram. Another advantage is you can have re-sizable window.

Quote
Never did that. Gadtools worked nicely. Of course, that's fairly simple, but it was good enough for most cases. There was no need to go for the full-fledged 100K for MUI if I had everything I ever needed in ROM.


But how do you implement font sensitive UI with Gadtools without writing your own layout manager? You have to find out current font (coding), then calculate gadget sizes and positions (more coding) and then finally open GUI and add gadgets. Then you must write your own event loop and add keyboard handling for shortcuts.

Quote
As in? There is actually only a single Os call to do that. It could be called by programs that felt like it - in the beginning to save precious chip-ram - or for games to avoid screen-switching. Or to adjust the screen mode. It's non-crucial for the first applications since the memory situation improved. The latter is where it makes a difference, but this is typically not anoying since you do not adjust your screen every minute.


If you change fonts it has to reopen WB screen. I dont know why but tuning AOS used to be my favorite hobby in the past.

Quote

The purpose of iconification is not so much to get rid of the workbench, but to get a better overview on what's on the screen, and re-organize the windows. As soon as you have a couple of windows open, it becomes rather anoying to shuffle them around, and iconification is a solution.


I agree.

Quote
Yes, it really is. Its entire design is too tightly coupled to the Amiga chipset (bitplanes, blitting) and hard to abstract from. A lot of code in P96 is just there to emulate the bitmap blitting. Gfx also documented too many of its internals and does not have a clean interface. So for example, the view and the viewport are entirely "open" structures, which led to the bizarre hack that gfx stores the monitor and viewmode information in the *colormap* because this one was *not* documented. And uses hacks like "GfxAssociate" to link external published structures that can be messed with by any user by its internal administration structures, simply because the documented structures became too small and unsuitable.

The entire monitor database is an extreme hack and has no clearly documented structure. Instead, it depends on a couple of Gfx-internal databases that were never documented.


Oh, I see. But it was also typical for that era.

Quote

Instead of using clearly defined "creation and destruction" functions like intuition does (OpenWindow/CloseWindow) - nowadays one would call this "constructors" and "destructors", gfx relies upon the user that he builds such structures "correctly", which is a nightmare for forwards compatibility - see above: Such structures cannot be extended.

Count for example the number of patches that go into gfx to make rtg happen - an entire hack-o-rama necessary for graphics cards, with a lot of emulation overhead due to the poor interface.

Ok, seriously: Gfx was slammed together, probably in a rush, without thinking and without any design. It's an excellent example for teaching people of how *not* to design a graphics primitives library.


When I am reading RKRM gfx part I am getting impression GFX was meant to be low level interface to game developers. It does go in detail how to load views or build copper lists. It explains BOBs and sprites and there are dual playfield examples.

Some of examples in RKRM are not even safe because they bypass Intuition. Which is weird.
My Amigas: A500, Mac Mini and PowerBook
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #43 on: July 18, 2014, 06:33:56 PM »
Short update, thus I revive the thread: Christian Sauer reported that you can actually use the V45 layers with CGfx *without* the LayersAntiHack program, provided that 1) you use CGfx version 4 (probably also: or better, if there is such a thing, I do not know) and 2) if you make sure that ENVARC:CyberGraphX/SUPERLAYERS is *not* set. IOW, make sure that you delete this file from ENVARC: Apparently, V45 is "super" enough. (-;
 

Offline biggun

  • Sr. Member
  • ****
  • Join Date: Apr 2006
  • Posts: 397
    • Show only replies by biggun
    • http://www.greyhound-data.com/gunnar/
Re: Layers.library V45 on the aminet
« Reply #44 from previous page: July 18, 2014, 07:33:59 PM »
Hi Thomas,

great work. Nice to see this update. Thanks!

What you say that Intuition could be enabled to support dragging windows out of the screen sound cool.
I like this feature.
How complicated would this be in your opinion?