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 - ]

06.09.2006, 15:04 Uhr

bubblebobble
Posts: 707
Nutzer
Ich denke das mit den Bitmasks haben jetzt alle verstanden.

Was haltet ihr denn von WaitBOVP() ?

WaitBOVP() scheint unter WinUAE nur gefakted zu sein, und stimmt nicht 100% mit dem Monitor VSync überein. Dadruch hat man einen versatz z.B. bei horizontalem scrolling. Ist aber immer noch besser und "stabile" snzuschauen als wenn man willkürlich den Bilschirm updated. Aber vielleicht ist es ja auch anderen Systemen korrekt.
(vielleicht auch überhaupt nicht,und bringt nur den Standard 50Hz, der nichts mit dem heutigen Monitoren zu tun hat.)

Gibt es noch andere Möglichkeiten, den Bildschirm output mit dem Monitor zu synachronisieren ? Das ist notwendig, sonst bekommt man kein Versatz-freies sauberes Scrolling hin.

Wer will, dem schicke ich mal ein Test Program mit verschiedene Sync modi, damit ich Feedback bekomme welche Methode am besten aussieht.


--
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 - ]

06.09.2006, 15:05 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Georg:
Zitat:
Original von gni:
Der Grafikchip der PIV (CL5446) hat einen Planarmodus und den kann man mit P96 auch problemlos benutzen.

Planare Modi müßten eigentlich bei allen Grafikkarten da sein.
Ich wußte es nur definitiv für die PIV.
Zitat:
Der standard 640 x 480 x 16 Farben VGA Modus ist so ein planarer Mode.
Genau den benutze ich für einen uralt DiskMaster ;) Prinzipiell läuft der zwar auch mit einem Chunky-Screenmode, aber gelegentlich endet das dann im Guru. Nachdem ich diesen Planarmode "entdeckt" hatte, habe ich das für problematische Software verwendet. Das gute alte MOS 0.4 hat zb. bei mir mit P96 auch nur mit einem planaren Grafikartenbildschirm gewollt. Aber das ist Schnee von gestern ;-)
Zitat:
Die Planes sind im Speicher dabei auch so wie beim Amiga (also nicht z. B. wie beim Atari ST oder bei diesen komischenen Planaren Chunky Modes).
Was ist "planares Chunky"?
Zitat:
Der AROS vga.hidd Treiber benutzt den Modus (weil er immer vorhanden sein sollte). Im Treiber intern wird aus Geschwindigkeitsgründen und wohl auch ein wenig Faulheit alles in nen RAM chunky buffer gerendert und Änderungen dann per chunky 2 planar ins VRAM übertragen.
Und ich dachte c2p wurde nur beim Amiga benötigt ;)

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 15:12 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von bubblebobble:
Ich denke das mit den Bitmasks haben jetzt alle verstanden.

Was haltet ihr denn von WaitBOVP() ?

WaitBOVP() scheint unter WinUAE nur gefakted zu sein, und stimmt nicht 100% mit dem Monitor VSync überein. Dadruch hat man einen versatz z.B. bei horizontalem scrolling. Ist aber immer noch besser und "stabile" snzuschauen als wenn man willkürlich den Bilschirm updated. Aber vielleicht ist es ja auch anderen Systemen korrekt.
(vielleicht auch überhaupt nicht,und bringt nur den Standard 50Hz, der nichts mit dem heutigen Monitoren zu tun hat.)


Das ist auch bei CGFX/P96 auf 68K-Maschinen und GraKa so. WaitBOVP() ist auf GraKas nicht zu gebrauchen (ist das technisch überhaupt machbar? Da war doch irgendwas, daß der Copper für den BOVP-Sync zuständig ist?).

Wie das für WaitTOF() aussieht, kann ich nicht genau sagen, das scheint aber zu funktionieren, da die DB-Funktionen des OS einwandfrei ihren Dienst tun (wenn auch etwas komplex zu handhaben). Bisher ist mir dabei noch kein Geflacker begegnet.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 16:15 Uhr

malte2
Posts: 148
Nutzer
WaitBOVP() basiert auf Polling, WaitTOF() nutzt das VBlank IRQ. Je nach Grafiksystem und Graka kann auch beides mit IRQ funktionieren oder überhaupt nicht (dann wird der Chipset IRQ benutzt bzw. Polling).

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 18:08 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Georg:
Zitat:
Original von Holger:

Also eigentlich so:

1111........
1001........
1111........


Nein. Wenn alle Planes auf einmal geblittet werden sollen, dann geht das nicht. Denn alle Blitterquellen zählen ja alle jedesmal um ein WORD hoch und die Masken-Quelle würde dann in die "." reinlaufen und für die Planes [2 bis Anzahlplanes] nicht richtig sein.


1.) Nirgendwo in der Dokumentation ist spezifiziert, dass der Transfer im Falle interleaved BitMaps tatsächlich in einem Rutsch erfolgt. Dagegen steht dort "same size and dimensions". Wenn man die Planes mit dem original-Algorithmus einzeln kopiert, gibt es keine Kompatiblitätsprobleme.

2.) Wie Du selber schreibst, kann man die Modulo-Werte des Blitters für jede Quelle einzeln setzen, und Quelle und Maske sind verschiedene Quellen. Wenn die Implementierung intern die Modulo-Werte anpasst, kann man in einem Rutsch transferieren, und hat ebenfalls keine Kompatiblitätsprobleme.

3.) Eine Funktion kompatibel implementieren, heißt nicht, sie so implementieren, wie ein altes Programm, das von interleaved nichts weiß, sie implementieren würde. Sondern so, wie sie bei Auslegung der Spezifikation für den Aufrufer das richtige tut. So dass ein Programm, das von interleaved nichts weiß, sie trotzdem aufrufen kann.

Wenn sie nicht, wie oben angegeben funktioniert, dann ist sie inkompatibel. Wenn sie inkompatibel wäre, würde es auch keinen Grund geben, die Vervielfachung der Maskenzeilen vom Programmierer zu fordern.

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

[ - Antworten - Zitieren - Direktlink - ]

06.09.2006, 19:41 Uhr

Georg
Posts: 107
Nutzer
Zitat:
Original von Holger:
1.) Nirgendwo in der Dokumentation ist spezifiziert, dass der Transfer im Falle interleaved BitMaps tatsächlich in einem Rutsch erfolgt. Dagegen steht dort "same size and dimensions". Wenn man die Planes mit dem original-Algorithmus einzeln kopiert, gibt es keine Kompatiblitätsprobleme.


Stehen tuts nirgends, aber man siehts ja das es so ist wenn man BltMaskBitMapRastPort() mit ner interleaved BitMap benutzt. Ich hatte nie ne Grafikkarte in meinem A1200 und hab' das selber benutzt und gesehen.

Vermutlich ist das ja wie gesagt ein Bug der bei Einführen von interleavt BitMaps übersehen wurde. Denn es ist nicht unwahrscheinlich daß bei Blits die graphics.library sowas macht:

code:
if (interleavedbitmap)
{
   ypos *= planes;
   height *= planes;
   planes = 1
}
/* alter Code */


Zitat:
2.) Wie Du selber schreibst, kann man die Modulo-Werte des Blitters für jede Quelle einzeln setzen, und Quelle und Maske sind verschiedene Quellen. Wenn die Implementierung intern die Modulo-Werte anpasst, kann man in einem Rutsch transferieren, und hat ebenfalls keine Kompatiblitätsprobleme.

Nein, das geht eben nicht. Alle Quellen (+ Ziel) verarbeiten ja die gleiche Menge an Daten, aber ne 1-Plane Maske ist halt kleiner als ne 5-Plane Grafik. Da kann man mit Modulos nichts machen wenn man alles in einem Blit machen will. Praktisch bräuchte es für den Blitter ein Feature um der Mask Quelle zu sagen "wiederhole Zeile" Anzahl Planes mal. Das Feature gibt es aber nicht. Der Blitter kennt "Multiplanes" nicht. Nur rechteckige Speicherbereiche (= 1 Plane), also für die Breite ein best. Anzahl Bytes - dazwischen zu ignorierende Bytes (Modulo) - und das "Höhe mal" wiederholt.

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 00:21 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
@Holger

Beim Blitten von width*height Pixeln, kopiert der Blitter zuerst die erste Zeile und erhöht dann die Quelladresse um den Modulowert, du kannst sowohl für die Quelle d.h. das Image, die Maske und für das Ziel Adressen setzen als auch Modulo werte. Damit ist auch erslichtlich, warum man nicht einfach mittels einer 1 Bit Maske ein Mehrplaniges Image maskieren kann und dass ein Blitt in einem Rutsch nur dann möglich ist, wenn sowohl Quelle als auch Ziel wie auch die Maske, gleiche Tiefe besitzen und selbst Interleaved sind.

wenn du z.B. das folgende 2 Bit Image in eine Zielmap kopieren willst

110011 plane1 zeile 1
001100 plane2 zeile 1
001110 plane1 zeile 2
001000 plane2 zeile 2

001100 maske plane 1 zeile 1
001100 maske plane 2 zeile 1
110011 maske plane 1 zeile 2
110011 maske plane 2 zeile 2

000000000 ziel plane 1 zeile 1
000000000 ziel plane 2 zeile 1
000000000 ziel plane 1 zeile 2
000000000 ziel plane 2 zeile 2

wen du jetzt das 2 Planige Image mit der Breite 6 und der Höhe 2 Pixeln in das Zielimage kopieren willst welches hier 9*2 pixel gross ist sind die Modulus für die Quelle und die Maske 0 und für das Ziel 3, d.h. wenn eine ganze Zeile kopiert wurde müssen im Ziel 3 Pixel übersprungen werden. Bei der Quelle und Maske sind die Modulos = 0, da nach 6 Pixeln automatisch die nächste Zeile/Plane kommen, im Speicher sieht das ganze halt so aus als ob es ein DEPTH mal so hohes Image wäre, also eine Plane mit Depth=1, aber 4 Zeilen.

Interleaved ist weil der Blitter wenn er die ersten 6 Zeilen der Quelle kopiert hat automatisch die ersten 6 Pixel der zweiten Plane hat, er muß nur im Ziel 3 Pixel nach jeder Zeile überspringen.

Du kannst damit wie Georg auch sagte nicht den Blitter anweisen Zeilen zu wiederholen, wenn du mit einem Blitt auskommen willst, weil der Blitter nach der Erszen Zeile automatisch in der Nächsten ist, du kannst das Modulo halt auf -6 Setzen, aber dann würde der Blitter immer nur die erste Zeile der Maske laden, d.h.

bei einer Maske

001100
110011

wie Sie bei einem planaren äquivalent nötig wäre wäre der Blitter nach 6 Pixeln in der Zweiten Zeile, bei einem Modulo von -6, wäre er nach dem lesen zwar immer noch am Anfang, aber das dann für immer.

Du Kannst den Blitter aber auch Depth mal starten und dann hast du das Problem nicht eine Depth Planige maske haben zu müssen, hast aber keinen Vorteil gegenüber Noninterleaved Images.

[ Dieser Beitrag wurde von DariusBrewka am 07.09.2006 um 00:24 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 15:58 Uhr

Holger
Posts: 8116
Nutzer
Genug der was-wäre-wenn Diskussion. Folgendes Programm dürfte ja nach Eurer Auffassung dann nicht funktionieren, sondern müsste ein einfarbiges Bild erzeugen, weil ja die Maskenbits nicht verdoppelt wurden.

Auf meinem System funktioniert es allerdings und produziert mit Interleaved und Non-Interleaved BitMask identische Bilder:
C code:
#include <proto/intuition.h>
#include <proto/graphics.h>
#include <intuition/intuition.h>
#include <graphics/gfx.h>

__chip ULONG Plane0[]={
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFF0000FF,
0xFF0000FF,
0xFF0000FF,
0xFF0000FF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
}, Plane1[]={
0xFFFFFFFF,
0xFFFFFFFF,
0xFC00003F,
0xFC00003F,
0xFC00003F,
0xFC00003F,
0xFC00003F,
0xFC00003F,
0xFC00003F,
0xFC00003F,
0xFFFFFFFF,
0xFFFFFFFF,
}, ilPlane[]={/* two interleaved Planes */
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFC00003F,
0xFFFFFFFF,
0xFC00003F,
0xFF0000FF,
0xFC00003F,
0xFF0000FF,
0xFC00003F,
0xFF0000FF,
0xFC00003F,
0xFF0000FF,
0xFC00003F,
0xFFFFFFFF,
0xFC00003F,
0xFFFFFFFF,
0xFC00003F,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
0xFFFFFFFF,
},
Mask[]={
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
0xAAAAAAAA,
},
ilMask[]={/* interleaved Mask, just normal Map with padding */
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
0xAAAAAAAA, 0x00000000,
};
struct BitMap bm={
  4, 12, 0, 2, 0, 
  (UBYTE*)Plane0, (UBYTE*)Plane1, NULL, NULL, NULL, NULL, NULL, NULL
}, ilBM={/* interleaved BitMap */
  8, 12, 0, 2, 0x805c,
  (UBYTE*)ilPlane, (UBYTE*)(ilPlane+1), NULL, NULL, NULL, NULL, NULL, NULL
};

int main(int bla, char**fasel)
{
  struct Window *win;
  if(win = OpenWindowTags(NULL,
          WA_ScreenTitle, "BitMap Test, Interleaved/Non-Interleaved",
          WA_InnerWidth, 34, WA_InnerHeight, 30,
          WA_Flags, WFLG_DRAGBAR|WFLG_DEPTHGADGET|WFLG_CLOSEGADGET|WFLG_SMART_REFRESH,
          WA_IDCMP, IDCMP_CLOSEWINDOW,
       TAG_DONE))
  {
    BltMaskBitMapRastPort(&bm, 0, 0, win->RPort,
        win->BorderLeft+2, win->BorderTop+2,  32, 12, 0xe0, (APTR)Mask);
    BltMaskBitMapRastPort(&ilBM, 0, 0, win->RPort,
        win->BorderLeft+2, win->BorderTop+16, 32, 12, 0xe0, (APTR)ilMask);
    WaitPort(win->UserPort);
    CloseWindow(win);
  }
  return 0;
}


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

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 16:41 Uhr

whose
Posts: 2156
Nutzer
@Holger:

Und welches System ist das genau? Zumindest hast Du damit gezeigt, daß die von Dir befürchtete "Inkompatibilität" nicht (mehr) besteht. Obwohl ich dieses Funktionieren eher als Workaround betrachten würde.

Hast Du das Programm mal auf nem "echten" AGA-Amiga getestet?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 16:55 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
C code:
__chip ULONG Plane0[]={


Welcher Compiler (wegen __chip)?

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 16:58 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
@Holger:
Und welches System ist das genau? Zumindest hast Du damit gezeigt, daß die von Dir befürchtete "Inkompatibilität" nicht (mehr) besteht. Obwohl ich dieses Funktionieren eher als Workaround betrachten würde.

AOS3.9
Ich sehe das nicht als Workaround, es ging ja nur um die Frage, ob die Funktion exakt so, wie dokumentiert, funktioniert, also die Maske lediglich die gleiche bytesPerRow aufweisen muss, oder ob man tatsächlich pro Bitplane die Maskendaten wiederholen muss.

Das Problem der Speicherverschwendung löst sich dadurch nicht.
Es sei denn, man hat bis zu acht gleich große Bilder, dann könnte man die zugehörigen Masken verzahnt im Speicher ablegen.
Zitat:
Hast Du das Programm mal auf nem "echten" AGA-Amiga getestet?
Was heisst echt?
Ich habe von einer Interleaved BitMap auf eine Interleaved BitMap (Workbench 256Farben) kopiert.
Dass der AGA-Chip von UAE emuliert wurde, halte ich nicht für relevant. Der verhält sich exakt so, wie die Software, in diesem Fall die graphics.library, ihm befiehlt. Sonst würden die Spiele kaum funktionieren, wenn die Behandlung von Modulo und Masken in der Blitteremulation nicht exakt wäre.

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

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 16:59 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von gni:
Zitat:
Holger:
C code:
__chip ULONG Plane0[]={


Welcher Compiler (wegen __chip)?

vbcc

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

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 17:00 Uhr

thomas
Posts: 7716
Nutzer
@Holger:

Du mußt bei interleaved Bitmaps BMF_INTERLEAVED setzen. Und dann mußt du auch die Maske in der Höhe verdoppeln. Dein Beispiel zeigt nur, daß man, wenn man nicht AllocBitMap benutzt, pseudo-interleaved Bitmaps anlegen kann, die die Vorteile von "richtigen" interleaved Bitmaps nicht nutzen.

Daß man bei interleaved Bitmaps die Maske in der Höhe an die Tiefe der Bitmap anpassen muß, ist keine Inkompatibilität, sondern liegt in der Natur der Sache.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 17:12 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
@Holger:
Und welches System ist das genau? Zumindest hast Du damit gezeigt, daß die von Dir befürchtete "Inkompatibilität" nicht (mehr) besteht. Obwohl ich dieses Funktionieren eher als Workaround betrachten würde.

AOS3.9
Ich sehe das nicht als Workaround, es ging ja nur um die Frage, ob die Funktion exakt so, wie dokumentiert, funktioniert, also die Maske lediglich die gleiche bytesPerRow aufweisen muss, oder ob man tatsächlich pro Bitplane die Maskendaten wiederholen muss.


Dann probier das doch nochmal auf einem blanken 3.1-System. Ich denke nämlich schon, daß da ein Workaround eingebaut wurde, um eben genau dieses Problem älterer Software zu beheben.

Zitat:
Das Problem der Speicherverschwendung löst sich dadurch nicht.
Es sei denn, man hat bis zu acht gleich große Bilder, dann könnte man die zugehörigen Masken verzahnt im Speicher ablegen.


Hm, da hast Du eine interessante Idee ins Spiel gebracht... ich notier mir das mal :)

Zitat:
Zitat:
Hast Du das Programm mal auf nem "echten" AGA-Amiga getestet?
Was heisst echt?
Ich habe von einer Interleaved BitMap auf eine Interleaved BitMap (Workbench 256Farben) kopiert.
Dass der AGA-Chip von UAE emuliert wurde, halte ich nicht für relevant. Der verhält sich exakt so, wie die Software, in diesem Fall die graphics.library, ihm befiehlt. Sonst würden die Spiele kaum funktionieren, wenn die Behandlung von Modulo und Masken in der Blitteremulation nicht exakt wäre.


Das ist richtig. Ich meinte allerdings mehr einen bspw. A1200, wie er zum Spielen gern verwendet wird. Also ohne OS3.9 und ohne P96. Darauf dürfte Dein Programm wahrscheinlich Probleme machen. Für Spiele (die kommerziellen Titel vor allem) ist die graphics.library wohl auch nicht so sehr von Belang. Selbst viele PD-Titel haben die fürs Blitten außen vor gelassen.

Die Geschichte wurde von Darius, malte2 und georg ja nicht nur so aus Spaß erwähnt...

Um mal wieder aufs letzte Thema zu kommen: Gibts eigentlich Informationen darüber, welche GraKas WaitTOF() bzw. WaitBOVP() in Hardware unterstützen oder wie die Emulation dieser Funktionen per Software genau funktioniert? Es ist irgendwie lästig, daß man sich nie sicher sein kann, ob eine Grafik flackerfrei auf den Bildschirm kommt, je nach System.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 17:12 Uhr

malte2
Posts: 148
Nutzer
@thomas:

BMF_INTERLEAVED ist kein Flag in der BitMap Struktur, das Flag wird in GetBitMapAttr() "berechnet". Sein Beispiel funktioniert deshalb, weil ein Maskenblit nichts anderes als eine Folge von 3 Blits ist:

Soure->Dest mit (ABC|ANBNC)
Mask->Dest mit Minterm (0xe0)
Source->Dest mit (ABC|ANBNC)

Wobei aus der Maske eine BitMap erzeugt wird, bei der alle Plane Pointer dem ersten Pointer entsprechen.

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 17:15 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von thomas:
@Holger:
Du mußt bei interleaved Bitmaps BMF_INTERLEAVED setzen. Und dann mußt du auch die Maske in der Höhe verdoppeln. Dein Beispiel zeigt nur, daß man, wenn man nicht AllocBitMap benutzt, pseudo-interleaved Bitmaps anlegen kann, die die Vorteile von "richtigen" interleaved Bitmaps nicht nutzen.

Daß man bei interleaved Bitmaps die Maske in der Höhe an die Tiefe der Bitmap anpassen muß, ist keine Inkompatibilität, sondern liegt in der Natur der Sache.


Das ist doch schon wieder die gleiche Art der Mutmaßungen, wie wir sie vor dem Beispielprogramm hatten.

1.) Benutz den Code und füge meinetwegen eine Abfrage per GetBitMapAttr(..., BMA_FLAGS) hinzu, ob die BitMap Interleaved ist. Sie ist Interleaved.

2.) Die Maske besitzt die korrekte Größe. Die hat sie, weil ich mit 0-bytes padding eingefügt habe, wie man deutlich sehen kann. Eine "Höhe" besitzt die Maske nicht. Sie besitzt nunmal, wie spezifiziert die gleichen Dimensionen wie die Quell-BitMap. Das heisst, pro Zeile padding-bytes.

3.) Dass sich diese Funktion kompatibel verhält, zeigt dieser code ja.

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

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 17:17 Uhr

malte2
Posts: 148
Nutzer
@whose:

Bei p96 kann der User den IRQ abschalten. Die Emulation besteht darinn einfach den OCS/ECS/AGA Chipsatz IRQ zu verwenden bzw. das Positionregister mittels Polling abzufragen. Bei OS4 hat wohl jemand einen Timerirq eingebaut, der den klassichen VBlank emuliert.

[ Dieser Beitrag wurde von malte2 am 07.09.2006 um 17:18 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 17:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Dann probier das doch nochmal auf einem blanken 3.1-System. Ich denke nämlich schon, daß da ein Workaround eingebaut wurde, um eben genau dieses Problem älterer Software zu beheben.

Hab ich grad nich da.
Aber ich hatte ganz vergessen, dass ich eh schon vorsorglich das ROM-Update, wie auch AfA und ähnliches abgeschaltet hatte. Also

> version graphics.library full
graphics.library 40.24 (18.05.93)
Zitat:
Für Spiele (die kommerziellen Titel vor allem) ist die graphics.library wohl auch nicht so sehr von Belang. Selbst viele PD-Titel haben die fürs Blitten außen vor gelassen.
Hinzu kommt, dass die meisten Anwendungen nur ihre Grafikobjekte auf den Screen blitten und nichts auslesen. Und sowieso meistens einen eigenen Screen öffnen, und der ist per default non-interleaved. Und deshalb ist bei diesen Programmen die Quelle sehr selten interleaved.

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

[ - Antworten - Zitieren - Direktlink - ]

07.09.2006, 22:21 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Mann kann auch Interleaved Bitmaps mit Masken kopieren die nicht verdoppelt sind, das ist kein Problem nur Reicht in diesem Fall nicht ein einziger Blitt aus.

[ - Antworten - Zitieren - Direktlink - ]

08.09.2006, 14:05 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von DariusBrewka:
Mann kann auch Interleaved Bitmaps mit Masken kopieren die nicht verdoppelt sind, das ist kein Problem nur Reicht in diesem Fall nicht ein einziger Blitt aus.


Klar kann man. Das "wie" hat Georg ja schon gepostet
http://www.amiga-news.de/forum/thread.php?id=23879&start=91&BoardID=7#240425

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

[ - Antworten - Zitieren - Direktlink - ]

08.09.2006, 14:39 Uhr

malte2
Posts: 148
Nutzer
Und das ist genau das gleiche, was BltMaskBMRP() macht. Nur mit den Unterschied, daß die Systemfunktion den Modulo der Sourcebitmap übernimmt und damit die Maske unnötige Leerzeilen benötigt.

[ - Antworten - Zitieren - Direktlink - ]

06.10.2006, 23:20 Uhr

akl
Posts: 265
Nutzer
@DariusBrewka:
akPNG exportiert PBAFMT_ARGB (32 Bit) bei Bildern mit Alphachannel, sonst PBAFMT_RGB (24 Bit) - der Alpha-Support lässt sich auch abschalten, dann wird stets 24 Bit exportiert. PBAFMT_#? entspricht den CyberGraphics-Datentypen für RTG-Bitmaps. Was der pic-dt damit macht, ist eine andere Sache - solange jedoch nichts gerendert wurde, kann er damit auch nichts gemacht haben.

[ - Antworten - Zitieren - Direktlink - ]

07.10.2006, 01:11 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von akl:
@DariusBrewka:
akPNG exportiert PBAFMT_ARGB (32 Bit) bei Bildern mit Alphachannel, sonst PBAFMT_RGB (24 Bit) - der Alpha-Support lässt sich auch abschalten, dann wird stets 24 Bit exportiert. PBAFMT_#? entspricht den CyberGraphics-Datentypen für RTG-Bitmaps. Was der pic-dt damit macht, ist eine andere Sache - solange jedoch nichts gerendert wurde, kann er damit auch nichts gemacht haben.


na mir brauchst du das nicht sagen denn das habe Ich nicht bestritten, sondern benutzt, darum habe ich damals (ca. 1 Jahr her) das AROS datatype auf 68k Compiliert.

[ - Antworten - Zitieren - Direktlink - ]

07.10.2006, 21:45 Uhr

bubblebobble
Posts: 707
Nutzer
Die Frage ist halt, ob man in der Software eine lange Liste haben will die so aussieht:

- aber nur mit datatype.library xzy
- nur mit AKPNG.datatpye V45.1 oder höher
- benötigt AfA V3.93.4
- keine Alphachannel Unterstützung für OS3.x
- usw.

die Leute beschweren sich bei mir schon wenn man die guigfx.library installieren muss.
Ist naütrlich ein Henne-Ei Problem. Wenn man keine Software schreibt, die hohe Voraussetzungen hat, zwingt man auch nicht die User sich das zu installieren. Anderer seits bekommt man im obigen Fall jede Menge Bugreports und Vorwürfe, warum das nun auf System xzy nicht läuft.

BTW:

Das Problem mit den Bitmaps und der 16er Bereite habe ich jetzt akzeptiert und alles so umgeschrieben, dass es mit beleibigen Bytes Per Row funktioniert. Ist auch viel sauberer so.

Das einzige Problem was ich jetzt noch habe ist, dass ich nur in Schwarz auf meine Bitmaps+RastPort malen kann, mangels ColorMap/Friendly screen.
Der Penless Mode würde wohl unter OS4 und MOS funktionieren, aber leider nicht unter OS3.x, weil Penless Mode nur mit dem "Palette-temporär-verbiegen-Hack" gelöst ist.
Ich sehe leider auch keine andere Lösung, weil man dazu Picasso96 ändern müsste. Mittlerweile ist das ja wohl eingebaut, aber wird wohl leider nie für 68k kompiliert werden. Schade. Was für eine Verschwendung.


--
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 - ]

08.10.2006, 00:13 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Naja, wenn jamand deine Software benutzen will, dann muß er darauf eingehen. Ich habe das damals so gemacht, weil man durch das ewige schauen daß es auch auf LowConfig-Rechnern geht, entweder mehr Arbeit oder kaum Entwicklungschancen hatte.

Es ist ja nicht so daß der User andauernd nach den Neusten suchen muß um dein Programm zu benutzen.

[ - Antworten - Zitieren - Direktlink - ]

08.10.2006, 00:25 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von bubblebobble:
Das einzige Problem was ich jetzt noch habe ist, dass ich nur in Schwarz auf meine Bitmaps+RastPort malen kann, mangels ColorMap/Friendly screen.


Ich denke mal, die Friendlybitmap braucht man nur für die Initialisierung, dann mach doch einfach Kurzzeitig einen Screen auf und schliesse ihn dann nach AllocBitmap() wieder. AFAIK nutzen alle 32 BIT Screens das BGRA Format, da in dieser Bitmap wahrscheinlich in den freien PLANEPTR u.a. auf die ColorMap verwiesen wird (P96/CGX Konform), kannst du diese Bitmap auch für weitere AllocBitmap() Aufrufe nutzen.

[ - Antworten - Zitieren - Direktlink - ]

08.10.2006, 03:06 Uhr

bubblebobble
Posts: 707
Nutzer
Nein, das Pixelformat z.B. bei AOne und WinUAE/Amithlon ist verschieden. (ARGB vs. BGRA)
Ausserdem will ich für das handling von 24bit Bilder nicht vorraussetzen, dass das System einen solchen Screen öffnen kann.
Z.B. würde niemand einsehen, warum ein Jpeg2PNG CLI Tool eine Grafikkarte benötigt.

Ich weiss, evtl. sollte man sagen: ok, wer kein 24bit hat ist selbst schuld. Hold dir einen gescheiten Rechner!
So wie Microsoft das macht.

Irgendwie will ich immer, dass es auch auf Low-Spec Hardware läuft.
Vielleicht ist es mal an der Zeit, sich davon zu trennen.


--
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 - ]

08.10.2006, 12:40 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Original von bubblebobble:
Irgendwie will ich immer, dass es auch auf Low-Spec Hardware läuft.
Vielleicht ist es mal an der Zeit, sich davon zu trennen.


Dann mach das! Ehrlich was willst du machen? ein 32Bit Malprogram, und was erwartet man davon?, daß es mit 32Bit läuft, also warum setzt man das nicht voraus. Fakt ist 90% Nutzen entweder MOS, OS4 oder WinUAE, selbst ein 68060 kann diese Datenmengen kaum bewältigen und ohne Grafikkarte kann man sowieso kaum noch arbeiten oder meinst du irgendwer würde ein True-Color-malprogramm Allen ernstes auf AGA laufen lassen oder damit er nicht einschläft gar mit 16 Farben Screens?

Speicherverschwendung muß nicht sein, aber wer Truecolor machen will muß damit Rechnen, anders geht es nicht. Wer heutzutage keine Grafikkarte hat macht ehe kaum was, bzw. benutzt DPaint&Co.


[ - Antworten - Zitieren - Direktlink - ]

08.10.2006, 12:42 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]
Zitat:
Z.B. würde niemand einsehen, warum ein Jpeg2PNG CLI Tool eine Grafikkarte benötigt.

Ok, aber ich würde auch nicht sehen warum ein Jpeg2PNG CLI Tool einen Rastport braucht worein man Text mit einer bestimmten Farbe zeichnen kann.


[ - Antworten - Zitieren - Direktlink - ]

08.10.2006, 17:41 Uhr

bubblebobble
Posts: 707
Nutzer
Wenn es nur um ein 24bit Malprogram gehen würde könnte man einen entsprechenden Screen vorraussetzen, klar.

Ich schreibe aber eher so eine Art Function Library für AB2, mit der man alles mögliche machen kann vom Bilderanzeiger über Jpeg2PNG über 2D Spiele über GUI-elemente in einer Anwendung bis hin zu einem Malprogram.
Deshalb sollte diese "Engine" recht scalierbar sein.


Vielleicht sollte ich eine Extra funktion einbauen,
sowas wie image_Prepare24bitDrawingFunctions().
Das geht dann nur mit Graka. Alles andere würde dann noch unabhängig von der Hardware laufen.

Aber ihr habt recht. Wer an einem Rechner ohne Hi/True Color sitzt, macht sowieso nichts ernsthaftes und soll sich nicht beschwereren.
WinXP setzt auch Hi/True Color und 800x600 vorraus.


--
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.
.