Mephisztoe Zurückspulen ist nur mit den Events schwierig, sofern in denen nicht auch der State (Figurpositionen, Animationsphasen etc.) drin ist. Was man meist recht einfach machen kann, ist, zum Debugging alle Spielobjekte serialisierbar zu machen und für jedes Frame den kompletten Zustand abzuspeichern.
Beiträge von 1570
-
-
Ich kämpfe ja auch immer mit meinem Drucker.
Wenn ich mir das so ansehe:
Bitte melde dich an, um diesen Anhang zu sehen.
Drückt sich Deine Nozzle in das PLA.
Das war bei/wegen Herumspielen mit dem Extrusionsfaktor...
-
Auf dem Bild sehen die Perimeter weitgehend okay aus und die Flächen auch. Da würde ich nicht davon ausgehen, dass der Z-Offset das Problem ist. Wenn Du den jetzt niedriger einstellst, werden die Löcher zwar etwas kleiner, aber dafür schiebt der Druckkopf dann Masse durch die Gegend und macht alles andere damit unsauber vermutlich. Probier's gerne aus, dann siehst's ja selbst.
Das sieht wie gesagt nach einem Problem mit Pressure Advance aus. Ist da vielleicht irgendwas mit M572 im Setup-GCode schon (falsch) eingegeben?
Wobei falsches Pressure Advance mit (deutlich) langsamerer Druckgeschwindigkeit bzw. geringer Beschleunigung unproblematisch sein sollte, das könnte man ggf. als Workaround runtersetzen.
-
Im Anhang fehlt auch ein großer Teil des zweiten Perimeters einfach. Das hat dann mit Overlap o.ä. nichts zu tun, sondern ist ein Problem des Extruders/Filaments.
Ansonsten:
- Bilder von der Unterseite des Drucks bringen wenig und verwirren eher. Es interessiert die OBERSEITE, weil man dort sehen kann, ob der Druckkopf z.B. Furchen zieht. Auf der Unterseite sieht man nur die Struktur des Druckbetts.
- Viele Deiner Fotos sind unscharf. Besseres Licht nehmen und Entfernung zum Objekt beim Fotografieren variieren (ggf. auch von ein paar cm weiter weg probieren).
- Für mich sehen die Flächen an sich soweit gut aus. Extrusionsfaktor ist dann eigentlich als Fehlerquelle raus.
-
Das gehört so.
Mit einer guten Makroaufnahme des gedruckten Teils von der Druckseite (nicht der von der Build Plate texturierten Unterseite) her könnte man evtl. auch mehr sagen.
Aber letztendlich kann man da mit nur einem Layer vermutlich nicht zaubern. Ggf. einfach mit einem 200°C-Lötkolben etwas nacharbeiten...
-
Bisschen mehr Overlap und ggf. "Concentric" als Top Fill Pattern.
Ein Problem wird da auch sein, dass der Druckkopf zum Rand hin abbremst/beschleunigt und der Massefluss aus dem Hotend raus minimal zeitlich verzögert zu den Bewegungen des Extruders erfolgt (weil sich erst der Druck des verflüssigten Filaments im Hotend aufbauen muss). D.h. bei Beschleunigung wird unkorrigiert tendenziell zu wenig Material aufgebracht, beim Abbremsen zu viel. Korrigiert werden kann das mit "Pressure Advance", kann man manchmal im Slicer einstellen, manchmal in der Firmware des Druckers, richtig gut kann das glaube ich nur Klipper, aber Prusa hat wohl auch sowas: Bitte melde dich an, um diesen Link zu sehen.
-
Wenn man Linux auf dem 6510 zum Laufen bringen würde, bzw. überhaupt könnte ... dann wär's interessant.
Genau darum geht doch dieser Thread, siehe erstes Posting. Läuft! Halt noch verpackt in einen RISC-V-Emulator und braucht eine RAM-Erweiterung.
Viel mehr als das wird's vermutlich auch nicht mehr. Vielleicht könnte man noch eine Art JIT-Compiler für RISC-V basteln (statt Interpreter) und den Speicherzugriff irgendwie optimieren (Paging/Ultimax-basierte RAM-Erweiterung vielleicht?). Dann braucht Linux halt nur noch einen Tag zum Booten statt einer Woche...

LNG ist sicher ganz nett, hat aber mit Unix/Linux fast nichts zu tun, so wie's aussieht, außer etwas "Inspiration". Anders wird man aber auch nichts Praktikables auf dem C64 hinbekommen.
-
Sieht Bitte melde dich an, um diesen Link zu sehen. ziemlich ähnlich. Das war mächtig viel für rund 8kB, wenn ich mich recht erinnere.

-
Tatsächlich ist COMAL damals sogar ein Blick in die Zukunft gewesen.
Ja so aus programmiersprachen-archäologischer Sicht her ist Comal sicher spannend. Vielleicht mag jemand auch noch etwas zu Bitte melde dich an, um diesen Link zu sehen. beitragen.
-
Der einzige Nachteil von COMAL ist, dass man ein COMAL-Modul benötigt.
Und schwupps sind die anderen Nachteile unter den Teppich gekehrt und die niedrige Geschwindigkeit ganz ignoriert. Aber gut, der Rest Deines Postings stimmt.
ZitatDas hat dann aber keine Ähnlichkeiten mehr zu BASIC.
Das war doch in dem Thread hier gar nicht gefordert.
Naja, ich denke, das Thema ist durch? Der OP schaut sich ja u.a. TRSE an, damit kann man wirklich eine Menge reißen, wie man an den Demos sieht, und das zugrundeliegende Pascal ist auch recht elegant und trotzdem einsteigerfreundlich (und in Form von FreePascal auch z.B. für PC verfügbar, bzw. TRSE kann wohl auch direkt x86).
-
Das ist doch völliger Unsinn. Man kann sowohl mit BASIC als auch mit COMAL viele interessante Spielkonzepte realisieren.
[...]
Und für Anwendungsprogramme ist COMAL sowieso prädestiniert, denn genau dafür wurde es erschaffen.
Klar, man kann damit vieles machen; was halt mit der zwar etwas schnelleren Geschwindigkeit als unkompiliertem BASIC V2 aber deutlich langsameren Geschwindigkeit als allem anderen
geht und was in die gerade mal rund 10k (oder 30k, wenn man ein Modul voraussetzt) passt. -
...hobbymäßig mit interpretierten (Hoch-)sprachen auf dem C64? Und COMAL scheint mir ein interessantes "Forschungsobjekt" zu sein. - Ist das so verkehrt?
Nö. Deswegen ja auch meine erste Frage aus Posting Bitte melde dich an, um diesen Link zu sehen.. Aber wenn hier Anwendungs- und insbesondere Spieleprogrammierung als grundlegende Motivation im Thread genannt werden, ist Comal raus, sofern man nicht nur Tic Tac Toe programmieren oder wesentliche Teile mit Assembler-Helpern o.ä. schreiben will.
Nochmal zum Thema, "Zoo Mania" war auch mehr oder weniger hier im Forum entstanden, schon etwas länger her, mit cc65 umgesetzt: Bitte melde dich an, um diesen Link zu sehen.
-
Ad Hominem ist nicht so cool.
Tatsächlich fänd ich es prima, wenn Du mit Deinem Durchhaltevermögen und auch Gespür für Spieledesign ein Toolset wählen würdest, das Dir nicht ständig Steine in den Weg legt. Da würde bestimmt noch weit Tolleres bei rauskommen als bisher, was alles doch recht stark von technischen Einschränkungen geprägt war.
-
Omega Also eigentlich hast Du so lange rumgenörgelt, bis andere Leute wesentliche Teile Deiner Projekte in Assembler umgesetzt haben

-
Omega Dein Comal-Thread ist von Februar 2025, was war doch gleich bis kurz davor laut Dir das Beste seit geschnitten Brot?

-
Danke für die vielen Rückmeldungen. Angedacht hatte ich, ein Spiel oder auch eine nützliche Anwendung zu schreiben. Genaues habe ich noch nicht geplant. Mit BASIC kommt man teilweise schon recht schnell an die Grenzen.
COMAL verschiebt sicher die Grenzen etwas und erlaubt es, halbwegs strukturiert zu programmieren, aber es bleibt eine interpretierte recht starre Inselsprache. Interpretiert=langsam, starr=keine Flexibilität was z.B. Speicherlayout angeht, Inselsprache=keine Verbreitung.
Für Spiele bietet sich Assembler oder was Kompiliertes an (TRSE Bitte melde dich an, um diesen Link zu sehen. oder Bitte melde dich an, um diesen Link zu sehen. zum Beispiel).
-
Ne, im Monitor ist ja PETSCII nicht so die ideale Wahl...
Für M und SCR etc. will man im Monitor ja durchaus (auch) PETSCII haben...
-
Vermutlich wird der PETSCII-Font nicht richtig geladen, schau mal in die Logs, es gibt auch ein paar Kommandozeilenoptionen zu.
-
Lohnt es, sich damit zu beschäftigen?
Was ist denn Dein Ziel? Ein bisschen Retro zu machen? Anwendungen zu schreiben? Spiele zu schreiben? Was zu lernen, was auch abseits des C64 einsetzbar ist?
-
Das ist jetzt aber ein anderes Fehlerbild, oder? Die Bildschirmausgabe an sich ist sieht ja okay aus. Was sagt Bitte melde dich an, um diesen Link zu sehen. ? Das Problem beim Destest ist, dass man nicht genau weiß, wie der funktioniert/was er genau testet; das Problem beim alten Dead Test ist, dass ihm einige wichtige Tests fehlen.