I always fill all bitplanes with the real data.

One of the things I will have to do anyway with my menu project is to make the code easier to read.  What was I thinking?

I will put one function per file and name the file after that function.  That is the way I prefer to do it these days.

All this hunting around trying to find the functions is driving me crazy at the moment.

I will have to add an iff loader to my menu project sometime I suppose and stop taking the short and dirty track with the temporary hard coded images.  I've written one that works correctly elsewhere so I'll have to rip it out of there and transfer its workings.

How I find my functions:
ff #?.h FunctionName

Where ff is FlashFind from Aminet

I was thinking with the menus that I can implement different text versions of the same item (ie. Undo, Undo Stretch, Undo Rotate, Undo Delete) as whole text items rather than multi-text items.

So instead of 'Undo %s' I could just have them all in the full forms.

Is there any situation that we would need to have multi-text items?
Like: Logout Sarah, Logout Matthew.

Obviously these are combining set text with adhoc items.

Thus, sorry to got lost, but I don't understand the problem????

Thomas

What are you doing, and why do you believe to have a leak?

Thanks,
Thomas

Apparently all that needs to be done is put 0 in the bitmap plane array for planes that are all 0s and -1 in the bitmap plane array for planes that are all 1s.
So easy and it works but I didn't know before.

I'll do up a custom class for you and see if it suits your needs.
It will presently take an image as the source and will generate a mask for the image automatically.

   pCheckImage = NewObject(BITMAP_GetClass()
     ,NULL
     ,BITMAP_SourceFile,"Gadgets/English/CheckmarkForMenus.iff"
     // ,BITMAP_Precision,PRECISION_EXACT
     ,BITMAP_Screen,pScreen
     ,BITMAP_Masking,TRUE
     ,TAG_DONE); 

I assume the iff.datatype causes the memory leak, but who knows?

    pCheckImage = NewObject(BITMAP_GetClass()
      ,NULL
      ,BITMAP_SourceFile,"Gadgets/English/CheckmarkForMenus.iff"
      // ,BITMAP_Precision,PRECISION_EXACT
      ,BITMAP_Screen,pScreen
      ,BITMAP_Masking,TRUE
      ,TAG_DONE); 

Otherwise, my suggestion was less to load the image from a file, but rather to provide a boopsi method that uses a masked blit, i.e. create a custom boopsi via MakeClass/FreeClass.

Greetings,
Thomas

  IF (pCheckImage) DisposeObject(pCheckImage);
  IF (BitMapBase) CloseLibrary(BitMapBase);
  

My ilbm.datatype is 44.9 (08/02/00)
My Classes/Images/bitmap.image is 44.1 (07/14/99)

This explains why the mem leak was randomly sized!

I could have figured this out on the 1st day but ooowwwww I had to stop or die.

The moral of the story is 1: Disable Samba before debugging and 2: A person in pain can't think straight!

/me bestows the Lamest Amiga Coder of the Year Award to Team Chaos Leader

CONCLUSION: No memory leaks from BOOPSI detected.  Sorry for the false alarm guys.  Please shoot me now.

Thanks Thomas also.  I'd forgotten that a class doesn't need to be turned into a library.  So I'll go write that class for you now TCL as a private class so that your OS 3.0 users will be able to have backless amiticks.

I've finished creating the class now.  I'll have to test it first and then send it over to you TCL.  I'll do that later.

I've only just noticed with the Amiga menu system that it displays some unusual behaviour when it comes to dragging over check items.  That is something I will have to change...

I worked around it by doing a LoadRGB32(viewport,ColorTable);

Remapping when no remapping needed is a huge waste of CPU power.

 
  Sorry but this BOOPSI coding concept still confuses me.  For example why on Earth must I need to specify a screen for a BITMAP class? It would makes sense to supply a bitmap for it to load into but not a screen.  What if a CLI command never opens any screen?  It gets BANNED from using BOOPSI/Datatypes?
 

No. Boopsi is a software layer within intuition, it is not related to P96 or CGfx. Boopsis may do whatever the graphics library offers, by means of calling the right functions. For example, drawing with transparency. That is something the native hardware, cgfx and P96 support by means of transparent blits. And *those* are used to create the transparency, i.e. P96 patches the corresponding graphics.library calls, not intuition.

Greetings,
Thomas

Team Chaos Leader wrote:

Maybe it did return an Image struct but it remapped the colors of the brush.  I never gave it permission to remap my colors.

Datatypes usually do that, or may do that. At least, they don't offer enough flexibility to do exactly what you need, and the result may even depend on the specific datatype in the system.

As said, I don't think *loading* the image is the right way to go. Instead, design a new image class with MakeClass(), deriving it from the "imageclass" and use a transparent blit in its drawing hook, see p.311ff of "RKRM: Libraries". Then create a boospi of that class, and install it as image into the menu/gadget.

The clue is here that any boopsi derived from "imageclass" can be used transparently wherever a "struct IntuiImage" was valid before. Thus, to do exactly what you want, create a "imageclass" boopsi that *does* exactly what you want.

Steps:

1) Create a private new boopsi class, derive it from "imageclass" with MakeClass(). Leave newclassid NULL to make it a private class.
2) Install the boopsi function dispatcher into myclass->cl_Dispatcher.h_Entry, and write a dispatcher method with __saveds prototype (or set h_SubEntry and use the HookEntry function from the Amigalib).
3) In the dispatcher function, check for the OM_DRAW and OM_DRAWFRAME method. Pass other methods through to the superclass.
4) In the draw method, use the Gfx masked blits (a bitmap as mask, and another as the graphics you want to draw) to render the image. Alternatively, draw it manually by means of line drawing. You can use all the calls from the gfx library here, just remember that you're called in the context of the input.device event dispatcher so you're probably better fast.
5) Now create an *instance* of this class by NewObjectA(). The "privclass" pointer should be a pointer to your class (what you got from MakeClass) and the pubclass name should be NULL (you are using your own boopsi now).
6) Use that instance wherever a "struct IntuiImage" would be valid. This works because you derived from the "imageclass".
7) When done, first dispose the object(s) by DeleteObject().
8) Then dispose the class by RemoveClass().
9) Enjoy!

Greetings,
Thomas

I am surprised because if you have the colours already locked in your screen then it should remap to the same colours.  But maybe not?  It worked fine when I loaded it into my menus on the Workbench screen.

You are correct that bitmap.image does try to remap.  That is the only reason that the screen argument is supplied.  So that it can obtain the best colour from those currently used by the screen or if need be obtain the next free colour.
You will have noticed that I left the option BITMAP_Precision commented out.  The values this can be set to are:
PRECISION_EXACT -1
PRECISION_IMAGE 0
PRECISION_ICON 16
PRECISION_GUI 32
So maybe you should set this as: BITMAP_Precision,PRECISION_IMAGE

The NewObject() is defined as APTR apparently.
It returns a pObject which you normally defined as Object *.
The Object is just typedef'ined as ULONG.  ie typedef ULONG Object;
This is all just a way of saying that 'objects' are black boxes and when you call an object you don't need to know what it contains.

What NewObject() actually returns is a pointer to a block of memory that is made up of all the data that is defined for the class plus all the data defined for its superclasses.  That data could be anything and is defined by the class coders.  There is also a pointer to the class before this data so that the object can find its data amongst all the other superclass data.
ie.  [pClass,rRootData][rSuperSuperData,rSuperData,rObjectData,etc]
as a guess...

So basically the data could be anything.

But, in order to maintain backward compatibility with the old structures, the Amiga had to compromise on this black box policy.
This is only the case for images and gadgets.
The pointer returned by NewObject() actually returns a pointer to what is a valid Image or Gadget structure for these two.
All the other data for the superclasses, subclasses and pClass are appended around this legacy structure.
ie. [pClass,rRootData][rImage,rSuperData,rObjectData]
as a guess...

The above are ment to depict [before pointer][from pointer].
I assume the Root Data lies before the pointer so that the Image and Gadget data could be put at pObject+0.
The pClass may even be part of the root data; I don't know.

The main thing is that for an image or a gadget you do get back a valid image or gadget structure.  However they have extra data before and after the image or gadget structure relevant to rootclass and subclasses.

The main thing is you should never write to any the fields directly if you are accessing the object.  Those fields should only ever be written to by the class for that object.  Instead you need to use the methods supplied.

Some of the fields are okay to read such as Left, Top, Witdh, ...

Having said all that it will be partly easier to see what I mean when I send you the automask.image class that I have written.
You won't have to worry about any remapping with mine as I take the data that you supply and rely completely on that.  The only thing I do is generate a mask based on where the image is colour 0.

A CLI command can use BOOPSI.  It is only that the writers of bitmap.image have decided that they will obtain information they need via the screen.  Maybe they need to lock the screen but I don't see why.  You will find in the class that I will send to you that I do not ask for your screen at all.  I rely completely on the data you create the object with.

The only thing I do rely on is the rastport that is supplied to me when I am asked to draw the image.  This is supplied by the DrawImage() command as one of its arguments.

There are two aspects to BOOPSI coding.  One is calling existing classes.  The other is writing your own classes.

The first one is the best first step.  Apart from not knowing what is going on inside the object and not knowing what data it contains, it is just defined by a set of methods (or commands).  You just need to find the class that does what you need and rely on it to do it.  Just like a library command I guess except library commands don't contain data and only have one call not multiple methods.  You have to pass all data to a library command but an object can contain data specific to its instance.

As an example the file open command requires you to pass the FILE * to it but a file object would contain the FILE data so you wouldn't have to pass this to it.  And where you have multiple commands to operate on the FILE handle; you only have one object and can call it with different commands.  So you see the difference is about data encapsulation.

The main advantage with classes is that you don't have to try to write a one structure fits all structure.  You end up putting in more data than you need.  If the Amiga had BOOPSI from the start then it would be likely that the image and gadget fixed structures would never have existed.

None of the other base classes, except for image and gadget, has a base structure simply because it is undesirable.

It worked fine when I loaded it into my menus on the Workbench screen.

Does it look every bit as good as as it does when you view the CheckMarkForMenus.iff in Viewtek? (or other pic viewer)

You are correct that bitmap.image does try to remap.  That is the only reason that the screen argument is supplied.  So that it can obtain the best colour from those currently used by the screen or if need be obtain the next free colour.   You will have noticed that I left the option BITMAP_Precision commented out.  The values this can be set to are:   PRECISION_EXACT -1   PRECISION_IMAGE 0

I have already tried those over and over.
As far as I am concerned they are both broken, bugged and useless.

PRECISION_ICON 16   PRECISION_GUI 32

I did not try those.