ZFX + Developia

EA hat den Quellcode zu Command and Conquer auf github veröffentlicht:
https://github.com/electronicarts/CnC_R ... Collection

Ich klick mich gerade ein wenig durch den C++ Sourcecode :)

LONy hat geschrieben: ↑09.06.2020, 14:51 EA hat den Quellcode zu Command and Conquer auf github veröffentlicht:
https://github.com/electronicarts/CnC_R ... Collection

Ich klick mich gerade ein wenig durch den C++ Sourcecode :)

Cool. Hehe, jede gute Effekt-Animations-Klasse braucht ein Do_Atom_Damage :D

BWAHAHAHA

https://github.com/electronicarts/CnC_Remastered_Collection/blob/master/REDALERT/CONST.CPP#L206 hat geschrieben:// HACK ALERT! This unused text string is here to stop Watcom from crashing. There is some
// magic text heap length that causes a crash before the code executes. This dummy string
// changes the text heap length enough to stop the crash. Who knows why, but it works.
char * __test__ = "alskdfjlasdfjkajsdfkja;sldjfklasj9awutreqjfnfdkvnldzlknvadsjgflkasdjfkajsdfas";

Dabei sah Watcoms Disassembly eigentlich immer ganz gut aus …

MMPX Style-Preserving Pixel Art Magnification
Beindruckend viele Details bleiben bei diesem Filter beim hochskalieren erhalten.

Wusste gar nicht dass es so eine Liste gibt:

The VFX Reference Platform is a set of tool and library versions to be used as a common target platform for building software for the VFX industry.

https://vfxplatform.com/

Digital color codes of stars
https://arxiv.org/abs/2101.06254
Im Anhang des Papers: Tabellen Schwarzkörper-Oberflächentemperatur -> RGB

Der Spektrum-Artikel, worüber ich darauf gestoßen bin:
https://www.spektrum.de/news/astrophysi ... obal-de-DE
Erklärt auch, wenn auch nur im Ansatz, warum es z.B. keine grünen oder violetten Sterne gibt.

Gerade eben drauf gestoßen: Scheinbar eine private Sammlung von unzähligen Artikeln rund um die Spieleentwicklung.

https://www.gamedevpensieve.com

Interessantes Animationstool, das mich ein wenig an Joeydees Arbeiten erinnert.



Sicherlich kein generisches Tool wie Blender, aber vllt für das ein oder andere Projekt nutzbar.

Oh das ist auch cool, danke dafür :)
Tatsächlich bin ich da immer auf Ideensuche was die schnelle Umsetzung und Animation von (Comic-)Charakteren angeht, also voll ins Schwarze.

Aus meinen Lesezeichen zum Thema:

Shobon Souls, ein Game-Prototyp in diesem Stil:


Die Programme von Live2D (Cubism bzw. Euclid) https://en.wikipedia.org/wiki/Live2D - Weiß nicht wie die sich genau unterscheiden.
Erst dachte ich, man kann seine Zeichnungen nur auf gekaufte geriggte Modelle wrappen, aber dann habe ich ein Video "from Scratch" gefunden:

Also Keyframe-Morphing in Layern.

Die Rendermethode auseinandergenommen (von rukusu, dem Typ hinter Shobon Souls, der forscht wohl auch gerne zu diesem Thema):
https://twitter.com/i/status/857935959572201472

Mein eigener bisheriger Ansatz, Ist aber noch nicht wirklich ausgereift (Ursprungskizze ist nicht von mir);
https://www.phoximages.de/uploads/2020/ ... bmilk9.gif

Iniquilez hat ein 42min Video gemacht, wie er Schritt für Schritt eine Shader-Landschaft zusammenbaut. Nicht immer einfach zu folgen, wenn man den Mathe-Background nicht eh schon hat, aber phantastisch visualisiert und voller kleiner gemeiner Tricks. Großartig!

Oh, danke!

Schrompf hat geschrieben: ↑11.04.2022, 21:05 Iniquilez hat ein 42min Video gemacht, wie er Schritt für Schritt eine Shader-Landschaft zusammenbaut. Nicht immer einfach zu folgen, wenn man den Mathe-Background nicht eh schon hat, aber phantastisch visualisiert und voller kleiner gemeiner Tricks. Großartig!

Ufff! Das ist wirklich heftig!

... if we take the dot-product and, when positive, multiply it by "brown", ...

Made my day :-)

JellyCar 2D-Physik.
Wenn man die Konzepte "Pointmass" und "Spring" versteht, wird in diesem Video (fast) alles andere gelöst was man bis zu einer spielfähigen Physik noch benötigt.

Schön, und hat ein paar interessante Lösungen, die rückblickend naheliegend wirken.

joeydee hat geschrieben: ↑24.02.2023, 18:42 JellyCar 2D-Physik.
Wenn man die Konzepte "Pointmass" und "Spring" versteht, wird in diesem Video (fast) alles andere gelöst was man bis zu einer spielfähigen Physik noch benötigt.

Sehr schönes Video. Und es macht Lust, so etwas selbst zu implementieren. Könnte mir vorstellen, dass das auch für einen Plattformer funktionieren könnte.

Hm naja. Irgendwie ist es ja schon ein Plattformer. Vergesst was ich geschrieben habe :)

Für alle, die sich mit den Animationen in Asset-Importer-Lib schwertun: https://youtu.be/sP_kiODC25Q

Falls jemand eine eigene Programmiersprache o.ä. entwickelt, könnte das hier interessant sein:
https://github.com/microsoft/tolerant-p ... ItWorks.md

Microsoft hat einen Fault-Toleranten Parser (und Lexer) geschrieben, um PHP mit einem LanguageServer unterstützen zu können.
Im verlinkten Artikel gehen sie detailliert auf das Design ein, u.a. auch wie sie Error Propagation im AST umsetzen und wie das Design für den inkrementellen Parser aussehen könnte.

Da steckt viele Jahre Erfahrung drin, wie man am besten einen modernen Parser schreibt. Microsoft hat da auch schon diverse Erfahrungen drin (insbesondere ist ja C# einer der schnellsten und gleichzeitig präzisesten Parser).

Wirkt mir relativ PHP spezifisch. Gibt ein paar Entscheidungen, die ich nachvollziehen kann, es selbst aber nicht so mache. Einfach weil meine Sprachregeln anders sind. Mal schauen, ob ich die Aussage in Zukunft revidiere, wenn ich den Prettyprinter mal implementiere. Falls. Ist alles viel langwieriger, als man denkt.
Btw. hat Microsoft keine Erfahrung, weil es eine Firma und keine Person ist. Würde nur zu gerne wissen, wie viele Microsoftmitarbeiter schreiend weglaufen würden, wenn sie wüssten was da steht :D

Ich glaube eher, was die meisten unterschätzen ist, dass das Parsen garnicht das Problem ist.
Einen AST bekommt man irgendwie schon hin, aber wenn deine Sprache nicht gerade C-ähnlich ist, dann kann man nicht einfach ein Backend an den AST klatschen (wie man das z.B. im Kaleidoscope-Beispiel von LLVM sieht)

Natürlich macht es jeder ein bissel anders, aber ein paar Entscheidungen fand ich durchaus interessant, wie z.B. Start und FullStart in den Tokens, oder wie sie die kompakt gestaltet haben. Macht man dann selbst sicher anders, aber ich fand es eine gute Anregung.
Oder dass man sich die Invariants von seinem AST genau überlegen und evtl. mal explizit aufschreiben sollte.
Ich habe z.B. einfach zu oft die gleichen Sachen geprüft, beispielsweise beim Generieren der IL und dann im Backend nochmal.

Oder dass sie Top-Down parsen mit Ausnahme der Expressions. Das mache ich mittlerweile tatsächlich genauso, hat mich aber ca. 2 Jahre gekostet, den Vorteil da zu sehen.

Daher denke ich ist der Artikel durchaus ein guter Einstieg, bzw. auch später eine interessante Anregung.
Die Talks über den C#-Compiler fand ich da aber auch sehr gut - finde sie aber grad nicht mehr :-/

Wusste nicht, dass Leute sich für so technische Details interessieren. Vielleicht sollte ich auch was von meiner langen Reise aufschreiben. Bin bei Tyr, um mich zu zwingen die Sprache sauber zu halten, zu einem AST und voller serialisierung in einem getrennten Tool übergegangen. War soweit ich mich erinnere am Anfang anders. Bei der IR-generierung aus dem AST ist die Welt ziemlich kompliziert, weil ich keine definierte Auswertungsreihenfolge mehr habe. Der Syntaktischeanalysepass ist mit ANTLR gemacht und ich nehme, was da rauskommt. Ist nicht unbedingt schnell und hat auch mehr Zeit gekostet, als es mit einem LL(1)-Parser zu bauen, ist die Ausdrucksmächtigkeit aber imho Wert. Den Teil für switch type und switch class zu erweitern habe ich bei einer Tasse Kaffee gemacht. IR habe ich jetzt switch type und switch class habe ich noch nichts. Hab' aber auch meinen Code aufräumen müssen, weil switch mittlerweile 20% vom AST-Expressionübersetzungscode ausgemacht hat und unübersichtlich wurde. Operatoren waren da schon seit Jahren nicht mehr drin, die zählen da also nicht rein.

NB: Wenn alle Tokens im AST sind, dann ist es kein AST, sondern der konkrete Syntaxbaum ;) Den hole ich mir von ANTLR und mach dann Top-Down den AST draus.

EDIT: Hat mich natürlich jetzt interessiert: Hab mit grep mal direkt 16 Kommentare zu invarianten in den Datenstrukturbeschreibungen gefunden. Im Code wüsste ich nicht wie ich die mit grep identifizieren soll. Was ich eigentlich sagen will: Ja das macht man so und es freut mich immer, wenn andere das auch so machen :)

Cool, danke fürs Teilen wie du das machst.
Falls es dich (oder andere) interessiert:

Ich habe den Parser selbst geschrieben (Pratt-Parser). Wenn man das 1-2 Mal gemacht hat ist es fast so leicht wie ein Framework zu verwenden.
Bei mir erzeugt der Parser einen CST (Concrete Syntax Tree) und der wird dann später zu einem AST "ausgebaut".

Den nenne ich aber nicht so, sondern "HIFIR" (High-Fidelity Intermediate Representation).
Diese ist so akkurat wie nur möglich, enthält alle Tokens und Trivias (Whitespaces+Kommentare) plus ein paar Zusätze, und dient als Ausgangsbasis für den Compiler oder andere Tools (wie z.B. "format document") - und bis hierher wird auch unvollständiger oder fehlerhafter Code unterstützt.
Und darauf setze ich dann die Semantische Analyse auf und entferne Doppeldeutigkeiten und Syntactic Sugar (z.B. bei "object.xyz" könnte xyz eine methode sein, d.h. es wird später nach "xyz(object)" ge-lowered, oder ein member/property. Und object könnte dann auch noch ein pointer/referenz sein. Das sind in meinem hifir dann verschiedene operatoren und nicht alles der operator '.'

Also das ist die "höchste" Repräsentation des Programms, aus der das Ursprungs-Programm auch wieder komplett erzeugt werden kann, und danach geht das ganze wieder runter (lowering, Polymorphimus auflösen, Funktionen durch labels ersetzen, calls zu "goto" machen und am ende kommt mehr oder weniger assembly bei raus. Und das Übersetze ich dann aber nach C, weil ich (noch) keinen x64 Assembler scheiben will :-P

Das habe ich auch schon gemacht und fand' das auch mal 'ne Weile eine gute Idee. Würde das nicht mehr machen, wenn es nicht unbedingt erforderlich ist und nie wenn man die Sprache selbst designt. Das Problem ist, dass es einfach viel zu verlockend ist irgendwo eine Sonderbehandlung einzubauen, die einem dann drei Versionen später sehr hart auf die Füße fällt. Oder wenn man plötzlich mit einem anderen Ziel als Übersetzung an das Problem herangeht. Programmanalyse, Programmtransformationen; würde für beides Designentscheidungen anders jeweils treffen als für einen Übersetzer mit Ziel Ausführung.

Und ich würde nicht C als Backend nehmen. LLVM braucht ein bisschen, um reinzukommen, aber es ist viel klarer und besser zu benutzen als wenn man einfach irgendwo C rausrotzt und hoffen muss, dass man später noch irgendwie versteht warum was wie funktioniert. Wenn du in dem Bereich viel machst und irgendwann mal Zeit hast solltest du dir mal OGSS (in meine Fußzeile) anschauen. Damit kann man Zwischendarstellungen generieren. Spart mir unfassbar viel Zeit.

Tileset-Templates generieren, inkl. jeweiligem Bitmask-Script für Autotiling:
https://www.boristhebrave.com/permanent ... t-creator/

Ever struggled to figure out all the possible combinations of tiles you need to put together for autotiling? I’ve create a tool answers that question for a variety of cases, with visualizations.

"General Plant Tips" von "Pixelbutterfly" Marie Lazar
http://pixelbutterfly.com/

Wissenswert! Teile davon hat man irgendwie schon selbst in seiner Laufbahn rausgekriegt, aber das ist ne tolle Zusammenstellung

Diese Fliesen Vorlagen (Tilesets) sind eine tolle Sache

Tools & Libraries to Make Your Own C++ Game Engine
https://pikuma.com/blog/how-to-make-you ... ame-engine

Eine Seite, um nicht nur Gauss-Blur-Koeffizienten nach Bedarf berechnen zu lassen, sondern da habe ich auch gerade einen Trick gelernt, wie man mit der Hälfte der Samples auskommt: man nutzt den bilinearen Texturfilter und samplet an der Stelle zwischen zwei Texeln, so dass die beiden Werte in den richtigen Anteilen relativ zueinander einfließen. Clever! Warum bin ich da noch nicht selbst drauf gekommen?

https://lisyarus.github.io/blog/graphic ... rator.html