Nee, das ist alles kein großes Problem, so Update-Mechaniken gibt es schon mehrere im C64Studio.
Man muss es halt nur machen, und grundsätzlich bin ich ja ein fauler Sack und suche Ausreden
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von 64erGrufti am
Nee, das ist alles kein großes Problem, so Update-Mechaniken gibt es schon mehrere im C64Studio.
Man muss es halt nur machen, und grundsätzlich bin ich ja ein fauler Sack und suche Ausreden
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?
Danke für's Zusammenstellen, wird gefixt!
Korrigierte Version ist auf dem WIP-Link hochgeladen! Danke für's Melden!
In Kürze sollte ich endlich mal wieder ein neues Release fertig stellen.
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
Ist eigentlich ein Linuxport geplant?
Da fehlt mir die Erfahrung zu
Es gibt wohl Möglichkeiten, das mit Mono oder WINE ans Laufen zu bekommen, irgendjemand hatte das hier mal gepostet.
Ich hoffe immer noch heimlich auf eine Forms-Portierung auf .NET Core.
Ok, ja Schade, dass man C# mit WPF oder WinForms nicht gleich crossplattform gemacht hat. Aber da denkt jede Firma natürlich nur an das eigene System.
Ich hatte es Mal getestet mit wine und Mono.
Resultat: irgendwas fehlt ich weiß nur nicht mehr was
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.
Ja, ich mit meinen bösen GDI-Funktionen dahinter. Da muss ich mal zugucken, das muss ja auch ohne gehen eigentlich.
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.
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.
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".
Ja, die wollen ja immer diese Trennung von Programmierer und GUI Designer erzwingen, ob es so etwas in der Praxis gibt?
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
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
.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).