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

amiga-news.de Forum > Programmierung > Kreis Zeichnen ohne graphics.library [ - Suche - Neue Beiträge - Registrieren - Login - ]

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

13.04.2008, 11:00 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:

void setpixel(struct raster_bitmap *bm, unsigned int x, unsigned int y)
{
if (x > 0 && x < bm->width && y > 0 && y < bm->width)
{
bm->data[bm->width * y + x] = bm->color;
}
}


Siehts so aus alswenn du einen Punkt mit einer Farbe in eine
Bitmap schreibst?


Das war noch die Pen-basierte Version. Dort habe ich ein Pixel in einem Pixel-Array für die AmigaOS-Funktion WritePixelArray8() gesetzt. In solchen Pixel-Arrays stehen keine Farbwerte, sondern Pen-Nummern. Dort ist ein Byte pro Pixel. Und in diesem Byte steht dann, welche Pen-Nummer dieses Pixel hat.

Was anderes ist es wenn man 24 bzw. 32 Bit Pixelarrays für die Cybergraphx-Funktion WritePixelArray() haben will (Vorsicht: Nicht diese beiden Funktionen verwechseln, auch wenn sie ähnlich heißen).
Dort hat man z.B. für RGB 24 folgendes in dem Pixel-Array stehen: RGBRGBRGB usw. Ein Pixel besteht dort aus 3 Byte - für jede Farbkomponente ein Byte - als Werte von 0-255 oder Hexadezimal geschrieben 0x00 - 0xFF.

Demnach dieht die 24/32 Bit Variante der Funktion setPixel, die einen Pixel in dem Pixel-Array setzt, wie folgt aus:
c code:
void setpixel(struct raster_bitmap *bm, unsigned int x, unsigned int y)
{
    ULONG pos = (bm->width * y + x) * bm->BytesPerPixel;

    
    if (x >= 0 && x < bm->width && y >= 0 && y < bm->height)
    {
	switch (bm->PixFmt)
	{
		case PIXFMT_RGB24:
			bm->data[pos] = bm->Red;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Blue;
		break;

		case PIXFMT_BGR24:
			bm->data[pos] = bm->Blue;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Red;
		break;

		case PIXFMT_RGBA32:
			bm->data[pos] = bm->Red;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Blue;
			bm->data[pos + 3] = bm->Alpha;
		break;

		case PIXFMT_ARGB32:
			bm->data[pos] = bm->Alpha;
			bm->data[pos + 1] = bm->Red;
			bm->data[pos + 2] = bm->Green;
			bm->data[pos + 3] = bm->Blue;
		break;

		case PIXFMT_BGRA32:
			bm->data[pos] = bm->Blue;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Red;
			bm->data[pos + 3] = bm->Alpha;
		break;

		default:
			bm->data[pos] = bm->color;
	}

    }
}


Also nochmal kurz zusammengefasst:

Das Problem ist, daß wir einerseits ein eindimensionales Array haben, in dem die Farbwerte unserer Pixel stehen, andererseits aber eine Matrix, in die unsere Pixel bei der Darstellung kommen. Folglich muß irgendwie berechnet werden, an welcher Position des Arrays unsere Pixeldaten für einen Pixel aus Zeile/Spalte x/y unserer Matrix ist.

Das mache ich mit dieser Zeile (nochmal Danke an Der_Wanderer für die Korrektur):

code:
ULONG pos = (bm->width * y + x) * bm->BytesPerPixel;


Die Breite des Bildes mal die y-Komponente der Position an der unser neuer Pixel hin soll, ergibt die Position, an der die gesuchte Zeile anfängt, in die unser Pixel in der Bildmatrix erscheinen soll. Addiert mal dann noch die x-Kompunente hinzu, haben wir auch die Position bezüglich der Spalte der Bildmatrix. Das ganze müssen wir noch mit der Anzahl der Bytes pro Pixel multiplizieren, da bei 24 Bit 3 Bytes pro Pixel benötigt werden und bei 32 Bit 4 Byte.

Jetzt kommt die If-Klausel:
c code:
if (x >= 0 && x < bm->width && y >= 0 && y < bm->height)


Das ist das Clipping. So stellt man sicher, daß man nicht über den "Rand" der Pixelmatrix "hinauszeichnet". Das würde auch nicht gehen - man würde in irgend einen undefinierten Speicherbereich schreiben (was bei AmigaOS 3.x ja passieren kann, wenn man schlampig programmiert, da kein Speicherschutz).

Um jetzt die RGB(A) Komponenten der Pixel innerhalb des Pixelarrays zu setzen, muss man erstmal schauen, welches Pixelformat man überhaupt haben möchte, da ja je nach Pixelformat RGBRGBRGB ,BGRBRGBRG ,RGBARGBARGBA, usw. in den Speicher muß.
c code:
switch (bm->PixFmt)
	{
		case PIXFMT_RGB24:
			bm->data[pos] = bm->Red;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Blue;
		break;

		case PIXFMT_BGR24:
			bm->data[pos] = bm->Blue;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Red;
		break;

		case PIXFMT_RGBA32:
			bm->data[pos] = bm->Red;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Blue;
			bm->data[pos + 3] = bm->Alpha;
		break;

		case PIXFMT_ARGB32:
			bm->data[pos] = bm->Alpha;
			bm->data[pos + 1] = bm->Red;
			bm->data[pos + 2] = bm->Green;
			bm->data[pos + 3] = bm->Blue;
		break;

		case PIXFMT_BGRA32:
			bm->data[pos] = bm->Blue;
			bm->data[pos + 1] = bm->Green;
			bm->data[pos + 2] = bm->Red;
			bm->data[pos + 3] = bm->Alpha;
		break;

		default:
			bm->data[pos] = bm->color;
	}


Das ist eigentlich schon der ganze Trick. Mit einer solchen Funktion, die einen Pixel in einem Pixelarray stetzt, kann man dann auch ganz leicht den Breseham für Linien und Kreise Programmieren.

--
http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 13.04.2008 um 11:30 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 11:50 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:

>Nach den Entwicklerunterlagen geht es auch mit CGFX-Bitmaps und
>bei 7.x sollte es auch mit P96-Bitmaps gehen.


Weder P96 noch AGA druckt hier, wenn man mit AllocBitmap
arbeietet. Also ob mit der norm. Dump Funktion noch mit der
Turboprint eigenen.


Dann erklär mir doch mal, wieso TP hier auf einem reinen P96-System (OS4) problemlos Grafiken druckt. Das geht auch ohne Mucken über die Hardcopy-Funktion, welche letztendlich eine Bitmap druckt, die per AllocBitMap angelegt wurde.

Letztendlich bleibt für mich da nur der Schluß, daß Du irgendwas verkehrt machst.

Zitat:
>Hast Du in den Printer-Preferences einen passenden Druckertreiber
>eingestellt?

Ähm, einige die passen könnten.

>Bei mir funktioniert es. Wenn es bei Dir nicht funktioniert,
>liegt es an Deinem System.

Ein direkten Treiber für mein Modell gibts nicht, ausser in TP.


Welches Modell ist das?

Und nochmal zum Problem "CGFX AGA": Wie kommst Du darauf, daß das nicht funktionieren würde? Du kannst auch unter CGFX AGA problemlos 24Bit-Bitmaps mittels AllocBitMap anlegen, sie sind nur nicht ohne weiteres darstellbar.

Das bedeutet, daß Du in diesem Fall die BitMap, in die Du hineinzeichnen willst, Offscreen anlegen mußt (ohne friend bitmap) und für die Ansicht auf dem Bildschirm per BltBitMap() o.Ä. in die sichtbare BitMap hineinblitten mußt (sieht dann aber nicht ganz so schön aus, weil kein großartiges Dithering stattfindet).

Das geht problemlos und Du kannst dann sogar via TP ohne weiteres drucken.

Nachteil dabei wäre dann nur, daß Du auch für AGA-Maschinen CGFX voraussetzen müßtest und das Ganze kein Geschwindigkeitswunder ist.

Wenn Du das nicht magst ist selbstmachen angesagt, was dann ein deutliches Mehr an Arbeit nach sich zieht.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 13:36 Uhr

MaikG
Posts: 5172
Nutzer
>Dann erklär mir doch mal, wieso TP hier auf einem reinen P96-System
>(OS4) problemlos Grafiken druckt.

Mit dem Graphic Publischer druckt TP hier auch.


>Das geht auch ohne Mucken über die Hardcopy-Funktion, welche
>letztendlich eine Bitmap druckt, die per AllocBitMap angelegt
>wurde.

TP überschreibt einen wert der von AllocBitmap angelegt
wurde. Bytes per Row, der beträgt unter CGX 41 oder 43.

Was natürlich falsch ist, aber vermutlich (u.a.) für die erkennung
bei TP erforderlich ist.

>Letztendlich bleibt für mich da nur der Schluß, daß Du irgendwas
>verkehrt machst.

Das will ich nicht ausschließen.


>Welches Modell ist das?

Ein 930er.


>Und nochmal zum Problem "CGFX AGA": Wie kommst Du darauf, daß das
>nicht funktionieren würde? Du kannst auch unter CGFX AGA problemlos
>24Bit-Bitmaps mittels AllocBitMap anlegen, sie sind nur nicht ohne
>weiteres darstellbar.

Ja, das dachte ich auch. Deswegen wollte ich erst wenigstens CGXAGA
unterstützen. Ebend mit der Farbreduzierung+Scalierung.
Was aber nur für die darstellung ist, für das Drucken wird
exakt der selbe code verwendet.


code:
printrp&=AllocVec&(RastPort_sizeof%, MEMF_CLEAR&)
  IF printrp& THEN
   InitRastPort printrp&
   bm&=NULL&                                       REM BMF_MINPLANES& (PIXFMT_ARGB32&<<24)
   bm& = AllocBitMap&(pwidth%+10, pheight%+10, 24,BMF_MINPLANES& OR BMF_SPECIALFMT& OR (PIXFMT_RGB24&<<24), NULL&) REM +10 sicherheitsraum
   IF bm& THEN 
    POKEL(printrp&+RastPortBitMap%),bm&


... malen etc.
Drucken:

FUNCTION dumpRP%(BYVAL rp&, BYVAL cm&, BYVAL modeID&, x%,y%,x1%,y1%)
	STATIC pmp&, pio&, sigfr&, r%, TPExtIODRP&

	dumpRP% = -1	'generic failure

	' Create private messageport
	pmp& = CreateMsgPort&()
		' Allocate Printer IO block
		pio& = CreateIORequest&(pmp&, IODRPReq_sizeof%)
			' Open the printer.device
			r% = OpenDevice&(SADD("printer.device" + CHR$(0)), 0, pio&, 0)
			IF r% = 0 THEN
				' Fill in the IODRPRequest
				POKEW pio& + IODRPReqio_Command%, PRD_DUMPRPORT&
				POKEL pio& + io_RastPort%, rp&
				POKEL pio& + io_ColorMap%, cm&  REM ohne cm& Hit vom Printer.device
				POKEL pio& + io_Modes%, modeID&
				POKEW pio& + io_SrcX%, x%
				POKEW pio& + io_SrcY%, y%
				POKEW pio& + io_SrcWidth%, x1%
				POKEW pio& + io_SrcHeight%, y1%

				POKEL pio& + io_DestCols%, 4000
				POKEL pio& + io_DestRows%, 4000
				POKEW pio& + io_Special%, SPECIAL_MILROWS& OR SPECIAL_MILCOLS&

SendIO pio&

				sigfr& = xWait&((1& << PEEKB(pmp& + mp_SigBit)))

				IF sigfr& AND (1& << PEEKB(pmp& + mp_SigBit%)) THEN
					' printer is either ready or an error has occurred

					WHILE GetMsg&(pmp&)
						' Remove any messages
					WEND
				END IF

				' Return error code (in this case we count user-abort as an error)
				dumpRP% = PEEKB(pio& + IODRPReqio_Error%)

				CloseDevice pio&
			ELSE
				dumpRP% = r%
			END IF
			DeleteIORequest& pio&
			DeleteMsgPort pmp&
END FUNCTION


[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 16:44 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Dann erklär mir doch mal, wieso TP hier auf einem reinen P96-System
>(OS4) problemlos Grafiken druckt.

Mit dem Graphic Publischer druckt TP hier auch.


>Das geht auch ohne Mucken über die Hardcopy-Funktion, welche
>letztendlich eine Bitmap druckt, die per AllocBitMap angelegt
>wurde.

TP überschreibt einen wert der von AllocBitmap angelegt
wurde. Bytes per Row, der beträgt unter CGX 41 oder 43.

Was natürlich falsch ist, aber vermutlich (u.a.) für die erkennung
bei TP erforderlich ist.


Hm, das kann ich mir nun beim besten Willen nicht vorstellen. TP müßte sich dazu in AllocBitMap() einhängen, aber wozu sollte das gut sein? CGFX-BitMaps sind an den BitMap-Attributen einwandfrei erkennbar (Pixelformat beispielsweise), es gibt gar keinen sinnvollen Grund, da irgend etwas in BytesPerRow einzucodieren.

Ich schätze, da schreibt Dein Programm in Bereiche, wo es nichts zu suchen hat bzw. es baut die BitMap nicht korrekt auf.

Zitat:
>Letztendlich bleibt für mich da nur der Schluß, daß Du irgendwas
>verkehrt machst.

Das will ich nicht ausschließen.


Ich auch nicht ;)

Zitat:
>Welches Modell ist das?

Ein 930er.


Sollte mit dem 9xx-Treiber von OS3.5+ funktionieren (970, glaube ich). Es gibt aber Unterschiede, Cx hatten die Teile glaube ich als "Anhang" der Typenbezeichnung, die anderen haben kein HP-PCL als "Sprache".

Zitat:
>Und nochmal zum Problem "CGFX AGA": Wie kommst Du darauf, daß das
>nicht funktionieren würde? Du kannst auch unter CGFX AGA problemlos
>24Bit-Bitmaps mittels AllocBitMap anlegen, sie sind nur nicht ohne
>weiteres darstellbar.

Zitat:
Ja, das dachte ich auch. Deswegen wollte ich erst wenigstens CGXAGA
unterstützen. Ebend mit der Farbreduzierung+Scalierung.
Was aber nur für die darstellung ist, für das Drucken wird
exakt der selbe code verwendet.



Ok, dann fang doch erst einmal mit der CGFX-Unterstützung an und bring das zum Laufen. Danach, also wenn das wenigstens prinzipiell tut, mach mit der Farbreduzierung & Skalierung weiter. Wenn das dann einwandfrei funktioniert, geh ans Drucken. Dazu suchst Du Dir einen Tester, der das in BASIC übersetzte NDK3.9-Beispiel antesten kann, wenn Dein Drucker mit den OS-Druckertreibern nicht mag. Das dient dann dazu, die Korrektheit Deiner BASIC-Includes und Strukturdefinitionen zu überprüfen. Wenn das funktioniert, gehts mit TP weiter.

Immer ein Schritt nach dem anderen...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 17:32 Uhr

MaikG
Posts: 5172
Nutzer
>Hm, das kann ich mir nun beim besten Willen nicht vorstellen.
>TP müßte sich dazu in AllocBitMap() einhängen, aber wozu sollte das
>gut sein? CGFX-BitMaps sind an den BitMap-Attributen einwandfrei
>erkennbar (Pixelformat beispielsweise), es gibt gar keinen
>sinnvollen Grund, da irgend etwas in BytesPerRow einzucodieren.

Ich meine das beispiel aus dem TP-Dev.
Nachdem Allocmem war schreibt es die BytesPerRow nach
3*widht. Nach dem Kommentaren tut es dies vermutlich in
jedem seiner Programme.


>Ich schätze, da schreibt Dein Programm in Bereiche, wo es nichts zu
>suchen hat bzw. es baut die BitMap nicht korrekt auf.

Der Source steht doch da, die Bitmap wird doch vom System
aufgebaut. Würde ich in Fremde bereiche schreiben, dann hätte
es einen Hit gegeben, spätestens hätte sich aber OS4 gemeldet.


>Sollte mit dem 9xx-Treiber von OS3.5+ funktionieren (970, glaube ich).
>Es gibt aber Unterschiede, Cx hatten die Teile glaube ich als
>"Anhang" der Typenbezeichnung, die anderen haben kein HP-PCL als
>"Sprache".

Ich habe sowohl die OS3.5+ als auch die aus dem Aminet durch.
Ausser das die Seite eingezogen wird und einige Hits von den
Treibern ist nichts passiert. Turboprint war deaktiv und als
Testprogramm habe ich Wordworth genommen.

>Ok, dann fang doch erst einmal mit der CGFX-Unterstützung an und
>bring das zum Laufen. Danach, also wenn das wenigstens prinzipiell
>tut, mach mit der Farbreduzierung & Skalierung weiter. Wenn das
>dann einwandfrei funktioniert,


Es Funktioniert alles fehlerfrei, bis auf AGA und P96.
Also das Drucken, die darstellung geht unter AGA+P96(letzteres bis auf Pens).



[ Dieser Beitrag wurde von MaikG am 13.04.2008 um 17:33 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 17:58 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von MaikG:

Nachdem Allocmem war schreibt es die BytesPerRow nach
3*widht. Nach dem Kommentaren tut es dies vermutlich in
jedem seiner Programme.


BytesPerRow = 3 * Width. Warum wohl? Denk mal darüber nach, was das zu bedeuten hat...

--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 18:33 Uhr

MaikG
Posts: 5172
Nutzer
>BytesPerRow = 3 * Width. Warum wohl? Denk mal darüber nach, was das zu bedeuten hat...

Du brauchst 3 Bytes bei RGB (RGB24) und die anzahl der Pixel
in einer Reihe nimmst du damit mal.
Bei CGX stehen da aber ganz andere Werte drin, deswegen schreibt
das Demo explizit 3*Width da rein.


Mache ich das in meinen Programm so, stürzt es ab weil CGX
auf seinen Wert angewiesen ist um auf dieser Bitmap zu Zeichnen.

Würde ich nicht Zeichnen müssen, könnte ich dafür dann drucken...

[ Dieser Beitrag wurde von MaikG am 13.04.2008 um 18:35 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 21:39 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>BytesPerRow = 3 * Width. Warum wohl? Denk mal darüber nach, was das zu bedeuten hat...

Du brauchst 3 Bytes bei RGB (RGB24) und die anzahl der Pixel
in einer Reihe nimmst du damit mal.
Bei CGX stehen da aber ganz andere Werte drin, deswegen schreibt
das Demo explizit 3*Width da rein.


Mache ich das in meinen Programm so, stürzt es ab weil CGX
auf seinen Wert angewiesen ist um auf dieser Bitmap zu Zeichnen.

Würde ich nicht Zeichnen müssen, könnte ich dafür dann drucken...


Also nochmal gaaaaaanz langsam:

Wenn Du ohne die Hilfe von CGFX/P96 24Bit-Grafiken erzeugen willst, mußt Du eigene Zeichenfunktionen schreiben, die z.B. innerhalb eines simplen Arrays zu 3 Byte pro (gedachtem) Pixel arbeiten. MadDog hat Dir schon ein gutes dutzend Beispiele dazu geliefert.

Wie Du mittels TurboPrint dieses Array als "getürkte" BitMap druckst, zeigt Dir das TP-Beispiel. Das macht nämlich nichts anderes, als das Array (alloziert per AllocMem() und über BytesPerRow = 3 * width als 24Bit/Pixel-BitMap definiert) in eine "struct BitMap" einzuhängen
C code:
InitBitMap(&MyBitMap,1,Width,Height);

 // now set the right BytesPerRow
 // we could have set it as 3*Width in InitBitMap but
 // InitBitMap sometimes calculates wrong BytesPerRow
 // so we do it on our own

 MyBitMap.BytesPerRow = 3*Width;

 if (MyBitMap.Planes[0]= (APTR)AllocMem(3*Width*Height,0))
 {
 MemPoint = (UBYTE*)MyBitMap.Planes[0];


und diese wiederum in eine "struct RastPort",
C code:
InitRastPort(&MyRastPort);
 MyRastPort.BitMap = &MyBitMap;


so daß sie per "PRD_TPEXTDUMPRPORT" (das Kommando setzt eine ausgefüllte "struct RastPort" als Parameter voraus) ausgedruckt werden kann.

Wie Du schon ganz richtig erkannt hast, unterscheidet sich so eine "BitMap" (die gar keine echte BitMap im Sinne des OS ist!) von einer vergleichbaren BitMap, wie sie AllocBitMap() mit CGFX-Patch anlegen würde. Ergo brauchst Du gar nicht weiter rumzulamentieren, Du kannst diese beiden Arten, eine Grafik zu erzeugen, nicht munter mischen. Entweder mit CGFX, dann aber auch mit den CGFX-Zeichenfunktionen, oder Selbstbau, dann aber auch mit Selbstbau-Zeichenfunktionen.

Das Zeichnen mit CGFX-Funktionen in eine handgestrickte BitMap und umgekehrt geht nicht ohne weiteres und erst Recht nicht ohne größeren Aufwand, Punkt.

Mittels CGFX kannst Du eine (ggf. unsichtbare) BitMap ganz normal per AllocBitMap() anlegen und auch auf den Bildschirm bringen. Ausdruck läuft ganz normal über PRD_DUMPRPORT, sowohl über printer.device V44 als auch TP ab Version 4. Wenn der Ausdruck einer solchen BitMap bei Dir nicht hinhaut, so machst Du etwas verkehrt, ganz simpel. Komplexere Zeichenfunktionen mußt Du Dir ggf. auch selbst bauen und kannst dazu WritePixel() als "Punktsetzer" benutzen (wenn auch reichlich ineffizient).

Und nochwas: Daß das printer.device V44-Beispiel für das Drucken über Hook bei Dir nicht funktioniert liegt schlicht daran, daß TP das Kommando nicht kennt und Dein Drucker nicht durch einen Treiber für das OS-printer.device unterstützt wird. So wie es aussieht, hast Du einen erwischt, der mit dem Treiber für die 970er-Reihe nicht funktioniert. Das ist dumm, aber nicht zu ändern und auch nicht die Schuld vom OS oder Irseesoft. Letztere haben erklärt, daß TurboPrint nicht mehr weiterentwickelt wird, somit wird es wohl auch keine Erweiterung des TP-printer.device zum Drucken über Hooks geben und Du mußt evtl. beim Druck zwischen TP und printer.device V44 unterscheiden. Punkt.

Wenn Du (ausnahmsweise mal) ganz lieb bittest, findet sich vielleicht jemand, der einen LIDIL-Treiber für Deinen 930er und OS3.5+ baut. Die Dokumentation dazu findet man in der HPLib, welche u.A. für GutenPrint verwendet wird. Wenn ich das richtig in Erinnerung habe, wird der simple 930er und einige andere Drucker dieser Serie per LIDIL gesteuert. Die Cx-Serie wird per PCL gesteuert, daher laufen die auch mit den meisten OS3.5+-Treibern (untereinander austauschbar bis zu einem gewissen Grad).

Und nochwas persönliches:

Mensch Maik, hör doch endlich einmal damit auf, Deinen Kopf durchsetzen zu wollen und nimm die Ratschläge an, die Dir gegeben werden. Zusätzlich solltest Du damit aufhören, Dein (in meinen Augen ziemlich verkorkstes) System als Maß aller Dinge hinzustellen. Das Drucken per printer.device V44 geht bestens, wenn man einen passenden Drucker hat und Hits schmeißen die Treiber auch eher selten (meist ist es die druckende Anwendung, die da fehlerhaft ist). Genauso funktioniert das Drucken per TP wunderbar, wenn man sich die Mühe macht, dessen Erweiterungen bzw. Kommandos zu verstehen.

Also, entscheide Dich für einen Weg (CGFX oder selbstgebastelte BitMap) und dann laß Dir dabei helfen, auf diesem Weg Ergebnisse zu bekommen, statt ständig herumzulamentieren und nur zu schreiben "das geht nicht". Bei allen anderen hier geht es nämlich, auf beiden Wegen, nur nicht bunt gemischt.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 21:48 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von MaikG:
Ich habe sowohl die OS3.5+ als auch die aus dem Aminet durch.
Ausser das die Seite eingezogen wird und einige Hits von den
Treibern ist nichts passiert. Turboprint war deaktiv und als
Testprogramm habe ich Wordworth genommen.


Druck doch einfach mal ein Bild mit MultiView aus. Das sollte eine einfache Hardcopy-Routine sein. Wordworth macht sein eigenes Ding und könnte einen Bug haben.

Tschüß



[ - Antworten - Zitieren - Direktlink - ]

13.04.2008, 23:22 Uhr

MaikG
Posts: 5172
Nutzer
>Wenn Du ohne die Hilfe von CGFX/P96 24Bit-Grafiken erzeugen willst,
>mußt Du eigene Zeichenfunktionen schreiben, die z.B. innerhalb
>eines simplen Arrays zu 3 Byte pro (gedachtem) Pixel arbeiten.

Hab ich schon kapiert.

>Wie Du mittels TurboPrint dieses Array als "getürkte" BitMap druckst,
>zeigt Dir das TP-Beispiel.

Ich weiss.


>Du kannst diese beiden Arten, eine Grafik zu erzeugen, nicht munter
>mischen. Entweder mit CGFX, dann aber auch mit den CGFX-Zeichenfunktionen,
>oder Selbstbau, dann aber auch mit Selbstbau-Zeichenfunktionen.

Will ich auch nicht. Der Selbstbau von Schrift ist aufwendig
und langsam. Per CGX kann ich das Text von der gfx Library verwenden.

CGXAGA wäre schonmal was, geht aber nicht.



>Mittels CGFX kannst Du eine (ggf. unsichtbare) BitMap ganz normal
>per AllocBitMap() anlegen und auch auf den Bildschirm bringen.
>Ausdruck läuft ganz normal über PRD_DUMPRPORT, sowohl über
>printer.device V44 als auch TP ab Version 4. Wenn der Ausdruck
>einer solchen BitMap bei Dir nicht hinhaut, so machst Du etwas
>verkehrt, ganz simpel.

Solange ein Grafikkarte im System ist, gibt es auch keine Probleme.
CGXAGA und P96 machen den Strich durch die Rechnung.


>und Du mußt evtl. beim Druck zwischen TP und
>printer.device V44 unterscheiden. Punkt.

Auch kein Problem, aber ich kann nicht testen ob diese
Hook Funktion irgendeinen vorteil bietet. Wer weiss vielleicht
kommt bei AGA und OS4 dann auch nur müll aus dem Drucker wie jetzt.


>Wenn Du (ausnahmsweise mal) ganz lieb bittest, findet sich
>vielleicht jemand, der einen LIDIL-Treiber für Deinen 930er
>und OS3.5+ baut.

Ich denke mal das ist ein risesen Aufwand und einer der den
Drucker nicht hat wird sich das kaum antun.


>Mensch Maik, hör doch endlich einmal damit auf, Deinen Kopf
>durchsetzen zu wollen und nimm die Ratschläge an, die Dir gegeben
>werden.


Wo ist das Problem dabei wenn ich manches aufgrund des Aufwands
bzw. da ich es selbst nicht testen kann einfach nicht machen möchte?



>Zusätzlich solltest Du damit aufhören, Dein (in meinen
>Augen ziemlich verkorkstes) System als Maß aller Dinge
>hinzustellen.

Mein System läuft, stürzt nicht ab und macht keine Hits.
Solange ich keine Buggy Soft Installiere.


>Das Drucken per printer.device V44 geht bestens,
>wenn man einen passenden Drucker hat

Hab ich aber nicht. Auch beim Drucker möchte ich gerne alleine
meine wahl treffen.


>und Hits schmeißen die Treiber
>auch eher selten (meist ist es die druckende Anwendung, die da
>fehlerhaft ist).

WW druckt mit Turboprint, als auch mit anderen WB Treibern ohne
Fehler.
Wenn der Treiber auch nur selten Hits von sich gibt ist der
Fehlerhaft.
Ich vermeide es sowas in meinem System zu haben.


>Also, entscheide Dich für einen Weg (CGFX oder selbstgebastelte
>BitMap) und dann laß Dir dabei helfen, auf diesem Weg Ergebnisse
>zu bekommen, statt ständig herumzulamentieren und nur zu schreiben
>"das geht nicht". Bei allen anderen hier geht es nämlich, auf
>beiden Wegen, nur nicht bunt gemischt.

Nicht mit meinem Drucker bzw. weise wurde gar nicht das
getestet was ich beschrieben habe.

[ - Antworten - Zitieren - Direktlink - ]

14.04.2008, 00:54 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von MaikG:
>Wenn Du ohne die Hilfe von CGFX/P96 24Bit-Grafiken erzeugen willst,
>mußt Du eigene Zeichenfunktionen schreiben, die z.B. innerhalb
>eines simplen Arrays zu 3 Byte pro (gedachtem) Pixel arbeiten.

Hab ich schon kapiert.


Offensichtlich nicht, da Du trotzdem versuchst, mittels CGFX in dieses Array zu zeichnen bzw. dieses Array an CGFX/graphics.library-Funktionen zu übergeben!

Zitat:
>Du kannst diese beiden Arten, eine Grafik zu erzeugen, nicht munter
>mischen. Entweder mit CGFX, dann aber auch mit den CGFX-Zeichenfunktionen,
>oder Selbstbau, dann aber auch mit Selbstbau-Zeichenfunktionen.

Will ich auch nicht. Der Selbstbau von Schrift ist aufwendig
und langsam. Per CGX kann ich das Text von der gfx Library verwenden.

CGXAGA wäre schonmal was, geht aber nicht.


Doch, das geht. Es geht bei Dir nicht, weil Du nicht verstehen willst, was man Dir sagt und Du auch keine Lust hast, die Dokumentation zu verstehen. Ein Tip: Vergiß dabei "friend BitMap"...

Zitat:
>Mittels CGFX kannst Du eine (ggf. unsichtbare) BitMap ganz normal
>per AllocBitMap() anlegen und auch auf den Bildschirm bringen.
>Ausdruck läuft ganz normal über PRD_DUMPRPORT, sowohl über
>printer.device V44 als auch TP ab Version 4. Wenn der Ausdruck
>einer solchen BitMap bei Dir nicht hinhaut, so machst Du etwas
>verkehrt, ganz simpel.

Solange ein Grafikkarte im System ist, gibt es auch keine Probleme.
CGXAGA und P96 machen den Strich durch die Rechnung.


Nein, das machst Du selbst, weil Du nicht zuhörst.

Zitat:
>und Du mußt evtl. beim Druck zwischen TP und
>printer.device V44 unterscheiden. Punkt.

Auch kein Problem, aber ich kann nicht testen ob diese
Hook Funktion irgendeinen vorteil bietet. Wer weiss vielleicht
kommt bei AGA und OS4 dann auch nur müll aus dem Drucker wie jetzt.


Wieder ein Beispiel dafür, daß Du nicht zuhörst. Das Hook-Beispiel funktioniert einwandfrei bei passendem Drucker bzw. Treiber. Das kannst Du sowohl NoImag als auch mir glauben und es geht sogar unter OS4 und über USB. Wenn es bei Dir nicht funktioniert, machst DU etwas verkehrt bzw. Du hast halt keinen passenden Drucker/Treiber. Ist das so schwer zu kapieren?

Das Drucken über Hook bietet Dir u.A. den Vorteil, daß Du die interne Aufbereitung der Druckdaten (z.B. Konvertierung des 24Bit-Arrays in ein passendes Format) zeilenweise selbst vornehmen kannst. Damit bist Du nicht auf z.B. CGFX-BitMaps angewiesen sondern kannst z.B. die Daten direkt aus einem Array im FastRAM beziehen, welches Du selbst aufbereitet hast. U.A. könntest Du damit auch einen Alpha-Kanal in Deine Grafiken mit einbeziehen, was unter OS3.x vom OS nicht für die Zeichenfunktionen bereitgestellt wird.

Zitat:
>Wenn Du (ausnahmsweise mal) ganz lieb bittest, findet sich
>vielleicht jemand, der einen LIDIL-Treiber für Deinen 930er
>und OS3.5+ baut.

Ich denke mal das ist ein risesen Aufwand und einer der den
Drucker nicht hat wird sich das kaum antun.


Du hast es ja nicht einmal versucht zu fragen...

Zitat:
>Mensch Maik, hör doch endlich einmal damit auf, Deinen Kopf
>durchsetzen zu wollen und nimm die Ratschläge an, die Dir gegeben
>werden.

Wo ist das Problem dabei wenn ich manches aufgrund des Aufwands
bzw. da ich es selbst nicht testen kann einfach nicht machen möchte?


Dann mach doch nicht so einen Aufstand darum, akzeptiere einfach, daß manches nicht so möglich ist, wie Du es gern hättest und lerne, anderen einfach mal zu vertrauen und zu verstehen, was sie Dir sagen.
Die Sache mit dem TP-Beispiel zeigt doch schon, daß Du einfach nicht zuhörst. Dieses Beispiel zeigt, wie man eine handgestrickte BitMap an TP durchreicht, damit dieses diese Pseudo-BitMap (nach Angabe des Pixelformats!) ausdrucken kann, nichts anderes. Da steht nirgendwo, daß eine derart aufbereitete BitMap dafür geeignet ist, daß Du mittels CGFX und/oder den Funktionen der graphics.library darin herumpfuschen kannst!

Zitat:
>Zusätzlich solltest Du damit aufhören, Dein (in meinen
>Augen ziemlich verkorkstes) System als Maß aller Dinge
>hinzustellen.

Mein System läuft, stürzt nicht ab und macht keine Hits.
Solange ich keine Buggy Soft Installiere.


Das hatten wir schon mal... daß ein System, sei es auch zutiefst verbugt, nicht unbedingt Hits auswerfen muß ist so ziemlich jedem bekannt, nur Dir nicht.

Gehe einfach mal davon aus, daß ein Hit nicht unbedingt von dem Programm stammen muß, daß ihn scheinbar erzeugt.

Zitat:
>Das Drucken per printer.device V44 geht bestens,
>wenn man einen passenden Drucker hat

Hab ich aber nicht. Auch beim Drucker möchte ich gerne alleine
meine wahl treffen.


Wo liegt das Problem? Du kannst da ja wählen, aber Du solltest Dir dann endlich mal klar darüber werden, auf welchem Weg Du die Grafikdaten aufbereiten willst und Dir dann auch darüber klar werden, wie das tatsächlich funktioniert. CGFX AGA kann durchaus 24Bit-BitMaps erzeugen und sie sogar (wenn auch ohne Dithering) darstellen. Du solltest Dich aber darüber informieren, wie das tatsächlich geht und nicht einfach davon ausgehen, daß Du keine Fehler machst sondern nur die anderen und im Zweifel immer das OS.

So weit bist Du mit Deinen Programmierkünsten noch längst nicht.

Zitat:
>und Hits schmeißen die Treiber
>auch eher selten (meist ist es die druckende Anwendung, die da
>fehlerhaft ist).

WW druckt mit Turboprint, als auch mit anderen WB Treibern ohne
Fehler.


Ja, das tuts hier auch. Sogar mit den OS3.5-Treibern. Und?

Zitat:
Wenn der Treiber auch nur selten Hits von sich gibt ist der
Fehlerhaft.


Oder das Programm, das ausdruckt.

Zitat:
>Also, entscheide Dich für einen Weg (CGFX oder selbstgebastelte
>BitMap) und dann laß Dir dabei helfen, auf diesem Weg Ergebnisse
>zu bekommen, statt ständig herumzulamentieren und nur zu schreiben
>"das geht nicht". Bei allen anderen hier geht es nämlich, auf
>beiden Wegen, nur nicht bunt gemischt.

Nicht mit meinem Drucker bzw. weise wurde gar nicht das
getestet was ich beschrieben habe.


Was wurde nicht getestet? In einem simplen Array mit CGFX-Funktionen herummalen? Natürlich wurde das nicht getestet, weil das nicht funktioniert (nicht funktionieren kann). Alles andere wurde lange vor Dir getestet und funktioniert. Sogar das TP-Beispiel für selbstgebaute Bitmaps funktioniert problemlos, und das unter OS4...

--
---

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


[ Dieser Beitrag wurde von whose am 14.04.2008 um 01:01 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.04.2008, 06:27 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von whose:
Zitat:
Original von MaikG:
>Wenn Du ohne die Hilfe von CGFX/P96 24Bit-Grafiken erzeugen willst,
>mußt Du eigene Zeichenfunktionen schreiben, die z.B. innerhalb
>eines simplen Arrays zu 3 Byte pro (gedachtem) Pixel arbeiten.

Hab ich schon kapiert.


Offensichtlich nicht, da Du trotzdem versuchst, mittels CGFX in dieses Array zu zeichnen bzw. dieses Array an CGFX/graphics.library-Funktionen zu übergeben!


Vorsicht! Eine CybergraphX-Funktion gibt es doch, an die solch ein Pixel-Array übergeben werden kann/soll, nämlich WritePixelArray().
Das habe ich auch in dem Demoprogramm zu meiner 24 Bit Version des Bresenham so gemacht, um dieses selbstgestrickte Array dann auf den RastPort eines Fensters zu bekommen.

Hier nochmal der Link zum Archiv:

bresenham24.lha

Und hier mal der Sourcecode des Demoprogramms:
c code:
/*
 * Bresehnah_Demo
 *
 * Demoprogramm für Bresenham-Algorithmus
 *
 * Autor: Norman Walter
 * Datum: 5.4.2008
 *
 */

#include <stdlib.h>

#include <pragma/cybergraphics_lib.h>

#include <cybergraphx/cybergraphics.h>

#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/intuition.h>
#include <proto/graphics.h>

#include "bresenham.h"
#include "Polygon.h"

#define BMWIDTH 256
#define BMHEIGHT 256

struct Library *CyberGfxBase;

// Funktion zum Zeichnen des Sierpinski-Fraktals
void DrawSierpinski(struct raster_bitmap *bm)
{
	int iterate;
   SHORT x1, y1, x2, y2;

   x1 = x2 = bm->width/2;
   y1 = y2 = 0;

   // Schleife zum Iterieren und Zeichnen der Pixel
   for(iterate = 0; iterate < 10000; iterate++)
   {
      // Zufallswerte erzeugen/
      switch (rand()%3)
      {
         case 0: x1 = (x2 + bm->width/2) / 2;
                 y1 = y2 / 2;
         break;

         case 1: x1 = x2 / 2;
                 y1 = (y2 + bm->height) / 2;
         break;

         case 2: x1 = (x2 + bm->width) / 2;
                 y1 = (y2 + bm->height) / 2;
         break;
      }

      setpixel(bm, x1, y1);

      x2 = x1;
      y2 = y1;
   }

}

int main (void)
{
	struct Window *win;
	struct Message *msg;

	int i;
	ULONG x,y;

	struct raster_bitmap *bm24;

   CyberGfxBase = OpenLibrary(CYBERGFXNAME,41L);

	bm24 = AllocRasterBitmap(BMWIDTH,BMHEIGHT,PIXFMT_RGB24);

	if (win = OpenWindowTags (NULL,
		WA_Title,"Bresenham",
		WA_InnerWidth,BMWIDTH,
		WA_InnerHeight,BMHEIGHT,
		WA_Flags,WFLG_CLOSEGADGET|WFLG_DRAGBAR|WFLG_DEPTHGADGET|WFLG_ACTIVATE,
		WA_IDCMP,IDCMP_CLOSEWINDOW|IDCMP_MOUSEBUTTONS|IDCMP_VANILLAKEY,
		TAG_END))
	{

	SetColorRGBA(bm24,0xFF,0xFF,0xFF,0xFF);
	DrawSierpinski(bm24);

	WritePixelArray(bm24->data, 0, 0,
						 bm24->BytesPerRow,
						 win->RPort,
						 win->BorderLeft,
						 win->BorderTop,
						 BMWIDTH,BMHEIGHT,
						 RECTFMT_RGB);

	Delay(250);

		for (i=0; i<256; i+=32)
		{
			SetColorRGBA(bm24,i%128,i%64,i,0xFF);
			ClearRaster(bm24);

	WritePixelArray(bm24->data, 0, 0,
						 bm24->BytesPerRow,
						 win->RPort,
						 win->BorderLeft,
						 win->BorderTop,
						 BMWIDTH,BMHEIGHT,
						 RECTFMT_RGB);
		}

			SetColorRGBA(bm24,0,0,0,0xFF);
			ClearRaster(bm24);

      SetColorRGBA(bm24,0xFF,0x00,0x00,0xFF);
		ZeichnePolygon(bm24,3,40,128,128);
		SetColorRGBA(bm24,0x00,0xFF,0x00,0xFF);
		ZeichnePolygon(bm24,4,60,128,128);
		SetColorRGBA(bm24,0xFF,0x00,0xFF,0xFF);;
		ZeichnePolygon(bm24,5,80,128,128);
		SetColorRGBA(bm24,0xFF,0xFF,0x00,0xFF);
		ZeichnePolygon(bm24,6,100,128,128);
		SetColorRGBA(bm24,0x00,0xFF,0xFF,0xFF);
		ZeichnePolygon(bm24,7,120,128,128);
		SetColorRGBA(bm24,0x00,0x55,0xFF,0xFF);
		ZeichnePolygon(bm24,8,140,128,128);

	WritePixelArray(bm24->data, 0, 0,
						 bm24->BytesPerRow,
						 win->RPort,
						 win->BorderLeft,
						 win->BorderTop,
						 BMWIDTH,BMHEIGHT,
						 RECTFMT_RGB);

		Delay(250);

		SetColorRGBA(bm24,0xFF,0xFF,0xFF,0xFF);
      ClearRaster(bm24);

		for (y=0; y < bm24->height; y++)
		{
			for (x=0; x < bm24->width; x++)
			{
				SetColorRGBA(bm24,(UBYTE)x,(UBYTE)y,0,0xFF);
				setpixel(bm24,x,y);
			}
		}

	WritePixelArray(bm24->data, 0, 0,
						 bm24->BytesPerRow,
						 win->RPort,
						 win->BorderLeft,
						 win->BorderTop,
						 BMWIDTH,BMHEIGHT,
						 RECTFMT_RGB);


		Delay(250);

		SetColorRGBA(bm24,0xFF,0xFF,0xFF,0xFF);
      ClearRaster(bm24);

		for (i=2; i<=160; i+=4)
		{
		   SetColorRGBA(bm24,i,i,0,0xFF);
			rasterCircle(bm24,bm24->width/2,bm24->height/2,i);
		}

	WritePixelArray(bm24->data, 0, 0,
						 bm24->BytesPerRow,
						 win->RPort,
						 win->BorderLeft,
						 win->BorderTop,
						 BMWIDTH,BMHEIGHT,
						 RECTFMT_RGB);

	WaitPort (win->UserPort);

	while (msg = GetMsg (win->UserPort))
		ReplyMsg (msg);

	CloseWindow (win);

	FreeRasterBitmap(bm24);

	if (CyberGfxBase != NULL)
	{
		CloseLibrary(CyberGfxBase);
	}

	}

return (0);
}


Vorsicht bei dieser Zeile:
c code:
bm24 = AllocRasterBitmap(BMWIDTH,BMHEIGHT,PIXFMT_RGB24);


Diese Funktion Namens AllocRasterBitmap() ist keine AmigaOS oder Cybergraphx-Funktion, sondern eine Funktion aus meinem eigenen Include "bresenham.c":
c code:
struct raster_bitmap * AllocRasterBitmap(unsigned int width, unsigned int height, ULONG PixFmt)
{
   struct raster_bitmap *bm;

   bm = (struct raster_bitmap *)AllocVec(sizeof(struct raster_bitmap),NULL);

   bm->width = width;
   bm->height = height;
   bm->PixFmt = PixFmt;

   switch (PixFmt)
   {
	case PIXFMT_RGB24:
	case PIXFMT_BGR24:
		bm->Depth = 24;
		bm->BytesPerPixel = 3;
	break;

	case PIXFMT_ARGB32:
	case PIXFMT_BGRA32:
	case PIXFMT_RGBA32:
		bm->Depth = 32;
		bm->BytesPerPixel = 4;
	break;

	default:
		bm->Depth = 8;
		bm->BytesPerPixel = 1;		
   }

   bm->BytesPerRow = bm->width * bm->BytesPerPixel;
   bm->size = bm->BytesPerRow * bm->height;
   bm->color = 1;

   // RGBA-Komponenten für die Zeichenfarbe setzen
   bm->Alpha = 0xFF;
   bm->Red = 0xFF;
   bm->Green = 0xFF;
   bm->Blue = 0xFF;

   bm->data = (UBYTE *)AllocVec(bm->size, MEMF_CLEAR);

   return bm;
}


Und raster_bitmap ist auch keine AmigaOS- oder CybergraphX-Struktur, sondern ebenfalls was selbstgestricktes, definiert in meinem Include bresenham.h:
c code:
struct raster_bitmap
{
  unsigned int width;   // Breite des Bitmaps
  unsigned int height;  // Höhe des Bitmaps
  UBYTE Depth;		// Farbtiefe in Bit
  ULONG PixFmt;		// Das Pixelformat (RGB, ARGB...)
  UBYTE BytesPerPixel;  // Bytes pro Pixel
  ULONG BytesPerRow;	// Bytes pro Zeile des Bitmaps
  UBYTE color;          // Aktuelle Pen Nummer
  UBYTE Alpha;		// Alpha der Zeichenfarbe
  UBYTE Red;		// Rotanteil der Zeichenfarbe
  UBYTE Green;		// Grünanteil der Zeichenfarbe
  UBYTE Blue;		// Blauanteil der Zeichenfarbe
  ULONG size;           // Größe des bitmapy in Byte
  UBYTE *data;          // Bilddaten des Bitmaps
};


Der Zeiger data zeigt nach Aufruf von AllocRasterBitmap() auf die Speicherstelle, wo das Pixel-Array anfängt. Dieser Zeiger ist es auch, der im Demoprogramm der Cybergraphx-Funktion WritePixelArray() übergeben wird:
c code:
WritePixelArray(bm24->data, 0, 0,
        	bm24->BytesPerRow,
		win->RPort,
		win->BorderLeft,
		win->BorderTop,
		BMWIDTH,BMHEIGHT,
		RECTFMT_RGB);

--
http://www.norman-interactive.com


[ Dieser Beitrag wurde von Mad_Dog am 14.04.2008 um 06:36 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.04.2008, 07:14 Uhr

Mad_Dog
Posts: 1944
Nutzer
Um nochmal darauf einzugehen, wie man einen Pixel innerhalb eines Pixel-Arrays setzt, hier man ein praktisches Beispiel:

Gegeben sei folgende 16 x 14 Matrix:

Bild: http://w3.norman-interactive.com/C-Kurs/Ufo-Matrix.png

Diese Grafik hat 2 Dimensionen: Höhe und Breite, ein Pixel-Array hat aber nur eine Dimension. D.h. in einem Pixel-Array sind einfach die Werte der Spalten der Matrix aneinandergereiht.

Wenn wir die obige Matrix in einem 24 Bit (RGB) Pixel Array darstellen wollen, dann sähe die erste Spalte wie folgt aus:

code:
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,255,255,255,255,255,255,255,255,255,255,255,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0


Die Folge

code:
255,255,255,255,255,255,255,255,255,255,255,255


repräsentiert dabei die 4 weißen Pixel dieser Spalte - die Restlichen Pixel sind Schwarz (0,0,0).

O.k., schauen wir uns mal genauer an, an welcher Position innerhalb des Pixel-Arrays die RGB-Werte des ersten, weißen Pixels zu finden sind:

Die Koordinaten dieses Pixels innerhalb der Matrix sind 6/0, also x=6 und y=0. D.h. 1. Spalte, 7. Pixel.

In meiner Funktion setpixel aus bresenham.c habe ich die Position, an der die RGB-Werte einer Matrix innerhalb eines Pixel-Arrays anfangen, wie folgt berechnet:

code:
ULONG pos = (bm->width * y + x) * bm->BytesPerPixel;


Also in unserem Fall: (16 * 0 + 6) * 3 = 18

D.h. die RGB-Werte für den ersten, weißen Pixel aus unserer Beispielgrafik fangen an Position 18 des Pixel-Arrays an. Wenn man das in obigem Beispiel nachprüft, wird man sehen, daß nach 17 Nullen das erste mal an Position 18 der Wert 255 kommt. Dies ist die Rot-Komponente des ersten Pixels.

code:
bm->data[pos] = bm->Red;


Die Grün-Komponente kommt eine Position danach:

code:
bm->data[pos + 1] = bm->Green;


Und die Blau-Komponente kommt 2 Positionen nach pos:

code:
bm->data[pos + 2] = bm->Blue;


Ich hoffe, daß es damit endgültig klar ist, wie das funktioniert?

--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

14.04.2008, 10:09 Uhr

MaikG
Posts: 5172
Nutzer
>Offensichtlich nicht, da Du trotzdem versuchst, mittels CGFX in
>dieses Array zu zeichnen bzw. dieses Array an CGFX/graphics.library-Funktionen
>zu übergeben!

Ich Zeichne mit CGX in einem Rastport und nicht in ein Array.


>Doch, das geht. Es geht bei Dir nicht, weil Du nicht verstehen
>willst, was man Dir sagt und Du auch keine Lust hast, die
>Dokumentation zu verstehen. Ein Tip: Vergiß dabei "friend BitMap"...

Wenn du meinen Code gelesen hättest, wüsstest du das ich friend BitMap
überhaupt nicht angegeben habe.


>Wieder ein Beispiel dafür, daß Du nicht zuhörst. Das Hook-Beispiel
>funktioniert einwandfrei bei passendem Drucker bzw. Treiber.
>Das kannst Du sowohl NoImag als auch mir glauben und es geht
>sogar unter OS4 und über USB. Wenn es bei Dir nicht funktioniert,
>machst DU etwas verkehrt bzw. Du hast halt keinen passenden
>Drucker/Treiber. Ist das so schwer zu kapieren?

Ist es so schwer zu verstehen das ich nichts auf gut glück
Programmiere? Ich weiss nicht ob der aus dem C Übersetzte Code
geht, ich weiss nicht ob dieser Code unter allen möglichen Umständen
geht.
Was ich weiss, wenn ich das so raussgebe und es Funktioniert
nicht bekomme ich sinnlose Bugreports. Ala "Da steht OS3.5-OS4 in der
Anleitung bei mir gehts aber nicht.



>Du hast es ja nicht einmal versucht zu fragen...


Ich bin pessimist.



>Dann mach doch nicht so einen Aufstand darum, akzeptiere einfach,
>daß manches nicht so möglich ist, wie Du es gern hättest und lerne,
>anderen einfach mal zu vertrauen und zu verstehen, was sie Dir sagen.

Ich mach kein Aufstand, ich beantworte nur was andere schreiben.
Wenns nicht geht, gehts halt nicht.


>Die Sache mit dem TP-Beispiel zeigt doch schon, daß Du einfach nicht
>zuhörst. Dieses Beispiel zeigt, wie man eine handgestrickte BitMap
>an TP durchreicht, damit dieses diese Pseudo-BitMap (nach Angabe des
>Pixelformats!) ausdrucken kann, nichts anderes. Da steht nirgendwo,
>daß eine derart aufbereitete BitMap dafür geeignet ist, daß Du
>mittels CGFX und/oder den Funktionen der graphics.library darin
>herumpfuschen kannst!


Das Demo war klein genug damit ich es vollständig verstehen
konnte.
Es war nie die rede davon das ich das demo dahingehend ändern möchte.
Ich habs nur probiert die art zu verwenden und es hat halt nicht
funktioniert - na und hab ich halt Zeit verschwendet.


>Gehe einfach mal davon aus, daß ein Hit nicht unbedingt von dem
>Programm stammen muß, daß ihn scheinbar erzeugt.

Klar das kommt vor, wenn man z.B. irgendein Library mit etwas
füttert was nicht erlaubt ist.
WW7 ist trotzdem sauber.


>Wo liegt das Problem? Du kannst da ja wählen, aber Du solltest Dir
>dann endlich mal klar darüber werden, auf welchem Weg Du die
>Grafikdaten aufbereiten willst und Dir dann auch darüber klar
>werden, wie das tatsächlich funktioniert. CGFX AGA kann durchaus
>24Bit-BitMaps erzeugen und sie sogar (wenn auch ohne Dithering)
>darstellen. Du solltest Dich aber darüber informieren, wie das
>tatsächlich geht und nicht einfach davon ausgehen, daß Du keine
>Fehler machst sondern nur die anderen und im Zweifel immer das OS.

Ich will es so machen wie es jetzt ist.
AllocBitmap, Zeichnen mit CGX, Text mit graphics.
Das war schon immer so, ich zog nur alternativen in betracht.

Bei CGXAGA kommt auch eine Bitmap zurück, alle Zeichenoperationen
funktionieren. Aber es kommt ein rein schwarzes Bild aus dem Drucker.

Klar kann es sein das ich was falsch mache, den Code habe ich
gepostet. Bissher hatte daran keiner etwas auszusetzen.



>Vorsicht! Eine CybergraphX-Funktion gibt es doch, an die solch ein
>Pixel-Array übergeben werden kann/soll, nämlich WritePixelArray().
>Das habe ich auch in dem Demoprogramm zu meiner 24 Bit Version
>des Bresenham so gemacht, um dieses selbstgestrickte Array dann auf
>den RastPort eines Fensters zu bekommen.


Ich arbeite ja mit einer Bitmap.


[ - Antworten - Zitieren - Direktlink - ]

15.04.2008, 00:37 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von MaikG:
Klar kann es sein das ich was falsch mache, den Code habe ich
gepostet. Bissher hatte daran keiner etwas auszusetzen.


Dein Code ist unvollständig. Du gibst nirgendwo an, was die Parameter zum Drucken enthalten. Was gibst Du für die Colormap an? Du sagst, das Zeichnen unter CGFXAGA funktioniert. Heißt das, Du siehst auf dem Bildschirm das korrekte Resultat?

Tschüß





[ - Antworten - Zitieren - Direktlink - ]

15.04.2008, 09:52 Uhr

MaikG
Posts: 5172
Nutzer
>Dein Code ist unvollständig. Du gibst nirgendwo an, was die
>Parameter zum Drucken enthalten. Was gibst Du für die Colormap an?

Die Colormap ist die von der Workbench, ModeID ist NULL.

Dazwischen stell dir einfach ein writetrgbpixel an 10,10 mit 0x00550000
vor.
Das Zeichnen wird kontrolliert, es kann also nicht negativ oder
positiv über die Bitmap hinaus.


>Du sagst, das Zeichnen unter CGFXAGA funktioniert. Heißt das, Du
>siehst auf dem Bildschirm das korrekte Resultat?

Ich sehe das 100% korrekte Resultat.

Auch bei P96, wobei Text aber grundsätzlich schwarz ist, sowohl
auf UAE, als auch auf OS4.

[ - Antworten - Zitieren - Direktlink - ]

16.04.2008, 00:27 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von MaikG:
>Dein Code ist unvollständig. Du gibst nirgendwo an, was die
>Parameter zum Drucken enthalten. Was gibst Du für die Colormap an?

Die Colormap ist die von der Workbench, ModeID ist NULL.


Gebe doch mal was vernünftiges für die ModeID an, z.B. die ModeID der Workbench.

Zitat:
>Du sagst, das Zeichnen unter CGFXAGA funktioniert. Heißt das, Du
>siehst auf dem Bildschirm das korrekte Resultat?

Ich sehe das 100% korrekte Resultat.

Auch bei P96, wobei Text aber grundsätzlich schwarz ist, sowohl
auf UAE, als auch auf OS4.


OK, aber unter AGA ist doch eine 24-Bit-Bitmap nicht darstellbar. Kopierst Du Deine Grafik in ein Fenster oder hast Du nur die Zeichenoperationen als solches getestet?

Tschüß



[ - Antworten - Zitieren - Direktlink - ]

16.04.2008, 10:01 Uhr

MaikG
Posts: 5172
Nutzer
>Gebe doch mal was vernünftiges für die ModeID an, z.B. die ModeID
>der Workbench.

Und wenn die Workbench grade 4 Farben hat? Das bringt bestimmt
nichts gutes.



>OK, aber unter AGA ist doch eine 24-Bit-Bitmap nicht darstellbar.
>Kopierst Du Deine Grafik in ein Fenster oder hast Du nur die
>Zeichenoperationen als solches getestet?


Ich hab doch eine Farbneuberechnung incl. Scalierung geschrieben.

[ - Antworten - Zitieren - Direktlink - ]

16.04.2008, 22:23 Uhr

NoImag
Posts: 1050
Nutzer
Zitat:
Original von MaikG:
>Gebe doch mal was vernünftiges für die ModeID an, z.B. die ModeID
>der Workbench.

Und wenn die Workbench grade 4 Farben hat? Das bringt bestimmt
nichts gutes.


Die ModeID hat nicht direkt etwas mit der Farbanzahl zu tun. Alle AGA-Modi gibt es von 1 bis 8 Bit. Laut RKRM wird die ModeID nur für das richtige Aspectverhältnis ausgewertet. Das kann man zwar auch anders angeben, ich habe aber nirgendwo eine Bemerkung gefunden, dass man die ModeID einfach auf 0 setzen darf.

Zitat:
>OK, aber unter AGA ist doch eine 24-Bit-Bitmap nicht darstellbar.
>Kopierst Du Deine Grafik in ein Fenster oder hast Du nur die
>Zeichenoperationen als solches getestet?

Ich hab doch eine Farbneuberechnung incl. Scalierung geschrieben.


OK.

Tschüß



[ - Antworten - Zitieren - Direktlink - ]

17.04.2008, 09:54 Uhr

MaikG
Posts: 5172
Nutzer
>Das kann man zwar auch anders angeben, ich habe aber nirgendwo
>eine Bemerkung gefunden, dass man die ModeID einfach auf 0 setzen
>darf.

ModeID ist ein neuer Parameter und müsste gar nicht übergeben werden.
Aber ich probiere es heute mal.

[ - Antworten - Zitieren - Direktlink - ]

17.04.2008, 11:25 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von NoImag:
Laut RKRM wird die ModeID nur für das richtige Aspectverhältnis ausgewertet. Das kann man zwar auch anders angeben, ich habe aber nirgendwo eine Bemerkung gefunden, dass man die ModeID einfach auf 0 setzen darf.

Wenn der erste Satz stimmt, dann sollte 0 kein Problem darstellen. 0 ist aufgrund der Altlasten eine gültige ID und bedeutet LoRes, also ~4:3, je nach System PAL oder NTSC, da keine Monitor-ID enthalten ist.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

17.04.2008, 18:57 Uhr

MaikG
Posts: 5172
Nutzer
Die Angabe der ModeID macht keinen Unterschied.

[ - Antworten - Zitieren - Direktlink - ]


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


amiga-news.de Forum > Programmierung > Kreis Zeichnen ohne graphics.library [ - Suche - Neue Beiträge - Registrieren - Login - ]


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