Showroom - Aktuelle Arbeiten und Projekte

[Tiles]

Bunt und Knuffig ist gut :)

[joeydee]

Cooles Bild, Tiles :)

[Tiles]

Thx :)

[Mirror]

Immer wieder erstaunlich wie viel Arbeit in so einem Bild steckt. Das waren jetzt vier Wochen Arbeit.

@Tiles
Sehr schönes Bild. Gut zu wissen das da wirklich viel Arbeit drin steckt. Ich habe keine Ahnung vom Modellieren und dachte immer das sei pure Zauberei. Es beruhigt mich das ihr das auch nicht in 10 Minuten zaubert. Das gibt mir Mut auch mal etwas in der Richtung anzufangen.

Auch wenn es kein Hexenwerk ist, sondern wie bereits erwähnt viel Arbeit ist oder besser gesagt genau aus diesem Grund: Tolles Bild !!!

[Tiles]

Auch dir Danke :)

Naja, vier Wochen sollte ein Profi für sowas definitiv nicht brauchen. Speziell die Robos sind im Grunde Primitives. Ich bin einfach komplett aus der Übung. Und das schlimmste war mal wieder dass ich überhaupt nicht wusste wo das Bild eigentlich hingehen sollte :)

Aber das unterschätzen viele was da wirklich alles zu tun ist. Ein paar Primitives in die Szene zu schmeissen ist kein Hexenwerk. Das dann aber wirklich lebendig und in sich stimmig zu bekommen dass es nach was aussieht das dauert seine Zeit. Grobe Regel ist dass du so 2-3 Jahre brauchst bis du mal die wichtigsten Schritte verinnerlicht hast. Aber dann gehts ja erst los. Es ist Kunst. Da lernst du dein Leben lang. Und die letzten 5 bis 10 % die die Spreu vom Weizen trennt haben es einfach in sich. Und je realistischer und detaillierter das aussehen soll um so grösser wird auch der Aufwand. Und speziell 3D entwickelt sich immer noch in einem Affenzahn weiter. Ich kannte noch die Zeit als man Charactere mit SDS Modeling gebaut hat. Heute sculptet man ja nur noch. Und klatscht am Schluss ein Retopo drauf.

Das kann man aber alles lernen. Heutzutage hast du es ja gut, da gibts für jeden Schritt ein eigenes Tutorial. Und so Sachen wie Megascans und Quixel Mixer. Und Character Creatoren. Oder so Sachen wie DAZ wo du dir deine Assets einfach zusammenkaufst und dich dann stolz 3D Künstler nennen kannst. Da kannst du böse formuliert einen Dorftrottel dransetzen das sieht immer noch nach was aus.

Als ich angefangen habe hatte ich eine zugelaufene Version von trueSpace 1 ohne Manual und Internet. In dem Ding hast du jedes Vertice einzeln mit Handschlag begrüsst. Und meinen ersten brauchbaren Character richtig mit SDS Modeling, gescheiter Topologie und Textur habe ich dann auch erst Jahre später hinbekommen. Aus der Zeit stammt mein Avatar. Puh, lang ists her. Ich bin wohl echt ein alter Sack :)

[joeydee]

Interaktive Sternenkarte mit ein paar diffusen Nebeln:


Und natürlich konnte ich nicht widerstehen, auch mal frei durchzufliegen, umgerechnet mit irgendwaspaarundtausendzigfacher Lichtgeschwindigkeit:

Sterndurchmesser sind natürlich nicht maßstäblich.
Technisch simpel gelöst: Prozedurales gleichverteiltes Universum (Integerraum ^3) ohne übergeordnete Struktur, in jeder Unit-Box (gedanklich als 1LJ definiert) kann ein Stern mit eigenem Seed stecken. Die Nebel sind einfach eine handvoll Sprites, sprich ein oldschool Partikelsystem. Bichen getrickst um Gimbal-Drehungen zu vermeiden. Da ich dies zum Generieren einer Skybox an beliebiger Stelle im All verwenden möchte, muss von einer bestimmten Koordinate aus gesehen die Ausrichtung der Sprites jederzeit reproduzierbar sein. Texturen kommen aus fester 4x4-Tilemap.

[Schrompf]

Schiiiick! Tiefensortierst Du die Nebelpartikel?

[Tiles]

Definitiv sehr geil :)

[Jonathan]

Die Nebel sind sehr schick und auch die Sterne sehen cool aus (ich meine, es sind bunte Punkte, aber dafür sehen sie halt ganz ok aus :D ).

Was mir beim zweiten Video aufgefallen ist: Es wirkt irgendwie unstrukturiert. Selbst die großen Nebel sind irgendwie klein, man kommt sich vor als sei man in einem Raum komplett ohne irgendwelche Orientierungspunkte. Es ist unmöglich zu verstehen, wo man ist, oder einen Stern jemals wieder wiederzuerkennen.
Vielleicht wäre es cooler, z.B. eine große Galaxienstruktur zu haben (mit diesen Spiralarmen). Vielleicht einen wirklich großen Nebel quasi unendlich weit weg in der Skybox, damit man zumindest immer weiß, in welche Richtung man schaut. Halt irgendetwas, was Orientierung gibt, wodurch man von "dieser Stern ist" zu "dieser Stern ist dort" kommen kann.

Was mir damit auch nochmal auffällt: Eigentlich ist das Weltall richtig richtig doof :D. Zum einen ist es eigentlich komplett leer und es macht überhaupt gar keinen Sinn irgendetwas maßstabsgetreu darzustellen. Und zum anderen ist es auch ziemlich hässlich, weil es eigentlich komplett schwarz ist. Um diese Nebel oder Galaxien zu sehen, muss man die Lichtintensität massiv hochschrauben und/oder noch ganz andere Bereiche des EM Spektrums irgendwie auf den sichtbaren Farbbereich abbilden. Sprich: Man muss richtig viel tricksen und betrügen, bevor es auch nur annähernd cool aussieht. Und das ist ja nur das Weltall ansich, für sowas wie Raumschlachten werden ja auch immer nur Raumschiffe gezeigt, die sich wie Flugzeuge verhalten, was von der Flugphysik auch totaler quatsch ist. Selbst Asteroidengürtel sind eigentlich wirklich leer und super langweilig (tatsächlich muss man sich eher aktiv anstrengen um überhaupt mal in Sichtweite eines Asteroiden zu kommen), was in Filmen auch nie so dargestellt wird.
Aber wenn man es komplett unrealistisch macht, ist es schon irgendwie ein cooles Szenario :D

[Schrompf]

Aber wenn man es komplett unrealistisch macht, ist es schon irgendwie ein cooles Szenario :D

Genau mein Reden! Wir hacken da aber im IRC schon genug auf joeydee rum, dass er das nicht vergisst :-)

[joeydee]

man kommt sich vor als sei man in einem Raum komplett ohne irgendwelche Orientierungspunkte

Ja, willkommen im Weltall ;) aber darum gehts dabei auch (noch) gar nicht. In erster Linie möchte ich kohärent Skyboxen auch für benachbarte Systeme generieren, sowie die Nebel sinnvoll in der Map anzeigen können. Wird evtl. auch wieder bunter, so wie in den letzten Screens, aber habe den Look noch nicht festgelegt. Wollte nur mal den Stand der Dinge zeigen. Ob ich den Live-Durchflug in Ego-Perspektive dann überhaupt nutzen möchte, steht noch in dern Sternen, sprichwörtlich.
Größere Strukturen im Hintergrund: ja, auch schon dran gedacht (u.a.), aber so weit bin ich noch nicht. Für das bisherige Ziel wäre es aber nichtmal dringend nötig.
Mit den Asteroiden hast du recht, und nichtmal Planeten wären leicht zu finden, wenn man einfach irgendwo im Sonnensytem abgesetzt würde. Falls man überhaupt was sieht, dann siehts aus wie ein Stern, kann man nur mit Langzeitbeobachtung oder Spektralmessung feststellen (wir sind auf dem 3. Planeten, wo die Planeten am engsten stehen, aber selbst unsere Nachbarplaneten Venus und Mars, sowie den riesigen Jupiter, kann man nur dann mit bloßem Auge sicher von Sternen unterscheiden, wenn man genau weiß wonach man zu suchen hat).
Daher auch schon früher die Anmerkung: aktuell keine Prio auf Planeten-Generierung und -LOD, da man die ohne Waypoints eh nicht finden würde ;)
Ich werde mir trotzdem mal einen Spaß daraus machen, Entfernungen und Größen einigermaßen realistisch einzustellen, weil mich das einfach mal interessiert. Aber dann nicht für Spielzwecke.
Bis dahin zu diesem Thema: https://joshworth.com/dev/pixelspace/pi ... ystem.html

Sortierung: nein, BlendFunc steht einfach auf "Add". Aber wäre kein Problem wenn ich mal anderes Blending machen möchte, da aktuell sowieso noch je Frame der ganze Buffer neu generiert und hochgeschoben wird. Verschwendung, ja. Aber ich wollte es ja ursprünglich nur einmalig für Skybox.

[Jonathan]

Bis dahin zu diesem Thema: https://joshworth.com/dev/pixelspace/pi ... ystem.html

Ja, die Seite ist irgendwie großartig und nutzlos gleichzeitig. Nutzlos, weil man so lange scrollt, dass man kein Gefühl mehr für die Strecke (z.B. 3 Bildschirme nach rechts) sondern nur noch für die zeit (ich dreh mein Mausrad seit 2 Minuten) hat. Wie das zu dem einen Pixel korrespondiert, kann man dann nicht mehr einschätzen. In Bonn ist am Rhein entlang auch das Sonnensystem Maßstabsgetreu aufgebaut - die Sonne ist eine mannshohe Kugel, alle Planeten sind auf Metalltafeln eingraviert. Spätestens ab dem zweiten oder dritten kann man die Sonne schon nicht mehr sehen, und man kann die Planetengröße überhaupt nicht in Relation zur Entfernung einordnen. Wären die Planeten unkorrekterweise 10 mal größer dargestellt, würde im Gehirn exakt das selbe Gefühl für die Größenrelation entstehen, nämlich "joah, pervers weit weg". Unser Sonnensystem ist so absurd leer, dass man es selbst dann nicht richtig versteht, wenn man es grafisch maßstabsgetreu darstellt. Erst als ich versucht habe, mir das wirklich vorzustellen und es nicht geschafft habe, hab ich gemerkt, wie krass es ist. Alles was ich tun kann ist, die Zahlen hinzuschreiben und die Exponenten zu vergleichen, anschaulicher wird es irgendwie nicht...

[xq]

Joeydee inspirierte mich und ich habe wieder mal Gamedev-Kram angefangen. Man kann jetzt langsam ein "Raumschiff" erkennen:




Idee ist, das ganze so Richtung "Space Engineers" wachsen zu lassen, mal schauen, wo die Reise aufhört

[joeydee]

@xq: Cool! :)


Bei mir sind die "Raumschiffe" zwar immer noch sinnfreie unförmige Quader-Konglomerate. Aber nun mit ein wenig Textur (geklaut, und noch ohne Mip) sowie mit Kollsionsphysik Playerkugel vs. Dreiecksuppe. Sprich, man kann da jetzt sehr nah ran und zwischen den Strukturen durchfliegen.

Zur Kollision: Video, or it didn't happen. Ein paar Flugübungen auf dem Schifssfriedhof.
Steuerung ist mit Drift, aber stark gedämpft. Man kann nur mit Steuerdüsen, mit Triebwerk und mit Boost (braucht sich schnell auf) fliegen.
(Am Anfang des Videos wird nur im Map-Scale zum Stern navigiert; das ergibt dann die Skybox für die lokale Szene. Nicht verwirren lassen, die Map erkennt man noch nicht als solche mangels Labels etc., und es gibt auch noch keinen Reise-Übergang ins Zielsystem)

[joggel]

0.38er Rohr in einer Überstulpmuffe mit Zwiebelnut.
(Ingenieur-Sprache kann ich :P)

Fehlt jetzt nur noch die Texturierung. Ich habe mich ewig mit Eulerwinkel rumgeärgert, da bei Rotationen >120° die Slider im GUI falsche Werte angenommen haben. Dank Quaternionen fühlt sich jetzt GUI, Gizmo und Model-Geometrie (fast) konsistent an.

Modelle nach OBJ exportieren klappt auch.

[Jonathan]

0.38er Rohr in einer Überstulpmuffe mit Zwiebelnut.

Haha, genial. Im Gegensatz zu dem ganzen Informatik-Fachsprech klingt Ingenieurssprache einfach unfassbar deutsch. So richtig kantig und griffig, aber auch manchmal ein wenig Selbstironisch. Als Hobby-Sprachnerd macht mich das irgendwie an :D

(Fun-Fact: Die alternative Schreibweise von Nut ist Nute. Unreifere Menschen würden an dieser Stelle jetzt kichern, ich aber natürlich nicht.)

[joggel]

Im Gegensatz zu dem ganzen Informatik-Fachsprech klingt Ingenieurssprache einfach unfassbar deutsch.

Ich finde, dass das fast immer etwas obszön (oder gar vulgär) klingt :D
Naja... vlt ist das auch in der deutschen (Sprach-)Kultur begründet.

[smurfer]

0.38er Rohr in einer Überstulpmuffe mit Zwiebelnut.

Haha, genial. Im Gegensatz zu dem ganzen Informatik-Fachsprech klingt Ingenieurssprache einfach unfassbar deutsch. So richtig kantig und griffig, aber auch manchmal ein wenig Selbstironisch. Als Hobby-Sprachnerd macht mich das irgendwie an :D

(Fun-Fact: Die alternative Schreibweise von Nut ist Nute. Unreifere Menschen würden an dieser Stelle jetzt kichern, ich aber natürlich nicht.)

Ich halte mich für relativ, nein, sehr reif und ich habe gekichert -- und stehe dazu ;-).

Es gibt aber auch noch mehr so Perlen. Ich bin Simulationsfan und außerdem recht vertraut im deutschsprachigen Automotive-Umfeld. Reifenmodelle finde ich spannend, deswegen ist mir der Begriff "tire contact patch" sehr geläufig (also der Teil des Reifens, der inklusive Deformation den Boden zu einem bestimmenten Zeitpunkt berührt). Der ingenieursmäßige Begriff des Reifen-Latsch lies mich dann aber auch wieder sehr schmunzeln -- natürlich in reifer Form ;-)

[LONy]

Mit Shardcraft geht's seit längerer Zeit leider nicht weiter.
Da ich heute aber meinen zehnten Geburtstag hier bei ZFX feiern darf, gibts ne mini Vorstellung von einem Nebenprojekt ;)

Und zwar ein Pegelmesser für einen kleinen Bach. Normal ist der Bach 20 cm hoch. Im Juli wurden auch wir nicht mit Hochwasser verschont und so ist die Idee für einen Pegelmesser entstanden.

Ein Ultraschallsensor SRF05 misst den Abstand zur Wasseroberfläche.
Ein dsPIC steuert den SRF05 an, misst auch noch die Temperatur und ermittelt aus den Daten über die Schallgeschwindigkeit und die Schalllaufzeit den Abstand.
Die ermittelten Daten werden über RS485 an einen Raspberry Pi geschickt. Auf dem Pi läuft node.js. Mit einem Javascript werden die Daten an der seriellen Schnittstelle empfangen und über HTTPS an einen Webserver geschickt und hier in einer MySQL Datenbank gespeichert.
Ein PHP Script läd die Daten aus der Datenbank und visualisiert den Verlauf mittels einer SVG Grafik :)

Blöderweise misst der Ultraschallsensor auch das Gras am Ufer, weshalb der Pegel so verrauscht ist. Da muss ich evtl. selbst das Echosignal vom Sensor auswerten. Aber ansonsten funktionierts.

Die Elektronik mit dem dsPIC ist einfach meine Masterarbeit. Eigentlich kann man mit dieser über Sprachbefehle ohne Cloud ein Licht steuern ;)
In dem Video kann man die Elektronik (mit der Anwendung zur Sprachsteuerung) in Aktion sehen:

[Krishty]

Sehr geil! Würde gegen das Gras am Ufer ein max()-Filter über n Sekunden helfen? Wenn Gras vor dem Wasser ist, kann die Distanz ja schonmal zu gering erkannt werden, aber mir fällt kein Fall ein, in dem die tatsächliche Distanz zum Wasser überschritten werden könnte.

[joeydee]

Ich habe mich die letzten Tage mal ein wenig mit dem Prinzip "wave function collapse" beschäftigt.
Nachdem ich dank xq (und Schrompf) verstanden hatte, dass das gar nichts mit Wellenfunktionen zu tun hat, sondern einfach nur ein Synonym entliehen aus der Quantenmechanik ist für "in diesem Kästchen ist das Ergebnis noch unbestimmt". A la Schrödingers Katze existieren erstmal gleichzeitig mehrere Zustände (mehrere Tiles je Kästchen). Ziel ist dann, alles kollabieren zu lassen, bis es nur noch einen Zustand je Kästchen gibt.

Was passiert da genau?
Ein Muster (hier nicht im Bild) wird auf Regeln ("wer neben wem?") untersucht, daraus wird ein Regelset erstellt, und schließlich wird eine neue Fläche so gefüllt, dass sie allen Regeln entspricht.
Es ist vergleichbar mit dem Erstellen eines Sudoku: Man fängt mit leerem Grid an, in jedem Feld können theoretisch noch alle Zahlen auftauchen, d.h. je Feld existiert eine Liste mit allen Zahlen. Man trägt irgendwo eine mögliche Zahl zufällig ein (damit werden in dieserm Feld alle anderen Zahlen in der Liste gestrichen), daraus ergeben sich laut Regeln Ausschlusskriterien für bestimmte Zahlen in anderen Feldern, diese streicht man wiederum dort aus den Listen usw.

ich bin da noch sehr am Anfang, alles noch sehr eingeschränkt, mit wenigen Prüfrichtungen und ohne automatisches Weighting. Musste erstmal sehen ob Regelscan und Anwendung überhaupt richtig funktionieren. Scheint so.

[Horz]

So ganz habe ich das noch nicht verstanden. Ich fange mit einem leeren Feld an und kann dort eine Zahl eintragen - ok. Jetzt habe ich Regeln, die ausgehend von dieser Zahl die anderen Felder-Zahlen-Listen beeinflussen. Ok.
Ich sehe da ein "Problem" in den Regeln. Denn zum Beispiel bei Sudoku-Regeln kann ich relativ einfach mein gleiches Schema immer wieder abspulen, wenn alle Felder gleich sind. Ich nehme an, du hast zur Zeit 3 Zahlenwerte für blau, gelb und grün. Hast du da schon Regeln, die ein abwechslungsreiches "Durchspielen" ermöglichen?

Zum Beispiel ist eine deiner Regeln für Blau: Im benachbarten Feld kein grün - Im Gegenzug verhindert grün blaue Nachbarn. ich verstehe langsam den Ansatz.

Gehe ich recht in der Annahme, dass sich das Spielfeld dann irgendwann teilweise von selber füllt, du aber immer wieder entscheiden darfst, wie es weitergeht?

Bei deinen aktuellen Regeln könntest du das ganze Spielfeld einfarbig setzen, richtig? So könnte man Punkte für ein erfolgreiches Spiel davon abhängig machen, wie viele unterschiedliche Farben man mindestens besitzt (10 blaue, 7 grüne und 8 gelbe wären dann 7 Punkte, da max. 7 von jeder Farbe)

[joeydee]

Das wird kein Spiel, sondern ist lediglich ein Algo zum Imitieren von (bzw. automatischen sinnvollen Ergänzen nach) vorgegebenen Mustern.
Der Sudoku-Vergleich war auch weniger zum "Sudoku-Spielen", sondern zum "Gültiges Sudoku aus leerem Feld selbst erstellen" gedacht. Weil das ähnlich abläuft.

Eine Anwendung z.B. wäre das prozedurale Erstellen von Mustern/Texturen nach Bitmap-Vorlagen. Von xq hatte ich diesen Link: https://robertheaton.com/2018/12/17/wav ... algorithm/
Dort sind am Anfang Beispiele zu einfachen Mustern.

Eine andere Anwendung wäre ein prozeduraler Levelgenerator: Man "malt" z.B. mit einem Tile-Editor eine kleine sinnvolle Levelvorlage, diese wird dann gescannt, daraus automatisch Regeln erstellt welches Tile neben welchem liegen darf, und dann kann man mit dem Collapse-Algo beliebig größere Level erstellen, die von der ursprünglichen Vorlage abkupfern, ohne direkt zu kopieren. Und man kann in die Generierung auch lokal eingreifen wenn man mag, oder Seeds vorgeben, dass an bestimmten Koordinaten schon bestimmte Tiles vorgegeben sind. Also praktisch das was du vermutet hattest mit "Gehe ich recht in der Annahme, dass sich das Spielfeld dann irgendwann teilweise von selber füllt, du aber immer wieder entscheiden darfst, wie es weitergeht?"

Das geht natürlich auch mit anderen Graphen, auch z.B. in 3D-Grids mit Meshes. Da sind feine Sachen mit möglich, Townscaper z.B. hat so einen Algo drin damit die Dioramen bei jedem Klick sinnvoll ergänzt werden:
https://www.youtube.com/watch?v=QtVkteAS15M

[Horz]

Danke für die Aufklärung. Anwendungen sind mind. genau so spannend wie Spiele - wobei ich denke, dass man aus dem Prinzip auch ein spannendes Puzzle machen könnte. Die Verwendung für Maps finde ich ebenfalls nachvollziehbar. Auch für die Anordnung von Räumen in prozedural generierten Dungeons.
Nicht das ich was damit anfangen könnte... aber es gibt ja auch Nicht-Astronauten, die sich für Astronomie interessieren :D

[Lord Delvin]

Wirkt auf jeden Fall spannend und nützlich. Ich glaub' ich würd's auch vor allem mal für einen 2D Map-Editor hernehmen.

[antisteo]

Ich habe einen Hyper-Performanten Game-Of-Life-Simulator implementiert

Grobe Randdaten:

mein GOL-Simulator schafft eine 1024x1024-Welt in 0.11 ms zu simulieren
der könnte 9.000 solcher Welten je Sekunde schaffen zu simulieren
das sind 9437184000 Zellen pro Sekunde
9 Milliarden Zellen pro Sekunde bei nur 3 Milliarden Takten pro Sekunde, das sind 3 Zellen pro CPU-Takt!!! (und das in der single threaded Implementierung)

Wie ist das möglich? Ist die Ryzen Zen2 Architektur so gut, dass sie mehr als 3-mal so viele Schleifendurchläufe schafft wie sie Takte zur Verfügung hat? Nein.

Ratet mal, wie ich diese Performance hinbekommen habe. Auflösung im Spoiler.

Die Magie heißt Vektorisierung.
Anstatt in einer Schleife über jede einzelne Game-Of-Life-Zelle zu steppen, habe ich eine Datenstruktur namens Chunk64 implementiert, die einen 64x64-Chunk in Form von 64 64bit-Unsigned-Integern ablegt.

In der Simulations-Funktion, die nur 100 Zeilen Code umfasst (etwa 80 Zeilen mehr als der naive Algorithmus, aber auch nicht unheimlich komplex), wird in der äußeren Schleife ein Marching Cubes-ähnlicher Algorithmus gefahren, um jeweils ein Fenster von 3x3, also 9 Bitmustern zu durchfahren. Dabei wird Jeder dieser 9 Werte repräsentiert einen 64-Bit-Vektor für 64 gleichzeitig simulierte Zellen. Mit 21 Halbaddierern (jeweils ein & und ein ^, insgesamt also 42 Integer-Instruktionen) zähle ich die äußeren 8 Bitvektoren zusammen (das sind die 9 außer dem mittleren). Der Ryzen scheint die komplette innere Schleife in seiner Register Renaming Einheit also genau auf 21 Takte herunterschrauben zu können. Respekt!

Die 21 Halbaddierer errechnen also die Anzahl der Nachbarn einer Zelle (als 4-bit-Zahl von 0-8) - jetzt wird nur noch ein Bitmuster darübergelegt, welche Zellen absterben und welche Zellen neu geboren werden: Geboren werden sie bei Nachbarschaftszahl 3, sterben tun sie bei 1, 2 und ab 4 und höher. Diese Maske ORe und AND-NOTte ich dann auf den Original-64-Bit-Vektor der Chunk-Zeile und bin fertig.

Code:

Code: Alles auswählen

package main

import "fmt"
import "time"
import "github.com/atomicgo/cursor"

type Chunk64 struct {
	Board [64] uint64
}

func (c *Chunk64) RenderTwoRow(row int) {
	v := c.Board[row]
	v2 := c.Board[row+1]
	for j := 0; j < 64; j++ {
		if (v & (1<<63) != 0) {
			if (v2 & (1<<63) != 0) {
				fmt.Printf("█")
			} else {
				fmt.Printf("▀")
			}
		} else {
			if (v2 & (1<<63) != 0) {
				fmt.Printf("▄")
			} else {
				fmt.Printf(" ")
			}
		}
		v = v << 1;
		v2 = v2 << 1;
	}
}

func (c *Chunk64) RenderRow(row int) {
	v := c.Board[row]
	for j := 0; j < 64; j++ {
		if (v & (1<<63) != 0) {
			fmt.Printf("█")
		} else {
			fmt.Printf(" ")
		}
		v = v << 1;
	}
}

func (c *Chunk64) Set(row int, col int, val int) {
	if (val != 0) {
		c.Board[row] = c.Board[row] | (1 << (63 - col))
	} else {
		c.Board[row] = c.Board[row] &^ (1 << (63 - col))
	}
}

func (c *Chunk64) Simulate(clu, cmu, cru, cl, cr, cll, cml, crl, result *Chunk64) {
	// build first row from upper block
	bm := cmu.Board[63]
	bl := (bm >> 1) | (clu.Board[63] << 63)
	br := (bm << 1) | (cru.Board[63] >> 63)
	// read out first block
	bml := c.Board[0] // 64 cells we want to simulate in one vector
	bll := (bml >> 1) | (cl.Board[0] << 63)
	brl := (bml << 1) | (cr.Board[0] >> 63)
	for i:= 0; i < 64; i++ {
		// shift last block one up
		bmu := bm
		blu := bl
		bru := br
		// shift middle block one up
		bm = bml
		bl = bll
		br = brl
		// read out own block
		if (i == 63) {
			// in next chunk below
			bml = cml.Board[0]
			bll = (bml >> 1) | (cll.Board[0] << 63)
			brl = (bml << 1) | (crl.Board[0] >> 63)
		} else {
			// in this chunk
			bml = c.Board[i + 1] // 64 cells we want to simulate in one vector
			bll = (bml >> 1) | (cl.Board[i + 1] << 63)
			brl = (bml << 1) | (cr.Board[i + 1] >> 63)
		}
		// layout:
		//  blu bmu bru
		//  bl  bm  br
		//  bll bml brl

		// now count together blu+bmu+bru+bl+br+bll+bml+brl
		// bX_Y bitpattern of 64 cells to count the neighbours; X is the level (0 = multiplied by 2^0; Y is the index)
		// the following algorithm can simulate 64 cells in less than 42 clock cycles (the naive algo would need 64 loop iterations with lots of jumps and caluclations - speedup at least 100x)
		//fmt.Printf("%016x %016x %016x %016x %016x %016x %016x %016x\n", blu,bmu,bru,bl,br,bll,bml,brl)

		// the following code is a series of half adders working on 64 bit vectors
		// first line: 0 0 0 0
		b0_0 := blu ^ bmu
		b1_0 := blu & bmu

		b0_1 := bru ^ bl
		b1_1 := bru & bl

		b0_2 := br ^ bll
		b1_2 := br & bll

		b0_3 := bml ^ brl
		b1_3 := bml & brl

		// now clean up 4x 0's with 3 half adders
		b0_4 := b0_0 ^ b0_1
		b1_4 := b0_0 & b0_1

		b0_5 := b0_2 ^ b0_3
		b1_5 := b0_2 & b0_3

		b0_6 := b0_4 ^ b0_5
		b1_6 := b0_4 & b0_5

		// now add 7x 1's with 3+2+1 half adders
		b1_7 := b1_0 ^ b1_1
		b2_0 := b1_0 & b1_1

		b1_8 := b1_2 ^ b1_3
		b2_1 := b1_2 & b1_3

		b1_9 := b1_4 ^ b1_5
		b2_2 := b1_4 & b1_5

		b1_10 := b1_6 ^ b1_7
		b2_3 := b1_6 & b1_7

		b1_11 := b1_8 ^ b1_9
		b2_4 := b1_8 & b1_9

		b1_12 := b1_10 ^ b1_11
		b2_5 := b1_10 & b1_11

		// now add 6x 2's with 3+2+2 half adders
		b2_6 := b2_0 ^ b2_1
		b3_0 := b2_0 & b2_1

		b2_7 := b2_2 ^ b2_3
		b3_1 := b2_2 & b2_3

		b2_8 := b2_4 ^ b2_5
		b3_2 := b2_4 & b2_5

		b2_9 := b2_6 ^ b2_7
		b3_3 := b2_6 & b2_7

		b2_10 := b2_8 ^ b2_9
		b3_4 := b2_8 & b2_9

		// collect bits of count
		count_0 := b0_6 // least significant bit of neighbour count
		count_1 := b1_12 // second least significant bit of neighbour count
		count_2 := b2_10
		count_3 := b3_0 ^ b3_1 ^ b3_2 ^ b3_3 ^ b3_4
		//fmt.Printf("%016x %016x %016x %016x\n", count_3,count_2,count_1,count_0)
		// now create the following mask for life manipulation: 00x100000 where x = leave; 0 = set zero; 1 = set_one
		set_zero := (count_3 | count_2) | (0xffffffffffffffff ^ count_1)
		set_one := ((count_0 & count_1) &^ count_2) &^ count_3

		// apply the mask to 64 cells
		result.Board[i] = (bm | set_one) &^ set_zero
		//fmt.Printf("%016x %016x %016x %016x\n", bm, set_one, set_zero, result.Board[i])
		// you won't be able to read that algorithms but it has less than 64 instructions that handle 64 cells and don't use any jump or things like that
	}
}

type World struct {
	Size int
	Board [][]Chunk64
}

func NewWorld(size int) *World {
	result := new(World)
	result.Size = size
	result.Board = make([][]Chunk64, size)
	for i, _ := range result.Board {
		result.Board[i] = make([]Chunk64, size)
	}
	return result
}

func (w *World) Set(row int, col int, val int) {
	w.Board[(row / 64) % w.Size][(col / 64) % w.Size].Set(row % 64, col % 64, val)
}

func (w *World) RenderTwoRow() {
	/*
	size := w.Size
	for row := 0; row < size; row++ {
		for i := 0; i < 64; i+=2 {
			for col := 0; col < size; col++ {
				w.Board[row][col].RenderTwoRow(i)
			}
			fmt.Printf("\n")
		}
	}
	cursor.Up(size * 64 / 2)
	*/
	row := 0
	col := 0
	for i := 0; i < 64; i+=2 {
		w.Board[row][col].RenderTwoRow(i)
		fmt.Printf("\n")
	}
	cursor.Up(64 / 2)
}

func (w *World) Simulate() *World {
	size := w.Size
	result := NewWorld(size)
	for row := 0; row < size; row++ {
		for col := 0; col < size; col++ {
			// clu, cmu, cru, cl, cr, cll, cml, crl
			w.Board[row][col].Simulate(
				&w.Board[(row + size - 1) % size][(col - 1 + size) % size], // lu
				&w.Board[(row + size - 1) % size][col], // mu
				&w.Board[(row + size - 1) % size][(col + 1) % size], // ru
				&w.Board[row][(col + size - 1) % size], // l
				&w.Board[row][(col + 1) % size], // r
				&w.Board[(row + 1) % size][(col - 1 + size) % size], // ll
				&w.Board[(row + 1) % size][col], // ml
				&w.Board[(row + 1) % size][(col + 1) % size], // rl
				&result.Board[row][col]) // result
		}
	}
	return result
}

func main() {
	w := NewWorld(16)
	w.Set(1, 2, 1)
	w.Set(2, 3, 1)
	w.Set(3, 1, 1)
	w.Set(3, 2, 1)
	w.Set(3, 3, 1)
	for {
		w.RenderTwoRow()
		start := time.Now()
		w = w.Simulate()
		duration := time.Since(start)
		fmt.Println(duration.Nanoseconds())
		//time.Sleep(10000000)
	}
}

Kopiere dir den Code und messe selbst!

[Lord Delvin]

Sehr cool. Deine Idee? Und wenn ja, wie kommt man drauf?

[antisteo]

Sehr cool. Deine Idee? Und wenn ja, wie kommt man drauf?

Ich glaube, es ist schon meine Idee. Ich wollte mal einen vektorisierten CPU-Cryptominer implementieren, allerdings umfasst der SHA256-Algorithmus TAUSENDE Bitgatter, weshalb ich dafür hätte meinen eigenen Compiler entwerfen müssen. Mit dem Game Of Life ist es händisch händelbar

[Krishty]

Auf AVX wirst du dort keinen Zugriff haben? Dürfte ja mindestens 4x so breit sein, und durch die weitaus höhere Registerzahl ein Bisschen Loop-Overhead entfernen.

[antisteo]

Auf AVX wirst du dort keinen Zugriff haben? Dürfte ja mindestens 4x so breit sein, und durch die weitaus höhere Registerzahl ein Bisschen Loop-Overhead entfernen.

Auf dem Ryzen habe ich avx2, allerdings habe ich jetzt in golang implementiert und noch keine AVX-Bibliothek gefunden. Dem Inline Assembler wollte ich mich jetzt nicht hingeben. Außerdem muss ich die schönen berechneten Welten ja irgendwann an die Außenwelt rendern und ab da komme ich nicht mehr mit 3 Zellen/CPU-Takt hin.

Der Großwelt-Simulator ist ja in golang. Ich baue gerade in WebGL den Client, der einen Teil der Großwelt herunterlädt und lokal weitersimuliert. Wenn man 64 Zellen an jedem Rand mehr lädt, müssen nur alle 64 Frames die Daten am Rand korrigiert werden, damit der Betrachter im Client IMMER den richtigen Zustand sieht.

Gleichzeitig will ich daraus ein Spiel bauen, bei dem jeder Spieler Objekte in die Welt spawnen muss, um die gegnerische Burg zu zerstören.