Danke für die Antworten, ihr beiden!
Nein, DOSferatu, ist nicht zu viel, ich bin ja interessiert an sowas.
Ich möchte nur mal zum Thema Real Mode sagen:
Doch, ich denke das ist, wofür ich mich entscheide.
16 Bit, Real Mode, 640 K RAM.
Gerade für mich, da ich nicht wirklich jemand bin, der die ganze Zeit nur programmiert,
ist es mit einer gewissen Einfachheit doch besser. Mit dem Real Mode habe ich Erfahrung,
und jetzt noch so viel anderes dazu lernen, das muss für mich nicht sein.
Real Mode Stil wäre für mich:
- direktes Schreiben in den Bildschirmspeicher
- Addressieren des Speichers direkt möglich, d.h. kein XMS usw...
- lieber in Spielen auch mal gewisse Daten direkt vom Datenträger
in den Speicher puffern oder gewisse Sachen zwischendrin nachladen,
wer kennt es noch, diese wunderbaren "Loading..." Screens.
Ansonsten hatte man bei Sprachausgabe oft den Fall, dass diese eben
vom Datenträger (CD-ROM z.B.) aus ner 300MB Datei "gestreamt" wurde.
Oder FLI(c)-Dateien. Das hat funktioniert, ich hatte nur hinterher immer
Bedenken, wie sowas mit DMA Ausgabe beim Soundblaster harmoniert.
Es gibt genug Programme, Spiele, in diesem Format, um 1990, + - ...
Die waren gut, damit bin ich aufgewachsen, damals wollte ich soetwas
selber machen, konnte es aber noch nicht, aber heute.
Die technischen Beschränkungen inspirieren, es macht Spass diese auszureizen,
man knobelt intelligente Datenformate aus anstatt einfach alles redundant und
dekadent groß zu speichern, das ist etwas anderes als wenn man einen heutigen
Rechner mit virtuell unbegrenzten Speicherkapazitäten programmiert, an
dessen technischen Grenzen man erst stößt wenn man entweder total schlecht
programmiert oder ein riesiges Team hinter sich hat.
Moderne Architektur hat natürlich ernsthafte Vorteile: Es ist pragmatisch, für
professionelle Anwendungen wie Musikprogramme mit allem Pipapo oder auch
Grafikbearbeitung, da ist das alles ein Segen wenn man uneingeschränkt alles
machen kann was einem in den Sinn kommt.
Für mich als Kleinprogrammierer macht es aber mehr Spass, wenn ich wenigstens
ein veraltetes System so programmieren kann, wie es damals State-Of-The-Art war,
dabei hat das ganze dann noch diesen gewissen Charme.
Zu DOSferatus eigenem Musikformat:
Interessant wäre es mal, die Opcodes zu sehen, bzw. mal zu sehen, ob ein Opcode
Format wirklich speichersparender ist als ein effizient gespeichertes Tracker-Pattern-Format.
Grundsätzlich finde ich das mit Opcodes aber auch gut, und wenn es keine
patternmäßige Rasterung gibt, kann es auch flexibler sein. Die Frage ist nur,
welche Art von Musik eigentlich nicht in ein Pattern-Raster passt.
Nach 20 Jahren Tracker-Erfahrung kann ich eigentlich sagen, dass 99%
aller Musik in Patterns reinpasst.
Die Kanalaufteilung kann ein Argument sein, beim Tracker hat man eine gegebene
Anzahl Spuren, die statisch sind - alternativ, mit Opcodes, könnte man eine dynamische
Verwaltung aktiver Spuren / Instrumente realisieren.
Wie kreiert man denn Musik dafür? Ist es nur ein Datenformat oder gibt es auch einen Editor?
4 Bit Sound, das würde mich interessieren wie das klingt. Könnte übelst rauschen wenn es
nicht nur Rechteckwellen sein sollen.
Das wäre aber alles einmal interessant zu sehen, auch der Sprite-Editor!
Konsolenspiele vor 1995:
Da muss ich, jetzt mal unabhängig von Konsole, beispielsweise an Indiana Jones & The Fate Of Atlantis
denken. Das Spiel ist von 1992. Offensichtlich war es Real Mode und 16 Bit, denn es funktionierte auf
meinem übelst alten 286er. Zu dieser Zeit gab es aber auch schon 386er. Und auf einem solchen,
bzw. 486er, lief das Spiel sehr viel besser. Wie viele andere auch die um 1992/93 erschienen, auf
286er mehr als schlecht als recht und auf 486ern perfekt liefen.
Daher mein Gedanke: Ich habe nicht vor, 32 Bit Code zu machen. Höchstens mal ne EAX Geschichte.
Das kann BP70 von Haus aus auch nicht so recht. Gleichzeitig möchte ich mich aber auch nicht dem
Leistungslimit eines 286ers verpflichten.
Wo würdet ihr eine sinnvolle Grenze ziehen für 16 Bit Code auf der einen Seite, und Rechnerleistung
auf der anderen?
Mein Gefühl sagt mir, ein 486er darf es schon sein.
Trackermodul-Engine (sehr einfach)
Re: Trackermodul-Engine (sehr einfach)
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
Ich habe da so eine Idee, wegen Tracker und Rechenleistung.
Man könnte die Performance erhöhen und das Live-Entpacken der Samples beibehalten, indem man die Tracks mit
unterschiedlicher Qualität vormischt, und dann am Ende auf den größten gemeinsamen Nenner zusammenmischt.
Es reicht dann vielleicht ein HQ Track, und der Rest kann auf halber oder sogar Viertel (oder drittel) Samplerate gerendert
werden.
Oder man macht das dynamisch oder automatisch, so dass die Patterns gescannt werden und entschieden wird, welche
Samples in dieser oder jener Zeile mit welcher Qualität behandelt werden müssen - und diesen Teil kann auch schon der
Converter erledigen.
Beispielsweise würde dann eine Hihat auf dem HQ Track landen, und ein Bass auf dem extremsten LQ. Man kann das evtl.
auch pro Zeile dynamisch arrangieren und selbstverständlich auch eine Berechnung komplett weglassen, wenn gerade auf
dem Track nichts läuft.
Wenn der Converter das alles macht, dann kann auch sehr kritisch sortiert werden, indem die Samples analysiert werden,
man kann die Delta-Werte bilden und danach deren Amplitude überprüfen, je niedriger diese ist, desto eher kann man den
Track Low-Quality behandeln. Man muss nur ein High-Quality Limit setzen, damit in der späteren Anwendung die
Rechnerleistung nicht plötzlich doch kollabiert.
Das würde alles natürlich die gesamte Klangqualität nicht unbedingt verbessern... Aber Unterhaltungssoftware des Real
Modes geht nun eben meistens einen Kompromiss ein, jedoch sind gesamplete Klänge für mich ein muss.
Dabei ist es eine Überlegung Wert, ob man eben auch das ganze Musikformat doch eher Opcode-mäßig aufbaut.
Dazu müsste ich aber von DOSferatu mal ein Beispiel sehen. Man kann ja nach wie vor die Musik in einem
Tracker schreiben, lediglich würde beim Konvertieren statt einer Tracker-Pattern-Struktur etwas vielleicht
effizienteres geschrieben - es muss, wenn man nach High und Low Quality sortiert, sowieso noch einmal
ein anderer Ansatz her.
Hierzu könnte sich wobo auch äußern, weil er ja einen MOD-Player geschrieben hat und dort ebenfalls
mit Leistungsproblemen zu kämpfen hatte.
Man könnte die Performance erhöhen und das Live-Entpacken der Samples beibehalten, indem man die Tracks mit
unterschiedlicher Qualität vormischt, und dann am Ende auf den größten gemeinsamen Nenner zusammenmischt.
Es reicht dann vielleicht ein HQ Track, und der Rest kann auf halber oder sogar Viertel (oder drittel) Samplerate gerendert
werden.
Oder man macht das dynamisch oder automatisch, so dass die Patterns gescannt werden und entschieden wird, welche
Samples in dieser oder jener Zeile mit welcher Qualität behandelt werden müssen - und diesen Teil kann auch schon der
Converter erledigen.
Beispielsweise würde dann eine Hihat auf dem HQ Track landen, und ein Bass auf dem extremsten LQ. Man kann das evtl.
auch pro Zeile dynamisch arrangieren und selbstverständlich auch eine Berechnung komplett weglassen, wenn gerade auf
dem Track nichts läuft.
Wenn der Converter das alles macht, dann kann auch sehr kritisch sortiert werden, indem die Samples analysiert werden,
man kann die Delta-Werte bilden und danach deren Amplitude überprüfen, je niedriger diese ist, desto eher kann man den
Track Low-Quality behandeln. Man muss nur ein High-Quality Limit setzen, damit in der späteren Anwendung die
Rechnerleistung nicht plötzlich doch kollabiert.
Das würde alles natürlich die gesamte Klangqualität nicht unbedingt verbessern... Aber Unterhaltungssoftware des Real
Modes geht nun eben meistens einen Kompromiss ein, jedoch sind gesamplete Klänge für mich ein muss.
Dabei ist es eine Überlegung Wert, ob man eben auch das ganze Musikformat doch eher Opcode-mäßig aufbaut.
Dazu müsste ich aber von DOSferatu mal ein Beispiel sehen. Man kann ja nach wie vor die Musik in einem
Tracker schreiben, lediglich würde beim Konvertieren statt einer Tracker-Pattern-Struktur etwas vielleicht
effizienteres geschrieben - es muss, wenn man nach High und Low Quality sortiert, sowieso noch einmal
ein anderer Ansatz her.
Hierzu könnte sich wobo auch äußern, weil er ja einen MOD-Player geschrieben hat und dort ebenfalls
mit Leistungsproblemen zu kämpfen hatte.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
OK, ich habe mal den Beschreibungstext, der die derzeitig funktionierende Version meiner Sound Engine beschreibt (und die Tasten für den Editor) auf meine Webseite hochgeladen.
Bitte beachten, daß dies nicht als endgültige Version zu verstehen ist - genau wie bei meinem GameSys2 kann sich im Verlaufe von Tests noch einiges daran ändern.
In solchen Tests finde ich dann immer heraus, was sinnvoll und nützlich ist, was vielleicht zusätzlich noch nützlich und wünschenswert wäre und was vielleicht weggelassen oder eingeschränkt werden kann.
Unbedingt in 437er Zeichensatz (oder wenigstens 850er) ansehen, da "Grafikzeichen" für Tabellen benutzt werden.
Die bis jetzt noch nicht einprogrammierten Mnemonics/Opcodes sind:
BND/$60 (Portamento) - vorbereitet
WFI/$7A (Filter) - Nur ein reservierter Opcode für (vielleicht!) spätere Benutzung von Lo/Hi Filtern.
???/$6F/1 (Special) - Die "Spezial" Befehle, die "Programm-artiges" Verhalten ermöglichen durch Modifikation von Daten/Registern
WAV/$78 - (Wellenform) - Vom Code her ist es fertig. Aber ich plane, die Standard-Wellenformen vielleicht gegen andere auszutauschen - speziell die Formen 3-7 durch nützlichere zu ersetzen. Eigentlich reichen mir 2 Pulsformen. Es gibt nur gar nicht so viele "Standardformen", die man benutzen könnte.
Naja, ich muß auch am eigentlichen Soundgenerator (Sound Engine), vielleicht auch noch einige Verbesserungen vornehmen. Irgendwie übersteuert/untersteuert der manchmal. Ich weiß schon, woran es liegt. Momentan habe ich nur leider jobbedingt irgendwie oft keinen Nerv zum Programmieren, weil ich mich kaum konzentrieren kann. Ich bin entweder total müde oder total genervt - manchmal beides.
Seufz... Jobs fressen einen auf und nehmen einem jede Begeisterung, Lebensenergie und Gesundheit. Sowas sollte eigentlich verboten werden...
Achja: Da ist der Text zu finden:
http://www.imperial-games.de/z/_ism.txt
Bitte beachten, daß dies nicht als endgültige Version zu verstehen ist - genau wie bei meinem GameSys2 kann sich im Verlaufe von Tests noch einiges daran ändern.
In solchen Tests finde ich dann immer heraus, was sinnvoll und nützlich ist, was vielleicht zusätzlich noch nützlich und wünschenswert wäre und was vielleicht weggelassen oder eingeschränkt werden kann.
Unbedingt in 437er Zeichensatz (oder wenigstens 850er) ansehen, da "Grafikzeichen" für Tabellen benutzt werden.
Die bis jetzt noch nicht einprogrammierten Mnemonics/Opcodes sind:
BND/$60 (Portamento) - vorbereitet
WFI/$7A (Filter) - Nur ein reservierter Opcode für (vielleicht!) spätere Benutzung von Lo/Hi Filtern.
???/$6F/1 (Special) - Die "Spezial" Befehle, die "Programm-artiges" Verhalten ermöglichen durch Modifikation von Daten/Registern
WAV/$78 - (Wellenform) - Vom Code her ist es fertig. Aber ich plane, die Standard-Wellenformen vielleicht gegen andere auszutauschen - speziell die Formen 3-7 durch nützlichere zu ersetzen. Eigentlich reichen mir 2 Pulsformen. Es gibt nur gar nicht so viele "Standardformen", die man benutzen könnte.
Naja, ich muß auch am eigentlichen Soundgenerator (Sound Engine), vielleicht auch noch einige Verbesserungen vornehmen. Irgendwie übersteuert/untersteuert der manchmal. Ich weiß schon, woran es liegt. Momentan habe ich nur leider jobbedingt irgendwie oft keinen Nerv zum Programmieren, weil ich mich kaum konzentrieren kann. Ich bin entweder total müde oder total genervt - manchmal beides.
Seufz... Jobs fressen einen auf und nehmen einem jede Begeisterung, Lebensenergie und Gesundheit. Sowas sollte eigentlich verboten werden...
Achja: Da ist der Text zu finden:
http://www.imperial-games.de/z/_ism.txt
Re: Trackermodul-Engine (sehr einfach)
Kenne ich. 2011 und 2012 hatte ich nur halbtags gearbeitet und bin super zum Programmieren gekommen. Jetzt arbeite ich Vollzeit für 4 verschiedene Arbeitgeber. Decfacto arbeite ich jetzt den ganzen Tag und knalle mich abends totmüde ins Bett. Habe ich mal einen freien Tag, kann ich nichts mehr machen, was das Hirn anstrengt - ich bin einfach nur platt und habe einen Schädel, als hätte ich am Vortag gesoffen!DOSferatu hat geschrieben:... Momentan habe ich nur leider jobbedingt irgendwie oft keinen Nerv zum Programmieren, weil ich mich kaum konzentrieren kann. Ich bin entweder total müde oder total genervt - manchmal beides.
Decfacto habe ich 2013 nur die Weihnachtsfeiertage und Anfang Neujahr 2014 was programmiert. Ansonsten waren die Dosen eigentlich aus. Ich habe mich heute entschieden, die Programmierei endgültig an den Nagel zu hängen und gleich mal ein paar HDs platt gemacht. War eine richtige Befreiung - ich hatte ohnehin einfach zu viele Baustellen eröffnet. Zu viele Projekte, die ich so gerne weiterbearbeitet hätte. Die aber einfach nicht zu schaffen waren. Jetzt ärgere ich mich nicht mehr, weil ich mit diesen Projekten nicht mehr voran komme. Sondern habe den Kopf frei für das, was mir am wichtigsten ist (Familie & Beruf!).
Das war auch der Grund, warum ich kein Feedback Dir und Zatzen gegeben habe: Momentan habe ich einfach keinen Kopf, um vernünftig mitdenken zu können. Interesserieren tut es mich aber schon, was Ihr alle hier in dieser Sektion an Code/Gfx/Sounds bastelt. Bei Gelegenheit werde ich immer hier in diese Sektion reinschauen und nach Lust und Laune Euer Zeugs antesten und auch mal meinen Senf dazu geben. Allerdings nur unregelmäßig und aus reiner End-User-Sicht
Forumstechnisch lege ich meinen Schwerpunkt jetzt nämlich in die Sektion "Spiele" Noch kurz zum Schluß: Ich finde ja wirklich beeindruckend, was Du und Zatzen macht. Nämlich eigene (Denk-)Wege gehen. Und eigene Lösungswege ausarbeiten. Ich habe das - auf viel geringerem Niveau- auch immer versucht, d.h. ich habe immer versucht, nicht im Netz nach Lösungen zu googeln, sondern einfach immer versucht, die jeweiligen Probleme mit meinen Mitteln zu lösen. Ich finde das ultra spannend - und weiß deswegen auch, dass es dann Jahre dauern kann, bis man etwas vorzeigbares hat. Deswegen: keinen Stress und keine Krämerei, macht einfach weiter und wenn es Jahre dauert, dann gucke ich mir das auf jeden Fall noch an
Re: Trackermodul-Engine (sehr einfach)
Wenn Du es klinisch rein haben willst, dann ist wahrscheinlich für 16-bit Code ein 286-25 die Obergrenze. Leistungsmäßig dürfte der genauso schnell sein wie ein Stangenware 486sx25 ohne 2nd-level-cache (mein 486sx25 ist jedenfalls langsamer als wenn ich Dr.Zeissler´s 286-10 auf 25 Mhz hochrechne).zatzen hat geschrieben: Daher mein Gedanke: Ich habe nicht vor, 32 Bit Code zu machen. Höchstens mal ne EAX Geschichte.
Das kann BP70 von Haus aus auch nicht so recht. Gleichzeitig möchte ich mich aber auch nicht dem
Leistungslimit eines 286ers verpflichten.
Wo würdet ihr eine sinnvolle Grenze ziehen für 16 Bit Code auf der einen Seite, und Rechnerleistung
auf der anderen?
Mein Gefühl sagt mir, ein 486er darf es schon sein.
Ich würde das aber nicht so eng sehen. Die Grenze für 16-Bit code würde ich dort ziehen, wo man kein Dos mehr einsetzt. Die Grenze dürfte daher bei einem P200mmx bzw. einem K6 liegen. Tendenziell würde ich die Grenze sogar dort ziehen, wo als letztes noch Boards mit ISA-Slot verkauft wurden, also alles bis Ende der 90er.
Re: Trackermodul-Engine (sehr einfach)
Danke euch!
Bei dem Opcode-Musikformat durchzusteigen erfordert noch etwas mehr Zeit für mich.
Ich überlege gerade an einem Sample-Format, möglicherweise 2 Bit Delta aber Blockweise skaliert.
Ich weiss nicht ob das Funktioniert, allerdings das IMA ADPCM Format klingt mit 2 Bit schon sehr gut,
ich schätze nur, das Dekodieren würde zu viel Leistung fressen. Aber erstmal sehen. Das alles nur für
die Möglichkeit, statt Musik im Trackerformat einfach eine Musik Stückchenweise aneinanderzureihen,
auch für Variation, und auch Soundeffekte einfach mit hineinzumischen, also alles ohne Resampling.
Ansonsten überlege ich auch, ob man Sprites nicht noch effektiver Speichern kann. Evtl. zerlegen
in Blöcke von 4x4 Pixeln oder so, welche dann mitunter nur 1 - 16 Farben enthalten und entsprechend
wenig Speicher bzw. Bits benötigen. Das gibt natürlich dann viele Paletten, die man sinnvoller auch
Sprite-Übergreifend anlegt - ist erstmal nur eine Idee. Skalierung würde ich eher nicht benötigen, und
Drehungen nur 90 Grad, und/oder Spiegeln / Flippen.
Wobo, mir macht es eben ab und an Spass zu programmieren, denn heute klappen die Programme
meistens sofort beim ersten oder zweiten Anlauf, während ich früher erstmal über dutzende
Stolpersteine gefallen bin. Und ich mache das auch wirklich nur nebenbei. Macht halt einfach
schonmal Spass. Das ist wohl auch der Grund, warum ich den Real Mode bevorzuge: Durch die
Einschränkungen kommt es mir zumindest so vor, als wenn schon relativ kleine Programme
ihr Dasein rechtfertigen, bzw. Spiele, die technisch relativ bescheiden sind, sprich, kein 3D usw.
Das ist eine gute Sichtweise: Real Mode zu nutzen ist "korrekt" bis zu dem Zeitpunkt, wo 32 Bit Code
Pflicht wurde (Windows). Ganz klar ist mir gerade aber nicht, ob XMS auch erst ab 32 Bit möglich war.
Bei dem Opcode-Musikformat durchzusteigen erfordert noch etwas mehr Zeit für mich.
Ich überlege gerade an einem Sample-Format, möglicherweise 2 Bit Delta aber Blockweise skaliert.
Ich weiss nicht ob das Funktioniert, allerdings das IMA ADPCM Format klingt mit 2 Bit schon sehr gut,
ich schätze nur, das Dekodieren würde zu viel Leistung fressen. Aber erstmal sehen. Das alles nur für
die Möglichkeit, statt Musik im Trackerformat einfach eine Musik Stückchenweise aneinanderzureihen,
auch für Variation, und auch Soundeffekte einfach mit hineinzumischen, also alles ohne Resampling.
Ansonsten überlege ich auch, ob man Sprites nicht noch effektiver Speichern kann. Evtl. zerlegen
in Blöcke von 4x4 Pixeln oder so, welche dann mitunter nur 1 - 16 Farben enthalten und entsprechend
wenig Speicher bzw. Bits benötigen. Das gibt natürlich dann viele Paletten, die man sinnvoller auch
Sprite-Übergreifend anlegt - ist erstmal nur eine Idee. Skalierung würde ich eher nicht benötigen, und
Drehungen nur 90 Grad, und/oder Spiegeln / Flippen.
Wobo, mir macht es eben ab und an Spass zu programmieren, denn heute klappen die Programme
meistens sofort beim ersten oder zweiten Anlauf, während ich früher erstmal über dutzende
Stolpersteine gefallen bin. Und ich mache das auch wirklich nur nebenbei. Macht halt einfach
schonmal Spass. Das ist wohl auch der Grund, warum ich den Real Mode bevorzuge: Durch die
Einschränkungen kommt es mir zumindest so vor, als wenn schon relativ kleine Programme
ihr Dasein rechtfertigen, bzw. Spiele, die technisch relativ bescheiden sind, sprich, kein 3D usw.
Das ist eine gute Sichtweise: Real Mode zu nutzen ist "korrekt" bis zu dem Zeitpunkt, wo 32 Bit Code
Pflicht wurde (Windows). Ganz klar ist mir gerade aber nicht, ob XMS auch erst ab 32 Bit möglich war.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
Zu der Sprite-Sache:
Ich hatte schon seit längerem die Idee, eine VGA-Standard-Palette zu machen.
Ist ja denkbar einfach. Vorläufig gelöst habe ich die Sache, indem ich für Rot und Grün
je 3 Bit verwendet habe und für Blau 2. Mein Empfinden ist so, dass man bei Blau weniger
empfindlich für Abstufungen ist.
Die Ergebnisse sind recht gut, Fotos auf diese Palette zurechtgestutzt sehen ungefähr so
aus, als hätte man 32-64 Farben speziell für das Foto reserviert. Für Pixelgrafik dürfte
es allemal reichen.
Der Vorteil davon ist nun, beispielsweise, man kann ohne Tabelle für jede Farbe Zwischenwerte
machen, z.B. für Transparenz. Oder Anti-Aliasing. Viel interessanter finde ich aber, dass man nun alles
in 3 Kanäle aufgeteilt vorliegen hat, und nun allerlei Möglichkeiten zur verlustfreien oder auch verlustbehafteten
Kompression hat.
Das ist jetzt OT, ich denke mal, wenn jemand daran noch interessiert sein sollte, einfach
vielleicht hier kurz melden, dann machen wir nen Thread dafür auf.
Ich hatte schon seit längerem die Idee, eine VGA-Standard-Palette zu machen.
Ist ja denkbar einfach. Vorläufig gelöst habe ich die Sache, indem ich für Rot und Grün
je 3 Bit verwendet habe und für Blau 2. Mein Empfinden ist so, dass man bei Blau weniger
empfindlich für Abstufungen ist.
Die Ergebnisse sind recht gut, Fotos auf diese Palette zurechtgestutzt sehen ungefähr so
aus, als hätte man 32-64 Farben speziell für das Foto reserviert. Für Pixelgrafik dürfte
es allemal reichen.
Der Vorteil davon ist nun, beispielsweise, man kann ohne Tabelle für jede Farbe Zwischenwerte
machen, z.B. für Transparenz. Oder Anti-Aliasing. Viel interessanter finde ich aber, dass man nun alles
in 3 Kanäle aufgeteilt vorliegen hat, und nun allerlei Möglichkeiten zur verlustfreien oder auch verlustbehafteten
Kompression hat.
Das ist jetzt OT, ich denke mal, wenn jemand daran noch interessiert sein sollte, einfach
vielleicht hier kurz melden, dann machen wir nen Thread dafür auf.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
XMS bis 2.0 ist reines 16-bit. Erst XMS ab 3.0 ist 32-bit. XMS 2.0 ist aber der eigentliche Standard zu DOS-Zeiten und ermöglicht knapp 64 MB extended memory (=65535kb), während XMS 3.0 dann die vollen 4 GB XMS zur Verfügung stellen kann. Aber die braucht eh niemand: 64 MB sind alle Mal genugzatzen hat geschrieben: Ganz klar ist mir gerade aber nicht, ob XMS auch erst ab 32 Bit möglich war.
.Re: Trackermodul-Engine (sehr einfach)
Ich habe eine Subroutine geschrieben, mit der mal so Paletten generieren kann - aber nicht nur bit-abhängig (also "wieviele Bits pro Farbphase R-G-B), sondern wieviele Stufen.zatzen hat geschrieben:Zu der Sprite-Sache:
Ich hatte schon seit längerem die Idee, eine VGA-Standard-Palette zu machen.
Ist ja denkbar einfach. Vorläufig gelöst habe ich die Sache, indem ich für Rot und Grün
je 3 Bit verwendet habe und für Blau 2. Mein Empfinden ist so, dass man bei Blau weniger
empfindlich für Abstufungen ist.
Die Ergebnisse sind recht gut, Fotos auf diese Palette zurechtgestutzt sehen ungefähr so
aus, als hätte man 32-64 Farben speziell für das Foto reserviert. Für Pixelgrafik dürfte
es allemal reichen.
Der Vorteil davon ist nun, beispielsweise, man kann ohne Tabelle für jede Farbe Zwischenwerte
machen, z.B. für Transparenz. Oder Anti-Aliasing. Viel interessanter finde ich aber, dass man nun alles
in 3 Kanäle aufgeteilt vorliegen hat, und nun allerlei Möglichkeiten zur verlustfreien oder auch verlustbehafteten
Kompression hat.
Das ist jetzt OT, ich denke mal, wenn jemand daran noch interessiert sein sollte, einfach
vielleicht hier kurz melden, dann machen wir nen Thread dafür auf.
Deine Palette wäre 8-8-4
Ich nehme gern 6-7-6, wenn ich eine "Standard" Palette brauche. Sind 252 Farben. (hat man noch 4 frei zB für Keyfarbe usw.)
Und ja: Das würde sich etwas dämlich berechnen, wenn man wissen will, welche Farbe man braucht usw.
ABER:
Das Ding legt auch drei Arrays zu je 256 Bytes an, eins für rot, eins für grün, eins für blau.
In jedem Array stehen die "Addier-Werte" drin (gleich "hochgerechnet"), die man braucht, um die 24bit-Farbe in die 8-bit Farbe umzurechnen.
Nehmen wir an, die 24bit Farbe ist RRGGBB
Also ist Result=ROT[RR]+GRUEN[GG]+BLAU[BB]
Man kann frei wählen, wieviele Stufen jede Farbphase haben soll, sinnvoll ist natürlich minimal 2. Außerdem sollten alle Phasen miteinander multipliziert natürlich maximal 256 ergeben.
Aber ja: Eigentlich gehört's natürlich nicht zum "Tracker" Thema - wäre wohl besser, einen eigenen Thread dafür anzulegen.
Re: Trackermodul-Engine (sehr einfach)
Hallo, ich habe ja einen Thread aufgemacht zum eigenen Videoformat. Daher hier nur kurz.
Eine 6-7-6 Platte scheint mir auch sehr sinnvoll, denn Rot und Blau empfinde auch ich als deutlich
weniger prägnant als Grün. Aber mit 8-8-4 sehen Bilder auch gut aus, und mit dieser Auslegung
kann ich zum einen bei Blau mehr Redundanzen rauskürzen, und vom Datenformat her deckt es
jeweils die kompletten Bitbereiche ab, und eine Farbe zu wählen aus RGB ist halt sehr einfach,
man kann ohne viel Rechnen und Tabelle einfach die Werte zusammensetzen.
Letztlich müsste ich aber auch sehen, ob 6-7-6 wirklich besser aussieht als 8-8-4.
Nach wie vor scheint es kompressionstechnisch ersteinmal günstiger, wenn Blau von Haus aus
mit einem Bit weniger auskommt. Muss ich mir mal eine 6-7-6 generieren...
Wobei ich gerade denke, auch für Kompressionstechniken könnte es interessant werden,
wenn ich für Blau und Rot max. zwar nur Werte bis 5 habe, aber mit den Werten 6 und 7 noch
irgendwas flaggen kann.
Eine 6-7-6 Platte scheint mir auch sehr sinnvoll, denn Rot und Blau empfinde auch ich als deutlich
weniger prägnant als Grün. Aber mit 8-8-4 sehen Bilder auch gut aus, und mit dieser Auslegung
kann ich zum einen bei Blau mehr Redundanzen rauskürzen, und vom Datenformat her deckt es
jeweils die kompletten Bitbereiche ab, und eine Farbe zu wählen aus RGB ist halt sehr einfach,
man kann ohne viel Rechnen und Tabelle einfach die Werte zusammensetzen.
Letztlich müsste ich aber auch sehen, ob 6-7-6 wirklich besser aussieht als 8-8-4.
Nach wie vor scheint es kompressionstechnisch ersteinmal günstiger, wenn Blau von Haus aus
mit einem Bit weniger auskommt. Muss ich mir mal eine 6-7-6 generieren...
Wobei ich gerade denke, auch für Kompressionstechniken könnte es interessant werden,
wenn ich für Blau und Rot max. zwar nur Werte bis 5 habe, aber mit den Werten 6 und 7 noch
irgendwas flaggen kann.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
Hmm naja es hält sich so die Waage, manches sieht leicht besser aus mit 6-7-6, manches eher schlechter.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
Es kommt immer auf das Bild an. Wasser und Himmel sieht mir weniger Blau nicht gut aus.
Dagegen Hautfarbe profitiert von Rot und Grün.
Ich verwende halt die 6-7-6, weil sie am "allgemeinsten" ist.
(Da grün die "hellste" der 3 Phasen ist, ist es sinnvoll, Grün als die 7er zu nehmen.)
6-6-6 kann man auch nehmen, sind dann 216 Farben (40 bleiben frei).
Indem man gleiche Anzahl Phasen nimmt, hat man natürlich auch reine Grautöne, ansonsten differieren sie immer leicht in den Grün- und Pink-Bereich (bei 6-7-6).
Mittlerweile tendiere ich wieder eher zu "manuell" erstellten Paletten. Also so einen dunkel-nach-hell "braun/orange/beige" Paletten-Anteil für Hauttöne, das gleiche für Blau und Grün, dann Grau-Anteile. Und alles was "bunte, unnatürliche" Farben sind, dafür auf weniger Anteile reduzieren. Auf die Art erreiche ich natürlicher aussehende Bilder. Wenn ich ein Spiel mache, will ich, daß es nicht so "reduziert" AUSSIEHT, auch wenn ich mit reduzierten Dingen arbeite.
Wenn ich sehe, was Lucas Art mit 256 Farben in seinen Adventures für eine Grafik hinbekommen hat - und dagegen manche Leute, die gleich mit 24bit um sich werfen, nur um alles mit monotonen großflächigen Farbverläufen füllen zu können, die dann eher "geometrisch-klotzig" wirken, weil eben keine "Details"...
Ich staune immer wieder, was Leute z.B. auf dem C64 mit 16 Farben und einem 3stimmingen Synthesizer (zugegeben einem sehr guten) so angestellt haben - davon abgesehen, daß die Speicheranordnung für Grafik aufgrund der Bauweise und Speicherspar-Eigenschaften der Grafik recht ... abenteuerlich ist.
Da zeigt sich, was gute Programmierer/Grafiker/Musiker, die sich Zeit nehmen, aus vorhandenen Mitteln machen können und da zeigt sich wahre Kunst.
Das Gegenteil davon ist, immer gleich die höchsten technischen Standards als Mindestvoraussetzung anzusetzen und den dadurch gegebenen Möglichkeiten nicht einmal zu 5% gerecht zu werden - was heutzutage eher Gang-und-Gäbe ist.
Man nennt diese Art Charakterzug der heutigen Gesellschaft "instant gratification", - locker übersetzt mit "sofortige Belohnung". Alles muß einfach und leicht und ohne viel Mühe zu machen sein und der Erfolg muß quasi GLEICH oder SOFORT eintreten - egal, ob man damit immer nur die ganze Zeit Mittelmäßigkeit verherrlicht und zum Maß der Dinge erhebt...
Da gibt's so ein schönes Lied namens "Manfred" von Rainald Grebe.
Am besten finde ich diese Stelle:
"Der Mittelweg ist golden, der Durchschnitt ist gesund.
Schnapp nie nach der Wurst, wenn sie zu hoch hängt - das weiß doch jeder Hund.
Himalaya und Tiefsee sind beide so konkret -
aber die deutschen Mittelgebirge sind sowas von Manfred..."
Besser könnte ich das auch nicht ausdrücken...
(Auch wenn ich mindestens einen Manfred kenne, bei dem das - zumindest programmiertechnisch - in keinster Weise zutrifft. Der Name in dem Lied war wohl einfach als "Deutscher Durchschnitts-Mittelschicht-Typ" gewählt.)
Dagegen Hautfarbe profitiert von Rot und Grün.
Ich verwende halt die 6-7-6, weil sie am "allgemeinsten" ist.
(Da grün die "hellste" der 3 Phasen ist, ist es sinnvoll, Grün als die 7er zu nehmen.)
6-6-6 kann man auch nehmen, sind dann 216 Farben (40 bleiben frei).
Indem man gleiche Anzahl Phasen nimmt, hat man natürlich auch reine Grautöne, ansonsten differieren sie immer leicht in den Grün- und Pink-Bereich (bei 6-7-6).
Mittlerweile tendiere ich wieder eher zu "manuell" erstellten Paletten. Also so einen dunkel-nach-hell "braun/orange/beige" Paletten-Anteil für Hauttöne, das gleiche für Blau und Grün, dann Grau-Anteile. Und alles was "bunte, unnatürliche" Farben sind, dafür auf weniger Anteile reduzieren. Auf die Art erreiche ich natürlicher aussehende Bilder. Wenn ich ein Spiel mache, will ich, daß es nicht so "reduziert" AUSSIEHT, auch wenn ich mit reduzierten Dingen arbeite.
Wenn ich sehe, was Lucas Art mit 256 Farben in seinen Adventures für eine Grafik hinbekommen hat - und dagegen manche Leute, die gleich mit 24bit um sich werfen, nur um alles mit monotonen großflächigen Farbverläufen füllen zu können, die dann eher "geometrisch-klotzig" wirken, weil eben keine "Details"...
Ich staune immer wieder, was Leute z.B. auf dem C64 mit 16 Farben und einem 3stimmingen Synthesizer (zugegeben einem sehr guten) so angestellt haben - davon abgesehen, daß die Speicheranordnung für Grafik aufgrund der Bauweise und Speicherspar-Eigenschaften der Grafik recht ... abenteuerlich ist.
Da zeigt sich, was gute Programmierer/Grafiker/Musiker, die sich Zeit nehmen, aus vorhandenen Mitteln machen können und da zeigt sich wahre Kunst.
Das Gegenteil davon ist, immer gleich die höchsten technischen Standards als Mindestvoraussetzung anzusetzen und den dadurch gegebenen Möglichkeiten nicht einmal zu 5% gerecht zu werden - was heutzutage eher Gang-und-Gäbe ist.
Man nennt diese Art Charakterzug der heutigen Gesellschaft "instant gratification", - locker übersetzt mit "sofortige Belohnung". Alles muß einfach und leicht und ohne viel Mühe zu machen sein und der Erfolg muß quasi GLEICH oder SOFORT eintreten - egal, ob man damit immer nur die ganze Zeit Mittelmäßigkeit verherrlicht und zum Maß der Dinge erhebt...
Da gibt's so ein schönes Lied namens "Manfred" von Rainald Grebe.
Am besten finde ich diese Stelle:
"Der Mittelweg ist golden, der Durchschnitt ist gesund.
Schnapp nie nach der Wurst, wenn sie zu hoch hängt - das weiß doch jeder Hund.
Himalaya und Tiefsee sind beide so konkret -
aber die deutschen Mittelgebirge sind sowas von Manfred..."
Besser könnte ich das auch nicht ausdrücken...
(Auch wenn ich mindestens einen Manfred kenne, bei dem das - zumindest programmiertechnisch - in keinster Weise zutrifft. Der Name in dem Lied war wohl einfach als "Deutscher Durchschnitts-Mittelschicht-Typ" gewählt.)
Re: Trackermodul-Engine (sehr einfach)
Ok, mit der Palette ist das natürlich so eine Sache.
Ich erinnere mich natürlich noch sehr gut, wie begeistert ich früher
war, wenn ich 256 Farben Grafik gesehen habe mit scheinbar stufenlosen
großflächigen Farbverläufen. Und dass ich enttäuscht war, sogar schon
bei LucasArts, insbesondere Indiana Jones 4, sobald solche Verläufe
offensichtlich nur gedithert waren.
Aber alles hat sein für und wider. Seit der Windows-Ära und Truecolor
sind stufenlose Farbverläufe nichts besonderes mehr, und so bin ich
wieder offen für Grafik, die mehr "Acrylgemäle" Charakter hat, bzw.
eben mehr nach kunstvoller Ausnutzung von 16 oder 32 Farben aussieht.
Letztlich wäre das alles aber auch kein Hindernis für die Kompressions-
routinen die ich gerade schreibe, denn die funktionieren für beliebige
Paletten, vielleicht lediglich für 8-8-4 effektiver.
LucasArts hat schon mit EGA ganz nette Sachen hinbekommen, und
EGA zumindest steckt die 8-8-4 Palette in die Tasche.
Jede Grafik hat so ihr eigenes Flair, alles kann reizvoll sein, von CGA bis Truecolor...
Mit 8-8-4 sieht vieles dann reduziert aus, aber man hat ein schönes Feature,
und das ist Transparenz, man könnte also beispielsweise nicht nur ein "Loch"
z.B. in Sprites reinmachen, sondern man kann auch Glasobjekte darstellen,
bei denen an beliebiger Stelle der Hintergrund eingefärbt durchscheint.
Ich weiss dass du das alles auch in deinem System gemacht hast, meins
ist halt noch eine andere Herangehensweise, ich finde auch die 8x8 Blöcke-
Sache schön, man kann die Grafiken unbekümmert gestalten wie man
will und sie werden immer so klein wie möglich abgelegt.
So kann ich auch eine Level-Map, anstatt sie aus einzelnen Blöcken
zusammenzusetzen im Level-Editor, komplett als nicht-redundante
riesige Grafik gestalten, solange ich nicht zu viel mit schwer komprimierbaren
Flächen gestalte. Das ist, wenn ich weit zurückblicke, nämlich auch eine
Sache die mich faszinierte, eine Level regelrecht "malen", und nicht zusammensetzen
aus sagen wir mal 32 immer gleichen Formen.
Ich bin mir nicht sicher, aber ich glaube wenn ich für Transparenz noch
eine Tabelle bemühen müsste oder zusätzlich noch eine für ene 6-7-6
Palette, dann würde das schon etwas langsamer werden.
Und ich merke gerade, es gibt verschiedene Arten von Transparenz,
sowohl eine subtraktive als auch, dass man den Mittelwert bildet für
einen gewissen deckenden Effekt. Und dann gibt es auch noch andere
arithmetische Dinge die man anstellen kann.
Ein bisschen zurück zum Thema:
Ich überlege auch an einem Sample Format, speziell für Sprachausgabe.
Ich möchte gern bei einem Spiel alles levelweise machen. Und trotzdem
sollen einige (10-20 ?) Sekunden Sprache rein (in 640K !). Dazu muss ich mal probieren
ob ich ein 2 oder sogar 1 Bit Delta + Multiplikator Verfahren einsetze, Multiplikator
schon bei den Deltas, die dann entsprechend "aufgeblasen" addiert den nächsten
Wert ergeben.
Was das Musikformat angeht denke ich, mache ich aus Geschwindigkeits und
Qualitätsgründen jetzt unkomprimierte Samples, aber noch ein oder zwei Kanäle
mit diesen Delta-komprimierten Samples, die dann deshalb noch recht einfach
zu integrieren sind, weil sie nur auf ihrer Basisfrequenz (= Mischfrequenz oder
halbe) abgespielt werden sollen. Eignen sich somit also für Drums oder Gesang.
Ja, Manfred... Vielleicht ist es das, warum ich lieber im Realmode rummache als in Windows.
Ich hätte absolut kein Interesse, ein Spiel objektorientiert zu schreiben, quasi nur noch
Hardware-fern irgendwelche Dinge zu definieren. Vielleicht sollte man da besser Regisseur
werden. Oder auch, die quasi nicht vorhandenen technischen Grenzen heutiger Systeme
nutze ich nur, wenn es mir auf das Endergebnis pur ankommt. Aber ein Spiel für DOS ist
mehr als das, es ist als wenn man sich eine Maschine komplett selbst auf baut, jedes
Schräubchen persönlich.
Ich erinnere mich natürlich noch sehr gut, wie begeistert ich früher
war, wenn ich 256 Farben Grafik gesehen habe mit scheinbar stufenlosen
großflächigen Farbverläufen. Und dass ich enttäuscht war, sogar schon
bei LucasArts, insbesondere Indiana Jones 4, sobald solche Verläufe
offensichtlich nur gedithert waren.
Aber alles hat sein für und wider. Seit der Windows-Ära und Truecolor
sind stufenlose Farbverläufe nichts besonderes mehr, und so bin ich
wieder offen für Grafik, die mehr "Acrylgemäle" Charakter hat, bzw.
eben mehr nach kunstvoller Ausnutzung von 16 oder 32 Farben aussieht.
Letztlich wäre das alles aber auch kein Hindernis für die Kompressions-
routinen die ich gerade schreibe, denn die funktionieren für beliebige
Paletten, vielleicht lediglich für 8-8-4 effektiver.
LucasArts hat schon mit EGA ganz nette Sachen hinbekommen, und
EGA zumindest steckt die 8-8-4 Palette in die Tasche.
Jede Grafik hat so ihr eigenes Flair, alles kann reizvoll sein, von CGA bis Truecolor...
Mit 8-8-4 sieht vieles dann reduziert aus, aber man hat ein schönes Feature,
und das ist Transparenz, man könnte also beispielsweise nicht nur ein "Loch"
z.B. in Sprites reinmachen, sondern man kann auch Glasobjekte darstellen,
bei denen an beliebiger Stelle der Hintergrund eingefärbt durchscheint.
Ich weiss dass du das alles auch in deinem System gemacht hast, meins
ist halt noch eine andere Herangehensweise, ich finde auch die 8x8 Blöcke-
Sache schön, man kann die Grafiken unbekümmert gestalten wie man
will und sie werden immer so klein wie möglich abgelegt.
So kann ich auch eine Level-Map, anstatt sie aus einzelnen Blöcken
zusammenzusetzen im Level-Editor, komplett als nicht-redundante
riesige Grafik gestalten, solange ich nicht zu viel mit schwer komprimierbaren
Flächen gestalte. Das ist, wenn ich weit zurückblicke, nämlich auch eine
Sache die mich faszinierte, eine Level regelrecht "malen", und nicht zusammensetzen
aus sagen wir mal 32 immer gleichen Formen.
Ich bin mir nicht sicher, aber ich glaube wenn ich für Transparenz noch
eine Tabelle bemühen müsste oder zusätzlich noch eine für ene 6-7-6
Palette, dann würde das schon etwas langsamer werden.
Und ich merke gerade, es gibt verschiedene Arten von Transparenz,
sowohl eine subtraktive als auch, dass man den Mittelwert bildet für
einen gewissen deckenden Effekt. Und dann gibt es auch noch andere
arithmetische Dinge die man anstellen kann.
Ein bisschen zurück zum Thema:
Ich überlege auch an einem Sample Format, speziell für Sprachausgabe.
Ich möchte gern bei einem Spiel alles levelweise machen. Und trotzdem
sollen einige (10-20 ?) Sekunden Sprache rein (in 640K !). Dazu muss ich mal probieren
ob ich ein 2 oder sogar 1 Bit Delta + Multiplikator Verfahren einsetze, Multiplikator
schon bei den Deltas, die dann entsprechend "aufgeblasen" addiert den nächsten
Wert ergeben.
Was das Musikformat angeht denke ich, mache ich aus Geschwindigkeits und
Qualitätsgründen jetzt unkomprimierte Samples, aber noch ein oder zwei Kanäle
mit diesen Delta-komprimierten Samples, die dann deshalb noch recht einfach
zu integrieren sind, weil sie nur auf ihrer Basisfrequenz (= Mischfrequenz oder
halbe) abgespielt werden sollen. Eignen sich somit also für Drums oder Gesang.
Ja, Manfred... Vielleicht ist es das, warum ich lieber im Realmode rummache als in Windows.
Ich hätte absolut kein Interesse, ein Spiel objektorientiert zu schreiben, quasi nur noch
Hardware-fern irgendwelche Dinge zu definieren. Vielleicht sollte man da besser Regisseur
werden. Oder auch, die quasi nicht vorhandenen technischen Grenzen heutiger Systeme
nutze ich nur, wenn es mir auf das Endergebnis pur ankommt. Aber ein Spiel für DOS ist
mehr als das, es ist als wenn man sich eine Maschine komplett selbst auf baut, jedes
Schräubchen persönlich.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
Ich denke gerade ein bisschen voraus an den Player für meine Trackerfiles...
Wäre es nicht praktisch, wenn man für die Position im Sample sowie für
die abspiel-Schritt-Geschwindigkeit einfach ein DWORD nimmt? Wenn
es das in Pascal gibt und nicht nu Longint...
Das wäre nämlich möglich, weil ich auch keine Samples > 64K verwenden
möchte. Es wäre dann auch sehr genau, nur frage ich mich grade, kann
ich das dann auch in Assembler einfach gestalten? Da bräuchte ich ja
Register wie EAX, kann man die auch in oberes und unteres Word aufteilen?
Wäre es nicht praktisch, wenn man für die Position im Sample sowie für
die abspiel-Schritt-Geschwindigkeit einfach ein DWORD nimmt? Wenn
es das in Pascal gibt und nicht nu Longint...
Das wäre nämlich möglich, weil ich auch keine Samples > 64K verwenden
möchte. Es wäre dann auch sehr genau, nur frage ich mich grade, kann
ich das dann auch in Assembler einfach gestalten? Da bräuchte ich ja
Register wie EAX, kann man die auch in oberes und unteres Word aufteilen?
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Trackermodul-Engine (sehr einfach)
Wenn Du unterhalb 64kB bleiben willst, brauchst Du nur WORD (gibts in Pascal), das ist 16bit ohne Vorzeichen (0-65535).
DWORD ist 32bit ohne Vorzeichen - also 4GB. (gibt's leider nicht in Pascal, das hat nur Longint (32bit MIT Vorzeichen +/- 2GB *).
Um mal wieder auf Tracker/Musik zurückzukommen:
Übrigens ist meine Abspielroutine für mein Musikformat letztens - quasi - "Stufe-1-fertig" geworden:
Alles, was sie in der ersten Stufe können sollte, ist jetzt implementiert, das heißt:
16 Stimmen, einzeln für jede Stimme: Lautstärke, Hüllkurve (ADSR), Wellenformen (7 Wellenformen, auch miteinander rekombinierbar und in verschiedenen Subfrequenzen mischbar), die 8. "Wellenform" funktioniert nur alleine und ist blaues Rauschen. Außerdem habe ich letztens den Portamento (weichen Übergang zwischen Noten) Befehl noch umgesetzt.
Was jetzt noch fehlt: Abspielen von Samples und die "arithmetischen Sonderbefehle". (Damit sind quasi "Berechnungen" möglich und ein wenig "Spielerei" mit den Registern. Diese Sub-Befehle sind dann nur für so Oberfreaks gedacht, denen das, was das Ding jetzt schon kann, noch nicht ausreicht.
Wie ich schonmal erwähnte, wird alles auf 4bit basiert generiert, d.h.: 16 Lautstärken, 16 verschiedene Werte jeweils für ADSR (Attack/Decay/Sustain/Release) Der Noisegenerator arbeitet mit 16bit (von denen die oberen 4 dann für den Klang benutzt werden - damit ergibt sich selbst mit der höchstmöglichen Tonfrequenz von knapp 4 KHz eine "Rauschwiederholung" von etwas über 16 Sekunden - das sollte ausreichen.
Und ja - Kombination von Portamento und Noise klingt schon irgendwie geil, so ansteigendes Rauschen als würde 'ne Rakete starten oder sowas... Aber für Explosionen muß ich mich wohl doch nochmal mit Filtern befassen, bin was das angeht damit noch nicht zufrieden...
Ja, es ist klein, es ist einfach, es ist von jemandem gemacht, der von Musik keine Ahnung hat und Musik genauso macht wie alles andere in seinem Leben: Mathematisch...
Vielleicht kann man ja trotzdem etwas damit anfangen.
Am Editor bin ich immer noch dran. Die Bedienung läßt derzeit noch einiges zu wünschen übrig - da ist noch einiges an Arbeit nötig.
Schade, daß die meisten Leute sich nicht mehr auf digitale Klangsynthese einlassen wollen, sondern eher (MOD-artig) ausschließlich mit fertigen Samples arbeiten wollen.
Ich habe mich bei dem Ding halt irgendwie ein wenig am SID des C64 orientiert (auch wenn mein Teil lange nicht die Qualität hat - ich habe z.B. noch keine FILTER drin und bisher auch noch keine wirkliche Idee, wie ich das softwareseitig umsetzen sollte. Obwohl ich auch einen Filter-Befehl bereits vorgesehen habe - nur macht der bisher noch gar nichts, und die Parameter dafür sind noch nicht definiert. Da ich 9 Bit frei habe, überlege ich schon, 6 bit für die Frequenzen in verschiedenen Stufen zu nutzen und 3 Bit um festzulegen, welche Art Filter/Pass man einstellen will, in verschiedenen Kombinationen aus treble, band und bass.
Und ja - das Internet ist voll von (komplizierten) Formeln, wie man (elektronische) Filter berechnet. Aber: Das Ganze soll ja noch Performance haben UND ich meine, das muß auch einfacher gehen. Ich habe zwar schon Ideen dazu, es auf eine recht abenteuerliche Art zu realisieren - aber da muß ich dann auch hören, ob es auch wirklich so funktioniert.
Bisher teste ich den ganzen Krempel auch nur mit der einen Stimme - um zu sehen bzw auch HÖREN, ob es funktioniert. Es bleibt abzuwarten, wieviel Performance die Klangsynthese von 16 Stimmen gleichzeitig verbrauchen wird und ob das Ganze dann überhaupt noch für Spiele tauglich sein wird. Ich meine: Alleine der Einsatz von 100% Assembler (wie in meinem Fall) ist zwar schon chic - aber auch Assembler kann nicht zaubern... Und ich bin ja nur ein kleiner Wicht - ich bin nicht so vermessen, mich mit wahren Programmiergrößen zu messen, die Dinge wie IPLAY oder MPXPLAY gebaut haben.
DWORD ist 32bit ohne Vorzeichen - also 4GB. (gibt's leider nicht in Pascal, das hat nur Longint (32bit MIT Vorzeichen +/- 2GB *).
Um mal wieder auf Tracker/Musik zurückzukommen:
Übrigens ist meine Abspielroutine für mein Musikformat letztens - quasi - "Stufe-1-fertig" geworden:
Alles, was sie in der ersten Stufe können sollte, ist jetzt implementiert, das heißt:
16 Stimmen, einzeln für jede Stimme: Lautstärke, Hüllkurve (ADSR), Wellenformen (7 Wellenformen, auch miteinander rekombinierbar und in verschiedenen Subfrequenzen mischbar), die 8. "Wellenform" funktioniert nur alleine und ist blaues Rauschen. Außerdem habe ich letztens den Portamento (weichen Übergang zwischen Noten) Befehl noch umgesetzt.
Was jetzt noch fehlt: Abspielen von Samples und die "arithmetischen Sonderbefehle". (Damit sind quasi "Berechnungen" möglich und ein wenig "Spielerei" mit den Registern. Diese Sub-Befehle sind dann nur für so Oberfreaks gedacht, denen das, was das Ding jetzt schon kann, noch nicht ausreicht.
Wie ich schonmal erwähnte, wird alles auf 4bit basiert generiert, d.h.: 16 Lautstärken, 16 verschiedene Werte jeweils für ADSR (Attack/Decay/Sustain/Release) Der Noisegenerator arbeitet mit 16bit (von denen die oberen 4 dann für den Klang benutzt werden - damit ergibt sich selbst mit der höchstmöglichen Tonfrequenz von knapp 4 KHz eine "Rauschwiederholung" von etwas über 16 Sekunden - das sollte ausreichen.
Und ja - Kombination von Portamento und Noise klingt schon irgendwie geil, so ansteigendes Rauschen als würde 'ne Rakete starten oder sowas... Aber für Explosionen muß ich mich wohl doch nochmal mit Filtern befassen, bin was das angeht damit noch nicht zufrieden...
Ja, es ist klein, es ist einfach, es ist von jemandem gemacht, der von Musik keine Ahnung hat und Musik genauso macht wie alles andere in seinem Leben: Mathematisch...
Vielleicht kann man ja trotzdem etwas damit anfangen.
Am Editor bin ich immer noch dran. Die Bedienung läßt derzeit noch einiges zu wünschen übrig - da ist noch einiges an Arbeit nötig.
Schade, daß die meisten Leute sich nicht mehr auf digitale Klangsynthese einlassen wollen, sondern eher (MOD-artig) ausschließlich mit fertigen Samples arbeiten wollen.
Ich habe mich bei dem Ding halt irgendwie ein wenig am SID des C64 orientiert (auch wenn mein Teil lange nicht die Qualität hat - ich habe z.B. noch keine FILTER drin und bisher auch noch keine wirkliche Idee, wie ich das softwareseitig umsetzen sollte. Obwohl ich auch einen Filter-Befehl bereits vorgesehen habe - nur macht der bisher noch gar nichts, und die Parameter dafür sind noch nicht definiert. Da ich 9 Bit frei habe, überlege ich schon, 6 bit für die Frequenzen in verschiedenen Stufen zu nutzen und 3 Bit um festzulegen, welche Art Filter/Pass man einstellen will, in verschiedenen Kombinationen aus treble, band und bass.
Und ja - das Internet ist voll von (komplizierten) Formeln, wie man (elektronische) Filter berechnet. Aber: Das Ganze soll ja noch Performance haben UND ich meine, das muß auch einfacher gehen. Ich habe zwar schon Ideen dazu, es auf eine recht abenteuerliche Art zu realisieren - aber da muß ich dann auch hören, ob es auch wirklich so funktioniert.
Bisher teste ich den ganzen Krempel auch nur mit der einen Stimme - um zu sehen bzw auch HÖREN, ob es funktioniert. Es bleibt abzuwarten, wieviel Performance die Klangsynthese von 16 Stimmen gleichzeitig verbrauchen wird und ob das Ganze dann überhaupt noch für Spiele tauglich sein wird. Ich meine: Alleine der Einsatz von 100% Assembler (wie in meinem Fall) ist zwar schon chic - aber auch Assembler kann nicht zaubern... Und ich bin ja nur ein kleiner Wicht - ich bin nicht so vermessen, mich mit wahren Programmiergrößen zu messen, die Dinge wie IPLAY oder MPXPLAY gebaut haben.