ZFX + Developia

Ich hatte anhand des aktuellen Acknex Contests mal wieder ein wenig Lust bekommen, was zusammenzubasteln.

Zielvorgaben waren:
- alles was bei der Standardinstallation von A8 dabei ist, darf benutzt werden (Templates, etc.)
- es dürfen beliebig viele eigene Ressourcen eingebunden werden (Modelle, Levels, Sprites)
- Das selber geschriebene Script darf allerdings maximal 5kb groß sowie 200 Zeilen lang sein (A8 Template Code zählt nicht rein in das Limit)

Die Idee:
Ja... zunächst hatte ich erstmal keine.
Dann hatte irgendwer im Acknex Forum eine alte Demo ausgegraben, die ich vor Ewigkeiten mal in wenigen Tagen für einen Dusmania Fun Contest zusammengeworfen hatte.
Das Ding nochmal angeschaut..... hmmm... ja, das lässt sich nochmal verwerten.
--> Das wird auf 5k Source Code runtergewurschtelt!
Ist nicht wirklich originell, aber da ich nun bis zum Einsendeschluss still gehalten hab, ist es hoffentlich ein schöner Fun Entry für alle, die schon längere Zeit die Engine benutzen.

Die Aufgaben:
- Das Original lief in A5 mit C-Script, Ziel ist A8 mit Lite-C. Etwas Konvertierungsarbeit.
- Kleinschrumpfen von 45kb Code auf 5kb Code
- Aufmotzen der Grafiken, copyright geschütztes Material entfernen
- Natürlich müssen bei kürzerem Code auch mehr Features rein, also noch ein paar Kleinigkeiten einbauen
- Die Standardshader durchschauen, ob sich irgendwas sinnvoll verwerten lässt
- Ein paar Easter Eggs für Acknex Kenner müssen natürlich rein

Bilder:
wegen der Größe nur Thumbnails und verlinkt

http://i42.tinypic.com/3522iyv.jpg


http://i43.tinypic.com/2dwbuyg.jpg


http://i39.tinypic.com/2v9510h.jpg


http://i39.tinypic.com/oqf2oy.jpg

Code:
http://pastebin.com/2acWk9CN
Benötigt die Ressourcen und eine Acknex 8.20.1+ Installation. Ein normaler C Compiler wird sich beim Kompilierungsversuch umgehend beschweren :)
Mir ging der Platz recht schnell aus, deswegen ist das eigentlich nur noch obfuskiertes irgendwas.

Download:
http://www.opserver.de/coni_users/web_u ... rected.zip (35MB)
Enthält sowohl den Source als auch eine gepublishte Version, welche hoffentlich auf den meisten Rechnern problemlos läuft.

Youtube:
http://www.youtube.com/watch?v=FDCaweuBtIg
Sieht leider etwas ruckelig aus, da kkapture irgendwie Probleme mit dem Sound der A8 hat. Deswegen habe ich MSI Afterburner für ein Live Capture verwendet.
Im Zweifelsfall lieber die Realtime Version anschauen.

Credits:
Die Musik kommt von Nightbeat - er wurde von mir damals explizit kontaktiert und kennt auch die Ur-Version von 2001.

Schöne Demo.
Also das mit dem unity/Acknex war richtig gut :D
Ansonsten: Muss man sich sehr anstrengen, um derartig unleserlichen Code zu schreiben? :D Also, hast du das vorher normal geschrieben und dann gehofft, dass du durch die ganzen defines unter die 5kb kommst? Was würde passieren, wenn du am Code nochmal was ändern müsstest? :D

Jo gefällt mir auch gut.

Ich glaube es gibt ne ganze Reihe Programme, die den Code so "packen" können oder? Also für JS kenne ich jedenfalls einige.

Jonathan hat geschrieben:Schöne Demo.
Also das mit dem unity/Acknex war richtig gut :D
Ansonsten: Muss man sich sehr anstrengen, um derartig unleserlichen Code zu schreiben? :D Also, hast du das vorher normal geschrieben und dann gehofft, dass du durch die ganzen defines unter die 5kb kommst? Was würde passieren, wenn du am Code nochmal was ändern müsstest? :D

Danke :)

Ich weiß nun, wie man in etwa die Matrix liest.

Man muss ein gewisses Gefühl dafür haben, wie man den Code kleinschrumpfen kann.
Meine grobe Rechnugn war ich schaffe ca. 50% noch wegzuoobfuskieren, d.h. ich habe erstmal auf eine Größe noch lesbaren Codes von 10kb gesetzt. Ich sag vornweg, dass die 50% sehr optimistisch waren.

Zunächst hatte ich probiert, vor allem die Zeilen von über 1500 auf 200 runterzubringen. Da man ja relativ problemlos in C Zeugs verketten kann, war das erstmal nicht so das Problem.
Viel wichtiger ist allerdings, dass man möglichst wenig unterschiedliche Enginebefehle nutzt, denn die kann man dann viel effizienter durch waskurzes ersetzen.
So kam es dann auch, dass ich einige Verkettungen wieder gebrochen habe, weil z.B.ein +0*V(...).x; einfach zu "teuer" war, und gegen Ende alles Mögliche ein Problem war, bloß nicht die Zeilenanzahl.
Die #defines sind in erster Linie search and replace (nicht Tool assisted) und viel Zeichen zählen.
Den Originalcode hatte ich natürlich immer in nem zweiten Fenster offen, aber irgendwann weiß man ganz gut, was in der Zeile so gemacht wird und warum mans schon wieder kaputtgegolft hat ;)

Wichtig ist auch, dass man möglichst viel in den Level selbst verschiebt. Dort können Objekte ja Eigenschaften haben, die man festlegen kann.
Wenn ich x-mal ein object.skill[0] benutze statt einen festen Wert, kann ich das halt auch kleiner squishen und die Festwerte einfach in den Objektproperties im Leveleditor eintragen.
Alle Layer Objekte (Texte) sind z.B. im Level schon vorhanden, versehen mit einer Funktion, die aus dem Dateinamen des jeweiligen Objektes einen Layer erstellt und via ein Pointer Array referenziert. Ist einigermaßen häßlich, aber somit hab ich schonmal eine beliebige Anzahl an Layer Objekten ohne Codezuwachs.

Es wäre sicher noch deutlich mehr möglich gewesen, aber dann hätte ich das nochmal komplett neu aufziehen müssen.

Hm, wenn du Lust hast, kannst du ja mal den Originalcode posten, dann kann mans schön vergleichen.

Ohje. Ich hab noch nie solchen Code gesehen! Respekt ;)

Jonathan hat geschrieben:Hm, wenn du Lust hast, kannst du ja mal den Originalcode posten, dann kann mans schön vergleichen.

http://www.swertvolc.de/download/tcrne12_code.zip

Tob dich aus :)

Schön war der Code allerdings nie und hat schon früh einige Tests drin, so dass er eigentlich nie wirklich gut lesbar oder gar vorbildlich war.

In den Unterordnern sind noch Vorversionen, bei welchen vieles noch nicht ins Level ausgelagert ist (d.h. da kamen später noch umfangreichere Änderungen). Die restlichen Versionen basieren so ziemlich auf dem selben Konzept und wurden in erster Linie gesquisht.

Die Ergebnisse des Wettbewerbs sind da:

User Votes: 2. Platz klar hinter dem Ersten, klar vor dem Dritten (fast doppelt soviele Stimmen)
Preisvergabe: 1. und 3. Platz gewinnen, ich gehe leer aus.

Mir fehlen da jetzt ziemlich die Worte, das fühlt sich regelrecht wie Betrug an... aber hoffe wenigstens ihr hattet ein wenig Freude an der Demo.

Hallo zusammen!

Ich würde hier gerne meine letzten Projekte vorstellen, in der Hoffnung auf ein bisschen Feedback und eventuell den ein oder anderen damit motivieren zu können. Ich persönlich wurde durch diverse Projekte (u.a. StoneQuest und Splatter, Krishtys Sternerenderer, usw.) einige Male vorangetrieben.


Projekt: Aurora (Windows Phone 7) / Auroris (iOS)
Dauer: 05/11 - 07/11, erstes Release: 02.06.11
Beschreibung: Partikel basierte Image Drawing App (z.B. um Wallpapers zu erstellen)
Features:
-Partikelsimulator
-optionales HighQuality Rendering
-Fake-Bloom/Glow Renderpass






Das Video dazu ist schon ein bisschen älter und spiegelt damit leider nicht den aktuellen Stand der App.



Projekt: Discovery (Windows Phone 7)
Dauer: 11/11 - 04/12, erstes Release: 07.04.12
Beschreibung: Sandbox-Game, vergleichbar Minecraft Creative Mode
Features:
-Chunk/perlin-noise basiertes Terrain
-Stimmige-/Realistische Beleuchtung mit Tag/Nacht
-Optimiert für Low-End Hardware (auf Lumia 800 bei Max Details 50+ FPS)
-Atmosphärischer Soundtrack

Der Aurora-Tool produziert sehr coole Bilder - gefällt mir :-) Das minecraft-artige Spiel sieht auch sehr gut aus, spricht mich aber nicht so an - an Block-Landschaften habe ich mich irgendwie sattgesehen. Was ist aus dem Spiel geworden?

Danke Schrompf! Da das Spiel erst vor 4 Tagen releast wurde ist es schwer das zum jetzigen Zeitpunkt zu beurteilen. Bisher hat es ca. 2000 freie Downloads generiert. Microsoft hängt bei den Statistiken immer ca. 6 Tage hintendran. Werde in ca. einem Monat mal detailliertere Zahlen (an anderer Stelle) posten. Eventuell ist das für den ein oder anderen hier interessant. Hoffe bei Splatter geht es ebenfalls gut voran!

Danke! Zahlen würden mich interessieren!

Mit Splatter geht es so leidlich voran. Technisch schaffe ich vieles, inhaltlich geht es auch gut voran. Ich denke, dass Splatter am Ende ein Spiel wird, bei dem die Leute nicht bereuen werden, 10€ ausgegeben zu haben. Aber die PR hängt mächtig... man müsste eigentlich jede Woche ein neues Video produzieren und darauf auch jedesmal irgendwas pannendes Neues zeigen können. Geht aber nicht, da allein die Video-Produktion ein paar Tage Arbeit darstellt. Also dümpelt der Bekanntheitsgrad so vor sich hin :-/

Gefällt mir beides sehr gut! Besonders Discovery sieht klasse aus! Kann mir gar nicht richtig vorstellen, dass das so auch auf den alten Smartphones läuft ;)

@Schrompf: Das Problem haben wir auch, nur dass wir neben unserer gewöhnlichen Arbeit(bei mir kommt auch noch die Schule dazu) noch an Imaging Software und Middleware arbeiten. Da bleibt für andere Sachen abgesehen vom Programmieren bzw. Entwickeln leider kaum Zeit übrig. Auch die notwendigen rechtlichen Schritte zur Unternehmensgründung haben bis jetzt noch nicht in unseren Zeitplan geschafft(jede Woche Samstag machen wir einen Dev-Tag, ansonsten immer nur Abends).

Imaging Software ist natürlich ein noch kleinerer Markt als der Spielemarkt, dennoch wäre etwas mehr Aufmerksamkeit für unsere Homepage bzw. unsere Software auch nicht schlecht. Ein Ausdruck dieser Verödung ist beispielsweise, dass ZFX in diesem Monat unsere Hauptquelle für Traffic war. Naja, wir hoffen, dass das mit der neuen Version unserer Software etwas mehr wird.

Videoproduktion und Blogartikel sind sehr aufwändig, gerade wenn man auf Qualität achtet. Als Entwickler verwendet man seine Zeit meist dann doch lieber zum Entwickeln...

Ihr macht das einfach total falsch, so wird das nie was mit dem Hype. Neue Informationen werden schon lange nicht mehr veröffentlicht. Leak heißt das Zauberwort. Erst wenn es dem Netz aus allen Ritzen trielt, und der tumbe Netzwandler, von allen Seiten durchnässt, ausnahmsweise sein Gesicht aus dem Buch hebt, um sich, angetrieben vom Kitzel des Unrechtmäßigen, selbst aktiv auf die Suche nach dem Leck zu begeben, erst dann wird man sich an euch erinnern. Dabei kann es so einfach sein, eine kurze plausible Geschichte genügt:

develop online hat geschrieben:Frankfurt headquartered studio Crytek is building the third instalment of its blockbuster Crysis series, a growing body of online evidence has shown. A leaked, and now deleted, advert promoting the game would suggest that [...]

@scheichs: Sehr schöne Screenshots hast du da, insbesondere die Beleuchtung ist dir wirklich gelungen. Hut ab bei der Performance auf mobilen Endgeräten.

Danke für eure Kommentare!

Schrompf hat geschrieben:Danke! Zahlen würden mich interessieren!

Nicht nur dich. Man stolpert ja eher selten über Erfahrungsberichte, die mit konkreten Zahlenmaterial unterlegt sind. Vielleicht sollten wir mal einen Thread eröffnen um solche Sachen zu bündeln und auf einem Blick zu haben und ggf. vergleichen zu können.

Darüber bin ich z.B. heute morgen über indiegames.com gestolpert: http://www.gamasutra.com/view/feature/1 ... umbers.php

Ich freu mich gerade! Nunmehr habe ich Shadowmapping mit Shadern für multitextured Terrain für statische und animierte Modelle hinbekommen. :) Der Baum im Bild dreht sich und die Figur kann laufen und der Schatten ändert sich entsprechend auch. Und wie man am Modell und am Baum sieht, sind die Objekte auch self-shadowed.
Viel muss noch an den Schatten optimiert werden, z.B. für Weitsicht. Auch sollte ich vielleicht Mal nicht-grüne Modelle einsetzen. Jedoch ein großer Erfolg, da mir diesmal nicht 100% vorgekaut wurde, sondern nur 80%. :)

Ja, wenn Schatten einmal funktioniert, ist das ein tolles Gefühl :)
(das blöde ist ja, die THeorie dahinter ist immer soo einfach - hat man in einer halben Stunde kapiert. Das Implementieren dagegen und die ganzen kleinen Details...)

Habe vor einiger Zeit wieder meine Leidenschaft für Musikvisualisierung entflammt. Zur Zeit noch auf Fehlerjagd, aber es sieht schon ganz gut aus wie ich finde.
Meine Audio-Aufnahmetechnik ist zwar eher bescheiden, aber wenigstens sieht man, wie's funktioniert. ;)
[youtube]wwWAGeV7V4U[/youtube]

Was ist das für ein Lied? Gibts davon Noten? :D

Noten? Ist das was nützliches? *zwinkersmilie*
Eigentlich sind die Akkorde des Hauptteils A-moll G-dur C-dur und E-dur. Als Laie spiele ich (natürlich) auf C mit Transponierung, für diese Aufnahme bin ich nur zwei Halbtöne nach unten.

edit: das Lied entstand beim Spielen, als ich Как на войне von Agatha Christie (Агата Кристи) nachspielen wollte.

Hm, ja, ohne Noten spielen hat schon was. Müsste ich auch mal mehr üben, und vielleicht wag ich mich dann mal eines Tages daran, das nachzuspielen. Wenn du es mit einem Keyboard aufgenommen hast, dann hast du nicht zufälligerweise davon eine midi? :D

Na, wie dem auch sei, hier kommt ein Ingame Video, zu den neu implementierten Animationen:
[youtube]Zj4sy5nr9KU[/youtube]
Ja, viel mehr gibt es dazu gar nicht zu sagen. Außer vielleicht, dass ich noch nicht zwischen einzelnen Keys interpoliere - aber ansich ist die Auflösung der Animation dafür schon gut genug.

Hab' nur Audio aufgenommen, da ich eh nicht im Takt bleibe (+n kann)...

Die Animation sieht gut aus. Meine Bone-Animationsversuche sind fehlgeschlagen und ich habe entnervt aufgegeben ;)
Planst du die Verschmelzung unterschiedlicher Animationen ein? Also Laufen + Angriffsanimation oder Laufen und zum Spieler gucken?

Splatter mal wieder: es gibt da eine Stelle, an der der Spieler durch gas-geflutete Keller durchmuss, indem er von Belüftungspunkt zu Belüftungspunkt hüpft. Es galt also, da irgendwie Gas darzustellen. Und das hatte ich schon mal gemacht, und es sah eigentlich ganz gut aus - falls sich noch jemand an AEGIS von der letzten ZFX Action erinnert, dort hatte ich das schonmal gemacht. Aber ich wollte ja unbedingt das Gas auch interaktiv haben - es sollte umherwallen wie ... nunja, wie schweres Gas halt. Das Ergebnis nach circa 6h Arbeit sieht jetzt so aus:
Reichlich dünne. Es wallt zwar schön, wenn man durchlatscht oder Explosionen darin stattfinden, aber ist numerisch etwas instabil und vor allem kriechend lahm. Das sind 15k Partikel, die mit der Umgebung und untereinander interagieren. Schon mit 15k Partikeln kann ich keine vollen 75fps mehr halten. Ich könnte das Ganze jetzt zwar noch parallelisieren, aber das wäre nur eine Übung in Nutzlosigkeit, da das Spiel noch auf einem DualCore laufen soll und ich auch mit doppelt so vielen Partikeln noch keine schöneren Ergebnisse bekäme. So ein Mist.

Nuja, zurück zum Reissbrett. Vielleicht ist es Zeit, die Herren Navier und Stokes rauszuholen. In einem banalen 2D-Array dürften jedenfalls die Nachbar-Interaktionen sehr viel schneller werden. Nur fürchte ich da wieder, dass meine Mathe-Fähigkeiten bald am Ende sind :-)

Sind die 15k Partikel denn jeweils ihrer Zelle zugeordnet und können so in O(1) mit den Nachbarzellen gecheckt werden, sodass die Interaktion wirklich nur da berechnet werden muss, wo es wirklich notwendig ist?

Wenn du Navier-Stokes rausholst, wirst du das explizit lösen müssen (impliziete Lösung über stable fluids wird bei so vielen Zellen schnell sehr langsam) und dann einen großen Faktor vor die Diffusion packen müssen, damit es auch bei größeren Zeitschritten stabil bleibt. Ich schreibe darüber momentan meine Bachelorarbeit, kannst mich also gerne an-PM-en mit irgendwelchen IM-Kontaktdaten oder so, wenn du wirklich das über Navier-Stokes machen möchtest.

Nachtrag: Wenn man etwas mehr Mühe investiert und einen geschickteren Löser als Gauß-Seidel benutzt, kann man auch Stable-Fluids in etwas größer nutzen.
Beispiel zu Stable-Fluids mit Auftriebskraft und Vorticity Confinement, allerdings Gauß-Seidel: http://www.multires.caltech.edu/teachin ... fluids.htm

Moin,

und Danke für das Angebot. Mit 15k waren einfach nur Partikel gemeint - frei bewegliche Kügelchen, die über einfache Federkräfte mit nahen Partikeln und der Umgebung interagierten. Das rechenaufwändigste hier war also die Partikel-Partikel-Interaktion - mit einem kleinen Grid drunter hat jeder Partikel nur noch mit ~100 anderen Partikeln interagiert, aber teuer ist es troztdem.

Navier-Stokes war nur ein Stichwort, was ich irgendwann früher mal aufgeschnappt hatte. Ich habe mich inzwischen belesen, dass das Differentialgleichungen sind, die man so direkt nicht lösen kann. Stattdessen gibt es verschiedene Ansätze und Vereinfachungen. Der beste/neueste Ansatz soll wohl die Level-Set-Methode sein, aber die Paper erreiche ich nicht. Ich habe mir jetzt gerade - die faule Sau, die ich bin - Beispielcode für die Lattice-Boltzmann-Methode ergoogelt und schaue mal, wie das aussieht. Die Videos, die ich bisher dazu gesehen habe, sahen eher nach Flüssigkeit als nach Gas aus, aber ich brauche wohl ein Zwischending, wenn ich dichtes Gas mit Luftstellen dazwischen simulieren will.

[edit] Oh mein Gott, da hat jemand C++ am Beispiel gelernt. Da liest man dann z.B. folgendes: #pragma omp parallel for wird's schon heilen...

"Direkt nicht lösen" heißt dort immer "in geschlossener Form", "in einem Schritt", "implizit" lösen.

In meinem Nachtrag gibt es Beispielcode für Stable-Fluids, die Navier Stokes in der inkompressiblen Form in 3 getrennten Schritten "lösen". Es ist relativ günstig, immer stabil, egal wie groß der Zeitschritt und einfach zu implementieren.
Das Paper dazu ist: StableFluids (sorry, ist der Google-Link)

Zusammen mit dem richtigen Rendering und "Vorticity Confinement" sieht das eigentlich gut nach Rauch aus.

Vermutlich meine Bc-Arbeit, ein Hybrid aus Ray Tracing, Ray Casting und Rasterisierung. Ich kann zwar noch nicht sagen, in wieweit ich das ganze echtzeitfähig bekommen werde (mehr als 2-10 FPS? :P) , aber ich habe trotzdem schonmal ein paar Screenshots gemacht. ;)

Grob basiert das Verfahren auf einer Projektion von zu verfolgenden Strahlen in ein Bildraumgitter, an Stelle einer üblichen umgekehrten Diskretisierung der Geometrie. Die Projektion dient einer ungefähren Vorsortierung, anschließend werden mit potentiell geschnittenen Dreiecken genaue Strahlschnitttests durchgeführt, wobei eine klassische perspektivische Projektion mit konservativer Rasterisierung genutzt wird, um Dreiecke schnell den richtigen Strahlen zuordnen zu können. Das Verfahren arbeitet somit mit der exakten Dreiecksgeometrie (keine Voxelapproximation) und liefert exakte Ergebnisse wie beim Raytracing, wenn auch mit denselben Nachteilen (Aliasing, Füllkonventionen). Insbesondere handelt es sich bei den Reflexionen an den Wänden nicht um verzerrte planare Reflexionen, sondern um echt richtungs- und ortsabhängige Strahlverfolgung. Das Verfahren arbeitet vollkommen ohne vorberechnete Beschleunigungsstrukturen, das Materialsystem und die Input-Daten sind die einer klassischen Deferred Shading Pipeline. Das hier ist quasi ein frühes Preview; näheres, wenn die Arbeit weiter fortgeschritten ist.

(Zum Vergrößern klicken)
Und ja, es sind noch immer einige Artefakte drin. Konservative Rasterisierung lässt grüßen.

Ich bin beeindruckt! :) Erinnert mich irgendwie an dies hier: http://www.gamedev.net/topic/590256-rea ... y-tracing/