amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Bitmaps nur durch 16 teilbare Breite? [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 5 6 [ - Beitrag schreiben - ]

01.09.2006, 18:49 Uhr

bubblebobble
Posts: 707
Nutzer
@Holger
> Eben noch hast Du geschrieben, dass Deine Shadow-BitMap im
> Screenformat vorliegt, was ja auch logisch ist, wenn Du sie
> möglichst schnell auf den richtigen Screen blitten willst.
> Jetzt bekommst Du die Möglichkeit, mit den OS-Zeichenfunktionen
> drauf rumzumalen, aber jetzt bist Du schon wieder nicht zufrieden.
In die Shadow Bitmap kann ich natürlich hineinmalen, aber das bringt mir ja nichts. Die Shadowbitmap hat ein beliebiges Pixelformat, und reduziert u.U. die Qualität des Bildes (16bit, Farb-Indiziert). Und zum Speichern in 24bit müssste ich wieder zurückmappen.
Deshalb halte ich mir ja ein Full-Blown ARGB Abbild. Und darauf muss ich zeichnen können.

> Es gibt keine ideale Lösung. Schon gar nicht, wenn man die
> Problemstellung alle Nase lang umdefiniert.
Mein Ziel war immer das gleiche. Nur habe ich während des Threads unterschiedliche Ideen entwickelt, wie man es lösen kann, und am Anfang nur ein Teilproblem geschildert.

> Tja, bringt Dir halt nix, weil dann ja sowieso keine OS-Funktionen funktionieren
Nicht ganz. BltBmapRasport oder FillPixelArray z.B. funktioniert. Aber du hast recht wirklich lohnen tut sich das nicht. Evtl. bleib ich eben doch bei meinem PixelArray, dann spare ich mir den Remapping Code und kann das via guigfx machen, wobei es mir schon gefallen würde guigfx los zu werden.





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


[ - Antworten - Zitieren - Direktlink - ]

02.09.2006, 00:07 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von bubblebobble:
Ja, mit dem AfA Datatype bekommt man den Alphachannel, aber das RGB Bild ist trotzdem nicht mehr das original, sondern mit dem Alphachannel und der Hintergrundfarbe verrechnet.


Wenn du die Draw Methode benutzt dann kann dass schon sein, aber GETPIXELARRAY gibt mir definitiv ARGB zurück.


[ - Antworten - Zitieren - Direktlink - ]

03.09.2006, 09:49 Uhr

bubblebobble
Posts: 707
Nutzer
Das ARGB Array lese ich natürlich aus, ist aber auch vergewaltigt.

Beispiel:
Das ist das eigentliche Bild:
Bild: http://www.hd-rec.de/pics/Wanderer_NoAlpha.png

Auf das Bild lege ich jetzt diese Alphamaske:
Bild: http://www.hd-rec.de/pics/Wanderer_AlphaMask.png

Das Ergebis, wenn ich mit akpng Datatype lese, sieht so aus:
(keine Garantie wie das jetzt in eurem Browser aussieht.
Schaut es aber mal mit akpng Datatype an, dann ist der
Hintergrund komplett schwarz (im MS Explorer übrigends auch).
Auch in dem ARGB Array ist das so.
Bild: http://www.hd-rec.de/pics/Wanderer_WithAlpha.png

Für ein Zeichenprogramm ist das natürlich nicht akzeptabel.
Zum Beweis dass das Bild eigentlich noch alle Daten enthält,
könnt ihr das Bild auch mal z.B. in Arteffects reinladen,
dann seht ihr dass der Hintergrund noch da ist.

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



[ Dieser Beitrag wurde von bubblebobble am 03.09.2006 um 09:50 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

03.09.2006, 13:44 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Schicke mir mal das Bild, ich möchte das mal anschauen.

[ - Antworten - Zitieren - Direktlink - ]

03.09.2006, 13:45 Uhr

bubblebobble
Posts: 707
Nutzer
Speichere es doch einfach im Bowser ;-)

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


[ - Antworten - Zitieren - Direktlink - ]

03.09.2006, 14:10 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Hast Recht, da das Bild aber keine eigene Maske enthält muß aber was anderes Falsch sein, denn ohne eigene Maske wird kein Datatype irgendwas am Bild machen. Zumindestens ist das Bild (das Originale) bei mir so in Ordnung obwohl ich mit akPNG lese, ich nutze mein picture.datatype von AROS, hab's aber nicht mit AfA ausprobiert.

Wenn die von dir gegebene Maske darauf angewendet wird, dann kann kein Resultat herevorkommen wie ich es hier sehe (Gesicht ausmaskiert).

Wie hast du überhaupt die Alpha-Maske angewendet, die ist 24BIT und nicht 8BIT.

[ Dieser Beitrag wurde von DariusBrewka am 03.09.2006 um 14:15 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

03.09.2006, 15:17 Uhr

bubblebobble
Posts: 707
Nutzer
Also ...

Das 1. Bild ist ein RGB .png Bild und wird imme richtig dargestellt, ohne Alpha Maske eben, als Referenz.

Das 2. Bild ist nur da, um euch die Alphamaske zu zeigen, die im 3. Bild drin ist.
(Die stimmt alledings nicht ganz, das Gesicht ist beim Ausschneiden auch transparent geworden, aber das ist nur ein Unfall in Arteffects, weil es machmal Probleme beim Abspeichern von png hat. Das ist aber unwichtig um den Effekt hier zu demonstieren).

Das 3. Bild ist ein ARGB .png Bild, das genauso aussieht wie das RGB Bild, aber zusätzlich einen Alphakanal drin hat, so in etwa wie im S/W Bild zu sehen und als Hintergrundfarben Definition Schwarz.

Wenn ich das 3. Bild via Datatype asl ARG Pixelarray lade, ist der Hintergrund (also was im Alpha Kanal "durchsichtig" ist) komplett schwarz gefärbt und dadurch zerstört.
Lade ich es z.B. in Arteffects, sehe ich den Hintergrund + Alphakanal korrekt.
Das Datatype ist also einfach zu "intelligent", und verrechnet den Alphakanal sofort mit der Hintergrundfarbe, obwohl es für meine Zwecke das ARGB Bild einfach 1:1 herausgeben sollte.

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



[ Dieser Beitrag wurde von bubblebobble am 03.09.2006 um 15:18 Uhr geändert. ]

[ Dieser Beitrag wurde von bubblebobble am 03.09.2006 um 15:20 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

03.09.2006, 16:06 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Also bei mir wird das Korrekt geladen, wenn ich die Maske einrechne zum Anzeigen, dann ist der Hintergrund Transparent, wenn ich nur die RGB ohne A darstelle, dann ist der Hintergrund auch korrekt und nicht schwarz. Ich denke mal dass das ein Problem in AfA ist, weil die Standard Grafik-Funktionen keine Aplha-Masken unterstützen und Bernd dieses aus Rückwärtskompatiblitätsgründen so gemacht hat.

Wie gesagt ich nutze das AfA Datatype nicht, meines hat die Korrektur aber nicht und wird mit anderen Programmen Probleme haben, nichtsdestotrotz kann ich dir Meines mal senden wenn du mir ne e-mail schickst.

Am ak Datatype wird das nicht liegen sondern am picture.datatype.

[ Dieser Beitrag wurde von DariusBrewka am 03.09.2006 um 16:07 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

03.09.2006, 20:20 Uhr

Georg
Posts: 107
Nutzer
PNG selber laden (oder auch speichern) geht mit der libpng ziemlich einfach. Der AROS png.datatype benutzt die libpng und der Source ist deshalb sehr klein.

Text() in ein pixel array ist auch nicht wirklich schwierig. Code von AROS oder Bernd's AfA abschauen.


[ - Antworten - Zitieren - Direktlink - ]

04.09.2006, 11:07 Uhr

bubblebobble
Posts: 707
Nutzer
@Darius
Du hast vermutlich recht.
Aber ich will nicht, dass meine Software hinterher auf der Hälfte der Systeme nicht ordentlich läuft. Aber das ist auch nicht mein Problem, einen png Loader/Saver habe ich schon lange fertig.

@George
Danke für die Tipps. Ich habe mein Png Loader/Saver bis auf den GZip Alogrithmus selbst implementiert. Das war recht interessant, und ich habe einiges über Bildformate gelernt.


Ich habe jetzt fast alles auf System Bitmaps re-implementiert. Nur noch beim Remappen auf <=8 bit benutze ich guigfx. Das kommt auch noch dran.

Aber eins ist mir noch aufgefallen:

Wenn ich einen Layer/RastPort über meiner ARGB Bitmap erzeuge, wird diese gecleared (alles zu 0, schwarz), bei CreateUpFrontLayer().
ist das normal oder mache ich das was falsch ?

code:
...
\ARGBbitmap_ptr = AllocBitmap(...)
...
If \ARGBbitmap_ptr
  \layerinfo_ptr = NewLayerInfo_
  If \layerinfo_ptr
    \layer_ptr    =  CreateUpfrontLayer_ (\layerinfo_ptr,\ARGBbitmap_ptr,0,0,\img_width-1,\img_height-1,0,0)
    If \layer_ptr
      \rastport_ptr = \layer_ptr\rp
    Else
      error {"image_init_rp: Unable to create upfront layer!"}
    End If
  Else
    error {"image_init_rp: Unable to allocate LayerInfo!"}
  End If
Else
   error {"image_init_rp: Unable to get ARGB bitmap!"}
End If



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


[ - Antworten - Zitieren - Direktlink - ]

04.09.2006, 11:41 Uhr

Georg
Posts: 107
Nutzer
@bubblebobble:

Der layer wird backgefillt. CreateUpfrontHookLayer mit hook = LAYERS_NOBACKFILL verwenden. Als layertyp würde ich LAYERSIMPLE verwenden obwohl es eigentlich egal ist. Ich erinnere mich vage daran, daß es evtl. bei entweder SIMPLEREFRESH oder SMARTREFRESH Layern das Problem gibt, das LAYERS_NOBACKFILL beim Layer Erzeugen ignoriert wird und deshalb trotzdem alles 0,schwarz wird. Wenn das so ist, den anderen layertyp probieren.


[ - Antworten - Zitieren - Direktlink - ]

04.09.2006, 12:13 Uhr

bubblebobble
Posts: 707
Nutzer
@Georg

Danke. Dass es nicht gefüllt wird ist wichtig für mich, denn sonst kann ich den Rastport nicht anlegen, wenn er angefragt wird, sondern muss ihn immer anlegen, VOR dem Laden des Bildes. Und das würde doch einiges an Speed und Speicher kosten, wenn man z.B. 1000 Bildchen für ein Spiel lädt.



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


[ - Antworten - Zitieren - Direktlink - ]

04.09.2006, 12:50 Uhr

gni
Posts: 1106
Nutzer
Zitat:
bubblebobble:
Ich habe mein Png Loader/Saver bis auf den GZip Alogrithmus selbst implementiert.

Und damit kannst Du alle PNG-Varianten inklusive aller möglichen Chunks laden oder nur ARGB? Wenn Du gzip nicht selber gemacht hast, wie dekodierst Du das dann - mit einer shared zlib?

[ - Antworten - Zitieren - Direktlink - ]

04.09.2006, 13:31 Uhr

bubblebobble
Posts: 707
Nutzer
Mit der zlib.library aus dem Aminet.
Leider ist die nicht sooo toll, man kann z.B. nicht in
mehreren Chunks entpacken/packen. Es muss immer alles
auf einmal in einem Memoryblock liegen.

Wenn es da eine bessere Lösung gibt wäre ich froh.
Selbst implementieren war mir auf die Schnelle
etwas zu aufwendig, auch wenn es Referenz Code in C gibt.

Der Loader/Saver ist bisher nur für ARGB pngs.
Die anderen werden via Datatype geladen, da gibt es
ja auch kein Problem mit dem Alphachannel.

Das auf RGB auszuweiten wäre allerdings kein Problem, da es ja prinzipiel genauso funktioniert, nur eben auf 3 statt 4 bytes pro Pixel. Für den Saver mache ich das auf jeden Fall noch.

Die anderen Chunks werte ich nicht aus, wird auch so gut wie nie verwendet.


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


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 13:55 Uhr

bubblebobble
Posts: 707
Nutzer
Noch eine Frage:

BltMaskBitMapRastPort()

Im Falle eine Classic ohne Graka, muss da die Bitmaske im Chipmem liegen ?

Ansonsten kommt der Blitter ja nicht an die Bitmaske, und somit kann er das nicht erledigen, sondern die CPU muss ran.

Gibt es einen standard Weg, diese Mask zu erzeugen oder soll man einfach Speicher allocieren und das selbst tun ?

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


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 14:21 Uhr

thomas
Posts: 7716
Nutzer

AllocBitMap mit Tiefe 1 oder AllocRaster.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 14:21 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von bubblebobble:
Noch eine Frage:

BltMaskBitMapRastPort()

Im Falle eine Classic ohne Graka, muss da die Bitmaske im Chipmem liegen ?

Ansonsten kommt der Blitter ja nicht an die Bitmaske, und somit kann er das nicht erledigen, sondern die CPU muss ran.


Natürlich, auch wenn es mittels FBlit auch ohne gehen könnte, aber verlassen würde ich mich darauf nicht.

Zitat:
Gibt es einen standard Weg, diese Mask zu erzeugen oder soll man einfach Speicher allocieren und das selbst tun ?

was ist ein Standard Weg eine Maske zu erzeugen? Das einzige womit man eine Maske erzeugen kann ist guigfx/CreatePictureMask(), allerdings ist das IMHO nutzlos, da es aus einem ARGB Bild die Alphamaske in eine blitter-fähige-ein-bit Maske konvertiert.

Eine Maske für BltMaskBitMapRastPort() ist ein linearer Speicherbereich im CHIP MEM, mit (((width+15)>>4)<<4)*height bits, ich wüsste nicht wie man aus einem Bild eine Maske erstellen sollte, außer man sagt z.B. Farbe 0 = Maske, oder meintest du soetwas ähnlichen wie AllocMask(w,h), was nur den Speicher alloziiert? das gibt's nicht auch wenn es ganz gut wäre, da es entsprechend AllocBitmap() auch auf die Boundaries (Wordgrenzen) wert legen könnte.


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 14:29 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von thomas:

AllocBitMap mit Tiefe 1 oder AllocRaster.

Gruß Thomas

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


Das ist der Grund warum ich die Maskenfunktionen nicht Mochte, ich wußte nie so genau on die Masken an Wordgrenzen liegen mussten, lt. Autodocs muss AllocBitmap()->Planeptr[0] nicht AllocRaster() entsprechen. Anders ausgedrückt liefert AllocRaster() nicht einfach AllocMem((width*height+7)>>3, MEMF_XYZ) zurück?

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 14:46 Uhr

bubblebobble
Posts: 707
Nutzer
Ich meinte jetzt nicht, wie man semantisch die Maske erzeugt (bei mir geht die nach Alphakanal mit Schwellwert ODER Farbe mit Schwellwert ODER aus einer Datei), sondern rein programmiertechnisch.

Ich will kein Allocmem mit MEMF_CHIPMEM drin haben. Was würde da auf OS4 oder MOS passieren ? Ausserdem ist das für Grafikkarten nicht besonders toll wenn die Maske im Chipmem liegt.

Ok, AllocBitmap mit Tiefe 1 klingt gut, aber woher will AllocBitmap wissen, ob ich vorhabe auf einen 24 Bit screen zu gehen oder auf einen PAL screen beispielsweise ?
Klar, Picasso96 könnte die Bitmap swappen, aber bei BltMaskBitmapRastPort gibt man ja nur den Pointer auf die nackte Bitplane an (16bit aligned). Weder den Pointer auf die 1-Bit Bitmap, noch einen ByterPerRow parameter.

Wie guigfx das macht weiss ich nicht, aber es muss ja auch irgendwelche OS funktionen dazu benutzen. Teilweise gab es aber auch da wohl Probleme auf ChipSet Screens.

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


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 14:58 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von DariusBrewka:
Das ist der Grund warum ich die Maskenfunktionen nicht Mochte, ich wußte nie so genau on die Masken an Wordgrenzen liegen mussten, lt. Autodocs muss AllocBitmap()->Planeptr[0] nicht AllocRaster() entsprechen. Anders ausgedrückt liefert AllocRaster() nicht einfach AllocMem((width*height+7)>>3, MEMF_XYZ) zurück?


Wohl eher AllocMem((((width+15)>>3)&~1)*height, MEMF_CHIP).
Aber, ob das nun eine Plane mit "same size and dimensions as the planes of the source bitmap" ist? AllocBitMap liefert mit Sicherheit andere Planes, es sei denn, man gibt nicht displayable und keine friend BitMap an. Aber wenn wirklich bytesPerRow übereinstimmen müssten, würde AllocBitMap selbst mit displayable und friend BitMap keine identischen Resultate liefern, wenn z.B. die ZielBitMap interleaved ist, weil interleaved mit depth==1 im Prinzip identisch mit non-interleaved ist...

Wenn ich drüber nachdenke, mag ich die Maskenfunktion (und ihre unzureichende Dokumentation) auch nicht.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 15:04 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von bubblebobble:
Ok, AllocBitmap mit Tiefe 1 klingt gut, aber woher will AllocBitmap wissen, ob ich vorhabe auf einen 24 Bit screen zu gehen oder auf einen PAL screen beispielsweise ?

Das darf für die Maske keinen Unterschied machen. Natürlich ist das etwas ineffizient, wenn man für den Blit auf den RTG Screen Chip-Ram benutzt.
Zitat:
Klar, Picasso96 könnte die Bitmap swappen, aber bei BltMaskBitmapRastPort gibt man ja nur den Pointer auf die nackte Bitplane an (16bit aligned). Weder den Pointer auf die 1-Bit Bitmap, noch einen ByterPerRow parameter.
Vermutlich ist AllocRaster dann passender. Was dann heißen würde, dass man das "same size and dimensions as the planes of the source bitmap" aus der Dokumentation in die Tonne treten müsste. Dann wäre es also eine Plane mit 16Bit-Alignment, und man könnte genausogut den Speicher von Hand belegen, weil man dann mit Sicherheit auch Fast-Ram benutzen kann, wenn man weiß, dass die Ziel-BitMap RTG ist.

Falls das so stimmt.

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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 15:12 Uhr

bubblebobble
Posts: 707
Nutzer
Also unter WinUAE und Amithlon funktioniert es ohne Probleme, wenn ich die Maske per Hand mit AllocMem im FAST RAM allociere.
Die Frage ist nur, was macht ein Classic oder andere Systeme draus ?

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


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:04 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
Also unter WinUAE und Amithlon funktioniert es ohne Probleme, wenn ich die Maske per Hand mit AllocMem im FAST RAM allociere.

Hast du auch UAEGFX aus Devs/Monitors gelöscht und neu gestartet ? Solange UAEGFX läuft, können Bitplanes im Fast-RAM angelegt werden, auch bei OCS/ECS/AGA. Nur wenn du wirklich nativ (also mit Blitter) arbeitest, müssen Maske und Bitmaps ins Chip-RAM.

Gruß Thomas


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

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:18 Uhr

malte2
Posts: 148
Nutzer
Für non-interleaved bitmaps:

PLANEPTR mask = AllocRaster(GetBitMapAttr(bm, BMA_WIDTH)/8, GetBitMapAttr(bm, BMA_HEIGHT));

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:26 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von Holger:
Zitat:
Anders ausgedrückt liefert AllocRaster() nicht einfach AllocMem((width*height+7)>>3, MEMF_XYZ) zurück?

Wohl eher AllocMem((((width+15)>>3)&~1)*height, MEMF_CHIP).


lt. z.B. AROS sourcecode zu AllocRaster schon, aus den Autodocs kann ich das leider nicht herauslesen, dort steht nur dass für width*height Pixel Speicher belegt wird d.h. für mich (width*height+7)>>3 Bytes für das andere wird auf AllocBitmap() verwiesen.

Aber auch egal, diese Funktion ist auf RTG Systemen sowieso nutzlos wie schon mehrfach beschrieben, da diese nicht wissen kann ob nun CHIP oder FAST benötigt wird.

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:28 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von malte2:
Für non-interleaved bitmaps:

PLANEPTR mask = AllocRaster(GetBitMapAttr(bm, BMA_WIDTH)/8, GetBitMapAttr(bm, BMA_HEIGHT));


das halte Ich für gewagt bzw. warum soll die Maske plötzlich 8 mal schmaler sein?

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:31 Uhr

bubblebobble
Posts: 707
Nutzer
Also nehme ich jetzt AllocRaster oder AllocBitmap oder AllocMem ?

Im RKM steht bei FreeRaster, dass es CHIP Mem wäre.
Aber das muss ja nicht auf ein RTG Sysstem zutreffen.

Noch eine Frage:

Wenn ich den Bildaufbau in einem Spiel synchronisieren will, kann ich da auf allen Systemen WaitBOVP(ViewPort) benutzen ?

Auf WinUAE scheint das tatsächlich zu funktionieren, er wartet auf den "echten" VBlank, nicht der 50Hz VBlank des Chipsets.

Wobei der "echte" VBlank in WinUAE gefaked zu sein scheint, eine Versatzlinie läuft ganz langsam durch das Bild, aber immer noch besser als mit dem timer.device eine gewisse Zeit abwarten und dann blitten, dann sieht das Bild recht instabil aus (so wie in AsteroidsTR momentan die Scroll Version, oder in meinen Sources das "mirror" demo).

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


[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:37 Uhr

malte2
Posts: 148
Nutzer
@DariusBrewka:

Das /8 ist natürlich Unsinn, hatte gerade nochwas anderes im Sinn...

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:41 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von malte2:
@DariusBrewka:

Das /8 ist natürlich Unsinn, hatte gerade nochwas anderes im Sinn...


es wird für Interleaved / Noniterleaved Masken keinen Unterschied machen, der einzige Unterschied zwischen Interleaved und Non-Interleaved Bitmaps ist das bei Interleaved nur eine Plane existiert, die aber DEPTH mal so hoch ist. Damit werden auch die Boundaries (WORDGRENZEN) gleich sein.

[ Dieser Beitrag wurde von DariusBrewka am 05.09.2006 um 16:42 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.09.2006, 16:43 Uhr

bubblebobble
Posts: 707
Nutzer
Sorry, und gleich noch eine Frage.

Ich benutze LockBitmapTagList() um an den RAW Data pointer und die BytesPerRow zu kommen, dann bearbeite ich die Daten und mache dann UnlockBitmap.
Ist das vorgehen korrekt ? Ich vermute, die Daten über die Bitmap sind nur so lange korrekt, wie sie gelocked ist. Ansonsten könnte Picasso96 mir die Bitmap unter den fingern Weg swappen, evtl. sogar das Format verändern.

Allerdings habe ich festgestellt, wenn ich nicht schleunigst "unlockBitmap" mache, freezed der Rechner schnell. Man darf wohl wirklich nichts dazwischen anderes tun als die Bitmap beabreiten. Z.B. wenn ich das Programm mit dem Debugger nach dem Lock anhalte, freezed der Rechner. Vermutlich weil Picasso96 andere Dinge mit dem Debugger zu tun hat, und auf die freigabe der Bitmap wartet. Aber das locken einer beleibigen Bitmap dürfte doch nicht alle anderen Operationen blockieren, oder?

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


[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 4 5 6 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Bitmaps nur durch 16 teilbare Breite? [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.