Showroom - Aktuelle Arbeiten und Projekte

[scheichs]

Hatte mir mal überlegt es noch an Musik zu koppeln... ich bin auch nicht masslos enttäuscht von der Performance damals. Die App wurde massiv von Microsoft promoted im Windows Phone Store. War super oft als Recommended auf der entsprechenden Kategorieseite (Unterhaltung).
Waren aber trotzdem niedrige Umsätze weil das Ökosystem halt wenig Nutzer hatte und weil es wie Du schon sagst iwo limitiert ist. Auf den anderen Plattformen habe ich es meist als "Pipecleaner" eingesetzt, um zu schauen wie das mit dem Publishing Prozess läuft, etc.
Nun es war mal wieder schön was schnelles zu prototypen neben dem ernsthaften Kram.

[scheichs]

Hab mal nochn 3D FlowField dazugemacht

[xq]

Ich wurstel mal wieder an neuen Projekten™

Das ganze läuft auf meinem Gammel-Laptop bei ~300 Metern/Blöcken Sichtweite mit 60 FPS (ohne Culling, also auch 300 Meter "nach hinten") und bei 1000 Metern Sichtweite mit 30 FPS. Das Level ist endlich (1024² mit Chunks a 16×128×16) und soll auch nicht "unendlich" groß werden.

Was neben dem Renderer schon funktioniert: Physik bzw. der Raycaster für die Kollision sowie die Bestimmung der getroffenen Block-Seite. Jetzt steht also einem Character Controller und "Buddeln" nix mehr im Wege.

[xq]

Überraschend einfacher Terrain-Generator mit GIMP: Plasma → Grayscale → Oil Painting (Großer Radius) → Blur (wenig Radius) ergibt Hügellandschaft:



Nachtrag: Mehr Screenshots, jetzt auch mit 30% mehr Wasser:

[marcgfx]

Coole Sache! Jetzt noch mit Schatten bitte!

[scheichs]

Boah ich kann keine Klötzchen mehr sehen ... *Duck ...
Nee, schönes Ding! Bin ma gespannt was de draus machst.

[xq]

marcgfx: Schatten wird wohl noch eine Weile brauchen… Ja, sind cool, aber die fressen auf meinem Laptop so viel Leistung, dass ich dann nix mehr sinnvoll testen könnte ;)

scheichs: Bin auch gespannt... Grade hab ich einfach massig Spaß, den Renderer zu optimieren und zu tunen.

Darum: Jetzt neu! Frustrum Culling und noch weniger Polygone als vorher. Von 60 FPS bei 200 Block Sichtweite auf 60 FPS bei 600 Block Sichtweite hat sich auf jeden Fall gelohnt. Die Activity Map zeigt mir jetzt auch an, in welchen Chunks gerade Änderungen passieren (Neugeneration des Meshes), zudem sieht man auch, welches Areal gerendert werden soll und was davon tatsächlich gerendert wird...

[xq]

Wenn man beim Bug suchen vergisst, eine Zeile Code wieder einzukommentieren und in gefühlt den letzten 50 Screenshots kein Shading aktiviert ist...

Sieht doch mit gleich viel besser aus!



Hier noch ein Screenshot der kompletten Map:


Und hier noch ein kleines Video, weil warum nicht:

Die Activity Map zeigt an, welche Chunks noch kein Mesh haben (matschgelb), gerade aktualisiert werden (lila), gerendert werden (weiß), in Sichtweite, aber geculled werden (hellgrau) oder nicht gerendert werden (dunkelgrau)

[joeydee]

Weil hier so wenig los ist: Ich fahre z.Zt. mit einem blauen Sessel über eine grüne Wiese mit Baum-Wänden und sammle rote Punkte ein.

Mal wieder an meinem Entity-Component-System weitergeschraubt, sowas lässt sich am besten in 2D topdown testen, ist aber natürlich nicht daran gebunden. Die Physik ist nun endlich auch komponentenbasiert, und die gefundenen Kollisionen werden an die custom Game-Logik übergeben. Mit dem Komponentensystem lassen sich dann leicht komplexere Entscheidungen formulieren was alles ausgelöst werden soll wenn A auf B trifft, und ob z.B. rigid response stattfindet oder nicht.

[michismail]

Hi an alle Spiel entwickelnden Kollegen :)

wir haben nach einigem schwitzen und Knobbeln unsere erste Game App in einem kleinen Dreiköpfigem Team relased. Da wir uns nun nach und nach etwas tiefer in die Materie vorwagen wollten, hatten wir uns vorgenommen in einem ersten Durchlauf einfach mal eine kleine App in den Google Play Store zu bringen.

Unsere Game-App ist ein knobbliges Puzzle Spiel, in welchem der Spieler dem "tapferen Schneiderlein" helfen muss, Kleidungsstücke für verschiedene Märchenfiguren anzufertigen. Dabei muss der Schneider effizent mit seinen Materialien umgehen und die vorgegeben Formen so aus dem Stoff ausschneiden, dass möglichst wenig Ausschuss entsteht...

Wenn ihr Lust habt, würde mich euer Feedback sehr interessieren. Die App hat zugegeben noch ein paar Schwächen. :) Als Artists müssen wir in UX noch einiges dazulernen.

Link zum Game: https://play.google.com/store/apps/deta ... hneiderApp
Name: Das tapfere Schneiderlein

Wir haben einiges spannendes dazugelernt, was Monetarisierung von Unity Ads - bis hin zu den Hürden der Platzierung im Google Play Store angeht.
Wir hoffen dieses gelernte hilft uns in Zukunft manche Fehler zu vermeiden.
Wenn sich also hier jemand austauschen mag - sehr gerne.
Ansonsten freue ich mich über euer Feedback und eure Eindrücke.

[xq]

Gratulation zum Release! Aus Mangel an einem Android-Gerät kann ich das Spiel leider nicht testen :(

[xq]

Starcow hat mich dazu inspiriert, mal ein Kollisionssystem auf Basis von 2D-SDFs zu implementieren:



Die gesamte Kollision sind vllt. 50 Zeilen Code, wenn überhaupt. Das ist alles schön übersichtlich. Morgen mal schauen, wie sich das ganze mit komplexeren SDFs schlägt.

[Jonathan]

Sieht nett aus. Ich nehme an, du hast einen kreisförmigen Avatar und testest auf Kollision in dem du seinen Radius mit dem Ergebnis der Abstandsfunktion vergleichst?

Was mich dann noch interessieren würde: Wie bekommst du die Oberflächennormale bzw. den Kontaktpunkt? Im Video ist der ja mit eingezeichnet, aber mir ist nicht direkt klar, wie man den aus der SDF bekommt.

[xq]

Sieht nett aus. Ich nehme an, du hast einen kreisförmigen Avatar und testest auf Kollision in dem du seinen Radius mit dem Ergebnis der Abstandsfunktion vergleichst?

Korrekt. Für die meisten Top-Down-Spiele reicht das ja völlig aus an Kollisionscode (alles Player Characters sind ein Kreis, wenn man nur fest genug daran glaubt).

Was mich dann noch interessieren würde: Wie bekommst du die Oberflächennormale bzw. den Kontaktpunkt? Im Video ist der ja mit eingezeichnet, aber mir ist nicht direkt klar, wie man den aus der SDF bekommt.

Tja, der Trick hier nennt sich "Gradient" und ist dieses feine Stückchen Code hier:

Code: Alles auswählen

glm::vec2 gradient;
{
	float x0 = get_distance_to_point(player_pos + glm::vec2(1, 0));
	float x1 = get_distance_to_point(player_pos - glm::vec2(1, 0));
	float y0 = get_distance_to_point(player_pos + glm::vec2(0, 1));
	float y1 = get_distance_to_point(player_pos - glm::vec2(0, 1));

	gradient.x = x1 - x0;
	gradient.y = y1 - y0;

	gradient = normalize(gradient);
}

Man bestimmt einfach die Richtung der größten Änderung, damit hat man dann quasi direkt die Oberflächennormale von der Oberfläche, die einem am nähsten ist. Das tolle an diesem Trick ist, dass man sich nicht mal darum kümmern muss, was passiert, wenn man mit zwei Oberflächen gleichzeitig kollidiert. Denn dann ist der Gradient der Mittelwert beider Normalen und das ganze verhält sich automatisch korrekt. Sieht man auch hier ganz schön:

[Jonathan]

Ah ja, natürlich, ich hatte auf der Webseite geschaut, ob dort auch irgendwo analytische Ableitungen stehen, was ja prinzipiell auch eher nervig als schwer sein sollte. Mit finiten Differenzen geht das natürlich auch, die Funktionen sind ja alle eigentlich nicht so groß, dass die Extraauswertungen groß stören würden. Ich war spontan nur irgendwie nicht auf die Idee gekommen, dass so zu lösen, weil mir der Aufwand zu groß vorkam, bevor ich darüber nachgedacht habe.
Du könntest evtl. in der Gradientenberechnung den Offset (bzw. das Epsilon) noch wesentlich kleiner machen (z.B. 1e-4 anstatt 1). Da du eh hinterher normalisierst ist das nicht teurer, dürfte das Ergebnis in manchen Situationen aber genauer machen.

[xq]

Du könntest evtl. in der Gradientenberechnung den Offset (bzw. das Epsilon) noch wesentlich kleiner machen (z.B. 1e-4 anstatt 1). Da du eh hinterher normalisierst ist das nicht teurer, dürfte das Ergebnis in manchen Situationen aber genauer machen.

Die Präzision ist schon völlig ausreichend, zudem sind mein Kreise hier zwischen 32 und 96 groß, ich bin also schon gut Faktor 50 unter Strukturgröße. Wenns Probleme macht, kann man das natürlich immer noch reduzieren, aber bisher funktioniert's einfach und damit bin ich dann zufrieden

[scheichs]

Starcow hat mich dazu inspiriert, mal ein Kollisionssystem auf Basis von 2D-SDFs zu implementieren...

Schöne Sache. Danke für's zeigen!

[xq]

Ich bin immer noch überrascht, wie stabil und "glitchfrei" das ganze funktioniert. Ich hab mal noch nen kleinen Stresstest gecodet, der auch die drei "Betriebsmodi" des Systems (bounce, glide, nix) zeigt:



Man sieht aber auch grade bei "nix", dass das System bei weitem nicht perfekt ist (und ich noch nicht alle Edge Cases abgearbeitet habe)

[xq]

Dieses Wochenende hab ich wieder "von vorne" angefangen: Ein neues Framework auf Basis von Zig und OpenGL ES 2.0:


Seit sehr langer Zeit mal wieder einfaches Shadowmapping implementiert, als nächstes ist Postprocessing dran.
Meine Erfahrung mit Zig bisher ist ein: "Läuft". Läuft sogar richtig gut, die Sprache tippt sich angenehm und ist gut lesbar. Hier mal ein kleiner Auszug aus dem OBJ-Loader:

Code: Alles auswählen

pub fn load(allocator: *std.mem.Allocator, path: []const u8) !Model {
    var file = try std.fs.File.openRead(path);
    defer file.close();

    var stream = file.inStream();

    var model = Model{
        .positions = std.ArrayList(Vec4).init(allocator),
        .normals = std.ArrayList(Vec3).init(allocator),
        .textureCoordinates = std.ArrayList(Vec3).init(allocator),
        .faces = std.ArrayList(Face).init(allocator),
        .objects = std.ArrayList(Object).init(allocator),
        .allocator = allocator,
    };
    errdefer model.deinit();

    while (true) {
        var line = stream.stream.readUntilDelimiterAlloc(allocator, '\n', 1024) catch |err| switch (err) {
            error.EndOfStream => break,
            else => return err,
        };
        defer allocator.free(line);

        // parse comments
        if (std.mem.startsWith(u8, line, "#")) {
            continue;
        }
        // parse vertex
        else if (std.mem.startsWith(u8, line, "v ")) {
            var iter = std.mem.separate(line[2..], " ");
            var state: u32 = 0;
            var vertex = vec4(0, 0, 0, 1);
            while (iter.next()) |part| {
                switch (state) {
                    0 => vertex.x = try std.fmt.parseFloat(f32, part),
                    1 => vertex.y = try std.fmt.parseFloat(f32, part),
                    2 => vertex.z = try std.fmt.parseFloat(f32, part),
                    3 => vertex.w = try std.fmt.parseFloat(f32, part),
                    else => return error.InvalidFormat,
                }
                state += 1;
            }
            if (state < 3) // v x y z w, with x,y,z are required, w is optional
                return error.InvalidFormat;
            try model.positions.append(vertex);
        }
        // parse uv coords
        else if (std.mem.startsWith(u8, line, "vt ")) {
        	…
        } else {
            std.debug.warn("read line: {}\n", line);
        }
    }

    return model;
}

[xq]

Es geht weiter mit "von vorne Anfangen": Level-Laden mit Zuordnung zu Game Logic, Input, Game Logic ausführen:

[scheichs]

Total süss! Bin auch -ab und an- an 'nem Soccer Projekt dran.

[starcow]

Starcow hat mich dazu inspiriert, mal ein Kollisionssystem auf Basis von 2D-SDFs zu implementieren:

Sehr cool! Ich fühl mich geehrt! :-D
Sieht super aus!

[xq]

xq der alte Projektspringer hats schon wieder getan. Aktuelles Rumgewurstel: Eine x86-basierte "Virtual Console" a'la PICO-8, nur mit dem Unterschied, dass mein Kram auf echter Hardware läuft:

Programmiert wird mit einem Fake-Assembler (einfacheres Instruction Set als x86, wird aber "cross-assembliert") und es gibt später™ mal noch Editoren für Grafiken, Sounds und Musik...

Aktueller Stand: Man kann das Ding starten, sieht einen tollen Splash Screen, kann den Quellcode editieren und mit F5 assemblieren und ausführen:

[scheichs]

Ich liebe ja diese LowLevel Projekte von Dir. Erinnert mich zurück an die mid-90er, als ich in meinem Jugendzimmer, in warmen Sommernächten, an meinem SW-Renderer schrieb <3 ... und meine damalige Freundin mir deswegen die Hölle heiss machte ... XD
Natürlich ist Dein Zeugs da nochmal paar Ebenen drüber !

[xq]

Ich liebe ja diese LowLevel Projekte von Dir. Erinnert mich zurück an die mid-90er, als ich in meinem Jugendzimmer, in warmen Sommernächten, an meinem SW-Renderer schrieb <3 ... und meine damalige Freundin mir deswegen die Hölle heiss machte ... XD
Natürlich ist Dein Zeugs da nochmal paar Ebenen drüber !

Man dankt!

Das Projekt ist leider grade etwas eingefroren, warte auf Andrew, dass er den Bug mit packed structs fixed. Ich code das ganze in einer recht jungen Programmiersprache, die für mich ein guter Ersatz für C/C++ geworden ist, aber eben noch etwas Bugs hat. </werbung>

Darum habe ich in der letzten Woche an einem kleinen 2D-Projekt gecoded, welches im Stil der RPG-Maker-Spiele sein soll. Der aktuelle Status rendert UI-Elemente und eine Quadtree-organisierte Tilemap:



Fancy Font Rendering klappt mittlerweile auch:

[Krishty]

Felix, wie hast du’s denn auf Microsofts diesjährigen Ugly Christmas Sweater geschafft?

[xq]

Felix, wie hast du’s denn auf Microsofts diesjährigen Ugly Christmas Sweater geschafft?

ROTFL. Needs more xq!

Mein aktuelles Gewurstel, um mich vom Stress der puren Programmiererwelt abzulenken:

Projekt Spacewavr, ein Space War auf AVR implementiert:


Und was passiert, wenn man in C einfach mal das Array out-of-bounds indexed:

[xq]

Mehr Spacewar:


EDIT: Hier gibts auch noch etwas Projektdoku dazu, falls euch das interessiert :)

[Schrompf]

Baue aktuell an x uralten Projekten, um sie wieder fit zu machen. Daneben habe ich aber gestern mal ein Spaßprojekt angefangen - einen Dungeon Crawler. Im Endeffekt geht noch gar nix außer Rumlaufen, aber ich wollte damit eh was Technisches ausprobieren. Ein Spiel wird's wahrscheinlich nicht werden.

[xq]

Da Schrompf mich irgendwie dazu motiviert hat, hab ich mich mal hingesetzt und in Blender ein kleines Dungeon modelliert: