letzter Beitrag von 5ace am
Das koennte man mal probieren, mit der Steuerung. Muss man testen um zu wissen wie es sich anfuehlt 
Je nach Gameplay kann man schon 2 Dinge zusammenlegen, das ist schon korrekt... aber ob man damit auch "fein dosieren" kann ist halt fraglich. Manchmal will man vielleicht NUR Schub ohne Aufstieg... oder umgekehrt... also das kann ich jetzt so nicht beurteilen.
Aus Sicht der Flugphysik wäre es logischer dass Du langsamer wirst beim Hochziehen. Kostet ja Energie. Beim Drücken wird man schneller.
Speicher ist nicht alles – und hier erstmal nicht der Flaschenhals. Die CPU-Leistung ist wichtig. Es scheint so, dass der Z80 ohnehin besser geeignet ist für Berechnungen, wie man sie für 3D benötigt. Und dann kommt vor allem hinzu, dass die Z80-Rechner fast immer deutlich schneller getaktet waren (der Specci mit rund 3,5 MHz) als die 6502-Konkurrenz (vor allem der C64 mit seinem rund 1 MHz).
Retrofan Sehe ich ein mit der CPU-Leistung, in dem Fall sollte man mal überlegen ob man nicht den C128 mit seiner Z80-CPU verwenden kann um Zarch darauf umzusetzen, der
hat zwar nur 2 MHZ, aber wenn der Z80 besser für Berechnungen geeignet ist, insbesonders für so ein Spiel, böte sich der C128 doch an .
Aus Sicht der Flugphysik wäre es logischer dass Du langsamer wirst beim Hochziehen
Es geht nicht darum, eine Physik-Simulation zu erstellen. Vom Gefühl muss es passen. Die Flugzeuge, mit denen ich geflogen bin, waren auf jeden Fall am Boden langsamer als hoch in der Luft. 
Muss man testen um zu wissen wie es sich anfuehlt
Ja, das ist richtig. Das ist halt klasse, wenn ich z.B. mit ALeX zusammenarbeite – der schreibt dann mal schnell in Python oder ähnlichem eine kleine Demo (weil das viel schneller geht als in Assembler) und an der können wir dann herumoptimieren, bis es gut ist (oder eben auch nicht).
in dem Fall sollte man mal überlegen ob man nicht den C128 mit seiner Z80-CPU verwenden kann
Oder gleich einen richten Z80-Rechner. Ich dachte, hier ginge es um eine C64-Version.
Oder gleich einen richten Z80-Rechner.
Retrofan Der C64 steckt ja auch in dem C128, also zwei Fliegen mit einer Klatsche. 
Aber vielleicht wäre es möglich den Z80 für den C64-Modus zur Berechnung einzusetzen .
Oder gleich einen richten Z80-Rechner.
Retrofan Der C64 steckt ja auch in dem C128, also zwei Fliegen mit einer Klatsche.
Aber vielleicht wäre es möglich den Z80 für den C64-Modus zur Berechnung einzusetzen .
Eher nicht, denn das Umschalten zwischen 8502 und Z80 kostet Performance. Auch die 2 MHz des 8502 nützen nicht so viel, weil dann ja das VIC-Videosignal nicht dargestellt werden kann.
Wobei Deine Darstellung ja auch "Ecken und Kanten" hat - damit meine ich jetzt nicht die kuenstlerische Ausfuehrung, sondern ich meine jetzt tatsaechlich landschaftlich gesehen
Ich hatte die Darstellung deshalb gewählt, weil ich so mögliche Farbprobleme nur auf der vertikalen Achse habe, horizontal bleibe ich ja im Char-Raster. Und dann habe ich die Boden-Farben so gewählt, dass immer nur eine Color-RAM-Farbe auf eine MC- oder Hintergrundfarbe treffen kann. Ich habe also typischerweise hellgrün/grün-Wechsel (wobei grün die ColorRAM-Farbe ist) und bei Virus-Befall verwende ich hellrot/rot (wobei wieder die dunklere Farbe die ColorRAM-Farbe ist). Man kann dann entweder per Farbwechsel der ColorRAM-Farbe oder durch ändern des MC-Color-Bitmusters jede Kachel individuell "infizieren". (Zumindest, wenn ich nicht wieder einen Denkfehler eingebaut habe)
Aber vielleicht wäre es möglich den Z80 für den C64-Modus zur Berechnung einzusetzen
Es bliebe damit ein C128-Spiel. Hier ging es aber bisher um ein C64-Spiel. Wie gesagt, wenn man den C128 nehmen will, kann man genauso gut (eigentlich besser) den CPC als Zielplattform wählen.
Wie gesagt, wenn man den C128 nehmen will, kann man genauso gut (eigentlich besser) den CPC als Zielplattform wählen.
Gnade, bitte nicht (CPC). 
Hoffentlich liest oobdoo nicht mit. 
... kann man genauso gut (eigentlich besser) den CPC als Zielplattform wählen.
Der Archimedes würde sich dafür auch gut eignen.
Mir fällt auf, dass weiter hinten liegende Flächen nicht wirklich verdeckt werden, dafür ist die Landschaft zu flach.
Sorry, ist leider schwer, einen guten Schnappschuß zu machen, aber ich denke, man kann hier schon erkennen, wie die vorderen Flächen die hinteren verdecken. Außerdem sieht man, daß die Flächen nicht nur von oben gemalt werden, sondern je nach Kameraposition auch von unten.
Der Wunsch nach einem neuen, ansprechenden 3D- Spiel auf dem C64 ist ziemlich gross, alle Jahre wieder erscheint hier ein entsprechender Thread.
Mit dem Ergebnis, das der C64 dafür einfach nicht geeignet ist. Alles was machbar ist, gibt es schon, viel mehr geht einfach nicht.
Nur Zusatzhardware wie ein Chip auf dem Spielemodul wie beim Super Nintendo, welcher die Berechnungen übernimmt, würde etwas schickeres und spielbares ermöglichen. Das wurde glaube ich zuletzt im Mario Kart- Beitrag angesprochen.
ich denke, man kann hier schon erkennen, wie die vorderen Flächen die hinteren verdecken.
Wir können sicherlich festhalten, dass die Höhenunterschiede des Geländes durchaus groß sind. Die Frage ist doch eher, ob das wirklich spielentscheidend ist bzw. spielentscheidend sein muss für einen 2.5-D-Port auf einem schwächeren System. Ja, es sieht schön aus und man muss sicherlich darauf achten, dort nicht reinzukrachen – aber es gibt auch genügend andere Hindernisse und Herausforderungen.
Alles was machbar ist, gibt es schon
Selbst die hier diskutierte, abgespeckte 2.5D-Variante wäre in vielen Aspekten neu für den C64.
Nur Zusatzhardware wie ein Chip auf dem Spielemodul wie beim Super Nintendo, welcher die Berechnungen übernimmt, würde etwas schickeres und spielbares ermöglichen.
ALeX hat sogar schonmal einen Grafikbeschleuniger-Prototyen gebaut, der dem VIC vorberechnete Bitmap-Sachen "einfach" per DMA unterjubelt. Ich hatte das dann gedanklich für 3D erweitert (benötigt dann aber eine andere CPU, z.B. Pi Zero) und auch schonmal hier im Forum zur Diskussion gestellt.
Das hier könnte der VIC problemlos mit 50 fps darstellen (bei nur 4 Farben sind auch keine Color-Clashes zu erwarten) – wenn eine CPU in einem Cartridge vorher die Berechnung und Rendering/Rasterung übernimmt.
Aber auch das wirft Fragen auf: Z.B. wie viel der Spiel-Logik müsste mit auf der externen "GPU" laufen, damit die CPU/GPU-Kommunikation nicht zum Flaschenhals wird.
Der Archimedes würde sich dafür auch gut eignen.
Und ein aktueller PC erst. Vielleicht als Demo für die neuen M1-Macs?
Die letzte U64 fw hat gewurmt, daher mit etwas Verspätung die
2arch64 Demo V2
Neue Features:
Ballern, Treibstoff, Auftanken auf dem Landing pad, statische Landschaft, andere Kollisionsabfrage, Absturz im Wasser.
Mehr wird das nicht. War nur zum Spaß und dient mir als Basis für andere Spielideen.
auch wenn's nicht groß auffällt, kleiner bugfix
Also das Flugverhalten lässt schon richtiges Virus Feeling aufkommen. Wenn das Schiff dann noch Animiert wäre und die Landschaft scrollt, wäres ne echt feine Sache.
Gefällt mir schon richtig gut.
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.
(...)
Virus auf dem C64? Da muss ich schmunzeln, das war ja schon auf dem langsamen Amiga schrecklich. Das Spiel war auch nie des Spieles wegen interessant, sondern eben wegen der flinken 3D-Leistung. Das war das was mich damals beeindruckt hatte. Virus in 2D ist so interessant wie der Maze Bildschirmschoner in Windows. Aber das ist nur meine persönliche Meinung.
Es gibt übrigens noch ein ähnliches Spiel namens Hyperion (kann mich deshalb so gut erinnern weil das in der einzigen Playtime-Ausgabe (5/94) ist, die ich damals zusammen mit meinem C64 zum Geburtstag bekommen habe. Die habe ich etliche Male durchgeblättert und ne Magic Disk & Game On war auch dabei. Jedenfalls wurde da Bezug auf "Virus" genommen, aufgrund der ähnlichen Grafik)
