zatzen hat geschrieben:Sorry dass ich den Thread ausgrabe, aber ich habe mir nochmal ein paar Gedanken zu ZVID gemacht.
Ich erinnere mich schwach daran, dass damals, in echtem DOS, die Konfiguration, ob man EMS oder XMS verwenden wollte nicht immer so einfach war und teils eine Bootdiskette erforderte, nur damit man ein Spiel spielen konnte.
Naja, das - oder eben ein Bootmenü. Ich selbst habe es auf eine eher einfache Art gelöst: Ich habe ein Unterverzeichnis, in dem verschiedene AUTOEXEC.xxx und CONFIG.xxx Files liegen und einen Haufen Batch-Files, mit denen ich dann aufrufe, welche davon in's Root kopiert werden als AUTOEXEC.BAT und CONFIG.SYS. Dann einfach Affengriff (CTRL-ALT-DEL) und schon bootet der mit neuen Einstellungen. (Ja, ich weiß: Man könnt auch ein nicht mal 10 Byte großes Assembler-Programm bauen, das den Neustart alleine macht. Aber falls ich mal versehentlich die falsche BAT aufgerufen habe, kann ich das noch ändern, bevor ich reboote.)
zatzen hat geschrieben:In Dosbox ist das zwar anders, aber in Anlehnung an damalige Umstände würde ich dabei bleiben, nur den konventionellen RAM zu benutzen.
Ja, ich nutze auch kein EMS (obwohl es manchmal praktisch wäre - gerade für den Soundpuffer z.B.) und XMS versuche ich auch zu vermeiden. Manche meiner Tools bieten es an - für Spiele werde ich es wohl vermeiden. Man kann Levels/Grafiken u.ä. schließlich auch von Festplatte nachladen und daß bei einem Levelwechsel oder solchen Dingen mal eine kurze Ladezeit nötig ist (dauert ja nicht wirklich lange auf einem PC), sollte wohl keinen stören.
zatzen hat geschrieben:Gleichzeitig hält mich das bei der Stange, sparsam mit den Ressourcen umzugehen.
Gute Entscheidung. Sparsamer Umgang mit Ressourcen erlaubt mehr Systeme, auf denen Spiele/Tools lauffähig sind (also auch mehr Leute, die es benutzen können/wollen) und außerdem hat man "Luft nach oben", wenn man mal "etwas mehr" in ein Spiel/Tool einbauen will.
zatzen hat geschrieben:Daher würde die Verwendung von ZVID durchaus Sinn ergeben. Wenn man bedenkt dass eine NES Konsole mit ihren 64K (wovon nicht einmal alle verwendbar fürs Spiel sind) schon mit sehr komplexer Grafik aufwarten konnte, dann sollte es doch möglich sein, in 640K mindestens genausoviel unterzubringen.
Ja, dazu hab ich letztens ein tolles Video gefunden. Da haben paar Leute n aktuelles Spiel für NES geschrieben und erklärt, wie sie es geschafft haben, mit den beim NES freien 40 kByte auszukommen. An so etwas sollten sich viele Leute ein Beispiel nehmen:
https://www.youtube.com/watch?v=ZWQ0591PAxM
In irgendeiner 64'er wurde auch mal erklärt, wie es Manfred Trenz damals schaffte, so große und abwechslungsreiche Levels in Katakis zu ermöglichen. Das Level scrollt ja die ganze Zeit von rechts nach links (Raumschiffshooter). Er hat es nicht als "Kacheln" mit fester Größe ausgeführt, sondern das ganze mit (Selbstbezeichnung) "Modulen" gemacht. (Anm.: Fast alle C64-Spiele sind im Textmode. Nur daß man die Textzeichen selbst verändern kann, so daß sie wie Grafik aussehen, auch mehrfarbig möglich.)
Er hat dann einfach so "Einzelteile" (Module) definiert, die eine bestimmte Größe (Breite*Höhe) haben, also aus Breite*Höhe Zeichen bestehen, und im Level ist dann nur ein Vermerk, daß an aktueller Position, Zeile Y, ein Modul anfängt. D.h. wenn das Level an diese Position gescrollt war, brauchte für die entsprechenden Zeilen nur das Modul gestartet werden und ein Zähler (Countdown) drin sein, der die Breite runterzählt. Solange kein Modul da war, wurden Hintergrundzeichen ausgegeben. (Da gibts auch einen Trick: Wenn man ein oder mehrere solcher Zeichen nimmt und sie entgegengesetzt zur Scrollrichtung mit halber Scrollgeschwindigkeit "rotiert", hat man einen "räumlichen" Hintergrund aus "Patterns", der halb so schnell scrollt. Auf den Trick bin ich irgendwann selber mal gekommen.)
zatzen hat geschrieben:Das Vorgehen von ZVID ist der NES Konsole mehr oder weniger ähnlich, es unterteilt auch alles in 8x8 Blöcke und verwendet dort nur so viel Bits wie nötig. Bei der NES hat ein Block immer 2 Bit pro Pixel, also 16 Byte pro Block.
Ja, im NES (und vielen alten Konsolen) ist das hardwaremäßig (im Grafikchip) gelöst.
Eigentlich ist das Ganze nur eine Erweiterung der Funktionsweise des Textmodes. Der PC hat ja so etwas auch. Der Textmode ist, technisch gesehen, eigentlich der komplexere Modus. 24bit/32bit-Grafikmode (16777216 Farben) dagegen ist schaltungstechnisch eigentlich das simpelste, was es gibt: Das kann so wie es ist, direkt aus der VGA-Buchse rausgedonnert werden, ohne jegliche Nachberechnung. Der Textmode dagegen holt Farbnummern aus dem Speicher, die er erst aus Tabellen in RGB-Farben umwandeln muß und entsprechend dem Bitmuster der Textzeichen (je nachdem in welcher Zeile er sich befindet) an die VGA-Buchse schicken muß. Wenn dann noch Sprites dazukommen (VIC-II beim C64 oder die diversen anderen Grafikchips wie z.B. der im NES), ist das ganze Schaltungstechnisch noch anspruchsvoller. Lineare (Framebuffer) 24/32bit-Vollgrafik ist schaltungstechnisch so ziemlich das primitivste was man machen kann, Multicolor-Textmode mit Sprites, Kollisionsabfrage, Rasterzeilen-Interrupt und Lightpen/-gun Abfrage (und das auch noch mit ca. 14 MHz Takt, den der VIC-II hatte), inklusive RAM-Refresh, CPU-Controlle u.ä. ist technisch wesentlich anspruchsvoller.
(Ja, man merkt: ich habe großen Respekt und Anerkennung für die damaligen Entwickler. Heutzutage wird ja alles bloß noch mit möglichst hohem Systemtakt/Systemleistung erschlagen...) Na egal.
Jedenfalls: So tile-basiert ("gekachelt") funktionieren ja auch meine ganzen Levelroutinen (nur eben in Software). Bisher für Levels mit 16x16-Pixel-Blocks und 32x32-Pixel-Blocks (16x16 sogar bis zu 4 unabhängige Ebenen!). Aber es wäre für mich auch technisch kein Problem, 8x8-Blocks zu ermöglichen. Es ist eben so, daß ich bei Levels ganz gern für jeden "Block" nur ein Byte nehmen will, also bis zu 256 mögliche Blocks. Bei Blocks in 8x8 bräuchte ich zu viele Blocks, um daraus sinnvolle Objekte zu machen und wäre ganz schnell bei 256 - und dann würde das ganze Level irgendwie "an jeder Ecke gleich aussehen". Bei 32x32-Blocks (wie in Xpyderz) nutze ich nur 64 Blocks (jeder 16 aus 256 Farben, mit Paletten) brauche dafür dann 32kByte für alle Blocks (+1kByte für die Paletten), bei 128 Blocks bräuchte ich 64kByte (+2kByte Paletten). 256 Blocks würden dann schon 128kByte brauchen, außer, ich würde sie 4farbig machen. Aus Gründen der Performance (und des Speichers) möchte ich aber bei Blocks nicht mehr als ein Segment (64kByte) benutzen.
Daher erscheinen mir 16x16er Blocks der beste Kompromiß. (So ist es auch in vielen alten Konsolen - z.B. Sega Master System, NES.) Daß die 16x16 Pixel-Blocks auf so Systemen trotzdem "rechteckig" aussehen, liegt an deren Auflösungen, in den Pixel NICHT 1:1 sind. (z.B. 256x256 oder 256x240) - und ja! Ich kann solche Auflösungen auch einstellen (habe eine Unit dafür gebaut), sieht echt "konsolenmäßig" aus. Nur auf DOSbox (im Fenster) nicht so schön, weil DOSbox da immer quadratische Pixel machen will.
Natürlich könnte man auch 320x200 Mode (oder 320x240) benutzen und 20x16er oder 24x16er Blocks machen (damit es "wie Konsole" aussieht), aber ich schätze mal, jeder, der mal programmiert hat und sich ein wenig mit dem binären System auskennt, weiß, warum die Idee nur so halbgut ist...
Na gut, etwas ausführlicher als nötig. Wollte nur anmerken: Wäre möglich. Wie genau ein "Actionspiel" unter Verwendung von ZVID funktionieren würde, kann ich nicht sagen. Ich selbst "packe" ja auch Pixel (um z.B. aus 1 Byte 2 Pixel zu machen, für meine 16farbigen Elemente), aber bei Spielen neige ich dazu, das so zu machen, daß ich, egal wo "sich das Level/Figur gerade befindet", immer schnell und direkt die Farb-/Pixelwerte ermitteln kann. Ein komplizierteres Packverfahren würde vielleicht weniger Speicher benötigen (dafür mehr Programmspeicher - und weil wir "Von-Neumann-Computer" haben, ist es sowieso der gleiche RAM!) und noch dazu mehr Rechenzeit zum "Entpacken" und wäre, was Anordnung oder eventuelles Scrolling angeht, nicht so flexibel.
Natürlich wäre es (ZVID u.ä.) andererseits (gegenüber "gekachelten" Levels) ein großer Vorteil z.B. bei Hintergründen in Adventures, die sehr effektiv gepackt werden könnten und somit speichersparend wären - in so Hintergründen findet dann keine oder eher sparsame Hintergrundanimation statt, wofür ja ZVID von vornherein schon ausgelegt ist. Eventuelle Figuren oder Mauszeiger könnte man dann "davor" in getrennten Routinen behandeln.
Anm.: Ich habe auch schon wirklich mal darüber nachgedacht, ein grafisches und scrollendes, Spritebasiertes Spiel komplett in Textmode zu machen. Die Scrollregister der Grafikkarte funktionieren auch im Textmode, außerdem kann man auch mehrere "Bildschirme" haben (für Double-Buffering) und 8 verschiedene Zeichensätze (von denen 2 gleichzeitig eingeblendet sein können). Das "9. Bit" (das den Zeichenabstand erhöht) kann man bekanntlich ausschalten. Und Zeichen können 2 bis 32 Pixel hoch sein. (Zeichen kann man natürlich verändern.) Es wäre also möglich, ein Spiel zu programmieren, das aussieht wie 16farbige Grafik, mit Sprites und wenn man dabei geschickt vorgeht, würde es nicht einmal an Textmode erinnern. Den 256-Farb-Textmode (bei halber horizontaler Auflösung), den ich mal auf meiner ET-4000-basierten Grafikkarte im 486er gefunden habe, kann ich ja leider nicht verwenden - der wird nicht generalisiert unterstützt. D.h. viele Grafikkarten haben den nicht und Emulatoren kennen den auch nicht. Schade.
Aber mit den Softscroll-Registern UND Double-Buffering UND Zeichensatz-Manipulation sollte es möglich sein, ein Spiel zu bauen, das sogar auf langsamen Systemen noch richtig performt, weil das "Kacheln" ja von der Hardware (Grafikkarte) übernommen werden würde - es müssen ja nur so ca. 1000 bis 2000 Zeichen + Farbbytes in den Bildschirm gesetzt werden - das schafft selbst jeder XT im Schlaf).
zatzen hat geschrieben:ZVID kann auch, wenn es passt, die Daten pro Block auf 8 Byte
schrumpfen wenn nur zwei Farben vorhanden sind, oder auf nur ein Header Byte
mit Farbinformation wenn es sich um einen einfarbigen Block handelt. Gleichzeitig
hat man immer noch die Möglichkeit, auch Blöcke mit vollen 64 Farben zu nutzen,
mehr als 6 Bit pro Pixel werden nie benötigt, und im Schnitt sind es bei voller
256 Farben Ausnutzung 4-5 Bit.
Ja, aber wie ich immer wieder bemerke, zielt das Ganze darauf ab, Levelhintergründe zu "malen" und sie dann in ZVID-generierte "Bilder" zu verwandeln, damit die "Fliesen" nicht erkannt werden, sondern es ein durchgehendes Bild ist. Sieht dann sicher schön aus - aber dann würden ja auch noch "Meta-Daten" benötigt werden, damit die Figur mit einem solchen Level "interagieren" kann - d.h. auf bestimmte Bereiche springen, von Absätzen herunterfallen usw. Beim "kachelbasierten" Ansatz kann man den "Kacheln"/"Fliesen" gleich diese Eigenschaften zuweisen und die Levels dann aus diesen Kacheln bauen, ohne zu überlegen, ob/wie sie funktionieren, weil die Funktion gleich mitgegeben ist.
"Gekachelte" Levels müssen übrigens nicht wirklich auch so aussehen - d.h. man muß hier keine Gitter-Begrenzungslinien benutzen oder so "quadratische Steinblöcke", wie es in diesen "retro" Spielen der Fall ist. Diese "Kacheln" sind ja auch nur ein "kleines Stück Grafik" und wenn man sie entsprechend gestaltet, kann man sie auch nebeneinandersetzen, ohne daß man den "Übergang" bemerkt. Andererseits ist man damit auch in gewisser Weise flexibel - denn wenn man "Kacheln" so gestaltet, daß sie an mehrere andere "Kacheln" passen, kann man diese immer wieder neu kombinieren und damit die Flexibilität der Levels erhöhen, ohne mehr Speicher für Grafiken/Grafikelemente zu brauchen.
zatzen hat geschrieben:ZVID erreicht eine gute Kompressionsrate. Interessanterweise werden ZVID-komprimierte Grafiken von Algorithmen wie ZIP noch einmal deutlich kleiner
gepackt als wenn man diese Grafiken direkt mit letzterem packt.
Klar, denn ZIP und ähnliche sind ja auf "Archivieren" ausgelegt, d.h. auf Speichern auf möglichst kleinstem Raum, um "weggepackt, aber trotzdem noch da" zu sein. Methoden wie ZVID oder auch meine Methoden dienen ja eher dazu, daß man auf die gepackten Daten auch im laufenden Prozeß noch zeitnah zugreifen kann. Ich kann mir nicht vorstellen, daß es irgendeinen Rechner in "unserem" MHz-Bereich (Kategorie "späte DOS-Computer") gibt, der ZIP-gepackte Grafikdaten live entpacken und dabb mit 50fps live anzeigen könnte. Von daher würde ich mir keine Sorgen darüber machen, daß Dinge wie ZIP "besser" packen. Das Effizientere Packen erkauft man sich dafür eben mit mehr Rechenzeit zum Entpacken, d.h. es spart Speicher, performt aber nicht in einem Spiel.
zatzen hat geschrieben:Bislang habe ich in ZVID kein Clipping realisiert. Aufgrund der Blockstrukturierung und der für jeden Block potentiell anderen Kompressionsart ist es mir bisher zu komplex gewesen, ein Clipping, also das Abschneiden von Sprites, wenn diese
aus dem Bildschirm hinausragen, einzubauen.
Naja, wie bereits mehrmals erwähnt, wäre so etwas auch nicht unbedingt nötig (genausowenig wie Scrollen), um ein Spiel zu bauen, das Spaß macht.
zatzen hat geschrieben:Aber ich gehe einen Kompromiss ein.
Man kann auch ein Spiel so gestalten, dass alle bewegten Objekte im Bildschirmbereich
bleiben. Und auch Scrolling braucht ein Spiel nicht unbedingt. Es kann sogar ganz reizvoll
sein, in einem "Dungeon" seine Wege durch verschiedene Ebenen zu gehen, und dabei
bisherige Bildschirme erneut zu sehen, bloß dass man sich dabei auf einer anderen
Plattform befindet - das hat ein bisschen einen Irrgarten-Effekt.
Im Prinzip habe ich das auch so bei meinem Spiel "Kotzman II" gemacht.
Und dort will ich im Grunde auch nur anknüpfen, nur diesmal mit transparenten
Sprites, und mit meinem Musik-Sound Player. Der frisst zwar relativ viel
Rechenleistung, aber ein 486er reicht da allemal.
Ja, sag ich doch...
zatzen hat geschrieben:Man könnte meinen, ein DOS-Spiel müsste mindestens auf einem 386er oder am besten auf einem 286er lauffähig sein. Ich kann dazu aber nur sagen, dass
ich 1993 von einem 286er auf einen 486er gewechselt habe, und plötzlich
liefen alle Spiele flüssig. Und nicht alle von denen, die auf dem 286er langsam
waren, benötigten Erweiterungsspeicher.
Ja, nur meine einfachen Textmode-Spiele (4 Gewinnt, Pentomino...) laufen auf 286er, alles "grafische" ist bei mir schon ab 386er ausgelegt.
Ob ein Spiel mit meiner Game-Engine, meinen Grafikroutinen und meinen Synthesizer-Routinen auf einem 386er noch gescheit performen würde, kann auch bezweifelt werden (hängt auch von der Anzahl Sprites/beweglicher Elemente und von der Anzahl im Synthesizer benutzten Stimmen ab). Ich denke, um meine künftigen Spiele vernünftig spielen zu können, wird auch eher ein 486er vonnöten sein. Wahrscheinlich könnte ich auch ein Spiel machen, das auf XT oder 286er gescheit läuft (so wie der 8-Bit Guy mit "Planet X3", siehe Youtube), aber meine derzeitigen Routinen sind nicht dafür ausgelegt - sie sind inzwischen schon zu "32bit-verseucht".
zatzen hat geschrieben:Es gab zu dieser Zeit einige Konvertierungen vom Amiga.
Speicher war nicht das Problem, weil die 500(12?)K vom Amiga gut in die 640K vom PC passten. Lediglich das, wofür der Amiga Hardware hatte, also z.B. die Musikausgabe, musste beim PC per Rechenleistung erledigt werden.
Nicht zu vergessen, daß der Amiga Hardware-Sprites und Semi-Hardware "BOB"s hatte (Stichwort Blitter), was auch eine Menge Rechenleistung gegenüber echten Software-Sprites und Software-Fullscreen-Levels spart. Das muß auf PC ja alles in Software - über die CPU - erledigt werden.
zatzen hat geschrieben:Fazit für mich also: Real Mode ohne XMS oder EMS und 486er sind durchaus legitim.
Und: Es gibt gute "Jump&Runs" ohne Scrolling, so auch Prince of Persia. Da ist zwar
Clipping mit dabei, naja, aber vielleicht schaffe ich es ja doch das Clipping bei
ZVID wenigstens blockweise umzusetzen und setze den Bildausschnitt auf 306x186.
Oder ich mache einen entsprechend "breiteren" (336 Pixel) Bildschirmpuffer, der mir
dann wenigstens die volle Breite erlaubt bei immerhin 179 (65528 / 336 - 16) Zeilen,
wobei ich 181 Zeilen anzeigen könnte, da ein Block erst verschwindet wenn schon
der nächste einen Pixel nachgerückt ist.
Ja, alles möglich und macht auch Sinn. Außerdem könnte man die restlichen 20 (21) Zeilen ja auch für eine hübsche Anzeige der Werte (Punkte, Leben, Items) benutzen und hätte somit gleich eine "Entschuldigung" dafür. Dann wäre das nicht einmal ein "Problem"
zatzen hat geschrieben:Ansonsten bleibt immer noch die Möglichkeit, ZVID nur für feststehende Objekte bzw. Hintergrund zu nehmen, und für Sprites etwas simplere Methoden, wo die
Kompression zum Beispiel zeilenweise stattfindet. Das aber nur, wenn ich die Kompromisse beim Clipping bei ZVID umgehen will.
Ja, der Möglichkeiten gibt es viele. Die beste Idee, die ich dazu habe (auch wenn das, geht man von meinem Zeug aus, etwas komisch klingt) ist: Einfach mal damit anfangen!
Meine alten Spiele habe ich auch einfach "in die Maschine gehackt" ohne Vorbereitung. Xpyderz ist intern ein über Jahre gewachsenes "zusammengeschustertes" Ding.
Xpyderz hatte zu Anfang z.B. keine Assembler-Anteile! Es war 16 farbig, aber trotzdem im 320x200 256-Farben-Mode (weil einfacher anzusteuern) und 16farbig, weil ich die ganzen Grafiken dafür in einem selbstgebauten (Textmode!)Malprogramm gepixelt hatte.
Jeder Pixel hat 1 Byte gebraucht (obwohl 4 Bit gereicht hätten!), auch bei den Levels. Sowohl Level als auch Sprites wurden durch Pascal-Procedures dargestellt, das "Drehen" war auch in Hochsprache gelöst. Aber es hat funktioniert.
Es hat Speicher gefressen und nur recht mittelprächtig performt - aber es war erstmal etwas, womit/woran man "arbeiten konnte". Das war 2001. Ich habe da zwischenzeitlich auch immer mal wieder andere Dinge getan. 2004 hatte ich dann meine "Arcade"-Unit entwickelt, mit Levels und Sprites in ca. 85% Assembleranteil (so wie sie heute noch ist). und indem ich auf Farbpaletten gesetzt habe, konnte ich die ganzen 256 Farben benutzen, pro Sprite trotzdem nur 15 davon (1 für "Transparenz"), genauso wie für das Level und habe den benötigen Speicher für Sprites und Level auf einen Schlag fast halbiert! und zusätzlich einen ziemlichen Geschwindigkeitszuwachs erhalten. Aber es war immer noch dasselbe Spiel. Die Grafiken entsprechend zu konvertieren, damit sie in einem für die neuen Routinen besser geeigneten Format vorliegen, war kein Hexenwerk.
Aber ich hatte eben schon etwas, in das ich die neuen Routinen "reinhängen" konnte.
Das ist ja das, was mich momentan etwas stört: Ich habe viele sehr tolle Routinen hier - aber kein existierendes Spielprojekt, in das sie "reingehangen" werden könnten.
Klar - ich könnte auch Xpyderz nehmen, erneut "aufbohren", das weiterentwickeln - aber man will in seinem Leben auch mal etwas anderes machen. Mit Xpyderz habe ich - mit Unterbrechungen - 8 Jahre meines Lebens verbracht. Da muß dann auch mal etwas anderes kommen. Ich möchte schon lange einmal einen Raumschiffshooter à la R-Type/Katakis/Gradius bauen und auch ein Jump'n'Run, zu dem ich schon so viele Ideen habe.
Momentan bin ich aber immer noch an meinem "SLOT" (dem neuen "Spiel-Rahmen") dran. Habe da immer noch die eine oder andere Sache an den Subsystemen bzw. Units, die mir nicht so gefällt und die ich gern noch umsetzen würde, bevor ich das Zeug benutze. Es geht alles sehr langsam voran, weil ich hier immer wieder Ideen wälze. Und auch, weil ich oft sehr müde bin... seufz... - Es wäre natürlich schön, wenn dann am Ende auch mal jemand die Spiele, die ich (vielleicht, irgendwann...) mal fertig kriege, spielen würde. Aber so richtig glaube ich nicht dran... Also - daß ich noch mal *irgendwann* ein Spiel bauen werde (ob mit oder ohne "SLOT"), daran glaube ich schon. Aber daß das dann auch jemand - außer mir selbst - spielen wird, daran eher weniger.
zatzen hat geschrieben:Für ein Spiel fehlt mir aber immer noch die nötige Idee und Faszination.
Es müsste etwas sein, was dann auch, vor allem von mir selbst, schonmal
gespielt wird. Vielleicht weniger etwas zum durchspielen, sondern vielleicht
ein 2-Spieler Game, das immer wieder Spaß macht.
Naja, bei einem 2-Spieler-Game gibt es ja für mich mehrere Probleme:
Wenn es auf mehreren Rechnern laufen soll, braucht man schon wieder eine Verbindung/Verbindungsprotokoll usw. (Und ja, damit habe ich mich vor ein paar Jahren auch mal rumgequält. Xpyderz sollte nämlich eigentlich auch Multiplayer werden.)
Oder, wenn beide auf einem Rechner, dann, selbst wenn ohne Splitscreen sondern beide auf 1 Bildschirm, müssen ja beide das gleiche Keyboard benutzen. Das funktioniert nicht mit allzuvielen Tasten gleichzeitig bei vielen Keyboards. Joystick(s) wäre eine Option... Naja.
Und das größte Problem für mich wäre, daß man für ein 2-Spieler-Spiel ja auch immer, wenn man Bock zum Spielen hat, einen Mitspieler bräuchte. Dazu müßte ich erstmal Leute kennen.
zatzen hat geschrieben:Das letzte Update zu meinem ZSM Player ist ein wenig her...
Mittlerweile habe ich schon einige neue Modi drin, aber ich möchte dabei bleiben, weiter das Modarchive zu durchforsten und ein Paket von ZSMs beizulegen, und da muss ich noch etwas weiter vorankommen bis zum nächsten Update.
Ja, wie im anderen Thread schon erwähnt: Wie weit bist Du damit?
zatzen hat geschrieben:Ich überdenke nebenbei andere Möglichkeiten, Grafik platzsparend zu speichern.
Ich weiss nicht ob es letztlich sinnvoll ist oder zu etwas sinnvollem führt, aber über die Idee quasi Bitplanes mit je 2 Bit zu verwenden ist mir die Idee gekommen, die Standard EGA Palette zu nehmen und mit den gegebenen RGB Stufen (hex jeweils 00, 55, AA und FF) alle Möglichkeiten zu kombinieren und letztlich bei einer Palette mit 64 Farben zu landen die so aussehen kann:
4gapal.png
Für handgepixelte Grafik müssten das eigentlich Farben genug sein. Die restlichen 192 Farben könnte man dann noch für unabhängige fotorealistische Hintergründe verwenden, mit maßgeschneiderter Palette.
Ich habe ein Programm namens "Screen Thief" hier, mit dem ich Screenshoots machen kann - habe da viele von Monkey Island 1+2 gemacht.
Du wirst lachen: So scheinen die bei MI1+2 vorgegangen zu sein: Einen Teil feste Palette für die Figuren und die Textausgaben und einen Teil für die ganzen Grafiken. Macht auch irgendwie Sinn.
Was mich nur immer wieder wundert, ist, daß Du Dich auf eine feste gestufte Palette beschränken willst. Es gibt bei so "generalisierten" Paletten viele Farben, die man überhaupt nicht benutzt - diese ganzen schrillen Magenta-Töne ("pink") oder Cyan-Töne ("helles Türkis") braucht man kaum in diesem Umfang. Weil der Helligkeitswert von Grün höher ist als der von Rot+Blau zusammen (ja, das ist der Grund), hat man unheimlich viele Grüntöne, die fast gleich aussehen und die deswegen Platz verschwenden und man nicht gebrauchen kann - Und dafür hat man inkl. Schwarz+Weiß nur 4 Graustufen, obwohl man da gern mehr hätte und auch wenig Farben die für "Gesichtshaut" geeignet wären und bei denen man gern ein paar mehr hätte, um Gesichter nicht allzu "flächig" aussehen zu lassen. Zusätzlich fehlt einem meist genügend dunkler abgestufte Grüntöne, meist hat man dann nicht genügend Gelbtöne (und, wie gesagt, dafür viel zu viel Magenta und Cyan).
Früher[tm] hatte ich auch mal so generalisierte tabellierte Paletten benutzt - inzwischen bin ich davon abgekommen. Ich definiere da lieber ein paar der "wirklich gebrauchten" Farben in verschiedenen Helligkeiten und ggf. "Nebenschattierungen" - ganz dunkle Farben lasse ich weg, weil es nicht auffällt, ob man die durch dunkelgrau ersetzt und weil die im Gesamtbild sowieso fast schwarz wirken, dafür aber einen Haufen Palettenplatz wegnehmen, ohne wirklich gebraucht zu werden.
Aber das Ganze hängt natürlich von den persönlichen Präferenzen ab. Ich hätte da schon Ideen, wie man das Ganze trotzdem auf "blockbasiert" benutzen könnte: Der Block selbst bekommt nur eine Paletten-Nummer und eine die Palette ist maximal 64 Farben groß. ABER: Beim Erfassen des Bildes erfaßt man zuerst diejenigen 8x8-Blöcke, die die wenigsten Farben enthalten und baut darauf basierend die Paletten auf. Dann gibt man jedem Block die Palettennummer und die Anzahl Bits die er braucht für die Farbangabe (weil Blocks mit wenig Farben auch weniger Bits brauchen). D.h. die Farben stehen dann jeweils am Anfang der 64er-Paletten. Und immer wenn neue Blocks kommen, wird geschaut, ob es eine Palette gibt, die schon möglichst viele der benötigten Farben enthalten (d.h. es kommen dann immer mehr Blocks, die mehr Farben haben und dann ggf. auch mehr Bits brauchen). Daß man dann innerhalb der Blocks zusätzlich noch ggf. Laufzeitcodierung oder bei ganz wenigen Pixeln einfach "Positions-Pixeln" machen könnte, wär ja dann auch OK. Die "Innerblock-Codierung" ist ja dann ein anderes Thema.
Naja, jedenfalls, falls kein Block mehr als 16 Farben braucht, kann man am Ende alle Paletten ja noch "abschneiden" und ganz am Bildanfang gibt man an, wieviele Farben eine Palette maximal hat, so daß man dann nur so viele Bytes pro Palette hintereinander speichern muß.
Beim "Entpacken" können die Blocks natürlich normal (in richtiger Reihenfolge) entpackt werden, weil sie ja einen Zeiger auf die Palettennummer enthalten.
Daß gleiche Blocks natürlich nur einmal gespeichert werden müssen (egal an welcher Stelle im Bild) ist ja klar. Da brauchts ja nur die Blocknummer.
So würde ICH vorgehen, wenn ich so etwas vorhätte. (So ähnlich funktioniert mein Zeug ja auch, nur daß das dann die "Kacheln" werden und innerhalb der Kacheln nicht (oder nur "4 zu 8 Bit") gepackt wird. Aber noch umfangreicher packen würde ich dann nicht - für ein interaktives Spiel wäre mir das dann zu komplex. Daß die Performance zum Darstellen des Levels draufgeht oder ich deswegen nicht scrollen könnte, wäre nicht so in meinem Sinn.
Aber Fotorealismus strebe ich sowieso nicht an - und meiner Meinung nach sind 256 Farben (außer als Graustufen oder mit dem "Unreal"-Trick) dafür auch zu wenig. Das wird nie fotorealistisch, sondern immer irgendwie häßlich, wenn man da "runterkonvertiert" - und NOCH häßlicher, wenn man nur eine generalisierte Palette hat (ja, ich habe das alles schon durch!). Da hat man viele Farben in der Palette, die man nie braucht - und stattdessen ist der ganze "fotorealistische" Hintergrund eine Zusammensetzung häßlicher Grau- und Braun-töne, an wenigen Stellen mal unterbrochen von einem "bunten" Pixel.
Und ja, ich kenne da auch die Tricks: Vor dem Konvertieren die Farbsättigung leicht erhöhen, bzw. Kontrast erhöhen und Helligkeit gleichzeitig verringern, das Bild ggf. "entrastern" und dann konvertieren. Sieht dann besser (zumindest "bunter") aus, aber von Fotorealismus weit entfernt. Ich finde, einerseits LowRes-80er-mäßige palettenbasierte Arcade-Spiele machen wollen und andererseits "fotorealistische" Hintergründe aus 100-200 Farben machen wollen - das paßt nicht zusammen.
Aber - wie ich ja immer sage: Das muß jeder für sich selbst entscheiden. Ich lege hier nur meine auf persönlichen Erfahrungen basierenden Ansichten dar.