Trackermodul-Engine (sehr einfach)

[wobo]

Es gibt wenige Jump&Run-ähnliche Spiele wo man zu zweit
gleichzeitig spielen kann. Mario Bros. (nicht super mario,
und im Internet vorwiegend nur als "Afro Mario" zu finden)
ist so ein NES Spiel, wo man zu zweit, als Mario und Luigi
durch die Plattformen springt. Es ist sehr simpel gehalten,
macht aber Spass, und zu zweit macht es doppelt Spass.

Ich hatte mal ein Maria Jump'n Run ohne Scrolling auf dem Atari 2600.
Man konnte es zu zweit spielen und mußte Ungeziefer von unten anstupsen und aufsammeln.

Wegen des zu Zweit-Spielens war es das lustigste Game, das ich je gespielt habe.

Ich habe schon mehrfach daran gedacht, das für CGA (Ja, ) umzusetzen. Allerdings fehlen mir dazu Know-How & Zeit, so dass es nicht dazu kommen wird.

Wenn Du so ein Game machst, melde ich mich hiermit offiziell als Beta-Tester an!

[zatzen]

Wahrscheinlich meinst du genau dieses Spiel hier:


Jedenfalls hatte ich das, nur ohne die Afros, das hat irgendein Schelm
in dem ROM geändert.

Sowas in der Art wäre nicht schlecht, aber ich vermisse, wie auch
schon zu Kindeszeiten wo wir ein NES hatten, ein wenig die Interaktion
zwischen den Charakteren. Ich hatte mir bei NES Spielen immer
mehr Freiheit gewünscht, deshalb und nur deshalb spielte ich
auch aufs übelste Zelda, weil man da hingehen konnte wo man
wollte. Aber erst Monkey Island auf dem PC war das was ich
eigentlich gesucht hatte.

Trotzdem, ein Arcade mit etwas mehr grafischen und soundtechnischen
Gags wäre ein Ding was ich machen würde. Ich bin nur echt eher ein
Mensch der fühlt und nicht so gerne rational denkt, daher ist für mich
programmieren immer ein wenig masochistisch. Aber wenns sein muss
kann ich das auch...


Für's ernsthafte, wohlüberlegte Programmieren geht für mich
nichts über Borland Pascal 7. Allerdings, weil ich nunmal hier
tagein tagaus an meinem Quadcore Rechner sitze bleibt mir
nix anderes übrig als in DosBox zu coden ... *duck und wegrenn*
Naja, das aber eher aus dem Gefühl heraus, dass ich meinen 16 Jahre
alten Pentium schonen möchte, eine 16 Jahre alte Festplatte, und
noch kein Fehler drauf, irgendwann muss ja der Crash kommen...
Ansonsten isses gar nicht so falsch wenn man bei einem üblen
Programmierfehler nur dosbox neustarten muss und nicht
den ganzen Computer.

Freepascal läuft hierauf natürlich so fix wie Dos auf nem Pentium...
Aber ich benutze es nur für rein Zweckmäßige Programme,
Videobearbeitung z.B., ich hole mir in Virtualdub ein paar
tausend Bilder raus und programmier mir dann ein Programm
was diese dann z.B. zu 3x3 Multibildern kombiniert.

[zatzen]

WIr sind hier aber sehr off-topic geworden.
Deshalb mal wieder meine neuesten Gedanken zum ZEM Format:

Hab das vorhin dem Wobo geschrieben und poste es hier nochmal:

Ich überlege gerade, ob man die Samples noch komprimieren bzw.
datenreduzieren könnte, ohne große klangliche Nachteile und ohne großartigen
Mehraufwand beim Player heraufzubeschwören.
4 Bit Delta halte ich für keine gute Idee, denn:
- Ich denke das ist schwer zu implementieren, der Player müsste jedes Sample
intern Byte für Byte nacheinander abspielen und könnte nicht einfach "random"
auf eine bestimmte Position zugreifen. Selbst wenn er das bewerkstelligen würde
müsste man bei Schleifen eine Ausnahmeregel einführen und für den Schleifenanfang
ein "Stützbyte" definieren.
- Bei hohen Frequenzen, kombiniert mit hohen Amplituden, kommt 4 Bit Delta
nicht mehr mit. Es wird stumpf und verzerrt klingen.

Meine Idee wäre:
Man unterteilt die Samples in Segmente von z.B. 16 Byte.
Jedes Segment bekommt ein Info-Byte, welches in 4 Bit einen
Multiplikator enthält sowie in weiteren 4 Bit einen Offset.
So hätte man pro Segment 9 Byte, und mit diesen 9 Byte
ursprüngliche 16 Byte abgedeckt. Und dadurch die Datenmenge
auf 56,25% reduziert.
Der besseren Addressierung halber legt man die Info Bytes
alle hintereinander ab, und danach (oder in anderes Datenfeld) die jeweils 8 Byte.
Will man nun die Daten reproduzieren und auf einen bestimmten
Punkt im Sample zugreifen, so muss der Player die gewünschte
Sampleposition einmal durch 16 teilen (DIV) (-> var1).
Er liest Offset und Multiplikator aus dem Info-Byte der Position var1.
Weiterhin braucht er den entsprechenden 4-Bit Datenwert aus
dem Samplestream. Ich bin irgendwie grade zu unkonzentriert
um zu beschreiben wie er da rankommt. Ich "mal" es mal hin:
Angenommen, er braucht Sample-Position 23:
( 8 Byte [pos.0-15] )
( 8 Byte [pos.16-31]): aaaa bbbb | cccc dddd | eeee ffff | gggg [hhhh] <- !
Er findet diesen Wert also im Byte 11 (wenn man von 0 zählt) und im oberen
(oder unteren?)Nibble.

Jetzt zusammenbauen:
Samplewert = 16 * Offset + (Multiplikator + 1) * Datenwert

Dabei scheint es logischer, wenn die Samples vorzeichenlos daliegen.
Habe ich also bspw. gerade den oberen Teil der Welle einer Bassdrum,
so hätte ich vielleicht als Offset 0, und Multiplikator ebenfalls 0 (=1),
das wäre der Idealfall, es gäbe dann keinerlei Qualitätsverlust.
Andernfalls, wenn ich eine Schwingung innerhalb eines Segments
erfassen muss, die dort mehr Amplitude bzw. Umfang als 16 digitale Stufen hat,
muss der Multiplikator höher sein, und es wird zum Rauschen kommen.
Die recht engmaschige Segmentierung (man könnte auch nur jeweils 8
"Byte" Segmentieren, hätte dann immer noch lediglich 62,5% der Datenmenge)
sowie der Parameter Offset werden allerdings, so wie ich mir das denke,
dafür Sorgen, dass allzustarke Artfakte vermieden werden bzw. kaum hörbar sind.
Wusstest du, dass beim Telefon auch ein 8 Bit-Signal vorliegt,
dies aber durch nichtlineare Skalierung auf wenn ich nicht irre
12 Bit aufgeblasen wird? Und zwar werden die unteren Werte
eher linear behandelt, damit man Leises gut verstehen kann,
während Lauteres gröber abgestuft wird.
So ähnlich ist es auch hier, der Multiplikator wird nur wenn
es notwenig ist größere Werte annehmen, und es ist
nicht zuletzt Sache des Converters, wie gut die 4-Bit-Daten
ausgesteuert werden. Ich muss eine gute Abstimmung zwischen
Übersteuerung und Rauschen finden.

[zatzen]

Okay ne bessere Idee zur Sample-Komprimierung:

Ein Sample braucht, wenn es nicht gerade weisses Rauschen ist,
nicht permanent die gleich hohe Samplerate.

Man könnte ohne weiteres streckenweise Speicherplatz sparen,
indem man redundante Strecken zusammenfasst.

So würde der Kompressor in dem Fall in 4-Sample-Schritten
(Sample meint hier einen Punkt, also ein Byte im Sample)
das Sample analysieren und auswerten, ob man diesen
Bereich wirklich mit 4 Byte abbilden muss oder ohne
große Verluste auf 3, 2 oder nur einen Punkt reduzieren kann.

Beim Reproduzieren braucht man eine Info-Tabelle, die angibt,
auf welche Quantität reduziert wurde. Da diese entweder 1,
2, 3 oder 4 sein kann braucht es dafür 2 Bit. Die Tabelle
ist also insgesamt 1 / 16tel so groß wie das ursprüngliche
Sample und damit absolut vertretbar.

Derzeit ist mir jedoch noch ein Rätsel wie man "Random Access"
auf die Sampledaten haben kann. Es wäre zu viel Rechenaufwand,
für jeden Punkt die ganze Tabelle rückwirkend durchzulesen
um die Adresse im Samplestream zu finden... Wir haben hier
das Problem der "variablen Bitrate".

Als Komprimiermethode ist dies aber sicher nicht schlecht,
und ich werde das mal testen.

[DOSferatu]

Ich habe etwas ähnliches schon einmal programmiert - es funktioniert in der Tat so ähnlich wie das was Du vorhast.
Es diente damals mal zum Loggen von Daten die ein spezielles Hardwareteil lieferte. War für das Projekt eines Kumpels. War dann so Live-Log, der das auch in so Frames teilte.
Aber bei Samples ist es ja eher so - zumindest für welche bei "MOD"-artigen Dingen, daß die nur EINEN Punkt brauchen.
Meist sind so Samples ja so gedacht, daß sie einmal abgespielt werden und dann, wenn sie sich wiederholen, entweder vom Anfang oder von irgendeiner Stelle in der Mitte des Samples aus in Schleife abgespielt werden. Man könnte natürlich am Anfang des Samples auch eine kleine Tabelle anlegen, damit das Suchen innerhalb des Samples nicht so dauert. Von der "nächsten" Stelle aus muß dann nur noch das Sample "abgespielt" werden, bis man die wirkliche Stelle findet.
Naja, und so weiter...
Und die Idee mit den skalierten Werten ist auch ganz gut.
nämlich, daß die leisen Werte dichter zusammenliegen als die lauten. Das wäre dann zwar nicht verlustfrei, aber wahrscheinlich vom Klang her trotzdem vertretbar.

[zatzen]

4 Bit auf 8 skalieren wird nicht viel helfen, es wird nicht wirklich besser klingen
als linear skaliertes 4 Bit. Ich werde bei Zeiten mal eine Datenverringerung auf
4 Bit probieren, bin aber noch am grübeln was ich da genau mache.
Eine nichtlineare Codierung ist mir gerade auch eingefallen - Man lege sich
eine Tabelle mit je 2 Bit an und segmentiere das Sample ziemlich engmaschig
(vielleicht jeweils 2 Byte). Dann guckt man einfach, mit welcher Bitbreite
das jeweilige Segment auskommen würde. Sinnvoll erscheinen mir dann
entweder 2, 3, 4 oder 8 Bit, und diese Info kann man in die 2-Bit-Tabelle
einfliessen lassen. Wichtig wäre, dass die 2, 3, 4, 8 Bit Werte auch
jeweils Vorzeichenbehaftet wären. Ist aber natürlich wohl sehr kompliziert
zu reproduzieren in einem Player, aber es wäre vollkommen verlustfrei.
Würde wahrscheinlich aber auch nur so auf 80% reduzieren, ein Schuss
in den Ofen...

Aber auch die "ZEM" Patterncodierung gefällt mir mittlerweile nicht mehr so ganz,
ist zwar schon deutlich kompakter als alle gängigen MOD Formate, aber da
müsste noch mehr gehen, zumal die Effekte ja sehr abgespeckt sind.
Ich möchte es hinkriegen, dass nicht nur Triggern mit einem Byte auskommt,
sondern auch ein ganzer "Befehl" mit Wert, oder dass Triggern + Befehl in einem
Byte unterkommen. Wird nochmal komplett überdacht.

[zatzen]

Okay, mal der aktuelle Statusbericht zu meinen Überlegungen zum "ZEM" Format (interessiert das überhaupt wen? )

Die Samples werde ich auf 4 Bit mit 16-Samplewert-Segmentierung und Multiplikator speichern.
Erstaunlicherweise hält sich das Rauschen in Grenzen.
Ein Sample wird also in Segmente aufgeteilt, es wird nachgesehen wie weit dieses Segment
ausgesteuert ist, und dann wird das ganze optimal normalisiert in einem 4 Bit Wert gespeichert
mit einer 4-Bit Multiplikator Information für dieses Segment. Dadurch erreiche ich eine
Datenmengenreduktion auf 53% - und da das Rauschen, wenn man nicht gerade High End
erwartet, wirklich auszuhalten ist, könnte man fast schon sagen, 8 Bit unkomprimiert
wäre Verschwendung.

Bei den Patterns bin ich noch am Knobeln.
Bisher braucht ein Volume, Note oder Samplewechsel-Befehl jeweils 2 Byte. Und nur Triggern 1 Byte.
Das ist mir noch zu klobig. Ideal wäre für mich, Volume, Note, Samplenummer jeweils 1 Byte und
Triggern für alle 8 Kanäle zusammengefasst in einem Byte.
Trotzdem brauche ich dann aber noch die Info, auf welchem Kanal sich was ändert, sowie die
Info, wenn es eine Leerzeile gibt. Diese Info-Flag-Bytes wären mehr oder weniger statisch und
blähen die Patterndaten permanent auf, das gefällt mir noch nicht...

[DOSferatu]

Vielleicht für die Leerzeilen eine Lauflängen-Codierung?

[zatzen]

Bisher hab ich das eigentlich schon so gemacht, wenn eine komplette (auf allen Kanälen nichts) Leerzeile auftritt,
ist in dem "Leerzeilen"-Byte direkt vermerkt, wieviele Leerzeilen noch folgen. Wenns nur eine ist steht da eben
eine 0 drin. Ich gehe nicht jeden Kanal einzeln von oben nach unten durch, ich glaube es kommt aufs gleiche
raus wenn ich die Zeile bzgl. der Kanalevents dynamisch speichere, d.h. es werden nur die Kanäle gespeichert,
die aktiv sind, und dabei auch nur die, die wirklich etwas verändern. Wenn z.B. zwei gleiche Noten aufeinander
folgen wird nur vermerkt, dass das Sample erneut von vorn gespielt wird - die Note selbst ist schon gegeben
und damit redundant. Das kommt nicht selten vor, und gerade daher würde ich das, was ja nur einen Boolean
darstellt, gerne so sparsam wie möglich abspeichern, also nur 1 Bit.
Hab schon überlegt ob ich die ganzen Daten losgelöst von der Byte-"Rasterung" speichere, nur jeweils
so viel Bits wie sie wirklich brauchen, aber das würde ne ziemliche Fummelei beim Auslesen, vor allem
wenns dynamisch wäre. Also... Ich hab z.B. mich mittlerweile drauf geeinigt dass alle Parameter nur
6 Bit benötigen, das könnte ich ohne Byte-Raster sparsamer unterbringen.

Was die Leerzeilen angeht: Das Ding ist, dass meistens nie wirklich oder nur selten Leerzeilen auftreten.
Gerade 4 Kanal MODs, mal als Beispiel, sind oft sehr vollgepackt. Nicht zuletzt weil die Composer wegen
des fetten statischen Patternspeicherbedarfs lieber die Geschwindigkeit halbieren als Leerzeilen
zu erzeugen. Oder auch weil bei Amiga MODs die Patternlänge maximal 64 Zeilen ist, und sich
musikalische Floskeln am besten in vier Takten unterbringen lassen. Ich selbst habe mich über
die Jahre an 8 Zeilen pro Viertelnote gewöhnt, aber MOD-"Standard" ist allgemein 4 Zeilen.
Meine Patterns haben 128 Zeilen, die meisten könnte man auf 64 zusammenschrumpfen,
32tel Noten nutze ich hauptsächlich für Triller und Drum-Rolls, da sind 8 Zeilen/Viertelnote
wirklich praktisch.
Jedenfalls kann man nicht immer darauf bauen, dass ein statisches Gerüst durch Leerzeilen
deutlich kleiner wird.
Wenn ich meinetwegen 2 Byte statische Informationen pro Zeile habe, dann kleben an jedem
64 Zeilen Pattern mehr oder weniger ganze 128 Byte zusätzlich dran. Im Extremfall wäre man da
besser beraten, ungepackt und dafür ohne Info-Bytes zu speichern.

Aber noch macht es mir Spass ab und an mal zu knobeln... Ich denke irgendwann werd ich
ne gute Lösung finden.

[zatzen]

Oh ja ich habe ne Idee und werde mal ne andere Codierung versuchen.

Spurenweise. Der Player muss sich ja sowieso merken was gerade auf welchem Kanal los
ist, da kann ich auch einfach auf einem Track sagen "so jetzt kommen erstmal 15 Leerzeilen." -
optimalerweise noch nebenbei an wirkliche Daten angehangen, dann hätte man dafür wieder ein
Byte gespart, naja mal sehen.

Der Player "zieht" dann immer nur neue Daten, wenn die Leerzeilen noch nicht runtergezählt sind, ist ja klar.
Könnte effektiver sein als mein vorheriger engstirniger Ansatz der reinen Zeilenbetrachtung.

Juhuu, super Idee, hab ich wieder was zum Knobeln für unterwegs und zum Einschlafen :)

[zatzen]

Wie ich weiter oben schon schrieb, vertikale Leerzeileninformation,
also Track für Track, bringt wohl nicht viel, eher im Gegenteil.

Ich werde es doch mal als "Bitstream" versuchen, und dann Zeilenweise.

Dazu könnte ich gut nen Tipp gebrauchen, wie man Bitweise, oder auch soundsoviele Bits am Stück,
elegant liest oder schreibt. In sowas bin ich nicht gut.

Bis dahin denk ich mir die (dynamische) Datenstruktur aus.

[zatzen]

So, das neue Format steht, der Converter ist fertig.

DIe Patterndaten-Speicherung ist ziemlich effizient,
pro Zeile werden im Durchschnitt nur ca. 1-2 Byte benötigt.

Bei Interesse kann ich die Formatbeschreibung hier kundgeben.


Aber jetzt geht es daran, einen Player zu realisieren.
Erstmal ein Renderer, damit ich mich nicht noch zusätzlich
mit der Echtzeit-Soundkartenausgabe rumschlagen brauche.


Aber wo ich ein bisschen Starthilfe gebrauchen kann, wären
Fixkomma-Berechnungen.

Die Samples haben alle eine Länge von weniger als 65536 Byte.
Von daher müsste man die Sampleposition eigentlich in einem
Word halten können. Bloß, wie addiere ich dann einen Fixkomma-Wert?
Einfach wäre das, wenn ich für die Position in einem Sample einen
Longint nehme und darauf entsprechende Word-Werte addiere,
und die echte Position dann meinetwegen berechne indem ich
den Longint-Wert 10 Bits nach rechts schiebe, würde dann
bedeuten dass 10 Bits hinterm Komma sind.
Mit 16 Bit Assembler wird das aber umständlich.
Weiteres Problem: Schleifen. Dafür fällt mir bisher auch nichts
besseres ein, als einen Longint zu nehmen, und für den Fall
dass die Position größer ist als die Samplegröße eben die
neue Position zu errechnen, also dec(Position, Samplegröße).
Das kann aber haarig werden wenn ein sehr kurzes Sample
mit sehr hoher Frequenz abgespielt wird.

Wer kann mir auf die Sprünge helfen?
Ich könnte da jetzt rumprobieren, will aber nicht unbedingt
das Rad neu erfinden!

Eine Möglichkeit für die Fixkomma Addition sehe ich darin,
den Delta-Wert als zwei Bytes zu betrachten, das eine wird direkt
zur Sampleposition (wäre ein Word breit + 8 Bit Nachkomma) addiert,
und das andere auf die Nachkommastelle, die ja dann max. 1
Übertrag machen kann, der dann nochmal auf die Position draufgerechnet wird.
8 Bit Nachkomma könnten aber ein bisschen ungenau werden.

[zatzen]

So, nach laaaanger Pause melde ich mich mal wieder mit einer Überlegung:

Das Format steht. Codieren und Decodieren der Patterns funktioniert, alles Prima.

Player gibt's noch nicht.

Denn jetzt ist die Frage da nach dem Sinn:
So ein kompaktes Trackerformat macht nur Sinn, wenn ich es brauche, weil ich nur wenig
Speicher zur Verfügung habe. Sobald ich aber XMS oder Unreal Mode nutze, kann ich, zumindest
für ein Spiel, auch einfach eine große WAV Datei für die Musik nehmen. Klingt letztlich auch
noch besser, weil man es in aller Ruhe rendern bzw. sogar richtig professionell mischen kann.

Frage ist also: Real Mode oder nicht.
Als Kleinod zum Programmieren wäre ein Spiel im guten alten Real Mode attraktiv.

Möchte ich aber etwas umfangreicheres basteln, auch noch mit vielen polyphonen Soundeffekten
und jederzeit parater Sprachausgabe, dann brauche ich einige MB Speicher.
Dann ist da aber wieder die Frage, warum sowas überhaupt in DOS...

Fazit wäre:
Wenn mein Ziel das Spiel selbst ist, dann lieber direkt für Windows.
Wenn ich aber nochmal in die Freuden der Anfang-der-90er Programmierung
eintauchen will, dann Real-Mode. Kann das jemand nachvollziehen?

[wobo]

Fazit wäre:
Wenn mein Ziel das Spiel selbst ist, dann lieber direkt für Windows.
Wenn ich aber nochmal in die Freuden der Anfang-der-90er Programmierung
eintauchen will, dann Real-Mode. Kann das jemand nachvollziehen?

Sehe ich genauso.Unter DOS hast Du übrigens noch mehr Unstimmigkeiten: Wenn Du Sample-und Patternkomprimierung machst, bleibst Du vielleicht unter 640kb. Die Dekomprimierung aber wird wohl dazu führen, dass Du als Minimum einen Pentium ansetzen musst, weil ein typischer DOS-Rechner mit nur bis zu 1 MB (i.d.R. wohl ein 286-12) dafür viel zu langsam ist.

Andererseits hat ja jeder Pentium mehrerer MB, warum die also nicht nutzen? Dann brauchst Du auch die Samplekomprimierung nicht so unbedingt... ...und wenn Du die oberen MB nutzen willst, hast Du die Alternative zw. BIOS (Int $15), EMS, XMS, Unreal... ...und nichts ist so richtig perfekt, insb. portabel. 32bit-pmode wäre das einzig Richtige.

Ergo: Wenn man sich unter DOS nicht auf 16-bit und damit auf Kleinstprojekte beschränkt, hat man es sehr schwer. Ist leider ein unlösbares Dilemma, glaube ich...

[DOSferatu]

Zum Thema Sound-Engine:

Ich habe neulich (schon wieder einige Wochen her), ein eigenes Musikformat entwickelt - wie bei mir zu erwarten sieht es eher aus wie eine Sammlung von Pseudo-Opcodes. D.h. die "Musik" ist eine Art Programm. (Ich habe auch schon den dazugehörigen Editor in der Mache.)

Die "Abspielroutine" ist zu 75% fertig, d.h. die Subroutine die die Daten liest und daraus ein "Stück Sound" generiert, das man dann durch eine Soundkarte oder den PC-Speaker oder was-auch-immer abspielen lassen kann, d.h. es füllt den Soundpufffer, ist auch schon selbst auf Double-/Triple-.... Mehrfach-Buffering ausgelegt.

Das ganze Ding macht digitale Klangsynthese:
Man kann Werte für die Hüllkurve (Attack/Decay/Sustain/Release) setzen und eine Wellenform wählen. Diese kann aus 7 Wellenformen (1-7) gewählt werden und 1 bis 4 davon können zusammen zu einer "Ergebniswelle" für die Stimme (das Instrument) gemischt sein, dabei können die einzelnen Sub-Wellen auch unterschiedliche Frequenzen haben. Es gibt keine "Welle 0", diese ist dafür gedacht, wenn man weniger als 4 Wellen mischen will. Besonderheit: Wenn man 4x "Welle 0" (d.h. komplett 0) wählt, wird stattdessen der Noise-Generator benutzt, d.h. Rauschen (ich glaube blaues Rauschen, bin mir nicht sicher, ob es blau, weiß oder rosa ist).
Man kann so eine "Wellenform-Hüllkurve" Kombination als "Instrument" quasi speichern/laden, so daß man später, um die "Instrumente" zu wechseln, nur die entsprechende Nummer angeben muss.

Lautstärken sind für einzelne Stimmen und insgesamt einstellbar.
Eine einzelne Stimme generiert 4bit-Sound, es sind bis zu 16 Stimmen gleichzeitig möglich.
Ein einzelnes "Musikstück" kann bis zu 8 Stimmen nutzen (man kann es aber so tricksen, daß man 2 8stimmige Musikstücke gleichzeitig abspielt um 16 Stimmen zu haben). Das Ganze ist aher dazu gedacht, Musik UND Soundeffekte mit demselben Ding erzeugen zu können. Die von den einzelnen Stimmen generierten Daten werden "addiert" und am Ende auf 8bit hochskaliert, abhängig davon, wieviele Stimmen insgesamt genutzt sind und welche Masterlautstärke(n) benutzt werden soll(en).
Beispiel: 4stimmige Musik und 12 Stimmen für verschiedene Soundeffekte.

Portamento ist auch vorgesehen, wird noch eingebaut, ist eben ein weiterer "Adder" im Klanggenerator.

Alternativ dazu (bzw in Zusammenarbeit mit der Klangsynthese) ist auch das Abspielen von fertigen Samples in verschiedener Frequenz vorgesehen - als "Instrument", anstelle der Syntheseklänge.

Das Ganze ist auf Geschwindigkeit und Speicherersparnis ausgelegt - wie alles, was ich programmiere.
Dafür ist es keine Klangbrillianz von CD-Qualität. Aber ich selbst kann sowieso keine Musik "komponieren", die einer CD-Qualität würdig wären.
Und so wie meine Grafik, die intern oft 4-bit zu 8-bit Mechanismen benutzt (z.B. Objekte mit 16 aus 256 Farben, da sowieso kein Objekt alle 256 Farben gleichzeitig nutzt), habe ich mich auch beim Klang für diesen "Minimalismus" entschieden.

Ich weiß - die Dinge, die ich mache, werden niemals "total modern" und "für Highend-Geräte" sein. Das ist auch nicht mein Anliegen. Meine Spiele sollen eher so wie Konsolenspiele vor 1995 sein. Etwas anderes habe ich auch nie vorgehabt.

Btw: Mein Sprite-Grafik-Level-Editor ist "quasi" fertig. Ich muß nur noch die Hilfsseiten vervollständigen. Einige Funktionen sind noch inaktiv, aber diese werden auch nicht unbedingt benötigt. Ich habe noch nie ein Programm mit einer derart aufwendigen und umfangreichen grafischen Benutzeroberfläche gebaut.

Ich werde wohl definitiv mit RealMode auskommen. Und ja, ich nutze auch gelegentlich HIMEM.SYS (also XMS) für verschiedene Dinge. Das Sample-Handling ist jedenfalls bereits dazu ausgelegt, Samples "ein- und auszublenden", um unteren Speicher zu sparen (z.B. von/nach XMS kopieren, wenn gerade nicht gebraucht).

Vielleicht war das wieder zuviel Info. Ich dachte, es interessiert an dieser Stelle vielleicht jemanden - wo es um "Tracker" geht und so.