Sie sind nicht angemeldet.

1

Mittwoch, 17. Oktober 2018, 12:44

GraphicState

Bei den Grafik-Objekten in GeoDraw (Artist) spielt die Transformation der Geometriedaten (Stichwort: Transformationsmatrix) eines Objekts eine wesentliche Rolle. Wird zum Beispiel ein Arc-Objekt aufgezogen, dann ist der Arc in der Regel schon transformiert. Man kann das leicht sehen, wenn man nach der Erstellung des Objekts unter Transformieren den Punkt Transformation zurücknehmen wählt. Die Transformationsmatrix möchte ich auslesen. Ich hab's versucht mit GrGetTransform(gstate,*matrix) in der Methode MSG_VIS_DRAW des Grafik-Bodys . Ich erhalte aber stets nur die Einheitsmatrix. Das Problem scheint zu sein, dass ich nicht den GState des Objekts anspreche. Gibt es eine Möglichkeit, an das zum Objekt gehörige GState-Handle heranzukommen?

Wilfried

2

Mittwoch, 17. Oktober 2018, 21:19

Was mir auffällt ist, das alles außer Kreisbogen auf "Transformation zurücknehmen" nicht reagiert, wenn man vorher die Größe geändert hat. Also ist - außer für Kreisbogen - die "1-Matrix" vielleicht wirklich korrekt?
Gruß

Rainer
P.S. Wieso des Grafik Bodies? Wieso nicht des Grafik-Objekts? . Nur so ein Gedanke eines unwissenden :-)
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

3

Donnerstag, 18. Oktober 2018, 10:37

<<Was mir auffällt ist, das alles außer Kreisbogen auf "Transformation zurücknehmen" nicht reagiert, wenn man vorher die Größe geändert hat.>>

Hier scheint die ArcClass eine Sonderrolle einzunehmen. Wenn du aber die Größenänderung über Transformieren vornimmst und das auch noch in mehreren Schritten (um von UNDO unterscheiden zu können), dann wird durch Transformation zurücknehmen die komplette Änderung (bei allen Objekttypen) zurückgenommen.

<< Wieso des Grafik Bodies? Wieso nicht des Grafik-Objekts?>>

1. Ich kann eine Msg für ein GrObj nur abfangen, wenn ich die Objektklasse 'gesubclassed' habe. Das geht, wenn ich das GrObj per Code (von der Subclass) erzeuge. Die Objekte, die mit der Maus aufgezogen werden, sind aber immer von der Original-Klasse.

2. Die SuperClass von GrObjClass ist MetaClass. Pmake sagt dann auch, dass MSG_VIS_DRAW keine Msg der GrObjClass ist.

<<Nur so ein Gedanke eines unwissenden :-) >>

Lustig ;)

Wilfried

4

Donnerstag, 18. Oktober 2018, 21:58

Jetzt habe ich dich verstanden. Leider sehe ich keine Lösung.

Folgendes würde ich mir denken:

Das GState des GrObjBody sollte immer die Eins-Matrix haben, weil sonst ALLE Objekte transformiert würden. Wenn ich das implementieren müsste, dann würde ich die Transformationsmatrix in der VIS-DRAW des Objekts temporär ändern, um das Objekt transformiert darzustellen. Dann müsste die Transformationsmatrix des Objekts irgendwo in seinen Instancevariablen zu finden sein. Frag mich aber nicht wo.
Alternativ würde ich darüber nachdenken, ob man irgendwie bewirken kann, dass mit der Maus deine subclassed Objekte aufgezogen werden. Das Teil, das das bewirkt, muss doch irgendwoher wissen, welches Klasse von Objekt gerade aufgezogen werden soll. Wahrscheinlich steht in den Instancevariablen irgendwo ein ClassPointer oder sowas. Den müsste man umbiegen.
OK, das ist jetzt vielleicht nicht wirklich hilfreich. Vielleicht fragst du auf dem treffen einfach mal Falk.
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

5

Freitag, 19. Oktober 2018, 19:30

<<Das GState des GrObjBody sollte immer die Eins-Matrix haben, weil sonst ALLE Objekte transformiert würden.>>

Sehe ich auch so.

<<dann würde ich die Transformationsmatrix in der VIS-DRAW des Objekts temporär ändern, um das Objekt transformiert darzustellen.>>

Wie gesagt, 'ne Vis_Draw gibt es nicht. Aber in der Library zu GrObj habe ich MSG_GO_DRAW gefunden. Die habe ich abgefangen und gleich nach der Abbildungsmatrix gefragt. Antwort auch hier leider nur die Identität.

Nach Überwindung der fehlerhaften Beschreibung der TransMatrix und der Geos-eigenen Darstellung einer Abbildungsmatrix kann ich per Code erstellte Objekte mit MSG_GO_TRANSFORM verschieben, skalieren und rotieren. Schon schön, aber das war's ja nicht, was ich eigentlich wollte.

Bleibt also Syhra...

6

Samstag, 20. Oktober 2018, 19:28

Vielleicht muss man ganz anders denken. Wozu brauchst du die TransMatrix? Sprich: kommst du evtl. auch anders an die interessanten Informationen?
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

7

Sonntag, 21. Oktober 2018, 09:53

Mein Ziel ist es, die geometrischen Daten von den Grundobjekten Linie, Rechteck, Ellipse und Ellipsenteil (Arc) auszulesen und umgekehrt auch manipulieren zu können. Linie, Rechteck und Ellipsen verhalten sich dabei gutmütig. Ein Arc dagegen kommt schon transformiert zur Welt und zeigt sich widerspenstig bis sprunghaft in der Transparenz seiner Daten. Dazu kommt, dass jedes Objekt in seinem eigenen Koordinatenraum lebt, also zwischen den Koordinaten im Objektraum und im Dokumentenraum unterschieden wird. Hier scheint die Transformationsmatrix eine zentrale Rolle zu spielen. Wenn ich diese Matrix für ein Objekt aktuell hätte, könnte ich vielleicht eher verstehen, was bei einer Manipulation des Objekts gerade passiert. Insbesondere am Beispiel des Arc-Objekts kann ich zeigen, dass die Reaktion des Objekts auf manipulation mitunter total verrückt zu sein scheint.

Wilfried

8

Donnerstag, 25. Oktober 2018, 10:06

Gstate ist ein Mysterium. Ich finde nirgends eine exakte Definition. Ok, es ist ein Handle, aber auf welche Tabelle verweist dieses Handle und wie sieht die Struktur aus, auf die der Tabelleneintrag wiederum zeigt?

Wilfried

9

Donnerstag, 25. Oktober 2018, 19:10

Die genaue Struktur des GState ist bewußt intern und nicht public, damit es sich mit der Weiterentwicklung von GEOS auch weiterentwickeln und verändern kann. Zum Auslesen und Reinschreiben benutzt Du die GrXYZ-Funktions-Schnittstelle.

10

Freitag, 26. Oktober 2018, 10:46

Hallo Falk,

<<Die genaue Struktur des GState ist bewußt intern und nicht public>>

für uns als Entwickler also doch ein Mysterium ;) .

Wie kann ich einem bestehenden GrObj eine Message schicken, die als Parameter den gstate fordert?

<<Zum Auslesen und Reinschreiben benutzt Du die GrXYZ-Funktions-Schnittstelle.>>

Das hab ich versucht: LineClass 'gesubclassed', per Code eine Linie der SubClass erstellt und rotiert, also transformiert. Dann MSG_GO_DRAW abgefangen, hier mit GrGetTransform(gstate,&tm) versucht, die Transformationsmatrix tm zu bekommen. Der GState wird ja von MSG_GO_DRAW mitgebracht. Ergebnis: Einheitsmatrix, also angeblich keine Transformation :( . Und dieser Weg lässt sich für nicht 'gesubclasste' GrObjs eh nicht gehen.

Wilfried

11

Sonntag, 28. Oktober 2018, 19:22

Hallo Wilfried,
ich hab hier mal einen ganz anderen Ansatz. Noch nicht vollständig durchdacht, aber vielleicht vielversprechend.
Wer erzeugt denn das GState, das du suchst? Ich denken, das ist das Content des View, vielleicht in MSG_META_CONTENT_VIEW_WIN_OPENED bzw. _OPENING. Oder es ist das View selbst oder das GrObjBody. Jedenfalls sind das alles Objekte, die du subclassen kannst und an der richtigen Stelle das GState Handle "abgreifen" kannst.

Vielleicht hilft es ja.
Und noch eine habe ich:
Wenn du MSG_GB_INSTANTIATE_GROBJ subclasst und den übergebenen ClassStruct Pointer umbiegst bevor du @callsuper rufst, solltest du gesubclasste GrObj Objkete erzeugen können. Es gibt da auch noch MSG_GROUP_INSTANTIATE_GROBJ
Und hier Nummer drei:
hast du schin versucht MSG_GB_DRAW ( /* XXX */
GStateHandle gstate = bp,
DrawFlags visDrawFlags = cl,
GrObjDrawFlags GODrawFlags = dx); anzuzapfen?
And finaly: Vielleicht hilft es ja das zu subclassen und das GState abzufangen:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@message GStateHandle MSG_GB_CREATE_GSTATE () = bp;
/*
 * 	For speed purposes the grobj keeps a cached gstate.
 * 	When something in the grobj requests a gstate we
 * 	create a gstate and copy the cached gstates transform
 * 	into the new one. This prevent us from having
 * 	to vup up the vis linking several more levels.
 * 	We don't use the cached gstate so that the caller can
 * 	function just as if it called GrCreateState and 
 * 	destroy the gstate when it is done.
 * 
 * PASS
 * 	nothing
 * 
 * RETURN
 * 	bp - gstate
 * 
 * DESTROYED:
 * 	ax
 */


Vielleicht findest du ja beim Durchsuchen des GrObjBody Headers noch andere vielversprechende Messages, die man anzapfen könnte.

Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

12

Montag, 29. Oktober 2018, 11:52

Hallo Rainer,

einzig MSG_GB_DRAW lässt ich abfangen. Aber auch in dieser Methode liefert der gstate stets nur die Einheitsmatrix. MSG_GB_INSTANTIATE_GROBJ und MSG_GO_DRAW lassen sich nur bei selbst per Code erstellten Objekten abfangen. Ich komme also nicht an das ClassStruct von mit der Maus aufgezogenen Objekten heran.

Auch mit MSG_GO_DRAW bei einem selbst erstellten Objekt liefert der gstate nur die Einheitsmatrix. Gerade hier hätte ich erwartet, dass es klappt, da ich glaube, dass der gstate individuell für jedes Objekt erstellt wird. Ob dieser individuelle gstate in einen Sammel-gstate vom Body aufgenommen wird? Dann müsste der Body wissen, welcher Teil zu welchem Objekt gehört und beim Anklicken dieses Objekts den gstate-Teil zur Verfügung stellen. das funktioniert mit MSG_GB_DRAW aber wie schon gesagt auch nicht.

Wenn doch bloß die GrObj-Library für mich besser lesbar wäre...

Gruß

Wilfried

13

Montag, 29. Oktober 2018, 21:15

Hallo Wilfried,
nach meinem derzeitigen Verständnis der Dinge (Arbeitshypothese) sollte das GrObjBody das gstate für die Anzeige der GrObj Objekte erzeugen. Wenn sich ein GrObj darstellt (letztlich via VIS_DRAW) muss es das gstate vom GrObjBody anforderen. Wenn das grObj transformiert ist muss es die entsprechenden Infos selbst irgendwo in seinen Instancedaten speichern. Es wendet dann seine eigene Transformationsmatrix auf das gstate vom GrObjBody an und zeichnet sich dann in das transformierte gstate. Damit erscheint es transformiert auf dem Schirm.
Von dieser Warte aus wäre es nur zu verständlich, wenn das gstate des GrObjBody eine Eins-Matrix als Transformationsmatrix enthält.

Die Idee mit MSG_GB_INSTANTIATE_GROBJ basiert auf der Überlegung, dass das Aufziehen mit der Maus irgendeine Message des GrObjBody rufen muss, nämlich (hoffentlich) genau diese. Dann könntest du nämlich folgendes machen:


Quellcode

1
2
if ( *class == &ArcClass) *class = &MySubClassedArcClass; 
@callsuper

Wenn ich das richtig verstanden habe sollte dann beim Erzeugen eines Arc-Objkets dein gesubclasstes Arc-Objekt angelegt werden, statt des originalen.Was denkst du?
Gruß

Rainer
P.S. Bei den Instancevariablen von GrObjClass gibt es eine Chunkhandle namens GOI_normalTransform. Dort würde ich die Transformationsmatrix suchen. Was GOI_spriteTransform soll, weiß ich nicht, klingt aber interessant ;-)
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

14

Dienstag, 30. Oktober 2018, 12:09

MSG_VIS_DRAW ist laut pmake keine MSG von LineClass 'or its ancestors'. Der GrObjBody verschickt MSG_VIS_DRAW beim ersten Klicken ins Dokument und dann bei jeder Aktualisierung des Dokuments (F5). Er tut es nicht, wenn ich ein Objekt aufziehe.

MSG_GO_DRAW wird (laut Swat) an das gerade aufgezogene Objekt verschickt, lässt sich aber nicht abfangen. MSG_GB_INSTANTIATE_GROBJ lässt sich ebenfalls nicht abfangen. Laut Swat wird sie gar nicht verschickt, wenn ich ein Objekt aufziehe, sehr merkwürdig.

Die Attribute (Farbe, Liniendicke, usw) werden vom GrafikObjectAttributeManager gesammelt, die Transformationsmatrix bleibt beim Objekt, das sehe ich wie du. Aber genau hier stoße ich mal wieder an meine Grenzen, weil ich nicht weiß, was ich mit der Instanzvariablen ChunkHandle GOI_normalTransform anfangen kann. ChunkHandle GOI_spriteTransform bezieht sich meiner Vermutung nach auf das, was man beim Aufziehen bereits sehen kann, bevor das Objekt beim Loslassen der Maus dann wirklich existiert.

15

Mittwoch, 31. Oktober 2018, 22:24

Hallo Wilfried
weil ich nicht weiß, was ich mit der Instanzvariablen ChunkHandle GOI_normalTransform anfangen kann.

Das sollte ein Chunk im Objektblock des Objekts sein, vermute ich ganz stark. Wenn du in einer Methode des Objekts bist (oself ist der optr des Objekts) solltest du so an die TransMatrix kommen (Code aus dem Kopf..)


Quellcode

1
2
TransMatrix *tm;  
 tm = LMemDeref(OptrToHandle(oself), pself->GOI_normalTransform);
MSG_GB_INSTANTIATE_GROBJ lässt sich ebenfalls nicht abfangen. Laut Swat wird sie gar nicht verschickt, wenn ich ein Objekt aufziehe, sehr merkwürdig.
Ja, sehr merkwürdig....
Gruß
Rainer
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

16

Donnerstag, 1. November 2018, 17:30

Hallo Rainer,

meintest du LMemDerefHandles? Hab ich eben probiert. Ergebnis: Wieder die E-Matrix, diesmal auch in der 3. Matrixzeile ein Zahlenwert. Dies Zeile ist für die Translation zuständig. Hatte das Objekt aber nicht verschoben.

Manche Geheimnisse lässt Geos sich einfach nicht entlocken ;( .

Wilfried

17

Donnerstag, 1. November 2018, 21:26

Hallo Wilfried,
weiß nicht, ob das ad-hoc weiterhilft:

Der Zeiger, den das zuletzt diskutierte LMemDeref liefert, zeigt auf eine Struktur von Typ ObjectTransform.

Viele Grüße,
Falk

18

Freitag, 2. November 2018, 10:57

Hallo Falk,

in der GrObj.def steht es so, wie du sagst. In der GrObj.goh so, wie bisher diskutiert. Ein Widerspruch?

Wilfried

19

Freitag, 2. November 2018, 16:35

Ich hab's mal ausprobiert:

ObjectTransform *tm;

tm = LMemDerefHandles(OptrToHandle(oself), pself->GOI_normalTransform);
@send E11::MSG_GEN_VALUE_SET_VALUE(MakeWWFixed(tm->OT_transform.GTM_e11.WWF_int),0);
.
.
.

Ergebnis: Immer die Einheitsmatrix, egal was ich mit dem Objekt anstelle.

Zur Zeit ist neben Ihnen 1 Benutzer in diesem Thema unterwegs:

1 Besucher

Thema bewerten