amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Kreis Zeichnen ohne graphics.library [ - Search - New posts - Register - Login - ]

1 2 3 -4- 5 [ - Post reply - ]

2008-04-06, 14:08 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
>Dies gilt, wenn Du eine echte Bitmap drucken möchtest.

Hab ich zwar auch gelesen, nur finde ich keine Funktion der
ich eine Bitmap übergeben könnte.


Du musst die Bitmap natürlich mit einem Rastport versehen und den Rastport dann wie gehabt an das printer.device übergeben.

[ - Answer - Quote - Direct link - ]

2008-04-06, 14:20 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
Also ich wollte das mit der neuen OS3.5 Funktionalität mal
probieren. Passiert aber nichts, die Function wird nicht
aufgerufen.


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üß



[ - Answer - Quote - Direct link - ]

2008-04-06, 14:44 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-06, 19:53 h

NoImag
Posts: 1050
User
@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üß



[ - Answer - Quote - Direct link - ]

2008-04-06, 20:13 h

MaikG
Posts: 5172
User
>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. ]

[ - Answer - Quote - Direct link - ]

2008-04-06, 22:52 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
>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.


Wird irgendwas zur Hook-Funktion, insbesondere zu den erforderlichen Parametern und deren Reihenfolge, gesagt?

Zitat:
Das mit dem anderen 2 Parametern hab ich jetzt auch probiert,
erfolglos.


Wenn obige Frage nein lautet, hast Du die Reihenfolge hook, object, message verwendet?

Tschüß

[ - Answer - Quote - Direct link - ]

2008-04-06, 23:48 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-07, 10:55 h

Holger
Posts: 8116
User
@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.

[ - Answer - Quote - Direct link - ]

2008-04-07, 11:45 h

MaikG
Posts: 5172
User
@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;

[ - Answer - Quote - Direct link - ]

2008-04-07, 23:42 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
>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


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


Ich habe die Werte überprüft:
Zitat:
CONST DRP_height% = 16
sollte 12 sein, ensprechend sollte
Zitat:
CONST DRP_buf% = 20
16 sein.

Wie kommst Du auf
Zitat:
CONST DRPSourceMsg_sizeof%=78 'fill this buffer with 0x00RRGGBB pixels

Ob
Zitat:
CONST io_Taglist% =62
stimmt, habe ich nicht nachgerechnet. Es sollte 2 mehr sein als io_Special%.

Tschüß



[ - Answer - Quote - Direct link - ]

2008-04-08, 00:16 h

MaikG
Posts: 5172
User
>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. ]

[ - Answer - Quote - Direct link - ]

2008-04-08, 23:13 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
>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.


Hast Du es ausprobiert?

Zitat:
Stimmt das mit TAG_USER+0x60000 ? Kam mir etwas komisch vor.

So steht es in den Includes.

Tschüß



[ - Answer - Quote - Direct link - ]

2008-04-08, 23:31 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-09, 22:24 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
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...


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üß



[ - Answer - Quote - Direct link - ]

2008-04-10, 07:32 h

MaikG
Posts: 5172
User
>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. ]

[ - Answer - Quote - Direct link - ]

2008-04-10, 20:02 h

NoImag
Posts: 1050
User
@MaikG:
Turboprint habe ich dafür deaktiviert. Wenn Turboprint läuft, dann hast Du ein anderes printer.device.

Tschüß



[ - Answer - Quote - Direct link - ]

2008-04-10, 23:46 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-12, 00:12 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
>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.


Das spielt keine Rolle, wenn Du eine Funktionalität benötigst, die Turboprint nicht bietet!

Zitat:
TP sollte eigentlich zu >=OS3.5 kompatibel sein.

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üß



[ - Answer - Quote - Direct link - ]

2008-04-12, 02:25 h

whose
Posts: 2156
User
Zitat:
Original von NoImag:
Zitat:
Original von MaikG:
>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.


Das spielt keine Rolle, wenn Du eine Funktionalität benötigst, die Turboprint nicht bietet!


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:
Using the extended DumpRastPort command ("PRD_TPEXTDUMPRPORT"):

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

--
---

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

[ - Answer - Quote - Direct link - ]

2008-04-12, 09:57 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-12, 10:40 h

whose
Posts: 2156
User
Zitat:
Original von MaikG:
>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.


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:
Ist es nicht dumm sowas nicht zu unterstützen?

Das liegt mehr daran, daß es sich nicht mehr rechnet, TP weiterzuentwickeln.

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.


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.


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

--
---

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

[ - Answer - Quote - Direct link - ]

2008-04-12, 14:32 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-12, 15:35 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von MaikG:

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


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

[ - Answer - Quote - Direct link - ]

2008-04-12, 15:38 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von whose:
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.


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

[ - Answer - Quote - Direct link - ]

2008-04-12, 17:52 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-12, 19:13 h

Mad_Dog
Posts: 1944
User
Zitat:
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.


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

[ - Answer - Quote - Direct link - ]

2008-04-12, 22:55 h

NoImag
Posts: 1050
User
Zitat:
Original von MaikG:
>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.


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

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


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

Zitat:
Für normale Zeichenfunktionen ist das gut aber Fonts gehen
damit nicht. TTF wurde mal erwähnt, aber ich möchte meine Amiga
Fonts.


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

[ - Answer - Quote - Direct link - ]

2008-04-13, 00:22 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]

2008-04-13, 05:48 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von MaikG:
Zu dem Problem gehört dann noch das man nicht per WriteRGBPixel sondern per POKE die Bitmap bearbeiten muss.


Siehe mein Beispielcode. Wo ist da das Problem? Wenn Du etwas nicht verstanden hast, dann frag doch einfach!

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


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

[ - Answer - Quote - Direct link - ]

2008-04-13, 09:49 h

MaikG
Posts: 5172
User
>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.

[ - Answer - Quote - Direct link - ]


1 2 3 -4- 5 [ - Post reply - ]


amiga-news.de Forum > Programmierung > Kreis Zeichnen ohne graphics.library [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.