Map effizient auf Screen abbilden

Bin echt fasziniert, das Spiel läuft wieder korrekt und zeichnet nochmal extrem viel schneller, danke Acorn für die Erwähnung DIESER Idee

Die codeseitigen Optimierungen sind ja nach wie vor auch drin, und es sieht fast so aus als könnte es jetzt möglich sein, auf double-buffering zu verzichten (was einiges vereinfachen würde), das will ich gleich mal probieren, bei nem aktiven Screen von 40x23 mit individuellen character-Farben sicher auf NTSC hart an der Grenze, aber vielleicht klappt es ja!

Zitat von WebFritzi

Du hast also tatsächlich maximal 16 Zeichen pro Farbe im Map-Bereich?

Tatsächlich maximal 2 sonst hätte ich das jetzt nicht machen können, den Platz ab $20 im Charset brauche ich für meinen Text-Font...

Zitat von WebFritzi

Du könntest dein Charset im unteren Bereich wechseln. Oder hast du dazu zu wenig Speicher?

Wieso drüber nachdenken solange es nicht nötig ist Ich brauche im Moment ein komplett leeres Charset um den Scrollbereich oben/unten sauber "abzuschneiden", da gäbe es VIELLEICHT auch ne elegantere Lösung, aber so wie es ist tut es ja Und der Platz im tatsächlich verwendeten Charset reicht ja aktuell für alle Tiles MIT dem netten "Farbtrick" und dazu noch den Font. Also, alles gut so

Hehe danke . Und sorry fürs "Kapern" indem ICH hier jetzt was für mein Projekt nützliches gefunden habe Aber vielleicht kannst du von dieser Idee ja auch profitieren. Denke hier liegt jetzt ein ganz netter "Werkzeugkasten" im Thread um irgendwelche Maps in character modes so schnell wie nur möglich zu zeichnen

Zitat von Claus

Könntest Du das nicht durch Umschalten auf einen illegalen Screenmode lösen? Praktischerweise ist Dein Hintergrund ja schwarz (was auch bei illegalen Screenmodes augegeben wird).

Ist er halt leider nicht, das sieht nur so aus. Tatsächlich ist der Hintergrund im Spielfeldbereich braun ....

edit: Funktionieren könnte es trotzdem, das "abgeschnittene" soll ja schwarz sein. Naja, wenn ich mal in die Verlegenheit komme Wie gesagt, im Moment passt ja netterweise alles

So, bin immer noch fasziniert. Ich hab double-buffering ausgebaut. Musste dazu die draw-routine ein kleines bisschen verlangsamen, weil sie jetzt strikt von oben nach unten malen muss (um dem Rasterstrahl immer zuvorzukommen):

Aber hey, das funktioniert!, ist selbst auf NTSC flott genug

Jetzt stimmt natürlich an einigen Ecken das Timing nicht mehr, einige Glitches zu fixen, aber das ist machbar und eröffnet dann ganz neue Möglichkeiten, wie eben das schnellere Scrolling beim "sich umschauen". SAU gut!

Zitat von WebFritzi

Kein Problem. Thema ist ja zunächst abgeschlossen.

Ja, für mich zunächst in der Tat auch Der Code oben ist zwar nicht mehr GANZ so effizient wie vorher, weil er zeilenweise loopt ... aber da ich auf den kompletten Block mit dem Farb-Lookup verzichten kann ist das tatsächlich schnell genug für "Echtzeit" Rendering Glitches inzwischen sauber gefixt, Spiel läuft wieder super auf sämtlichen Videosystemen. Jetzt gilt es, die neu gewonnene Rastertime sinnvoll einzusetzen, mal sehen

Optimierungen sind jedenfalls echt n spannendes/cooles Thema.

Zitat von Zirias/Excess

Beim Thema "Dinge auf den Bildschirm bringen" ist das aber eher die Regel als die Ausnahme (Ich hab noch fast jede Bilschirmausgabe-Routine irgendwann mindestens ein mal umgeschrieben, damit sie schnell genug war...)

Übrigens, um das nochmal am Praxisbeispiel zu untermauern: Die "Draw"-Routine in Stoneage64 gibt's inzwischen in der vierten Version Ok, die erste kann man vielleicht nicht zählen, die hat halt "irgendwie" die Map auf den Bildschirm gebracht damals für den ersten Grobentwurf 2018, war zum scrollen unbrauchbar, und dann hab ich ja n paar Jahre nichts dran gemacht.

Version 2 konnte dann scrollen, allerdings hat es nur auf PAL gereicht. Nachdem sich das abgezeichnet hatte, hab ich ziemlich umgebaut, seither besteht das "board" (auf dem sich das Spielgeschehen abspielt) nicht mehr aus Tile-Codes (0 bis 4) sondern direkt aus Screen-Codes und ist damit 4 mal so groß, aber damit hat sich das zeichnen auf mehr oder weniger "kopieren mit offsets" reduziert, plus eben den lookup der Farbe. Da hab ich dann die weiteren Optimierungen (self-mod, teilweise unrollen) dazugepackt und damit war die dritte Version auch auf NTSC schnell genug.

Und jetzt eben noch die vierte Version dank des Tipps hier aus dem Thread. Ohne den Farb-Lookup funktioniert es theoretisch in "Echtzeit" (weniger als 1 Frame zum zeichnen), weil man aber strikt von oben nach unten zeichnen muss, wenn direkt ins aktive Screen-RAM gezeichnet wird ("racing the beam") klappt das dann nicht mehr ganz. Trotzdem ist das jetzt schnell genug, um es alle 2 Frames komplett auszuführen

Daher, "premature Optimization" ist zwar dringend zu vermeiden, aber beim Thema Bildschirmausgabe auf dem C64 kann man einfach WISSEN, dass es hier fast immer eng wird, da ergibt es durchaus Sinn, gleich über Optimierungen nachzudenken! Dann spart man sich vielleicht die ein oder andere Iteration

Zitat von ogd

Ich würde sogar sagen, dass bei einem Actionspiel solche Routinen immer zuerst angegangen werden sollten, um auszuloten, wieviel Rechenzeit für die eigentliche Spiellogik übrig bleibt.

Hab ich, als ich das Projekt im Dezember dann ernsthaft verfolgt habe, auch genau so gemacht (die ersten Versionen haben einfach nur automatisiert "rumgescrollt", um zu sehen, ob das mit dem Timing hinhaut und eben, genau, wieviel eigentlich übrig bleibt). Nur Version 4 kam jetzt später, den super-schnellen Scroll beim sich umschauen hätte ich zwar gerne gehabt, aber war "nice to have" und ohne diesen Trick (farb-lookup einsparen) zu kennen dachte ich, das wird eh nichts.

Was man vielleicht noch als Tipp mitgeben kann: Frühzeitig Musik (kann ja ein "Dummy" sein) einbauen schadet nichts, macht die Tests aber realistischer. Der Player wird ja immer einen gewissen Anteil Rastertime auffressen