Eigenes Videoformat

Re: Eigenes Videoformat

Beitragvon zatzen » So 6. Dez 2015, 18:26

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.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Eigenes Videoformat

Beitragvon zatzen » Do 10. Dez 2015, 18:00

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.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Eigenes Videoformat

Beitragvon DOSferatu » Mo 21. Dez 2015, 09:56

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.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Eigenes Videoformat

Beitragvon zatzen » Mo 21. Dez 2015, 16:30

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.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Eigenes Videoformat

Beitragvon DOSferatu » Di 29. Dez 2015, 22:27

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.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Eigenes Videoformat

Beitragvon zatzen » So 28. Feb 2016, 19:43

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.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Eigenes Videoformat

Beitragvon DOSferatu » Mo 29. Feb 2016, 20:22

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.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Eigenes Videoformat

Beitragvon zatzen » Sa 23. Apr 2016, 20:53

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)
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Eigenes Videoformat

Beitragvon DOSferatu » Fr 29. Apr 2016, 23:05

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.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Eigenes Videoformat

Beitragvon zatzen » So 1. Mai 2016, 16:12

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.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Eigenes Videoformat

Beitragvon zatzen » Mi 4. Mai 2016, 14:50

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...
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Eigenes Videoformat

Beitragvon zatzen » Mo 16. Mai 2016, 20:56

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?
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Vorherige

Zurück zu Programmierung

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste