Ferien sind toll. Da das keine weitere Erklärung benötigt ist das heut einfach mal der WLog Titel, da ich nicht weiss, was aus den 2 Monaten () ohne Eintrag das wichtigste Neue ist.

Zuerst ging es recht schleppend mit den inzwischen 3 gleichzeitigen Projekten (Vorx.Engine, The Vorx selbst und Vorx.Editor) voran.

Als dann aber mein Router den Geist aufgab gepaart mit der Unfähigkeit der Telekom mir innerhalb von 20 Tagen einen neuen zukommen zu lassen, liess der Fortschritt nicht lange auf sich warten.
Und jetzt sind eh Ferien ich hab also endlich mal Zeit.

Wobei ich leider im Moment nicht so genau weiss in welche Richtung es weitergeht.

Doch zuerst die Neuerungen (wenn möglich geordnet und klar strukturiert dargelegt...)

Vorx.Editor:

Das Interface wurde stark verändert/vereinfacht



Es gibt jetzt zum Beispiel kein Menu am oberen Rand und keine Status Leiste am unteren Rand.
Letztere, weil sie nicht gebraucht wird, ersteres, weil es durch ein mauslastigeres System ersetzt wurde.

Ein Beispiel: Anstatt über Map -> Tile -> LoadTileset ein Tileset zu laden, reicht es nun die betreffende Datei irgendwo im Editor per Drag 'n' Drop abzuwerfen, sie wird dann automatisch in der Images Node des GameManager Trees gespeichert. Moment mal das ist doch gar kein Image! Es gibt doch extra eine Tileset Node!?

Das ist richtig. Möchte man ein geladenes Bild als Tileset oder als Animation aufbereiten lassen (so dass der Editor nachher mit umgehen kann), so reicht wieder ein Draggen und Droppen der Datei aus dem Game Manager Tree in eine der Arbeitsflächen.

Wirft man das Bild z.B auf die MapEditor Arbeitsfläche, so wird es als Tileset geladen und landet dann auch im richtigen Ordner. Wirft man es stattdessen auf die (hypothetische) Animations Editor Fläche, wird es als Animation interpretiert.

Es wird sich zeigen ob diese Bedienung allen Leuten so einfach fällt.


Maps werden einfach auf die MapEditor Fläche gezogen, erscheinen dann dort und können bearbeitet werden.


Integrieren von neuen Dateien:

1.) Neue Grafiken, Textdateien und Sounds liegen im Projekteordner.
2.) Vorx.Editor öffnen, alle Dateien markieren und in den Game Manager ziehen.
3.) Der ordnet sie (siehe oben) nach Format in die richtigen Ordner ein

Nächste Neuerung:

Platzieren und Editieren von Entities (mehr dazu demnächst)

In seiner jetzigen Version (0.0.1) hat der Editor zwar noch längst nicht volle Funktionalität, aber läuft stabil und lässt sich (meiner Meinung nach) super bedienen.



--------------------------------------------------------------------------------------------



Vorx.Physics:

Nun wie soll ich anfangen: ES FUNZT VERDAMMT NOCHMAL! ENDLICH!
Boaah. Was habe ich in Tische gebissen wenn die hässligen Kisten sich mal wieder mit Überlichtgeschwindigkeit verabschieden

Nunja Version 1.0 ist stabil, nicht perfekt, aber sieht gut aus

Dazu ein paar Bildchen:

Jump'n'Run Test


Der schlanke weisse Kasten repräsentiert übrigens den "Spieler", der per Leertaste in die Luft befördert wird. Das Ganze diente eig nur dazu um zu gucken wie die Kollision mit statischer Geometrie funktioniert.

Shooting Test + armselige Texturierungsversuche:


Der Test war relativ schwer zu implementieren, da ich erstmal das richtige Verhältnis zwischen Gewicht und Geschwindigkeit der Kugeln finden muss. Aber es sieht ganz gut aus.

Der letzte Test kommt einer realen Anwendung am nächsten:
Cs2D PhysX :


Hier spielen Vorx.Engine, Vorx.Maps und Vorx.Physics recht gut zusammen.
Die Map wurde im Editor erstellt, lediglich die Kisten werden noch "inGame" platziert.
Der weisse Kreis ist hier der Player, der auf die Kisten schiessen kann.

Soweit so gut. Ich hab keine Lust mehr zu schreiben, ich hoffe aber auch das der nächste Eintrag nich wieder 2 Monate später kommt.

Daher schonmal frohe Feiertage (:
ComNik

Guten Morgen BBP!

Nach etwas längerer Zeit kann auch ich wieder Fortschritte vermelden: Vorx.Script ist jetzt (zumindest so wie ich das aktuell überblicken kann) fertig. Wenn es noch Bugs gibt, die ich nicht schon gefixt habe, dann werde ich natürlich noch daran arbeiten..

Es wird jetzt noch das Modul BaH.MuParser benötigt, um Vorx.Script nutzen zu können, da ich für das Parsen von mathematischen Ausdrücken ebenjenes Modul nutze. (Ein Eigenes schreiben wollte ich schlicht und einfach nicht)
Herunterzuladen gibt's das Modul BaH.MuParser hier.

Was ist hinzugekommen:
Mathematische Ausdrücke (man kann in ihnen allerdings nur Scriptvariablen und Zahlen nutzen)
Verzweigungen (einfache If-Verzweigungen, mehr wäre möglich, aber nicht notwendig)
Bugfixes

Ich habe nochmal alles schön zu Paketen geschnürt:
Vorx.Script, das Modul
Vorx.Script Testpaket (sowohl Source als auch eine .exe sind enthalten).

Über Feedback bzw. Kritik würde ich mich freuen. (:

mfg, n-Halbleiter

EDIT: Ich habe noch einen Fehler in der Dokumentation entdeckt. Das neue Paket zu Vorx.Script ist hochgeladen und der Link ersetzt.

Guten Tag,

meine Güte liegt der letzte Eintrag schon zurück

Es ist aber auch einiges dazwischengekommen. Trotzdem ging es immer stetig voran und davon soll ja schliesslich auch der heutige Eintrag handeln.

Erstmal kurz zur Verspätung: In letzter Zeit beschäftige ich mich nebenbei/hauptsächlich mit zwei Wettbewerben: 1. Bundeswettbewerb Informatik und 2. Google AI Contest. Wobei 1. eher Fleissarbeit ist :/

Wenn ich an The Vorx / der Vorx.Engine weitergearbeitet hab, dann nur am Editor.

Man kann im Moment:

Maps erstellen
Bilder und Tilesets laden
geladene Assets in der "Game Manager" TreeView verwalten
Bilder direkt im Editor anschauen.
Entity Komponenten bearbeiten

Dazu mal ein paar Bilder:

Dropbox Gallery

Als nächtes kommen ein paar Tools für genügend Komfort, z.B:

Rect Fill (füllt einfach einen per Maus markierten Bereich mit dem gleichen Tile)
Random Set (setzt bei jedem klick ein zufälliges Tile aus einer vorher ausgewählten Menge)
Pick (wählt das Tile an der jetzigen Mausposition
diverse Masken

sowie die restlichen Speicher Methoden.

Für The Vorx arbeite ich gerade an einem kleinen Test für Goal Oriented Action Planning.

Das Programm kriegt quasi eine Menge Funktionen und ein Ziel, wobei alles mit Bedingunen und Effekten verknüpft ist. Danach soll das Programm eine Reihe von Funktionen ausgeben, die a) zum Tiel führen und b) erlaubt sind, also alle Bedingunen zum Zeitpunkt der Ausführung erfüllt sind.

Ein Beispiel:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Bedingung für WaffeFeuern() wäre z.B das die Waffe geladen ist. Effekt das ein Ziel tot ist.
(Hier kann man natürlich auch Wahrscheinlichkeiten einbringen).

Nachladen() hat keine Bedingung, aber den Effekt das die Waffe geladen ist.

GeheZu() hat keine Bedingung, aber den Effekt das Self an (x,y) steht.

Ein einfacher Aktionsbaum wäre nun:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Das schöne an der Sache ist nun, dass der Npc ohne Ifs nachlädt, wenn er seine Waffe feuern will und sie nicht geladen ist.

Auch ist das ganze sehr flexibel. Mehr Aktionen einbauen und Kosten errechnen lassen machen den Algorithmus schon sehr viel interressanter.

Zum Beispiel könnte man eine große tödliche Waffe neben den Npc stellen, ihr geringere Kosten für WaffeFeuern() zuschreiben, eine Funktion WaffeWechseln() oder WaffeAufheben() schreiben und als Bedingung zum Beispiel setzen, dass der Situationsbewertungs - Algorithmus ein "Gute Situation" oder "Keine Gefahr" zurückliefert.

Dann würde der Npc hinrennen, schauen ob mann auf ihn schiesst und wenn nicht, in aller seelenruhe die Mörderwaffe aufheben und auf das arme Ziel entladen.

Die Möglichkeiten sind unendlich

Und damit komm ich auch schon zum Ende, mehr zu GOAP in einem der nächsten Einträge.

Ein schönes Restwochenende noch,
ComNik

Guten Abend BBP!

Auch von mir gab es längere Zeit nichts, was wohl daran lag, dass ich mich durch zwei nervtötende Features schlagen musste (direkte Wertzuweisungen von Feldern und Funktionen). Aber jetzt ist das getan, und Vorx.Script geht in die Version 1.7. (:

Was ist nun dazugekommen?
Funktionen inkl. Rückgabewerte
Scoping (globaler und lokaler Scope pro Funktion)
Wertzuweisungen von Feldern
Globale Variablen werden mit "Global" deklariert, die Syntax sonst bleibt erhalten
Mehrere Variablendeklarationen pro Zeile

Und ich habe noch etwas Performance herauskitzeln können.

Das soweit zur neuen Version, hier die Downloads:
Links entfernt, siehe weiter oben für neue Versionen.

Nochmal, zur Info: Zum selbstkompilieren wird eine Modifikation von BRL.Reflection benötigt, die gibt's hier.

Falls sich noch Fragen ergeben, fragt.

Soweit von mir und meinen kleinen Fortschritten, als Nächstes kommen mathematische Ausdrücke und Verzweigungen.

mfg, n-Halbleiter

Einen wunderschönen guten Abend nach längerer Zeit!

Nein, mit dem neuen Spielzeug ist nicht etwa Starcraft 2 gemeint (*produktivitätskiller*) sondern
der Vorx.Editor passend zur Vorx.Engine.

Ich gebe erstmal einen Umriss was der Vorx.Editor so ist und kann, danach gibts ein paar Bilder zu sehen.
Eins vorweg: Die momentane Version läuft unter der Bezeichnung "Visions Prototyp" Es ist also noch wenig High Level funktionalität drinn.

1. Wozu einen Editor?

Wer die Spielebranche ein wenig verfolgt hat, wird mitbekommen haben, dass Programmierer immer mehr zu Editor schreibern werden, mit denen Designer dann ganze Spiele erstellen können. Da ich von Physik Optimierungen die Schnauze voll hatte dachte ich mir ich probier das doch auch mal aus.
Praktischerweise wurde ja letztens erst die MaxGUI kostenfrei veröffentlicht, also entschloss ich mich mir die mal anzuschauen. - Und ich bin positiv überrascht! Bis auf die unglaublich dämlichen Tabber Gadgets -.- (danke an BlitzCoder, dessen Erweiterung mir das Schreiben einer eigenen erspart hat...)


2. Was soll der Editor können?

Der Editor ist streng modular aufgebaut, dass hört man zwar immer aber ich werde es trotzdem erklären:

Jede Komponente für den Editor (z.B Map bearbeiten, Scripts schreiben oder Entities erstellen) wird in eine eigene von TModule abgeleitete Klasse gepackt (z.B TMapEditor, TScriptEditor oder TEntity/TPropertyEditor). Module haben eine tabId um zu wissen wann sie geupdatet werden sollten, oder ob sie immer geupdatet werden müssen.

Desweiteren hat jedes Modul einen Tab auf dem sogenannten Editor Tabber (sozusagen die Arbeitsfläche links vom Splitter, siehe Bild) und auf dem UI Tabber (die kleinere Fläche rechts vom Splitter).

Das Modul muss nichts davon benutzen, kann aber. Auf dem Bild hier sollte das deutlich werden:



Wie man erkennen kann, ist im Moment auf dem Editor Tabber das Map Editor Modul geöffnet, allerdings auf dem uiTabber, der vom TVorxEditor - Hauptmodul herstammende, Content Manager (oder auch Game Manager).

Durch diverse Kontextmenüs, läd man sich später alle Game Assets in die richtigen Unterordner, oder erstellt neue wenn was fehlt. Die Kontextmenüs verbinden übrigens auch eventuelle, im Editor erstellbare Assets wie Maps oder Entities mit den dazugehörigen Modulen (wie man auch auf dem Bild sehen kann, entweder eine Map laden oder einfach direkt eine erstellen).

Hierbei muss allerdings gesagt werden, dass die Map Engine noch nicht eingebunden ist, daher kann mann Maps noch nicht erstellen.



EDIT: Natürlich sind DC's Tilesets nur zum testen drinn!

Um möglichst viel Verschiedenes auf ein Bild zu bekommen, ist hier gleichzeitig ein geladenes Entity mitsamt den Map Tools dargestellt. Unter "Tiles" setzt man wieder erwarten Tiles, unter "Entities" alle anderen Objekte (da ja alles ein Entity ist ) und unter Sections wird die Map in im Spiel ansprechbare Bereiche eingeteilt.

Man kann alle Fields eines Komponenten schön übersichtlich über die Tabs bearbeiten und dann speichern.

Alles in allem wird es wohl noch mindestens ein, zwei Wochen (Schule :@) dauern, bis es eine Alpha Version mit mehr High Level funktionalität gibt.

Übrigens wird das einzige Feature, dass den Editor an die Vorx.Engine bindet sein, dass man das Level aus dem Editor heraus testen kann. Wenn man den Editor für andere Engines oder Spiele nutzen will ist das kein Problem, solange man Bah.Persistence nutzt, oder mit .txt Dateien vorlieb nimmt. Und notfalls kann man ja jederzeit ein neues Modul hinzufügen, oder vorhandene abändern.

Das wars von mir,
Gute Nacht (:

Eins vorweg: Dieser Eintrag wird langweilig für die, die kein Interresse an Low Level Optimierungen, Mathe im Allgemeinen oder an langen Erklärungen haben. Nächstes mal kommt wieder was zum Spiel

Huhu,

nun VMath ist ein neues SubModul der VorxEngine, warum es nicht einfach Vorx.Math heisst, sondern VMath?
Erklär ich sofort, erstmal zum (total spannenden) Inhalt.

VMath stellt Vector2, Matrix2 (2x2), Rect und Line bereit, zusammen mit vielen kleineren (Hilfs-)Funktionen.

Nun zum etwas *besonderen*: VMath unterstüzt ein nicht ganz so coderfreundliches optimiertes Interface um ein Float[2] Array als Vektor zu benutzen wobei [0] = x und [1] = y sind.

Warum nennt sich das optimiert? Nun, primitive Datentypen sind vom erzeugten Assembler Code immer schneller (respektive weniger umfangreich = weniger Asm Befehle = schnellere Laufzeit). Natürlich macht das nicht die Welt aus aber es wenn Millisekunden zählen, kann sich selbst so etwas minimales bei Vekotraufwändigen Sachen bezahlt machen.

Und was noch viel besser ist: Wenn unser Assembler / Compiler gnädig ist, optimiert er unsere Float Arrays in __m128 SIMD Datentypen.

Für alle die es interressiert und die es noch nicht wissen:

SIMD = Single Instruction Multiple Data ist eine fest im Prozessor verbaute Technik, die es erlaubt ein Float[4] Array mehr oder weniger gleichzeitig zu berechnen das heisst, alle Elemente des Float Arrays zu addieren würde in etwa so viel Zeit einnehmen wie das addieren einer Float.

Das ganze wird also ~4 mal schneller, solange es der Prozessor unterstützt. Um in C++ direkt SIMD schreiben zu können muss man den __m128 Datentyp nutzen, normale Float[4] Arrays werden nicht immer vom Compiler optimiert. Möchte mann nun mit den Fake Vektoren rechnen, so behilft man sich mit Compiler Intrinsics (die automatisch unterstützt werden, wenn SIMD unterstüzt wird). An die C++er
unter euch: "mmintrinsics.h" sollte (wenn ich nicht irre) die nötigen Intrinsics zur Verfügung stellen.
Intrinsics sind übrigens meistens schneller als Inline Assembler.

Aber ich will mich hier nicht in C verlieren sondern komme zurück zu BlitzMax. Ich habe einen kleinen Test gemacht, der in etwa so aussah:

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

SuperStrict

Import Vorx.VMath

Global v1:Vector2 = Vector2.Create(100.0,100.0)
Global v2:Vector2 = Vector2.Create(100.0,100.0)

Global time:Float = MilliSecs()
For Local i:Int=0 Until 1000000
	v1.Dot(v2)
	v2.Perp()
	v1.Perp()
	v2.ScalarMultiply(2)
Next
Print(MilliSecs()-time)

In diesem Test wird das ganz normale nutzerfreundliche Vector2 benutzt. Eine Millionen mal irgendwelche zufälligen, nicht sehr rechenaufwändigen Vektor Operationen.

Die Ausführungszeit liegt (auf meinem I7) bei durchschnittlich 1500 Ms.

Ersetzt man den Test nun durch:

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Global v1:Float[] = [100.0,100.0]
Global v2:Float[] = [100.0,100.0]

Global time:Float = MilliSecs()
For Local i:Int=0 Until 1000000
	vDot(v1,v2)
	_vPerp(v2)
	_vPerp(v1)
	vMul(v2,2)
Next
Print(MilliSecs()-time)

Die Aktionen sind genau das gleiche, allerdings haben wir nun eine durchschnittliche Laufzeit von 450 Ms!
Das sind etwa 60% der Zeit, die der *normale* Ansatz benötigt.

Man beachte hier, dass sowohl das Skalarprodukt (vDot()) und die Skalarmultiplikation (vMul) an beiden Indizes des Float[] Arrays werkelt. Fügt man der Schleife zwei Normalisierungen hinzu, sieht das ganze schon anders aus, da die Wurzel nicht durch SIMD optimiert werden kann, sondern nur die anschliessende Dimension. Mit Normalisierung ist der Geschwindigkeitsgewinn nur noch 30% (allerdings ohne schnelle Wurzel Funktion, sondern mit der Standard Sqr()).


Das wars für heute, ich hoffe es war wenigstens für manche interressant
Nächstes mal gehts wieder um was spannenederes...

lg
ComNik

Guten Morgen BBP!

Die letzten Tage war ich fleißig und habe nun auch etwas kleines zusammengehackt: Version 1.5 des Scriptsystems von The Vorx (sofern es wirklich übernommen werden sollte).

Es beinhaltet ein paar kleine Änderungen gegenüber des alten Scriptsystems:
Es ist schneller
Variablen werden mit "Var [Variablenname] -> [Variablentyp]" deklariert ( [...] sind die Platzhalter )
Sämtliche Aufurfe von "Call: " und "Invoke: "entfallen
Wertzuweisungen funktionieren jetzt wie von BlitzMax gewohnt mit einem "="
Primitive Datentypen sind jetzt möglich. Ferner sind "True" und "False" als Parameter zugelassen und werden auch korrekt behandelt

Die weitere Syntax ist denkbar einfach: Wer schonmal mit BlitzMax gearbeitet hat, wird wohl wissen, wie man Methoden und Funktionen von Types mit Parametern aufruft. Genauso geht's auch hier.

Mehr fällt mir jetzt spontan nicht ein. Was noch nicht möglich ist sind das direkte Setzen von Feldern, Funktionen (eventuell auch später Klassen, wer weiß) im Script, mathematische Ausdrücke und Verzweigungen. All das ist geplant und wird schnellstmöglich umgesetzt, und zwar in dieser Reihenfolge.

Im Script kann man alle Types mit Funktionen, Methoden und Feldern nutzen, die importiert oder inkludiert werden. So ist es theoretisch auch möglich, aus dem Script heraus einen anderen Script zu starten (theoretisch deshalb, weil ich es noch nicht getestet habe).

Genug geschwafelt, hier das Modul (schon vorkompiliert im Debug- und Releasemodus für Win32, Singlethreaded): Link entfernt, siehe weiter oben für neue Version

Und ein Test (im Paket enthalten: "Test.debug.exe" zum schnellen Ausführen, "Test.bmx" zum Ansehen, ein Ordner "Test_Imports" für alles, was gebraucht wird und "Script.txt" als Script selbst):
Link entfernt, siehe weiter oben für neue Version

Ich möchte hiermit zum Ausprobieren und Rückmelden anregen.

Es kann sein, dass sich das Programm unter gewissen Umständen mit einer "Exception_Access_Violation" verabschiedet, ich weiß nicht genau, woran es liegt, aber es könnte am Reflectionmodul liegen, das verwendet wird (eine Modifikation von BRL.Reflection, zu finden hier). Ich werde der Sache auf den Grund gehen.

Sollten sich weitere Fehler ergeben, bitte die Scriptdatei und die (eventuell) modifizierte bmx-Datei per PN an mich senden. Mal sehen, was sich machen lässt.

mfg, n-Halbleiter

Gute Nacht

tut mir leid für den blöden Titel, ich bin zu müde für einen kreativeren, aber ich wollte euch auch die neusten Features von Vorx.Physics vorenthalten, zumal Cloth/Verlet Simulation ja hier gräd mächtig in Mode kommt <.<

Ja also Wabbel ist genau das was Verlet simulierte Körper machen, vorrausgesetzt man spielt an der Joint Elastizität rum, aber egal ich greife vor, eins nach dem anderen:

1.) Ein Bildchen:


2.)
Wie man eventuell erkennt, hat Vorx.Physics nun auch eine TCSoftBody Komponente. Erstellen und simulieren geht etwas anders von der Hand als Rigid Bodies :

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Global entity:TEntity = TEntity.Create(400,300)
entity.AddComponent(TCSoftBody.Create(4,6))
Global body:TCSoftBody = TCSoftBody(entity.GetComponent(CT_SOFTBODY))
body.AddParticle(350,250)
body.AddParticle(450,250)
body.AddParticle(450,350)
body.AddParticle(350,350)

body.AddJoint(0,1,40)
body.AddJoint(1,2,40)
body.AddJoint(2,3,40)
body.AddJoint(3,0,40)
body.AddJoint(0,2,40)
body.AddJoint(1,3,40)

Ich werde aber noch ein an der User Freundlichkeit schrauben. AddJoint nimmt als Parameter übrigens die Indizes der Partikel 0 ist also der zuerst hinzugefügte, 3 der letzte.

Dann wird in der Main Loop mit:

BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

For Local s:TCSoftBody = EachIn VPhysics.softBodies
	s.Update(dt)
			
	For Local s2:TCSoftBody = EachIn VPhysics.softBodies
		If s <> s2 
			VPhysics.VCollide(s,s2) 
		End If 
	Next
		
	s.Draw()
Next 

Diese ganzen Schleifen werden übrigens später einfach per VPhysics.Simulate() oder so verkürzt.

Wie man sieht, werden SoftBodies direkt in der Funktion VCollide (die auch nur für SoftBodies zu gebrauchen ist) Kollidiert. Demnächst baue ich ein, dass Rigid Bodies mit Soft Bodies kollidieren können.


Nun ja also es funktioniert super, ich hab jetzt noch keinerlei Optimierungen drinn (ich schreib auch erst ne Stunde oder so drann, Strand geht vor (, außer AABBs.

Joa, ich denke mal in den nächsten Tagen/Wochen, gibt es ein paar "ausprobierbare" Physik Spielereien (mir gefallen Wippen ganz gut, jedenfalls bei den Rigid Bodies...).

Außerdem experimentiere ich gerade mit "reißenden" Verbindungen bei den SoftBodies, damit eventuelle 2D Cloth Simulationen (Cloth in 2D, naja egal) auch schönen reißenden Stoff bekommen...

Ok, ich streiche jetzt erstmal einen dicken Punkt der ToDo Liste und gehe Schlafen (:

Allen einen guten Morgen! (Zeitverschiebung rocks)

Guten Abend BBP.

Die Grundsteine des Scriptsystems sind gelegt, ein Script der Version 1 könnte zum Beispiel folgendermaßen aussehen:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Mit "//" sind Kommentare.
Folgende drei Optionen stehen pro Zeile zur Verfügung:
Var: Eine neue Variable wird eingeführt. (Intern wird alles als Object gehandhabt, deshalb sind keine primitiven Datentypen (Int, Float, Byte, ...) möglich
Invoke: Eine Methode/Funktion eines Types aufrufen, die einen Rückgabewert hat. Der Rückgabewert wird in der Variable nach dem Pfeil (->) gespeichert.
Call: Eine Methode/Funktion eines Types aufrufen, die keinen Rückgbewert hat.

Weitere Eigenschaften:
Sämtliche Variablen müssen irgendwo im Script deklariert werden.
Man kann auf dem Weg zu einer Methode auch beliebig auf Felder und/oder Methoden bzw. Funktionen zugreifen. Das funktioniert auch dann, wenn eine Methode nichts zurückgibt, zum Beispiel, wenn man im Voraus Berechnungen anstellen will.

Möglich wird das alles durch die wunderbare Möglichkeit der Reflections. Für Funktionen gibt es die Modifikation hier. Damit sind noch ein paar mehr schöne Dinge mit Reflections möglich, die sonst nicht funktionieren würden.

So viel zur Version 1, das ist alles bisher nur ein Test, ich muss mir noch Gedanken dazu machen, was ich modifizieren muss.

mfg und gute Nacht, n-Halbleiter

Guten Abend,

Gestern und Heute waren zwei sehr produktive Tage, ich werde die Ergebnisse gleich mal zusammenfassen und dann kurz was zum neuen Team (n-Halbleiter und ich) sagen.

Zuerst mal die Erfolge:

Vorx.Physics unterstützt dank darth nun korrekte Impulse
Zudem werden nun tangentiale Impulse unterstützt
(an diesem Punkt war mein Kopf explodiert, gottseidank gibts hier so viel Sonne und Meer )
Ich habe eine neue Optimierung drinne: best case: keine Zeit für Integration benötigt (nur bei statischen Szenerien), average case: ca 50 % weniger Dauer für den Integrationsteil, worst case, keine Beschleunigung für die Integration


Zudem arbeite ich gerade an einer Geometrie Optimierung, es wird (hoffentlich?) möglich sein ohne mehr Speicherbelastung belieb viele Objekte gleicher Geometrie (also z.B eine Kiste oder ein Partikel) zu erstellen (Geometry Cloning). Das klingt relativ einfach ist aber wesentlich komplizierter korrekt umzusetzen...

Diese Art Optimierung wird extrem nützlich für z.B Wasser Simulationen, wenn man tausende gleicher Wasserpartikel simulieren will, der Speicher wird nicht belastet (zu gunsten wirklich minimaler CPU Auslastung).

Wie Calvin mir bestätigen konnte (bzw ich ihm staunend bestätigte), schafft die Simulation im Debug Modus gerade gute 300 Objekte bei ca. 90-100 FPS (Framebegrenzung ist 100). Als härtetest habe ich gerade 400 Objekte auf ziemlich engem Raum (das erhöht die worst case wahrscheinlichkeit der Optimierung) erstellt und hatte immernoch 30 FPS. Und man muss bedenken, dass die Simulation noch ohne jegliches BSP arbeitet und nicht testet ob Objekte beim zeichnen noch auf dem Bildschirm sind...

Nunja, jetzt noch schnell zu "Warping Cows", vllt hat jemand das Video gesehen (eine Folge von =3), der Name fiel mir vorhin ein. n-Halbleiter wird diesen Worklog jetzt auch von Zeit zu Zeit beschreiben, allerdings nicht zum Spiel, sondern zu einer Scriptsprache, die er für das Dümpel-Vorx Framework Mischmasch erstellt, ihr werdet schon lesen (hoffe ich doch ).

Jetzt bin ich aber auch in Amerika müde und morgen geht es schliesslich früh wieder ins Meer, also hör ich jetzt mal auf (:

Gute Nacht und motivierte lg
ComNik