Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen

[Immanuel Halupczok]

Mark Weyer a écrit :
> > > Oh, eine Fehlerquelle. Werde heute abend mal schauen, ob das immer noch
> > > so ist, nachdem ich Koordinaten durch absolute Orte ersetzt hab, aber
> > > wahrscheinlich schon...
> >
> > ?? (absolute Orte = Datentyp, der alle Informationen ueber den Ort eines 
> > Blops enthaelt?) (Klingt gut)
>
>
> Ja. Im Gegensatz zu relativen Orten, die das ersetzen, was im Parser mal
> variablen_ort hieß, und eine Klasse Ort bilden, die die C++-Variante des
> Typs (ort_absolut -> ort_absolut option) sind.
>
> Die Fehlerquelle war übrigens zur harmlosen Hälfte realisiert. Im copy-
> Konstruktur wurde der Ort mitkopiert, im =-Operator nicht. Da für jede
> Anwendung des copy-Konstruktors bevor was wichtiges kommt noch einmal
> set_besitzer aufgerufen wird (was den Ort setzt), hat sich der bug nicht
> ausgewirkt.
>
>
> > Und die Variablen gar nicht in den Blob-Objekten speichern? Faend ich 
> > irgendwie unschoen.
>
>
> Aber es entspricht der Realität. Ortsfeste Variablen gehören eben nicht
> den Blops sondern ihren Positionen im Spielfeld (sonst wären sie nicht

Ok, ueberzeugt.

> ortsfest). Eine andere Sicht, die Du villeicht implizit hast, wäre, daß
> es zusätzlich zu den bisherigen Blops ortsfeste Blops gibt. Dann würden
> die die ortsfesten Variablen haben. Außerdem könnten sie ortsfeste mal-
> event-handler haben, so daß manche Dinge am Ort statt im Blop (nach
> bisheriger Sichtweise) geschehen. Das ist auch ein feature, das wir
> bestimmt schon oft verwendet hätten... Ich scheue mich aber ein wenig
> vor dem Performanceoverhead in Leveln, die das nicht brauchen. Wie
> würdest Du ihn einschätzen?

Uber die ortsfesten Blops hab ich auch schon mal nachgedacht. Waere 
zumindest konsequent, wenn auch die global-blobs blobs sind.

Performance-Overhead: Ich denke, wenn die of-blobs gar keinen Cual-Code 
ausfuehren, wird's nicht so schlimm sein. (Allerdings hab ich schon oft 
nicht-so-schlimm-Dinge hinzugefuegt, und auf die Dauer summiert sich das 
sicher.) Wirklich Angst hab ich nur, wenn jemand anfaengt, die of-blobs 
zu benutzen, d.h. wenn die auch alle noch Cual-Code ausfuehren.

Noch was: Die Bild-Stapel sind ja bisher noch in den Blobs drin. Die 
sollten dann auch eher an den Orten sein, insbesondere weil ja mehrere 
Blobs in die selben Stapel malen.

Und dann waere wieder zu klaeren: Wer malt zuerst, die of-blobs oder die 
 normalen?

Und: Will man als dritte sorte Blobs welche haben, die beim 
Reihe-rueberschieben mitwandern? Jetzt werden's langsam wirklich viele 
Blobs.


Aber jetzt nochmal generell: Ortsfeste blobs bedeutet: Alle Variablen 
existieren sowohl in Ortsfest als auch in orts-variabel. Ich glaube, das 
ist eine Menge unnoetiger Overhead. (So wie es eigentlich jetzt schon 
unnoetiger Overhead ist, dass die globalen Blobs die selben Variablen 
haben wie die normalen.) Und ausserdem: Der Variablen-Zugriff von einem 
variablen Blob auf den of-Blob an der selben Stelle wird syntaktisch 
vermutlich nicht so schoen.

Ausserdem (jetzt, wo ich drueber nachdenke): Wenn man ortsfeste 
Variablen hat, braucht man orstfeste blobs ueberhaupt nicht mehr. Wenn 
man was malen will, was an einem festen Ort ist, ist es voellig egal, ob 
zu was fuer eine Art Blob die Malroutine gehoert, so lange die 
Variablen, die sie verwendet, ortsfest sind. Mal abgesehen davon 
natuerlich, dass die Ortsfestmalroutine im Moment in jede Sorte 
geschrieben werden muesste. (Aber eigentlich hab ich schon lange das 
Gefuehl, dass die Existenz von verschiedenen Sorten mehr oder weniger 
nur eine grosse switch-Anweisung ist, und auf lange Sicht sollte man dem 
Leveldesigner irgendwann ueberlassen, ob und wie er diese 
switch-Anweisung wirklich haben will.)

Ich versuche, zusammenzufassen, wie eine ideale Cuyo-Welt (nach meinem 
aktuellen Wissensstand) aussehen wuerde:
- Bei Variablen-Deklarationen gibt man die Geschmacksrichtung an:
  normal-beweglich / halb-ortsfest / ortsfest / semi-global / global
  (/ evtl. weitere)
- Es gibt Events, die Code ausfuehren. In Abhaengigkeit vom Event
  kann bekommt der Code verschieden detaillierte Informationen ueber
  seinen Ort. (global-step-Event bekommt gar keine Information,
  draw-Event bekommt x,y,spieler,fallend?.)
- Variablen-Zugriff und malen kann (je nach Variablen-Typ)
  Ortsinformation benoetigen. Default ist vom Event mitgelieferte
  Ortsinformation (so sie existiert.)
- Das, was bisher Sorten waren, bedeutet lediglich, dass fuer alle
  Events mit Orts-Information ein grosses switch nach der Variable kind
  eingefuegt wird. (Syntaktisch koennen Sorten aber ruhig so bleiben
  wie bisher (so lange niemand eine bessere Idee hat).)

Was genau "Blob" in dieser Welt bedeutet, ist mir nicht ganz klar.
Entweder, man verwendet "Blob" nur noch fuer die normal-beweglichen 
Dinge (und also nicht mehr fuer den Global-Blob), oder (vermutlich 
besser) "Blob" gibt es auch in den verschiedenen Geschmacksrichtungen, 
wobei allerdings Zuweisungen/etc. nur innerhalb einer Geschmacksrichtung 
erlaubt sind.


Haelst du diese Idealwelt-Beschreibung fuer brauchbar? Wenn ja, wuerde
ich vorschlagen, dass man sie einfach bei allen 
Aenderungen/Ergaenzungen, die man macht, im Hinterkopf behaelt, um sich 
ihr so mit der Zeit anzunaehern.

        Immi

> > Anderer Vorschlag: Normaler Copy-Constructor kopiert auch diese 
> > Variablen nicht mit, und an der Stelle im Programm, wo die Blops wegen 
> > Reihe-rueber in den Arrays senkrecht verschoben werden mit einer anderen 
> > Methode diese Variablen doch noch kopieren.
>
>
> Oder dann statt durch eine Methode durch den Reihe-rüber-event-handler
> der ortsfesten Blops.
>
>   Mark
>
> P.S.: Deine Einträge im Changelog (also bei cvs commit) sind Englisch.
>   Soll ich das auch so machen?
>
>
>
> _______________________________________________
> Cuyo-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/cuyo-devel


--

--------------------------------------------------------------------------
    Immanuel Halupczok       www.karimmi.de       www.croco-puzzle.com
--------------------------------------------------------------------------