Langsam muss ich mir was überlegen, wie ich GUI-Tests automatisiert kriege.
Und wo bleiben dann für uns die Überraschungen und der Spaß?
You are about to leave Forum64 to get redirected to the following address:
Please note, that the target website is not operated by us. We are not responsible for it's content nor does our privacy policy apply there.
Langsam muss ich mir was überlegen, wie ich GUI-Tests automatisiert kriege.
Und wo bleiben dann für uns die Überraschungen und der Spaß?
Hi Endurion,
ich weis nicht ob das jetzt ein Bug ist. Aber mir ist schon des öfferten aufgefallen wenn ich Sprites in Datazeile exportiere, das er immer eine Zahl zuviel macht.
Hier mal die Bilder dazu
Bild 01 - Sprite gezeichnet
Wir merken uns die letzten 8 Bit des Sprites, die sollen als Dez. Null ergeben
So hier das Exportergebnis für Datazeilen:
So wenn wir uns jetzt die letzten 4 Zahlen der Zeile 9100 anschauen, sehen wir dort 0,62,0,5
Und wenn wenn ich das jetzt das mit mein Sprite vergleiche (letzte Reihe)
dann stimmt die Zahl 0 (1. 8 Bit-Reihe)
die Zahl 62 (2. 8 Bit-Reihe)
die Zahl 0 (3. 8 Bit-Reihe)
aber wo jetzt die Zahl 5 herkommt weis icht nicht.
Gut es ist jetzt kein Beinbruch die Zahl 5 aus der Data Reihe zu entfernen. Aber die Frage ist doch, macht er das nach jedem Sprite wenn man mehrere hat, oder nur beim letzten Sprite.
Gruß Drachen
aber wo jetzt die Zahl 5 herkommt weis icht nicht.
Wird ein Füllbyte sein, damit du immer 64 DATA-Werte pro Sprite hast. Auf diese Weise kannst du bei mehreren Sprites alle Daten über eine große FOR-NEXT-Schleife einlesen.
Andererseits könnte es auch einfach ein Versehen sein. So oder so wäre vielleicht ein Feld "Insert extra Byte" (oder so) angezeigt.
Im letzten Byte wird oft die Spritefarbe gespeichert.
Im letzten Byte wird oft die Spritefarbe gespeichert.
Jupp, das isses!
Aus der Anleitung:
QuoteGenerally: Since sprites only use 63 bytes a fill byte is written after the sprite data containing the sprites custom color.
Ah, ein selbst-lösendes Problem. Finde ich gut
Eine Option wäre aber evtl. doch nicht schlecht, manchmal ist ein Byte schon eins zu viel.
Hallo,
ich hab etwas mit dem Debug-Mode mit Maschinensprache zu kämpfen.
Und zwar hab ich den Eindruck, dass der Debug-Modus in Vice nicht immer richtig anspringt.
Ich habe eine asm Datei (Haupt-Datei), welche mit !source Direktive weitere asm Dateien einbindet.
Breakpoints in der Haupt-Datei (die ich auch vom Studio aus mit "Build and Debug ausführe"), werden meist richtig erkannt und das Studio geht in den Debug-Modus.
Zwar wird die aktuelle Zeile nicht immer richtig hervorgehoben (bloß der Cursor blinkt darin), aber man kann sich ja mit dem PC in der Registeranzeige helfen.
Breakpoints in den !source Dateien werden aber eigentlich nie angesprungen.
Der Vice bleibt aber trotzdem in einem Zustand hängen, wo er keine Eingaben akzeptiert. Auch kein Monitor kann aktiviert werden.
Drücke ich dann im C64-Studio auf "Play", macht Vice weiter - aber dort, wo die Breakpoints schon vorbei sind.
In der Register-Anzeige bleiben in diesem Zustand alle Felder leer. Aber gestoppt ist trotzdem alles irgendwie.
Aufgesetzt ist das im Studio als Projekt bzw Solution.
Ich habe aber keine Pfade oder sonstiges definiert (wenn ich das mache, startet der Vice übrigens garnicht korrekt sondern bleibt beim Starten schon irgendwie komisch hängen).
Das ganze läuft auf Windows, ich habs mit Vice 3.7.1 und 3.8 GTK probiert.
C64Studio hab ich soeben auf 7.9.95 aktualisiert.
Ich muss wohl irgendwo was falsch eingerichtet haben, sonst würden ja alle dieses Problem haben...
Danke für jeden Input
Ich muss wohl irgendwo was falsch eingerichtet haben, sonst würden ja alle dieses Problem haben...
Poste doch mal ein Bild der Einstellungen unter Preferences -> Emulators/Tools.
Ich denke das könnte Endurion schon helfen. Vielleicht auch noch die Ausgabe unter Output, da sieht man wie der Vice gestartet wurde.
Sehr gern
In den Properties der Assembler-Dateien wird C64-Studio als Assembler erkannt.
Ich halte mich grundsätzlich an die ACME Syntax, sollte ich das umstellen?
Hier noch der Console-Output
Ich habe nun das gesamte Projekt und die gesamte Solution nochmal neu angelegt, jetzt funktioniert es.
Da waren ein paar Dateien im Projekt mit drin, die außerhalb der Projekt/Solution Ordner gelegen hatten.
Die dürften das ganze irgendwie durcheinander gebracht haben.
Jetzt funktioniert das Debugging soweit wieder mal normal.
Ich werde das genau weiter beobachten, um vielleicht Rückschlüsse ziehen zu können, wo das Übel seinen Ursprung nahm (wenn wir mal davon ausgehen, dass ich im Lauf der Zeit den selben Blödsinn nochmal mache )
Hmm, da ist irgendwas im Argen. Mit einem ganz simplen Beispiel klappt es bei mir, aber bei einem komplexeren Programm habe ich ähnliche Effekte.
Der initiale Breakpoint wird angesprungen, die Breakpoints werden umgebaut, aber VICE macht hinterrücks bereits weiter, und flutscht dann über den neuen Breakpoint drüber, bevor er vollständig registriert ist. Hatte ich jetzt sowohl mit VICE 3.5, als auch GTK 3.8. Ich muss mal gucken, ob ich da überhaupt was machen kann. Wenn VICE beim Break nicht stehen bleibt, habe ich kaum eine Chance.
Wo es problemlos klappte, war x128 aus VICE 2.4.
Bei mir habe ich selten mal das Problem, wenn ich debuggen will, das Vice startet und dann direkt noch das Fenster vom Vice-Monitor mit aufgeht. Klicke ich das weg läuft Vice weiter, aber Breakpoints funktionieren dann nicht.
Wo es problemlos klappte, war x128 aus VICE 2.4.
Danke, das werd ich gleich mal ausprobieren
Was ich nicht so dufte finde: Wenn ich C64 Studio minimiere und dann wieder durch einen Klick in die Taskleiste restore, wird der Mauszeiger in das Find/Replace-Fenster gesetzt. Kann ich das abstellen, ist das gewollt oder ein Bug?
Huch, sowas mache ich nicht. Ich reagiere nicht auf das Event, auf jeden Fall nicht absichtlich. Bei mir bleibt der Fokus auf dem zuletzt aktiven Element (Sourcecode, oder irgendein anderes Eingabefeld)
Hast du irgendein Tool, das dir den Mauszeiger auf das Element mit dem Fokus setzt?
Was ich nicht so dufte finde: Wenn ich C64 Studio minimiere und dann wieder durch einen Klick in die Taskleiste restore, wird der Mauszeiger in das Find/Replace-Fenster gesetzt. Kann ich das abstellen, ist das gewollt oder ein Bug?
Kann ich bei mir so nicht nachstellen. Wenn ich den Fokus auf das finden/ersetzen Fenster hatte, dann ist der nach dem Restore wieder da drin aber mein Mauszeiger bleibt in der Taskleiste.
Hast du eventuell eine Software drauf die beim Fenster aktivieren den Mauszeiger versetzt? ich kannte sowas von früher mal. Da sprang der Mauszeiger nu hin und her wenn man Fenster aufmachte, hervorholte usw.
Edit: Endurion war schneller
Ich weiss nicht ob ich jetzt irgendwie falsch liege.
der Pseudobefehl !to funktioniert doch folgerndermassen
!to "name",cbm müsste mir nach dem build eine Datei mit "name.prg" erstellen, oder?
Bei mir kommt da eine Datei welche "b" heisst. Das b kommt von cbm. Setze ich da "plain" dran, dann erhalte ich eine Datei die "l" heisst.
Hast du eine Idee woran das liegen könnte?
Edit: Version vom Studio ist 7.9.105
Es passiert sogar schon beim Start von C64 Studio - ganz ohne FInd/Replace-Fenster. Der Cursor wird irgendwo am rechten Rand platziert. Echt merkwürdig.
Hast du irgendein Tool, das dir den Mauszeiger auf das Element mit dem Fokus setzt?
Müsste ich ja, aber ich wüsste nicht, welches das sein sollte.
Auch merkwürdig: Ich habe gerade die neueste WIP-Version herunter geladen. Ganz oben in meiner Main-Datei habe ich stehen
Wenn ich dann aber assembliere, heißt die Datei im D64 einfach nur "6(.prg)".
Hier die ersten Zeilen des Output:
Die Datei GUI64.d64 wird auch nicht geändert. Stattdessen wird eine Datei namens "6" (ohne Endung) im Ordner angelegt.
Auch merkwürdig: Ich habe gerade die neueste WIP-Version herunter geladen. Ganz oben in meiner Main-Datei habe ich stehen
Wenn ich dann aber assembliere, heißt die Datei im D64 einfach nur "6(.prg)".
Hier die ersten Zeilen des Output:
Die Datei GUI64.d64 wird auch nicht geändert. Stattdessen wird eine Datei namens "6" (ohne Endung) im Ordner angelegt.
Ich weiß jetzt nicht, ob Du da schon irgendwas über die Bedingungen geschrieben hattest, ich finde zumindest auf Anhieb nichts, kann das aber nicht nachstellen. Bei mir wird es einwandfrei in das D64 mit dem angegebenen Namen kopiliert.