Zitat von Gerd im Beitrag #19Nabend! Auch wenn es überrascht, ich lese mit und bin erstaunt was hier so "abgeht"! Da muß ich wohl nochmal beginnen und mich genauer einlesen. Es ist aber wirklich interessant und die Zusammenarbeit scheint zu funktionieren. Weiter so! Echt klasse Arbeit.
Gruß Gerd
Hallo Gerd. Schön, dass dir meine Arbeit gefällt. Ich dachte mir ich fange mit diesem Thread mal an meinen Fortschritte, Pläne und Niederlagen regelmäßig zu posten, damit die Arbeit transparenter wird und die Wartezeit vielleicht etwas schneller verstreicht. Außerdem scheint es so zu einem besseren Ideenaustausch zu kommen.
Und nun zum aktuellen Stand. Ich habe diese Woche erstmal an meinem Tool zur Erstellung von PG3DE2XX kompatiblen SHP und Pnazer2.dat Dateien gearbeitet. So wie ich es verstanden habe liegt das Hauptinteresse an der Unterstützung von PNG-Dateien ja zum einen in der geringeren Größe und zum anderen an dem immer größer werdenden Angebot von neuen Grafiken in diesem Format. Da mein Tool ja OG Grafiken in neue PG Grafiken umwandeln und auch neue PG Grafiken erstellen soll habe ich mich damit beschäftigt möglichst kleine PNGs aus beliebigen Vorlagen zu erstellen. Getestet habe ich gegen die 9914 PNGs von Open General. Ich lade dazu die Bilder in meine Anwendung und speichere alle wieder als PNGs ab. Manche meiner PNGs sind kleiner andere größer als das Original. Im Durchschnitt ist jedes PNG um 8,42% größer als die von Hand erzeugten OG PNGs. Das sind ca. 86 Bytes pro Kilobyte. Für den Anfang reicht mir dass erstmal. Wer hoch optimierte SHP-Dateien erstellen will muss die PNGs erstmal von Hand erzeugen. Wichtiger ist erstmal die Arbeit am Spiel selbst.
Zitat von James Font im Beitrag #22... liegt das Hauptinteresse an der Unterstützung von PNG-Dateien ja 1. zum einen in der geringeren Größe 2. zum anderen an dem immer größer werdenden Angebot von neuen Grafiken in diesem Format.
Huch, Miss Verständnis ist wieder auf dem Laufsteg.
1. Die Größe ist der Grund der OpenGeneralisten, alles, also auch die bisherigen SHPs, auf PNG umzustellen. Mich interessiert das nicht die Bohne; ob sich einmal im Jahr jemand 25 oder 35 MB (bezogen auf die Panzer2.dat) runterlädt, ist doch völlig wurscht; wir leben nicht mehr im C64-Zeitalter! Bevor du da viel Zeit investierst und evtl. sogar optische Qualitätsverluste auftreten, lass es lieber.
2. Ja, das ist der einzige Grund!
Nostalgie ist auch nicht mehr das, was sie mal war.
Zitat von James Font im Beitrag #22... liegt das Hauptinteresse an der Unterstützung von PNG-Dateien ja 1. zum einen in der geringeren Größe 2. zum anderen an dem immer größer werdenden Angebot von neuen Grafiken in diesem Format.
Huch, Miss Verständnis ist wieder auf dem Laufsteg.
1. Die Größe ist der Grund der OpenGeneralisten, alles, also auch die bisherigen SHPs, auf PNG umzustellen. Mich interessiert das nicht die Bohne; ob sich einmal im Jahr jemand 25 oder 35 MB (bezogen auf die Panzer2.dat) runterlädt, ist doch völlig wurscht; wir leben nicht mehr im C64-Zeitalter! Bevor du da viel Zeit investierst und evtl. sogar optische Qualitätsverluste auftreten, lass es lieber.
2. Ja, das ist der einzige Grund!
Nur kurz bevor ich ins Bett gehe. Über einen optischen Qualitätsverlust brauchst du dir keine Sorgen machen. PNGs werden ja in immer verlustfrei gespeichert und ich manipuliere auch nicht an den Pixelfarben rum. Wenn es einen Qualitätsverlust gäbe, währe es ein Programmierfehler. Schön dass es nicht immer die allerkleinste Datei sein muss. Dann lag ich ja richtig mit meinen Prioritäten. Die Arbeit die ich mir bis jetzt gemacht habe war auf jeden Fall notwendig, weil es neben der Größe auch um das richtige einlesen der Pixel ging. 1-Bit, 2-Bit, 4-Bit, 8-Bit, 24-Bit und 32-Bit Bilder werden ja alle unterschiedlich im Speicher dargestellt und bei in paar Formaten gab es da Probleme.
Jetzt arbeite ich an der automatischen Konvertierung vieler Dateien auf einmal in das neue PG3DE2XX SHP-Format.
Hallo. Ich habe wieder einen Fortschritt zu verkünden. Diesmal gibt es keinen Screenshot, weil man keinen Unterschied zum normalen Spiel sehen würde. Gestern habe ich mein Tool zur Erstellung des neuen PG-SHP Grafikformats soweit gebracht, dass es, ohne eine Fehlermeldung auszuwerfen, Rayys komplette Panzer2.dat entpackt und gleichzeitig alle alten SHP-Grafiken in das neue PNG gestützte Format umgewandelt hat. Das ganze habe ich dann mit dem PG2 ShpTool wieder in eine neue Panzer2.dat verpackt. Heute habe ich dann das Spiel damit gestartet. Es waren zwar einige Grafikfehler zu sehen aber immerhin gab es keinen Absturz. Danach habe ich den Grund für die Grafikfehler in meinem Quelltext beseitigt. Das Spiel lässt sich also jetzt komplett auf PNG-Grafik umgestellt spielen.
Leider ist mir ein unschönes Problem aufgefallen, das Rayy aber vermutlich erstmal egal seien wird. Das Laden einiger Bildschirme, wie z.B. dem Einkaufsbildschirm, dauert merklich lange und bei jedem Buttonklick auf diesen Bildschirmen gibt es die gleiche Verzögerung. Ursache sind auf jeden Fall die PNG Grafiken. Ich vermute, dass das Spiel sich hier nicht ganz ressourcenschonend verhält und für viele Zeichenoperationen die betreffende Grafik neu aus der Panzer2.dat liest anstatt die Grafik im Speicher vorzuhalten. Da das Laden einer PNG-Grafik wesentlich rechenintensiver ist als bei den normalen SHP-Dateien, bleibt das Spiel dadurch hängen. Das ganze betrifft anscheinend nur die Dialoge. Zumindest habe ich auf meinem Rechner bis jetzt kein Problem mit den Einheiten festgestellt. Die werden vermutlich nicht so häufig neu geladen. Wenn ich für die Dialoge wieder die alten SHP-Dateien einspiele, läuft das Spiel bei mir flüssig. Ich untersuche das weiter und teste am Wochenende auch mal auf zwei langsameren PCs.
Hmmmnnnjaaa ... dass es grundsätzlich geht und alles in einer Panzer2.dat, d.h. nicht verteilt auf Dat und Ordner, liegt, ist natürlich klasse. Signifikante Verzögerungen im Spiel wären allerdings störend. Der Hauptgrund, warum ich einst OpenGen ad acta gelegt habe, waren (gefühlte) Gedenkminuten bei einigen Aktionen! PG2 lässt sich (bisher) einfach flüssiger spielen.
Da führt zurück zu der Frage: Warum hast du die Hintergrund-SHPs (alt) ebenfalls in die neuen 'PNG-SHPs' umgewandelt? Vermutlich, damit alles im einheitlichen Format in die Dat passt. Da führt zurück zu der Frage: Warum gibt es ein neues SHP-Format? Kann man die PNGs nicht in das alte SHP-Format konvertieren und dann wie bisher in die Dat schmeißen? Das hätte auch den Vorteil, dass die Suite sie darstellen kann, denn Luis wird das neue Format sicher nicht dort einbauen (er bastelt ja nicht mal die Bugs raus).
Vielleicht schreibe ich am Problem vorbei. Um Diskussionen im luftleeren Raum zu vermeiden, schick mir doch bei Gelegenheit mal den aktuellen Stand. Dann kann ich auch die Verzögerungen auf meiner altersschwachen 2 GHz-Mühle besser einschätzen.
Nostalgie ist auch nicht mehr das, was sie mal war.
Zitat von Rayydar im Beitrag #26Hmmmnnnjaaa ... dass es grundsätzlich geht und alles in einer Panzer2.dat, d.h. nicht verteilt auf Dat und Ordner, liegt, ist natürlich klasse. Signifikante Verzögerungen im Spiel wären allerdings störend. Der Hauptgrund, warum ich einst OpenGen ad acta gelegt habe, waren (gefühlte) Gedenkminuten bei einigen Aktionen! PG2 lässt sich (bisher) einfach flüssiger spielen.
Da führt zurück zu der Frage: Warum hast du die Hintergrund-SHPs (alt) ebenfalls in die neuen 'PNG-SHPs' umgewandelt? Vermutlich, damit alles im einheitlichen Format in die Dat passt. Da führt zurück zu der Frage: Warum gibt es ein neues SHP-Format? Kann man die PNGs nicht in das alte SHP-Format konvertieren und dann wie bisher in die Dat schmeißen? Das hätte auch den Vorteil, dass die Suite sie darstellen kann, denn Luis wird das neue Format sicher nicht dort einbauen (er bastelt ja nicht mal die Bugs raus).
Vielleicht schreibe ich am Problem vorbei. Um Diskussionen im luftleeren Raum zu vermeiden, schick mir doch bei Gelegenheit mal den aktuellen Stand. Dann kann ich auch die Verzögerungen auf meiner altersschwachen 2 GHz-Mühle besser einschätzen.
Hallo Rayy. Du schreibst nicht nur am Problem vorbei . 1. Also, ich habe alle Dateien umgewandelt, weil ich sonst hätte festlegen müssen welche Grafiken nicht umgewandelt werden sollen und, noch wichtiger, weil das ein wunderbarer Stresstest ist. Wenn wirklich alle Grafiken im neuen Format sind fallen Fehler und unschöne Effekte, wie die Verzögerung, einfach am schnellsten auf.
2. Das ganze ist natürlich nur für die Testversion gedacht. Sinn macht später eine gesunde Mischung. Grafiken, die ausschließlich Standartfarben von PG3D verwenden, können problemlos weiter im alten Format verwendet oder auch in dieses verlustfrei gewandelt werden, falls sie nur als OG-PNGs vorliegen. Für OG-PNGs muss ich das Umwandeln aber noch in mein Tool einbauen. Grafiken die andere oder mehr Farben als das alte Format verwenden, müssen momentan im neuen SHP-Format gespeichert sein.
3. Evtl. baue ich später noch ein, dass die OG-PNGs direkt benutzt werden können, allerdings ist deren Verarbeitung noch etwas rechenintensiver, weil hierbei größere Bilder (da immer alle Bilder in einem Großen Bild stecken) geladen werden und ich natürlich Quellcode einfügen muss, der den richtigen Teil des Bildes auswählt bevor ich das Bild so weiterverarbeiten kann wie bei meinem Format gleich nach dem Laden. Das heißt nicht, dass die OG-PNGs eine schlechte Lösung sind. Sie passen dazu wie OG damit umgeht aber in PG3D muss ich mich an bestimmte vorgaben durch das vorhandene Spiel richten und dazu passen die OG-PNGs nicht ganz so gut. Mann müsste also sehen ob der zusätzliche Nachteil des Ladens dieser Bilder einen merkbaren Unterschied macht.
4. Ich werde am Wochenende zwei Testversionen zusammenstellen. Einmal komplett im neuen Format und einmal eine Mischung bei der nur die Einheiten und zu den Einheiten gehörende Bilder, wie Explosionen, im neuen Format sind. Die stelle ich dir dann zur Verfügung. Dann kannst du den Unterschied sehen und mir sagen ob die Kombination aus neuem und altem Format bei dir auch so flüssig läuft wie bei mir.
5. Es kann auch gut sein das ich die Geschwindigkeit noch etwas steigern kann, aber momentan sieht es so aus als wenn das Problem wirklich rein am Laden der PNGs liegt und dieser Teil ist nicht von mir programmiert, sondern wird über die bereits optimierte Bibliothek libpng erledigt.
Hallo. Ich habe mich jetzt schon eine Weile nicht gemeldet, weil es nicht viel Vorzeigbares gibt. Deshalb hier nur ein ganz kurzer Zwischenbericht.
Eine gute Nachricht gibt es. Rayy hat auf seinem alten Rechner meine Testversionen der Panzer2.dat mit dem gleichen Ergebnis wie ich auf meinem hoch modernen Rechner getestet. D.h., wenn alle Grafiken ins PNG-Format gewandelt werden, hakt das Spiel bei einigen Anzeigen, wie dem Einkaufsbildschirm, wenn man aber nur die Einheiten in das PNG-Format wandelt und alle anderen Bilder im alten Format belässt, merkt man keinen Unterschied zum unveränderten Spiel.
Allerdings ist bei uns die generelle Frage aufgekommen, ob PNG das richtige Format für PG3D ist. Es wäre nützlich, wenn man direkt die PNG-Dateien nutzen könnte, die von OG genutzt werden. Unser Test zeigt aber, dass wir uns schon mit dem Format, das ich möglichst kompatibel zu PG3D gestaltet habe, bei PNG-Bildern an eine Performancegrenze stoßen. Wenn ich die OG PNG-Bilder direkt, so wie sie sind im Spiel unterstützen würde, müsste ich jedes Bild im Spiel vor jeder Verwendung erst einmal relativ aufwändig lesen/umwandeln. Von daher fällt der Vorteil ohne Konvertierung OG-Bilder zu nutzen erst einmal weg und dann stellt sich eben die Frage "Muss es unbedingt PNG sein?". PNG-Bilder sind hoch komprimiert, was eine möglichst kleine Dateigröße ergibt, aber dazu führt, dass ich nicht einfach ein einzelnes Pixel des Bildes auslesen kann. Das auslesen von einzelnen Pixeln ist aber für PG3D ganz wichtig. Auf weitere Details gehe ich hier nicht ein, weil der Text sonst zu lang werden würde. Sollte es euch interessieren, fragt bitte nach.
In den letzten Tagen habe ich mir viele Gedanken gemacht, wie ein Bildformat aussehen müsste, damit es möglichst gut zu PG3D passt. Dazu habe ich mir verschiedenen Bildformate angeschaut und damit herumexperimentiert.
Hier meine Ergebnisse (PG2PNG ist mein experimentelles PNG-SHP-Format):
Bildformat Vorteil Nachteil GIF lossless max 256 Farben; Komprimierung nicht gut lesbar BMP (RAW) lossless; sehr gut lesbar; 32-Bit Farben unkomprimierte Daten (maximale Dateigröße) BMP (RLE) lossless; gut lesbar schwache Komprimierung; max 8-Bit Farben PCX lossless; gut lesbar schwache Komprimierung; max 8-Bit Farben TGA lossless; gut lesbar; 32-Bit Farben schwache Komprimierung PG2 lossless; gut lesbar; mittlere Komprimierung feste Vorgabe von 256 Farben PG2PNG lossless; starke Komprimierung; 32-Bit Farben Komprimierung nicht gut lesbar JPEG starke Komprimierung; 32-Bit Farben "lossy" Komprimierung; Komprimierung nicht gut lesbar
Wie man sieht, hat alles seine vor und Nachteile.
Was sich aus meiner Sicht für 99% aller PG3D und OG Bilder sehr gut machen würde, ist eine abwärtskompatible Erweiterung der normalen PG2 Bilder. Dort gibt es im Header jedes Bildes ein ungenutztes Feld, das normalerweise den Wert 0 hat. Wenn ich hier denn Offset für eine alternative Farbtabelle eintrage, kann man mit dem ansonsten unveränderten Bilddaten schon ein Bild mit beliebigen 256 Farben darstellen, anstelle der festen 256 Farben von PG3D. Wenn das Feld den Wert 0 hat wird, die PG2-Farbtabelle verwendet, wenn nicht, kommt die Bildeigene-Farbtabelle zum Einsatz. Wir hätten also schon mal ganz einfach ein echtes 8-Bit Bild. Luis PG2 Suite würde diese Bilder zwar immer nur in den PG2-Standartfarben darstellen, aber sie würden zumindest angezeigt.
Wenn man mehr als 256 Farben in einem Bild darstellen will, würde kann das Format nicht mehr von Luis PG2 Suite dargestellt werden, weil ich in diesem Fall die Bilddaten selbst anders kodieren müsste. Hier habe ich, neben dem schon vorhandenen PG2PNG-Format, einige Ideen die auf einer Mischung der Formate PG2, BMP (RLE), PCX und TGA basieren. Diese müsste ich aber noch untersuchen und schauen, welche sich davon als nutzbar erweisen.
Achso, in der kürze des letzten Beitrags habe ich vergessen zu sagen, dass ich jetzt ganz gern als erstes das bestehende PG2/PG3D-Bildformat auf "echte" 8-Bit Unterstützung erweitern würde. Ich sollte mich nicht immer so kurz fassen , dann vergesse ich nicht immer die wichtigsten Punkte. Jedenfalls sollte das sehr schnell gehen, weil ich das ursprüngliche Format mittlerweile inklusive der Kompression schon sehr gut lesen und vor allem wieder schreiben kann und die Erweiterung, wie schon beschrieben, minimal ist.
@Rayy Deine paar Bilder, die damit evtl. nicht richtig dargestellt werden können schaue ich mir noch einmal genauer an und gebe dir dann Rückmeldung.
Zitat von James Font im Beitrag #29Achso, ... @Rayy Deine paar Bilder, die damit evtl. nicht richtig dargestellt werden können schaue ich mir noch einmal genauer an und gebe dir dann Rückmeldung. ...
Ähm ja, also vielleicht hätte ich erst noch einmal prüfen sollen bevor ich das schreibe. Natürlich sind die GB- und BN-Icons von der Erweiterung problemlos darstellbar. Da brauch ich nichts großartig genauer anschauen. Es handelt sich um 4-8 Bit Bilder.
Jagutichsachma: Ich habe wieder nur die Hälfte - und davon ca. 50% - verstanden. Mit 'fundierten Vorschlägen' kann ich also leider nicht dienen.
Aber mein Bauch bleibt dabei: möglichst unkompliziert! D.h.: a) 8 Bit reicht, wenn eine alternative Palette für korrekte Darstellung der gängigen OG-Icons vorhanden ist, b) Wenn die Suite was nicht darstellen kann, muss man für die E-File-Bastelei eben im OG-Repo gucken; unschöner wäre es allerdings beim Szenario-Editing auf der Map. c) Komprimierungsfähigkeit ist nicht sekundär, sondern ungefähr quartär.
„Geist und Grips sind unsere einzigen Rohstoffe, und Bayern ist ein rohstoffarmes Land.“ - Edmund Stoiber
Zitat von Matze im Beitrag #31hammer Arbeit -> in deiner Liste ist BMP (RAW) wohl am besten - aber willst du echt alle png´s von OG in BMP umwandeln?
Nein will ich nicht. Umwandlung, ja aber nicht in ein reines BMP. Für die Performance wäre ein unkomprimiertes BMP am besten, aber das bestehende Format reicht aus Sicht der Performance auch aus. Ich bevorzuge erstmal eine Erweiterung des bestehenden PG2-Format um eine eigene Farbpallette. Wie schon geschrieben deckt das 99% aller bestehenden Icons ab und die verbleibenden lassen sich normaler Weise ohne sichtbaren unterschied auf 8-Bit bringen. Außerdem lässt sich meine Implementierung für das PG2-Format auch darauf anwenden, ohne dass ich eine Große Änderung vornehmen muss. Ich habe also kaum Arbeit damit.
Später werde ich dann sehen, wie man effektiv noch ein paar Farben mehr einbringen kann ohne dass die Performance, wie bei der PNG-Lösung sichtbar leidet.
aha - für neue Icons müsste man sie dann an dich senden, damit du sie einbaust - oder holst du sie auf der OpenIcon.dat regelmäßig ab -> nur mal so gefragt, wie das im Betrieb dann laufen soll.
Immer wenn du lügst wird Jesus Blut weinen (Todd Flanders zu seinem Vater)
Zitat von Rayydar im Beitrag #32Jagutichsachma: Ich habe wieder nur die Hälfte - und davon ca. 50% - verstanden. Mit 'fundierten Vorschlägen' kann ich also leider nicht dienen.
Aber mein Bauch bleibt dabei: möglichst unkompliziert! D.h.: a) 8 Bit reicht, wenn eine alternative Palette für korrekte Darstellung der gängigen OG-Icons vorhanden ist, b) Wenn die Suite was nicht darstellen kann, muss man für die E-File-Bastelei eben im OG-Repo gucken; unschöner wäre es allerdings beim Szenario-Editing auf der Map. c) Komprimierungsfähigkeit ist nicht sekundär, sondern ungefähr quartär.
Du hast doch alles soweit verstanden und diesmal hast du auch das gleiche Ziel wie ich :). Nur eine Frage habe ich. Das "Szenario-Editing", findet das mit dem Szenario-Editor im Spiel statt oder wird dafür ein anderes Tool verwendet? Ich frage, weil der Szenario-Editor im Spiel natürlich alle Bilder korrekt darstellen wird, ein externes Tool hätte aber natürlich die gleichen Probleme wie die PG2 Suite. Alle Bilder, die nur die PG2-Farben verwenden, werden wie immer richtig dargestellt, weil hier das alte PG2-Format und die neue Erweiterung identisch sind aber alle anderen Farben würden in der PG2 Suite durch eine Farbe aus der PG2-Farbpalette dargestellt.
Zitat von Matze im Beitrag #34aha - für neue Icons müsste man sie dann an dich senden, damit du sie einbaust - oder holst du sie auf der OpenIcon.dat regelmäßig ab -> nur mal so gefragt, wie das im Betrieb dann laufen soll.
So eine schnelle Antwort.
Also ich programmiere parallel ein Tool, was die Umwandlung übernimmt. Für den Anfang werde ich für Rayy alle Grafiken aus der OpenIcon.dat konvertieren. Sobald, das Tool soweit fertig ist, dass es auch von anderen genutzt werden kann werde ich es zur Verfügung stellen. Es sollte dann OG zu PG2 verlustfrei (sofern nicht mehr als 256 Farben verwendet werden) wandeln können und umgekehrt.
Zitat von James Font im Beitrag #35Nur eine Frage habe ich. Das "Szenario-Editing", findet das mit dem Szenario-Editor im Spiel statt oder wird dafür ein anderes Tool verwendet?
Ebenfalls die Suite - wie für eigentlich alles. Den Editor im Spiel benutzt seit Äonen keiner mehr.
„Geist und Grips sind unsere einzigen Rohstoffe, und Bayern ist ein rohstoffarmes Land.“ - Edmund Stoiber
Zitat von James Font im Beitrag #35Nur eine Frage habe ich. Das "Szenario-Editing", findet das mit dem Szenario-Editor im Spiel statt oder wird dafür ein anderes Tool verwendet?
Ebenfalls die Suite - wie für eigentlich alles. Den Editor im Spiel benutzt seit Äonen keiner mehr.
Hmm, dann bliebe natürlich als einfachste Lösung die neue Panzer2.dat ein zweites Mal als OG-kompatible Panzer2.dat abzuspeichern, wie auch immer die Datei dann genau heißt. Die zweite Panzer2.dat wäre dann für die PG2 Suite ganz normal lesbar und darstellbar. Das sollte mein Tool hinbekommen.
Zitat von Matze im Beitrag #34aha - für neue Icons müsste man sie dann an dich senden, damit du sie einbaust - oder holst du sie auf der OpenIcon.dat regelmäßig ab -> nur mal so gefragt, wie das im Betrieb dann laufen soll.
So eine schnelle Antwort.
Also ich programmiere parallel ein Tool, was die Umwandlung übernimmt. Für den Anfang werde ich für Rayy alle Grafiken aus der OpenIcon.dat konvertieren. Sobald, das Tool soweit fertig ist, dass es auch von anderen genutzt werden kann werde ich es zur Verfügung stellen. Es sollte dann OG zu PG2 verlustfrei (sofern nicht mehr als 256 Farben verwendet werden) wandeln können und umgekehrt.
Gruß James
prima - das mit den Farben kann ein Problem sein - aber nur bei den neuesten Icons und man muss ja auch schaun - was dein Programm dann bei mehr Farben darstellt. Bzw. wenn er eine Farbe nicht in seiner Palette hat - was es damit macht.
Immer wenn du lügst wird Jesus Blut weinen (Todd Flanders zu seinem Vater)
Zitat von James Font im Beitrag #38dann bliebe natürlich als einfachste Lösung die neue Panzer2.dat ein zweites Mal als OG-kompatible Panzer2.dat abzuspeichern, wie auch immer die Datei dann genau heißt. Die zweite Panzer2.dat wäre dann für die PG2 Suite ganz normal lesbar und darstellbar. Das sollte mein Tool hinbekommen.
Das ist erbaulich. Allerdings solte die "zweite Panzer2.dat" einfach weiter Panzer2.dat heißen, weil die Suite ja genau dieses File öffnen will. Die Spieler hingegen sollten sich schon mal an den hübschen Namen Panzer3.dat gewöhnen; es heißt ja auch PG3DE..
Nostalgie ist auch nicht mehr das, was sie mal war.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Offline
.
