Rastport ohne Fenster? - amiga-news.de Forum

amiga-news.de Forum > Programmierung > Rastport ohne Fenster?

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

17.03.2008, 15:23 Uhr

MaikG
Posts: 5172
Nutzer

Ich wollte mal mit Drucken experimentieren.
Wie man den Rastport druckt und etwas auf diesem ausgibt weiss
ich.
Bei AGA hat man ein max. Screen von 1280x512, auf dem Drucker
sieht das trotzdem noch kantig aus. Kann ich irgendwie
ein Rastport machen auf den ich zwar zeichnen kann, welcher
aber viel größer ist?

[ - Antworten - Zitieren - Direktlink - ]

17.03.2008, 15:49 Uhr

thomas
Posts: 7718
Nutzer

Ein RastPort hat keine Größe. Die Größe des Zeichenbereichs wird durch die Bitmap bestimmt. Und natürlich kannst du eine Bitmap so groß anlegen, wie es dein Speicher erlaubt. Mit Screens hat das überhaupt nichts zu tun.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

17.03.2008, 16:28 Uhr

MaikG
Posts: 5172
Nutzer

Also lege ich eine Bitmap an, sagen wir 3200x2000x8 oder evtl. x16.
Dann bekomme ich den Rastport durch bitmap->rport?
Und kann ich drauf Zeichnen und den ans printer.device schicken.
Gibt es da irgendwelche Einschränkungen weil pre OS3.5 war die
Farbtiefe doch irgendwie begrenzt?

[ - Antworten - Zitieren - Direktlink - ]

17.03.2008, 16:40 Uhr

geit
Posts: 332
[Ex-Mitglied]

Zitat:
Original von MaikG:
Also lege ich eine Bitmap an, sagen wir 3200x2000x8 oder evtl. x16.
Dann bekomme ich den Rastport durch bitmap->rport?

Nein umgekehrt. Du allokierst eine Rastport-Struktur, rufst InitRPort() auf und dann
trägst Du den Pointer Deiner Bitmap in den Rastport ein.

Dann kannst Du in dem RastPort rum malen.

Geit

[ - Antworten - Zitieren - Direktlink - ]

17.03.2008, 23:46 Uhr

MaikG
Posts: 5172
Nutzer

Also prinzipell so:

code:

rp&=AllocRaster&(3000,2000)
IF rp& THEN
 InitRastPort rp&
 bm& = AllocBitMap&(3000, 2000, 8, BMF_CLEAR&, NULL&)
 IF bm& THEN 
  POKEL(rp&+RastPortBitMap%),bm&
  WaitBlit
  delay 50
  FreeBitMap bm&
  ELSE PRINT "bitmap fail"
 END IF
 FreeRaster& rp&,3000,2000
ELSE PRINT "raster fail"
END IF

Klappt aber nicht. Es wird versucht Chipmem zu verwenden und
das reicht dafür natürlich nicht.

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 00:16 Uhr

NoImag
Posts: 1050
Nutzer

@MaikG:

AllocRaster() alloziert keinen Rastport sondern eine Bitplane. Du musst ganz einfach Speicher in der Größe der Rastportstruktur anfordern, so wie man das immer bei Betriebssystemstrukturen macht. ChipMem ist nicht notwendig. Diesen Speicherbereich übergibst Du an InitRastport(). Das WaitBlit() ist an der Stelle überflüssig. Das brauchst Du nur nach Grafikoperationen, in der Regel erst direkt vor FreeBitMap(), in Deinem Anwendungsfall vor dem Drucken.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 10:41 Uhr

Der_Wanderer
Posts: 1229
Nutzer

Am besten, du macht auch gleich einen layer drüber, sonst wird jedes über-die-grenzen malen böse bestraft:

Hier der Code, wie ich es in Amiblitz3 mache:
(in dem Fall ARGB 32-bit Bitmap)

code:

bitmap_ptr = AllocBitMap_(img_width,img_height,24,#BMF_MINPLANES|#BMF_SPECIALFMT|#F_ARGB32,0)

If bitmap_ptr
  layerinfo_ptr = NewLayerInfo_
  If layerinfo_ptr
    layer_ptr    =  CreateUpfrontHookLayer_ (layerinfo_ptr,bitmap_ptr,0,0,width-1,height-1,0,#LAYERS_NOBACKFILL,0)
    If layer_ptr
      rastport_ptr = layer_ptrrp
    Else
      error{"\__THIS_FUNCTION: Unable to create upfront layer!"}
    End If
  Else
    error{"\__THIS_FUNCTION : Unable to allocate LayerInfo!"}
  End If
Else
   error{"\__THIS_FUNCTION : Unable to allocate bitmap!"}
End If

--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 11:08 Uhr

MaikG
Posts: 5172
Nutzer

Also ich habs jetzt so:

code:

rp&=AllocVec&(RastPort_sizeof%, MEMF_CLEAR&)
IF rp& THEN
 InitRastPort rp&
 bm& = AllocBitMap&(3000, 2000, 8, BMF_CLEAR&, NULL&)
 IF bm& THEN 
  POKEL(rp&+RastPortBitMap%),bm&
  delay 50
  WaitBlit
  FreeBitMap bm&
  ELSE PRINT "bitmap fail"
 END IF
 FreeVec& rp&
ELSE PRINT "Mem fail"
END IF

Aber da kommt nur Bitmap fail und dann bin ich trotzdem 1,8 MB meines
Chipspeichers los.

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 14:27 Uhr

tboeckel
Posts: 124
Nutzer

@MaikG:

Wer unfallfrei mit einem Taschenrechner umgehen kann, der wird merken, daß eine Bitmap mit 3000x2000 Pixeln in Tiefe 8 exakt 6MB Speicher benötigt. Was das für Auswirkungen auf einem System mit max. 2MB Chipram hat bleibt als Denksportaufgabe für dich übrig. Wie die Bitmap im Fastram landet wurde dir bereits um 10:41 erklärt. Allerdings setzt das Patches wie FBlit, CyberGraphics oder Picasso96 voraus. Ein nacktes OS3.x reicht dafür nicht.

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 15:40 Uhr

MaikG
Posts: 5172
Nutzer

>Wie die Bitmap im Fastram landet wurde dir bereits um 10:41 erklärt.
>Allerdings setzt das Patches wie FBlit, CyberGraphics oder
>Picasso96 voraus. Ein nacktes OS3.x reicht dafür nicht.

Ich würde schon gerne für AGA kompatibel bleiben, andere Programme
drucken doch auch in einer wesentlich höheren auflösung.

So hab ich nicht wirklich was gewonnen, könnte auch einen 1280x512x8
Screen öffnen...

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 15:55 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Ich würde schon gerne für AGA kompatibel bleiben, andere Programme
drucken doch auch in einer wesentlich höheren auflösung.

Wenn ich mich recht entsinne, muss gar keine komplette BitMap vorhanden sein, stattdessen kann man eine BitMap geringerer Höhe zum printer.device schicken, die einen Teil des Bildes beschreibt. Dann wartet man auf Vollzug, zeichnet den nächsten Teil des Bildes, schickt diesen, und so weiter und so fort, bis das komplette Bild übertragen ist.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 17:48 Uhr

MaikG
Posts: 5172
Nutzer

>Wenn ich mich recht entsinne, muss gar keine komplette BitMap
>vorhanden sein, stattdessen kann man eine BitMap geringerer Höhe
>zum printer.device schicken, die einen Teil des Bildes beschreibt.
>Dann wartet man auf Vollzug, zeichnet den nächsten Teil des Bildes,
>schickt diesen, und so weiter und so fort, bis das komplette Bild
>übertragen ist.

Das wäre ein heftiger berechnungsaufwand beim Zeichen und Texten
auf dem (gesplitteten)Rastport.

Warum kann das denn nicht im Fastram sein, WritePixel und so
einfache konsorten kommen doch ohne Customchips zurecht.

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 20:31 Uhr

akl
Posts: 265
Nutzer

@MaikG:

siehe http://www.amiga-news.de/forum/thread.php?id=28747&BoardID=1

TurboPrint hat eine eigene API, probiere es doch mal damit

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 22:33 Uhr

MaikG
Posts: 5172
Nutzer

>siehe http://www.amiga-news.de/forum/thread.php?id=28747&BoardID=1

>TurboPrint hat eine eigene API, probiere es doch mal damit

Dann müssten alle Turboprint dafür haben...
Ich hab zwar die neuste Version gekauf, aber die ist verhältnissmäßig
teuer für ein lang nicht mehr gepflegtes Programm...

Was ist wenn ich eine Bitmap simulieren würde? Also
AllocVec(FastMem) dann etwas rein was so in der Bitmap steht
größe, Tiefe oder was da drin ist. Ich möchte sagen einige befehle
der graphics.library funktionieren im Fastmam.

[ - Antworten - Zitieren - Direktlink - ]

18.03.2008, 23:32 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von MaikG:
>Wenn ich mich recht entsinne, muss gar keine komplette BitMap
>vorhanden sein, stattdessen kann man eine BitMap geringerer Höhe
>zum printer.device schicken, die einen Teil des Bildes beschreibt.
>Dann wartet man auf Vollzug, zeichnet den nächsten Teil des Bildes,
>schickt diesen, und so weiter und so fort, bis das komplette Bild
>übertragen ist.

Das wäre ein heftiger berechnungsaufwand beim Zeichen und Texten
auf dem (gesplitteten)Rastport.

Warum kann das denn nicht im Fastram sein, WritePixel und so
einfache konsorten kommen doch ohne Customchips zurecht.

Wenn Du einen Layer verwendest, lässt sich der Berechnungsaufwand in Grenzen halten. Allerdings wird es dann sehr langsam. Wenn Du wirklich keine komplexen Funktionen wie z.B. Draw() oder Text() benötigst, dann kannst Du natürlich die Bitmap auch von Hand im Fastram erstellen. Dem printer.device ist das egal. Wenn Du allerdings nur einzelne Punkte setzt, dann frage ich mich, wieso überhaupt Berechnungsaufwand besteht.

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 08:05 Uhr

Madcat
Posts: 247
Nutzer

Welche Aufloesung koennen denn Drucker die mit einem Standard-Amiga funktionieren? Ich denke 3000*2000 ist da etwas ueberzogen. Standard beim Drucker sind doch 72 dpi, oder? Das wuerde dann bedeuten, dass die Grafik auf dem Papier ca. 41 inches * 27 inches (1 inch ~ 25,4 mm) gross ist. Dafuer braucht man ja schon nen Plotter, fuer DIN A4 (210 mm * 297 mm) ist das naemlich etwas gross. Ich bin aber auch nur Laie was das Thema Drucken angeht, so am Rand. Mir kam grad nur die Dimension etwas riesig vor fuer einen Drucker.
--
Zeit ist eine Droge. Zuviel davon bringt einen um.

[ Dieser Beitrag wurde von Madcat am 19.03.2008 um 08:06 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 09:08 Uhr

Solar
Posts: 3680
Nutzer

Zitat:
Original von Madcat:

Standard beim Drucker sind doch 72 dpi, oder?

Selbst ein Fax hat heute deutlich mehr. Minimum ist so etwa 300 dpi, "normal" sind 600 dpi, hochauflösender Druck geht heute auch bei preiswerten Druckern mit über 2000 dpi.

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 10:02 Uhr

MaikG
Posts: 5172
Nutzer

>Wenn Du einen Layer verwendest, lässt sich der Berechnungsaufwand
>in Grenzen halten. Allerdings wird es dann sehr langsam.

Muss ich mal nachlesen.

>Wenn Du wirklich keine komplexen Funktionen wie z.B. Draw() oder
>Text() benötigst, dann kannst Du natürlich die Bitmap auch von
>Hand im Fastram erstellen. Dem printer.device ist das egal.
>Wenn Du allerdings nur einzelne Punkte setzt, dann frage ich mich,
>wieso überhaupt Berechnungsaufwand besteht.

Also ein paar mehr funktionen sind es schon, wie Move, Draw, SetAPen
und Rectfill.

>Welche Aufloesung koennen denn Drucker die mit einem Standard-Amiga
>funktionieren? Ich denke 3000*2000 ist da etwas ueberzogen.
>Standard beim Drucker sind doch 72 dpi, oder?

Ich druck immer mit 600dpi, mit einer Speziellen Drop Modulation
Technik kann der Drucker nochmer. Aber ich glaube das kann man
beim erstellen der Grafik nicht direkt nutzen.

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 14:33 Uhr

MaikG
Posts: 5172
Nutzer

Also im Fastmem geht z.B. SetFont nicht, brauche ich aber leider.
Eigenartig, weil ich cybergraphics habe...

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 17:01 Uhr

NoImag
Posts: 1050
Nutzer

Zitat:
Original von MaikG:
>Wenn Du einen Layer verwendest, lässt sich der Berechnungsaufwand
>in Grenzen halten. Allerdings wird es dann sehr langsam.

Muss ich mal nachlesen.

Der Layer verhindert nur, dass Du über den Rastport hinausschreibst. Damit kannst Du aber ohne großen Berechnungsaufwand sondern nur mit einem Offset dafür sorgen, dass immer der richtige Ausschnitt in der Bitmap landet. Der Preis ist, dass Du die Grafik für jeden Druckstreifen komplett neuzeichnest.

Zitat:
>Wenn Du wirklich keine komplexen Funktionen wie z.B. Draw() oder
>Text() benötigst, dann kannst Du natürlich die Bitmap auch von
>Hand im Fastram erstellen. Dem printer.device ist das egal.
>Wenn Du allerdings nur einzelne Punkte setzt, dann frage ich mich,
>wieso überhaupt Berechnungsaufwand besteht.

Also ein paar mehr funktionen sind es schon, wie Move, Draw, SetAPen
und Rectfill.

Draw() und RectFill() benötigen auf jeden Fall den Blitter (zumindest unter AGA).

Tschüß

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 17:48 Uhr

MaikG
Posts: 5172
Nutzer

>Der Layer verhindert nur, dass Du über den Rastport hinausschreibst.
>Damit kannst Du aber ohne großen Berechnungsaufwand sondern nur mit
>einem Offset dafür sorgen, dass immer der richtige Ausschnitt in
>der Bitmap landet. Der Preis ist, dass Du die Grafik für jeden
>Druckstreifen komplett neuzeichnest.

Ah, verstehe und das macht man mit CreateUpfrontHookLayer?
Vielleicht sollte ich auch ein Fenster nehmen, das verhindert
das zeichnen über den Rand und braucht bei CGX zusätzlich kein
Chipmem.

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 19:26 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Das wäre ein heftiger berechnungsaufwand beim Zeichen und Texten
auf dem (gesplitteten)Rastport.

Der Rechenaufwand ist, wenn man es richtig macht, nur geringfügig größer, als wenn Du das komplette Bild zuerst berechnest und dann überträgst.
Wenn Du die Tatsache nutzt, dass die Daten asynchron zum Drucker übertragen werden und Du währenddessen den nächsten Teil zeichnen kannst, dürfte es sogar deutlich schneller sein.

Zitat:
Warum kann das denn nicht im Fastram sein, WritePixel und so
einfache konsorten kommen doch ohne Customchips zurecht.

Ich wüsste jetzt nicht, welches die Konsorten sein sollen. WritePixel ist die einzige Funktion, die ohne ChipRAM auskommt und das auch erst ab AOS3.0 (oder war's 3.1?).

Jedenfalls hat das Anlegen einer FastRAM-BitMap weder mit Systemkonformität, noch mit der von Dir gewünschten Unabhängigkeit von Drittsoftware zu tun.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 19:36 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Ah, verstehe und das macht man mit CreateUpfrontHookLayer?
Vielleicht sollte ich auch ein Fenster nehmen, das verhindert
das zeichnen über den Rand und braucht bei CGX zusätzlich kein
Chipmem.

Fenster liegen auf Screens. Das bedeutet, dass die zugehörige BitMap darstellbar sein muss. Das heißt auf deutsch, wenn Du über diesen Umweg drucken würdest, kannst Du maximal in der (horizontalen) Auflösung drucken, die der gerade verwendete Grafikchip unterstützt, auch wenn der Drucker (mit ziemlicher Sicherheit) mehr kann. Diese Abhängigkeit kann man einem Benutzer nur schwer vermitteln, vor allem, wenn man wie Du eigentlich Wert auf möglichst wenig Abhängigkeiten zu irgendetwas installiertem legt.
Wie sich dieses Problem noch verschlimmert, wenn keine Grafikkarte installiert ist, kannst Du Dir vielleicht selbst ausrechnen.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

19.03.2008, 23:03 Uhr

MaikG
Posts: 5172
Nutzer

>Der Rechenaufwand ist, wenn man es richtig macht, nur geringfügig größer, als wenn Du das komplette Bild zuerst berechnest und dann überträgst.
>Wenn Du die Tatsache nutzt, dass die Daten asynchron zum Drucker
>übertragen werden und Du währenddessen den nächsten Teil zeichnen
>kannst, dürfte es sogar deutlich schneller sein.

Gut wenn ich jetzt Texthöhe etc. berechen würde.
Aber was ist wenn ich ein Komplexeres Bild zeichne oder einen
Farbverlauf...

>Jedenfalls hat das Anlegen einer FastRAM-BitMap weder mit
>Systemkonformität, noch mit der von Dir gewünschten Unabhängigkeit
>von Drittsoftware zu tun.

Okay. Bei mir braucht aber so gut wie gar nichts Fastram,
Selbst wenn ein Programm z.B. 3000x20x24 verwenden würde bräuchte
das irgendwie Chipmem.

>Fenster liegen auf Screens. Das bedeutet, dass die zugehörige BitMap
>darstellbar sein muss. Das heißt auf deutsch, wenn Du über diesen
>Umweg drucken würdest, kannst Du maximal in der (horizontalen)
>Auflösung drucken, die der gerade verwendete Grafikchip unterstützt,

Stimmt.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Rastport ohne Fenster?

[ - Suche - Neue Beiträge - Registrieren - Login - ]