|
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 - ] |
|
06.04.2008, 14:08 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Du musst die Bitmap natürlich mit einem Rastport versehen und den Rastport dann wie gehabt an das printer.device übergeben. [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2008, 14:20 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Wo hast Du INITHOOK definiert? Die Verwendung von Hooks ist halb lowlevel und könnte in BASIC Probleme machen. Die Parameter werden über Register an die Hook-Funktion übergeben. Bei Compilern, die dies nicht unterstützen ist Assembler erforderlich. Mir sind zwei Dinge aufgefallen: 1. Deine Hook-Funktion Readpixels& hat nur einen Parameter (hook und object fehlen) 2. Du übergibst bei INITHOOK keine userdata. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2008, 14:44 Uhr MaikG Posts: 5172 Nutzer |
>Wo hast Du INITHOOK definiert? >Die Verwendung von Hooks ist halb lowlevel und könnte in BASIC >Probleme machen. Die Parameter werden über Register an die >Hook-Funktion übergeben. Bei Compilern, die dies nicht unterstützen >ist Assembler erforderlich. Ist eine MaxonBasic Funktion. >Mir sind zwei Dinge aufgefallen: >1. Deine Hook-Funktion Readpixels& hat nur einen Parameter >(hook und object fehlen) Wie gesagt ich hab keinen schimmer von Hooks, ich kann hook und object dazusetzen. Hab aber keine ahnung wozu ich die verwenden sollte oder ob das hilft. Da die Funktion erst gar nicht aufgerufen wird, scheint es auch ein anderes Problem zu sein. >2. Du übergibst bei INITHOOK keine userdata. Das scheint bei der Funktion nicht vorgesehen, es macht meine Funktion Readpixels für das Betriebssystem zugänglich und kümmert sich auch um die Parameter. [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2008, 19:53 Uhr NoImag Posts: 1050 Nutzer |
@MaikG: Was sagt denn das MaxonBASIC-Handbuch zu INITHOOK? Wie das ganze in C aussehen muss, findest Du ausführlich in hook.h beschrieben. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2008, 20:13 Uhr MaikG Posts: 5172 Nutzer |
>Was sagt denn das MaxonBASIC-Handbuch zu INITHOOK? INITHOOK Hook_Adresse, Funktions_Adresse Dieser Befehl initalisiert einen "Hook", damit er vom Betriebssystem aufgerufen werden kann. usw. Das mit dem anderen 2 Parametern hab ich jetzt auch probiert, erfolglos. >Wie das ganze in C aussehen muss, findest Du ausführlich in hook.h >beschrieben. Leider ist lesen was anderes als verstehen ;-) [ Dieser Beitrag wurde von MaikG am 06.04.2008 um 20:21 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2008, 22:52 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Wird irgendwas zur Hook-Funktion, insbesondere zu den erforderlichen Parametern und deren Reihenfolge, gesagt? Zitat: Wenn obige Frage nein lautet, hast Du die Reihenfolge hook, object, message verwendet? Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2008, 23:48 Uhr MaikG Posts: 5172 Nutzer |
>Wird irgendwas zur Hook-Funktion, insbesondere zu den erforderlichen >Parametern und deren Reihenfolge, gesagt? Ja, ist ein Beispiel dabei: Function meineHookFunktion&(BYVAL Hook&, BYVAL o&, BYVAL msg&) ... End function Dim h(Hook_sizeof2) INITHOOK VARPTR(h(0)), VARPTRS(meineHookFunktion&) res&=CallHookPkt&(VARPTR(h(0)),SADD("Hallo"+CHR$(0)),0) >Wenn obige Frage nein lautet, hast Du die Reihenfolge hook, object, >message verwendet? Ja. Wie gesagt ich tippe eher darauf das ich die Includes falsch gemacht habe. Denn selbst mit falschen parametern etc. sollte die function zumindest aufgerufen werden. Bzw. sollte wenigstens ein Enforcer Hit kommen. Aber es passiert nichts programm bleibt stehen. [ - Antworten - Zitieren - Direktlink - ] |
|
07.04.2008, 10:55 Uhr Holger Posts: 8116 Nutzer |
@MaikG: Falls Dein Code immer noch so aussieht, wie Du ihn gepostet hast, solltest Du mal sicherstellen, dass der RastPort, den Du Deiner Funktion dumpRP% übergibst, auch tatsächlich in die TagList eingetragen wird. Bisher steht da nur NULL& und der rp& Parameter wird komplett ignoriert... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
07.04.2008, 11:45 Uhr MaikG Posts: 5172 Nutzer |
@Holger das muss so. Ist dem NDK3.9 C-beispiel entsprechend: ior->io_Command = PRD_DUMPRPORTTAGS; ior->io_Flags = 0; ior->io_Error = 0; ior->io_RastPort = NULL; ior->io_ColorMap = NULL; ior->io_Modes = 0; ior->io_SrcX = 0; ior->io_SrcY = 0; ior->io_SrcWidth = 256; ior->io_SrcHeight = 256; ior->io_DestCols = 256; ior->io_DestRows = 256; ior->io_Special = 0; ior->io_TagList = tags; [ - Antworten - Zitieren - Direktlink - ] |
|
07.04.2008, 23:42 Uhr NoImag Posts: 1050 Nutzer |
Zitat: In diesem Beispiel wird BYVAL (was bedeutet dies?) verwendet, in Deinem Quellcode dagegen nicht. Verwendet PRINT stdio oder Text()? Im ersten Fall dürfte es nicht funktionieren. Zitat: Ich habe die Werte überprüft: Zitat:sollte 12 sein, ensprechend sollte Zitat:16 sein. Wie kommst Du auf Zitat: Ob Zitat:stimmt, habe ich nicht nachgerechnet. Es sollte 2 mehr sein als io_Special%. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
08.04.2008, 00:16 Uhr MaikG Posts: 5172 Nutzer |
>In diesem Beispiel wird BYVAL (was bedeutet dies?) verwendet, >in Deinem Quellcode dagegen nicht. Das die Variable als Wert übergeben wird, daher vom unterprogramm nicht geändert werden kann. Ist auch schneller, hat aber nichts zu bedeuten. >Verwendet PRINT stdio oder Text()? Im ersten Fall dürfte es nicht >funktionieren. Ein Fenster von MaxonBasic. Aber wo du es sagst, wenn die routine direkt vom System aufgerufen wird... Edit: Macht auch keinen unterschied. >Ich habe die Werte überprüft: Die hab ich heute mittag korregiert. >Wie kommst Du auf Weiss nicht mehr, hab ich aber nicht verwendet, >stimmt, habe ich nicht nachgerechnet. Es sollte 2 mehr sein als >io_Special%. Ist es. Stimmt das mit TAG_USER+0x60000 ? Kam mir etwas komisch vor. [ Dieser Beitrag wurde von MaikG am 08.04.2008 um 00:20 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
08.04.2008, 23:13 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Hast Du es ausprobiert? Zitat: So steht es in den Includes. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
08.04.2008, 23:31 Uhr MaikG Posts: 5172 Nutzer |
>Hast Du es ausprobiert? Ja. Tja, ich hab schon überlegt ein Teil des Druckens in C zu legen. Dafür wollte ich mal das Beispiel vom NDK3.9 Testen. Und was passiert - nix. Also wenn das bereits fertig Compilierte Programm in C nicht läuft brauch man nicht versuchen das in Basic umzusetzten... >So steht es in den Includes. Bei Basic wird immer der komplette Wert und nicht Rechenoperationen mit Kontanten aus anderen Includes. [ - Antworten - Zitieren - Direktlink - ] |
|
09.04.2008, 22:24 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Bei mir läuft das compilierte Programm aus dem NDK, wenn ich es aus der Shell starte. Der Hook funktioniert also. Ich schlage vor, dass Du als erstes das Beispiel 1:1 nach BASIC übersetzt, bevor Du Änderungen vornimmst. Mir ist nämlich einiges an Deinem Quellcode nicht klar. Hast Du schon überprüft, ob Du überhaupt bis SendIO() kommst? Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
10.04.2008, 07:32 Uhr MaikG Posts: 5172 Nutzer |
>Bei mir läuft das compilierte Programm aus dem NDK, wenn ich es >aus der Shell starte. Der Hook funktioniert also. Bei mir definitiv nicht. Benutzt du das OS3.9 eigene printer.device oder Turboprint? >Ich schlage vor, dass Du als erstes das Beispiel 1:1 nach BASIC >übersetzt, bevor Du Änderungen vornimmst. Mir ist nämlich einiges >an Deinem Quellcode nicht klar. Ausser SendIO statt DoIO hab ich schon alles gleich gemacht. Ich könnte noch das DOIO einsetzen, aber da das Beispiel in C eh nicht geht wird das nichts bringen. >Hast Du schon überprüft, ob Du überhaupt bis SendIO() kommst? Ja, ist nichts kritisches davor. Also bissher kam ich zur folgender erkenntniss: 24 Bit Drucken -unter CGX+Turboprint kein Problem. -unter CGXAGA+Turboprint nicht möglich (absturz printer.device) macht man die Bitmap per AllocVec selbst geht das, allerdings kann man dann die CGX Funktionen sowie Text nicht benutzen -unter OS4+Turboprint kommt nur Müll aus dem Drucker da P96 wohl die Bitmap so anlegt das TP diese nicht identifizieren kann. Rein Theoretisch könnte es per AllocVec gehen(ohne CGX). Ohne Turboprint könnte es jetzt sogar noch sein das gar nichts geht. [ Dieser Beitrag wurde von MaikG am 10.04.2008 um 09:01 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.04.2008, 20:02 Uhr NoImag Posts: 1050 Nutzer |
@MaikG: Turboprint habe ich dafür deaktiviert. Wenn Turboprint läuft, dann hast Du ein anderes printer.device. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
10.04.2008, 23:46 Uhr MaikG Posts: 5172 Nutzer |
>Turboprint habe ich dafür deaktiviert. Wenn Turboprint läuft, >dann hast Du ein anderes printer.device. Ich denke TP ist das meistgenutzte, denn die OS3.9 Treiber sind teilweise buggy oder es gibt keine für halbwegs aktuelle Drucker. Für meinen gibts keinen anderen Treiber als Turboprint, habe alle Treiber die kompatibel sein könnten durch. TP sollte eigentlich zu >=OS3.5 kompatibel sein. Die intenen funktionen von Turboprint zu nutzen bringt leider auch nur das was man mit dem Standard DumpRP kommando erreichen kann. [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 00:12 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Das spielt keine Rolle, wenn Du eine Funktionalität benötigst, die Turboprint nicht bietet! Zitat: Nein, nicht in dem Sinne, wie Du es meinst. Turboprint unterstützt die neuen Fähigkeiten des printer.device V44 nicht. Siehe http://www.irseesoft.de Es gibt einen einfachen Test: Was meldet "version printer.device" Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 02:25 Uhr whose Posts: 2156 Nutzer |
Zitat: Er sollte mal auf der irseesoft-Seite schauen, da gibts Doku zu TP. Da wird ihm dann hoffentlich klar, daß TurboPrint DUMPRPORTTAGS als Kommando für das modifizierte printer.device nicht kennt. Dafür hat TP etwas Neckisches genau für seine Zwecke parat, allerdings funktioniert das wiederum nicht mit dem V44 printer.device: Zitat: Damit kann man das Format der zu druckenden Bitmap explizit mitteilen, was für seine händisch gebaute Bitmap das Richtige sein dürfte. Nachteil ist allerdings, daß sein Prog dann nur mit TP drucken kann, dessen Weiterentwicklung für Amiga ja, wie es aussieht, gestorben ist. Muss er dann wissen, ob er auf eine tote Druckertreiber-Seitenlinie setzen oder doch lieber CGFX/P96 bzw. OS3.5+ voraussetzen will. @MaikG: Schau mal auf der Irseesoft-Seite unter "Tech-Info", da findest Du die Dokumentation zum TP-printer.device. Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 09:57 Uhr MaikG Posts: 5172 Nutzer |
>Er sollte mal auf der irseesoft-Seite schauen, da gibts Doku zu TP. >Da wird ihm dann hoffentlich klar, daß TurboPrint DUMPRPORTTAGS als >Kommando für das modifizierte printer.device nicht kennt. Ich habe mir die develloper dateien runtergeladen. Konnte das daraus aber nicht entnehmen. Ist es nicht dumm sowas nicht zu unterstützen? >Damit kann man das Format der zu druckenden Bitmap explizit >mitteilen, was für seine händisch gebaute Bitmap das Richtige >sein dürfte. Nachteil ist allerdings, daß sein Prog dann nur mit >TP drucken kann, dessen Weiterentwicklung für Amiga ja, wie es >aussieht, gestorben ist. Muss er dann wissen, ob er auf eine >tote Druckertreiber-Seitenlinie setzen oder doch lieber CGFX/P96 >bzw. OS3.5+ voraussetzen will. Ja, die Funktion macht mit TPFMT_RGB24% OR TPFMT_CyberGraphX% das selbe wie die normale Funktion. Problem ist, die geht nur wenn CyberGraphX auch vorhanden ist. Der Verursacher könnte aber auch AllocBitmap sein. Fertige ich eine Bitmap per Hand an kann ich mit den CGX Funktionen nicht darauf zeichnen. Text geht auch nicht. [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 10:40 Uhr whose Posts: 2156 Nutzer |
Zitat: Es steht nicht direkt im Klartext drin (wie sollte auch? Zu der Zeit des printer.device V44 war TPs Schicksal schon besiegelt), aber man kanns "zwischen den Zeilen" entnehmen. Da steht nirgendwo etwas davon, daß die Funktionalität des printer.device V44 unterstützt wird. Zitat: Das liegt mehr daran, daß es sich nicht mehr rechnet, TP weiterzuentwickeln. Zitat: Wie heißt es so schön? Man kann nicht alles haben! Um eine Konvertierung für die Darstellung unter AGA/CGFX sowie eigene Zeichenfunktionen wirst Du nicht herumkommen, wenn Du Bitmaps per Hand strickst und darin zeichnen willst, noch dazu, wenn Du CGFX nicht explizit voraussetzen möchtest. Mit der oben angegebenen Funktion von TP kannst Du aber immerhin 24Bit Farbtiefe auch ohne CGFX drucken (ja, das funktioniert!), mit CGFX/P96 gibt Dir auch printer.device V44 die 24Bit oder Du kannst die Daten ggf. über den Hook liefern (wie in dem Beispiel aus dem NDK3.9 gezeigt, mußt nur die Version des printer.device überprüfen und dementsprechend zwei Ausgabefunktionen nutzen). Ob das mit Deinem BASIC-Äquivalent des NDK-Beispiels funktioniert kann sicher jemand anderes testen, u.A. ich und NoImag kann das sicher auch. Auf lange Sicht solltest Du übrigens auf HP-Drucker umsteigen, das sind die einzigen, für die man noch erschöpfend Informationen ohne irgendwelche lustigen NDAs bekommt und somit Treiber bauen kann. Zum Zeichnen nochmal: Immerhin vereinfacht Dir CGFX die Konvertierung mittels WritePixelArray(), für AGA/ECS mußt Du selbst konvertieren. Die Zeichenfunktionen selbst sind so oder so "Fleißarbeit", wobei Dir MadDog nicht unerheblich behilflich war, wie ich gesehen habe. Am OS vorbei zu entwickeln ist halt ziemlich oft nichts für "mal eben und mit möglichst Null Aufwand". Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 14:32 Uhr MaikG Posts: 5172 Nutzer |
>Es steht nicht direkt im Klartext drin (wie sollte auch? Zu der >Zeit des printer.device V44 war TPs Schicksal schon besiegelt), Mir war so als wäre es nicht so lage her als ich TP7.6 gekauft habe. OS3.5 und ich glaub sogar 3.9 liegt weiter zurück. >Um eine Konvertierung für die Darstellung unter AGA/CGFX sowie >eigene Zeichenfunktionen wirst Du nicht herumkommen, >wenn Du Bitmaps per Hand strickst und darin zeichnen willst, >noch dazu, wenn Du CGFX nicht explizit voraussetzen möchtest. Ich denke CGFX vorrauszusetzten ist aktzeptabel. >Mit der oben angegebenen Funktion von TP kannst Du aber immerhin >24Bit Farbtiefe auch ohne CGFX drucken (ja, das funktioniert!), Ja, wenn man die BM selbst macht. >mit CGFX/P96 gibt Dir auch printer.device V44 die 24Bit oder Du >kannst die Daten ggf. über den Hook liefern (wie in dem Beispiel aus dem NDK3.9 gezeigt, >mußt nur die Version des printer.device überprüfen und dementsprechend zwei Ausgabefunktionen nutzen). >Ob das mit Deinem BASIC-Äquivalent des NDK-Beispiels funktioniert >kann sicher jemand anderes testen, u.A. ich und NoImag kann das >sicher auch. Ich bezweifle das es geht, denn das NDK Beispiel startet und beendet sich sofort. Basic bleibt hängen. >Auf lange Sicht solltest Du übrigens auf HP-Drucker umsteigen, >das sind die einzigen, für die man noch erschöpfend Informationen >ohne irgendwelche lustigen NDAs bekommt und somit Treiber bauen >kann. HP sind auch die besten Drucker nach meiner erfahrung, Trotzdem ist Treiber schreiben, für mich zu hoch. Zumal TP sonst mit jedem Programm Problemlos funktioniert. Und da es fürs >OS3.5 System keine aktuellen funktionierenden/sauberen Treiber gibt ists genauso sinnlos darauf zu setzen. >Die Zeichenfunktionen selbst sind so oder so Fleißarbeit", wobei >Dir MadDog nicht unerheblich behilflich war, wie ich gesehen habe. Für normale Zeichenfunktionen ist das gut aber Fonts gehen damit nicht. TTF wurde mal erwähnt, aber ich möchte meine Amiga Fonts. [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 15:35 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Sorry, wenn ich das jetzt sage, aber: Wir helfen Dir hier gerne, aber alles vorkauen können wir Dir auch nicht. Wenn Du was mit Fonts machen willst, und am OS vorbeiprogrammierst, musst Du dafür eben auch selbst eine Lösung finden. Gehen tut das sicher, nur der Aufwand ist eben entsprechend hoch. Vielleicht solltest Du auch mal einen neuen Thread eröffnen, da Deine eigentliche Fragestellung (Wie ohne graphics.library zeichnen) schon längst ausführlich beantwortet wurde. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 15:38 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Ein Lob auf HP! Kann dem nur zustimmen. Habe selbst seinerzeit ein Konfigurationsprogramm für meinen HP LaserJet 1320 für den Amiga geschrieben. Das war dank der vorbildlichen Entwicklerdokumentation (sogar mit Beispielcodes) seitens HP auch wirklich ein Kinderspiel. -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 17:52 Uhr MaikG Posts: 5172 Nutzer |
>Sorry, wenn ich das jetzt sage, aber: Wir helfen Dir hier gerne, >aber alles vorkauen können wir Dir auch nicht. Wenn Du was mit >Fonts machen willst, und am OS vorbeiprogrammierst, musst Du dafür >eben auch selbst eine Lösung finden. Gehen tut das sicher, nur der >Aufwand ist eben entsprechend hoch. Wie kommst du darauf das ich am System vorbei Programmiere? Ich benutze Standard Systemfunktionen. Das Allocbitmap evtl. ohne CGX z.B. nicht das richtige Pixelformat nimmt oder was es immer macht ist ja nicht mein Fehler. Wenn ich direkt in den Speicher schreibe, sagen wir mit einer WritePixelRGB variante - dann würde ich das eher am OS vorbeiprogrammierem nennen. [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 19:13 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Du hast doch gefragt, wie Du Kreise und Linien OHNE die graphcs.library bzw. cybergraphx zeichnen kannst. Und das geht eben nur mit einem Pixelarray, so wie ich es Dir gezeigt habe. Und wenn man das so macht, muß man eben für alle Grafikprimitiven, angefangen von einem Pixel setzen, selbst schreiben. Ich hoffe, daß Du das verstanden hast? Das ist zwar viel Arbeit, aber man muß ja auch nicht das Rad neu erfinden. Die Beispielcodes, die ich gepostet habe, sind nur geringfügig modifizierte Varianten des Bresenham Algorithmus, wie auf Wikipedia beschrieben. Dort findest Du übrigens auch die Basic-Variante. Nochmal kurz angerissen, was ich gemacht habe: 1.) Ich besorge mir ausreichend Speicher für meine Bilddaten. Wieviel ich brauche, hängt von der Auflösung und Farbtiefe ab: Speicherbedarf = Bytes per Pixel * Breite * Höhe. Also z.B. 24 Bit (= 3 Byte), 640 x 480 = 921600 Byte 2.) Einen Pixel setze ich wie folgt: Ich rechne mir die Position aus, wo der erste Farbanteil steht, dann setze ich die Bytes der entsprechenden Farbkomponenten (und bei Bedarf den Alpha Wert). 3.) Auf der Funktion, die EINEN PIXEL setzt, kann ich dann weitere Funktionen für Linien und Kreise aufbauen. 4.) Das Pixel-Array bekomme ich dann mit Hilfe der Cybergraphx-Funktion WirtePixelArray() in einen RastPort. Das ist eigentlich nicht besonders schwer zu verstehen, nur eben ein wenig Arbeit, das auszuprogrammieren. Aber so ist es nun mal: Wenn man eine Funktionalität haben will, welche das OS bzw. irgendwelche APIs von Drittanbietern nicht am Start haben, muss man das eben gezwungenermaßen selbst programmieren, oder aber man läßt es einfach. -- http://www.norman-interactive.com [ Dieser Beitrag wurde von Mad_Dog am 12.04.2008 um 19:14 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
12.04.2008, 22:55 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Das letzte echte Update war 7.0 oder 7.1 (vielleicht weiß das jemand noch genau). Das war vor WB 3.5. Danach gab es nur noch neue Treiber, kein Update des printer.device. Zitat: Nach den Entwicklerunterlagen geht es auch mit CGFX-Bitmaps und bei 7.x sollte es auch mit P96-Bitmaps gehen. Zitat: Hast Du Turboprint deaktiviert? Hast Du in den Printer-Preferences einen passenden Druckertreiber eingestellt? Bei mir funktioniert es. Wenn es bei Dir nicht funktioniert, liegt es an Deinem System. Zitat: BASIC code:DRPMsg&=PEEKL(DRPMsg2&) x&=PEEKL(DRPMsg&+DRP_x%) y&=PEEKL(DRPMsg&+DRP_y%) myWidht&=PEEKL(DRPMsg&+DRP_width%) myHeight&=PEEKL(DRPMsg&+DRP_height%) buffer&=PEEKL(DRPMsg&+DRP_buf%) ist falsch. Zitat: Du kannst Deinen Text auch in einen Rastport im Chipram schreiben (wenn es sein muss, Buchstabe für Buchstabe) und dann das Ergebnis pixelweise in Deine Bitmap (oder Puffer) im Fastram übertragen. Das ist nicht effizient, wird aber funktionieren. Tschüß [ Dieser Beitrag wurde von NoImag am 12.04.2008 um 22:57 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2008, 00:22 Uhr MaikG Posts: 5172 Nutzer |
>Du hast doch gefragt, wie Du Kreise und Linien OHNE die graphcs.library bzw. >cybergraphx zeichnen kannst. Ja, ohne graphics. Weil das Pen basierend und so nutzlos ist. >4.) Das Pixel-Array bekomme ich dann mit Hilfe der Cybergraphx-Funktion >WirtePixelArray() in einen RastPort. Na aber wenn du Cybergraphics benutzt kannst du das nicht mit Turboprint unter CGX AGA Drucken. Ist prinzipell das selbe wie jetzt, wo CGX geht geht auch graphics.library/Text. >Das letzte echte Update war 7.0 oder 7.1 (vielleicht weiß das >jemand noch genau). Das war vor WB 3.5. Danach gab es nur noch >neue Treiber, kein Update des printer.device. Ja, mag sein. Die Oberfläche ist auch sehr antiquiert geblieben, für den Preis (TP7.1 -> 7.6) hätte ich mehr erwartet. Zitat: >Mit der oben angegebenen Funktion von TP kannst Du aber immerhin >24Bit Farbtiefe auch ohne CGFX drucken (ja, das funktioniert!), Ja, wenn man die BM selbst macht. >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. >Hast Du Turboprint deaktiviert? Ja. >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. > Zitat: > Basic bleibt hängen. > BASIC code: > DRPMsg&=PEEKL(DRPMsg2&) > x&=PEEKL(DRPMsg&+DRP_x%) > y&=PEEKL(DRPMsg&+DRP_y%) > myWidht&=PEEKL(DRPMsg&+DRP_width%) > myHeight&=PEEKL(DRPMsg&+DRP_height%) > buffer&=PEEKL(DRPMsg&+DRP_buf%) >ist falsch. Kannst du das Prezisieren? Die 2. MSG lesen habe ich rausgenommen. >Du kannst Deinen Text auch in einen Rastport im Chipram schreiben >(wenn es sein muss, Buchstabe für Buchstabe) und dann das Ergebnis >pixelweise in Deine Bitmap (oder Puffer) im Fastram übertragen. >Das ist nicht effizient, wird aber funktionieren. Sowas hab ich mir auch schon gedacht. Zu dem Problem gehört dann noch das man nicht per WriteRGBPixel sondern per POKE die Bitmap bearbeiten muss. Wenn ich wiederrum die BM mit AllocVec hole, könnte ich mir jetzt schon denken das die Preview ausfällt weil BlitBitmap nicht damit funktioniert o.ä. Spätestens aber machen Bilder die ich mit den Datatype brauche bestimmt einen Strich durch die Rechnung. [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2008, 05:48 Uhr Mad_Dog Posts: 1944 Nutzer |
Zitat: Siehe mein Beispielcode. Wo ist da das Problem? Wenn Du etwas nicht verstanden hast, dann frag doch einfach! Zitat: BlitBitmap geht natürlich nicht damit, weil es ein Pixelarray und keine AmigaOS BitMap-Struktur ist. Das hat doch Holger schon lang und breit festgestellt. Für Hi/Truecolor-Pixelarrays brauchst Du die CybergraphX Funktion WritePixelArray(). Und wenn Du das auch unbedingt mit AGA funktionieren soll (also pures AmigaOS 3.x ohne Cybergraphx), dann musst Du wie schon richtig gesagt wurde selbst eine Remaping-Funktion schreiben. Und da Deine Riesen-Grafik sowieso nicht darstellbar sein wird (weil eben zu groß), mußt Du diese eben auch noch irgendwie skalieren, um sie in einem Fenster/Screen darstellen zu können. Aber vielleicht solltest Du Dir erstmal darüber klar werden, was Du überhaupt willst, d.h. was soll Dein Programm können? Welche Hard/Software soll Mindestvoraussetzung sein? -- http://www.norman-interactive.com [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2008, 09:49 Uhr MaikG Posts: 5172 Nutzer |
>Siehe mein Beispielcode. Wo ist da das Problem? Wenn Du etwas nicht >verstanden hast, dann frag doch einfach! Also wenn ich das lese: 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? >BlitBitmap geht natürlich nicht damit, weil es ein Pixelarray und >keine AmigaOS BitMap-Struktur ist. Okay, also keine Vorschau. Um das ganze nun aber drucken zu können müsste ich das Pixelarray auf einen Rastport bringen. Was wiederum eine 24 Bit Bitmap braucht und aufgrund der größe ist es kein echter Rastport. Da bin ich wieder an der Stelle an der ich jetzt bin, so kann ich das nur mit CGX&Graka+Turboprint drucken. >Und wenn Du das auch unbedingt mit AGA funktionieren soll (also pures AmigaOS 3.x ohne >Cybergraphx), >dann musst Du wie schon richtig gesagt wurde selbst eine >Remaping-Funktion schreiben. Ja, der Remaping und Scaling code war sehr einfach zu schreiben. Für die Vorschau ist das okay, fürs Drucken brauch ich 16,7 Mio Farben. >Aber vielleicht solltest Du Dir erstmal darüber klar werden, was Du >überhaupt willst, d.h. was soll Dein Programm können? Es kann schon alles was es soll, ausser Drucken auf AGA/P96. >Welche Hard/Software soll Mindestvoraussetzung sein? 68020, OS2 oder 3, einige MB Fastmem. Software ist halt das Problem optimal wäre wenn cgx und TP gar nicht zwangsweise benötigt werden. [ - 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. |
|