Reverse Engineering der NLT II

[wiese.hano]

Man sieht anscheinend deutlich, dass es sich um flache Texturen handelt. Dies war im Original nicht ganz so auffällig. Dass einem das so vorkommt, könnte daran liegen, dass es jetzt "full-screen" dargestellt wird.

Ich könnte aber damit "leben". So viel zu meinem ersten Eindruck.

[gaor]

Sehr cool! Daraus lässt sich bestimmt etwas machen.

Leider habe ich gerade nicht viel Zeit, mir größere Gedanken dazu zu machen. Spontan nur dies: Natürlich sollten die Häuser nicht auf allen Seiten Eingangstüren haben, aber das lässt sich bestimmt mit vernünftigem Aufwand noch ändern. ;-)

[Shihan]

Die Texturen sind tatsächlich sehr flach. Aber das fällt bei kleinerem Fenster nicht mehr ganz so auf bzw. stört nicht so sehr.
Wäre allerdings eine möglicher Ansatz für ein Mod

Die Eingangstüren lese ich gerade nicht aus der SCHICK.DAT aus, deshalb sehen alle Häuser gleich aus. Aber da bin ich schon dran

[aeyol]

Das ist klasse! Und ich finde den Nebel super, der unterstützt Räumlichkeit und Atmosphäre. Also bloß nicht weglassen.

Ansonsten wär mein erster Punkt auch, dass die ruckelige Fortbewegung noch unangenehm wirkt.

Welche Auflösung haben die Häusertexturen? Und würden verschiedene (höhere) Auflösungen ebenfalls unterstützt? (Stichwort Modding)

Billboards für die Wegweiser klingt nach einer eher fiesen Idee - zumindest wenn sie der Orientierung dienen sollten, hähä. Aber sinnvoll. *g*

Wie kommt das mit diesen (nun schwarzen) Sockeln an den Häusern? Ah. Wenn man sich genau das Haus im Original anschaut, scheint es ja "tiefer" zu liegen - https://i.ytimg.com/vi/pRvupm6biy4/maxresdefault.jpg und dieser Holzvorbau wirkt tatsächlich "vorgewölbt" - also wie von wiese.hano schon angemerkt, wirkt dadurch der erste Test hier flacher, weil dieser Vorbau-Maskierungstrick eben nicht mehr angewandt wird.
Stört mich jetzt auch nicht so sehr, aber ich find's interessant, dass die Vorlage in diesem Fall räumlicher wirkt.

Wie sieht's mit der Unterstützung von Alphatexturen aus? Und welches Dateiformat haben die?

[Mirko]

Hui, das sieht schon sehr interessant aus! Ich denke mal eine Umsetzung von fließenden Schritten würde sich wirklich lohnen. Die flachen Texturen stören mich persönlich weniger, aber ggf. könnte man hier ja die Möglichkeit einplanen, für jeden Wandtyp ein 3D-Modell laden zu können, das dann statt der flachen Textur angezeigt wird. Aber ich habe keine Ahnung wie komplex das wäre (mit Echtzeit-3D-Darstellungen habe ich mich noch nicht wirklich befasst). Den Nebel finde ich auch nicht schlecht. Ich hab damals in Riva die Sichtweite auch immer ganz runter gesetzt, weil die aus dem nichts auftauchenden bzw. nach 30 m abgeschnittenen Gebäude dort besser versteckt waren. War dadurch irgendwie atmosphärischer.

Wäre es eigentlich theoretisch auch möglich eine solche 3D-Darstellung in Bright-Eyes reinzuhacken? Vermutlich müsste die 3D Engine dann eigenständig parallel laufen und das Hauptprogramm müsste dann die Befehle weiterreichen (Drehung nach Rechts, Schritt nach Vorne, Tür durch geöffnete/eingeschlagene Tür ersetzen, Sonnenstand anpassen, Licht an/aus...) und bei den Sachen die so mehr Zeit brauchen (Flüssige Bewegungen statt Sprünge) auf die Rückmeldung warten. Dann müsste man noch irgendwie das 3D Bild mit der Oberfläche kombinieren. Vielleicht im eigentlichen Spiel das Pseudo-3D-Fenster mit einer Farbe, die dann als Transparenz genutzt wird, füllen und einfach über die 3D-Engine drüberkopieren? Aber sowas ist sicherlich nicht das, was du vorhast.

[Rabenaas]

Gefällt mir schon sehr und fängt die alte Stimmung gut ein.

[Alrik Alrikson]

[...]
Die Ortschaft kennt ihr bestimmt

Was meint ihr dazu?
[...]

Thorwal!

Gefällt mir sehr gut, wie das Original, nur in besserer Auflösung. Wobei ich beim Screenshot zuerst dachte, dass einige Texturen aus Riva kämen.

[Shihan]

Freut mich, dass es euch schon mal grundsätzlich gefällt. Dass die Atmosphäre möglichst nah am Original dran ist war mir sehr wichtig!
Bin selbst ein wenig überrascht, dass die Richtung stimmt. Wenn jetzt der Boden (Wasser, Gras und Stein) noch etwas passender ist und der Himmel irgendwie mehr hat, dann sind wir noch näher dran. Vielleicht probiere ich die Tage mal, den Stadt-Loader so aufzubohren, dass Eingänge und auch die verschiedenen Häusertypen besser erkannt werden (bisher kennt er nur Haus, Tempel, Wegweiser und legt ja überall einen Eingang hin). Denke mal, dass das dann noch besser aussehen wird.


Nun der Reihe nach zu euren Fragen:

Alles, was  diese Bibliotheksfunktion laden kann, kann als Textur genutzt werden. Dazu gehören also die Klassiker wie PNG (auch mit Alpha   ), GIF, JPEG, TGA, ...
Für unbekannte Formate (wie z.B. Schicks NVF oder BOB oder ACE oder oder oder) braucht man nur einen Loader zu schreiben, der am Ende 32-bit RGBA auswirft. Das lädt dann diese Bibliotheksfunktion.
Also sind wir was Texturen angeht ziemlich frei. Laut http://feedback.wildfiregames.com/report...XTURE_SIZE haben die meisten (99%) heutzutage üblichen Graphikkarten eine maximale Texturgröße von 2048. Ich denke, auch 4096 wäre möglich (95%). Aber dann sind wir, was die Größen angeht, definitiv auf AAA-Blockbuster-Niveau.


Die Sache mit den flachen Texturen ist etwas anderes. Bisher zeichne ich hier nur ein Quadrat (also eigentlich zwei Dreiecke    ) und lege da die Textur drauf, aber da könnte auch ein komplexeres 3D-Objekt als Wand herhalten. Wäre alles machbar. Muss nur eingebaut werden.
Vielleicht auch mittels Normalmap und Bump-Mapping. Auch das sollte in einer handvoll Stunden eingebaut werden können. Habe ich aber erstmal nach hinten gelegt, weil mir noch nicht klar ist, ob ein Lighting-System die Atmosphäre nicht wieder kaputt macht (weil es dann zuviel Eyecandy wäre). Da bin ich unentschlossen...


Diese Darstellung kann man so aber leider nicht ohne weiteres in BrightEyes reinhacken. Eventuell wäre das machbar, aber unendlich umständlich und keinesfalls etwas, worauf ich persönlich Lust habe. Jemand anderes kann das aber gerne machen. Sobald BrightEyes dann einen funktionierenden OpenGL 3.3 Kontext hat, kann ich wieder einsteigen und den City-Renderer drüberstülpen


Ja, es ist Thorwal
Dachte mir, dass das in jeder Hinsicht ein guter Startpunkt ist! Aus Riva habe ich noch keine Texturen genommen, aber das wäre grundsätzlich möglich. Habe Code, der aus den Riva-eigenen PIX-Dateien schon 32bit-RGBA machen kann. Den einzubauen sollte möglich sein.

[NewProggie]

Die Sache mit den flachen Texturen ist etwas anderes. Bisher zeichne ich hier nur ein Quadrat (also eigentlich zwei Dreiecke    ) und lege da die Textur drauf, aber da könnte auch ein komplexeres 3D-Objekt als Wand herhalten. Wäre alles machbar. Muss nur eingebaut werden.
Vielleicht auch mittels Normalmap und Bump-Mapping. Auch das sollte in einer handvoll Stunden eingebaut werden können. Habe ich aber erstmal nach hinten gelegt, weil mir noch nicht klar ist, ob ein Lighting-System die Atmosphäre nicht wieder kaputt macht (weil es dann zuviel Eyecandy wäre). Da bin ich unentschlossen...

Man könnte sich einen kleinen Geometry Shader hacken, der den Haustexturen an Tür und Fenster etwas mehr Tiefe gibt. Da die ganzen gezeichneten Texturen auch immer mit einer bestimmten Lichtrichtung gezeichnet wurden (frontal von oben), ließe sich der Shader direkt aus der Farbintensität pro Pixel berechnen. Wenn man mal von simplen Lambert'schen Reflektionseigenschaften ausgeht, dann wäre die Intensität (I e N) pro Pixel gerade der Kosinus des Winkels zwischen Oberflächennormale (n e N^3) und Lichtrichtung (l e N^3): I = <n, l>. Die Intensität lässt sich aus der Farbe bestimmen und die Lichtrichtung kann man wie gesagt, grob schätzen. Mit der gewonnen Oberflächenausrichtung pro Pixel würde man dann entsprechend an den Kanten von Tür und Fenster und Hausrändern dann etwas die Geometrie der Vertices nach Z verschieben. Statt zwei Vertices pro Textur würde ich vermutlich ein "Tesselation für Arme" machen: Das ließe sich ebenfalls leicht machen, in dem man irgendeinen Kantenfilter nimmt (z.B. Sobel) und die Informationen aus dem Filter verwendet, um die Vertices pro Textur zu erzeugen. Die so zerteilte Hauswand dann wie oben mit einem Shader noch zurecht rücken und mal schauen, wie das Ergebnis aussieht :-)

[Shihan]

Ha, das ist mal ein interessanter Ansatz! Sowas ist mir gar nicht in den Sinn gekommen (liegt wohl daran, dass ich bisher nur in Vertex- und Fragment-Shadern unterwegs war, niemals im Geometry Shader).

Ich vermute mal, dass das auf ziemliches Parametertuning hinausläuft. Die Position der Lichtquelle muss man experimentell bestimmen, ebenso wie den Versatz auf Z. Und den verwendeten Kernel auch. Was aber alles machbar wäre, wenn der Shader grundsätzlich vorhanden ist.

Hast Du da Erfahrungen?

[Rabenaas]

Ich würde erst mal die Texturen grau machen und dann als Bumpmap über die eigentlichen legen. Die genaue Richtung der Beleuchtung ist vermutlich bei der beinahe-Comicgrafik nicht so wichtig. Sowas habe ich aber bisher nur mit Raytracern gemacht, noch nicht in GL.

[wiese.hano]

Richtig: Der Nebel sollte auf jeden Fall drin bleiben!

Auch die Möglichkeit, sich schrittweise zu bewegen, sollte (wenigstens als Option) erhalten bleiben und auch für das Drehen verfügbar sein, eben so, wie im Original.

Wenn man mal von simplen Lambert'schen Reflektionseigenschaften ausgeht, dann wäre die Intensität (I e N) pro Pixel gerade der Kosinus des Winkels zwischen Oberflächennormale (n e N^3) und Lichtrichtung (l e N^3): I = <n, l>.

Ja, nee, is klar.

[Tobi]

Programmiertechnisch tendiert mein Wissen leider gegen null. Möchte nur anmerken, daß ich auch schwer beeindruckt bin.
Der Nebel ist klasse. Sorgt für Flair, absolut!
Für die (zumindest angedeutete!?) schrittweise Bewegung bin ich auch, ich würde sonst etwas vermissen.
Wolken wären toll.

[wiese.hano]

Ich habe, sagen wir mal, Grundkenntnisse in prozeduraler Programmierung mit C und Ansatzweise mit C++, aber das reicht natürlich nicht, um sich hier sinnvoll einzubringen, zu mal ich mich gerade mit Java beschäftige und davon auch nicht weg möchte.

Umso mehr freut es mich, dass jetzt hier wieder Bewegung in das Projekt kommt. Macht weiter!

[Borbaradwurm]

Hier findet ihr ein kleines Video (liegt auf meinem Server):

Was meint ihr dazu?

Was mir im Video sofort auffällt ist das die Hälfte der Textur-Koordinaten falsch sind (bei HOUSE1.NVF #0 ist die Tür auf der linken Seite, im Video sind die Texturen der nach Norden und nach Osten ausgerichteten Quads horizontal gespiegelt).

Die Ortschaft kennt ihr bestimmt

Es ist diese hier, nicht war:
   
   
   
Mein Programm basiert auf C++14 mit SDL 2.0 OpenSceneGraph (die temporären Bodentexturen sind aus Drakensang).

• der Schritt nach vorn/hinten/links/rechts könnte ähnlich flüssig sein wie die Rotation.
  
• wie erwähnt: Billboards für die Wegweiser
  

Funktioniert bei mir gut. Doom-Style-Sprites auch für den Leuchtturm und den Schwarzen Finger.

• Häusertexturen haben mitunter einen Sockel (schwarzer Rand unten), den müsste man noch entfernen
  

Mache ich per Textur-Koordinaten, man muss jedoch darauf achten das die Textur-Höhen der Eingangs- und der Seiten-Textur übereinstimmen da die 3d-Ecken der Quads sonst extrem auffallen.

[Shihan]

Das sieht aber auch gut aus! Wie ich sehe, hast du dich auch für NN-Filtering entschieden. Erhält den Retrolook besser, wie ich finde.
Was kann denn dein Programm schon alles schönes?



Die Texturkoordinaten können bei mir noch gar nicht stimmen, weil ich denen bisher keinerlei Aufmerksamkeit geschenkt habe. Mir ging es erstmal um Loader für die diversen Binärformate und einen generellen Renderer für eine Grid-basierte Stadt.

Die nächsten beiden Ziele sind:
- Wahlmöglichkeit klassische Steuerung (mit Sprüngen) <-> Schweif-artige Steuerung mit Interpolation ("weiche" Schritte bzw. Drehungen)
- Auswahl der richtigen Texturen für jedes Haus (das wird dann der Zeitpunkt sein, wo ich mich um die Texkoords kümmere)

Und vorher noch etwas größeres Refactoring, damit der Code sauberer wird.

[wiese.hano]

Jetzt habe ich gedacht, ich muss doch mal gucken, wie die Dialoge (in der Schicksalsklinge) organisiert, bzw. strukturiert sind, d.h. ermitteln, wie die Strings gespeichert sind (Speicherort) und wie die Logik zum Abruf derselben lautet.

Hauptsächlich geht es mir um die Dialoge in den Tavernen, aber auch die von Händlern, Herbergen und Schmieden sind interessant, ebenso wie alle sonstigen Dialoge.

Dabei war ich der Meinung, dass es hier im Forum irgendwo eine "Sammlung" sämltlicher Dialoge gibt, weiß aber nicht mehr, wo. Wenn dem so ist und jemand den entsprechenden Thread kennt oder schnell findet, würde ich mich über die Information freuen.

Jedenfalls annimierte mich das, einen Blick ins Bright-Eyes-Wiki zum Thema TLK-Dateien zu werfen. Leider sind die dort aufgeführten Infos nicht intuitiv erschließbar. Man muss schon über jede der Angaben einen Moment nachdenken, bevor man begreift, was sie bedeuten.

Und wie es der Namenlose will, bin ich sehr schlecht im Denken.

Warum z.B. ist in den Dateien zu jedem Dialog die Anzahl der Gesprächspartner aufgeführt? Welchem Zweck dient das? Und vorauf bezieht sich "Gesprächspartner" überhaupt? I.d.R. sind die Gesprächspartner meine Gruppe (1-7 Leute) und ein weiterer Gesprächspartner (Wirt, Herbergsvater, etc.). In wie weit ist das für die Spiellogik relevant?

[gaor]

Ich habe für viele der Daten in der SCHICK.DAT schonmal ein Tool in Python geschrieben - auch für die Dialoge. Vielleicht hilft dir das? https://github.com/tuxor1337/schick-data-gui Der Code für das Laden der TLK-Dialoge ist in https://github.com/tuxor1337/schick-data...er.py#L382

Die "Anzahl der Gesprächspartner" ist missverständlich. Eigentlich müsste es "Anzahl der Dialoge" heißen. Denn es sind mehrere Dialoge in jeder TLK-Datei gespeichert.

[Shihan]

Gut, dass du das ansprichst, gaor!
Habe gestern Abend folgenden Fehler mit schick-data-gui gehabt (Win7, Python3.4):

Code:

Traceback (most recent call last):
   File "schick-data-gui.py", line 4, in <module>
      from schick.gui.base import SchickGUI
   File "D:\dev\nlt\schick\schick-data-gui\schick\gui\base.py", line 4, in <module>
      from schick.gui.dat import SchickDatContent
   File "D:\dev\nlt\schick\schick-data-gui\schick\gui\dat.py", line 2, in <module>
      from schick.gui.dat_extra import *
   File "D:\dev\nlt\schick\schick-data-gui\schick\gui\dat_extra.py", line 259
      "({:02d},{:02d}): {} (#{}, {})".format(*l[0][1:], *l[1:])
                                                                                 ^
SyntaxError: invalid syntax

Ideen?

[sonicpp]

Guten abend!

Sorry for spamming here in english, but the english part of this forum is very rarely used.

First of all I want to thank you for all your work you have made, reverse-engineering machine code, trying to rewrite the engine etc.

I am reading this topic with google translate, so I am not sure that I understood everyting you said. My reply is to discussion about the direction of the project. Personaly I prefer something like OpenDUNE, which:

attempts to re-create the original game and apply modern technology to it to allow it to be run natively on most operating systems.

You can run the game in two modes:

1. mode when game acts like the original Dune II, including bugs
   
2. original game with fixes and improvements (small ones)
   

The reason why i prefer this way is that we can have the original game running natively, open sourced, keeping in mind that we play the ORIGINAL. If we (you) want to do it more moddable, add more new stuff, multiplayer etc, then it should be different project. Thats are just my two points.

Keep up the good work and sorry again for writing here in english (if you want reply to me, do it in german, I will use tranlator) . Auf wiedersehen