Die Möglichkeiten in den Levels sind ja hier bei TT64 relativ komplex -Boulderdash ist da viel simpler-,
Das glaube ich aber nun nicht.
Es gibt 1.096 Antworten in diesem Thema, welches 187.971 mal aufgerufen wurde. Der letzte Beitrag (
Die Möglichkeiten in den Levels sind ja hier bei TT64 relativ komplex -Boulderdash ist da viel simpler-,
Das glaube ich aber nun nicht.
oder ich überschätze mich in meinem ASM-Optimierungfähigkeiten
Ich finde gut, dass Du im Gegensatz zu anderen auch zu Selbstkritik fähig bist. Arbeite noch ein wenig dran, auf Anregungen einzugehen und alles wird gut ![]()
@240: Doch sehr, oder guckt ihr nur auf die Grafik ? In TT64 gibt's scheinbar 'etliche' "Waffen", Items und intelligente Feinde (Gegnerprites), die erstmal alle je nach Level richtig eingebunden werden wollen. In Boulder Dash gibt's nur 'Erde', die verschwindet, sobald man mit dem Sprite drauf ist, Diamanten zum einsammeln (beides simpel und genau in der gleichen Art das zu programmieren) und Steine, die fallen sobald kein Erd oder Stein Char unter ihnen ist. Das war's bei Boulderdash, die Engine ist sehr simplel da. Ok, bis auf das noch vorhandene Scrolling.. aber wenn ich mich recht erinnere stoppt der Steinfall solabd bzw. so lange gescrollt wird (?), also ist auch das nicht soo komplex und vorstellbar. Boulderdash macht doch höchstens wegen seines manchmal intelligenten oder interessanten Leveldesigns so einen "komplexen" Eindruck.
Dafür habe ich mal fürs DTV eine Boulder-Dash-Version gebaut, die 360 (!) Level beinhaltet. Läuft auch als One-Filer auf einem normalen C64.
Äh, also, es gibt wohl so viele Funktionen, dass nicht alle gleichzeitig in den Speicher passen und daher nur die Funktionen geladen werden, die gerade im aktuellen Level verwendet werden? Oder wie soll man sich das vorstellen?
*kopfkratz*
Ansonsten befindet sich doch immer die komplette Game-Logik im Hauptprogramm und nur die Leveldaten werden nachgeladen, d.h. die Definition, welche Funktion wo im Level verwendet wird. Das kann doch nicht so schwer sein.
Zu viele Waffen,zu viele Funktionen etc.... das ist doch bullshit. Nichts von dem was man bisher sehen konnte ließe sich nicht komfortabel in einem onefiler unterbringen.
ich weise mal darauf hin, dass ich soeben einen Bitte melde dich an, um diesen Link zu sehen. von 15:15 gerade frei geschalten habe... ich hoffe ihr könnt damit mehr anfangen als ich.... ![]()
Der beitrag von Ace ist damit nun 241 und Komentar 243 bezieht sich eben auf diesen und nciht auf den 240er von Vernunftsmensch....
(ich hoffe damit sind alle Klarheiten beseitigt...
)
sl FXXS
Vorweg, ich find es immer noch gut das VM sich da so reinbeißt.
Trotzdem sehe ich an dem bisher gezeigten nicht ansatzweise einen Grund, etwas 'auslagern' bzw. nachladen zu müssen.
Auch die Fehlerhäufigkeit ist ein grundsätzliches Problem bei TT64.
Anstatt sich mal um die Sandbox samt drumherum zu kümmern, wird munter weiterverschlimmbessert ohne richtig vorwärts
zu kommen. Irgendwie gehts 2 Schritte vor, und direkt danach aber 3 zurück.
Bau dir EINEN Level, in dem du munter drauflos testen kannst. Bring dann dein Menü in Ordnung das man nicht JEDESMAL
das Game neu laden muß wenn mal was schief läuft. Fix endlich Tatstatur und Joystick Routienen und fang gefälligst verbotene
Tasten so ab, das TT64 NICHT abstürzt. Und, und, und.... Baustellen hast du imho genug. Fang vorne an.
Erst danach bau neue Level.
Brauchst du Hilfe, frag mich oder andere hier.
LG, duke
Insbesondere folgende würden mich mal intressieren.
Davon am meisten Kernalmanagement und Kompremierung
LG, duke
10 14 313 Ausgangsverwaltung.h
75 181 1813 Kernalmanagement.h
2 0 2 Kompremierung.h
886 1322 15843 select.h
872 1308 15764 select (Mit ordentlichem Menü).h
57 90 1080 Soundmanagement.h
5 10 245 Speicherverwaltung.h
Ich finde es echt gut, dass VM jetzt wirklich sich auch Ratschläge zu Herzen nimmt. Dafür ein dickes Lob von mir. Es gehört eine Menge dazu, Fehler einzugestehen und was verändern zu wollen. ![]()
In TT64 gibt's scheinbar 'etliche' "Waffen", Items und intelligente Feinde (Gegnerprites), die erstmal alle je nach Level richtig eingebunden werden wollen. In Boulder Dash gibt's nur 'Erde', die verschwindet, sobald man mit dem Sprite drauf ist, Diamanten zum einsammeln (beides simpel und genau in der gleichen Art das zu programmieren) und Steine, die fallen sobald kein Erd oder Stein Char unter ihnen ist. Das war's bei Boulderdash, die Engine ist sehr simplel da.
Diamanten unterscheiden sich von Erde ("dirt"), da sie ebenfalls fallen. Und selbst im allerersten Boulder Dash gibt es noch die Amöbe, Fireflies, Butterflies und Zaubermauern, die alle spezielle Behandlung erfordern.
Weiterhin sollten wir unterscheiden zwischen der Engine (d.h. dem Code, der all diese Funktionen bereitstellt) und den Levels (d.h. den Datenblöcken, anhand derer die Engine das aktuelle Spiel initialisiert).
Wenn man Vernunftmenschs Behauptung bedenkt, nicht einmal sauhund könne alle 107 Level in eine Datei stecken, scheint es so, als kenne Vernunftmensch den Unterschied zwischen Engine und Levels selbst nicht so richtig.
Bei den Leveldaten sehe ich keine allzugroßen Unterschiede; die TT-Engine jedoch dürfte tatsächlich ein Stück komplexer sein als die BD-Engine. In den Speicher des C64 sollte es dennoch reinpassen.
ZitatWeiterhin sollten wir unterscheiden zwischen der Engine (d.h. dem Code, der all diese Funktionen bereitstellt) und den Levels (d.h. den Datenblöcken, anhand derer die Engine das aktuelle Spiel initialisiert).
Ich unterscheide zwischen den Datenblöcken .tt64-Dateien mit auf der Diskette, die die Levels ausmachen. In diesen Dateien werden Vortexte definiert bishin zu den Daten, um ein Level als Video auf dem C64er vorzuführen.
Dem Initialisierungscode, der die Engine initialisiert - Die Engine weiß nicht mehr, daß sie ein bestimmtes Verhalten machen soll, weil es ein Biter z.B. ist, sie weiß nur, was sie zu machen hat - , den ich auslagern kann.
Dem Goattracker MusikTonDatenblock, den ich während des Spielens rein und rauslade, welcher übrigens auch vom Level ausgesucht wird, sprich das Level kann seine Musik aussuchen.
Und dem übrigen Code, der dann auch alle Variablen enthält.
Ich finde, daß ich das gut mache. ![]()
@VM: Lern endlich Assembler und hör mit C auf. Es kann doch nicht sein, dass dein bissle Spiel da nicht vollständig in den Speicher passt.
das liegt zumindest in dem fall hier aber nicht an C ![]()
Das glaube ich aber nun nicht.
TT64 is marginal komplexer. vielleicht. (eigentlich ist das einzig nicht triviale die sogenannte "blockphysik", der rest ist doch kaum der rede wert)
Zitat
TT64 is marginal komplexer. vielleicht. (eigentlich ist das einzig nicht triviale die sogenannte "blockphysik", der rest ist doch kaum der rede wert)
Sehe ich auch so. Immerhin ist quasi TrapThem ein BoulderDash-Clone. Eben allerding mit der revolutionär neuen Blockphysik, die sich J-Snake ausgedacht hat. Aber die eröffnet soviel Tiefgang, den das Tutorial nicht anspricht. Da sollen nur die Regeln erlernt werden. Wie bei BoulderDash kommt der Tiefgang durch lustige Level.
Äh, also, es gibt wohl so viele Funktionen, dass nicht alle gleichzeitig in den Speicher passen und daher nur die Funktionen geladen werden, die gerade im aktuellen Level verwendet werden? Oder wie soll man sich das vorstellen?
*kopfkratz*
Ansonsten befindet sich doch immer die komplette Game-Logik im Hauptprogramm und nur die Leveldaten werden nachgeladen, d.h. die Definition, welche Funktion wo im Level verwendet wird. Das kann doch nicht so schwer sein.
Das kenne ich von Pascal ("Prozeduren") aber beim C64 ? in Assembler.., weiß nicht ob das immer soo einfach umzusetzten ist/wäre, wie du es beschreibst.
Zu viele Waffen,zu viele Funktionen etc.... das ist doch bullshit. Nichts von dem was man bisher sehen konnte ließe sich nicht komfortabel in einem onefiler unterbringen.
War bisher ja noch nicht alles an Möglichkeiten zu sehen, nur einfache Anfangslevel(formen).
Eben. -Ich find das immer etwas lustig, wie immer wieder von manchen Vergleiche zu Topspielen von damaligen Top-Programmierern wie sie z.B. bei Activision waren gezogen werden..
.
Die Frage ist nur: Wer will denn "Weniger" spielen? Ich will ja auch nicht die Proberaumaufnahmen von Bernd B.'s Band hören, die sich vor 6 Monaten gegründet hat. Und wenn ich eine Demo code (
), werde ich an den Codern von Oxyron, Crest, Censor und wie se alle heißen, gemessen. Und? Wenn ich so 'nem Vergleich absolut nicht standhalten kann, laß ich's eben (mit der Veröffentlichung!). Das ist eine Einstellung, die vielen Leuten auch mal gut tun würde.
ZitatSpace Taxi hat auch seine Level nachgeladen und die Physik je Leveltyp angepasst, war da auch nicht nervig.
Space Taxi, Wizard, Below the Root etc laden (schnell) immer gleich große Blöcke nach, die lediglich grafische Daten zu enthalten scheinen. VM lädt, wenn ich das richtig verstanden habe, den jeweils benötigten Teil seiner 64 MB-Engine nach.
Das kenne ich von Pascal ("Prozeduren") aber beim C64 ? in Assembler.., weiß nicht ob das immer soo einfach umzusetzten ist/wäre, wie du es beschreibst.
natürlich ist es das. jedes halbwechs sinnvoll programmierte spiel macht das so, auch auf dem c64. spacetaxi lädt auch nur leveldefinitionen und ein kleines bischen extra code pro screen, zb.
Bei den alten Rechnern gilt Data Is Code und umgekehrt. Code kann genauso im Speicher rumgeschoben werden wie "normale" Daten. Eine Unterscheidung nach "ausführbar" und "anzeigbar" o.Ä. gibt es nicht.
natürlich ist es das. jedes halbwechs sinnvoll programmierte spiel macht das so, auch auf dem c64. spacetaxi lädt auch nur leveldefinitionen und ein kleines bischen extra code pro screen, zb.
Ich weiß das auch, dass das nach Möglichkeit so sauber gemacht wird. Ich mache das ja selbst in Basic so mit Subroutinen. Aber du verstehst das was ich meinte in der Breite / Ganzen 'mal wieder nicht genügend. Bevor das wieder ausartet, sag' ich aber nichts weiter dazu, weil man eh dann wieder nur jedesmal aneinander vorbeiredet ;).