IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

[Lukas]

Und was schlägst du als Alternative vor?

[Whiz-zarD]

Eine Mischung aus beidem. Eine Suche über einen eindeutigen Index, der nach einen übersetzten Text sucht und wenn er keinen findet, einen geeigneten Default-Wert zurückliefert.
z.B.
Index: ERROR
Default-Wert: "Sorry, but there is an error"
deutsche Übersetzung: "Tut uns leid. Es ist ein Fehler aufgetreten."

mit gettext("ERROR", "de_DE"); würde er nun die deutsche Übersetzung zurückgeben.
Wenn man aber nun gettext("ERROR", "fr_FR"); ausführt, würde er nun den default-Wert zurückgeben, da es keine französische Übersetzung gibt. Auf diese weise lässt sich der Default-Wert ändern, ohne dass die Anwendung angepasst werden muss. Diese Variante ist zwar auch fehlerträchtig, da sich auch die Indizes ändern können, aber diese ändern sich nun mal seltener als ganze Texte und bis jetzt habe ich in jeder Firma, wo ich bis jetzt als Softwareentwickler tätig war, diese Lösung gesehen.

[Xardas der Dunkle]

Wir nutzen auf der Arbeit SilverStripe das nutzt genau diese Mischung:

Code:

_t('ClassName.ERROR', 'There has been an error');

über ein Script werden alle Dateien automatisch geparsed und die Zuordnung der Indizes zu ihren englischsprachigen default Werten weggeschrieben.
Somit hat man immer Index und den Standard Text zusammen. (Allerdings sollte man sich auf den default-text im Quellcode nicht verlassen, da er ja über die Sprachdatei überschrieben werden kann.)

[niR-kun]

Für Sound nutzen wir beim Cuina Project Paulscode Soundsystem.
Java und Sound ist immer so eine Sache.

Ich fände es schön, auch wenn man ein Konkurrenz-Projekt baut, dass man zumindest soweit zusammen arbeitet, das Maps und Spieldaten einfach von Engine X auf Engine Y portiert werden können. Ich schlage da vor zusammen einen minimalen projektunabhängigen offenen Standard zu entwickeln (und gegebenenfalls auch zu erweitern). Wie und ob man nun den Standard implementiert ist nun dem/den Entwickler/n offen gestellt.

[R.D.]

Mein MapSystem ist komplett offen Es funktioniert weil ich raw bytes schreibe und lese und das ganze dynamische laden kann. Übrigens baue ich keinen Maker oder so. Nur eine Engine. Und diese Engine werde ich auch nicht weiter groß pushen Wer will kann sich da nehmen was er will (Ich meine, ich hab das nicht umsonst mit BSD als Lizenz gemacht). Also sie das nicht als Konkurrenz.

@Sound
Ah ja, ich würde es auch nutzen wenn es nur um Desktop ginge. Aber so einfach ist die Sache leider nicht. Allein Web ist Sound irre kacka. libgdx nutzt ein eigenes system zum abspielen von Sounds und Musik das wie auch alles andere in der Engine auf den Backends beruht. Es funktioniert durch Interfaces aber es gibt eben Sachen die nicht möglich sind. Es gibt z.B. keine setPosition method für Musik (Obwohl es für Desktop und Android nicht schwer ist zu implementieren). Diese Drawbacks muss man halt beachten.
Java und Sound ist imho keine große Sache. Wenn ich schon OpenGL und Java nutze (was auch libgdx tut), kann ich auch OpenAL nutzen (Pauscode System hat ja eine solche Implementation für LWJGL). Ich finde eher das viele Engine extrem lacken was Sound angeht. Es gibt nie Möglichkeiten Sound dynamisch zu behandeln wie in Zelda oder SSX. Das muss man selbst erledigen (auch hier bietet libgdx eine Möglichkeit über ein AudioDevice, allerdings müssen dann alle Daten selbst geladen und erstellt werden, sprich man muss Ahnung in Sachen low-level haben). Viele Engines haben auch Probleme mit mehr als einem Stream (Danke JOrbis).

Edit:
Übrigens kann man mit der Engine bereits was machen. Ich hab mal meinen Partikeltest auf die Schnelle in die neue Engine gebracht, Ergebnis:

[niR-kun]

Mein MapSystem ist komplett offen Es funktioniert weil ich raw bytes schreibe und lese und das ganze dynamische laden kann.

...

Offen ist zwar gut, aber für mich sind deine Map-Dateien dennoch Bit-Müll, weil ich nichts mit anfangen kann.
Ich kann deine Map-Dateien nicht einfach Notepad++ öffnen und bearbeiten, weil sie nicht menschenlesbar sind.

Worauf ist hinaus will ist eine öffentliche Minimal-Spezifikation für rpg_rt-ähnliche Engines, angefangen wie das Map-Format aufgebaut ist.
Es spart erstens viel Zeit sich ein eigenes Format auszudenken und zweitens wer will schon für sagen wir mal 10 Engines mit je unterschiedlichem Map-Format 10 Konvertierungsalgorithmen in das eigene Map-Format schreiben.

[R.D.]

Was sparst du dir denn für Zeit ein Format auszudenken? So wie ich das sehe tun das viele Entwickler ohne groß drüber nachzudenken. Sie schreiben einfach die Daten sie brauchen und mehr tue ich in dem "Map-Format" ja auch nicht. Das es für dich nach müll aussieht liegt wahrscheinlich daran das es mittels ZLib komprimiert wurde. Ich will halt kein XML oder Json dafür haben. Das ist mir zu bloated und naja wie gesagt, schau in die MapIO Klasse, da kannst du sehen wie man es lesen kann. Es sind nur ein paar primitives und Strings die ich schreibe. Keine Magie
Das Ganze ist auch eher ein Feature in der Engine. Ich werde es sehr wahrscheinlich entfernen und als Extension wieder ermöglichen. Ich will eben nur aktuell alles in einem Projekt haben

Es ist auch meines Wissens nach nur in meiner Engine so. Die meisten nutzen halt Tiled. Aber ich mag Tiled nicht. Total nutzlos das Tool wenn man mehr als "darstellen" will. Aktuell ist das ja nicht in meinem Map-Format drin aber es wird noch ein Event-System eingefügt das dem von Rpg Maker sehr ähnlich ist (Die Idee ist allein von Lachsen).

[Whiz-zarD]

Sie schreiben einfach die Daten sie brauchen

...

Und das ist oftmals das Problem in größeren Projekten.
Man denkt nicht nach. Man tut einfach irgendwas.

In so einer Situation befinde ich mich auch grad auf der Arbeit. Für ein und das selbe Problem gibt es tausend unterschiedliche Implementierungen und ich darf ein Feature bauen, womit alle Implementierungen zurechtkommen können. Am liebsten würde ich sagen: "Gebt mir ein halbes Jahr Zeit und ich mache alles neu!", nur welche Firma investiert 180 PT für ein einzelnes Feature, welches die meisten Kunden eh nicht benutzen, bzw welcher Kunde würde 180 PT für ein Feature bezahlen wollen?

[Jesus_666]

@Whiz: PT? Das einzige, wozu ich das auflösen könnte, wären "Punkte" wie in "Prozentpunkte", aber ich bezwifle, daß deine Firma Verträge macht, in denen sie 180% ihres Einkommens weggeben...


Insgesamt aber ja. "Ich schreibe mal Kram in eine Datei, ohne drüber nachzudenken" funktioniert so lange, wie man davon ausgeht, daß niemals jemand mit einem kompatibel sein will.

Beispiel: Es gibt für DSA3 und DSA4 einen Charaktereditor namens "DSAWiege". Für DSA3 war das Ding echt heißer Scheiß; für DSA4 wurde es von einem OSS-Projekt überholt. Wir haben zu DSA3-Zeiten ewig den Entwickler angehauen, daß er uns doch mal die Sourcen gibt; unter Anderem deshalb, weil sämtliche Datenformate aus "ich schreibe einfach Strings in einer Textdatei und die Reihenfolge bestimmt, was was ist" bestanden. Richtig geil, wenn man den Kram verwerten möchte, weil das ewig langes Reverse Engineering bedeutet.
Die Sourcen hätten da auch nicht furchtbar viel Zeitersparnis gebracht.

Beispiel: Magic Workstation. Ein Programm, mit dem man online MtG spielen kann. Ganz nett und hat in der Regel recht aktuelle Kartenlisten komplett mit eingebackenen Errata. Sehr geil, wenn man eine Kartendatenbank bauen möchte... Bis auf ein Problem: Das Datenformat für die Kartenlisten ist "ich nehme dieses Delphi-Objekt und schreibe es auf die Festplatte". Damit sind die Listen exakt dann lesbar, wenn man Delphi benutzt und alle verwendeten Klassen hat. Magic Workstation ist nicht OSS.
Ich habe meine Karten exportiert gekriegt, aber es involvierte eine recht zerbrechliche Toolchain aus mehreren Konvertierungsprogrammen.

Wenn du ein Datenformat entwickelst, mach' es selbsterklärend (denke "XML") und/oder dokumentiere es vernünftig. Es sei denn, Inkompatibilität mit dem Rest der Welt ist ein Designziel.

[Whiz-zarD]

@Whiz: PT? Das einzige, wozu ich das auflösen könnte, wären "Punkte" wie in "Prozentpunkte", aber ich bezwifle, daß deine Firma Verträge macht, in denen sie 180% ihres Einkommens weggeben...

...

PT = Persontage

[NPC Fighter]

In so einer Situation befinde ich mich auch grad auf der Arbeit. Für ein und das selbe Problem gibt es tausend unterschiedliche Implementierungen und ich darf ein Feature bauen, womit alle Implementierungen zurechtkommen können. Am liebsten würde ich sagen: "Gebt mir ein halbes Jahr Zeit und ich mache alles neu!", nur welche Firma investiert 180 PT für ein einzelnes Feature, welches die meisten Kunden eh nicht benutzen, bzw welcher Kunde würde 180 PT für ein Feature bezahlen wollen?

...

Du bist nicht allein! (=

Es gibt nichts ätzenderes als historisch gewachsene Projekte, an die zig Entwickler unzählige Änderungen rangeflanscht haben.
Die Auswirkung von tieferen Modifikationen ist quasi "untestbar", weil man mit an Sicherheit grenzender Wahrscheinlichkeit doch einen der hundert Sonderfälle vergisst und spätestens beim Going-Live knallts dann an allen Ecken und Enden.
Weil das ein verdammt teurer Spaß würde, bleibt einem also nichts übrig, als seinen eigenen Kram auch irgendwie ranzuflanschen.

@ R.D.: Gute Planung zaht sich wirklich aus! (:

[R.D.]

@Whiz
Ich meinte ehr direkt Spiele usw und weniger Engine aber egal, wie gesagt sehe ich das eh eher als Extension Man sollte dazu vllt auch Wissen das die Engine mehr oder weniger aus einem Spiel entsteht. ich enkopple nur Sachen die ich eh wiederverwenden werde. Wenn ich damit Leuten noch helfen kann, schneller ihre Ideen auf den Bildschirm zu kommen mach es umso mehr Spaß.

@NPC-Fighter
Was genau meinst du damit?

[Kyuu]

Ich sehe nichts Verwerfliches in einem Binärformat, d.h. solange es gut durchdacht und dukumentiert ist. Erweiterbarkeit lässt sich auch in Binärformaten realisieren, z.B. ähnlich wie es RIFF macht. XML finde ich persönlich zu aufgebläht und würde JSON vorziehen, falls Menschenlesbarkeit erforderlich ist und Binärdaten nicht gespeichert werden sollen.

[MagicMagor]

Hallo,
ich habe da eine kleine C++ Frage.
Mein Compiler weigert sich den Typ int64_t in time_t ohne expliziten Cast umzuwandeln.

Code:

#include <time.h>
#include <stdint.h>

int main() {
int64_t test = 1234567890;
tm* now = localtime(&test);
return 0;
}

Dieser Code ergibt als Ausgabe:

Code:

test.cpp: In function ‘int main()’:
test.cpp:7: error: invalid conversion from ‘int64_t*’ to ‘const time_t*’
test.cpp:7: error:   initializing argument 1 of ‘tm* localtime(const time_t*)’

Meine Frage ist, woran liegt das? An einer zu alten Compiler-Version? (Bei mir läuft 4.2.1) Und nein, einfach explizit zu casten ist keine brauchbare Lösung für mich.

[DFYX]

Da wird kein int64_t sondern ein int64_t*, also ein Pointer konvertiert. Pointerkonvertierung macht C++ normalerweise NIE automatisch.