Hmm sind die Gegner in einem separaten Array? Kann man die nicht genauso wie die Steine usw behandeln? Letztendlich sind doch alle Elemente immer nur auf einem Feld und reagieren nach bestimmten Regeln mit den umgebenden Feldern... egal ob nun Stein, Diamant, Gegner, etc
Basic Mega65 - Boulder Dash
-
Drachen -
March 24, 2022 at 8:38 PM -
Thread is Resolved
There are 413 replies in this Thread which has previously been viewed 79,693 times. The latest Post (
-
-
Kann sein, dass ich dich hier jetzt nicht korrekt verstanden habe, aber ich denke, das da mit BASIC 65 geht zumindest in diese Richtung.
Danke. Please login to see this link. ist schnell, ja, aber ein gruseliger Hack: EDMA kopiert einfach hart Speicher durch die Gegend und ist eher mit PEEK und POKE zu vergleichen als einem vernünftigen Hochsprachebefehl. Insbesondere bekommt man den Rechner damit ggf. sehr schnell zum Absturz, was bei "echten" BASIC-Befehlen niemals möglich sein sollte. Und der Befehl ist auch nicht portabel, da er ein bestimmtes Speicher-Layout voraussetzt.
-
Danke. Please login to see this link. ist schnell, ja, aber ein gruseliger Hack: EDMA kopiert einfach hart Speicher durch die Gegend und ist eher mit PEEK und POKE zu vergleichen als einem vernünftigen Hochsprachebefehl. Insbesondere bekommt man den Rechner damit ggf. sehr schnell zum Absturz, was bei "echten" BASIC-Befehlen niemals möglich sein sollte. Und der Befehl ist auch nicht portabel, da er ein bestimmtes Speicher-Layout voraussetzt.
Gut, unter solchen Bedingungen müssten als Erstes POKE, DMA und EDMA aus dem Befehlssatz von BASIC 65 verbannt werden, bevor wir hier überhaupt weiterreden können!
-
Na so war das offensichtlich nicht gemeint. Wenn man BASIC im ursprünglichen Sinne erweitern und schnell machen will, muss man aber schöne flexible (speicher-)sichere Befehle hinzufügen - eben so wie den von mir vorgeschlagenen Befehl zum Ansprechen des Bildschirminhalts, der schnell und flexibel größere Mengen Daten aus Arrays auf den Bildschirm kopieren kann. Sowas wie EDMA dagegen ist eigentlich immer nur "komfortabler" Ersatz für ein paar POKEs (ich gehe mal davon aus, dass man die DMA-Engine auch per POKE anwerfen kann) und ganz sicher nicht im Sinne dessen, was BASIC mal sein wollte.
(letzter Beitrag von mir zum Thema, da ich diesen Thread nicht weiter stören will)
-
Wenn man BASIC im ursprünglichen Sinne erweitern und schnell machen will, muss man aber schöne flexible (speicher-)sichere Befehle hinzufügen - eben so wie den von mir vorgeschlagenen Befehl zum Ansprechen des Bildschirminhalts, der schnell und flexibel größere Mengen Daten aus Arrays auf den Bildschirm kopieren kann.
Da bin ich 100% bei dir! Wenn schon neue Befehle, dann diese auch sicher und flexibel implementieren.
Ich finde deinen Vorschlag auf alle Fälle interessant und gut. Mal schauen, was sich hier noch tut.
-
Hmm sind die Gegner in einem separaten Array? Kann man die nicht genauso wie die Steine usw behandeln? Letztendlich sind doch alle Elemente immer nur auf einem Feld und reagieren nach bestimmten Regeln mit den umgebenden Feldern... egal ob nun Stein, Diamant, Gegner, etc
Ja du hast recht, alle Gegner und Element wo im Spiel wichtig sind, sind in einen Array gespeichert. Das Problem das ich in Moment damit habe ist, wenn ich ein Objekt lösche, müsste ich das Array von Objekt auch korrikieren.
Nur weis ich leider nie um welchen Index vom Array es ist. Damit ich den letzten Index vom Array dorthin kopieren kann und den Index dann um eins vermindere.
Nun gehe ich her und lösche alle Arrys des Objektes und scanne dann das Spielfeld einfach neu ein. So hoffe ich das ich die doppelt Einträge eliminieren.
Und ich hoffe das das nicht sooooooooooviel Zeit frist.
-
okay aber gibt es dafür einen Grund, dass die Objekte in einem separaten Array liegen? müsste die Engine nicht auch so funktionieren dass alles, egal ob Sand, Stein, Gegner etc ganz einfach ein Element des Spielfeldes ist?
-
okay aber gibt es dafür einen Grund, dass die Objekte in einem separaten Array liegen? müsste die Engine nicht auch so funktionieren dass alles, egal ob Sand, Stein, Gegner etc ganz einfach ein Element des Spielfeldes ist?
Das hatte ich ganz am Anfang gehabt. Das gesamte Spielfeld in einen Array. Das einlesen des Spielfeldes hat ziemlich lange gedauert. Danmals wollte ich schon aufgeben, weil alles so langsam war, trotz der 40 Mhz.
Aber dann haben TheRealWanderer und Acron mir ihre Engine vorgestellt, die um einiges schneller waren als meine Engine.
Und mit der seperraten Arrays lässt es für mich besser händeln. Man braucht nicht mehr das komplette Spielfeld als Array abspeichern, sondern nur die Sachen wo im Spiel wichtigt ist. Somit hat man eine höhere Geschwindigkeit beim einlesen.
Da die Engine im Grunde ja nur den Butterfly, Firerfly, Steine, und Diamanten in Arrays speichert.
Ich hoffe ich konnte das gut rüberbringen. Im Erklären bin ich eine Niete.
-
Ah ok ja verstehe
hab den Thread bzw die Entwicklung irgendwann nicht mehr so genau verfolgt -
Bei TheRealWanderer Ansatz werden nur die aktiven Objekte verwaltet. Durch das Aufteilen in mehrere Array braucht man nur die Position der Objekte, zu speichern.
In der Hauptschleife wird je ein Element pro Array bearbeitet. Sobald ein Array komplett bearbeitet ist, wird sofort wieder mit dem erste begonnen, deshalb werden auch die Objekte unterschiedlich schnell bewegt. Um das zu verhindern, müsste man für die kürzeren Array einen Mittelwert berechnen, damit alle gleich schnell abgearbeitet werden.
-
- Official Post
Bei TheRealWanderer Ansatz werden nur die aktiven Objekte verwaltet. Durch das Aufteilen in mehrere Array braucht man nur die Position der Objekte, zu speichern.
In der Hauptschleife wird je ein Element pro Array bearbeitet. Sobald ein Array komplett bearbeitet ist, wird sofort wieder mit dem erste begonnen, deshalb werden auch die Objekte unterschiedlich schnell bewegt. Um das zu verhindern, müsste man für die kürzeren Array einen Mittelwert berechnen, damit alle gleich schnell abgearbeitet werden.
So ist es.
Ich denke, der beste(?) Ansatz dafür, das der Geschwindigkeitsunterschied nicht so gravierend ist, ist, dass der bereits von Jedi04 eingebaute Verzögerungszähler in Abhängigkeit von einem Referenzwert abzgl. der Arraygröße bzw. -dimensionierung modifiziert wird.
Beispiel:
bisher:
3135 Z1=Z1+1
3140 IF Z1=6 THEN FZ=FZ-1:Z1=0:GOSUB7000
neu:
3140 IF Z1>INT(24/(ZF+1)) THEN FZ=FZ-1:Z1=0:GOSUB7000
ZF ist die Arraydimensionierung für die Fireflys, also bei 4 Fireflys ZF=3 (Zählung ab 0, ZF+1 ist wegen Div/0). Referenzwert = 24 (muss man mal genauer prüfen, was da passt, evtl. die Anzahl der am meisten vorkommenden Objekte?) . Verzögerung = 24:4=6. Somit wird jeden 6. Durchlauf wird eine andere Firefly bewegt, also alle 4 in insgesamt 24 Durchläufen.
Falls ZF=0 ist, wird jeden 24. Durchlauf ein Firefly bewegt. damit sollte die Geschwindigkeit immer recht gleich sein, egal, wie viele von den Objekten vorhanden sind.
Das könnte man für andere Objekte dann auch so machen, wenn das funktioniert.
Ist jetzt erstmal nur so ein Gedankenspiel...
-
Display More
Bei TheRealWanderer Ansatz werden nur die aktiven Objekte verwaltet. Durch das Aufteilen in mehrere Array braucht man nur die Position der Objekte, zu speichern.
In der Hauptschleife wird je ein Element pro Array bearbeitet. Sobald ein Array komplett bearbeitet ist, wird sofort wieder mit dem erste begonnen, deshalb werden auch die Objekte unterschiedlich schnell bewegt. Um das zu verhindern, müsste man für die kürzeren Array einen Mittelwert berechnen, damit alle gleich schnell abgearbeitet werden.
So ist es.
Ich denke, der beste(?) Ansatz dafür, das der Geschwindigkeitsunterschied nicht so gravierend ist, ist, dass der bereits von Jedi04 eingebaute Verzögerungszähler in Abhängigkeit von einem Referenzwert abzgl. der Arraygröße bzw. -dimensionierung modifiziert wird.
Beispiel:
bisher:
3135 Z1=Z1+1
3140 IF Z1=6 THEN FZ=FZ-1:Z1=0:GOSUB7000
neu:
3140 IF Z1>INT(24/(ZF+1)) THEN FZ=FZ-1:Z1=0:GOSUB7000
ZF ist die Arraydimensionierung für die Fireflys, also bei 4 Fireflys ZF=3 (Zählung ab 0, ZF+1 ist wegen Div/0). Referenzwert = 24 (muss man mal genauer prüfen, was da passt, evtl. die Anzahl der am meisten vorkommenden Objekte?) . Verzögerung = 24:4=6. Somit wird jeden 6. Durchlauf wird eine andere Firefly bewegt, also alle 4 in insgesamt 24 Durchläufen.
Falls ZF=0 ist, wird jeden 24. Durchlauf ein Firefly bewegt. damit sollte die Geschwindigkeit immer recht gleich sein, egal, wie viele von den Objekten vorhanden sind.
Das könnte man für andere Objekte dann auch so machen, wenn das funktioniert.
Ist jetzt erstmal nur so ein Gedankenspiel...
OK das werde ich in laufe der Woche mal testen. Hört sich sehr gut an.
-
- Official Post
- Interesting post
Hier mal ein Video vom aktuellen Stand von Drachen s BoulderDash. Es nimmt Form an
Leider ist die Qualität des Videos nicht so dolle geworden...
Please login to see this media element.
-
Hier mal ein Video vom aktuellen Stand von Jedi04 s BoulderDash. Es nimmt Form an
Wow, das schaut schon wirklich gut aus!
Jetzt noch ein Karton drumrum und ab ins Verkaufsregal!
-
Hier mal ein Video vom aktuellen Stand von dragon s BoulderDash.
Da meinst du bestimmt jemand anderen. Mein bestellter Mega65 liegt leider noch bei Trenz... und mit Programmieren habe ich leider nichts am Hut.
-
Hier mal ein Video vom aktuellen Stand von dragon s BoulderDash.
Da meinst du bestimmt jemand anderen. Mein bestellter Mega65 liegt leider noch bei Trenz...
Er meinte Drachen , kann man schonmal durcheinander kommen.
-
- Official Post
Uppps, stimmt, Schande über mich
-
Hier mal ein Video vom aktuellen Stand von Drachen s BoulderDash. Es nimmt Form an
Leider ist die Qualität des Videos nicht so dolle geworden...
Please login to see this media element.
Na, an diesen Projekt bin ich ja nicht alleine. Da ist TheRealWanderer und Acron auch mit dabei. Von TheRealWanderer stand die Hauptengine und von Acron die Aufbauroutine der Levels.
Also es ist ein Gemeinschaftsprojekt. Und meiner einer, bastelt das dann einwenig zusammen.
Aber es gefällt mir bis jetzt auch sehr gut. Jetzt fehlen noch ein paar Kleinigkeiten und das Basic Game ist komplett.
Ach ja die Musik habe ich auch schon, die hat Please login to see this link. beigesteuert von Post #166. Was ich großartig fand.
Wie man sehen kann es ist ein Gemeinschaftsprojekt von Forum64.
-
Sieht echt schon richtig toll aus. Respekt!
-
Schaut schon super aus! Wahnsinn, was alles mit Basic geht - nicht auszudenken, wie das in Assembler wäre…
Ach ja, eines ist mir aufgefallen: die Steine fallen viel zu langsam. Normalerweise haben die dieselbe Geschwindigkeit wie die Figur selbst.
