Hallo Besucher, der Thread wurde 680k mal aufgerufen und enthält 5181 Antworten

letzter Beitrag von 64erGrufti am

C64 Studio - Entwicklungsumgebung

    Hm, ich glaube ich habe einen Fehler entdeckt, bin mir aber auch nicht zu 100% sicher.

    Ich wollte je nach Definition eine andere Makrodefinition haben, aber irgendwie bekomme ich das nicht hin.


    Hier mal ein stark vereinfachtes Beispiel um den Fehler aufzuzeigen:

    Edit: Ok, mit der !end Syntax geht es zumindest. Sollte aber mit den Klammern eigentlich auch gehen, oder?

    Endlich mal wieder ein Päckchen geschnürt, hier ist Version 6.5:


    Eine der besseren Änderungen ist der Einbau des neuen Binary Monitor Interfaces des neuen VICE. Dazu muss die Kommandozeile des Emulators aber derzeit noch manuell angepasst werden:

    Statt "-remotemonitor" muss es "-binarymonitor -binarymonitoraddress" 127.0.0.1:6510 sein.

    Vorsicht: Das ist möglicherweise noch nicht ganz stabil, aber auf jeden Fall deutlich schneller als die alte Lösung.


    Fix: Update URL for version check

    Fix: Allow {, }, _ as valid keys for BASIC (to access assembly symbols)

    Add: Binary Editor - remove nth byte option

    Fix: Macro with squiggly braces inside inactive scope would not be properly parsed

    Fix: Replace tool list with arrangeditemlist

    Add: Allow clone for arranged item lists (sprite editor, grapic screen editor, value table editor, library paths, build chains)

    Add: Binary editor, wrap data output (ASM)

    Fix: BASIC Renumber modified Ctrl-N in string literals

    Add/Fix: Export sprite to BASIC now obeys the wrap-at-x-bytes setting

    Fix: Crash when copylinedown is used in bottom most line

    Fix: Theming, set BASIC editor fore color to CODE, not CONTROL_TEXT

    Fix: Remove "GO" BASIC token once again, messes up syntax coloring for GOSUB and GOTO

    Fix: Only auto-add truedrive options for VICE

    Add: Auto-Add local baselib path for Kernal.asm

    Fix: Tiny theming issue with labels

    WIP: Decent sample projects

    Tiny cleanup of sample projects, needs major overhaul!

    Fix: Rename BASIC line number for exports consistently

    Add: !fill expression method

    Add: Keybindings for bookmarks

    Fix: Scaling bug in sprite editor

    Add: Allow font styles

    WIP: New binary monitor interface to GTK Vice

    Fix: typo in doc

    Fix: autodetection for zeropage addressing failed for value $ff (facepalm)

    Fix/Add: Allow adding of .chr binary to solution

    Fix: Allow breakpoints working with non-project files

    Fix: Export to Koala, added missing BG color byte

    Fix: Proper wait for executed output during build

    Add: Dependencies and symbols from other projects

    Add: Charset control in charset screen

    Add: Export to binary charset from map project

    Fix: charset screen size change only sets modified if it really changes



    Neue Version ist wie immer auf https://www.georg-rottensteine…iles/C64StudioRelease.zip

    Zitat von Endurion

    Irgendjemand hatte das hier mal gepostet.

    Ich hatte es soweit unter Linux erstellt bekommen, aber es lief trotzdem nicht, da es auf native win32 (nicht dotNet bzw. Mono) Funktionen zurückgreift, diese nicht findet und somit mit Laufzeitfehlern um sich wirft. Wenn ich die Aufrufe auskommentiert hatte, hab ich zumindest ein leeres Fenster angezeigt bekommen.

    Längerfristig wirst du wohl nicht darum herumkommen einen Schnitt zu machen und komplett neu auf eine andere Basis anzufangen, wenn Du wirklich die IDE systemübergreifend machen willst.


    Ich weiss nicht wie weit sich Visual Studio Code (nicht Visual Studio) UI mässig programmieren lässt, aber ich würde mir das mal anschauen.

    Die Code Entwicklung sowie Debugging sollte da wohl lösbar sein, das ganze rundherum wie Deine speziellen Addons, müsstest du evt. auslagern.

    Zumindest die IDE UI Basis müsstest Du nicht selbst bauen, die ist schon gratis in Gamma's systemübergreifend existierenden VS Code gut abgedeckt.

    Zitat von syshack

    Längerfristig wirst du wohl nicht darum herumkommen einen Schnitt zu machen und komplett neu auf eine andere Basis anzufangen, wenn Du wirklich die IDE systemübergreifend machen willst.


    Ich weiss nicht wie weit sich Visual Studio Code (nicht Visual Studio) UI mässig programmieren lässt, aber ich würde mir das mal anschauen.

    Die Code Entwicklung sowie Debugging sollte da wohl lösbar sein, das ganze rundherum wie Deine speziellen Addons, müsstest du evt. auslagern.

    Zumindest die IDE UI Basis müsstest Du nicht selbst bauen, die ist schon gratis in Gamma's systemübergreifend existierenden VS Code gut abgedeckt.

    Das hört sich nach *sehr* viel Arbeit an, und auch nicht nach sehr viel Spaß, da man am Ende im besten Fall eine IDE hat, die genauso gut ist wie sie jetzt ist. Ich würde eher empfehlen, sich einen engagierten Mitstreiter jeweils für Linux und macOS zu suchen und das ganze mit Mono oder unter Wine lauffähig zu machen.

    Hmm, wenn es Java wäre würde ich mich mit dranhängen. Da ich schon länger selber an sowas arbeite.

    Zitat von Claus

    Das hört sich nach *sehr* viel Arbeit an, und auch nicht nach sehr viel Spaß, da man am Ende im besten Fall eine IDE hat, die genauso gut ist wie sie jetzt ist. Ich würde eher empfehlen, sich einen engagierten Mitstreiter jeweils für Linux und macOS zu suchen und das ganze mit Mono oder unter Wine lauffähig zu machen.


    Das Problem ist dass Mono & co halt auch nicht unbedingt alles haben, was im C64 Studio unter Windows verwendet wird.

    Der Wille und Hilfe allein bringt Dir Dann nicht viel, das dann nach MacOX und Linux cross-entwickeln zu wollen.

    Es muss halt das darunter liegende Framework in der Lage sein, die Apps auf diese drei Plattformen laufen zu lassen.


    Ich weiss nicht wie gut WinForms in der Zwischenzeit unter Mono laufen, das war vor ein paar Jahren noch nicht wirklich was.

    Xamarin.Forms könnte noch was sein, aber ich weiss nicht wie gut und ob Linux Unterstützt werden.

    Zumindest unter MacOS und Windows wäre hier vielleicht was möglich.

    Man könnte evtl. auf GTK# setzen, aber auch das ist wahrscheinlich ein kompletter Rewrite.


    Was mit ziemlicher Sicherheit kommen wird, ist .NET Core, da läuft ja alles im Moment hin. Das dürfte dann schon einige notwendige Anpassungen erfordern, die das komplett-Übersetzen dann vereinfachen.

    So weit ich gelesen habe möchte aber Mircosoft kein WPF oder so für .NET Core für andere Systeme außer Windows umsetzen. Was bleiben würde, wäre einen Backend in C#/Mono mit .NET Core und das Frontend auslagern, in was auch immer. Wäre aber alles wahrscheinlich ein Rewrite ohne Spaß an der Freud.

    Forms wird am meisten gewünscht, weil es am angenehmsten zu verwenden ist (IMHO) :)

    Aber das setzt zu sehr auf Win32 auf, das müsste man ja fast mitportieren.


    WPF ist ein völlig überdesignter XML-Clusterf*ck. Das hat java-"Qualität".

    Zitat von Endurion

    Forms wird am meisten gewünscht, weil es am angenehmsten zu verwenden ist (IMHO) :)

    Aber das setzt zu sehr auf Win32 auf, das müsste man ja fast mitportieren.


    WPF ist ein völlig überdesignter XML-Clusterf*ck. Das hat java-"Qualität".

    Ähm...ich habe mich auch lange gestreubt, aber auch wenn ich jetzt nicht oder kaum mehr programmiere, vor ein paar Jahre habe ich den Switch auf WFP gemacht und danach Win32 mit WinForms nur noch grässlich gefunden :D

    UWP ist quasi der Nachfolger von WPF.

    Das wäre vermutlich eher noch portierbar als WinForms, was ein schöneres Wort für das ganze underlying Win32, MFC & co Gefrickel ist :bgdev


    .NET Core wird in den nächsten Versionen 5 und dann 6 immer mehr .NET Framework Klassen enthalten und es ersetzen. Aber ob das eine gute Idee ist?

    Es wird auch nicht den ganzen UI Kram enthalten für nicht-Windows Systeme. Das macht es dann sehr kompliziert, plattform-unabhängige Tools zu bauen, was eine der Stärken heute bei .NET Code ist (allerdings nur für CLI Applikationen).