TrapThem64 - WIP

Es gibt 1.096 Antworten in diesem Thema, welches 187.950 mal aufgerufen wurde. Der letzte Beitrag (25. Februar 2020 um 20:49) ist von Vernunftmensch.

  • Zitat

    Bitte zeig uns doch mal deinen Aufruf zu Auslagerung.tmp.

    cbmfehlermeldung=cbm_load ("auslagerung.tmp",8,NULL); :(:(:(;(;(;(;(;(;(:?:

    Zitat

    btw: Bei mir hing er beim Zugriff auf AUSLAGERUNG.TMP mit Fehler 4

    Also den Fehler habe ich bislang nur bekommen, wenn es die Datei wirklich nicht gibt. Ich bekomme immer Bitte melde dich an, um diesen Link zu sehen..

    Zitat

    Wenn ein C64-Spiel etwas auslagert, läuft etwas grundfalsch.

    Ich schreibe allen Code, den das Level während des Spielens nicht braucht ab $1000, speichere den weg in auslagerung.tmp und lege die Goattrackerdatei drüber.

    Zitat

    "Speichern" dauert nämlich prinzipiell länger als "Laden"

    Die Datei wird einmal geschrieben und bleibt dann konstant.

    ------------------------------------------------------------------------------
    Da es später sowieso auf echter Hardware laufen soll, überlege ich einen Schnelllader einzubauen. Der dann hoffentlich keinen Unsinn macht. cbm_load sollte zwar eingebaute Schnellader nutzen, da möchte ich mich aber nicht drauf verlassen.

    Gibt es auch Schnellspeicherer? (muß kein irq-schnellader sein)

  • cbmfehlermeldung=cbm_load ("auslagerung.tmp",8,NULL);

    Okay, an der Library-Funktion wird es wohl nicht liegen. Dann wäre mein nächster Verdacht, dass irgend ein fehlerhafter Programmteil die Konstante "8" überschreibt - das wird natürlich schwierig zu debuggen sein. Um diese Hypothese zu testen, könntest Du direkt nach dem "I/O error Bitte melde dich an, um diesen Link zu sehen." (device not present) Speicherstelle $ba auslesen - da sollte ja jetzt eigentlich 8 drinstehen.

    Ich schreibe allen Code, den das Level während des Spielens nicht braucht ab $1000, speichere den weg in auslagerung.tmp und lege die Goattrackerdatei drüber. Die Datei wird einmal geschrieben und bleibt dann konstant.

    Wenn der Inhalt konstant ist, warum dann zur Laufzeit speichern? Erzeuge die Datei bei Dir und liefere sie einfach mit. Nach den Beschreibungen hier im Thread sind die Ladezeiten jenseits von gut und böse - wenn auch noch unnötig gespeichert wird, ist das nicht verwunderlich. Wie groß ist eigentlich diese Auslagerungsdatei? Berechne mal die Größe der dynamischen Spieldaten (Punktestand/Levelzähler/Spielername/...) und vergleich damit.

    Da es später sowieso auf echter Hardware laufen soll, überlege ich einen Schnelllader einzubauen.

    Die wievielte offene Baustelle wäre das dann? Es gibt da diese Programmierweisheit "First make it work, then make it fast/elegant/small/optimal/whatever"...

    Gibt es auch Schnellspeicherer?

    :wand Siehe oben - einfach nur grundfalsch. Pfui! Aus! Böser Vernunftmensch!

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Zitat

    Okay, an der Library-Funktion wird es wohl nicht liegen. Dann wäre mein nächster Verdacht, dass irgend ein fehlerhafter Programmteil die Konstante "8" überschreibt - das wird natürlich schwierig zu debuggen sein. Um diese Hypothese zu testen, könntest Du direkt nach dem "I/O error Bitte melde dich an, um diesen Link zu sehen." (device not present) Speicherstelle $ba auslesen - da sollte ja jetzt eigentlich 8 drinstehen.

    Steht siehe Bild. Das Bild kann ich erst im nächsten Post posten, sorry.

    Zitat

    Wenn der Inhalt konstant ist, warum dann zur Laufzeit speichern? Erzeuge die Datei bei Dir und liefere sie einfach mit. Nach den Beschreibungen hier im Thread sind die Ladezeiten jenseits von gut und böse - wenn auch noch unnötig gespeichert wird, ist das nicht verwunderlich. Wie groß ist eigentlich diese Auslagerungsdatei? Berechne mal die Größe der dynamischen Spieldaten (Punktestand/Levelzähler/Spielername/...) und vergleich damit.

    Die Auslagerungsdatei ist nicht größer als die größte Musikdatei und die Musikdatei ist nicht größer als der Code, den man unbedenklich auslagern kann für die Zeit, in der die Musik läuft. Im cc65 ist ein Beispielprogramm, um Datenblöcke in der .cfg als Extrabindatei auszulagern. Das wäre schon eine Möglichkeit. Wird auch genauso kommen, denn die Datei möchte ich nicht zur Laufzeit einrichten, obwohl das geht.

    Zitat

    Die wievielte offene Baustelle wäre das dann? Es gibt da diese Programmierweisheit "First make it work, then make it fast/elegant/small/optimal/whatever"...

    Ich kann das Wort Baustelle nicht mehr hören. Demnächst hänge ich mir vor dem Coden ein Baustellenschild an die Türe.

    Nein, im Ernst. Ich bin so verzweifelt, daß ich schon auf einen Schnelllader umgeswitscht bin.
    Bitte melde dich an, um diesen Link zu sehen.

    Ich kapiere bei dem Ding nur noch nicht, wie ich meine Startadresse selbst einstellen kann, vielleicht hat man hier eine Idee?

    Zitat

    :wand Siehe oben - einfach nur grundfalsch. Pfui! Aus! Böser Vernunftmensch!

    Ja, wenn cbm_load oder cmb_save nicht wollen, dann vielleicht solche Alternativen?

    :cursing: Böser C64er.... böse.

  • Zitat

    Nein, im Ernst. Ich bin so verzweifelt, daß ich schon auf einen Schnelllader umgeswitscht bin.


    mach doch erstmal das spiel fertig, völlig egal wie schnell das lädt. da kannst du dir am schluss gedanken drum machen.

    (mir ist eh ein rätsel was da warum nachlädt, dieses spiel sollte komplett in den speicher passen)

  • Zitat


    mach doch erstmal das spiel fertig, völlig egal wie schnell das lädt. da kannst du dir am schluss gedanken drum machen.

    (mir ist eh ein rätsel was da warum nachlädt, dieses spiel sollte komplett in den speicher passen)

    -107 Level
    -je nach Leveltyp andere Musik
    -aussehen angepaßt auf leveltyp
    -tt64-engine schon fast komplett in asm und speicherprobleme
    -tt64-engine muß sowiesi einmal gründlich mit allem initialisiert werden, damit sie von selbst läuft

    Welche Speicheradressen sollte ich immer wieder herstellen, wie $ba? ($ba war es offensichtlich nicht)?

    :motz:


  • Welche Speicheradressen sollte ich immer wieder herstellen, wie $ba? ($ba war es offensichtlich nicht)?

    Es geht nicht darum bestimmte Speicherzellen immer wieder herzustellen, sondern das sie
    wenn du sie benötigst nicht durch irgendwas anderes zerschossen/überschrieben werden.

  • Steht siehe Bild.

    Hm, machst Du vielleicht irgendwas an den Registerbits für den seriellen Port kaputt? Evtl. beim Wechseln der VIC-Bank?

    Die Auslagerungsdatei ist nicht größer als die größte Musikdatei und die Musikdatei ist nicht größer als[...]

    Ächz. Okay, vielleicht war meine Formulierung nicht eindeutig genug, also hier noch einmal ganz simpel:
    Lass das sein mit dem Auslagern. Auslagern ist bei einem C64-Spiel eine Scheißidee. Es ist unnötig.
    Kein C64-Spiel lagert etwas aus. Und warum nicht? Weil Code, Grafik, Musik und Leveldaten jederzeit wieder nachgeladen werden können. Und was man nachladen kann, muss man nicht auslagern. Kapiert? Wenn bei meinem Linux der Speicher knapp wird, so wird etwas ausgelagert, z.B. die aktuell geladene Webseite. Was aber nicht ausgelagert werden wird, ist das Browser-Binary - das wird einfach nur verworfen, denn es kann bei Bedarf wieder geladen werden, genau von dort, von wo es beim Programmstart auch geladen wurde (jetzt bitte keine Korinthenkackerei über Linkertabellen etc. - ich versuche hier was zu erklären :))
    Auslagern muss man nur, wenn die dynamisch erzeugten Daten nicht in den Speicher passen - das sind bei Deinem Spiel aber nur Punktestand und Levelzähler, also nur eine Handvoll Bytes. Was folgern wir daraus? Bei TrapThem muss nichts ausgelagert werden.
    Deine Frage nach "Schnellspeicherern" ist ein Versuch, an den Symptomen herumzudoktern. Vergiss die Symptome und beheb stattdessen die Ursache des Problems: Lass den Auslager-Scheiß weg. Echt jetz.

    Ich bin so verzweifelt, daß ich schon auf einen Schnelllader umgeswitscht bin.
    Bitte melde dich an, um diesen Link zu sehen.
    Ich kapiere bei dem Ding nur noch nicht, wie ich meine Startadresse selbst einstellen kann, vielleicht hat man hier eine Idee?

    Ja, ich hab eine Idee: Mach keine neue Baustelle auf.

    Ja, wenn cbm_load oder cmb_save nicht wollen, dann vielleicht solche Alternativen?
    :cursing: Böser C64er.... böse.

    Weder cbm_load/cbm_save noch der C64 sind hier das Problem.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Zitat

    -107 Level
    -je nach Leveltyp andere Musik
    -aussehen angepaßt auf leveltyp


    du musst also maximal die leveldaten nachladen. ansonsten zeigen artverwandte spiele wie zb boulderdash das man so eine engine durchaus zusammen mit ziemlich vielen leveln komplett in den speicher kriegt

    Zitat

    Hm, machst Du vielleicht irgendwas an den Registerbits für den seriellen Port kaputt? Evtl. beim Wechseln der VIC-Bank?


    oder die interrupt routine, welche vor dem laden nicht sauber angehalten wird und während dem laden munter weiter rennt, hackt stumpf in $zeropageadresse rein? ansonsten ist das rumspielen an $dd00 natürlich auch eine tolle idee während kernal load :=)

  • du musst also maximal die leveldaten nachladen. ansonsten zeigen artverwandte spiele wie zb boulderdash das man so eine engine durchaus zusammen mit ziemlich vielen leveln komplett in den speicher kriegt

    Mein Eindruck bei den vorgestellten Levels hier in letzter Zeit war, dass jeder Level anscheinend eigens zusammengeschustert wird mit jeweils eigenem Code. Anders ausgedrückt: Es existiert keine universelle "TrapThem-Engine" beim C64-Port. Vernunftmensch: Ist das tatsächlich so oder täuscht mich der Eindruck?

  • aua =) in dem fall würde mich interessieren in wie vielen diskettenboxen dieses spiel geliefert wird =)

  • ...immerhin, damit würde Vernunfti als Erfinder des ersten wirksamen Kopierschutzes in die Geschichte eingehen. :D

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • @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.

  • Zitat

    Mein Eindruck bei den vorgestellten Levels hier in letzter Zeit war, dass jeder Level anscheinend eigens zusammengeschustert wird mit jeweils eigenem Code. Anders ausgedrückt: Es existiert keine universelle "TrapThem-Engine" beim C64-Port. Vernunftmensch: Ist das tatsächlich so oder täuscht mich der Eindruck?

    Diese Vermutung hab ich mittlerweile - dank Auslagerung.tmp - ebenfalls, und das wär vereinfacht gesagt DER HAMMER.
    Wenn ich sehe was die Anfang der 80er schon alles in wesentlich weniger Platz gepresst haben (H.E.R.O. zB) ist TT64 da ein wenig , um es nett zu formulieren, rückständig...


    LG, duke

  • Das Retten einiger ZP-Register bewirkt auch nicht den gewünschten Erfolg. ;(

  • Ich habe schon merhfach gefragt, wofür diese Unmengen an Code eigentlich benötigt werden.
    Vernunftmensch: Erkläre doch mal, was bei dir 'game engine' bedeutet.

    Bitte melde dich an, um diesen Link zu sehen. ~ Bitte melde dich an, um diesen Link zu sehen. ~ Bitte melde dich an, um diesen Link zu sehen. ~ Bitte melde dich an, um diesen Link zu sehen. ~ Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    Mein Eindruck bei den vorgestellten Levels hier in letzter Zeit war, dass jeder Level anscheinend eigens zusammengeschustert wird mit jeweils eigenem Code. Anders ausgedrückt: Es existiert keine universelle "TrapThem-Engine" beim C64-Port. Vernunftmensch: Ist das tatsächlich so oder täuscht mich der Eindruck?

    Jedes Level ist abwärtskompatibel. Damit meine ich, daß mitlerweile alle TutorialLevel auf der Engine laufen, kann man ja nachsehen in meinen vielen Levelposts.

    Mitlerweile ist das allermeiste schon in ASM umgesetzt. Hier unterschätzen offenbar die ASM-Größe einer solchen Engine oder ich überschätze mich in meinem ASM-Optimierungfähigkeiten. Jedenfalls glaube ich, daß sogar sauhund die 107 Level nicht in eine Datei kriegt.

  • 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.. :platsch: .
    Die Möglichkeiten in den Levels sind ja hier bei TT64 relativ komplex -Boulderdash ist da viel simpler-, daher kann ich schon verstehen, dass man die Routinen bei TT64 je Level individuell anpassen muss, damit man pro Level den gleichen Speed in den individuell ablaufenden Spiel-Schleifen (Routinen) erreicht usw. . Alle Möglichkeiten in eine Engine (mit If..Then artigen Verknüpfungen/Abfragen) wäre ziemlich schwierig denke ich. Sollen die anderen erstmal hinkriegen, bevor sie sowas verlangen :).
    Space Taxi hat auch seine Level nachgeladen und die Physik je Leveltyp angepasst, war da auch nicht nervig.

  • Ohne Worte.....

    vernunftmensch@ubuntu:~/Arbeitsfläche/TrapThem64 (v2.0)/cc65-2.13.3/___engine/___asm-files$ wc *.s
    445 920 9645 cbm_selbst.s
    120 181 1894 diamanten.s
    1170 2073 19532 dieb.s
    836 1282 15147 echtzeit_betriebssystem.s
    510 813 9855 edelsteine.s
    6395 10277 119458 einzig_vorher.s
    6680 11696 106955 engine_optimal.s
    10 80 744 enginevariablen.s
    84 131 1604 explosion.s
    3481 6332 68673 fallsoftwaresprites.s
    6379 10264 119190 farbig_vorher.s
    33 48 653 levelx_asm.s
    26 46 444 macros.s
    1561 2294 23928 __prof_ground.s
    6358 9869 113404 __prof_levelx_asm.s
    2124 3427 33740 __prof_mark.s
    212 482 6136 tonusound.s
    36424 60215 651002 insgesamt

    vernunftmensch@ubuntu:~/Arbeitsfläche/TrapThem64 (v2.0)/cc65-2.13.3/___engine/h$ wc *.h
    10 14 313 Ausgangsverwaltung.h
    105 239 2651 edelsteine.h
    75 181 1813 Kernalmanagement.h
    2 0 2 Kompremierung.h
    417 1250 12718 __prof_data.h
    1453 2601 31356 __prof.h
    13 23 269 Schachbrett.h
    101 157 1904 schritt1.h
    886 1322 15843 select.h
    872 1308 15764 select (Mit ordentlichem Menü).h
    6 12 153 Softwarespriteverwaltung.h
    57 90 1080 Soundmanagement.h
    5 10 245 Speicherverwaltung.h
    285 687 7252 Spriteverwaltung.h
    0 0 0 Superdiamantenverwaltung.h
    6 7 246 Viecher.h
    4293 7901 91609 insgesamt