Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Gute Tipps und Ideen, die ich umsetzen werde. Wie gesagt, heute komme ich nicht mehr dazu, aber der Lauf der Woche wird einiges davon realisieren. Spracheinstellungen habe ich schon vorgesehen, nur noch nicht umschaltbar gemacht 
Danke jedenfalls für die Blumen. Motiviert ungemein
Mal ne andere Sache. Das Tool ist derzeit dafür ausgelegt zu lange Zeilen im Dump kenntlich zu machen. Ich stelle mir gerade die Frage ob man auch zu kurze Zeilen anzeigen lassen könnte.
(Ich vermute das folgender Vorschlag zu kompliziert zum umsetzen ist. Trotzdem wollte ich es mal in den Raum stellen. Wenns nicht klappt, vergesst es einfach 
)
Beim überprüfen des Textdumps achte ich nicht nur einfach darauf das die Zeilen nicht zu lang sind (was zu Grafikfehler führen würde oder den Text nicht ganz anzeigen lässt), sondern auch ob die Zeilen nicht zu kurz sind (was einfach nur ein optischer Aspekt ist). Ich versuche nicht generell den Text möglichst effektiv zusammen zu stauchen, ein frühzeitiger Zeilenumbruch bei Satzende ist ok. Aber ein frühzeitiger Zeilenumbruch, obwohl noch etwas in die Zeile gepasst hätte, schaut eher unschön aus (Ja, da bin ich sehr penibel. Bei mir muss so etwas nun mal perfekt sein).
Hier mal ein Beispiel:
Linkes Bild ist so aktuell in meiner Rom. Das Wort Piratenversteck in der zweiten Zeile hätte noch locker mit in die erste Zeile gepasst. Dadurch schaut der Text wesentlich geordneter aus. Auch würde so die fünfte Zeile "sein muss!" noch mit in die erste Massagebox passen.
Nach genau solchen Stellen wie in diesem Beispiel suche ich derzeit noch in meinem Textdump um den Text zu optimieren.
(Wie solch eine Textanordnung zu stande kommt? Beim übersetzen im Texteditor konnte ich die Zeilenlänge nur nach eigenem Ermessen abschätzen, weshalb einige Zeilen zu lang, andere aber auch zu kurz sind)
Das ganze lässt sich auch ohne dem Tool erledigen, aber ich habe überlegt ob man dafür noch eine Funktion ins Tool mit einbauen könnte. So einfach ist das sicher nicht, denn man muss unterscheiden zwischen gewollten Zeilenumbrüche (Satzende durch . ! ?), oder Stellen an den es aus Platzgründen nicht anders geht (in meinem Beispiel: wenn "Piratenversteck" zulang für die erste Zeile gewesen währe und so die Maximale Pixelbreite überschritten wurde). Dann darf natürlich auch nur jeder Pointer für sich behandelt werden und nicht Pointer übergreifend.
Mir fällt da keine Möglichkeit ein das ganze unkompliziert um zu setzen, wahrscheinlich müsste man dem Tool dafür sehr viel "beibringen" was dabei zu beachten währe. Trotzdem wollte ich die Thematik einfach mal in den Raum stellen. Könnt ihr euch alle mal ein paar Gedanken zu machen. 
Dann ist da noch ein kleiner Denkfehler aufgetaucht bei der Kombination von Leerzeichen und "Pixel zwischen Buchstaben". Letzderes bedeutet ja nur das zu jedem Zeichen (in meinem Beispiel) ein Pixel dazu gerechnet wird. Achtung, jetzt wirds kompliziert: Zwischen zwei Wörter (also das Leerzeichen) hatte ich 5 Pixel. Davon musste ich aber noch den einen Pixel abziehen der vom letzdem Buchstaben des ersten Wort dazu kommt und einen Pixel der vom Leerzeichen selber dazu gerechnet wird. Somit ist das Leerzeichen nicht 5 Pixel sondern nur 3 Pixel breit.
Weswegen mein Vorschlag war, eine Diagonale reinzupixeln. Dann sieht man sofort, wo welches Textzeichen aufhört und das ander anfängt ...
Beim überprüfen des Textdumps achte ich nicht nur einfach darauf das die Zeilen nicht zu lang sind (was zu Grafikfehler führen würde oder den Text nicht ganz anzeigen lässt), sondern auch ob die Zeilen nicht zu kurz sind (was einfach nur ein optischer Aspekt ist). Ich versuche nicht generell den Text möglichst effektiv zusammen zu stauchen, ein frühzeitiger Zeilenumbruch bei Satzende ist ok. Aber ein frühzeitiger Zeilenumbruch, obwohl noch etwas in die Zeile gepasst hätte, schaut eher unschön aus (Ja, da bin ich sehr penibel. Bei mir muss so etwas nun mal perfekt sein).
Durchaus berechtigt. - Bei langen Wörtern könnte man dann auch "von Hand" abtrennen. - Müsste auch programmiertechnich leicht gehen. Braucht nur die Angabe, ab wenn eine Zeile "zu kurz" ist.
Weswegen mein Vorschlag war, eine Diagonale reinzupixeln. Dann sieht man sofort, wo welches Textzeichen aufhört und das ander anfängt ...
Eine Diagonale geht von li. oben nach re. unten (oder von li.unten nach re. oben).
Geiles Tool was mich am meisten begeistert das es sich universell ansiedelt 
Super Arbeit Bredator so ein Tool hat echt gefehlt ich würde auch vorschlagen das man ein Text fenster hinter den Dialogen Pixelt was man vorher angegeben hat dazzu bräuchte man aber warscheinlich einen variablen Font ich denke das ist denke ich aber leider nicht möglich naja mal sehen wie man das problem lösst ....
fetten DANK schonmal von mir Bredator
Zitat- Die Ignorliste (>H<xy, [>Pointer xy<]) die im Moment aktiev ist und speziell für mein Dump (bzw. Dump mit SNESedit) angepasst ist, in einem Setting-Menüpunkt ein/ausschaltbar machen (damit es nicht zu Verwirrung kommt wenn ein Dump anders ausschaut)
Kommentarzeichen wie '#' und '//' werden in SnesEdit-Dumps auch verwendet ...
... Aber jetzt verstehe ich immer noch nicht warum eine Diagonale? Die Höhe interessiert hierbei doch gar nicht. ...
Nein, die Höhe interessiert mich auch nicht, aber bei einer Diagonale kann man genau sehen, ob das Pixel noch zum alten Buchstaben gehört, oder schon zum neuen.
... Zum anderem Thema mit den zu langen Wörtern: Meinst du mit "von Hand abtrennen"? Falls du Trennzeichen meinst, da bin ich nicht so der Fan von. Passt ein Wort nicht in eine Zeile, packe ich es lieber in die nächste anstatt es zu zerreißen. Ist natürlich auch Geschmackssache. ...
Ja, Wörter trennen mache ich auch selten - ist Geschmackssache. Habe aber jetzt so Wort-Ungetüme, die haben von sich aus - wegen der Lesbarkeit - schon einen Bindestrich, wie z.B. "Magie-Akademie" (und noch viel längere, die mir aber gerade nicht einfallen.). - Da würde ich den Zeilenumbruch im Wort bestimmt nehmen - vor allem, wenn ich ihn brauche. - Will sagen, wenn ich damit den Ganzen Satz auf einmal in's Textfenster bekomme, ohne den Satz neu zu formulieren (Die Alternative wäre ja, mitten im Satz auf die Eingabe des Benutzers zu warten, und dann das Gesamte Textfenster zu löschen, und den 2. Teil des Satzes anzuzeigen.).
... Zum Tool: Einfach nur zu definieren ab wenn eine Zeile "zu kurz" ist, reicht nicht unbedingt aus. Wie oben geschrieben bei Zeilenumbrüche die absichtlich frühzeitig gemacht wurden weil z.B. der Satz abgeschlossen ist. Oder Dialoge die einfach nur eine, kurze Zeile haben. ...
Ist schon richtig, und gerade die 2. Situation kommt so oft vor, dass es nervig wird, Jeden Satz angezeigt zu bekommen. Trotzdem - immer noch die besste Alternative (glaube ich) und besser als nix. Man schaut sich halt alle kürzeren Stücke an, sagt "O.K., das passt schon so." und weiß, dass so ziemlich alles O.K. ist ...
Evtl. hab ich aber eine Idee wie man dieses Problem relativ einfach (aus Sicht eines Leien) lösen könnte.
So, hier mal meine Idee. Ich dachte mir das links wo die Pixelanzahlen jeder Zeile stehen, zusätzlich noch die restliche Pixelanzahl angezeigt wird, die noch in die Zeile passen würde, also vom Maximalwert errechnet (klar, könnte man auch schnell im Kopf rechnen, aber man(n) ist ja bequem 
). In einem Grauton, damit es sich besser vom ersten Wert abhebt.
Und dann eine Möglichkeit mit dem Curser einzelne Teile des Textes zu markieren und sich die Pixelanzahl des markierten Text anzeigen zu lassen. Ob es in dem Feld nun per Echtzeit errechnet wird oder per Button-Klick ist ja egal.
So könnte man einfach schauen ob ein verschieben des Textes bei zu kurzen Zeilen nicht die maximale Pixelanzahl pro Zeile überschreiten würde. Man muss nur bedenken das beim verschieben eines Wortes noch ein zusätzliches Leerzeichen dabei gerechnet werden muss.
Ich denke das ist eine einfach umsetzbare Lösung für das oben beschriebene Problem. Bredator was meinst du?
Ist sehr einfach umsetzbar, steht auf der Liste, kommt auch Danke für den Tipp.
Nachdem ich nochmal drüber nachgedacht habe:
Das mit den Hex-Werten wäre super - wenn SinaP das in sein Dialog-Edit einbauen könnte.
Da du schon mit einem Text-Dump arbeitest liegen diese "Sonderzeichen" ja in einer völlig anderen Form vor.
Keine Ahnung, ob sich der Aufwand lohnt ...
Hi nochmal,
das Tool ist natürlich nicht vergessen, auch wenn ich die Woche jetzt praktisch nichts dran machen konnte. Im Laufe der nächsten Stunden stelle ich Teile eines anderen Projekts fertig und hab das dann erst mal ein paar Tage vom Acker, was Zeit für das Tool freiräumt. Hab mir die bisherigen Posts nochmal durchgeschaut und eine Liste angefertigt, was ich fürs Erste noch einbauen möchte.
Gast-110: Stimmt, da das Tool mit einem Dump arbeitet ist das mit Hex-Werten nicht so einfach machbar. Hier könnten wir uns aber nochmal drüber unterhalten, wie man das Problem entweder umschiffen könnte bzw. ob das nicht wirklich im Dialog-Edit besser aufgehoben wäre. Der Table-Editor bietet bisher lediglich die Möglichkeit, eigene Zeichen unten anzufügen, die dann aber auch im gleichen File-Encoding so im Dump vorhanden sein müssen. Wie gesagt, würde ich mal noch etwas hinten anstellen, aber trotzdem nicht vergessen.
Ja, es ist im Dialog-Edit besser aufgehoben. Da die Hexwerte im Dump durch ihre Entsprechung ersetzt werden, müsste dein Tool die jeweilige Entsprechung exakt wiedererkennen. Die Fehlerquelle liegt hier auch beim Endanwender, der ja als Entsprechung jede beliebige Schriftzeichen-Kombination vergeben kann. Und die Entsprechung muss ja zwingend kurz sein, sonst braucht man wieder eine TBL für dein Tool und eine TBL für SnesEdit. Es ist aber meist auch ein zu vernachlässigen geringer Prozentanteil von Texten.
So, da bin ich wieder. Habe jetzt mal wieder etwas Zeit gefunden zum basteln. Exceptionhandling ist nach wie vor dürftig, wird mit einer kommenden Version behoben.
Changelog:
- Selektierte Texte werden nun dynamisch gleich mit ihrer Länge angezeigt
- Zeilenlängen werden in einem eigenen Bereich angezeigt
- Kritische Textlängen können nun angegeben werden. Texte dieser Länge, die gleichzeitig aber kleiner als die maximale Länge sind, werden Gelb/Gold angezeigt. Farbe gefällt mir aber noch nicht. Wird später selbst einstellbar gemacht.
Anmerkung:
Am Ende der Textzeilen werden die Leerzeichen entfernt. Allerdings wird beim Markieren eine Leerstelle sichtbar. Diese wird aber nicht gezählt (kann mit dem Selektieren selbst geprüft werden). Hier handelt es sich um den CurrageReturn, sprich den Zeilenumbruch. Das Tool entfernt aber, wie gesagt, Leerzeichen an Zeilenenden des Skrips korrekt.
ToDo:
- Ignoreliste selbst definierbar machen
- Farbeinstellungen selbst wählbar
- Stabileres Programm schaffen, damit es bei Fehlbedienung nicht gleich in den Schlund der Hölle stürzt.
Ich hoffe auf etwas Feedback, falls es noch weitere Punkte gibt, die ich mir anschauen sollte. Momentan habe ich etwas mehr Zeit, in 3 Wochen sieht es aber schon wieder anders aus
Gruß
Da war aber jemand fleißig und der Mi213 wird sich freuen
Gruß
red
Perfekt!
Hab gestern noch zu red geschrieben das mit dem anderen Sachen bei FFV bald fertig bin und mich anschließend um die Dialoge kümmern wollte. Für die Dialoge wollte ich aber noch auf die neuen Funktionen warten. Der Zeitpunkt passt also super.
Dann bin ich mal gespannt. Ich schau es mir gleich mal an.
Danke schon mal für deine Mühe!
Oha, hab was gefunden.
Die linke Zeile wo die Pixelwerte stehen, scrollt nicht mit wenn man den Text runter scrollt. Man muss sie unabhängig von einander scrollen, was natürlich semioptimal ist da man irgendwann nicht mehr weiß welcher Wert zu welcher Zeile gehört. Das kann natürlich nicht im Sinne des Erfinders sein. Ein anderes seltsames Verhalten: Wenn ich die Textdatei verändert neu lade oder auch eine ganz andere Textdatei, wird die linke Zeile mit den Werten nicht aktualisiert. Also im Prinzip nur beim ersten mal wenn ein Text geladen wird und dann erst wieder nach einem Neustart des Tools.
Warum hast du die Werte eigentlich in eine separate Zeile gepackt? Die haben doch in dem großem Fenster nicht gestört.
Und ich wollte noch mal an dem Vorschlag erinnern das neben dem Pixelwert der Zeile auch die übrigen Pixel angezeigt werden, die noch passen würden bis die Maximale Zeilenlänge in Pixel erreicht werden (wie oben in dem Bild von mir), so kann man besser (schneller) abschätzen in wie fern eine Änderung des Textes möglich ist.
Noch mal etwas, das mir in einer älteren Version aufgefallen ist: Mit dem Button Table-Editor kann man eine neue tbl erstellen, aber nicht in eine geladene tbl einsehen bzw. diese editieren.
Ok, schau ich mir heute Abend gleich an. Dass die linke Zeile aktualisiert wird, ist auch schnell gemacht.
Rausgenommen hab ich die, weil sie beim Text selektieren massiv gestört haben, da sie Ergebnisse verfälscht haben
Dass noch freie Pixel angezeigt werden, ging wohl irgendwie unter. Ist vermerkt und evtl. heute Abend gleich noch gemacht. Table laden und editieren ist dann auch gleich drin.
So, neue Version mit einigen Bugfixes bzw. Änderungen:
Changelog:
- Scrollbar scrollt nun das zweite Textfeld mit den Zeilenlängen korrekt mit
- Übrige Pixel für die Zeile werden beim Markieren angezeigt
- Tables sind nun im Editor einlesbar und editierbar
Probiers einfach nochmal aus, ob es jetzt einigermaßen passt
Kleine Anmerkung noch:
Ich gebe den Code und alles drumherum raus, sobald ich selbst das Ding für einigermaßen fertig halte. Ein paar Sachen müssen noch gemacht werden, dann stelle ich alles hier rein.
