Posts by 5ace

Quote from M. J.

Die DIvision sieht dann so aus:

Vielen Dank. Dein Code und Deine Ausführungen waren sehr hilfreich.
Ich habe gerade einige isolierte Tests gemacht und die Division scheint zu funktionieren.

Wie würde man folgende Divison durchführen?
15 / 2.25

(Das Umschreiben als Bruch mit 15 * 4 / 9 und das Ausrechnen über die Tabelle funktioniert und ergibt 6, wobei ich nur eine Tabelle log_1 verwendet habe.)
Kann man irgendwie low und highbyte einzeln ausrechnen ?
Also 15/2 und 0/$40 (für 0.25)

Warum ergeben 0/$40 und 1/$40 = 4 ? (Es wird scheinbar 256 / 64 ausgerecht.)

Feststellung:
Die Geschwindigkeit für die Berechnung der Pixel, lässt sich extrem beschleunigen, wenn man
1.) das Level verkleinert; um auch mehr oder größere Tabellen in den Speicher laden zu können.
2.) alle Schleifen ausschreibt und alles nicht so wissenschaftlich sieht.

Zu 1.)
Das Level ist jetzt 64*64 = 4096 Bytes groß und scheint als Spielfläche ausreichend zu sein, d.h. man benötigt keine Tiles.
Zur Geschwindigkeit: Um die 64 Höhen für den angezeigten Ausschnitt (8x8 Punkte) aus dem Level auszulesen, kann man einmal die Levelposition umrechnen und dann indiziert auf die ersten 32 Punkte zugreifen. Danach erhöht man das Highbyte der Levelposition und greift auf die restlichen 32 Punkte zu.
Als zweiten Schritt kann man das angezeigte Gitter mit dem Softscroll-offset vorbereiten.

Bspw:

x[i] = 16*(i%8)+softscroll für alle 64 Punkte

und

z[i] = i*16+softscroll für die 8 Tiefen in das Feld.
Im dritten Schritt wandelt man die 3D-Koordinaten mithilfe der bereits erwähnten Tabelle in Bildschirmkoordinaten um. xs[i] = x[i] / z[i%8] und ys[i] = (Levelhöhe für Punkt i + globaleHöhe) / z[i%8]
Die Tabelle beinhaltet nur Absolutwerte, d.h. um eine x-Koordinate umzuwandeln, wird unterschieden, ob sich der Punkt links oder rechts von der Bildschirmmitte befindet und danach wird entsprechend zur Bildschirmmitte der Wert aus der Tabelle addiert oder von ihr abgezogen. Bei der y-Koordinate muss man sich keine Gedanken machen. Hier ist es eher wichtig, dass man sich im Rahmen der Tabellengröße bewegt.
Jetzt können die Punkte gezeichnet werden.

Zum Schluss lassen sich die gespeicherten Bildschirmkoordinten bei der nächsten Bewegung zum Löschen der Punkte nutzen.

Zu 2.)
Im Prinzip ist alles sehr einfach und der ausgeschrieben Code passt in ca. 1400 Byte.
Angehängt ist ein Beispiel, bei welchem ich mir keine Mühe um das "Drumherum" gemacht habe und welches auch abstürzen kann.
Es soll zur Demonstration der Geschwindigkeit dienen. Viel mehr ist realistisch gesehen nicht drin (, d.h. es kann nur langsamer werden).
Die Berechnungen und Tabellen sind nicht geprüft/korrigiert etc. und das Level ist auch nicht wirklich im Speicher, sondern man sieht nur "Müll".
Der Eindruck der Geschwindigkeit kommt mit Sicherheit auch durch die Nutzung einer Beschleunigungsfunktion bei der Steuerung.
(...)

Was zu tun wäre (, irgendwann einmal...):
- Die Tabellen korrigieren. Evtl. versuchen sie nochmal zu verkleinern, um mehr Y-Werte zulassen zu können (am liebsten 255 bzw. den genannten Trick mit dem Shift auszuprobieren.
- Double-Buffering, d.h. am besten alles 2 mal unterbringen. (Speicher ist genug da)
- Korrektur an der Steuerung (Ich glaube, dass ich irgendwo addiere statt zu subtrahieren o.ä. etc..)
und dann könnte man sich wieder um die Linien und eine Füllroutine kümmern.

testzarch5.prg

Anbei ein neuer Test.

Einige Details dazu:

- Es gibt Softscrolling.

- Die Umsetzung erfolgt wieder über Tabellen.

-- Ich gehe davon aus, dass eine Division über log-Tabellen zu lange dauert, weil man je Punkt eine 16-Bit Multiplikation mit dem Kehrwert benötigt.

-- Einen Versuch mit den Routinen aus codebase hatte ich umgesetzt; das Ergebnis war fehlerhaft; Ursache war bestimmt ein Fehler meinerseits.

--- Andere Gedankengänge, bspw. mit fixen Divisionen scheinen mir Geschwindigkeitsmäßig im Vergleich zu den verwendeten Tabellen eher nachteilig zu sein.

---- Idee: Evtl. könnte man einen Mix schaffen, d.h. es gibt eine Sprungtabelle und diese liefert entweder einen Wert oder führt Verschiebeoperationen durch.

-- Der Trick bei den Tabellen ist, dass 64 Einträge für die Breite ausreichend sind. Die Spielfläche ist max. 128 MC-Pixel breit, so diese auch für das Setzen eines Pixels die Adressierung über eine Page ausreichend ist.

-- Die Anzahl der Tabellenzeilen ist "leider" auf 96 beschränkt, so dass auch die Achse entlang der (3D-)Höhe begrenzt ist. (Per Feuerknopf kann man die Höhe ändern.)

--- Ich gehe davon aus, dass man die Tabelle erweitern kann, wenn man 32 Einträge und einen Shiftbefehl nutzen würde.

--- Es gibt auch einen "Pumpeffekt" für flache Blickwinkel, den ich glücklicherweise irgendwie einigermaßen eliminieren konnte. (Die Anzahl der Schritte im Softscrolling kann ich erhöhen/anpassen; so dass das Ergebnis in einigen Fällen besser/schlechter wird.)

- Der Kartenausschnitt ist nur scherzhaft (=als Bonus) eingebaut. Eigentlich sollte er auf die rechte Seite und der Untergrund sollte natürlich gerettet werden.

- Mein eigentliches Ziel war, gefüllte Flächen zu zeichnen. Evtl. ist es sinnvoller vorher die Tabelle in den Griff zu bekommen und zu verkleinern.

- Die Steuerung oder das Gefühl dafür, könnte man natürlich über eine Beschleunigung verbessern. (Momentan bin ich einfach froh ein einigermaßen stabiles Programm präsentieren zu können.)

- Double-Buffering wird nicht verwendet.

(...)

testzarch4.prg

Quote from Retrofan

Ist eigentlich irgendwer coding-mäßig dran an der Idee, etwas Zarch-ähnliches auf den C64 zu bringen, egal ob nun in 2-, 2.5- oder 3D? Ich möchte nur wissen, ob man sich hier noch auf kommende Teil-Ergebnisse freuen kann oder ob das Thema, zumindest von Realisierungs-Seite her, gestorben ist.

Ich habe noch einige Ideen zu den eigenen Versuchen gesammelt.
Mich interessiert, wie schnell der Boden gezeichnet werden kann, d.h. im Endeffekt wird es max. ein kleiner Grafiktest mit abgespeckten Vorgaben.

Quote from Retrofan

Ganz ehrlich, ich kann mir nicht vorstellen, dass der C64 in der Lage ist, ein PEFORMANTES Spiel in der Art zu wuppen. Schon die Specci-Version zeichnet sich durch eine extrem niedrige Framerate aus (gefühlt 4 fps, und das bei einem Z80 mit 3,5 MHz) – was will der C64 da reißen? Dazu kommt, dass bei Virus Farbe eine gewisse Rolle spielt (die verseuchten Flächen werden in rot/braun-Tönen dargestellt) und dass man mit einem 1-Button Digital-Joystick auch nur schwer in der dritten Dimension navigieren (und dann noch schießen etc.) kann.

Ich glaube, dass das Zeichnen/Scrolling der Landschaft mindestens genau so "gut" aussehen kann, wie auf dem ZX Spectrum.
Die Umsetzung der Farben stellen mit Sicherheit die Herausforderung dar.
Die Festlegung auf MC mit 4 Farben einscheint mir rein techn. gesehen sinnvoll.
Für den Spielspaß im Vergleich zum Original wäre das bestimmt ein Negativpunkt; im Vergleich zur ZX Spectrum Version dann jedoch wieder nicht.
Falls eine Steuerung über den Joystick, den Ansprüchen nicht gerecht wird, könnte man die Maus in Betracht ziehen.
(Die anderen Versionen lassen sich ja auch irgendwie über den Joystick und/oder die Tastatur steuern; also sollte es auf dem C64 auch genauso gut (=ohne Abstriche) gehen.)

Bis vor einigen Minuten, wäre ich auch Deiner Meinung, was die Umsetzbarkeit der Darstellung angeht.
Dann habe ich gemerkt, dass der Screenshot, den ich zur Hilfe verwendet habe, sehr unvorteilhaft war.
Es gibt eine Online-DOS-Box mit dem Spiel. Von dort heraus habe ich einen neuen Screenshot erstellt.
https://classicreload.com/zarch-lander.html



Der Vorteil ist, dass man eine saubere 320x200 Auflösung hat und das Spielfeld anders als im Video (=den anderen Versionen) aufgebaut und proportioniert ist.
Der Ausschnitt ca. 8x9 (?) Kacheln groß und max. 256 Pixel breit. Die schwarze Fläche beträgt ca. 84%, d.h. der Ausschnitt ist ca. 16% bzw. 1280 Bytes groß.
Das sollte doch mit dem C64 machbar sein, oder nicht?

Für eine "imaginäre" C64 Version könnte man also die Landschaft (ca. 32x8+ Zeichen) links zeichnen und hätte dann rechts 8 chars für die Map.
Bei der Online-Version kann man einwenig ausprobieren und sehen, wie das Raumschiff immer an der selben Stelle gezeichnet wird und wie eine Maussteuerung umgesetzt werden könnte.
(...)

M.M.n. müsste zuerst eine schnelle Füllroutine für die Vierecke her; dann könnte man wieder was zur Geschwindigkeit/Umsetzbarkeit sagen und ob man für den Rest evtl. vorberechnete Sprites nutzen könnte/müsste.
(((Ein Wort noch zum Vergleich: Das Testprogramm mit den Linien testzarch2.prg hatte fast doppelt soviele Punkte/Flächen, wie die Version im neuen Screenshot.)))

------
Zu Deinem Mockup: Ich mag die klaren Farben und Linien + Es ist interessant zu sehen, in welche Richtung die Vorstellung gesponnen werden kann.

Ich wollte noch etwas zu Zarch schreiben.
Ich hatte spaßeshalber einen Screenshot aus dem Youtube-Video gemacht (der Balken ist noch zu sehen), um zu ermitteln, wie groß die Fläche ist, die gezeichnet werden müsste und wie die Farben abgebildet werden könnten. Die schwarze Fläche beträgt ca. 63 Prozent, d.h. es müssten ca. 3000 Bytes für die Landschaft gezeichnet werden.

Nachfolgend der Vollständigkeit halber einfach die Screenshots, in die ich aus dem ursprünglichen erstellt hatte, um die Optik/Formate zu vergleichen:

Quote from M. J.

Hättest Du vielleicht den dazu gehörigen Programmcode, damit ich mir das Programm mal ansehen kann? Auf den ersten Blick würde ich sagen, daß a) die Berechnung mit den Fließkommaroutinen des Basic-Interpreters oder einem umständlichen Zahlenformat durchgeführt wird, b) ich mir nicht sicher bin, ob es sich bei der Darstellung wirklich um 3d handelt oder einfach nur um verschobene 2d-Punkte, die mit Linien verbunden werden., So oder so erzeugt solch ein Programm Dreiecks-Polgone, wohingegen ein Spiel wie "Virus" die Landschaften aus Vierecken zusammensetzt, d. h. die zugrundeliegende Symmetrie ist anders.

Ich gehe auch davon aus, dass es den Basic Interpreter nutzt + bei den Vierecken hast Du recht.

Quote from M. J.

Verzeih, eine kleine Frage: Hattest Du bei den Tabellen berücksichtigt, daß die Kamera nach oben und unten bewegt werden kann, wodurch die Punkte anders gestreckt/gestaucht werden?

Nein, die Kameraperspektive (=der Winkel auf bzw. die Neigung zum das Spielfeld) würde sich in dieser Vorstellung nicht ändern, sondern es würde einfach ein Offset zur Levelhöhe addiert/subtrahiert werden, d.h. aber auch, dass der 3D-Eindruck bestehen bleibt. Anders ausgedrückt: Man bewegt den Kopf nur parallel zum Boden und kann das Kinn nicht nach unten oder oben neigen

Quote from M. J.

Ich vermute, Du meinst damit sowas wie "Subkarten", d. h. es gibt eine große Karte, z. B. 16 x 16. Jedes Element dieser Karte besteht wiederum aus 4x4 Elementen, die die finale Höhe angeben. WIll man also die Höhe an einem Punkt ermitteln, nimmt man X/Y, teilt diese durch 4, holt sich die "Kachel" aus der großen Map und indiziert dann die Submap/Kachelmap mit den verbliebenen unteren 2 Bits. Dadurch käme man in diesem Beispiel auf eine Gesamtgröße der Karte von 64x64 Werten. Andere Werte sind natürlich nach Belieben möglich.

Ja, richtig.

Quote from M. J.

Mich auch. Einfach nur so aus Interesse. Wenn ich mehr Zeit hätte, würde ich ja mal ein kleines Testprogramm schreiben...

Anbei eine Version mit Linien.
- Meine Line-Funktion hat einige Macken, d.h. die Sonderfälle für horiz./vert. Linien habe ich nicht berücksichtigt und es tauchen in bestimmten Fällen horiz. Streifen auf.
- Im Allgemeinen genügt jedoch diese Version, um eine "etwaige" Vorstellung für die Geschwindigkeit zu entwickeln. (Optimieren kann man sicherlich an vielen Stellen. Es werden Tabellen statt der freien Division oder log-Tabellen verwendet. Hires statt MC wäre auch interessant; dann würde ich jedoch lieber nur ein 256 Pixel anzeigen.)
- Eine Version mit Double-Buffering hatte ich angefangen, aber dann verworfen, weil sie zu unordentlich wurde, d.h. hier müsste ich vorher einwenig umstrukturieren.

testzarch2.prg

Quote from M. J.

Problem ist, daß im Original Virus sich die Objekte nicht ruckhaft von Fläche zu Fläche bewegen, denn das würde bedeuten, daß es nur vier Bewegungsrichtungen gibt mit je einer Geschwindigkeit (Fläche ==> Fläche). Die Objekte rotieren aber um die Y-Achse, so daß bei einer Bwegung der X-Anteil und der Z-Anteil der Schrittweite beliebige Werte zwischen 0 und der aktuellen Geschwindigkeit annehmen können. Dadurch bewegen sich auch die Landpunkte nicht in einem festen Raster über den Bildschirm, so daß eine Berechnung über Tabellen aufgrund der hohen Anzahl verschiedener X-, Y- und Z-Werte nicht funktionieren dürfte. Wie ich schon schrieb, könnte man zur Berechnung Logarithmentabellen einsetzen. Das ist ein wenig aufwendiger, erspart aber dafür große Tabellen. Nur was die Genauigkeit anbelangt habe ich halt Zweifel, aber solange man es nicht probiert hat...

Ja, richtig. Die Objekte, d.h. diejenigen, die über Sprites gelöst werden, sollen sich frei bewegen können und nicht in einem Raster. Dort auch mit "echter" Division bzw. log-Tabellen o.ä..
Mir ging es nur um die Darstellung der Landschaft, die man, ausgehend von der ZX Spectrum Version, auch ohne Multiplikation umsetzen könnte.
Dort wird die Landschaft (scheinbar) nicht pixelweise verschoben, sondern nur im Raster. (Keine Frage, die Original-Version sieht um Längen besser aus.)
Ich gehe davon aus, dass das Player-Raumschiff durch die rasterweise Verschiebung der Landschaft auch so wirken würde, als ob es sich bzgl. der Landschaft nur in dem Raster bewegen würde und bzgl. der Objekte frei/pixelweise, weil das Player-Raumschiff, außer in der Achse, die die Y-Achse des Monitors wiederspiegelt, sich immer an einer festen Stelle auf dem Bildschirm befindet.

Zur Umsetzung über Tabellen hatte ich noch einen Gedanken:
Man benötigt wegen der Symmetrie nur ein Viertel der vorher angegebenen Tabellengröße und könnte so 4 mal mehr Pixel mit dem selben Speicherplatz darstellen.
Ein anderer Gedanke war, dass man die Tabellen weiter verkleinern könnte bzw. die Details im unteren Bereich erhöhen könnte, weil man die Spielfläche nie (?) am oberen Rand sieht, d.h. so als ob man von unten nach oben schaut, so dass sie oben am oberen Rand des Bildschirms dargestellt wird.

Was die Framerate angeht, würden natürlich mehr dargestellte Pixel diese weiter senken.
Und man bräuchte auch, wie von Dir genannt, eine interne Repräsentation für größere Karten, welche die Geschwindigkeit weiter senken würde. (Die Lösung sind aus meiner Sicht Tiles.)

Vielleicht wäre die Darstellung der Landschaft mit mehr Pixeln zufriedenstellend genug, so dass man sich die Divisionen und Polygone dafür spart.
Natürlich würde mich auch interessieren, wie schnell echte Polygone oder Linien wären

------
Einen Hinweis oder Anreiz darauf, wie die max. Güte aussehen könnte, zeigt ein Programm aus dem 64'er-Magazin:
"Superfrac 64" im 64'er Nr. 75 auf Seite 14
https://archive.org/details/64…heft_75/page/n13/mode/2up

Die Berechnungsdauer für einen Ausschnitt dauert, je nach Qualität, mehrere Sekunden bis zu ca. einer Minute und wäre für ein Spiel unbrauchbar.
Nachfolgend einige Screenshots. Es lassen sich MC und Hires auswählen:

Originalgetreu umsetzbar bestimmt, aber mit extrem niedriger Framerate
Was ich mir vorstellen kann, wäre eine abgespeckte Version:
Die Objekte als Sprites und die Landschaft nur mit Punkten umgesetzt. Das dürfte dann schnell genug sein. Die Sprites müssten vorberechnet sein, d.h. die möglichen Winkel wären sehr starr etc. ...

((( Eine andere (rein optisch, erträumte) Vorstellung, wäre eine Umsetzung im Multicolor-Bitmap-Mode mit einer Rasterung für die Flächen der Landschaft, d.h. bei 4 Farben hätte man da noch die Zwischenfarben, wenn man pixelweise oder zeilenweise die Farben wechselt. Vielleicht könnte man alle darstellbaren Variationen der einzelnen Flächen vorberechnen, indem man bspw. nur eine Steigung von max. einer Höhe zu einem benachbartem Feld o.ä. zulässt. )))

Zu der Umsetzung der Landschaft mit Pixeln habe ich mir einwenig mehr Gedanken gemacht:
In dem Video besteht der sichtbare Ausschnitt aus 12x10 Flächen, d.h. es müssten 13x11 Pixel ermittelt werden. Diese 13x11=143 Bildpunkte müssten also für unterschiedliche Höhen vorliegen.
Wenn man die möglichen Höhen begrenzen und vorberechnen würde, könnte man einfach die x und die y Position für den jeweiligen Punkt aus einer Tabelle auslesen.
Da 143 Punkte eine für 8-Bitter ungerade Zahl ist, könnte man max. 128 Punkte anstreben, so dass x und y Position in eine Page passen, d.h. für eine Fläche (oder Tiefe, je nachdem von welcher Richtung man das Spielfeld aufbauen möchte oder betrachtet) mit bspw. 16 Höhen, bräuchte man nur 4 kb, was sich sicherlich verschmerzen ließe.
((( Die Wurzel aus 128 ist ca. 11, d.h. 11x11x16x2 wäre eine solche Beispielrechnung. )))

Ein Bildpunkt im Level könnte als Byte gespeichert werden (evtl. sogar über ein Tileset), wobei dann 4-Bit für die Höhe und 4-Bit für die Farbe (oder evtl. ein Landschaftsmerkmal (bspw. Baum)) verwendet werden könnten.
(...)

Im Anhang ist ein kleines Experiment zu der Landschaftdarstellung über Pixel.
Der dargestellte Ausschnitt ist 16x8x16 Punkte groß. Die Ausgabe erfolgt im MC-Bitmap-Modus.
Die Map ist 256x64 Punkte groß.
Natürlich ist alles nicht optimiert und sieht schrecklich aus.
Der Bildaufbau ist momentan etwas langsamer als ein Frame, weshalb man das Löschen sieht.
Die Map selbst ist max. 11 Stufen hoch, d.h. hier könnte man etwas Dynamik reinbringen, vor allem weil die Map auch außerhalb des sichtbaren Bereichs, wie im Spiel, angezeigt werden könnte.
((( Ein einfacher nächster Schritt, wäre wenn man den Pixeln einfach unterschiedliche Farben, entpsrechend der Höhe gibt (bspw. Blau, grün und weiß oder grau) oder evtl. die Dichte vergrößern würde. Doublebuffering wäre dazu sicherlich notwendig. )))

testzarch.prg

Hallo Retrofan, Dein Mockup geht schon sehr in die Richtung, was ich mir unter Manimalismus für eine GUI vorstelle.
Besonders die Menüleiste und die Titelleiste. Ich würde auf die Zeichen mit dem Rahmen, die im Scrollbalken auftauchen, auf der ganzen Oberfläche verzichten, d.h. auch zwischen den Eingabefeldern und den Buttons. Das Fieldset und einige andere Kleinigkeiten, würde ich auch anders gestalten.

Das ist nicht als Kritik oder Aufforderung o.ä. gedacht, sondern nur als Info. Geschmäcker sind ja unterschiedlich...

Ich habe eine Frage. Gibt es einen Hires Editor, in dem man direkt Zeichen (aus dem Zeichensatz oder Rom) einfügen kann?
Welchen Editor hast Du benutzt? (Ich würde gerne meine Vorstellung als Mockup umsetzen, nur um zu sehen, wie diese wirken würde.)

Ich komme heute definitiv. Ich freue mich schon. Bis später.

Ich versuche zu kommen. (Entschuldige, dass ich momentan keine genauere Antwort habe. Aber ich komme gerne.)

Quote from Telespielator

Das finde ich auch und obwohl ich leider über rudimentäre BASIC-Kenntnisse nie hinaus gekommen bin, möchte ich den Vorschlag in den Raum stellen, ein 4-Spieler-Autorennen zu programmieren. Hier mal ein grober Entwurf, wie ich mir das vorstelle:
Es gibt ja zahlreiche Spiele, wo mehrere Spieler auf einem gemeinsamen Parcours um die Wette fahren. Ich habe mich gefragt, ob es nicht
möglich sein könnte, einen 4-Spieler-Splitscreen zu realisieren. Dabei sähe jeder Spieler den kleinen Abschnitt der Strecke, auf dem er sich gerade befindet und vom Gameplay wäre das dann ähnlich wie Rally Speedway. Auf dem obigen Bild sieht man in der Mitte die Strecke und wo sich welcher Fahrer gerade befindet, unten sieht man, dass der gelbe und der lila Rennwagen sich gerade vor der Ziellinie befinden. Was noch fehlt sind Eingeblendete Rundenzeiten und Anzeige der jeweiligen Runde, sowie Position des eigenen Spielers. Vielleicht könnte man sogar noch weitere Computergegner realisieren. Was meint Ihr dazu?

Die Spielidee finde ich sehr gut, weil Sie schön in meine Crap-Game Sammlung passen würde.

Zur Umsetzbarkeit der Strecke ist mir nur folgende Idee gekommen:
- Man speichert das Level 4 mal ab und scrollt immer um 4 Pixel.
- Die Strecke liegt also einmal im Original vor, einmal um 4 Pixel nach links verschoben, einmal um 4 Pixel nach oben und einmal um 4 Pixel nach oben und nach links verschoben vor.
- Am besten kann man sich das mit den Blöcken aus dem Petscii-Zeichensatz vorstellen. Ich habe das jetzt nicht zuende gedacht, aber es könnte auch sein, dass mehr Details möglich sind. Die einfachste Vorstellung ist der Original-Zeichensatz im Hires-Charset-Modus mit dem Hellgrau als Hintergrundfarbe und dem Grün als Vordergrundfarbe (so wäre die Hardware-Sprite-Hintergrundkollision nutzbar).
- Die Stecke muss nicht bei Programmstart in der Form vorliegen, sondern könnte aus einer 1-Bit Bitmap entpackt werden.

Angenommen man würde 32KB für die Strecke reservieren, dann wäre das "echte" Level ein viertel davon groß, d.h. 8 KB würde einer Größe von 128x64 Zeichen entsprechen. Die 1-Bit-Bitmap, um diese 8KB zu füllen wäre also 32Byte*64Byte = 1KB groß.
128x64 Zeichen (=Die Dimensionen der Strecke) entsprechen ca. 3x2,5 Bildschirmen.

Zur Darstellung der Autos genügen 2 Rasterirqs. Ein Ausschnitt für einen Spieler könnte 20x12 Pixel groß sein. Wenn man "Glück" hat und schön optimiert, könnte man jeden Frame ein Bildschirmupdate machen...

Nachfolgend ein Screenshot zu einem unoptimierten Test, in dem ich 20x10 Pixel für jeden Spieler update. Der Cyan-farbene Bereich zeigt die freie Zeit an. Wenn man jeden zweiten Frame ein Update durchführen würde, hätte man mit Sicherheit keine Hürden.

Was ich noch anmerken wollte ist, dass im Rasterzeileninterupt/"Spritemultiplexer" die Farben und die Spriteblöcke nicht neu gesetzt werden müssen, weil sie immer gleich bleiben. (Im Speicher würde man z.B. 16 Richtungen für das Fahrzeug bereithalten.)
(...)

Nicht, dass ich das jetzt programmieren möchte, aber wie hast Du Dir die Steuerung durch die anderen Spieler vorgestellt?
4 Joysticks oder 2 Joystick + 2 mal Keyboard ?
(...)

Wenn man noch einwenig weiterspinnt, könnte man sich auch andere Spiele in dieser Form vorstellen:
- z.B. etwas Gauntlet ähnliches oder irgendetwas wie Pacman, in dem 2 Spieler 2 andere jagen usw.usf....

Sehr schön Sokrates. Mir gefällt die Ansicht im 1-Spieler Modus.

Ich wünsche euch allen Frohe Weihnachten mit einem weiteren Crapgame "Happy Deer Hunter".
(Das Spiel sollte wahrscheinlich besser "Crappy Deer Hunter" heißen.)

Storyline:
Santas Hirsche haben eine neue Form von Rinderwahnsinn eingefangen und sind geflohen.
Hilf ihm, indem Du sie mit Deinem Gewehr betäubst, damit Weihnachten rechtzeitig gefeiert werden kann.
Feuer drücken, um Deine Mission zu starten - und erinnere Dich daran, dass keine Tiere verletzt werden
HOHOHO, frohe Weihnachten

Viel Spaß damit
5ace

Momentan kann ich keine Termine festlegen.
Gerne bin ich wieder dabei. Ich lasse euch mal planen und gebe dann kurzfristig bescheid.

Quote from CapFuture1975

Wäre es dann nicht besser, den Threadtitel ändern zu lassen, sonst findet das doch keiner!
WOWXS ist gar nicht schlecht, würde nur noch mehr Spaß machen, dass wenn die Monster durchgelaufen sind, einem Punkte wieder abgezogen würden.

Danke CapFuture1975 für Dein Feedback.
Ja, das stimmt mit Threadtitel.
Die Idee mit dem Punktabzug werde ich in einer nächsten Version von WOWXS einbauen.

Hallo an alle,

nachfolgend noch ein extrem simples "Spielchen" (als Übung in einer Sizung entstanden) mit einer Größe von 1.473 Bytes für den C64, wovon 896 Bytes auf die Sprites entfallen.
Ich werde alle "Crapgames", die noch so auf diese Weise entstehen, einfach unter dieses Thema posten.

Viel Spass damit (evtl. als Idee für ein loader-game o.ä..)
5ace

Ich bin auch da.

Hallo an alle,

anbei ein kleines und extrem simples Spielchen.
Es handelt sich um ein Atari Combat-ähnliches "Spiel", wenn man es so nennen kann, in 790 Bytes für den C64.
Danke für die Idee und viele Grüße an den Frankfurter Nerd Stammtisch.

5ace