Wielviel Hindergründe soll denn das Spiel enthalten ?
Yes
Posts by Endurion
-
-
Kurz vor Knapp!
Meine Tochter hat doch keine Lust mehr, d.h. nur ich und Sohnemann würden kommen. Bitte zwei der drei Plätze zusammenlassen, einer wird frei. Ist nur für Samstag! -
Ähnlich wie Visual Studio das anbietet? Muss ich mal gucken, ob die DockPanelSuite das her gibt.
-
Meine Internetverbindung ist aber stabil.
Version: 7.8.64
Internet braucht es für die Hilfe gar nicht, das liegt lokal als Datei vor. Hast du das in Visual Studio gestartet? Da passiert das im Release-Modus (doof, aber isso)
Grade mit der letzten WIP-Version auf dem Build-Server verglichen, da ging das (mit net6.0-windows).
Sonst guck bitte mal direkt nach dem Start im "Output"-Fenster, da wird der aktuelle Pfad zur Doku ausgegeben:
Ist es da der falsche Pfad? Da wird eigentlich der Pfad ausgehend vom Executable mit \Doc\main.html zusammengesetzt.
-
Ja, so etwas in der Art
Lynx: Mist, das wollte ich als neues weltweit einzigartiges Feature nur gegen Aufpreis verkaufen!
Das ist ja mal schräg.
Edit: Hab es schon gefunden, kann allerdings grade keine neue WIP hochladen.
-
Werden Fliegenpatschen verteilt?
Oder muss man selbst welche mitbringen? (Also Fliegenpatschen, Fliegen bringe ich aber auch gerne mit)
-
Alternativ könntest du auch die Post-Build-Events verwenden. Nachdem das vollständige .prg vorliegt, zerpflückst du das. Das geht mit diversen regulären Tools, aber zur Not auch mit dem $(MediaTool), da kann man auch binär-Dateien bearbeiten.
-
Uffz, hier mal die VIC20-Teile.
-
Und der Code ist mittlerweile aufgesplittet in 23 ASM-Dateien.
Arbeitest du mit dem C64Studio?
Wenn ja, würde mich interessieren wie lange ein kompletter Build bei dir dauert?
Ich warte bei mir aktuell gefühlt ca. 10 Sekunden von Tastendruck bis sich der Vice zeigt.
ist es tatsächlich die Assemblierung die so lange dauert, oder der Aufruf von Vice? Imho sind die neueren Vice-Versionen ziemlich zäh beim anstarten. Mit ein Grund, dass ich immer noch hauptsächlich mit vice 2.4 arbeite.
Aber ich sehe mir das gerne mal an, was ich performancetechnisch machen kann. -
Ich bastle auch gerade an so einem Kampfspiel. Für die Bewegungen habe ich mir eine Art Scripting gebastelt. Das beinhaltet Sprite-Verschiebungen, Sprite-Muster, Veränderung der HitBox, Ausführung des Treffe-ich-einen-Gegner-Codes, alles mit definierbaren Pausen dazwischen. Wenn man das hat, kann man da recht einfach neue Moves dazubauen, oder an den vorhandenen feilen.
Die passende Auswahl, welchen Move ein Gegner ausführen sollen habe ich noch nicht wirklich. Da muss IMHO die Hauptarbeit rein. Wie weit bin ich vom Wunschziel entfernt, sehe ich in die richtige Richtung, welche Moves kann ich jetzt gerade anbringen, wo hin muss ich mich bewegen um Move Y anzubringen. Das hat es alles in sich. -
Ah, ja, die Größe ist getrennt vom Modus. Ist ein bisschen eigenwillig. Die 40x25 kommen vom Default-Modus, der ist nun mal C64 40x25.
Ich ändere die Größe nicht, weil die Bildschirmdaten nicht durchs Ändern des Modus gelöscht werden sollten.Es schwebt mir schon länger im Kopf herum, dass man bei einem Projekt evtl. das Zielsystem angibt, und dann fangen die diversen Editoren mit passenden Voreinstellungen an. Dann denke ich immer, was, wenn man da mischen möchte, dann muss man ja .. Eichhörnchen!
-
Ach ja, jedes Sprite kann seine eigene 15-Farb-Palette mit sich bringen
-
Wenn man die Spritegröße 16x21 wählt, 16 Farben.
Aufpassen, eine Farbe ist die durchsichtige, also eigentlich stehen nur 15 zur Verfügung
-
Ich möchte als potentielle Spielerfigur Rumble McSkirmish und als Gegner Dr. Karate haben!
-
TD1334 hat völlig recht, Fehler darf man nicht einfach verschlucken. In der neuen WIP-Version kann man a) auch absolute Pfade verwenden und b), klappt das Schreiben nicht, gibt es eine entsprechende Meldung.
-
Wenn man beim Programmieren nicht ab und zu den AHA-Effekt hat, bzw. den hier, dann ist es kein richtiges Programmieren
Wobei da des öfteren noch ein dritter dazu kommt: "Das hätte nie funktionieren dürfen!"
-
Oh, da habe ich nicht vorgesehen, dass man absolute Pfade angibt. Guck mal in die "Compiler Messages", da steht der vollständige Pfad. Der sieht vermutlich so aus <Dein Pfad zur Datei>\n:\daten\....
-
So, das mit den Breakpoints scheint jetzt so zu klappen. Unterwegs bin ich auf einen dämlichen Bug gestossen, der jeden Breakpoint x-fach eingetragen hat, wobei x die Anzahl der Assembler-Dateien in einem Projekt war (fragt nicht).
Der Titel im FileManager wird jetzt auch gesetzt.
Neue WIP-Version!
-
Display More
Ich hätte auch noch einen.
Geht wieder mal um Breakpoints.
Wenn ich in der Zeile mit dem Breakpoint stehe
Wenn ich am Anfang der Zeile stehen und Enter drücke rutsch der Breakpoint mit. Das passt.
Wenn ich ab nach dem ersten Zeichen stehen oder auch am Ende der Zeile und dann Enter drücke, bleibt der Teil vor dem Cursor stehen, ein möglicher Rest der Zeile rutscht in die nächste Zeile und der Breakpoint mit.
Schön wäre es in dem Fall das der Breakpoint nur dann mitgeht wenn man am Anfang der Zeile steht, ansonsten sollte der BP stehen bleiben.
Das klingt so einfach, hat es aber in sich
Das direkt einzubauen ist simpel, wenn es aber ans Undo geht, wird es knifflig. Beim Source-Editor gibt es Undo nur für die Textbox. Das Verschieben der Breakpoints wird da indirekt über Events gelöst. Da muss ich mich mal reingraben, ob man das anhand eines Undos erkennt, ob ein Breakpoint am oberen Ende nach oben rutschen muss, oder bleiben kann, wo er ist.
-
Danke, das hat geholfen! Da hätte ich lange suchen können. Ich lasse das immer im Debug-Modus laufen, und der Fehler tritt aber nur im Release-Build auf
Neue WIP-Version, danke für die Info!
