code:

---

AROS_LD2(APTR, NewTool,
         AROS_LDA(APTR, pf, A0),
         AROS_LDA(APTR, pool, A1),
         struct AmiStartBaseP *, AmiStartBase, 8, AmiStart);

---

code:

---

AROS_LH2(APTR, NewTool,
         AROS_LHA(APTR, pf, A0),
         AROS_LHA(APTR, pool, A1),
         struct AmiStartBaseP *, AmiStartBase, 8, AmiStart)
{
    AROS_LIBFUNC_INIT
    AROS_LIBBASE_EXT_DECL(struct AmiStartBaseP *,AmiStartBase)
        
			/* library function code */
    return (APTR) _NewTool(pf, pool, AmiStartBase);
    
    AROS_LIBFUNC_EXIT
}

---

code:

---

//deklaration
void Test1();
void Test2();
void Test3();

//definition
void Test1() {
....
}
void Test2() {
....
}
void Test3() {
....
}

Functable:
 (APTR) Init,
 (APTR) Expuge,
 ...
 ...
 ...
 (APTR) Test1,
 (APTR) Test2,
 (APTR) Test3,
 NULL,

---

code:

---

DEF_FUNC(Test1) {}
 DEF_FUNC(Test2) {}
 DEF_FUNC(Test3) {}

FuncTable:
 ...
 FOR(i=1; i < NUM_FUNC, I++) {
  (APTR) FUNC_NAME(i)
 }

---

code:

---

gcc ... -DDATETXT="20.08.2004" ...

---

code:

---

DISPATCHERPROTO(MyImageDispatcher) {

 
	   DISPATCHER_INIT
           APTR ptr = GetUserData(cl);
	   switch (msg->MethodID)
	   {
		   case OM_NEW          : ...
	   }

	   return((ULONG) DoSuperMethodA(cl,obj,msg));
	   DISPATCHER_EXIT
   }

---

code:

---

DISPATCHERPROTO(MyImageDispatcher) {

	   DISPATCHER_INIT
           APTR ptr = cl->cl_UserData;

	   switch (msg->MethodID)
	   {
		   case OM_NEW          : ...
	   }

	   return((ULONG) DoSuperMethodA(cl,obj,msg));
	   DISPATCHER_EXIT
   }

---

code:

---

mcc = MUI_CreateCustom..()
mcc->mcc_Class->cl_UserData = ...;

---

Zitat:

---

Original von MarkusPohlmann:
Heute mache ich sowas nur, wenn abzusehen ist, dass sich der Speicherbedarf doch noch mal vergrössern könnte (als Puffer für Updates sozusagen).

---

code:

---

ULONG Image[NUMIMAGES][WIDTH*HEIGHT];

---

code:

---

ULONG Image[8][30*30];

---

code:

---

if (cr->BitMap) _dx = cr->bounds.MinX & 0x0f; else _dx = 0;

---

Zitat:

---

Original von Georg:
Wenn ein ClipRect zum Beispiel die bounds Koordinaten 130,100 - 170, 200 hat, dann ist die Offscreen bitmap praktisch für Kooridnaten 128,100 - 143,200 "ausgelegt". Die Start-X Kooridnate ist also auf ein Vielfaches von 16 abgerundet. Die End-X Koordinate auf ein Vielfaches von 16 aufgerundet minus 1.

---

Zitat:

---

Der Grund dafür sind die Planaren BitMaps bei den Classic Amigas. Wenn die BitMaps so aligned sind wie beschrieben dann kann offscreen-bitmap bereich mit onscreen-bitmap bereich umgeblittet werden ohne horizontal shiften (0 ... 15) zu müssen was einfacher und schneller ist. Für den Blitter.

---

Zitat:

---

Die ClipRects selbst "durchzugehen" sollte man aber eigentlich nicht tun. Ist evil! Man kann cgfx/DoCDrawMethodTagList() verwenden, welches für jedes relevante ClipRect eine User Hook Funktion aufruft mit den notwendigen Daten.

Aber auch da sollte man nicht davon ausgehen, daß das überall und immer funktionert. Z. B. unter AROS hosted/Linux tut es da nicht, weil dort Direktzugriff auf Screen bitmaps/friend bitmaps von screen bitmaps nicht unterstützt wird.

---

Zitat:

---

Gehe ich damit falsch an die Sache ran? Array besser noch grösser allokieren? Oder besser händisch allokieren (AllocVec)?

---

code:

---

picture.datatype V43
                          Copyright 1995-97
                           Ralph Schmidt
           Additional libs/tools/changes by F.Mariak/M.Scheler
  	       Sub datatype classes by Matthias Scheler

---

Zitat:

---

Original von Holger:
Aargh.
Irgendwie werden Env-Variable inzwischen für alles mögliche mißbraucht. Env-Variablen sind nicht dafür da, tiefgreifende System-Routinen zu steuern. Schlimm genug, daß WarpOS Benutzer sich damit quälen müssen.

---

Zitat:

---

Wenn ein Programm eine Routine aufruft, sollte deren Arbeitsweise so sein, wie das Programm es will, und nicht wie ein User es per Env-Variable definieren mußte. Wenn das Programm eine Verhaltensweise konfigurierbar machen will, muß das Programm diese Option anbieten, nicht das Datatype.

---

Zitat:

---

...
ist, könnte man dessen Bedeutung umdefinieren. Ansonsten gibt's noch den DrawMode, der zwischen Vordergrund und Vorder+Hintergrund unterscheidet. Auch der wäre passabel.

---

Zitat:

---

Original von Georg:
Das mit dem DRAW ist auch so ne Sache. Wer sagt denn daß ein datatype Benutzer es immer so will, daß alpha-geblendet geblittet wird? Möglicherweise will er ja die Daten in der BitMap so wie sie im Original PNG File waren (also praktisch wie per READPIXELARRAY nur will er halt die Daten direkt in ner BitMap anstatt in nem PixelArray), und nicht zusammengemixt/geblendet mit dem Hintergrund.

---

Zitat:

---

Original von Anjis:
Also ich find es auch schade das das Interesse an einer Weiterentwicklung wohl weniger besteht,so habe ich es jedenfals rausgelesen,kann mich auch irren.

---