TrapThem64 - WIP

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

  • Zitat

    wieviele bytes braucht denn z.b. das allererste level (das voll mit steinen ist) bzw wie legst du das im speicher ab?

    Geplant ist jedes Level durch den Exomizer zu schicken. Und dann nach dem Laden in den Speicher, auszupacken.

  • Das will alles keiner wissen.
    Die Frage ist: Was steht in den Leveldaten?

    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.

  • Ich habe für mich selber eine tt64.txt immer weiterentwickelt, das neuste sind die Videos, die zeigen, wie eine Lösung geht. Mit Okteka kannst Du in die *.tt64-Dateien reingucken.

  • Hoffentlich nur die reinen Char-Daten. Und falls ja, die Art von Level scheint ideal fürs Zusammensetzen durch simple Elemente (LineH, LineV, Area) zu sein. Da würdest du immens Platz sparen.

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: 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.

  • Eine gute Optimierung wäre Exomizer auf alle TT64 Dateien anzuwenden. Nach dem Laden in den Speicher können sich die resultierenden kleineren Dateien wiederherstellen. Ich würde also
    die resultierende Exomizer Datei in eine bestimmte Adresse reinladen und sie sich auf die gewünschte Adresse entpacken lassen.

    Und auf eine Kleinigkeit möchte ich noch hinweisen. Während das erste Level sehr groß ist sind die meisten anderen Level sehr klein. Darum beinhaltet das TT64 Format eine Eingrenzung
    wieviel mal wieviel Platz gebraucht wird.

  • abgesehen von endurions vorschlag, je nachdem wieviel verschiedene objekte du hast könntest du zwei in ein byte packen (wenn es maximal 16 sind zb.), oder du könntest ein bit für ein flag übrig lassen das, wenn es gesetzt ist, im nächsten byte definiert wird wie oft der stein wiederholt wird, also zeilenweise aufbauen. die grössendefinition kann man sich auch sparen wenn man einen "CR" stein definiert, der sagt das die zeile zuende ist und eine neue aufgebaut wird. ebenso kann man dann die leeren stellen 1x definieren und so oft wiederholen bis wieder ein stein oder erde erscheint. man könnte sogar die diamanten und gegnersprites so plazieren, die bewegen sich dann eh autonom innerhalb des levels. so oder so ähnlich hätte ich das gelöst, man braucht halt definitv ein tool dafür sonst ist es zuviel handarbeit. also wenn ein level jetzt schon mehr als 1k braucht dann würde ich mir sorgen machen.

  • Danke für Deine Antwort. :)

    Also generell gilt, man kann immer noch etwas verbessern.

    >abgesehen von endurions vorschlag, je nachdem wieviel verschiedene objekte du hast könntest du zwei in ein byte packen (wenn es maximal 16 sind zb.),

    Du unterschätzt, wieviel Speicher ein einziges Viech braucht, davon abgesehen, daß es in späteren Leveln bis zu 50 in einem Level gibt. Das Viech kann einen Zeitzünder haben und jedes Viech hat zudem eine Richtung.

    >oder du könntest ein bit für ein flag übrig lassen das, wenn es gesetzt ist, im nächsten byte definiert wird wie oft der stein wiederholt wird, also zeilenweise aufbauen. die >grössendefinition kann man sich auch sparen wenn man einen "CR" stein definiert, der sagt das die zeile zuende ist und eine neue aufgebaut wird.

    Die Größendefinition hat zwei Byte. Viel sparen kannst Du so nicht, sehe ich jedenfalls nicht.

    >ebenso kann man dann die leeren stellen 1x definieren und so oft wiederholen bis wieder ein stein oder erde erscheint. man könnte sogar die diamanten und gegnersprites so >plazieren, die bewegen sich dann eh autonom innerhalb des levels. so oder so ähnlich hätte ich das gelöst, man braucht halt definitv ein tool dafür sonst ist es zuviel >handarbeit.

    Also die Level werden aus dem XNA-Leveleditor herauskonvertiert. Für jedes einzelnes Feld verbrauche ich ein Char. In dem Char brauche ich etwa 170 verschiedene Zustände, je nachdem ob es Lava usw. ist oder ein Viech mit einer bestimmten Richtung. Ich verschwende also ca. ein Bit pro Char. Dafür kann die Engine dann alles gut "entpacken".

    >also wenn ein level jetzt schon mehr als 1k braucht dann würde ich mir sorgen machen.

    Keine Sorge:

    Abgesehen von den Leveln mit Starttext/Vorführvideo sind die Level 2-3 Blocks groß. <1k

  • Ich denke diese Dateien hier sind schon gepackt? Bei 170 Typen wirds ein wenig kniffliger. 50 Viecher in einem Level, wie willst du das lösen? Also bei ca. zwei Blocks pro Level verstehe ich dann nicht wieso du drei diskettenseiten brauchst.

  • sofern die sich nicht alle gleichzeitig bewegen kann man sie ja als chars einbinden? 50 echte sprites sind nicht mehr so trivial

  • >sofern die sich nicht alle gleichzeitig bewegen kann man sie ja als chars einbinden? 50 echte sprites sind nicht mehr so trivial

    Gehe mir weg mit Multiplexing, das kostet zu viel Rechenzeit. Klar verwende ich die acht Realsprites.

    Ja, also mit berechneten Softwaresprites schaffe ich eine höchstens einen weiteren Roboter, bei zwei gibt es schon häßliche Slowdowns. Dabei wird kompliziert eine Figur im einfachsten Falle und ohne Überlagerungsfall zwischen zwei Zeichen mit diesen zwei Zeichen gemalt. Die Verwaltung kostet allerdings ordentlich RAM, was dazu führte, daß nichtmal das aktuell möglich ist.

    Je nachdem was für Roboter schaffe ich aktuell bis zehn, wenn ich einfach nur Feld pro Feld darstelle. Da bin ich dran, Du kennst vielleicht schon Level mit sehr vielen Crystalblades, am liebsten würde ich die auch so hinkriegen. 1k habe ich mir dazu noch als Feld freigehalten, in das ich Richtungswechsel vorberechnen könnte.

    Ich konzentriere mich jetzt auf komplett erstmal auf die Levelverwalung. Beantworte aber gerne weiter Fragen hier.

  • >"..Levelverwalung.."
    Alles voller Wale.. dann is kein Druchkommen mehr ;). Alles voller grüner Cannabis ähnlicher Pflanzenchars per Druck auf "F" oder so war schon genug. *Scherz*

    ---

    Mach' das Game und die technischen Lösungen einfach so, wie du meinst/kannst u. allein du es beriets durchdacht hast und gut isses.

  • die menus sind ja toll, hoch/runter geht mit dem joystick, feuer macht aber nichts. auswahl geht dafür mit return - aber nicht hoch/runter mit den cursortasten?

    werzurhölle denkt sich sowas aus? /o\

    - das starten eines neuen spiels ist viel zu viel klimbim. das muss mit ein paar mal knopf drücken erledigt sein.
    - was auch immer eine "memory disk" im context dieses spiel sein soll, vergiss das ganz schnell. niemand wird bei diesem spiel disk jockey spielen wollen schon bevor es los geht. ich bezweifle auch sehr das sich der spielstand nicht bequem auf der ersten disk ablegen lässt
    - wie kommst du auf die idee zwischen "real floppy" und "true drive emulation" wählen lassen zu müssen? diese auswahl ist komplett sinnfrei und wenn es aus irgendeinem grund tatsächlich einen unterschied macht ist irgendwas echt sehr kaputt.
    - wenn ich "neues spiel" wähle möchte ich spielen, und keine endlose ascii animation ansehen - die sich zu allem überfluss auch nicht abbrechen lässt

    die levelauswahl find ich ok so. das spiel selbst lässt sich ja nicht testen leider

  • Ich mag die ODER Frage mit yes/no Antwort wenn man ein 'complete' new game starten moechte :wink:

    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.

  • Zum seltsamen Speichermanagement sag ich nix mehr, auch nicht zum lieblosen Bitmap. Aber: Was muss ich denn alles auswählen bzw. mich durchquälen, bevor ich zum ersten mal einen Schritt machen kann? Wieso dieses Anlegen eines Spielstandes als ob ich erst Charaktere wie für Ultima erstellen muss? Und wieso SAM Sprachausgabe?? Wo ist das Spiel? Das Spielprinzip war doch ok - und jetzt finde ich es nicht einmal mehr...

  • Iegendwie erinnert mich das an Bitte melde dich an, um diesen Link zu sehen. : Tausend mal return, yes, Codeeingeben, um in einem flackernden Bildschirm zu enden.

  • Die Menüs bzw. dieses moderne (erinnert ja fast an diese sich dynamisch bewegenden Menüs in so einigen moderneren Spieletiteln) flüssige Bewegen der border, also Anpassung je nach benötigtem Platz, gefällt mir.

    Aber du solltest die Return Tastenfunktion zusätztlich oder halt einzig auf den Feuerknopf legen. Der Knopf wird ja bereits abgefragt.., wie man am Ton hört, wenn man ihn drückt. Er ist aber ohne Funktion in den Menüs und man muss stattdessen Return 'bemühen'