amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Privilegverletzung bei FreeBitMap() [ - Search - New posts - Register - Login - ]

-1- 2 3 [ - Post reply - ]

2004-10-31, 12:16 h

Reth
Posts: 1858
User 		Hallo mal wieder,

ich habe eine Problem beim Freigeben meiner BitMaps.
Am Ende des Programms werden bei mir alle mit AllocBitMap() angelegten BitMaps mittels FreeBitMap() freigegeben es wird der jeweilige Zieger verwendet.

Bei einigen BitMaps klappt das problemlos, doch immer an derselben Stelle bekomme ich eine Privilegverletzung und weiss nicht wieso?

Was könnten Gründe dafür sein?

Hat da jmd. ne Idee?

Danke schon mal!

Ciao

[ - Answer - Quote - Direct link - ]
2004-10-31, 14:01 h

thomas
Posts: 7718
User
Vermutlich hast du über den Rand der Bitmap hinaus gezeichnet und damit irgendwas zerschossen. Normalerweise bekommt man dann einen 0100000c oder 01000005 oder so, aber bei unvorhersagbaren Ereignissen weiß man ja nie.

Oder du hast doch den falschen Pointer übergeben.

Laß halt mal Mungwall mitlaufen. Und wenn du auf einem richtigen (Classic) Amiga bist, auch Enforcer bzw. Cyberguard.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-10-31, 23:53 h

Reth
Posts: 1858
User 		Danke für die Tips!

Habe mir mal 2 Versionen vom Enforcer ausm Aminet geholt.
Beide bringen mein System (A4000/060/PPC233) zum Einfrieren/Absturz!
Nich so doll das!

Werde mal MungWall probieren und mich auf die Suche nach dem Cyberguard machen!

HIer auch mal mein Code zum Initialisieren der einzelnen BitMaps.Der tut eigentlich ganz gut. Noch nicht ganz OO!
Zeichne auch nicht in die BitMaps, sondern blitte sie nur in andere BitMaps!

[i]
void FrameC::initBitMap(struct BitMap *friendBitMap)
{
bitMap = AllocBitMap(width, height, SCREENDEPTH, BMF_DISPLAYABLE, friendBitMap);
InitBitMap(bitMap, SCREENDEPTH, width, height);

// Berechnen des Offset der einzelnen Bitplanes
// zuerts Bytes per Row bestimmen
int planeoffset = width/SCREENDEPTH;

// Bytes per row müssen immer gerade Anzahl haben und dabei multipliziert mit SCREENDEPTH >= width sein
while (((planeoffset*SCREENDEPTH) < width) || ((planeoffset%2) != 0))
{
planeoffset += 1;
}

// Offset der einzelnen Bitplanes = Bytes per Row mal Höhe für jede Bitplane
planeoffset = height*planeoffset;

for (int i=0; i<SCREENDEPTH; i++)
{
bitMap->Planes = (PLANEPTR)&data[i*planeoffset];
}
}


[ Dieser Beitrag wurde von Reth am 01.11.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-11-01, 03:13 h

bubblebobble
Posts: 707
User 		Stürzt das auch ab, wenn du nur sllocierst und sofort
wieder frei gibst ? Wenn das nicht abstürzt, dann
zeichnest du mit ziemlicher Sichereit irgendwann mal über
den Bitmap Rand, und zwar oben oder unten. Nicht nach rechts oder links,
weil das ja speichermäßig wieder in der Bitmap liegen würde und keinen Fehler produziert, ausser einem Grafikfehler, den man sehen würde.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2004-11-01, 08:50 h

thomas
Posts: 7718
User
Zitat:
1. bitMap = AllocBitMap(width, height, SCREENDEPTH, BMF_DISPLAYABLE, friendBitMap);
2. InitBitMap(bitMap, SCREENDEPTH, width, height);

Um Gottes Willen ! Zuerst allokierst du mit OS3-Mitteln eine RTG-Bitmap und dann zerstörst die ganze Struktur, indem du mit mit OS1-Mitteln die Fehlder neu initialisierst, vermutlich mit ganz anderen Werten. Kein Wunder, daß das abstürzt. Im Gegenteil, es ist ein Wunder, daß du mit der Bitmap überhaupt arbeiten kannst.

AllocBitMap macht alles für dich. Und die Bitmap-Struktur ist anschließend eine Black-Box. Du darfst nicht reinschreiben, nicht rauslesen und schon gar nicht irgendwelche Annahmen machen. Wenn du zwingend eine planare Bitmap brauchst, mußt du sie komplett selbst anlegen, nach OS1-Stil:

bitmap = AllocVec ();
InitBitMap (bitmap);
bitmap->PlanePtr[i] = AllocRaster(w,h);

Nur dann kannst du irgendwelche Annahmen über die Felder der Bitmap machen (wie z.b. BytesPerRow).
Das setzt natürlich voraus, daß die Tiefe kleiner oder gleich 8 ist.

Wenn du RTG- und zukunftssicher sein möchtest, mußt du mit AllocbitMap arbeiten und darfst nur mit GetBitMapAttr darauf zugreifen. Bitplanes gibt es dann nicht mehr, die Bitmap kann genausogut chunky sein, das kannst du nie wissen, vor allem wenn du mit einer Friend-Bitmap arbeitest.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ Dieser Beitrag wurde von thomas am 01.11.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-11-01, 10:50 h

Reth
Posts: 1858
User 		@Thomas:

Wusste nicht, dass ich AllocBitMap() und InitBitMap() nicht zusammen verwenden darf und auch die BitPlanes nicht selber belegen darf!

So hat's allerdings funktioniert. Hatte keine Probleme mit den BitMaps, die Grafik ist in Ordnung. Ich kann viele der BitMaps freigeben, nur bei immer der gleichen BitMap-Freigabe (also immer bei derselben Grafik wenn man so will) kommt der Privilegfehler.
Bei InitBitMap() werden auch keine anderen Werte genommen.

Wenn ich die BitPlanes selbst mit Daten belegen will, ist dann folgende Vairante sinnvoll?

[i]
struct BitMap bitMap;

InitBitMap(&bitMap, SCREENDEPTH, width, height);
...
bitMap.Planes = ...

[ - Answer - Quote - Direct link - ]
2004-11-01, 16:19 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Wenn ich die BitPlanes selbst mit Daten belegen will, ist dann folgende Vairante sinnvoll?

[i]
struct BitMap bitMap;

InitBitMap(&bitMap, SCREENDEPTH, width, height);
...
bitMap.Planes = ...
Wenn Du eine BitMap nach OS1.x-Methode von Hand anlegst, mußt Du dafür Sorge tragen, dass die Tiefe max. 8 ist, und alle BitPlanes im ChipRAM liegen.
Wenn Du vorhast, ein Programm zu schreiben, dass hardwareunabhängig läuft, solltest Du auf diese Performance-Bremse verzichten. Es gibt eigentlich keinen sinnvollen Grund, eine BitMap auf diese Weise anlegen zu wollen, es sei denn, Du schreibst eine Hardware-Demo.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2004-11-01, 16:24 h

Reth
Posts: 1858
User 		Hallo Holger,

danke für den Rat.
Zitat:
Original von Holger:
Wenn Du eine BitMap nach OS1.x-Methode von Hand anlegst, mußt Du dafür Sorge tragen, dass die Tiefe max. 8 ist, und alle BitPlanes im ChipRAM liegen.
Wenn Du vorhast, ein Programm zu schreiben, dass hardwareunabhängig läuft, solltest Du auf diese Performance-Bremse verzichten. Es gibt eigentlich keinen sinnvollen Grund, eine BitMap auf diese Weise anlegen zu wollen, es sei denn, Du schreibst eine Hardware-Demo.

Was wäre dann die hardwareunabhängige, performantere Methode (die würde ich bevorzugen)?

AllocBitMap() und FreeBitMap()?
Aber wie weise ich den BitPlanes dann meine Grafikdaten zu?
Letztere liegen in *.h-Dateien ab (als UBYTE[]), die ich in mein Programm include.

Wie bekomme ich die dann in die BitPlanes?

[ - Answer - Quote - Direct link - ]
2004-11-01, 17:31 h

bubblebobble
Posts: 707
User 		Infos über Bitmaps kannst du mit GetBitmapAttr() und/oder
LockBitMapTagList() holen, aber das ist nicht zu empfehlen,
da du keine Annahmen über die Struktur der Bitmap machen darfst, also ob und wie viele Bitplanes es sind, es können ja auch Chunky oder 16, 24, 32 Bit - Bitmaps sein.

Generell solltest du keine Bitmap direkt anfassen wenn du systemkonform sein willst. Immer nur über OS Routinen gehen.

Informationen nur über Funktionen holen wie
GetBitmapAttr()

oder

handle = LockBitMapTagList(BitMap ,LBMI_BASEADDRESS,&destaddr,LBMI_BYTESPERROW,destbpr);
If (handle) UnLockBitMap (handle);

Aber besser nicht hinein poken!


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2004-11-06, 17:46 h

Reth
Posts: 1858
User 		Aber wie bekomme ich denn die Grafikdaten in eine mit AllocBitMap() angelegte Bitmap, so dass ich diese auch mittels Maske blitten kann?

In den Antworten waren immer nur lesende Zugriffe auf die BitMapStruktur angegeben?

Ich hab schon gesagt bekommen, dass das mit WritePixelArray8() gehen soll, aber wie weise ich denn der BitMap nen RastPort zu (normalerweise ist es ja umgekehrt)?

[ - Answer - Quote - Direct link - ]
2004-11-06, 20:47 h

thomas
Posts: 7718
User
Du machst es ja auch umgekehrt:

rp = AllocVec (sizeof(struct RastPort),MEMF_CLEAR);
InitRastPort (rp);
rp.BitMap = ziel_bm;
WritePixelArray8 (array,...,rp,...);
FreeVec (rp);


Du solltest dir mal überlegen, was du eigentlich machen willst und was für deine Aufgabe am sinnvollsten ist. Wenn deine Grafik planar vorliegt und dein Programm von der Logik her planar arbeitet, dann kannst du ruhig auch mit planaren Bitmaps arbeiten. Aber dann mußt du auch dafür sorgen, daß die Bitmaps planar sind. In deinem Beispiel hast du bei AllocBitmap eine Friend-Bitmap angegeben. D.h. die neue Bitmap hat das gleiche Pixelformat, wie die FriendBitmap. Wenn du als Friendbitmap also die Bitmap eines Screens angibst und der Screen auf einer Grafikkarte angezeigt wird, dann ist die Friendbitmap chunky und deine also auch. Deshalb solltest du lieber keine Friendbitmap angeben, dann ist deine Bitmap auf jeden Fall planar.

Natürlich gibt es bei der Umrechnung von planar nach chunky einen kleinen Performanceverlust. Das stecken Systeme mit Grafikkarten allerdings meistens so weg weil sie ja meistens auch einen schnellen Prozessor haben. Ganz anders AGA-only-Systeme mit langsamem Prozessor, die bei der Arbeit mit chunky-Daten (also WritePixelArray8) doch recht langsam sein können.

Wie gesagt, überlege dir, welcher Weg bei dir am häufigsten vorkommt, den du optimieren mußt und welcher Weg seltener vorkommt und deshalb nicht optimiert werden muß.

BltBitMap o.ä. ist schnell, wenn die Quell- und Zielbitmaps gleiches Pixelformat haben und langsam, wenn von Chunky nach Planar oder umgekehrt umgerechnet werden muß.

Das gleiche gilt für WritePixelArray8: wenn die Bitmap planar ist, dauert es lange, wenn sie chunky ist, geht es schnell.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-11-06, 20:56 h

Reth
Posts: 1858
User 		@thomas

Danke für die Hilfe.
Hab inzwischen aus nem anderen Post den Code Deines mask.c gefunden und mich dessen bedient. Bin aber noch dabei.

Ist besser den Rastport für das Bitmapfüllen so anzulegen:

struct rp;
InitRastPort(&rp);

oder so wie Du es hier angegeben hast mit AllocVec?

Das Problem bei der Freigabe hing echt mit der Initialisierung und Erstellung der BitMaps zusammen!
Was mich aber wunderte war, dass es bei immer den gleiche 6 BitMaps funktionierte, bei allen anderen aber nicht!

Es wurden alle auf die selbe Art und Weise angelegt. Die Tiefe ist immer genau 8 und die FriendBitMap bei allen dieselbe! Letztere kam vom Screen, der unter CGX auf ner CVPPC mit Tiefe 8 angelegt wurde!

Drum wundert mich das so.

Dann sollte ich am besten ne Fallunterscheidung einbauen, ob ich AGA oder CGX/Picasso96 bin. Gibts dafür nen Standardcode? (Sieht immer n bisschen so aus wie ne Browserweiche in JavaScript!)

Danke nochmals
Ciao

[ - Answer - Quote - Direct link - ]
2004-11-06, 20:58 h

bubblebobble
Posts: 707
User 		Es gibt eigentlich nur sehr wenige Gründe, warum man auf
Bitmaps "per Hand" rumpoken muss.
Du kannst ruhig eine Friend Bitmap allocieren, aber
dann immer nur mit OS Funktionen drauf zugreifen, die machen
das dann schon richtig. Dazu wirst du aber vermutlich
einen Rastport drauf legen müssen.

Was willst eigentlich auf den Bitmaps machen, evtl. kann ich dir
dann bessere Tipps geben. Zum reinen blitten braucht man keinen Rastport, da BltBitmapRastPort nur für des Ziel (den Screen)
einen Rastport braucht.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2004-11-06, 21:05 h

Reth
Posts: 1858
User 		@bubblebobble

Also ich habe Grafikdaten in UBYTE-Feldern. Diese muss ich in BitMaps bekommen, da ich diese BitMaps dann mittels Masken (die ebenfalls in UBYTE-Feldern liegen und immer einer BitPlane der jew. BitMap entsprechen) auf den Bildschirm bringe mit BltMaskBitMapRastPort().

Wenn Du mehr Infos brauchst, kein Problem!

Ciao

[ - Answer - Quote - Direct link - ]
2004-11-06, 21:11 h

Reth
Posts: 1858
User
Zitat:
Original von thomas:

Du machst es ja auch umgekehrt:

rp = AllocVec (sizeof(struct RastPort),MEMF_CLEAR);
InitRastPort (rp);
rp.BitMap = ziel_bm;
WritePixelArray8 (array,...,rp,...);
FreeVec (rp);

Was nehm ich denn bei WritePixelArray8() als Temporär RastPort her?
Auch nen selbst definierten? Oder kann man in diesem Fall sogar den gleichen nehmen, da die Daten ja eh in der BitMap landen sollen?

[ - Answer - Quote - Direct link - ]
2004-11-06, 21:50 h

Reth
Posts: 1858
User 		Soweit so gut!

Das Freigabeproblem besteht nicht mehr, dafür sehen meine Grafiken nicht mehr so aus wie sie sollen!

Woran kann das denn nun liegen?
Ich erzeuge die BitMaps nun folgendermassen:

void initBitMap(struct BitMap *friendBitMap)
{
struct RastPort rp, rpTemp;
struct BitMap *tempBitMap;

bitMap = AllocBitMap(width, height, SCREENDEPTH, BMF_DISPLAYABLE, friendBitMap);
tempBitMap = AllocBitMap(width, height, SCREENDEPTH, 0, bitMap);

InitRastPort (&rp);
rp.BitMap = bitMap;
rpTemp = rp;
rpTemp.Layer = NULL;
rpTemp.BitMap = tempBitMap;
WritePixelArray8 (&rp, 0, 0,width-1,height-1, data, &rpTemp);

FreeBitMap(tempBitMap);
}

Denke, dass da was noch nicht stimmt oder?

Geblittet wird dann wie folgt:

BltMaskBitMapRastPort(bitMap, 0, 0, rastPort, xPos, yPos, width, height, 0xC0, mask);

Die Mask ist dabei nur die Adresse des UBYTE-Feldes mit den Maskendaten. Der RastPort ist der des verwendeten Fensters, von dem auch die FriendBitMap in obiger Funktion stammt.

Data und Mask sind beide auf den Typ PLANEPTR gecastet und wie so angelegt:

UBYTE data[] =
{
daten,daten,daten... // immer mit der notwendigen Anzahl Bytes pro Zeile
}

UBYTE mask[] =
{
daten,daten,daten... // immer mit der notwendigen Anzahl Bytes pro Zeile aber nur entsprechend einer Bitplane
}

Irgend jemand ne Idee wieso die Grafiken jetzt Müll sind?

[ - Answer - Quote - Direct link - ]
2004-11-06, 22:33 h

whose
Posts: 2156
User
Zitat:
Original von Reth:
Soweit so gut!

Das Freigabeproblem besteht nicht mehr, dafür sehen meine Grafiken nicht mehr so aus wie sie sollen!

Woran kann das denn nun liegen?

...

Irgend jemand ne Idee wieso die Grafiken jetzt Müll sind?

WritePixelArray8() ist denke ich nicht die richtige Funktion, wenn Deine Ausgangsdaten in einem Planar-Format vorliegen und nicht Chunky. Du weißt ja, ich hab bisher nur mit WPA8() gearbeitet, daher weiß ich nicht genau, welche Funktion da besser geeignet wäre, aber ich tippe mal auf WritePixel() und Ähnliche. Vielleicht kann Dir einer der anderen hier mitschreibenden mehr dazu sagen. Ich hab mich gerade an der SDl festgebissen, da bleibt wenig Zeit für anderes ;)

Grüße


[ - Answer - Quote - Direct link - ]
2004-11-07, 14:53 h

Reth
Posts: 1858
User
Zitat:
Original von whose:

WritePixelArray8() ist denke ich nicht die richtige Funktion, wenn Deine Ausgangsdaten in einem Planar-Format vorliegen und nicht Chunky. Du weißt ja, ich hab bisher nur mit WPA8() gearbeitet, daher weiß ich nicht genau, welche Funktion da besser geeignet wäre, aber ich tippe mal auf WritePixel() und Ähnliche. Vielleicht kann Dir einer der anderen hier mitschreibenden mehr dazu sagen. Ich hab mich gerade an der SDl festgebissen, da bleibt wenig Zeit für anderes ;)

Grüße

Danke. Die Idee ist mir gestern nacht auch noch gekommen. Habe meine Grafikdaten von ArtPro als Image-Daten im C-Source speichern lassen. Dadurch sind sie Planar. Da WritePixelArray8() aber die Daten nicht planar interpretiert, probier ich sie mal anders zu speichern (es gibt noch die Interleaved-Funktion).

Oder Weiss jmd. wie ich die Daten richtig als UBYTE-Array bekomme, so dass ich sie in WritePixelArray8() verwenden kann?
Die Grafiken erstelle ich immer mit PPAint und schneide sie mit ArtPro auf die richtige Größe zu.

Bin für jeden Vorschlag dankbar!

[ - Answer - Quote - Direct link - ]
2004-11-07, 15:06 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Irgend jemand ne Idee wieso die Grafiken jetzt Müll sind?
(Mußte korrigieren) Dein Code ist sehr schwer lesbar, wieso initialisiert Du einen RastPort, kopierst ihn danach, um dann in der Kopie die Initialisierung wieder zu überschreiben? Bin selbst nach dem dritten Lesen nicht ganz sichern, ob ich jetzt weiß, was passiert.
tmp-rastport soll auf einen RastPort zum Zwischenspeichern einer Zeile zeigen, Du brauchst keine BitMap mit der kompletten Höhe anzulegen. Aber die ganze Operation dient zum Konvertieren chunky zu planaren Daten, Du legst aber eine friend-BitMap an, die vermutlich nicht planar ist. Und hast planare Daten, also komplett umgekehrt.
Zitat:
Original von Reth:
Oder Weiss jmd. wie ich die Daten richtig als UBYTE-Array bekomme, so dass ich sie in WritePixelArray8() verwenden kann?
Die Grafiken erstelle ich immer mit PPAint und schneide sie mit ArtPro auf die richtige Größe zu.
Wieso sind Deine Grafikdaten dann in UBYTE-Felder? Schreibt PPaint oder ArtPro bevorzugt UBYTE-Felder weg?
Wieso liest Du nicht einfach Bilder ein?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 07.11.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-11-07, 16:31 h

Reth
Posts: 1858
User
Zitat:
Original von Holger:

(Mußte korrigieren) Dein Code ist sehr schwer lesbar, wieso initialisiert Du einen RastPort, kopierst ihn danach, um dann in der Kopie die Initialisierung wieder zu überschreiben? Bin selbst nach dem dritten Lesen nicht ganz sichern, ob ich jetzt weiß, was passiert.
tmp-rastport soll auf einen RastPort zum Zwischenspeichern einer Zeile zeigen, Du brauchst keine BitMap mit der kompletten Höhe anzulegen. Aber die ganze Operation dient zum Konvertieren chunky zu planaren Daten, Du legst aber eine friend-BitMap an, die vermutlich nicht planar ist. Und hast planare Daten, also komplett umgekehrt.

Wieso sind Deine Grafikdaten dann in UBYTE-Felder? Schreibt PPaint oder ArtPro bevorzugt UBYTE-Felder weg?
Wieso liest Du nicht einfach Bilder ein?

Den RastPort initialisiere ich, weil WritePixelArray8() einen temporären RastPort benötigt. Den Code hab ich aus nem Beispiel entnommen. Meiner Meinung nach ist mein einziges Problem derzeit, dass ich planare Daten habe. Wenn ich das irgendwie ändern kann in Chunky, dann sind meine BitMaps endlich richtig initialisiert!
Ich dachte die Prozedur dient dazu BitMaps mit Grafikdaten zu versorgen ohne darauf Rücksicht nehmen zu müssen, welches Format die BitMap hat !?
Die FriendBitMap, die ich bei Allokation der Tempbitmap übergebe ist die BitMap, in der die letztendlichen Grafikdaten landen sollen (ich dachte, dass das nicht schaden könnte). Die FriendBitMap, die bei der Allokation der eigentlichen BitMap mitgegeben wird ist die BitMap des Fensters, in welches geblittet werden soll.

Kannst Du mir denn sagen, wie ich vorgehen soll, damit alles richtig funktioniert?
Als ich wie am Anfang dieses Threads die BitMaps als planar behandelt habe und sie selbst mit Daten pro Bitplane gefüllt habe, hatte ich Probleme mit der Freigabe der BitMaps (drum dieser Thread).

Nun ja, ArtPro schreibt die Daten in UBYTE-Felder und für das Einlesen von Bildern in BitMaps hab ich kein Codebeispiel gefunden und die Sache mit planaren BitMaps und UBYTE-Feldern schien prima zu funktionieren!

[ - Answer - Quote - Direct link - ]
2004-11-07, 16:31 h

thomas
Posts: 7718
User
Zitat:
wieso initialisiert Du einen RastPort, kopierst ihn danach, um dann in der Kopie die Initialisierung wieder zu überschreiben? Bin selbst nach dem dritten Lesen nicht ganz sichern, ob ich jetzt weiß, was passiert.

:D

WritePixelArray8 braucht zwei RastPorts. Einen, auf dem gearbeitet wird und einen für temporäre Daten.

InitRastPort(&rp);
rp.BitMap = bitmap;

etabliert den ersten RastPort und

temprp = rp;
temprp.Layer = NULL;
temprp.BitMap = AllocBitMap(width,1,depth,0,NULL);

ist wortwörtlich aus den Autodocs für Read/WritePixelArray8 abgeschrieben.

Daß es in diesem Fall, wo der erste Rastport nur rudimentär initialisiert wurde, nicht unbedingt notwendig ist, Layer zu löschen, tut der Funktion keinen Abbruch.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ Dieser Beitrag wurde von thomas am 07.11.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-11-07, 16:51 h

Reth
Posts: 1858
User
Zitat:
Original von thomas:

WritePixelArray8 braucht zwei RastPorts. Einen, auf dem gearbeitet wird und einen für temporäre Daten.

InitRastPort(&rp);
rp.BitMap = bitmap;

etabliert den ersten RastPort und

temprp = rp;
rp.Layer = NULL;
rp.BitMap = AllocBitMap(width,1,depth,0,NULL);

ist wortwörtlich aus den Autodocs für Read/WritePixelArray8 abgeschrieben.

Daß es in diesem Fall, wo der erste Rastport nur rudimentär initialisiert wurde, nicht unbedingt notwendig ist, Layer zu löschen, tut der Funktion keinen Abbruch.

Hab ich das jetzt falsch verstanden, oder ist das nun hier ein Tippfehler:

Zitat:
temprp = rp;
rp.Layer = NULL;
rp.BitMap = AllocBitMap(width,1,depth,0,NULL);

Wird nun bei dem temprp der Layer auf NULL gesetzt und die einzeilige BitMap zugewiesen oder wie hier dem eigentlichen RastPort, ich denke eher beim temprp, oder?

Ciao

[ Dieser Beitrag wurde von Reth am 07.11.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-11-07, 17:06 h

thomas
Posts: 7718
User
Zitat:
Wird nun bei dem temprp der Layer auf NULL gesetzt und die einzeilige BitMap zugewiesen oder wie hier dem eigentlichen RastPort, ich denke eher beim temprp, oder?

Flüchtigkeitsfehler. Korrigiert.

Gruß Thomas


--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Answer - Quote - Direct link - ]
2004-11-07, 17:13 h

whose
Posts: 2156
User
Zitat:
Original von Reth:

Hab ich das jetzt falsch verstanden, oder ist das nun hier ein Tippfehler:

Zitat:
temprp = rp;
rp.Layer = NULL;
rp.BitMap = AllocBitMap(width,1,depth,0,NULL);

Wird nun bei dem temprp der Layer auf NULL gesetzt und die einzeilige BitMap zugewiesen oder wie hier dem eigentlichen RastPort, ich denke eher beim temprp, oder?

Also, wie ich Dir schon per Mail schrieb, kannst Du den RastPort als eine Art "Seitenbeschreibung" verstehen. Darin findest Du Information über z.B. Größe der Bitmap, wo diese sich befindet, Layer, Stiftfarben etc. pp.

Die Bitmap als solche ist nicht im RastPort enthalten sondern nur ein Zeiger darauf. Genau das passiert in obigem Beispiel. Die Layer-Information im temrp-Rastport wird auf Null gesetzt und per AllocBitMap() ein Zeiger auf eine allozierte und initialisierte Bitmap in temprp eingetragen. Nicht mehr und nicht weniger.

thomas kam mir etwas zuvor, der RastPort heißt eben temprp. Nur eine Frage dazu: Warum eine Zeigerkopie??

Streng genommen könntest Du jetzt per WritePixel() und ähnlichen Funktionen, die einen RastPort als Parameter erwarten, in temprp hineinmalen. Das macht allerdings nicht viel Sinn bei einer einen Pixel hohen Bitmap ;)

Normalerweise benutzt man dieses Konstrukt für die temporäre Bitmap, mit der WritePixelArray8() bei der Chunky-zu-Planar-Konversion arbeitet. Die temporäre Bitmap braucht nämlich nur ein Pixel hoch zu sein und benötigt natürlich auch keinen Layer, es wird ja nichts wirklich dargestellt ;)

Grüße


P.S.: Hat jemand ein funktionierendes makefile für die SDL-1.2.7? Mit Amiga-Bordmitteln kommt man da nicht wirklich weiter und Linux kommt mir nicht mehr auf den PC, den Platz auf der Platte beansprucht Amithlon für sich ;)


[ Dieser Beitrag wurde von whose am 07.11.2004 editiert. ]

[ - Answer - Quote - Direct link - ]
2004-11-07, 17:31 h

Reth
Posts: 1858
User
Zitat:
Original von whose:

Also, wie ich Dir schon per Mail schrieb, kannst Du den RastPort als eine Art "Seitenbeschreibung" verstehen. Darin findest Du Information über z.B. Größe der Bitmap, wo diese sich befindet, Layer, Stiftfarben etc. pp.

Die Bitmap als solche ist nicht im RastPort enthalten sondern nur ein Zeiger darauf. Genau das passiert in obigem Beispiel. Die Layer-Information im temrp-Rastport wird auf Null gesetzt und per AllocBitMap() ein Zeiger auf eine allozierte und initialisierte Bitmap in temprp eingetragen. Nicht mehr und nicht weniger.

...

Streng genommen könntest Du jetzt per WritePixel() und ähnlichen Funktionen, die einen RastPort als Parameter erwarten, in temprp hineinmalen. Das macht allerdings nicht viel Sinn bei einer einen Pixel hohen Bitmap ;)

Normalerweise benutzt man dieses Konstrukt für die temporäre Bitmap, mit der WritePixelArray8() bei der Chunky-zu-Planar-Konversion arbeitet. Die temporäre Bitmap braucht nämlich nur ein Pixel hoch zu sein und benötigt natürlich auch keinen Layer, es wird ja nichts wirklich dargestellt ;)

Das ist schon klar. Es ging rein um den Codeausschnitt. In dem hatte Thomas versehentlich den eigentlichen RastPort mit dem TempRastPort verwechselt. Nur darum gings, damit niemand ein falsches Bsp. übernimmt.

Jetzt muss ich nur noch sehen, wie ich meine Grafikdaten ins Chunkyformat bekomme bzw. anders in die BitMap.

Ciao


[ - Answer - Quote - Direct link - ]
2004-11-07, 17:45 h

whose
Posts: 2156
User 		Ich denke mal, der simpelste Weg ist, die Daten als RAW zu speichern,
PPaint hat (glaube ich) einen passenden Operator, der die Daten auch
gleich im Chunky-Format schreibt.

Ansonsten mal die Konverter-Tools im Aminet ansehen, da war glaube
ich auch was von wegen IFF2Chunky oder so drin.

Wenn alles nichts hilft, lade die Bilddaten mittels Datatype und
schreibe die selbst wieder im Chunky-Format als Sourcecode auf Platte.
Ist zwar aufwändig, aber wenns nu gar nicht anders geht...

Ersatzweise könnte man auch die Bilddaten per Datatype direkt in eine
Bitmap schreiben lassen. Im Moment habe ich aber noch nicht so die
Ahnung, ob das auch mit Offscreen-Bitmaps geht. Technisch sollte das
machbar sein. Bei mir klappts zumindest, wenn ich direkt in einen
Screen rendern lasse, dank Thomas Hilfe sogar mit den korrekten Farben
;) Wenn Du willst, kann ich Dir den Code mal zukommen lassen.

Grüße


[ - Answer - Quote - Direct link - ]
2004-11-07, 17:50 h

Reth
Posts: 1858
User
Zitat:
Original von whose:
Ich denke mal, der simpelste Weg ist, die Daten als RAW zu speichern,
PPaint hat (glaube ich) einen passenden Operator, der die Daten auch
gleich im Chunky-Format schreibt.

Ansonsten mal die Konverter-Tools im Aminet ansehen, da war glaube
ich auch was von wegen IFF2Chunky oder so drin.

Danke gute Idee!

Zitat:
Wenn alles nichts hilft, lade die Bilddaten mittels Datatype und
schreibe die selbst wieder im Chunky-Format als Sourcecode auf Platte.
Ist zwar aufwändig, aber wenns nu gar nicht anders geht...

Ersatzweise könnte man auch die Bilddaten per Datatype direkt in eine
Bitmap schreiben lassen. Im Moment habe ich aber noch nicht so die
Ahnung, ob das auch mit Offscreen-Bitmaps geht. Technisch sollte das
machbar sein. Bei mir klappts zumindest, wenn ich direkt in einen
Screen rendern lasse, dank Thomas Hilfe sogar mit den korrekten Farben
;) Wenn Du willst, kann ich Dir den Code mal zukommen lassen.

Klaro! Immer her damit, bin für jedes Beispiel dankbar!

Auch noch mal Dank an alle andern hier, die mit geholfen haben und mit Beispielen viel zum Fortschritt beigetragen haben, z.T. auch aus anderen Threads (danke Thomas ;) )

Ciao

[ - Answer - Quote - Direct link - ]
2004-11-07, 18:02 h

whose
Posts: 2156
User 		Du hast Post ;)


Grüße

[ - Answer - Quote - Direct link - ]
2004-11-08, 13:12 h

Reth
Posts: 1858
User
Zitat:
Original von Reth:
Nun ja, ArtPro schreibt die Daten in UBYTE-Felder und für das Einlesen von Bildern in BitMaps hab ich kein Codebeispiel gefunden und die Sache mit planaren BitMaps und UBYTE-Feldern schien prima zu funktionieren!

Muss mich korrigieren, bei ArtPro kann man angeben, ob man Byte-, Word- oder Longdaten haben will (also 8Bit, 16Bit oder 32Bit).

Leider hab ich in ArtPro noch keine Möglichkeit gefunden die Daten im Chunkyformat zu speichern, werd aber mal den Konverter ausm Aminet probieren oder andere Funktionen zum Beschreiben der BitMap.

[ - Answer - Quote - Direct link - ]
2004-11-08, 21:06 h

Reth
Posts: 1858
User 		Jetzt versteh ich gar nix mehr!

Habe mir die Daten von ArtPro nun im Chunkyformat (UBYTES) speichern lassen und mittels WritePixelArray8() in die BitMap geschriebe.
Lediglich die Maske ist noch im planaran Format gespeichert was aber nichts machen sollte, da es eh nur eine BitPlane ist!

Woran kann denn das nun noch liegen, dass die Grafiken falsch angezeigt werden? Hab in ArtPro Right als Byte Type angegeben.

Oder brauch ich bei Chunkydaten ne andere Anzahl Bytes per Row als im planaren Fall?

Schreibt WritePixelArray8() die Daten immer richtig in die BitMap, egal ob diese im Chunky oder Planar Format vorliegt?

Oder muss ich den temporären RastPort noch irgendwie anders initialisieren?

[ Dieser Beitrag wurde von Reth am 08.11.2004 editiert. ]

[ - Answer - Quote - Direct link - ]

-1- 2 3 [ - Post reply - ]


amiga-news.de Forum > Programmierung > Privilegverletzung bei FreeBitMap() [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.