|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Privilegverletzung bei FreeBitMap() | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 2 -3- | [ - Beitrag schreiben - ] |
|
11.11.2004, 18:12 Uhr bubblebobble Posts: 707 Nutzer |
Also ich habe mir das Beispielbild angesehen. Es stimmt definitiv die Bytes Per Row Angabe nicht mit dem Bild überein, das sieht man sofort and den schrägen Verläufen. Da die Farben stimmen, ist es definitiv kein Problem mit Chunky vs. Planar, dann hättest du nämlich kompletten Salat. Das rosa am Ende sieht aus, als wenn du über die Bitmap hinausliesst, d.h. Die Bytes-Per-Row die der WPA annimmt sind höher als das Bild. Das mit den 16 bytes halte ich für ein Gerücht. Seit ihr euch da sicher ? Verwechselt ihr das nicht mit den 16 Pixel breiten Chipmem Bildern ? Damals war das so, dass die Bilder immer in 16 Pixel schritten breit sein durften, das ist ja auch klar weil ja ein Byte 8 pixel in der horizontalen darstellt. Der Blitter arbeitet mit 16bit, also kann er nur Bilder der Breite 16 verarbeiten. Alles andere wäre ja sinnlos, dann müsste man bytes mittendrin abschneiden. Bei Chunky Grafiken ist das doch aber völlig anders. Ich sehe keinen Grund warum es ein 16 Pixel Limit hier gibt. Ich habe auf sowas noch nie Rücksicht genommen und alles funtkioniert. Aber ich habe auch noch nie mit WPA8 gearbeitet. Ich empfehle dir, nutze Datatypes oder die guigfx.library. Alles andere ist doch Rumgemurkse, was wenn du es einmal am Laufen hast spätestens beim nächsten Update von AOS4 nicht mehr funktionert. (<-Scherz). Alle Befehle die als Ziel einen Rastport haben, werden auch automatisch geclipped, soweit ich weis. Alle, die eine Bitmap oder was anderes haben clippen natürlich nicht. Die Layers sind mit dem RastPort verbunden. Das kannst du dir ja auch zu nutze machen, wenn du z.B. eine Status anzeige hast und die nicht übermalen willst. Dann kannst du mit InstallClipRegion() den Layer temporär verändern, Blitten und wieder rückgängig machen. So ersarst du dir mühsames Clippen von hand, und schneller dürfte es auch sein. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
11.11.2004, 18:48 Uhr Reth Posts: 1858 Nutzer |
Hi bubblebobble (das Spiel muss es Dir mächtig angetan haben!  )Danke für Deine Antwort! Zitat: Aber ich gebe doch nirgendwo die Bytes per Row an, nur die Dimensionen und die Tiefe. D.h. die Bytes Per Row ermittelt er bei Bedarf selbst! Vielleicht hängt das ja mit der FriendBitMap bei der temporären BitMap zusammen? Hast Du Dir das Array mal angesehen? Da stehen genau so viele Bytes wie Pixel drinne und dennoch klappts mit WPA8() nicht aber mit WriteChunkyPixels() Zitat: Ist die Library den AOS Standard wie die Graphics Library? Mein Ziel ist es nämlich nur AOS komponenten zu nehmen, damit das Programm auf so vielen Konfigurationen wie nur möglich läuft, drum auch möglichst keine Datatypes. Das es momentan unter AOS4 tut ist eher Zufall. Da ich auch Betatester bin, will ich es später sowieso anpassen und dabei auf GCC umstellen. Zitat: Hast Du mir dazu zufällig ein Codebeispiel? Wäre toll, das könnte ich bestimmt mal gut brauchen, denn meine Statusanzeige wird noch erweitert! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
11.11.2004, 19:27 Uhr thomas Posts: 7718 Nutzer |
Zitat: Den Array braucht man sich gar nicht anzusehen. Du schreibst, daß folgendes funktioniert: Zitat: D.h. dein Array hat pro Zeile 100 Bytes. Für WPA8 muß die Anzahl Bytes pro Zeile aber durch 16 teilbar sein, das haben wir lang und breit durchgekaut. D.h. wenn du es schaffst, daß WriteChunkyPixels (&rp, 0, 0, 99, 79, data, 112); funktioniert, dann wird auch WritePixelArray8 funktionieren. Sprich, du mußt in deinem Array an jede Zeile 12 Null-Bytes anhängen. Gruß Thomas -- Email: thomas-rapp@web.de Home: home.t-online.de/home/thomas-rapp/ [ - Antworten - Zitieren - Direktlink - ] |
|
11.11.2004, 19:47 Uhr Reth Posts: 1858 Nutzer |
Zitat: Hab ja auch nie was anderes behauptet! Hab mich aber in dem Post mit dem  gewundert warum WPA8() immer noch nicht geht! Dort hab ich das Bild extra 112 Pixel breit genommen!Heut hab ich die Lösung des Problems gefunden! Ich darf bei der temporären BitMap keine FriendBitMap angegen und schon gehts! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
13.11.2004, 22:36 Uhr bubblebobble Posts: 707 Nutzer |
Das geht nur zufällig, wahrscheinlich weil die Bitmap ohne Friend Screen ein anderes Pixelformat hat. Was du da hast ist kein zuverlässiger Code. Anderes System, andere Graka und *?#! es geht nicht mehr, wenn es alleine an der angabe von Friendbitmap liegt. Datatypes ist sicher ein bestandteil von AOS4. GuiGfx.library ist KEIN bestandteil, aber es funktioniert überall, ich glaube es gibt sogar native versionen. also Datypes ist sicher die erste Wahl, wenn man auf die Zusatzfunktionalität der guigfx.lib verzichten kann. Die RAW Datei enthält keinerlei informationen, wie die Dimensionen des Bildes sind. Es enthält nur die Pixel. Also alle angaben wie Länge, höhe, Farbtiefe, Pixelformat muss du irgendwo einfliessen lassen. Also wenns nicht unbedingt RAW sein muss, dann nimmt Datatypes, du wirst es nicht bereuhen. Wenn es denn unbedingt RAW Data sein muss, dann musst du halt rumwurschteln, unsauber wirds auf jeden Fall. Aber trotzdem nun der Rat, wenn du das direkt machen willst: 1. Locke die Bitmap 2. Ermittle das Pixelformat 3. Wenn das Pixelformat stimmt, dann schiebe die Daten in die Bitmap 4. Unlocke die Bitmap Wenn das Pixelformat unbekannt ist, dann sollte das Program abbrechen. Das locken der Bitmap ist verdammt WICHTIG. Sonst kann dein Programm jederzeit crashen. AmigaOS erlaubt sich die Bitmap zu verändern, z.B. wenn kein Graka RAM mehr frei ist dann kann deine "Friend" Bitmap ins normale RAM verschoben werden. Dadruch ändert sich der Basepointer auf die Bitmapdaten, soagr das Pixelformat könnte sich ändern. Deshalb, wenn du auf eine Bitmap direkt zugreifst, IMMER locken, und nur während dem lock drauf zugreifen. Das Pixelformat sollte unbedingt überprüft werden. Wenn es nicht stimmt, macht es kein sinn die Daten reinzukopieren, dann gibts müll oder sogar Memtrash, wenn das Pixelformat weniger Speicher braucht. Die Bytes-per-row sind bei dir das gleiche wie die Breite des Bildes. Ich empfehle dir MovePixelArray() aus der cgfx.lib oder sowas, musst gucken welcher Befehl am besten zum rüberschieben ist. Irgendwie drehen wir uns hier im Kreis. Was ich oben geschrieben habe musst du beachten, sonst klappt das nicht. Glaube mir einfach, ich habe z.B. AsteroidsTR geschrieben, da siehst du dass ich mich damit bereits auseinandergesetzt habe und dass ich es geschafft habe dass es läuft. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.11.2004, 22:38 Uhr bubblebobble Posts: 707 Nutzer |
Achso, zum schieben der Pixel in die Bitmap kannst du genauso gut copymem() nehmen, wenn du weiss was du da machst. Da kannst du dir wenigstes sicher sein, dass die Daten 1:1 rüberkopiert werden. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.11.2004, 23:27 Uhr Reth Posts: 1858 Nutzer |
@bubblebobble Danke nochmals für die Hinweise, die sind schon sehr einleuchtend. Aber kannst Du mir erklären (damit ichs auch verstehe, warums so ist), wieso die von mir angewandte vorgehensweise nicht funktioniert? Ich erstelle die Bilddaten und speichere sie im Chunkyformat ab. Danach allokiere ich eine BitMap in der Höhe und Breite des Bildes und in 8Bit Tiefe (alle diese Werte sind mir bekannt!). Als FriendBitMap gebe ich hier die BitMap des Fensters an,in welches ich später blitten möchte, da ich denke, dass das eher hilft als schadet. Danach initialisiere ich einen RastPort, weise ihm die soeben allozierte BitMap zu und schreibe das Datenarry mit WriteChunkyPixel() in den Rastport. An keiner Stelle mache ich doch da Annahmen über die BitMap oder? Das einzige, was ich noch nicht tue ist die BitMap zu sperren, aber WriteChunkyPixel() arbeitet auf dem RastPort, keine Ahnung, ob das nicht schon ne Sperrung vornimmt? Ab dem Zeitpunkt wird die BitMap nur noch geblittet und nicht mehr verändert. Wo liegt denn da genau mein Problem. Ich sehe zumindest nicht, wo ich Annahmen über die BitMap treffe möchte aber alle Fehler ausschließen! Ich dachte mit diesem Weg erledigen die Systemfunktionen alle evtl. notwendigen Anpassungen? Das entnahm ich jedenfalls den Posts der anderen! Irgendwie scheinen sich hier einige Antworten zu widersprechen oder ich blicks nicht ganz?!? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
13.11.2004, 23:30 Uhr thomas Posts: 7718 Nutzer |
@Thilo: also dein Verständnis von "sauber" ist ziemlich daneben. BitMap "locken" (du meinst sprerren) ist schonmal per se unsauber, weil alles, was sperrt, unsauber ist. Noch dazu ist auch das *kein* Teil von AmigaOS, sondern von CyberGraphics bzw. Picasso96. Das was Reth da macht, ist schon die sauberste Methode. 8bit chunky Pixel mit WritePixelArray8 oder WriteChunkyPixels in eine mit AllocBitMap angelegte Bitmap zu schreiben ist eine zulässige, saubere und mit allen existierenden Amiga-Plattformen (Classic/Emulator, OS4, MorphOS) kompatible Prozedur. Um Pixelformate braucht man sich hier keine Gedanken zu machen, das macht AmigaOS bzw. CGX/P96. Und es ist vollkommen Multitaskingkonform. Die Sache mit LockBitmap ist nicht nur unsauber, sondern auch viel zu umständlich, aufwendig und fehleranfällig. Wie du selbst schreibst, muß jedes mögliche Pixelformat berücksichtigt werden. Andere Grafikkarte, anderes Pixelformat. Da der Autor üblicherweise nur eine Grafikkarte mit einem begrenzten Satz an Pixelformaten hat, gehen die meisten Pixelformate entweder unberücksichtigt oder zumindest ungetestet unter die Leute. Und wie war das ? *?#! es geht nicht mehr, genau. Lieber ein von AmigaOS vorgegebenes, definiertes Pixelformat (8bit chunky) benutzen und mit vorhandenen Funktionen in eine Bitmap bringen, das funktioniert überall. Und AutoDocs lesen. Da steht nämlich (implizit), daß man für die TempBitmap bei WritePixelArray8 keine FriendBitmap angeben soll. Da steht nämlich, man soll die Bitmap auf alte Weise anlegen, indem man nur den Speicher in der richtigen Größe reserviert und die Felder der struct BitMap selbst befüllt. Gruß Thomas -- Email: thomas-rapp@web.de Home: home.t-online.de/home/thomas-rapp/ [ - Antworten - Zitieren - Direktlink - ] |
|
14.11.2004, 00:58 Uhr whose Posts: 2156 Nutzer |
Zitat: *hust* Naja, in manchen Fällen ist Locking durchaus als "saubere" Methode anzusehen. Selbst LockBitMap() ist per se keine "unsaubere" Sache. Wenn man (ich betone: WENN!) sich genötigt sieht, in eine Bitmap höchstselbst hinein zu schreiben (warum auch immer) _muß_ man dafür sorgen, daß einem kein anderer Prozess dazwischenfunkt. Dafür ist das Locking ausdrücklich gedacht. Wie willst Du sonst verhindern, daß z.B. der Picasso-VMem-Task die Bitmap, in die Du gerade hinein schreiben willst, einfach ins FastRAM verschiebt, weil ein weiterer Prozess in diesem Moment das RAM der GraKa fast komplett in Beschlag nehmen will? Für solche Fälle ist das Locking da und es ist auch die einzig saubere Methode, um mit diesen Problemen umgehen zu können. Das es in diesem hier vorliegenden Fall keine besonders kluge Vorgehensweise ist, alles "von Hand" zu erledigen, steht auf einem anderen Blatt. Reth hats ja nun auf die Weise hinbekommen, wie man es eben machen sollte. Ich war ein paar Tage aus dem Rennen, sonst hätte ich ihm schon längst die Sache mit der FriendBitMap ausgetrieben  Im Grunde hast Du aber vollkommen Recht: Nutze die Möglichkeiten, die Dir das OS bietet und bastel nicht selbst, wenn Du gar nicht mußt. WPA8() wird von P96/CGX nämlich auch gepatcht und eben in dieser Funktion wird, na, was? LockBitMap() aufgerufen, um eine Verschiebung der Bitmap während der Übertragung der Daten zu verhindern. Jedes Mal, wenn ein Schwung Daten (eben die temp. Bitmap in der empfohlenen Größe) übertragen wird, wird die Bitmap für diese Zeit gelockt. Irgendwo habt ihr aber auch beide Recht, Thilo und Du. Er hats halt selbst gemacht (weil er auf die "Experten" in Sachen WPA8() hereingefallen ist. "Die ist vieeeel zu lahm!". Absoluter Schwachsinn. Auf P96/CGX wird auch nichts anderes als CopyMem() verwendet, wenn das BitMap-Format paßt. Was ist daran lahmer, als CopyMem() selbst aufzurufen? Hab ich aber auch erst kürzlich herausgefunden...), Du machst es ähnlich wie er, nur über die dafür vorgesehenen OS-Funktionen. Und hast weniger Arbeit und Ärger Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
14.11.2004, 02:18 Uhr Reth Posts: 1858 Nutzer |
Also wenn meine Vorgehensweise korrekt ist, wieso funktioniert dann der Algorithmus mit WriteChunkyPixels() bei meinen 100x80 Bildern, aber nicht bei meine 23x46 Bildern? Wenn ich bei letzteren die BytesPerRow mit 24 angeb (was ja eigentlich falsch ist), dann sehens sie fast normal aus, ansonsten verschoben wie in dem Beispielbild! Hab für WriteChunkyPixels() aber keinerlei Einschränkungen in den Docs gefunden!  Soeben hab ich festgestellt, dass unter DblPalHires Flimmerfrei nicht einmal die 100x80 Bilder stimmen! Was ist denn da los? Sind die Systemfunktionen denn zu gar nix mehr zu gebrauchen?  Ciao [ Dieser Beitrag wurde von Reth am 14.11.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.11.2004, 03:37 Uhr whose Posts: 2156 Nutzer |
Zitat: Ich mach Dir mal nen Vorschlag: Schick mir doch bitte mal ein kurzes Programm, daß mit Deiner Vorgehensweise funktioniert und mit Bitmaps der oben genannten Maße versehen ist (also im Sourcecode enthalten). Kannst ja aus Deinem Programm eben was rauskopieren und zusammensetzen, das es so eben gerade tut. Das Ganze wie gesagt im Source. So langsam kapiere ich nämlich nicht mehr, was _genau_ Du machst und _wie_ Du es machst. Ich hab mir hier mal den Spaß gegönnt und x-beliebige Bitmaps per Datatype laden und dann direkt mit WritePixelArray8() auf den Screen pinseln lassen. Egal, welchen Screenmode ich nehme, egal, welche Dimensionen die Bilder haben, es funktioniert immer bestens. So langsam habe ich das Gefühl, daß irgendwas in Deinem Programm nicht so ganz korrekt läuft. Ich hab nur keine Vorstellung, was das sein könnte. Daher der Wunsch nach einem kurzen Demo-Programm, wo genau das beschriebene Phänomen auftritt. Grüße [ Dieser Beitrag wurde von whose am 14.11.2004 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.11.2004, 03:57 Uhr whose Posts: 2156 Nutzer |
Bevor ich das aus den Augen verliere: Du hast aber schon daran gedacht, daß die Beschränkungen für die Dimensionen bei WritePixelArray8() ebenso für die Ziel-Bitmap gelten? Also durch 16 teilbar in der Breite? Wäre gut möglich, daß WriteChunkyPixels() auch unter dieser "Krankheit" leidet. Ich weiß es leider nicht genau, weil ich diese Funktion nie verwendet habe. Das etwas in den Docs nicht steht heißt ja nicht, daß es nicht existiert Schick mir aber trotzdem bitte mal das Demo-Programm, mich interessiert dieses Problem inzwischen brennend! Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
14.11.2004, 12:37 Uhr Reth Posts: 1858 Nutzer |
@whose Danke für Dein Angebot, der Code mit Daten ist schon raus! @All Glaube das Problem gelöst zu haben! WriteChunkyPixel() braucht wohl ein Datenfeld, dessen gesamte Byteanzahl ein Vielfaches von 16 oder auch nur von 8 (letzteres hab ich nicht extra getestet) sein muss! Dann klappts auch unter DblPalHires Flimmerfrei! Bin drauf gekommen, als ich mir die Byteanzahl des größeren Bildes angeschaut hab (und nachdem was whose oben schon anführte): 100x80=8000 Vielfaches von 8 und 16 23x46=1058 Kein Vielfaches von 8 und auch nicht von 16 Habe dann das kleinere Bild auf 24x46 erweitert (=1104 Vielfaches von 8 und 16!) und schon ging es! Steht leider bei keiner der Dokumentationen, die ich zu WriteChunkyPixel() hab! Danke nochmal an alle! Hoffe, dass ich zu dem Thread keine neuen Probleme mehr schreiben muss! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
14.11.2004, 16:50 Uhr whose Posts: 2156 Nutzer |
Nein, ich denke, Du mußt nicht mehr wegen Deiner Probleme posten. Ein bißchen Nachzählen in dem mit dem Konverter erzeugten Array hat mich auf die Spur gebracht. Der Übeltäter ist eindeutig der Konverter. Wenn Du mal die Bytes nachzählst und mit dem Bild vergleichst, wirst Du den Fehler in der zweiten Bildzeile finden. Dort ist auf einmal ein Null-Byte zu viel im Array drin, in jeder folgenden Zeile ebenfalls. Ich hab das Array mal von Hand korrigiert und dabei festgestellt, daß der Konverter ein paar Bytes des Bildes zu Gunsten der Null-Bytes unterschlägt. WriteChunkyPixels() ist also nicht der Schuldige Ich schicke Dir mal das korrigierte Array zu, dann kannst Du vergleichen. Sieht so aus, als käme der Konverter nicht so gut mit ungeraden Pixelzahlen klar. Grüße [ - Antworten - Zitieren - Direktlink - ] |
| 1 2 -3- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Privilegverletzung bei FreeBitMap() | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|