DeutschEnglish USEnglish GB
GoldenCode

Seit etwa 2011 entwickelt (oder hilft bei der Entwicklung) GoldenCode alias Daniel 'Daytona675x' Müßener knorke Spiele für alle wichtigen sogenannten Amiga-Varianten "der nächsten Generation":

AmigaOS4, MorphOS and AROS

Wings Remastered Entwicklungstagebuch

Wie ihr vielleicht wisst, bin ich momentan dabei, das PC Spiel Wings Remastered zurück auf unsere geliebten Amigas zu portieren.
Zunächst einmal danke an alle, die das durch ihre Vorbestellungen überhaupt möglich machen!

Leider ist bislang nur rund die Hälfte der wirklich für dieses Projekt notwendigen Anzahl an Vorbestellungen eingegangen.
Das bedeutet, dass ich zwar weitermache, aber nicht mit voller Kraft. Es ist einfach nicht genug zusammengekommen, so dass ich nicht Vollzeit daran arbeiten kann.
Deswegen ist es auch eher unwahrscheinlich unmöglich, dass das angekündigte Erscheinungsdatum Februar 2016 eingehalten wird.

Das ganze Ding ist kein vergleichsweise simpler SDL Port oder so! Es muss komplett neu geschrieben und nebenbei natürlich etliche Assets angepaßt werden.
Die ursprünglich geschätzte Dauer betrug ca. 3 Monate Arbeit; weil ich jetzt halt nicht Vollzeit dran arbeiten kann (siehe oben), wird es freilich länger dauern.
Wenn es weiterhin so läuft wie bisher, dann ist Mitte März 2016 realisitisch es fertig, wenn es fertig ist (was meine Programmierarbeit betrifft).

Weil die ganze Forenaktiviät auch Zeit kostet, habe ich mich dazu entschieden, dieses Projekttagebuch zu führen. So kann jeder die wichtigsten Fortschrittsinformationen usw. hier an einem Ort konzentriert und immer aktuell nachlesen und ich muss mich weniger in den Foren tummeln und dort Infohäppchen mal hier mal da verteilen.
Ich hoffe euch gefällt das!
Hier geht's zum neuesten Eintrag.

Bis denne,
Daytona675x

Wichtige Links:

Hier vorbestellen
Einige Screenshots
AmigaOS4 Demo Video

Demo-Version für AmigaOS4 Warp3D
Demo-Version für AmigaOS4 Compositing
Demo-Version für MorphOS TinyGL
Demo-Version für AROS x86 OpenGL

2015-12-05:

Einiges von dem hier folgenden Kram wurde schon vor einigen Tagen eingebaut, ich fange einfach mal grob da an, wo die Demoversion endete:

2015-12-07:

2015-12-10:

2015-12-11:

2015-12-12:

2015-12-13:

2015-12-14:

2015-12-15:

2015-12-16:

2015-12-17:

2015-12-18:

2015-12-19:

2015-12-20:

2015-12-21:

2015-12-22:

2015-12-23:

2015-12-24:

2015-12-30:

2016-01-03:

2016-01-16:

2016-01-17:

2016-01-18:

2016-01-20:

2016-01-21:

2016-01-22:

2016-01-23:

2016-01-25:

2016-01-26:

Ernsthafte 3D Modellkonvertierung Phase 1:


2016-01-27:

Ernsthafte 3D Modellkonvertierung Phase 1, Teil 2:


Die alle sind jetzt soweit ins korrekte Format gebracht. Das sind aber leider längst nicht alle Modelle, aber die wichtigsten, für's erste jedenfalls. Nahezu alle Modelle liegen übrigens in zwei Versionen vor, nämlich heil und kapput. Das dumme ist, dass die alle in etlichen verschiedenen Varianten in dem Assethaufen auftauchen; wobei die sich nicht im Design unterscheiden, sondern eher technisch, also was Polycount und Materialien betrifft. Zudem sind da auch irgendwelche Zwischenstände mit dabei, also fehlerhaftes bzw. unfertiges. Hier gilt es jetzt zunächst einmal auszumisten und nachzubearbeiten.


2016-01-28:

2016-01-29:

2016-01-30:

2016-02-02:

2016-02-04:

2016-02-06:

2016-02-09:

ModelConverter: etliche neue Befehle (z.B. um Objekte zu zentrieren oder auf den virtuellen Boden zu setzen), am wichtigsten davon sicherlich diese zwei Dinge:


2016-02-10:

2016-02-11:

2016-02-12:

Wie ihr vielleicht wisst benutze ich Cinema4D zum 3D Modellieren / Editieren. Natürlich eine etwas modernere Version, nämlich inzwischen die allerneueste, R17. Bis dato hatte ich R10 von anno pief, aber das Wings-Projekt machte ein Update dringendst notwendig, denn der FBX-Importer von R10 ist indiskutabel katastrophal und veraltet - und natürlich sind alle Modelle bei Wings im FBX Format. Also rund 800 Euronen in die Hand genommen und geupgraded.
C4D ist ja insgesamt eine feine Sache, aber bei einigen Dingen fragt man sich schon, ob die da irgendeinen untalentierten Praktikanten ran gelassen haben. Ganz besonders verkorkst ist leider der Wavefront OBJ Exporter. Wir reden hier über ein Standard-3D-Dateiformat von 1989. Und selbst in R17 ist der Exporter (mal wieder) total hinüber (kleines Beispiel: im Export finden sich 'Normalen' mit der Länge 0 und sonstige Scherze). Aber dummerweise nutzt mein Framework OBJ als Austauschformat...
Bis heute mußte ich daher folgenden Umweg gehen: Modell in R17 importieren, Modell editieren, dann nach 3DS exportieren, dann R10 starten und das 3DS importieren, dann aus R10 ein OBJ mittels eines kommerziellen Plugins (Riptide Pro) wegschreiben. Blöd ist nämlich, dass es von Riptide Pro kein Update für R17 gibt und das R10er Plugin ist nicht kompatibel :P
Heute hatte ich endgültig die Nase voll davon! Ich beschloß also, mal wieder ein eigenes Plugin für C4D zu schreiben. Um genau zu sein ein COFFEE Skript. Also ein OBJ-Exporter-Skript für R17.


2016-02-13:

Sooo, das Skript ist fertig! Hat tatsächlich so anderthalb Arbeitstage gekostet. Warum? Weil man von COFFEE aus zumindest nicht ohne weiteres an die Normalen-Vektoren eines Modells kommt und weil die Dokumentation ein schlechter Witz ist, grrr.
Die Normalen darf man sich selbst berechnen. Witzigerweise habe ich inzwischen herausgefunden, dass es bei C4D's Python Schnittstelle (neuerdings kann man auch Python zum Skripten benutzen) eine Funktion namens CreatePhongNormals dafür gibt. Bei COFFEE haben sie die wohl vergessen, danke sehr.
Um korrekte Normalen zu generieren reicht es natürlich nicht, einfach die Normalen eines Dreicks zu berechnen und dann für die Vertices den Durchschnitt zu bilden. So macht es vielleicht Heinz Blöd, aber nicht unsereiner. Nee, nee, da muss man schon ein wenig mehr tun. Denn an harten Kanten soll ja die Beleuchtung auch hart sein und nicht aufgeweicht. Zu diesem Zweck gibt es bei C4D sog. Phong-Tags. Da steht grob gesagt drin, ab welchem Winkel zwischen zwei Flächen nicht aufgeweicht werden soll. Nun, ohne ins Detail zu gehen: die Doku gibt noch nicht einmal das preis, geschweige denn, wie man das Winkel-Attribut von COFFEE aus abfragen kann...
Naja, wie auch immer: es ist vollbracht und funktioniert Sahne:


Ich habe mal eine schöne Photosession zusammengestellt, die den ganzen Modellkonvertierungsprozess illustriert. Viel Spaß!


2016-02-14:

2016-02-15:

LevelConverter Teil 1: es ist an der Zeit, sich um die echten Level-Karten zu kümmern. Für die Demo-Versionen hatte ich natürlich lediglich dreckige Abkürzungen genommen... Aber diesmal ist's ernst :)
Ich habe nun das XML Format für die Bombing- und Strafing-Missionen genau analysiert. Ja, es ist das selbe Format für beides. Für die PC Version bzw. Unity3D sind beide Arten von Levels technisch identisch: in beiden Fällen ist es eine dicke 3D Szene mit tausenden 3D Objekten und optional noch Unterobjekten ( = Soldaten). Plus noch spezielle Infos wie 'gibt es einen Zug?', 'Wetter?', etc.
Alles in allem besteht so eine Leveldatei aus 62 Kommandos / Strukturelementen. Alle werden vom LevelConverter korrekt ausgewertet. Aber bevor ich daraus jetzt wirklich meine eigenen Leveldateien generiere, muss ich noch etwas Analyse der konkreten Level-Inhalte betreiben (z.B. wie ist die maximale Anzahl unterschiedlicher Grafikbausteine in einem Bombing-Level und wie ist die max. Anzahl Soldaten, etc.). Diese Informationen sind ziemlich wichtig, wenn es darum geht, den optimalen Weg bei der tatsächlichen Implementierung einzuschlagen. Und je nachdem macht es evtl. Sinn, gewisse Dinge bereits in der Level-Datei auf die eine oder eine andere Art zu bunkern.
Übrgens, die originalen Karten-Definitionsdateien summieren sich zu, bitte hinsetzen: 99 MB! Kein Witz!
Ich benutzte freilich das universelle chunk-basierte Dateiformat, das ich mir für die 3D-Modelle gebastelt hatte, weswegen die konvertierten Leveldateien um ein paar Größenordnungen kleiner sein werden... Ich kann noch nicht genau sagen, wieviel es letztendlich sein wird, weil ich noch nicht 100%ig damit durch bin, aber ich glaube nicht, dass es mehr als 2 MB für alle sein wird.


2016-02-16:

LevelConverter Teil 2: Auch wenn das original Dateiformat für Bombing- und Strafing-Missionen das gleiche ist, so bedeutet das nicht, dass das für unseren Amiga Port auch die beste Idee ist. Ich fand heraus, dass es dort reichlich Informationen gibt, die entweder hier oder dort auftauchen, aber nicht bei beiden. Ich habe auch die Wertebereiche aller Attribute überprüft, denn letztlich gilt: warum mehr als ein Byte für einen positiven Integerwert wegspeichern, der nie größer als 255 werden kann? Ja, mag Korinthenkackerei sein, aber ich finde, wenn ich schon mal dabei bin, warum es nicht perfekt machen?
Aber egal, wie gesagt, es ist sinnvoll, zwischen Bombing- und Strafing-Karten zu differenzieren. Heute hatte ich erst einmal 'Spaß' mit den Bombing-Levels :P


2016-02-17:

2016-02-18:

2016-02-20:

2016-02-21:

2016-02-22:

2016-03-02:

Ja, ja, ich weiß, ich bin momentan etwas faul - aber nur was dieses Tagebuch betrifft ;)
Ich habe eben mal drei neue Screenshots rausgegeben, die die Optimierung des Flugzeugs für die Bombing-Missionen skizzieren. Bemerkenswert ist dabei auch, dass die Bomben ebenfalls optimiert sind: wenn sie am Flugzeug hängen, dann sind es eigentlich nur halbe Bomben, und ohne Unterseite. Nur während sie fallen wird das komplette Modell genutzt. Macht einen gewaltigen Unterschied...
Aber natürlich gab es auch sonst massig Optimierungen am Unterbau, hier mal aktuelle Werte:

Typischer Bombing-Level auf einem sam440ep, on-board Radeon, 640x480 16bit, Vollbild, kein Vsync, keine DXT Texturkompression (die niedrige Auflösung wurde gewählt, weil hier die Unterschiede so schön groß sind):

1. 8 Bomben am Flugzeug: ca. 140 fps
2. alle 8 Bomben fallen gleichzeitig (also 8x das komplette Modell): ca. 105 fps
3. keine Bomben: ca. 190 fps

Und in 1680 x 1050 (der höchsten Auflösung, die dieser sam überhaupt kann):

1.: ca. 75 fps
2.: ca. 65 fps
3.: ca. 95 fps

Wie ihr seht ist es selbst in höchster Auflösung auf dieser Low-End-Kiste butterweich. Viel schneller als die Platzhalter-'Engine' der Demoversion...


2016-03-03:

2016-03-06:

2016-03-07:

2016-03-08:

2016-04-01:

2016-04-05:

2016-04-27:

2016-05-17:

2016-05-26:

2016-06-02:

2016-06-20:

2016-06-22:

2016-06-24:

2016-06-25:

2016-06-26:

2016-06-27:

2016-06-29:

2016-07-01:

2016-07-02:

2016-07-03:

2016-07-04:

2016-07-17:

2016-07-18:

2016-07-19:

2016-08-15:

2016-08-16:

2016-08-17:

2016-08-18:

2016-08-28:

2016-10-13:

2016-12-15:

2016-12-17:

2016-12-18:

2016-12-19:

2016-12-20:

2016-12-22:

2016-12-23:

2016-12-24:

2016-12-26:

2016-12-27:

2016-12-31:

2017-01-04:

2017-01-13:

2017-01-14:

2017-01-16:

2017-02-08:

Ich finde nicht sonderlich oft Zeit, diesen Blog hier zu updaten, schon gar nicht zweisprachig. Deswegen empfehle ich, einfach meine öffentlichen Alben auf Facebook anzusteuern, wenn man sich auf dem Laufenden halten will. Ich habe zwar gerade alles was sich die letzten Monate getan hat hier herüberkopiert, aber werde ich wohl nicht so oft machen - und übersetzt ist es auch noch nicht. Deswegen: schaut euch diese Links hier an, keine Registrierung notwendig:

Hinweis:

201 Exemplare sind schon weg, nur noch 99 verfügbar. Also besser schnell vorbestellen!