Thomas Richter wrote:

Well... almost. And here comes the show stopper: You do not know at the time you hold the pointer to the window that the window pointer is still valid. Between quering the layer (or even immediately afterwards), the window could be gone. Remember, we're multitasking. ... To ensure that the window *does not* go away, you need to lock IntuitionBase.

It has been awhile since I've examined this aspect.
You are correct of course and thanks for reminding because I had forgotten.  I had a look through my MouseZone code and I can see that I realised this too back then.  I did manage to work with this.
It is different to what I was thinking now.  What I did was to add another type of thing I call 'watchers'.  Watchers are most usually commodities too but they are also added to a list held by MouseZone.  This was how I was eliminating the need to do the WhichLayer business again.

Thomas Richter wrote:

But as soon as you lock IntuitionBase, you cannot call any (or most) intuition functions anymore, so you're in a kind of henn and egg problem.

I hadn't had any problems with this with any of my zones.  It probably is worthwhile to add as a warning though.

Thomas Richter wrote:

Even worse, LockIBase brings most of the input system to a halt, as intuition's handler in the input device handler chain also needs access to this lock, thus the mouse pointer remains frozen for any activity that might affect the intuition state.

This is the stuff I can remember being most happiest with now.  I had experienced the pointer lag so I developed a solution to this as well.

Thomas Richter wrote:

Forbid() doesn't help, because intuition might be right in the middle of the process of removing the window, thus you do not know whether you're dealing with a valid window to begin with.  Only intuition can know *when* windows decease, and for this reason, only intuition has a safe access path to the windows. The problem is the window lifetime cycle.

Part of that solution is that I introduced a public lock for zone enabled apps so that they would not go away.  Commodities and zone enabled apps can handle things in two ways.  They can try to do everything while the MouseZone has locked IBase or zone enabled apps can return ZMR_DELAYEDRENDER which allows IBase to be unlocked.  The application can then be made to do whatever it needs without causing trouble for Intuition while the zone lock is still in place.

Thomas Richter wrote:

The problem is not with commodities (actually, probably the wrong access path to begin with, what do attempt here is not quite a commodity but would require direct access to the input events). The problem is the access control/life time of intuition windows you cannot intercept.  Should we ever get access to intuition, one of the first things to fix would probably provide reasonably better access to its menu system, but as the things are right now, there is really no safe way how to interact with it.

Is all good.  I'm fairly sure from what I've seen of my code that this is do-able.  But keep raising any concerns.  It helps.  If there is a problem I want to know about it so I can look at it.

Thomas Richter wrote:

Another issue, correct, but that's not quite what I'm after if I said "requester". I'm not talking about EasyRequest and friends. I'm talking about the stone-old, drop-dead intuition "Request()" function - a layer that can be replaced upfront on a window, to block input into that window. Such a requester can also be made to appear on a double right-mouse click. Only very few programs use intuition requesters ("SetVNC" being one), and even less programs use RMB-trap requesters (Databeckers stone-old "Profimat" being one), but nevertheless, the functionality exists.

Don't fully see the pathway on this yet.  Will have to think if it will affect the above.

Thomas Richter wrote:

Not without rewriting parts of intuition, unfortunately, the intuition/layers system of semaphores and locks is *very* delicate. I'm not against "fixing" intuition, but without proper licences for sources, this might be pretty hard to do. Be ensured that the *only* way for that is to re-do the intuition input handler completely...

I definitely agree that is the best way; probably incorporating my watcher system maybe.
But I think my approach will work too so far.
 

Thomas Richter wrote:

Oh, just a nice other nifty feature you should remember: IDCMP is *not* the only way how intuition communicates with windows. For the records, the console.device (and so ViNCEd, the 3.9 shell window) uses the input device chain downstream below the intuition handler to collect user input. (Use Xoper to check the list of input handlers - you'll see there intuition, console and - if installed - ViNCEd!) That is, you not only need to feed the IDCMP for "faking" menu events, you also need to pass "faked" input events downstream to more handlers if you replace or bypass the intuition handler. Again, *this* tiny detail is doable, but please take this as a warning. It is a very thorny road. Messing with the intuition input system is, due to its construction, a mere impossibility. Intuition needs probably not a fix, but a serious polish.

Again I'll have to wrap my head around this to see if my code and this clash at all.  Any further advice would be great.

Thanks Thomas.

To test this, open a RAW: window, and turn on the raw-events for MenuPick events. I forgot unfortunately the precise sequence for that, sorry, but you'll find it for example in the ViNCEd guide.

Events should be continued to delivered correctly.

Sorry - not quite correct yet, RAW: doesn't have a menu. Thus, here's the way to go:

Open a window, attach a menu bar, open a console.device in that window, and turn the menu pick RAW event on in that console unit, again using the CSI sequence. *That* should continue to work...

Touchy. I know. )-:

So long,
Thomas

#define APPAUTOMASKIA_Image 1000000
  
  struct ClassLibrary *pAutoMaskCL;
  
    if(pAutoMaskCL = (struct ClassLibrary *)OpenLibrary(
    "libs/automask.image",0))
  
    Object *pCheckMarkI;
  
    if(pCheckMarkI = NewObject(NULL,"automask.image"
      // Replace &rCheckMarkI with a pointer to your Image structure.
      ,AUTOMASKIA_Image,&rCheckMarkI
      ,TAG_END))
  

  DisposeObject(pCheckMarkI);
  
    CloseLibrary((struct Library *)pAutoMaskCL);
  

Ok I finally got my pain down low enough to try coping and pasting ur code:

The code seems to work, I can see the checkmark, the colors are correct, but there is no transparency.

Possible problems:
Bug in automask.image library?
Maybe initialization not done?
Maybe #define is off by 1 zero?

I always used to poke the checkmark into the struct NewWindow before I opened the window.  But due to chicken/egg syndrome with this new technique, I had to poke it in after the window was already opened. Is it ok to do that?

In the old version of the game that you have, the checkmark was drawn with a hard black background instead of a transparent one.
But I -am- using the new transparent checkmark now.  It just isn't being drawn transparently.

I am using automask.image 1.0  (02/21/10)  which I got direct from the author ;)

Team Chaos Leader wrote:

Bug in automask.image library?

Always possible.  Do different compilers compile things differently.  They shouldn't if they are ANSI compliant should they?

  BltClear(pData->amiid_Mask,wPlaneSize * 2,0x00);

Team Chaos Leader wrote:

Maybe initialization not done?

If the initialisation didn't get done the class wouldn't open.
I assume you would have added the needed { }s where necessary.

Team Chaos Leader wrote:

Maybe #define is off by 1 zero?

This all looks okay from what I can see.

Team Chaos Leader wrote:

I always used to poke the checkmark into the struct NewWindow before I opened the window.  But due to chicken/egg syndrome with this new technique, I had to poke it in after the window was already opened. Is it ok to do that?

If it works already it should be fine.  Is the chicken/egg syndrome due to MagicMenu is it?  Does it clear the checkmark?

Team Chaos Leader wrote:

In the old version of the game that you have, the checkmark was drawn with a hard black background instead of a transparent one.  But I -am- using the new transparent checkmark now.  It just isn't being drawn transparently.

Once you convert an ilbm to an Image all the transparency info is lost.  So this isn't really a problem for my class as you are supplying the Image to it which won't have any transparency.  My class than creates a mask.
The only problem that may occur is if the transparent colour is not colour 0.  My class assumes that colour 0 is the transparency colour.  If the back is not colour 0 then it won't get transparent with my class.
Another reason why a mask might not be created is if any bits are set in the Image->PlaneOnOff.  This will only occur if one of the planes is all 1s but then there would be no colour 0.  You said you don't presently use PlaneOnOff didn't you?

Team Chaos Leader wrote:

I am using automask.image 1.0  (02/21/10)  which I got direct from the author ;)

There's your problem ;)  Should be working hopefully!

gone gahgah wrote:

BltClear(pData->amiid_Mask,wPlaneSize * 2,0x00); I must admit the '2' in the above code in the class has been shoved in simply because it makes my code work.  I wouldn't have thought it was necessary but without it only the top half of the allocated mask is precleared.

Team Chaos Leader wrote:

1. Is the data in chipram?

I use AllocRaster() so I assume that is the case.  ie.

  pData->amiid_Mask = (PLANEPTR)AllocRaster(pObject->Width
     ,pObject->Height)

Team Chaos Leader wrote:

2. Maybe u miscalculated wPlaneSize?  The checkmark is 2 words wide, not 1 word wide.  8 planes deep.

I only need one plane for the mask so I use the following formula which I was lead to believe was correct.

   wPlaneSize = ((pObject->Width + 15) >> 4) * pObject->Height;

Team Chaos Leader wrote:

Inserting a *2 fudge factor looks as bad as global warming Climate Gate.

I know.  Makes my tummy queasy.

Team Chaos Leader wrote:

Maybe initialization not done?

gone gahgah wrote:

If the initialisation didn't get done the class wouldn't open.

Team Chaos Leader wrote:

I donno what you mean?

The Class_Init() function is called when you OpenLibrary() the class so if it is unsuccessful the class library won't open.

gone gahgah wrote:

I assume you would have added the needed { }s where necessary.

Team Chaos Leader wrote:

I donno what you mean?

I gave the example as:

  if(pAutoMaskCL = (struct ClassLibrary *)OpenLibrary(
     "libs/automask.image",0))
     Object *pCheckMarkI;
     if(pCheckMarkI = NewObject(NULL,"automask.image"
       // Replace &rCheckMarkI with a pointer to your Image structure.
       ,AUTOMASKIA_Image,&rCheckMarkI
       ,TAG_END))

  if(pAutoMaskCL = (struct ClassLibrary *)OpenLibrary(
     "libs/automask.image",0))
     {
     Object *pCheckMarkI;
     if(pCheckMarkI = NewObject(NULL,"automask.image"
       // Replace &rCheckMarkI with a pointer to your Image structure.
       ,AUTOMASKIA_Image,&rCheckMarkI
       ,TAG_END))
       {
       return(TRUE); // or some such thing...
       }
     }

Team Chaos Leader wrote:

I used to poke in a ((pointer to a struct Image) that had no datapointer) into the struct NewWindow then OpenWindow that struct then later on I would process .iff files and fill in the data gfx part of the struct. Processing the iff files uses the same window/rastport that I am setting the checkmark in.

My understanding of it is that: as long as you don't have any menus attached to the window or remove them first before changing the checkmark there should never be a problem.  If not you may get a very rare crash if the writing of the checkmark pointer is interrupted by Intuition wanting to draw the checkmark with that only partially updated pointer.  The pointer would then be invalid and point to who knows where.

If you can get your new checkmark over to me I'll have a look at it first before looking at the remainder.

My best GUESS atm is that your Picasso96OS hacked into AllocRaster() and inserted a bug which causes it to round up all requests to the nearest 64-bits.  This causes the raster to be twice as big as it is supposed to be.

It is a FACT that AllocRaster() is rather useless and has some sort of horrible bug/flaw that I found many many years ago. I can't remember what it was but it scared me away so I have never used AllocRaster() since then.  I banned AllocRaster() from all my source code.

I hope that AllocRaster() is not causing you a problem.  I just giving you this info to ponder.

p.s. I am not running P96OS.

Ok here I found a more likely bug!
You probably calculated the mask and stored it properly then the superslow blitter came along and overwrote it all with 0's just as u told it.

SOLUTION:
Change your BltClear() flags from 0 to 1
make it look like this:

   BltClear(pData->amiid_Mask,wPlaneSize * 2,0x01);

I'm thinking that wPlaneSize might actually be the number of words in the plane instead of the number of bytes.
I'm thinking this because (16 + 15) >> 4 = 1 word which is equivalent to 2 bytes.  If this is the case then it all makes sense.
The pPlane is a (WORD *) so in C if you add a value to it - such as wPlaneSize - doesn't the compiler automatically double that?

Doh! Yes of course that is it.
u should rename wPlaneSize to wPlaneSizeInBytes or wPlaneSizeInWords to avoid future confusion.

ok so the *2 thing is settled.  Now, why is there no transparency?

Should I recompile the class and send it to you?

Yes pls.

Does my transparent checkmark appear transparent to you?

The checkmark itself appears to be fine though.  When I load it into PPaint I can see that the back is all colour 0.

I have sent the updated library to you.  Hopefully that fixes the problem...

I even completely removed Magic Menu out of my SS but that made no difference.

I can send you my loader code if you want, but it only does IFFs, not PNG.

There are a few things that you have said in respect of your code previously that I have had questions about.

I think I recall that you said that you use iff.library.  Why don't you use the official iffparse.library?

You also said that you don't use PlaneOnOff instead filling every plane in the image structure (even if a plane is all 0's or 1's).
I imagine that you set PlanePick as 0xff and Depth as 8.
Why don't you use PlaneOnOff?

They were just some questions that struck me.
I would probably prefer to use iffparse.library.
Anyhow, I'll go have a look at your code now.

iff.library is small, fast and easy.

If iffparse.library was easy to use you would have already used it decades ago, right?

Everyone is free to use whatever library they want, as long as it works.

You also said that you don't use PlaneOnOff instead filling every plane in the image structure (even if a plane is all 0's or 1's).   I imagine that you set PlanePick as 0xff and Depth as 8.   Why don't you use PlaneOnOff?

1. I don't use struct Image enough for it to matter.  There are 30,000 gfx in the game but only 30 struct Image.  I almost never use DrawImage(), its way to slow for anims.  My gfx routines cruise at 32x-70x faster than AmigaOS and can be upto 144x faster in the extreme case (really heavy animation).

2. Most of my 30,000 gfx are large and probably don't have blank or full planes.  Properly drawn game gfx have a lot of colors with no blank planes.

But u do have a point, some of my gfx must have empty planes. I could code special gfx routines to process them....  I guess for any tiles that have empty planes I could increase my anim speed. (!)

I wish u had made me think about that back in the 90's when ppl still cared about AGA. I could have made my routines go faster!  Yeah!  When I mix the text overlay over the realtime animated gfx, that really overloads the fastram bandwidth I think.  And text has a lot of empty planes!  The text could have been mixed in almost for free!  Where were you when I needed u?!?! :)

Of course I would have to seriously consider the cost/benefit of doing that. I would have to add at least 1 extra cmp/bra to the start of each bitplane of each gfx.  So that is 1 extra brach to sometimes save 32 move.l    I hate branches.  If u have a tile that has 1 empty bitplane then that will cause 2 mispredicted branches, which is a lot of wasted cycles.  But then I get to save 32 move.l from fastram + I assume I could save the shadowmask anding/oring for that plane.  OTTOMH I will say that saves 32 more cycles.  So I guess using planepick in my general anim routines would be a bit faster most of the time and a lot faster in certain circumstances.

They were just some questions that struck me.   I would probably prefer to use iffparse.library.

Fine with me :)  Good luck :)

BTW you do great documentation in your code.  Makes it much easier to follow.

I have already written a loader that loads the back picture in something else I wrote using iffparse.library.  I will try to modify this to load the images.  Ultimately it might be more sensible to use iff.library as doing that certainly saves on coding.

p.s. if u really want to make a good loader, we really need a good .png loader.

I've gone with the following steps:

Step 1: Create pen remap array for converting file colours to screen colours.
Step 2: Go through new pens to determine the image depth (d2) & planepick.
Step 3: Allocate memory for target image.
Step 4: Allocate memory to hold a scanline.
Loop 1: Step through each row of plane 0 of the image.
   Loop 2a: Step through each depth level of the scanline.
     Loop 3a: Pass through each byte of the depth level of the scanline.
       Step 5: Load the byte indicated by the file into the current byte.
         Loop 4a?: Copy nbr of bytes from file into scanline depth.
         Loop 4a?: Copy next file byte nbr of times into scanline depth.
   Loop 2b: Step through each byte of the 1st depth level of the scanline.
            Step through each byte of the current plane 0 row.
     Loop 3b: Step through each byte bit from MSB to LSB.
       Step 6: Set PenColour as 0x00.
       Loop 4b: Step through each depth level at the current byte offset.
         Step 7: Read bit from current depth level at current byte offset.
         Step 8: If 1, Or PenColour with bit corresponding to current depth.
       Step 9: Convert file PenColour to the PenColour obtained from screen.
       Loop 5b: Step through each bit of the final PenColour.
                Step each plane for the current row at current byte offset.
         Step 10: If 1, Or ImageData in the current depth row byte offset.

I am using colour remapping because I will want to make the menu system available on user screens; so remapping is required.
It should be possible to modify it later to go with the existing screen colours.

You will remap gfx incorrectly every time you are dealing with a color cycling screen.