Hallo Besucher, der Thread wurde 63k mal aufgerufen und enthält 402 Antworten

letzter Beitrag von Lynx am

C64 Studio - Features Wunschliste

    2-Byte-Problem: Da sich das auf alles bezieht, was man per Cevi speichert und auf PC überträgt, wäre das natürlich nicht schlecht. Auch beim Einbinden von Tabellen etc. mit "!bin" muss man ja darauf achten. Allerdings habe ich mir bereits angewöhnt, die PRG-Dateien kurz in den Hex-Editor zu werfen, zweimal [Entf] drücken und einmal Save klicken, und fertig. Ich benutze dafür den Editor HxD (Freeware). Auch, um die Farben aus einem Koala-Bild zu extrahieren oder ähnliches, ist es gut geeignet.


    <= Trivial-Tutorial-Bild. Musste mal mein Snapshot-Programm erproben.



    Docking-System: Hab die Dinger im Quellcode vor-positioniert und sind jetzt ganz ungefähr da, wo ich sie wollte. Aber gerade beim Debuggen sehe ich lieber mehr auf einmal, ähnlich wie beim VICE-Debugger. Da muss irgendwas noch gespeichert werden, aber ich hab das System noch nicht durchschaut. Welches Fenster sich wie umpositioniert, hängt derzeit irgendwie davon ab, welche anderen Fenster wo positioniert sind. Bspw. erscheint das Find-/Replace-Fenster erst da, wo es sein sollte, aber dann wieder an einer andere Stelle, sobald ich zuvor ein ASM-Dokument geladen habe. Ist aber auch nicht das große Problem; es geht durchaus erst mal auch so. Es ist nur so, dass ich das ja nicht wusste und mir das zu Anfang alles mit viel Geduld und pixelgenau zurecht geschoben hatte ... :S



    Syntax-Highlighting:
    Hab ich mir schon mal weiter angepasst. Würde mich freuen, wenn das so ähnlich eingebaut würde, nicht nur für mich natürlich.


    1. Auswahl-Farbe: In SourceASMEx.Designer.cs habe ich editSource.SelectionColor zu weiß geändert. Es wäre gut, wenn man die Farbe einstellen könnte, denn bei dunklem oder schwarzem Hintergrund ist das voreingestellte Blau viel zu dunkel. Durch das Weiß mit Transparenz 50 ist es jetzt bei mir grau, während der ausgewählte Text darin erhellt wird. Sieht gut und praktisch aus.


    2. Berücksichtigung der bereits einstellbaren Farbe "Text", also aller Zeichen, die keinem syntaktischen Text zuordenbar sind. (SourceASMEx.cs, auch für 3. und 4.)
    Da die Farbe noch nicht aktiviert wurde und schwarz war, waren auf dem schwarzen Untergrund alle Zeichen, die keine andere Farbe bekommen, unsichtbar.


    RegEx: m_TextRegExp[(int)Types.ColorableElement.NONE] = new System.Text.RegularExpressions.Regex( @"\S" ); Whitespaces sollten verschont bleiben.
    void ResetAllStyles(...) { ... : Range.SetStyle( m_TextStyles[SyntaxElementStylePrio( Types.ColorableElement.NONE )], m_TextRegExp[(int)Types.ColorableElement.NONE] );



    3. Bei den Pseudo-Ops !8, !08 und !16 wurden die Zahlen hinterm Ausrufezeichen als Numeric Literal eingefärbt anstatt als Pseudo Operator. Deswegen hab ich die Colorisierungs-Priorität geändert:

    Code
    1. case C64Studio.Types.ColorableElement.LITERAL_STRING: value = 4; break;
    2. case C64Studio.Types.ColorableElement.OPERATOR: value = 5; break;
    3. case C64Studio.Types.ColorableElement.PSEUDO_OP: value = 6; break;
    4. case C64Studio.Types.ColorableElement.LITERAL_NUMBER: value = 7; break;
    7. // vorher: STRING = 4, NUMBER = 5, OPERATOR = 6, PSEUDO_OP = 7

    Bislang habe ich dadurch keinen Nachteil bemerkt. Ansonsten müsste man in der RegEx für LITERAL_NUMBER hinzufügen, dass Zahlen mit Ausrufezeichen davor nicht dazu gehören.



    4. Der Cursor der FastColoredTextBox ist etwas seltsam. Zum Blinken wird er nicht transparent, wie es üblich ist, sondern invertiert stattdessen und verdeckt dadurch oft einen Teil breiterer Zeichen. Das ist zwar nicht so schlimm, aber seine Ausgangsfarbe ist auf schwarz eingestellt, und beim Bewegen des Cursors nimmt er diese bei jedem Positionswechsel zuerst an, was während der Bewegung zur Folge hat, dass er nicht zum Blinken kommt und dauerhaft schwarz bleibt. Bei hellem Hintergrund immer noch kein Problem, aber sobald ein sehr dunkler oder schwarzer Hintergrund gewählt wird, verschwindet der Cursor während des Navigierens. Das macht jedes dunkle Theme quasi unbrauchbar.


    Abhilfe schafft hier eine Formel zur Bestimmung der optimalen Cursor-Farbe. Hab ich untergebracht in RefreshDisplayOptions(){...}:

    Code
    1. if ( ( 0.2126 * editSource.BackColor.R + 0.7152 * editSource.BackColor.G + 0.0722 * editSource.BackColor.B ) < 127.5 )
    2. {
    3. editSource.CaretColor = System.Drawing.Color.White;
    4. }
    5. else
    6. {
    7. editSource.CaretColor = System.Drawing.Color.Black;
    8. }


    Keine Ahnung, ob das alles so richtig ist, aber es funktioniert. :)




    jbtw .. Frohe Pfingsten!

    Au cool, danke :)


    Nehme ich gleich mit, was du schon gelöst hast, bzw. packe ich auf die Liste!



    Wegen des 2-Byte-Problems:
    !bin kann ja auch die ersten zwei Bytes überspringen (!bin "datei",,2)


    Alternativ ist auch schon ein Hex-Editor eingebaut (unter Window->Binary Editor)

    >"!bin kann ja auch die ersten zwei Bytes überspringen (!bin "datei",,2)"


    Das hatte ich auf der ACME-Wiki-Seite wohl gelesen, wusste allerdings noch nicht, ob das so auch schon im C64Studio implementiert ist. Wenn das so ist, ist das ja traumhaft.



    >"Alternativ ist auch schon ein Hex-Editor eingebaut (unter Window->Binary Editor)"
    oh, tatsächlich Jetzt könnte ich als Argument bringen, dass HxD aber 4GB-Dateien handeln kann, was gerade so ausreichend ist für C64-Programmierung. :haue:

    Von wegen behoben .. speichert immer noch kurz nach dem Starten einige Defaultwerte in die settings.dat, bspw. "0.25" für den sichtbaren Anteil bei "autohide" usw. Da hatte ich mich wohl zu früh gefreut und nicht richtig geprüft, weil ich weg musste, sorry. Werde mir das heute Abend nochmal ansehen, weil dieses WeiFenLuo-Ding einfach zu schön ist, um es nicht (ganz) im Sinne des Erfinders nutzen zu können.


    Syshack hat wohl Recht .. Da ist schon einiges an Code zusammengekommen für ein Ein-Mann-Projekt. Deswegen dachte ich, ich schau nach meinen eigenen (Sonder-) Wünschen selbst schon mal -- zumal wir alle ja nur noch 2 Jahre Zeit haben. ;) Nicht dass du, lieber Georg, nachher noch mit Burn-out-Syndrom zum Arzt musst. 8| Das sieht mir jedenfalls nach viel Arbeit aus, sodass ich da wohl mal was vom nächsten PP-Guthaben abzwacken muss. :)

    Gräbst du dich in das WeifenLua-Dingen rein? Ich habe da schon ein paar Mal versucht, den Stand anhand des Status im Debugger erkennen zu wollen. Dazu fehlt mir aber dann immer die Muße, die Innereien zu verstehen.


    Viel von den Parent/Child-Verbindungen sind immer gesetzt, selbst wenn es keinen Sinn zu machen scheint. Z.Bsp. Parent als einzelne Floating Instanz?


    Vielleicht habe auch ich selbst das Problem verursacht, in dem ich ein paar Docking-Präferenzen setze.

    Hallo @Endurion ich hätte da einen Vorschlag und zwar beim Disassembler. Wenn man unter Tools auf Disassemble File... klickt kommt ja der leere Kartenreiter zum Disassemblieren. In ihm befindet sich das Data Feld in der Mitte. Wenn man nun im Data Feld auf den Button open klickt (Und jetzt kommt der Vorschlag), dann währe es nicht schlecht, wenn nach dem Datei-öffnen-Dialog noch eine Abfrage stattfinden könnte, ob eine Binärdatei komplett, also in einem Rutsch, disassembliert wird, oder nur so, wie es schon ist, also etappenweise.


    Ich hoffe du steigst da durch, was ich meine.


    Nach der Dateiauswahl (*.bin) und dem öffnen klick soll halt eine Abfrage stattfinden. -> Ob ganz, oder häppchenweise.

    Also, auf Teufel komm raus, einfach komplett runter disassemblieren? Kann man machen, das hilft für einen ersten Blick vermutlich ganz gut.
    Fällt natürlich völlig auf die Schnauze, sobald auch nur ein Füll-Byte drin ist.


    Aber wer mit einem Disassembler rumspielt, weiß sowas eigentlich ;)

    Deswegen soll dein Studio ja besser sein, als die anderen einzelnen Disassembler. Man hat halt am Anfang die Wahl. Und wenn es schief läuft, kann man ja auch ein zweites Mal dann Stück für Stück disassemblieren. Es würde halt bei manchen Sachen hilfreich sein.


    Ist halt nur ein Verbesserungsvorschlag. Du mußt das nicht machen, wenn du nicht möchtest. :D
    Vielleicht geht das ja auch mit Häckchen setzen? Wer weis ...
    Das Andere sind glaube ich Radiobuttons? Bei der Vorauswahl der Radiobuttons kann man glaube ich eine Voreinstellung treffen, so daß er Standartmäßig halt häppchenweise disassemblieren würde und erst wenn der andere Radiobutton angeklickt wird, macht er halt in einen Rutsch.


    Oder so eine Achtung Meldung mit Nachfrage, bei der dann mit ja oder nein Klick die Entscheidung fällt und er die Datei läd und entsprechend der Entscheidung disassembled. :thumbsup:

    Hätte zum Disassembler auch noch einen Vorschlag.


    Einen Update-Button.
    Bisher ist es so.
    Datei assemblieren.
    Disassembler anklicken.
    Datei (wieder) wählen.
    Disassemblierung.


    Was wäre, wenn er sich den vorigen disassemblierten Dateinamen/pfad merkt.
    Ich drücke dann, falls ich wieder neu assembliert hab, einfach auf "Update" und er disassembliert mir dasselbe nochmals, nur diesmal eben mit den neuen Daten.
    Jetzt muss man immer die Datei neu auswählen.


    Danke :)

    Äh, änderst du die Quelldatei? Das wäre meines Erachtens nach der einzige Zweck des Update-Buttons (dann macht er auch Sinn)


    Ansonsten wird jetzt schon immer neu disassembliert, wenn man an den Labels oder Sprung-Adressen etwas ändert.

    Der Map Editor gefällt mir schon mal super. Die Funktion "copy inc'ed" hat mir eine Menge Zeit erspart!
    Trotzdem noch Wünsche und eine Frage.


    Wünsche für den Map Editor:

    • Map:

      • hier wären Hilfslinien super, gerne auch mit Zeilen/Spaltennummerierung
      • möglichkeit die Reihenfolge der Maps zu verschieben, wie bei den Tiles (Up/Down)
    • Tiles:

      • wenn die Hintergrundfarbe weiß=charcolor ist, kann ich nix sehen (habe als Workaround auf dunkelgrau gestellt)
      • schön wäre es noch, wenn man das obere Nibble der colortables für "material" hätte = 16 Werte für lau
      • ODER Optional die Werte von mehreren Farbtabellen zusammenfassen, so dass man mit 4*LSR jeweils den zweiten Wert selbst ausrechnen muss

    Frage:
    Wie bekomme ich da was nach "Extra Data"? Habe z.B.
    $CA,$FE
    eingetragen. Aber beim Ausleiten mit "tile data, then map data" -> "as assembly" kommt nur schmu raus?

    Gute Vorschläge, ich schaue, dass ich die umgesetzt bekomme!


    Extradata ist ein bißchen zickig, da kommen !byte-Statements rein. Ich habe da Assembler-Code gewählt, damit man auch Kommentare reinsetzen und vorhandene Labels/Konstanten verwenden kann. Bei dem F64GC für Adventures habe ich da Screen-Metadaten untergebracht:


    ;screen exit x,y,WWWWHHHH,target screen,target x,target y and dir DDxxYYYY
    ;exit left
    !byte AAT_EXIT,2,12,$13,1,33,$4d
    ;exit right
    !byte AAT_EXIT,37,12,$13,4,3,$0d
    ;return zone
    !byte AAT_TRIGGER_CUTSCENE,15,( DIR_UP << 6 ) | 9,$c1,15
    ;end
    !byte 0

    Ich hätte einen Wunsch bezüglich des Assemblerfensters. Könnte man im linken Teile (z.B vor der Zeilennummer oder der Taktzyklenanzeige) die Adresse im Speicher des C64 mit den gleichen Optionen wie die Taktzyklenanzeige / Zeilennummer anzeigen? Das würde das Suchen im Emulator einfacher machen, da man gleich die richtige Adresse angezeigt bekommt.