[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen
From: |
Immanuel Halupczok |
Subject: |
Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen |
Date: |
Thu, 01 Dec 2005 14:05:05 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20050602) |
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
--------------------------------------------------------------------------
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/01
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen,
Immanuel Halupczok <=
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Immanuel Halupczok, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Immanuel Halupczok, 2005/12/05
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/06
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Immanuel Halupczok, 2005/12/06
- Message not available
- Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Mark Weyer, 2005/12/06
Re: [Cuyo-devel] Vorschlag: unbewegliche Variablen, Bernhard R. Link, 2005/12/05