Welcome to Schneider / Amstrad CPC Forum. Please login or sign up.

29. March 2024, 16:44:24

Login with username, password and session length

Shoutbox

TFM

2024-01-15, 17:06:57
Momentan billige Farbbänder auf Ebay für PCW

Devilmarkus

2023-07-09, 10:37:40
Zweiter 👋😂🤣

TFM

2023-06-13, 14:21:49
Sommerloch!

TFM

2023-05-30, 17:00:20
Erster ;-)

Recent

Members
Stats
  • Total Posts: 11,656
  • Total Topics: 1,329
  • Online today: 188
  • Online ever: 1,724
  • (16. January 2020, 00:18:45)
Users Online
Users: 1
Guests: 153
Total: 154

153 Guests, 1 User
xesrjb

Hacking Bruce Lee

Started by Fessor, 13. November 2019, 23:07:58

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Fessor

Entscheidungen, Entscheidungen...
Mit ETO.Forms existiert ein Betriebssystemübergreifendes Framework für das User-Interface womit es sich auf dem jeweiligem Host integriert nahtlos in das Oberflächendesign integriert und wie eine typische Anwendung des Host-Systems erscheint. Den API-Beschreibungen der Grafikbibliothek nach beherrscht es auch indexed Bitmaps.
Riesengroßes Manko: Es hat keinen grafischen Interface-Designer. Weder auf Windows, noch auf dem Mac noch unter Linux.
Interfacedesign in Handarbeit per XAML (kenn ich nicht), JSON (kenn ich nochweniger) oder aus c# heraus....

Ich werd wohl also erstmal gucken, ob das mit den indexed Bitmapimages funktioniert wie erhofft...

Neuprogrammierung war eingeplant, aber dass sooo weit ausgeholt werden müsste dass auch das Interface programmiert werden muss, war eigentlich nicht auf dem Zettel...

Fessor

Eto.Forms will nich so wie ich wohl will. Bei den indexed-Bitmaps dort werden die Pixel per Pointerzugriff angesprochen, was in C# "unsafe" ist. Scheinbar hat Monodevelop beim Aufruf des Compilers einen Bug und der Parameter scheint fehlerhaft übergeben zu werden, so daß das Programm nicht compiliert werden kann. Damit hat sich das Experimentieren in diese Richtung erstmal erledigt.

Also gehts mit der Ursprünglichen Fassung weiter und der Code wurde weiter in Richtung eines Editor getrimmt; es wird nun nicht mehr direkt auf das Binary zugegriffen sondern alles relevante in Arrays verfrachtet um ein Abspeichern/Exportieren sowie ein Laden der Änderungen zu ermöglichen.

Ein Primitiver Tileeditor funktioniert nun auch, nun werd ich mal schauen, das man die Räume auch editieren kann.

Fessor

So. Die Performancebremse wurde auch gefunden. Die Custom-Widgets sind schuld und gehören nochmal überdacht.
Das Programm wurde richtig langsam als ich die 440 Tiles der Raumkarte mit Custom-Widgets darstellen wollte damit sie auf Klickereignisse reagieren können.
Also habe ich die selbsterstellten Widgets mal rausgenommen und das Programm reagiert praktisch verzögerungsfrei wenn man die Inks neu zuweist.


Fessor

Die Performancebremse ist nun eliminiert und die Oberfläche gibt wieder optisch Feedback, über welchem Tile der Mauszeiger grade schwebt; dieses sowohl in der Raumkarte als auch der Tilebox. Als nächstes steht nun an, ein Tile selektieren zu können und dieses per Mausklick in die Raumkarte einzubringen bzw. bei gedrückter Maustaste kontinuierlich bei Mausbewegung einzuzeichnen.

Übernächster Schritt ist dann ein RLE-Kompressor und das Speichern der Raumkarte(n) als Ascii-File für Winape und als Binärfile für den Editor (um arbeiten zu späteren Zeitpunkten fortsetzen zu können bzw. Sicherheitskopien erzeugen zu können, da ich noch keine Idee habe, wie eine Undo-Funktion zu realisieren wäre)


Fessor

Es läuft grade beim Coden.
Änderungen werden bemerkt und erzeugen bei einigen Funktionen Rückfragen. (Programmende und Laderoutinen)
Funktionen für "Neues Projekt", "Projekt öffnen" und "Projekt sichern" integriert um mehrere Levelsets verwalten zu können.
Die Environtmentvariable "HOME" wird ausgelesen und dort ein Basisverzeichnis für den Editor zur Verwaltung der Projekte erzeugt.
(Unter Windows müsste es die Variable eigentlich auch geben)

Bei den Overlays bin ich noch nicht ganz zufrieden; durch die Buttons für "Eintrag hinzufügen"/"Eintrag löschen" sieht das Layout der Tabelle nun unhübsch aus.
Ähnliches gilt für die Radio-Buttons unterhalb der Raumkarte. Mit denen bin ich auch noch nicht ganz zufrieden.
Das kommt mal zum Themenkomplex die OVLs bearbeiten/anzeigen zu können.

oobdoo

CPC 464/6128, 464/6128+, GX4000 | Atari 2600, 600XL, 800XL/XE, Portfolio | C64/II/G/R/SX, VC20, TC64 | LC 80, MPF-I | ZX81, AX81, ZX Spectrum 48k, ZX Spectrum+2 | Amiga 500/600/2000, A2630, A2088

Fessor

Danke, auf den ersten Blick sieht das aber nicht aus wie etwas, für das ich mich begeistern könnte.

Habe die Architektur im Editor mal von fixen byte-Arrays auf flexible Listen umgestellt um die Begrenzung auf 20 Räume aufzuheben. Ein RLE-Enkoder ist nun auch fertig sowie eine Exportfunktion von allen Daten für Winapes Assembler.

Also fix mal Assembliert und Yamo beim Fallen ein anderes Sprite zugewiesen...
Und das Ergebnis stimmt optimistisch.

Fessor

So, im ersten Beitrag ist nun ein Diskimage und ein erster Entwurf für einen Hackinguide zu finden. Das "neue" Spiel wird mit run"brucerev" gestarted.

Fessor

Frohes neues Jahr 2020.

Wieder ein Etappenziel erreicht: Overlays können nun per Mausklick platziert oder entfernt werden sowie die Tabelleneinträge editiert werden.

Müssen nur noch die Buttons im UI für "Raum Hinzufügen", "Eintrag hinzufügen" und "Eintrag löschen" gangbar gemacht werden und die Tabelleneinträge im Mapheader für die Verlinkung der Räume editierbar gemacht werden und der Editor wäre, von einigen noch wenigen kosmetischen Änderungen abgesehen, fertig.
Im Tileeditor muss ich noch hervorheben, welche INK grade ausgewählt ist und das Layout noch ein bischen aufhübschen.

Ein Spriteeditor ist erstmal nicht so wichtig, der kann per Update nachgereicht werden. Ebenso bin ich am noch am Überlegen ob ich einen kleinen Texteditor einbaue, mit dem man im Editor kleine Assemblerroutinen für die Events programmieren kann, die dann auch  mit Exportiert werden, oder ob ich es einfach nur beim Ausgeben von Labeln in den Headern belasse und man programmiert dann die Raumabhängigen Routinen in Winape.

Fessor

Eigentlich ist der Editor nun für eine erste Veröffentlichung bereit. Alle Funktionen und Szenarien sind durchgetestet. Er erkennt nun auch das  Betriebssystem auf dem er läuft  und fragt das Environment nach dem jeweiligem Home-Verzeichnis ab um seine Dateistrukturen anzulegen aber uneigentlich liegen wieder Steine im Weg - unter Windows will er nicht starten obwohl die benötigten DLLs beiliegen.
Alles mögliche schon durchgetestet. Path gesetzt - nope; Gtk#-Librarys installiert - nope; mono installiert - nope...
Aus der CMD.EXE gestartet - Keine Fehlermeldung.
Im Anwendungsprotokoll sind Einträge getriggert und man landet wieder in der Googlehölle mit zigtausend Meldungen zu ähnlichen Problemen aber keinen Lösungen weil das wieder viel zu generisch ist...



oobdoo

Bei mir startet es unter W10 weder mit Doppelklick noch über cmd.exe. Die Ereignisanzeige meldet .NET Runtime.

QuoteAnwendung: BruceLeeEditor.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.IO.FileNotFoundException
   bei BruceLeeEditor.MainClass.Main(System.String[])

Demnach fehlt irgend eine Datei. https://www.heise.de/download/product/process-monitor-38423 sollte unter Windows in solchen Fällen weiterhelfen.
CPC 464/6128, 464/6128+, GX4000 | Atari 2600, 600XL, 800XL/XE, Portfolio | C64/II/G/R/SX, VC20, TC64 | LC 80, MPF-I | ZX81, AX81, ZX Spectrum 48k, ZX Spectrum+2 | Amiga 500/600/2000, A2630, A2088

Fessor

#41
Quote from: oobdoo on 04. January 2020, 10:36:48
Bei mir startet es unter W10 weder mit Doppelklick noch über cmd.exe. Die Ereignisanzeige meldet .NET Runtime.

QuoteAnwendung: BruceLeeEditor.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.IO.FileNotFoundException
   bei BruceLeeEditor.MainClass.Main(System.String[])

Demnach fehlt irgend eine Datei. https://www.heise.de/download/product/process-monitor-38423 sollte unter Windows in solchen Fällen weiterhelfen.

Bei der Fassung liegen die nötigen DLLs nicht bei, insofern war das zu erwarten.

In einem Mailinglist-Posting von 2009 habe ich scheinbar die Lösung gefunden, da es auf meinem Virtual-Box-Window nun durchstartet.
Neue Fassung im Anhang anbei.


oobdoo

Keine Reaktion mit Doppelklick oder CMD.

QuoteAnwendung: BruceLeeEditor.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.DllNotFoundException
   bei GLib.Marshaller.g_utf16_to_utf8(Char*, IntPtr, IntPtr, IntPtr, IntPtr ByRef)
   bei GLib.Marshaller.StringToPtrGStrdup(System.String)
   bei GLib.Global.set_ProgramName(System.String)
   bei Gtk.Application.SetPrgname()
   bei Gtk.Application.Init()
   bei BruceLeeEditor.MainClass.Main(System.String[])
CPC 464/6128, 464/6128+, GX4000 | Atari 2600, 600XL, 800XL/XE, Portfolio | C64/II/G/R/SX, VC20, TC64 | LC 80, MPF-I | ZX81, AX81, ZX Spectrum 48k, ZX Spectrum+2 | Amiga 500/600/2000, A2630, A2088

Fessor

Das ist schon eine Fehlermeldung aus dem Programminneren. Die beiliegenden DLLs taugen offenkundig nur für Linux. Bei mir war gtk# noch vom experimentieren installiert. Wenn ichs deinstalliere krieg ich die gleiche Fehlermeldung.

Bei Windows müssen die Libs also offenbar extra installiert werden: https://xamarin.azureedge.net/GTKforWindows/Windows/gtk-sharp-2.12.45.msi

Ich werds beim nächsten Release beilegen.


oobdoo

Die letzte Antwort von Fessor war im Jannuar. Ich hoffe er halt bald wieder Zeit für sein Projekt.
CPC 464/6128, 464/6128+, GX4000 | Atari 2600, 600XL, 800XL/XE, Portfolio | C64/II/G/R/SX, VC20, TC64 | LC 80, MPF-I | ZX81, AX81, ZX Spectrum 48k, ZX Spectrum+2 | Amiga 500/600/2000, A2630, A2088