Seite 7 von 8

Re: Eigenes Videoformat

Verfasst: So 6. Dez 2015, 18:26
von zatzen
Im Grunde ist das Konzept was ich derzeit im Kopf habe ja auch nicht unbedingt das letzte was ich haben
werde bevor ich anfange, irgendetwas mit ZVID zu machen. In einem anderen Thread ("Ich habe ein Konzept")
steht ja noch meine Idee mit den BattleBots sozusagen.

Aber wenn man bei der jetzigen Idee bleibt... Ja das wäre ein Teilfeature, mit diesen etwas komplexer
gesteuerten Figuren. Neben denen kann man ja auch immer noch ganz simple Jump&Run Figuren als
wirkliche Gegner implementieren, die dann auch gefährlich für die anderen Charaktere sein könnten.
Ich denke mal, eine Engine, die Figure kompex animieren und steuern kann, ist auch nicht kontraproduktiv
dabei wenn man diese Charaktere "normal" damit programmiert, ohne dass es einer "Sims" Simulation
ausartet. Mit anderer Grafik meinte ich in diesem Zusammenhang übrigens "schlechtere" Grafik, also
nicht 3D sondern 320x200 Pixelgrafik.

Ich weiss noch nicht so recht, ob ich wieder ein klares 2D Side - Dingen mache oder lieber eine Art
Pseudo 3D im Adventure Stil.

Hmm, also Popolous oder Siedler sind ziemlich exakt genau die Spiele, die ich am allerwenigsten mag,
und in denen ich auch total schlecht bin. Es sind ja gerade die Spiele, wo man Stunden, Tage- Wochenlang
dran sitzt und sich etwas aufbauen muss. Bei meinen Spiel soll direkt von Anfang an volles Programm sein
und es ist einfach etwas völlig anderes...

Oh und nein, eine KI mit richtigem Lernen lasse ich lieber bleiben. Dann habe ich lieber strunzdoofe
Charaktere die zwar ihre höchstpersönlichen Eigenschaften haben, aber aus ihren Fehlern nicht
lernen können.
Aber: Wie ich schonmal schrieb: Die Engine soll mit dem Spiel wachsen.
Ich könnte damit anfangen dass eine Figur einfach hin und her läuft und vielleicht jedes mal
beim Umkehren etwas sagt. Und dann sehe ich weiter was ich gerne erweitern würde und ob es machbar ist.

Re: Eigenes Videoformat

Verfasst: Do 10. Dez 2015, 18:00
von zatzen
Wenn ich's mir recht überlege sollte ich mich vielleicht lieber etwas zurücklehnen und einfach warten
bis mir eine Idee einfällt, die wirklich ein gutes Spiel bedeutet, anstatt etwas an den Haaren herbeizuziehen,
was dann mehr eine interaktive Demo ist. So wäre die Motivation auch ungleich höher.

Und was XMS betrifft... Ich hatte etwas damit zu hadern dass ich etwas programmiere was die Leistung
eines 486er oder Pentium benötigt, aber dann keinen XMS beansprucht. Wenn ich XMS aber beanspruche
gibt es wiederum keine Rechfertigung für kompakt und intelligent komprimierte Daten.
Aber das wäre gerade der Reiz an der Sache, und vielleicht gehe ich dann lieber in diese Richtung,
dass ich ersteinmal sage, technisch gesehen nur max. 640K, mit ZVID und eigenem Trackerformat,
bei dem die Patterndaten wirklich sehr gut komprimiert sind, und wo man dann lediglich zusehen
muss dass die Sampledaten vielleicht nicht größer werden als 100K.

Re: Eigenes Videoformat

Verfasst: Mo 21. Dez 2015, 09:56
von DOSferatu
Ich gebe hier nochmal kurz meinen Senf dazu, was XMS-Nutzung angeht:

Das "Problem" bei Nutzung von XMS ist eben, daß das alles nur indirekt ist - d.h. man muß sowieso immer etwas aus dem XMS in den Heap (<640k) kopieren, um "damit arbeiten" zu können.

Das bedeutet:
1.) Man muß sowieso immer etwas HEAP-Speicher freibehalten, damit man überhaupt etwas aus XMS nach HEAP kopieren kann.

2.) Es ist immer gut/besser, gleich einen größere Teile zu kopieren. Also: Einzeln Bytes/Words aus XMS kopieren macht die komplette Performance tot - weil die "Vorbereitung" (also das Initialisieren) des Kopierens ja auch noch etwas "Zeit" beansprucht. Diese Zeit ist immer gleich, d.h. man erhält natürlich einen "besseren Schnitt", wenn man einen größeren Abschnitt (eher so in kB-Bereichen) kopiert, weil das Verhältnis "Initialisierung" zu "Kopieren" dann natürlich mehr zugunsten des eigentlichen Kopierens ausfällt.

3.) Also ist es bei Nutzung von XMS meienr Meinung nach eher die bessere Idee, das Ganze über "ein-/ausblenden" von Speicherbereichen zu lösen - d.h., z.B. nur das, was gerade gebraucht wird, in den Heap kopieren. (D.h. ein HEAP-Speicherbereich wird mehrmals genutzt.)
Kurze Erklärung, was ich meine (an einem eigenen Beispiel) :
Meine Spriteroutinen sind so gestaltet, daß ich bis zu 16 Bereiche angeben kann, in denen Sprites liegen, d.h. ich kann z.B. eine Gruppe von Figuren in einem Bereich zusammenfassen. Und wenn die eine Gruppe gebraucht wird (weil sie gerade angezeigt werden soll) und die andere nicht. wird eben die anzuzeigende Gruppe in den Speicher eingeblendet. Beide Gruppen nutzen dann quasi den gleichen Offset im Speicher. Würde man Sprites aus der "ausgeblendeten" (=derzeit nicht genutzten) Gruppe anzeigen wollen, würde man quasi andere, teilweise halbe und verschobene Sprites der aktuellen Gruppe sehen - was natürlich nichts macht - daman ja per Definition diese "ausgeblendeten" gerade nicht anzeigt. Das ganze erfordert dann natürlich eine kleine "Logik" außerhalb der Spriteanzeigeroutinen, die immer feststellt, welche Gruppen gerade gebraucht werden - aber so etwas sollte einem gescheiten Programmierer nichts ausmachen.
Und ja - das schränkt natürlich ein Spiel etwas ein, da auf diese Weise nie alle Spriteimages gleichzeitig angezeigt werden können, wenn der HEAP dafür nicht ausreicht. ABER: Dieses Problem hätte man auch ohne Nutzung von XMS oder ein-/ausblenden!
Das heißt: Es klingt zuerst wie eine Einschränkung, aber in Wahrheit ist es eine Erweiterung - denn man erhält ja so die Möglichkeit, wesentlich mehr mögliche Spriteimages anzuzeigen (also mehr mögliche Figuren/Gegner/wasauchimmer) - nur eben nicht alle gleichzeitig.

4.) Man weiß nie, von wieviel XMS und wieviel freiem man bei einem fremden PC ausgehen kann. Es sollte zwar immer so etwas wie eine Mindestanforderung möglich sein. Aber für ein DOS-2D-Spiel würde ich nicht einem User kommen mit etwas wie: Mindestanforderung HEAP: 630kB, XMS: 64MB. Das wäre extrem unrealistisch - wer stattet eine DOS-Maschine schon dermaßen mit Speicher aus? Und: Unter reinem MS-DOS ist 630kB auch eher ein Kunststück - meist supporten so etwas eher nur Emulatoren. Aber ein DOS-Spiel zu bauen, das dann nur unter Emulatoren (und nicht unter echtem DOS) läuft, wäre ja auch schon irgendwie sehr lame.

Geht man aber hier eher "dynamisch" vor, so hat man die Möglichkeit, Probleme wie diese zu "umschiffen", indem man bei zu kleinem HEAP mehr in XMS packt - und bei zu kleinem XMS dann immer noch auf die Festplatte ausweichen kann.
Auch wenn das heutzutage - LEIDER! - Gang und gebe zu werden scheint, selbst (und vor allem!) bei großen Spielefirmen:
Ich persönlich bin kein großer Freund davon, mit exorbitanten Systemanforderungen ein Programm/Spiel nur einer kleinen Elite zugänglich zu machen, die sich alle Vierteljahre neue Rechner kaufen oder die einen DOS-Rechner so ausstatten, daß er sogar für das neueste Windows noch "overdrived" ist, will sagen: Daß unterhalb einer wahnsinnigen Ausstattung ein Spiel dann GAR NICHT MEHR läuft. Das ist nicht die Art, wie ich programmiere. Es muß für kleinen Speicher/kleine Leistung immer noch einen "Plan B" geben - anders werde ich nie arbeiten.
(Ja, ich weiß: Meine Mindestanforderung "386er" ist auch schon überkandidelt für DOS-Maschinen, aber ich nutze die 32bit-Register und die erweiterten Segmentregister (FS,GS) ja auch sinnvoll aus, um mehr Leistung rauszuholen, und nicht, weil ich zu faul wäre, mit 16bit Registern auszukommen. Letzteres wäre möglich, würe aber viel häufigere Wechsel der Segmentregister bzw viel mehr Nutzung von Stack und Speicher erfordern, anstatt Werte in Registern zu halten und "alles in der CPU zu machen". Immerhin programmiere ich ja inzwischen einen Großteil der Sachen, die "innere Schleifen" beinhalten in Assembler. Von "zu faul" kann da also meiner Meinung nach kaum eine Rede sein.)

5.) Man weiß auch nie, wie schnell das Kopieren von XMS nach HEAP (und umgekehrt) erfolgt - das ist leider etwas hardwareabhängig. Und, wie ich bereits erwähnte: Unter Windows bzw. Emulatoren habe ich da auch leider schon etwas negative Erfahrungen gemacht. Also sollte man das Kopieren von/nach XMS nicht in Dinge einbauen, die "in Echtzeit" laufen sollen.

Das soll's erstmal für heute gewesen sein.

Re: Eigenes Videoformat

Verfasst: Mo 21. Dez 2015, 16:30
von zatzen
Ich hatte ja für dieses Spiel mit dem Labern auch nur für die Sprachausgabe oder Digital-Sound allgemein
den XMS eingeplant. Von TS&Besen weiss ich, dass sowas auch recht flott funktionieren kann, dieses
kleine "Spiel" läuft auch gerade so eben auf einem 486er, wobei die Soundengine eine 16-Kanal
Mischmaschine ist, die auch noch extra langsam sein dürfte, weil sie die Samples erst alle in
einen 16 Bit Puffer addiert, dann Clipping macht (alles auf -128 bis 127 beschränken) - sicherlich
zerrt und scheppert das, aber dafür ist die Lautstärke schon bei einem einzigen Sample "normal" hoch.
Und dieses Clipping habe ich wenn ich mich recht erinnere in den ASM Routinen einfach durch
CMP Vergleiche mit Zahlen statt Werten in Vergleichsregistern realisiert, wohl auch etwas lahm.
Letztlich wird das ganze dann in einen 8 Bit Puffer kopiert und abgespielt.

Für den Player meines simplen Trackerformats hatte ich angedacht, dass bei Lautstärkebefehlen
nichts mit MUL gerechnet werden und auch kein Zugriff auf Tabellen stattfinden muss, sondern
ich würde alles auf nur halbieren, vierteln usw. anlegen, so dass dort nur ein Befehl wie SAR zum
Einsatz kommen muss.
Einen 16 Bit Puffer und Clipping werde ich aber trotzdem wieder brauchen, denn bei
den 8 geplanten Kanälen müsste ich im schlimmsten Fall, um Clipping auf diese Weise
zu vermeiden, alles eben durch 8 teilen, und dann wäre der Klang sehr verstümmelt.
Vielmehr sollte man dann auch wählen können ob der Puffer mit voller Laustärke
übernommen wird mit ggfs. viel Clipping, oder ob man ihn ein oder zwei Bit nach
rechts schiebt.
Statt Clipping könnte man auch einen Limiter realisieren, dieser würde die Lautstärke
sofort auf einen Wert herunterregeln so dass nichts clippt, und dann mit etwas Verzögerung,
sagen wir, 1 Millisekunde, wieder die Lautstärke hochfahren bis wieder etwas "drüber
schwappt" usw.
Das könntest du bei deiner Soundmachine implementieren, mir ist nämlich bei
deinem Beispiel aufgefallen dass es immer leiser wurde, je mehr Stimmen dazukamen.

Jedenfalls ist es so, dass sich z.B. 8-Stimmige Tracker Songs oder auch welche deiner
Soundmachine, nicht auf Maximalamplituden aufaddieren die 8 mal so laut wie eine
einzige vollausgesteuerte Stimme sind. Das würde nur passieren, wenn man auf
allen 8 Kanälen zu einem Zeitpunkt das gleiche Instrument startet. Die Summen-
lautstärke liegt so gut wie immer deutlich unter (Anzahl Kanäle) * (Lautstärke Einzelinstrument)
und deshalb macht es Sinn die Gesamtlautstärke variabel zu halten, mit Clipping Absicherung
oder Limiter, anstatt alles so leise zu machen dass es nie voll ausschlägt.
Bei dir ist es vom Klang her natürlich wurscht, deine Instrumente haben 4 Bit und
du hast 16 Kanäle, also kein klanglicher Verlust wenn du die Lautstärke auf
1/16tel definierst - es ist lediglich ein wenig leise...
Wobei, wenn du in einen 8 Bit Puffer mischst und Lautstärkebefehle drin hast,
dann wird aus einer Dreieckswelle mal schnell was anderes...
Das wird man aber eher als eine Art Rauschen empfinden. Kannst ja mal sehen
wie sich das so entwickelt und dann überlegen wie du es mit der Hauptlautstärke hältst.

Ich glaube ich werde bald mal den Thread wechseln. ZVID ist ja mehr oder weniger schon fertig,
werde mich wohl demnächst erstmal wieder der Trackerfile-Engine widmen.

Re: Eigenes Videoformat

Verfasst: Di 29. Dez 2015, 22:27
von DOSferatu
In der Tat wird zur Vermeidung von Clipping genau das in meiner Engine getan - es wird auf eine Maximallautstörke reduziert, die sich nach Anzahl der verwendeten Stimmen richtet.
Daß einzelne Stimmen dadurch leiser werden, ist natürlich klar - aber auch beabsichtigt (um clipping zu vermeiden). Außerdem MUß das meiner Meinung nach auch so sein - denn es gibt die Lautstärkebefehle ja nicht umsonst. Und wenn z.B. gerade eine leise Stelle in der Musik drin ist, in der alle Stimmen gerade zufällig leise sind, darf so ein variabler Limiter das dann ja nicht automatisch auf "max" hochziehen. Daher verwende ich ausschließlich die Anzahl verwendeter Stimmen für diesen Limiter.
Es gibt übrigens nur 2 Werte, die diesen Limiter ändern.
1.) eine (von extern) einstellbare "Gesamtlautstärke"
2.) die Anzahl gerade benutzter Stimmen
Nur wenn sich mindestens einer dieser beiden Werte ändert, wird der Limiter geändert.
Dieser Limiter ist übrigens eine 256-Byte-Tabelle (oder mit weniger Bytes!), die NUR IN DIESEM FALL neu erstellt wird - und sie wird durch Aufaddieren (nicht durch Multiplikation) erstellt (und sie erzeugt auch zusätzlich gleich den "Mittel-Adder").
Ich arbeite gern mit Tabellen, um Rechenzeit zu sparen. Ich versuche da immer einen guten Trade-Off zwischen Speichernutzung (für Tabellen) und dadurch gesparter Rechenzeit zu finden.

Und ja, ich weiß um den Effekt des Leiserwerdens, wenn die Stimmen dazukommen - aber in dem speziellen Fall wollte ich das absichtlich demonstrieren. Im Normalfall sind bereits alle Stimmen der Musik aktiv.

Eine Stimme ist auch dann "aktiv", wenn sie gerade den Mute"-Befehl abspielt. Einzig der JET-Befehl, und auch nur dann, wenn die Stimme in diesem Soundframe noch keinen einzigen "Längen-"Befehl abgespielt hat, bewirkt das Nicht-dazuzählen einer Stimme. Um sie komplett auszuschalten, geht nur der PLAY (PLY) Befehl mit gelöschtem Bit für diese Stimme. In dem Fall muß sie durch eine andere Stimme desselben Devices wieder reaktiviert werden. Der QuitVoice (QUV) Befehl schaltet eine Stimme (oder mehrere) zwar ebenfalls aus - dann aber vollständig für das Device, d.h. das Device hat dann diese Stimme(n) weniger. Um wieder neue Stimmen zu erhalten, müßte dann wieder der VoiceInit (VOI) Befehl benutzt werden - dann werden die Stimmen allerdings wieder aus Nullwerte resettet und müssen neu initialisiert werden.

Und: Mir fällt keine bessere Methode ein, um Clipping zu vermeiden. Ich möchte dies nicht dem Ersteller der Musiken/SoundFX überlassen - und dann dann vielleicht ekliges Clipping haben, weil alles auf Maximum gedreht wird. Es muß eben auch eine Möglichkeit für verringerte Lautstärke geben - nicht alles, was man abspielt, hat schließlich immer maximale Amplitude.

Na egal. Jedenfalls: Es ist in ISM genau so gedacht, wie es derzeit ist. Die erste Stimme im Beispielsong wird zwar ebenfalls leiser, wenn die anderen 3 Stimmen dazukommen. Aber: die anderen 3 Stimmen sind in diesem "Song" übrigens nicht auf 100% Lautstärke gesetzt, damit sie im Verhältnis zur "Hauptstimme" leiser klingen - weil sie Begleitstimmen angelegt sind. Ich halte mich da dran, die Stimmen in unterschiedlichen Lautstörken und (noch wichtiger) unterschiedlichen Oktaven abzuspielen, um einen "Soundbrei" zu vermeiden.

Re: Eigenes Videoformat

Verfasst: So 28. Feb 2016, 19:43
von zatzen
Ein Limiter im tontechnischen Sinn funktioniert so erstmal so, dass er ein Regelverstärker ist.
Abhängig vom vorliegenden klanglichen Material ändert er seine Verstärkung, indem er bei Werten, die
über eine bestimmte Grenze hinausgehen, sofort die Lautstärke so anpasst, dass es nicht zu Clipping (Übersteuerung)
kommt, sondern nur zur Vollaussteuerung. Anschliessend geht er innerhalb eher kurzer Zeit, z.B. 1 Millisekunde
oder weniger, wieder auf die ursprüngliche (höhere) Verstärkung zurück, bis es wieder
zur Überschreitung der Grenze kommt, und er regelt wieder runter uswusf...
Das Ergebnis ist eine höhere Lautstärke die man sonst nur mit Clipping erreichen würde, aber
eben ohne Clipping. Aber auch der Limiter sollte nicht allzu viel arbeiten, nicht mehr als 6 dB
(also Faktor 2) eingreifen, denn auch hier gibt es Verzerrungsartefakte, die aber anders und weniger
auffällig klingen können als Clipping.
Aber gut, es wäre ungewöhnlich soetwas für ein Computerspiel zu implementieren, ich selbst würde
eher Clipping machen, weil mir die Soundqualität bei einem Spiel nicht so wichtig wäre und Clipping
bei einer Samplerate von 16000 Hz, welche ich nehmen würde, nicht ganz so schlimm klingt wie
bei 44100 Hz.

Re: Eigenes Videoformat

Verfasst: Mo 29. Feb 2016, 20:22
von DOSferatu
zatzen hat geschrieben:Ein Limiter im tontechnischen Sinn funktioniert so erstmal so, dass er ein Regelverstärker ist.
Abhängig vom vorliegenden klanglichen Material ändert er seine Verstärkung, indem er bei Werten, die
über eine bestimmte Grenze hinausgehen, sofort die Lautstärke so anpasst, dass es nicht zu Clipping (Übersteuerung)
kommt, sondern nur zur Vollaussteuerung.

Ja, das ist mir schon klar. Aber vielleicht ist das ja gar nicht gewünscht. Wenn ich in den Musikdaten Werte eingebe, sollen die ja auch quasi "linear" so umgesetzt werden. Sonst müßte ich ja am Ende "gegen den Limiter" arbeiten (d.h. die Werte anpassen), damit es dann so klingt wie gewünscht. Manchmal WILL man ja, daß es nicht volle Power ist...

zatzen hat geschrieben:Anschliessend geht er innerhalb eher kurzer Zeit, z.B. 1 Millisekunde
oder weniger, wieder auf die ursprüngliche (höhere) Verstärkung zurück, bis es wieder
zur Überschreitung der Grenze kommt, und er regelt wieder runter uswusf...

Abgesehen davon wäre sowas natürlich ein Performancekiller, weil die eigene Ausgabe nach Mixen auch noch ständig analysiert werden müßte - und um zu erkennen, wann es "clippt", müßte das ja eigentlich entweder schon während des Mixens getan werden... Das entwickelt sich dem Ziel entgegen, eine "kleine" schnelle Abspielroutine zu haben.

zatzen hat geschrieben:Das Ergebnis ist eine höhere Lautstärke die man sonst nur mit Clipping erreichen würde, aber
eben ohne Clipping.

Ja, schon klar. Mir reicht die Lautstärke eigentlich. Das Stück, was ich da aktuell (4stimmig) abspiele, wobei die Stimmen 2,3,4 nur verminderte Lautstärke haben, wenn ich das so original wie es die Routine ausgibt (bei max. Masterlautstärke) in ein WAV schreibe und dann mit'n SB abspiele, fallen mir fast die Ohren ab - und das bei meinen kleinen Lautsprechern hier (hab keine Anlage).
zatzen hat geschrieben:Aber auch der Limiter sollte nicht allzu viel arbeiten, nicht mehr als 6 dB
(also Faktor 2) eingreifen, denn auch hier gibt es Verzerrungsartefakte, die aber anders und weniger
auffällig klingen können als Clipping.

Ja, ich programmiere das rein "mathematisch", ich habe überhaupt kein Hintergrundwissen zu Musik oder Klangtheorie. Ich baue quasi einen billigen elektronischen Synthesizer in Software.

zatzen hat geschrieben:Aber gut, es wäre ungewöhnlich soetwas für ein Computerspiel zu implementieren, ich selbst würde
eher Clipping machen, weil mir die Soundqualität bei einem Spiel nicht so wichtig wäre und Clipping
bei einer Samplerate von 16000 Hz, welche ich nehmen würde, nicht ganz so schlimm klingt wie
bei 44100 Hz.

Naja, Clipping kommt für mich nicht in Frage - ich habe schon gehört wie das klingt und dieses Rauschen und Knistern bis hin zu teils unerträglichem sonstigen Krach (wenn's schlimmer clippt), das war einfach nichts für mich.
Wenn ich Rauschen und sonstigen Krach will, erzeuge ich den lieber bewußt/absichtlich. Die "Percussion" in dem Stück ist ein Beispiel dafür. Intern benutze ich dafür einen selbstgebauten 16-Bit Pseudo-Zufallsgenerator - blaues Rauschen also.

Re: Eigenes Videoformat

Verfasst: Sa 23. Apr 2016, 21:53
von zatzen
So, mal Back on Topic:

Ich habe eine dieser Animationen vertont, mit ZSM.
http://www.zatzen.net/hit_any.zip

ZVID ist jetzt ausserdem deutlich schneller, weil ich es entsprechend optimiert habe.
Hier und da wird noch die ein oder andere Variable überflüssig werden, und ich denke
ich werde einigen Pascal Code noch durch Assembler ersetzen und evtl. Sprungtabellen
verwenden.

EDIT: Hab die ZIP gerade nochmal aktualisiert (24. April, 16:00 Uhr)

Re: Eigenes Videoformat

Verfasst: Sa 30. Apr 2016, 00:05
von DOSferatu
zatzen hat geschrieben:Ich habe eine dieser Animationen vertont, mit ZSM.
http://www.zatzen.net/hit_any.zip

Ich fand's sehr lustig. Schönes Ding.

Re: Eigenes Videoformat

Verfasst: So 1. Mai 2016, 17:12
von zatzen
Noch eine:
http://www.zatzen.net/raisins.zip

Hier habe ich einfach Musik mit Gesang gemacht zu einer eher kurzen Animationsschleife.
Die Animation frisst allerdings gut Rechenzeit, auch wenn ZVID schon ziemlich optimiert ist.
Ich habe auch noch etwas am ZSM Player herumgeschraubt, ein paar Routinen in Assembler
umgewandelt.
Was klangtechnisch hier von Interesse sein könnte: Die Vocal-Samples sind stellenweise mal
mit 11 kHz gesamplet, manchmal mit 22, teils mit etwas dazwischen, und dann entsprechend
zusammengestückelt. Das habe ich gemacht weil ich nicht überall 22 kHz brauche, für soetwas
wie S-Laute aber durchaus.

Re: Eigenes Videoformat

Verfasst: Mi 4. Mai 2016, 15:50
von zatzen
Ich optimiere fleissig an ZVID herum, habe aber gerade einen Hänger.
Man kann laut Lektüre XLAT dazu veranlassen, ein anderes Segmentregister als DS zu verwenden.
Aber wie stelle ich das an... Erstmal lässt Pascal die Ergänzung um eine Byte-Variable nicht zu.
Zudem kennt es auch den Befehl XLATB nicht, aber den wollen wir ja gar nicht bzw. scheinen
ihn sowieso schon zu haben. Einfach db 65h davor mit vorher richtig gesetzem GS Register
funktioniert auch nicht.

EDIT: Doch geht doch, hatte nur ein Register versehentlich überschrieben...

Re: Eigenes Videoformat

Verfasst: Mo 16. Mai 2016, 21:56
von zatzen
Nur zur Info:
Eigentlich bin ich auf dem Weg, soetwas wie ein Spiel zu machen.
Aber die Grafikroutinen sollen optimal sein, und jetzt stehe ich vor der Aufgabe, die
Routinen für die Transparenz zu optimieren. Leider habe ich das bei ZVID nicht von
vornherein so angelegt, dass schon in den nicht-dekodierten Daten eine transparente
Farbe immer 0 ist. Die Farbe an sich sollte nämlich frei wählbar sein, und so wird
sie momentan erst nach der Dekodierung per CMP abgefragt. Wäre es anders, also
bereits undekodiert im Bitstream mit 0 als transparent kenntlich gemacht, dann
könnte ich mir nicht nur das langsame CMP sparen, sondern sogar das dekodieren
über z.B. XLAT.
Das muss also erstmal gemacht werden, aber dafür muss ich nun erstmal wieder
den alten Encoder mit seinen komplizierten Palettenverschachteleien verstehen,
den ich vor über 2 Jahren geschrieben habe.

Tante EDIT sagt: Leider sind die Palettenzusammenfassungsroutinen des Encoders
so gestaltet, dass immer volle verfügbare Bitbreite vorausgesetzt wird, also z.B.
bei 3 Bit eine Bereichsbreite von 8 Palettenelementen, und die transparente Farbe
kann zudem an beliebiger Stelle in dieser Palette stehen. Von daher muss ich es
also so lassen und kann mir höchstens Alternativen zu CMP ausdenken wie z.B.
ein Puffer-Register mit dem Wert der jeweiligen Farbe füllen und dann per XOR
prüfen ob es 0 ergibt.
Ein noch bedeutenderer Geschwindigkeitszuwachs wird sich aber ergeben, wenn
ich versuche, die Routinen für die redundanten Blockdaten weiter zu optimieren.
Dafür müssen nämlich mehr Daten eingelesen werden als für nicht-redundante,
und zudem werden ein paar Pointer usw. jedes mal neu bestimmt, da lässt
sich vielleicht noch was machen.

Dabei könnte es auch nützlich sein, ein Flag zu "missbrauchen", also quasi
statt einer bool'schen Variable. Hat damit jemand Erfahrung?

Re: Eigenes Videoformat

Verfasst: Fr 2. Mär 2018, 19:27
von zatzen
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.
In Dosbox ist das zwar anders, aber in Anlehnung an damalige Umstände würde ich dabei
bleiben, nur den konventionellen RAM zu benutzen.

Gleichzeitig hält mich das bei der Stange, sparsam mit den Ressourcen umzugehen.
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. 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. 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.

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.

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.

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.
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.
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.

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.

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.

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.

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.

Re: Eigenes Videoformat

Verfasst: Fr 18. Jan 2019, 20:31
von zatzen
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
4gapal.png (1.25 KiB) 228 mal betrachtet

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.

Re: Eigenes Videoformat

Verfasst: Sa 26. Jan 2019, 12:05
von DOSferatu
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.