Seite 16 von 22

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Do 2. Aug 2018, 21:06
von DOSferatu
zatzen hat geschrieben:Danke für die Antwort!
Freut mich sehr!

Ja, es ist sehr warm, und zudem befinde ich mich momentan mal wieder mehr im Real Life, Lautsprecher bauen, Musik bearbeiten / machen.
Du baust selbst Lautsprecher?
zatzen hat geschrieben: Deswegen wird mein Versprechen mit den nächsten ZSMs und der nächsten Programmversion auch noch etwas hinausgeschoben. Sind bis jetzt aber schon einige sehr schöne Stücke dabei, die technisch teils auch sehr interessant sind.
Kennst mich ja: Ich mag es, wenn jemand mit wenigen Stimmen und kleinen (oder gar keinen) Samples coole Sachen hinkriegt. Ich sag nur: Chris Hülsbeck (und viele andere) auf C64. Drei Stimmen, digitale Klangsynthese per Chip - und: Der WAHNSINN, was die damit angestellt haben! So stell' ich mir das vor!
zatzen hat geschrieben:Dass Du eine Tracker GUI für ISM geschrieben hast ist doch großartig, zumindest für mich.
Naja... Erst mal sehen, ob die Tracker-Tracker damit klarkommen. So richtig schön ist es noch nicht - aber da bin ich für Vorschläge offen, weil ich das Ding nicht für mich baue, sondern für Leute, die 'ne Trackeransicht brauchen.
zatzen hat geschrieben:Ich habe mich die letzten Jahre bloß eher beim Komponieren auf Samples gestützt, die schon wechselnde Harmonien oder Melodien vorgeben, und ich musste nur noch dazu improvisieren. Muss ich mal sehen ob ich auch etwas "from scratch" hinbekomme, aber das wird schon gehen.
Naja, schon fertige Melodien per Sample, das ist ja quasi schon fast "WAV-light", also das, was ich letzten erwähnt habe: Wenn man schon ein halbes Musikstück als fertiges Sample vorliegen hat, das ist für mich weder MOD, noch digitale Klangsynthese...
zatzen hat geschrieben:Zu meiner Überlegung würde ich schlussfolgern, dass ich das mit den Festplattenzugriffen lieber lasse und stattdessen die Sounddaten aus dem XMS hole. D.h. Sprachausgabe optional über XMS.
Naja, Festplattenzugriffe an sich sind nicht das Problem - es muß eben nur "intelligent" erfolgen - unter Ausnutzung von "Pausen" im Programm usw. - pures "Dauernachladen" ist jedenfalls (meines Erachtens) keine praktikable Lösung.
zatzen hat geschrieben:Und wie Du schon meintest, ist es für uns als Programmierer einfach schöner, wenn das Programm etwas intelligenter strukturiert ist und man nicht einfach alle Daten grob reinstreamt. Heißt, ich werde ZSM nutzen.
Ja, grobes Vorberechnen und dann nur "Abspielen" läßt einem auch zu wenig Möglichkeiten. Ich mag es, als Programmierer die volle Kontrolle über meine "Daten" zu haben und nicht einfach nur so "als fertigen Klotz nutzen".
zatzen hat geschrieben:Die ZSM Engine kann mehr als 16 Kanäle, allerdings habe ich den 16 Bit Puffer so optimiert dass er optimal ausgenutzt wird bei 16 Kanälen, d.h. bei mehr als 16 Kanälen könnte es Überlaufe geben, auch aber nur wenn auf allen Kanälen gerade die volle Sample-Präsenz und -Lautstärke herrscht. Trotzdem würde ich, auch der Performance wegen, die Musik vielleicht auf 8 Kanäle beschränken und die Soundeffekte ebenfalls.
Naja, das Ganze bleibt Dir überlassen. Für "Stand-Only" Musiken kann man ja beliebig abgehen und die Grenzen der Maschine bis zum Anschlag ausreizen. Wenn aber Klangausgabe "konkurrieren" muß mit allem, was es bei Spielen sonst so gibt: Grafikberechnung/-ausgabe, Steuerung und diversen kleinen, aber notwendigen, Hintergrundprozessen..., dann muß sich der Klang, ebenso wie alles andere, insofern einschränken, daß auch noch Raum+Zeit für den Rest zur Verfügung steht... Hatte ich ja alles schon geschrieben.
zatzen hat geschrieben:Letztere kann man von außen triggern, unabhängig von der Musik, ja.
Das ist gut.
ISM erlaubt so eine Art "Kommunikation" zwischen sich selbst und dem Restprogramm über so Puffer. So ist es - intelligente ISM-"Programmierung" vorausgesetzt - für das Hauptprogramm ein Leichtes, Dinge in ISM an-/auszuschalten, zu starten usw.
zatzen hat geschrieben:Meine Programmierfähigkeiten entziehen sich derzeit noch des Könnens und des Verständnisses, um die Ticker so zu gestalten wie Du es in XPYDERZ machst.
Naja, den Ticker auf bestimmte Frequenz setzen sind nur 2 Befehle und den Interruptvektor zu verbiegen kannst Du ja sowieso, weil Du das ja sicher auch mit dem Soundkarten-IRQ-Vektor machst.
zatzen hat geschrieben:Ich bin erstmal überhaupt froh, eine performante Sache mit simplem "warten auf Tonpuffer abgespielt" bzw. "ist die Dauer eines Frames rum?" hinbekommen zu haben.
Ja, ich bin da letztens drauf gekommen, woher EVENTUELL das "Tickern" bei hohen Frequenzen bei mir kommt. Ich schalte zwischen den beiden Puffern um und beginne sofort mit dem Generieren von neuen Daten in der "inaktiven" Pufferhälfte. Aber da sollte ich vielleicht noch warten, d.h. ZWEI Fixpunkte setzen (einer ist: Puffer zu Ende, schalte um auf neuen, der andere ist: Umgeschaltet, jetzt Daten generieren). Mal sehen, ob/wie ich das lösen kann und ob ich den Effekt dann losbekomme.
zatzen hat geschrieben:Du hast mir schon oft genug gesagt dass das ein No-Go ist,
Naja, ein No-Go ist es nicht, allerdings macht man sich damit zu sehr von der Soundausgabe abhängig. Ich programmiere "modular", d.h. die einzelnen Untergruppen wissen gar nicht, was die anderen machen und "Kommunikation" zwischen ihnen erfolgt nur auf bereitgestellten Interfaces. Klar, das modifiziere ich auch schonmal aus Performancegründen - beispielsweise muß man den "normalen Ticker" mit dem "Hochfrequenzticker" zusammenbauen, wenn man sowas wie Soundausgabe über PC-Speaker (oder LPT) machen will. Aber selbst da bemühe ich mich, daß das ganze für die restlichen Komponenten so aussieht "als wär da nix", bzw. als gäbe es kein "Problem" zu beachten.
zatzen hat geschrieben:allerdings sagtest Du mir auch, wenn ich mich recht erinnere, dass der Ton so wie Du es machst bis zu 200 ms hinterherhinken kann, und das wäre für mich ein No-Go.
Ich gehe davon aus, daß quasi JEDES größere Spiel, das es auf dem PC gibt, das genauso macht. "Hinterherhinken" des Tons ist normal, weil man ja nie gleichzeitig den Ton hört, wenn er generiert wird - sondern es wird in einen Puffer geschrieben und man hört ihn erst, wenn die Soundkarte an der entsprechenden Stelle im Puffer angekommen ist.
Gelöst werden kann das nur mit sehr kleinen Puffern, da ist der Versatz "quasi-Null" - ABER: Kleine Puffer haben zwei Probleme:
1.) Wie bereits erwähnt, kosten sie Performance, (das INIT/EXIT-Problem, siehe mein letztes Posting)
2.) Bei kleinen Puffern muß das Programm quasi "die ganze Zeit aufpassen", weil andauernd der Puffer leer wird - für größere andere Prozesse hat man dann gar keine Zeit mehr. Die komplette Abarbeitung in den Interrupt zu legen, wäre zwar eine mögliche Lösung (also sowohl Wechsel des Puffers als auch Berechnung) - allerdings würde der Interrupt das Hauptprogramm recht häufig unterbrechen... Das bremst dann...

Naja. Man müßte sehen, wie sich das in der Praxis hermacht. Eine ganze Grafikszene zu generieren (z.B. 4 Ebenen, mit vielen Sprites) schafft selbst mein 486er nicht in 1/70 Sekunde, also ist mit dieser Konfiguration wohl kein 100% flüssiges Scrolling drin - außer ich lerne, noch performanter zu coden. Aber während ich das generiere, kann ich nicht "aufpassen, ob der Sound neue Daten braucht" - da muß ich es schaffen, daß die Soundkarte diese Zeit "überbrücken kann".
zatzen hat geschrieben:Ich weiss auch nicht ob ich so weit in die Programmier-Materie einsteigen will, letztlich habe ich mir mit dem ZSM Player ersteinmal einen kleinen Jugendtraum erfüllt, und das Ding funktioniert so wie es ist ja erstmal gut und die Anzeigen sind mit dem Ton schön synchron.
Da denk ich grad an Ralph Ruthe's Figur Thorsten Dörnbach: "MÄNSCH, DAS IS DOCH DEIN ALTA JUGENDTRAUM!"

Ja, mein Traum wäre, es, endlich mal ein richtiges Spiel zu bauen. Alles was ich bisher gemacht habe, ist mehr oder weniger simpler Mist oder irgendwelche unfertige Grütze. Auf PC programmiere ich schon seit 1993 (und auf Computern insgesamt seit Mitte der 1980er) - und habe noch nichts Gescheites hinbekommen. Peinlich...
zatzen hat geschrieben:Ich hatte ja schon einen Test gemacht mit relativ viel Grafik, und das lief auf niedrigem 486er Niveau auch noch ganz rund bzw. ohne jegliche Hänger.
Wenn der User den Ton abschaltet bzw. keinen Soundblaster hat, würde ich das
Timing über den Timer realisieren.
Naja, wie gesagt, da ich modular programmiere, würde ich das ganz unabhängig voneinander halten. Das Hauptprogramm muß nur "wissen": Ich habe ein Soundinterface, wenn ich dem sage, Spiele Musik 5 oder Soundeffekt 31, dann macht es das - und ich muß nicht wissen, auf welche Abspielfrequenz der das spielt oder mit welchem Gerät. Das ist die Art, wie ich programmiere.
Und so ist es auch mit der Grafik. Ich habe Steuerdaten der Figuren, da sind Koordinaten, die kollidieren können und irgendwelche Imagenummern usw. und ein Level, das gerade an einer bestimmten Position relativ zum Spieler steht. Und der Grafiksubroutine sag ich nur: Mach was draus!
zatzen hat geschrieben:Ich gehe eben plump davon aus, dass innerhalb einer Frame-Dauer alles berechnet sein muss, und es wäre mir weitaus zu kompliziert, irgendwie fehlende Rechenkapazität bzw. deren Auswirkung gleichmäßig auf die Erscheinung des Spiel zu verteilen.
Naja, ich weiß nicht, vielleicht kann ich es einfach nur schlecht erklären.
Also - es verteilt sich quasi selbst. Da muß man nichts verteilen. Man macht nur sowas wie: Jedesmal wenn ein Bild(Frame) gezeichnet wird, erhöht man einen Zähler um 1. Und in regelmäßigen Abständen fragt man im Ticker, wieviele Bilder er zwischen dem letzten und dem aktuellen Tickeraufruf geschafft hat (im Ticker holt man den Wert aus dem Zähler und setzt den Zähler wieder auf 0). Und über diese geholten Werte bildet man einen Durchschnitt (am besten mit einem Ringpuffer). Dann weiß man, wieviele FPS pro Sekunde geschafft werden. Werden die FPS größer als die Bildwiederholrate des Grafikmodes (z.B. 70Hz beim MCGA, also Mode 13h), dann kann man die Vertical-Retrace-Abfrage ("Warteschleife") anschalten, dann hat man flüssiges Scrolling. Wenn nicht, dann nicht. Dann ruckelts, aber das Spiel läuft mit gleicher Geschwindigkeit.

Das Prinzip ist also: Die Steuerung des Spiels (und aller Figuren inklusive Level) läuft quasi "für sich allein" (als Daten) und die Grafikroutine macht quasi in regelmäßigen Abständen eine "Momentaufnahme" der aktuellen Situation...
zatzen hat geschrieben:Also alles zu seiner Zeit... Kotzman II war von der Rechenzeit so anspruchslos dass ich mit diesem Format sehr gut gefahren bin, ich habe sogar einfach eine Warteschleife genutzt um das Spiel zu bremsen, d.h. die eigentliche Rechenzeit für die Grafik und alles andere war vernachlässigbar.
Naja, wenn man nicht das Bild neuzeichnen muß, sondern quasi einfach nur die Sprites immer "drüberzeichnen" kann, mag das gehen. Es schränkt ein wenig die Möglichkeiten ein, z.B. daß der Hintergrund nur einfarbig sein kann.
zatzen hat geschrieben:Deswegen wäre der nächste logische Schritt für mich ersteinmal, die übrige Rechenkapazität nicht in einer Schleife zu verbraten sondern dem Spiel die Rechenleistung komplett zu geben und eben per Timer oder warten auf Soundpufferwechsel die Framerate zu kontrollieren.
Ja, Warteschleifen sollten nur eingesetzt werden, wenn der restliche Prozeß quasi gar nichts mehr zu tun hat bis zum nächsten "Tick". Es gibt auch einen Maschinenbefehl, der die CPU quasi "totlegt", bis zum nächsten IRQ.
zatzen hat geschrieben:Natürlich nutzt man damit die Rechenkapazizät nicht optimal, das Spiel läuft mit einer festen Framerate und nicht mit so viel wie der Rechner maximal schafft, und durch die fixe Framerate scheiden dann leider auch manche langsamen Computer aus. Das mag Dir ein Dorn im Auge sein, da Du ja immer versuchst so optimal zu programmieren wie möglich.
Naja, "optimal" kann man auf PC leider gar nicht programmieren - durch diese Baukastensystem-Art des PC hat jede Maschine da ein anderes "Optimum". Ich versuche, "so kompatibel wie möglich" zu bleiben, so eine Art "kleinstes gemeinsames Vielfaches"...
zatzen hat geschrieben:Aber ich würde in diesem Fall eine Ausnahme machen, mit meinem Können das mir vertraut ist etwas anfangen, das immerhin besser ist als das was ich 1995 gemacht habe. Es ist dann nicht 100% optimal programmiert aber würde dennoch ein sehenswertes Ergebnis hervorbringen.
Naja, es ist schon schön, daß sich heutzutage überhaupt noch jemand für (hardwarenahe) Spieleprogrammierung interessiert. Und schlußendlich wird sich das Produkt am Ergebnis messen lassen müssen. Wenn es Spaß macht und spielbar ist, ist schon ein großes Ziel erreicht.
zatzen hat geschrieben:Wäre mir das heute passiert mit der Festplatte hätte ich sie wohl retten können. Aber 1994, ohne Internet, noch wenig Erfahrung mit Computern, hatte ich keinen Plan.
Ja, damals habe ich das Internet kaum gekannt und auch nicht ernstgenommen. Heutzutage ist das Ding so totale Normalität geworden...
zatzen hat geschrieben:Ende der 90er mit dem FLI+Sound Player, das war ein anderer Computer (Pentium 200MMX), und mit dem hatte ich nie Probleme bis er sich vor ein paar Jahren verarbschiedete.
Seitdem nutze ich Dosbox.
Ja, schade. Eine richtige DOS-Maschine wär einfach besser. Hier gibt's doch sehr viele Hardwarebastler und "-Dealer". Könnte man da nicht etwas abgreifen?
zatzen hat geschrieben: Spiel auf Sound auslegen:
Ich hatte sogar schonmal die Idee ein Text-Adventure zu machen mit Ton...
Tja - wieso nicht?
zatzen hat geschrieben:Du hast mehr geschrieben als ich im Moment verstehen kann.
Aber das Forum hier bewahrt die Einträge und so können sie für die Zukunft viel wert sein. Ich bin mit der gesamten komplexen Materie bis ins Detail längst nicht so vertraut wie Du, und daher werden auf absehbare Zeit auch meine Programme nicht perfekt zugeschnitten auf ein entsprechendes Computersystem sein.
Wie schon erwähnt: Auf PC "perfekt zuschneiden" ist quasi ein Ding der Unmöglichkeit. Man kann nur versuchen, so gängige PC-Konfigurationen ausreichend gut zu unterstützen. "Perfekt zuschneiden" geht bei "monolithischen" Systemen, wie z.B. alten 8-Bit-Rechnern (C64...) oder Spielkonsolen. Da ist es immer das gleiche System - man weiß 100%, was sie können, was sie leisten können usw. und wenn man will, kann man da auf's letzte Bit und den letzten Zyklus ausreizen und es läuft trotzdem überall. - Beim PC ein Ding der Unmöglichkeit...
zatzen hat geschrieben:Es macht mir aber Spaß wenigstens ein bisschen intelligent zu programmieren, indem ich doch ein wenig von der Rechnerarchitektur verstanden
habe und so mit Assembler in Verbindung mit Pascal heute deutlich bessere Ergebnisse erziele also damals mit bloßem QuickBasic.
Naja, es macht schon Freude, wenn man wenigstens etwas Performance schon durch die Wahl der Hochsprache oder durch Einbringen von Assembler erreichen kann. Ständig nur zu denken: Verdammt ist das langsam (weil Interpreter) und keine Möglichkeit zu haben, es zu beschleunigen (weil Interpreter) und auch nichts machen zu können, was der Interpreter nicht anbietet (weil Interpreter) - das mag gehen, wenn man gerade mal ein halbes Jahr programmiert und froh ist, überhaupt "irgendein Ergebnis" zustandezubringen. Aber wenn man sowas 10 Jahre lang macht und trotzdem nur langsame popelige Grütze fabriziert, kann man sich ja irgendwann selbst nicht mehr ernstnehmen...
zatzen hat geschrieben:Wie auch immer, ich bin aufgewachsen mit Nintendo NES, also dem ersten sozusagen, da war die Grafik ja wie man's kennt eher bescheiden, wobei gleichzeitig die Geschwindigkeit der ganzen Sache noch etwas ist, das ich derzeit noch nicht erreichen würde.
Ach, Nintendo macht Riesenspaß. Und SuperNintendo sowieso... Mehr als "SuperNES" mäßige Spiele will ich gar nicht machen. Das ist so quasi mein Ziel.
zatzen hat geschrieben:Schliesslich kam bald aber der PC, das war so um 1989, und da gab es beispielsweise Spiele wie Captain Comic. Ich greife das nur mal heraus weil es im Grunde für ein "Arcade" Spiel sehr unübliche Parameter hat: Framerate von 10 fps, Scrolling in 8 Pixel-Einheiten. Trotzdem war es spielbar.
Ja, "Jill of the Jungle" hatte auch so blockweises "scrolling" und sehr krasse (und laute!) Soundeffekte... aber wieso auch nicht?
Hab hier auch "Thexder II" alias "Firehawk". Schönes Spiel. Ich bin nur leider zu schlecht, komme mit der Steuerung nur so halbwegs klar. Steuerung macht unheimlich viel aus bei einem Spiel. Wenn ein Spiel tolle Grafik und tollen Sound hat, aber die Steuerung unhandlich, kryptisch oder zu komplex - das kann ein ganzes Spiel versauen.
zatzen hat geschrieben:Für ein eigenes Spiel würde ich nicht zu viel Zeugs auffahren wollen, dafür aber auf etwas gehobenerem Level. Scrolling möchte ich nicht - weiches Scrolling entzieht sich wieder meinen Fähigkeiten. Also eher sowas wie ein Level-Platformer wie Donkey Kong, Mario Bros (ohne Super).
Naja, auf PC habe ich (fast) noch nie ECHT "gescrollt" (außer experimentell). Ich zeichne quasi die komplette Szene neu. Und wenn die Szene 1 Pixel verschoben ist, zeichne ich die um 1 verschobene Szene komplett neu. Ich kopiere da nix um.
zatzen hat geschrieben:Aber mit 256 Farben Grafik, transparenten Sprites, schönen Hintergründen und schöner Musik. Wäre eine Idee. Oder, vielleicht letztlich doch faszinierender, ein Dungeon-ähnliches Spiel, wo man überall hin laufen kan, und es wird von Screen zu Screen "geblättert", ähnlich wie bei Kotzman II.
Ja, da gabs früher einige so Spiele (Dangerous Dave und so). Hat auch Spaß gemacht. Wie bereits erwähnt: Scrolling ist keine Voraussetzung für Spielspaß. (Genauso wie 3D keine Voraussetzung ist.)
zatzen hat geschrieben:Du merkst vielleicht schon, dass ich bei der Grafik schon direkt schon eine Hemmnis habe, dass diese nicht zu viel Rechenzeit in Anspruch nimmt.
Naja, Du siehst das Ganze aus der Sound-Sicht, hab ich den Eindruck.

Ich versuche immer, alle Aspekte mit einzubeziehen. Für mich soll ein Spiel nicht "eine Soundengine mit ein bißchen Spiel drumherum" sein. Ich mache ja auch Abstriche bei der Grafik (z.B. Patterns/Sprites als 4bit, also nur 16 aus 256 Farben gleichzeitig usw). Und auch bei der Steuerung. Jeder Bereich ist wichtig. Aber kein Bereich ist SO wichtig, daß er quasi alle anderen Bereiche "ausmastern" darf. Das ist meine Art, an Spieleprogrammierung heranzugehen. Kann jeder anders machen.
zatzen hat geschrieben:Vom "schnell zum fertigen Produkt, Hauptsache schnell und es sieht gut aus" bin ich aber auch weit entfernt. Für mich zählt der Weg dorthin, dass ich weiss was hinter den Kulissen passiert.
Das ist sowieso mein Ansporn beim Programmieren. Ich kann es inzwischen auch nicht mehr so leiden, so "irgendwie zusammengeschusterte" Dinge zu etwas größerem zusammenzuschustern und dabei dann 50% des Programms aufzuwenden, den ganzen Unsinn, den die Einzelteile machen, zu "workarounden". Heute bin ich eher der Ansicht: Die Einzelteile müssen funktionieren - und erst dann werden sie woanders eingebaut.

Das klingt ja auch edel und so - leider braucht so ein Ansatz eben auch viel Entwicklungszeit. Und wenn man dabei quasi komplett auf sich allein gestellt ist, kann man nicht - wie es bei vielen, sogar damaligen (vor 30 Jahren) Spielen war - "parallel" entwickeln: Also der eine programmiert, der andere baut schon Levels und Sprites oder bastelt sich dafür vielleicht schon einen Editor. Einer komponiert währenddessen schon unabhängig davon Musik oder erstellt Effekte - diese werden dann passend zu den Levels benutzt... Aber man kann sich eben nicht vierteilen und so muß dann als Einzelner alles nacheinander erfolgen. Ich habe ja quasi "fast" alles zusammen - mit dem letzten Teil tue ich mich noch etwas schwer momentan - was aber eher an der derzeitigen Klimakatastrophe hier liegt...

Naja, soviel erstmal von mir.

Bis bald.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Di 7. Aug 2018, 20:27
von zatzen
Ja, ich baue Lautsprecher, d.h. Gehäuse in die ich dann entsprechend passende Chassis/Treiber
(also die Dinger mit der Membran) einbaue.
Dazu kommt noch das Abstimmen per Frequenzweiche, also etwas "gröbere" Elektronik, Filterschaltungen.
Wenn es nur geht mache ich irgendwas nach dem Hornprinzip, das klingt für meine Ohren direkter, dynamischer
und transparenter. Wenn ich das nächste Projekt abgeschlossen habe mache ich auf meiner Homepage eine neue
Rubrik auf, in der ich die Lautsprecher vorstelle.

Vorschläge für die Tracker GUI:
Wenn Du mir einen gefallen tun willst, mach eine Borland Oberfläche oder direkt alles ähnlich wie X-Tracker.
Der dürfte mittlerweile legal kopierbar sein, also könntest Du ihn Dir in Ruhe ansehen.

Samples mit Melodien: Ich gehe damit ja noch kreativ um und mache etwas anderes draus als es ursprüglich war.
Aber MODs die nur aus isolierten Klangsamples bestehen sind natürlich auch sehr schön.

Bei meinen derzeitigen Programmen die Ton nutzen ist zeitlich alles gerastert in Pufferlängen, alle Berechnungen
und auch Tastaturabfragen werden erledigt während der letzte Puffer spielt, und wenn nun ein Ereignis stattfindet
wird der entsprechende Sound ganz ab dem Anfang des nächsten Puffers eingerechnet.
Als Ergebnis sind Bild und Ton absolut synchron wenn auf den neuen Puffer umgeschaltet und die neuen Bilddaten
angezeigt werden.
Natürlich schränkt dieses Verfahren die Auflösung der Steuerung auf die Framerate ein, die wiederum durch die Länge
des Soundpuffers festgelegt ist. Da ist man dann nicht so flexibel, aber für meinen Bedarf reichen Framerates zwischen
20 und 30 fps aus.
Kollisionsabfragen etc. müsste man aber wohl intern mit einer höheren Auflösung erledigen, hier würde ich dazu
übergehen das ganze vielleicht 10 mal so fein zu machen und einfach 10 Durchläufe pro Frame zu machen.

Nebenbei: So wie ich es mache hinkt nicht der Ton dem Bild hinterher, sondern alles insgesamt hinkt
gewissermaßen sich selbst um eine Framedauer hinterher. Oder anders formuliert:
- Ton und Bild sind synchron
- Aber es gilt die Regel: Ich sehe die Situation und meine Entscheidungen zeigen sich erst im nächsten Frame.
Hmm, aber ist das nicht so oder so der Fall?
Hinkt dann überhaupt noch wirklich etwas bei meiner Herangehensweise?


Okay, ich denke ich habe Dein Prinzip mit der Grafik als "Momentaufnahme" verstanden. Ist auch logisch und
gewissermaßen "verlockend" das so zu machen, dann würde ich dazu tendieren zu denken ich kann ruhig ordentlich
Grafik im Spiel auffahren, notfalls geht's eben zwischendrin auf ne nur ne handvoll Frames runter.
Und dann verstehe ich auch das mit dem Soundpuffer besser, er macht dann wohl auch immer "Momentaufnahmen",
nur dass es hier nicht ruckeln darf und dass es je nach Puffergröße immer eine gewisse Verzögerung und somit
Asynchronität gibt.

Vernünftiger und Ressourcen besser ausnutzend ist die von Dir erklärte Methode, aber wenn ich nunmal ein Spiel
auf eine feste eher niedrige Framerate festlege und etwas Rechenkapazität verschwende bzw. der Rechner eine
Mindestleistung haben muss damit nicht der Super GAU namens Soundpuffer-Ruckeln eintritt, dann erreiche ich für
meine Begriffe wegen der perfekten Bild+Ton Synchronität eigentlich eine bessere Qualität für meine Ansprüche.
Jedenfalls würde ich das so erstmal machen wollen, später dann "richtig" - sollte ich mich mit Zeitversatz von Bild
und Ton anfreuden können.


Ich habe noch einen DOS-Rechner im Keller.
Ich programmiere zur Zeit aber lieber in Dosbox.
Das hat zum einen den Vorteil dass ich nicht extra noch einen Computer hier laufen haben muss.
Zum anderen hat es mir in letzter Zeit erst meine Fortschritte in Assembler und anderweitiger hardwarenaher
Programmierung ermöglicht, weil ein Absturz nur bedeutet "klick klick" und schon geht's weiter.
Nimmt ein bisschen Adrenalin aus der Sache was mir ganz gut tut.
Je nach Datenmaterial kann es auch sehr praktisch sein dieses mit Windows-Tools zu sichten
oder zu bearbeiten, ohne dafür einen Transfer von Rechner zu Rechner veranstalten zu müssen.
Ein größeres Projekt würde ich dann aber zumindest mal auf einem echten Rechner testen.


Spiele: Ja so Super Nintendo oder Amiga - das ist auch meine Ebene.
NES-Stil wäre in Verbindung mit ZVID interesannt, weil dann die Grafikkompression sehr gut
greifen würde (nur 1 Bit bis maximal 2 Bit).

Sound-Sicht:
Gewissermaßen bin ich schon ausgehungert nach anspruchsvollem Sound in Spielen, zumal ich aufgewachsen bin
mit NES (1987) und PC (1989).
NES hatte zwar seinen netten Synthesizer für Musik, aber es hat mir an realistischen Sounds gefehlt.
Am PC hatte ich die ersten vier Jahre nur den Piepser, dann 1993 eine Soundblaster Pro. Auch wenn
die Digisound konnte, boten die meisten Spiele zu der Zeit nur Adlib.
Bald hatte ich einen 486 und machte Bekanntschaft mit MODs. Das war eine ganz neue Welt und ich
wollte auch unbedingt in diesem Format Musik machen können, war erst schwierig Software zu finden,
so ganz ohne Internet, aber bald hat's dann doch geklappt.
Naja und dann war das ein ganz großes Hobby von mir das bis heute nicht versiegt ist.
Wenn man es so betrachtet sollte es verständlich sein dass ich auch meine eigenen Spiele mit realistisch
klingendem Ton ausstatten möchte und dafür vielleicht auch 200 KB anlegen würde (Musik + SFX).
Dann bleiben für die Grafik vielleicht noch 256, und mit ZVID könnte da einiges reinpassen.
Ich hatte nur bisher nicht die Geduld, ZVID auf Sprite-Clipping zu erweitern, d.h. ich stehe damit immer noch
vor demselben Problem wie beim QuickBasic PUT, dass es nicht über die Bildschirmgrenzen hinausgehen darf,
allerdings sind jetzt wenigstens schonmal transparente Sprites möglich.


Um ein Spiel zu machen würde es bei mir zuerst an der Grafik scheitern. Ich bin einfach nicht (mehr) so
begeisterungsfähig, Grafik zu machen. Auch deshalb würde ich bei einem Spiel nicht so viel Grafik
auffahren, wäre aber in der Lage soundmäßig etwas mehr zu liefern. Allerdings, je kleiner die Sprites
werden, desto einfacher wird es zumindest für mich, etwas zu pixeln. Deshalb strebe ich vielleicht
vorerst soetwas an wie ein NES Spiel, nur in 256 Farben.

Ich bin mal gespannt auf Dein neues Projekt!

Bis dann

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 11. Aug 2018, 10:10
von DOSferatu
zatzen hat geschrieben:Ja, ich baue Lautsprecher, d.h. Gehäuse in die ich dann entsprechend passende Chassis/Treiber (also die Dinger mit der Membran) einbaue.
Dazu kommt noch das Abstimmen per Frequenzweiche, also etwas "gröbere" Elektronik, Filterschaltungen. Wenn es nur geht mache ich irgendwas nach dem Hornprinzip, das klingt für meine Ohren direkter, dynamischer und transparenter.
Ich habe überhaupt keine Ahnung davon. Ich weiß nur, daß ein Lautsprecher prinzipiell eine schwingende Membran ist. Und daß manchmal Filter vorgeschaltet werden, um niedrige Frequenzanteile zu den großen Lautsprechern, die hohen zu den kleinen Lautsprechern zu leiten.
Vom Hornprinzip habe ich noch nie gehört/gelesen.
zatzen hat geschrieben:Vorschläge für die Tracker GUI:
Wenn Du mir einen gefallen tun willst, mach eine Borland Oberfläche oder direkt alles ähnlich wie X-Tracker. Der dürfte mittlerweile legal kopierbar sein, also könntest Du ihn Dir in Ruhe ansehen.
Das ist ja kein Vorschlag, um meinen Tracker zu verbessern oder wasauchimmer, sondern lediglich, um einen anderen Tracker 1:1 nachzubauen. (Es ging also wahrscheinlich nie wirklich nur um die "stimmensynchrone Trackeransicht", die bei prISM fehlt, um damit arbeiten zu können - sondern eher darum, daß alles, was nicht X-Tracker ist, sowieso nicht benutzbar ist.)

Eine Erklärung zu AtavISM: Der AtavISM-Tracker baut auf der gleichen Codebasis auf wie prISM, es ist quasi das gleiche Programm - bei dem mit den Mitteln, die die bereits in prISM vorhandene Minimal-GUI hergibt, die weitere Ansicht/Bedienung eingebaut wurde - alles auch unter anderem mit dem Ziel, Speicher zu sparen (also möglichst viel Speicher für Samples freizulassen. Mit Vorschlägen meinte ich eher eine Modifikation der Bedienung, andere Tasten, andere Anordnung und nicht "kompletter Umbau/Neubau des ganzen Systems, damit es genau wie ein bereits vorhandenes aussieht/funktioniert". prISM/AtavISM müssen ja mit den Dingen arbeiten/auskommen, die ISM kann. Die andere Ansicht, bzw. der "ISM-Code-Container" von AtavISM-Files ändert nichts daran, daß man damit generell immer noch nur ISM-artige Musik erzeugen kan.
zatzen hat geschrieben:Samples mit Melodien: Ich gehe damit ja noch kreativ um und mache etwas anderes draus als es ursprüglich war.
Ja, schon. Aber Samples mit Melodien sind groß. Und die entsprechen auch nicht der eigentlich Idee hinter Module-Tracking.
zatzen hat geschrieben:Aber MODs die nur aus isolierten Klangsamples bestehen sind natürlich auch sehr schön.
Ja, so ist es ja auch eigentlich gedacht. Die Samples ersetzen quasi die Instrumente. Das ist das gleiche Prinzip wie bei MIDI. (Ich weiß gerade nicht, ob MIDI die Idee von MOD übernommen hat oder MOD von MIDI.)
zatzen hat geschrieben:Bei meinen derzeitigen Programmen die Ton nutzen ist zeitlich alles gerastert in Pufferlängen, alle Berechnungen und auch Tastaturabfragen werden erledigt während der letzte Puffer spielt, und wenn nun ein Ereignis stattfindet wird der entsprechende Sound ganz ab dem Anfang des nächsten Puffers eingerechnet.
Naja, "quasi-gerastert" sind meine Spiele ja auch. Ich versuche das mal zu erklären: Bei mir ist es so, daß z.B. 50 "Schritte" pro Sekunde für jede Figur gemacht werden und erst alle Figuren ihren Schritt gemacht haben müssen, bevor die ersten ihren nächsten Schritt tun. Wieso ich das so explizit erwähne ist, weil es nur "durchschnittlich 50 Schritte pro Sekunde" sind - damit das Spiel überall mit der gleichen Geschwindigkeit läuft. (Man will ja nicht den "Wing Commander Effekt" haben.) Anm.: Die 50 Steps/Second sind nur ein Beispiel. Man kann auch jede andere Rate wählen.

Dazu läuft ein 50 Hz-Ticker "nebenher" mit, der quasi (fast) nichts weiter macht [1], außer alle 1/50 Sekunden einen Zähler hochzuzählen. Wenn die Hauptschleife mal wieder bei der "Steuer-Subroutine" angekommen ist, kopiert diese sich den Zähler, setzt den Zähler dann auf 0. Der kopierte Zähler ist nun die Anzahl Durchläufe, die die Steuer-Subroutine zu machen hat - im Idealfall ist das natürlich 0 oder 1. (Bei 0 ist das System so schnell, daß Grafikberechnung/-ausgabe und Soundberechnung/-ausgabe so schnell sind, daß sie in wesentlich weniger als dieser 1/50 Sekunde erledigt sind.) D.h. bei einem ausreichend schnellen System ist der kopierte Zähler immer nur 0 oder 1. Wenn er 1 ist, muß die Steuer-Subroutine für alle Figuren genau einen Schritt machen, d.h. einen Durchlauf.

Natürlich haben wir hier noch ein Problem: Fast alle Figuren "wissen" zwar, was zu tun ist, weil sie ja entsprechend programmiert wurden. Also auch bei mehreren Schritten verhalten sie sich zueinander völlig korrekt. (Wobei "korrektes Verhalten" hier auch sein kann, sich gegenseitig umzunieten... - Programmtechnisch korrektes Verhalten hat nichts mit Höflichkeit zu tun...)

Es gibt nur eine einzige Art von Figuren, die das nicht können, weil ihr "Verhalten" nicht programmiert ist - welche? Klar, die Spielerfigur(en)! Diese müssen ihre Steuerdaten natürlich irgendwo anders herbekommen. Die einfache, aber leider nicht "synchrone" Methode wäre, aktuell die Tasten abzufragen und dann die Figur zu bewegen. Allerdings würde auf langsamen Rechnern - z.B. einem der nur die halbe Framerate schafft (in Beispielfall 25 FPS) dann der Effekt eintreten, daß die Steuerung der Figur nur noch "halb so genau" ist - sie würde meist 2 komplett identische Schritte/Steuerbefehle etc. nacheinander ausführen, also Schritte in eine Richtung, Drehen um einen Winkel... usw.

Und - eigentlich gibt es bei einem zu langsamen Rechner keine richtig "synchrone" Methode, um dieses Problem zu lösen: Denn wenn der Spieler nur jedes 2. "Bild" sieht, kann er ja auch nur darauf reagieren... - nun ist es aber erstens so, daß Dinge in Spielen nicht so geschehen, daß etwas in 1/50 Sekunde zu sehen wäre und im nächsten Frame schon wieder weg wäre und wenn man das Frame verpaßt, würde man es nicht sehen... Das wäre ein wahnsinnig schweres Spiel - da könnte sich man auch bei Gewitter mit einer Kamera irgendwo hinstellen und immer exakt wenn es blitzt, den Auslöser drücken, um ein Foto zu machen...

Unser Gehirn ist nun aber so konstruiert, daß es die fehlenden Zwischenframes bis zu einer bestimmten Framerate interpolieren kann, d.h. daß fortlaufende Einzelbilder trotzdem als Bewegung wahrgenommen werden. Anders wären Dinge wie Fernsehen, Computermonitore und auch jede Art von digitalem Spiel nicht möglich.

Und jetzt komme ich zum oben geschriebenen [1]: Der Ticker macht nur fast nichts anderes als den Zähler hochzuzählen. Außerdem holt er exakt in jeder 1/50 Sekunde (oder welche Rate man gewählt hat) den Zustand der Steuerhardware (gedrückte Tastatur-Tasten, Maus-Tasten, Maus-Bewegung, Joystick-Auslenkung/-Tasten)... Natürlich nur die für den Spieler festgelegten Tasten/Buttons ezc. - und baut daraus ein Bitmuster, das er als Wert in einen Ringpuffer ablegt. Natürlich würde so ein Ringpuffer auch mal irgendwann "überlaufen" (oder anhalten - also keine neuen Werte annehmen - je nachdem wie er programmiert ist), aber wenn man ihn 50 Werte groß macht, kann man sogar den unwahrscheinlichen Fall abdecken, daß das Spiel - aufgrund langsamer Maschine - mit nur 1 FPS läuft... (So würde sowieso niemand spielen wollen.)

Dieser Ringpuffer ist es, aus dem eine Spielerfigur bei jedem Schritt ihre Steuerdaten holt. Da sind dann z.B. 4 Bits für hoch/runter/links/rechts. In Kombination bedeuten sie auch schräge Bewegung oder gleichzeitig vorwärts/drehen... je nachdem, wie das Spiel aufgebaut ist. Dann gibt es einzelne Bits für die "Aktionstasten", die z.B. einen Sprung auslösen oder das Abfeuern eines Projektils oder ähnliches. Diese Bits sind für das gleichen Spiel immer an der gleichen Stelle. Die Figur steuert sich quasi genau wie alle anderen Figuren, nur daß ihre Bewegungen nicht aus einem Steuerprogramm stammen, sondern aus der Auswertung der Steuerbits. Meine Steuer-Subroutine (GameSys2, falls Du Dich erinnerst) hat einen Befehl, um für Spieler X die nächste Steuerbefehlsbitmaske zu holen.

Das Ganze hat 3 Vorteile:
1.) Ob mit oder ohne Ringpuffer - das Umsetzen gedrückter Tastatur-/Maus-/Joystick-Tasten/-Bewegungen in Bitmuster erlaubt es, außerhalb des Spiels die Tasten und das Steuergerät frei wählen zu können. Das Spiel muß nur z.B. wissen: Gerade wurde "nach oben"/"vorwärts" gedrückt oder "soeben wurde Feuerbefehl gegeben" - es muß nicht wissen, mit welcher Taste/Joystickbutton oder was auch immer das passiert ist. (Und ja: So Folgen von Steuerbefehlen kann man auch in ein File schreiben. Wenn man es später ausliest, kann man damit ein laufendes Spiel simulieren. So funktonieren die "Spiel-Demos", die bei Xpyderz am Anfang im Hintergrund laufen.)

2.) Die Steuer-Eingabe und die Spielsteuerung können komplett unabhängig voneinander gehalten werden.

3.) Der Spieler kann trotzdem in seiner gewohnten Geschwindigkeit steuern - egal was seine Maschine für eine Framerate hergibt - alles was er eingibt, wird auch erfaßt. D.h. auch bei niedriger Framerate geht kein Tastendruck des Spielers verloren (außer er drückt so kurz daß es zwischen zwei 1/50 Sekunden Abfragen passiert - aber in dem Fall würde es auch ohne Ringpuffer nicht erfaßt werden - oder nur mal zufällig).

Für die Puristen will ich aber nicht den Nachteil verschweigen:
Es ist dadurch natürlich bei geringer Framerate leicht unsynchron - aber auch nicht unsynchroner als mit "direkter" Abfrage (sondern eher synchroner). Wenn mir jemand einen Spieler zeigt, der auf ein komplexes im Bild dargestelltes Spielgeschehen in weniger als 1/50 Sekunde reagieren und die entsprechenden Tasten in der nächsten 1/50 Sekunde drücken kann, dann will ich mal nichts gesagt haben - andererseits wird so jemand wahrscheinlich sowieso den schnellsten Computer der Welt brauchen (und damit nie das Problem einbrechender FPS kennen).

Und ja - mit zu niedriger Framerate zu spielen ist immer Mist - da beißt die Maus keinen Faden ab. Wenn man mit 3 FPS spielt, kann man natürlich nicht mehr zeitnah auf das Spiel reagieren - aber da kann dann die Steuerung auch nichts dafür, dann ist der Computer zu langsam oder das Spiel zu schlecht programmiert (meist eher letzteres).

Dinge wie diese Ringpuffer oder Ticker und alles was ich beschrieben habe, sollen ja auch nicht wirklich dazu dienen, dauerhaft ein Spiel mit 5 FPS spielen zu müssen, sondern eher, um kurzzeitige Performanceeinbrüche geschickt aufzufangen. Beispiel: Man spielt ein Spiel auf einem Rechner, der prinzipiell dafür ausreicht, aber quasi hart an der Grenze ist. Nun explodiert ein größerer Gegner, und erzeugt eine noch größere Explosion aus einem oder mehreren großen Sprites, was für einen kurzen Moment die Grafikroutine "überlastet", bzw., wodurch für einen kurzen Moment die Grafikroutine mal etwas mehr Zeit braucht, weil mehr (und größere) Sprites als sonst dargestellt werden müssen. Muß deswegen gleich der Sound aussetzen? Muß deswegen gleich die Spielersteuerung blockiert sein? Muß deswegen gleich das Spiel abstürzen? Ich meine nein.

Und solche kurzen Einbrüche der Frameraten, wenn irgend ein Teil des Spiels mal kurz etwas länger braucht, kann man durch so Pufferung und Ticker abfangen. Die Soundroutine kann z.B. auch mal länger brauchen: Gerade muß vielleicht ein Soundeffekt, der sonst nie gebraucht wird und deshalb nicht dauerhaft im Speicher liegt, nachgeladen werden - zack! Framerate runter! Aber da muß doch nicht gleich der restliche Sound stottern oder die Steuerung versagen! Und das muß es ja auch nicht, wenn Soundpuffer und Steuerpuffer groß genug (aber nicht zu groß) gewählt werden, um solche Dinge abzufangen/zu überbrücken.

Das alles ist nur meine persönliche Ansicht dazu. Wie schonmal erwähnt: Spiele - ob auf PC oder Konsole - sind NIE "synchron"! Die Grafik kann nur angezeigt werden und der Sound nur abgespielt werden, NACHDEM klar ist, was der Spieler eingegeben hat. Selbst auf der schnellsten Kiste der Welt "hinkt" alles immer um 1 Frame hinterher. (Die Ursache kommt immer vor der Wirkung. Nie umgekehrt. OK - Quantenphysiker werden mich jetzt vielleicht schlagen wollen...)

Und ja - diese Pufferungen führen natürlich zum Hinterherhinken von Grafik und Sound. Aber eine Soundpufferhälfte (bei Double Buffering) von mind. 1/10 Sekunde sollte man dem Rechner schon gönnen. Eine Zehntelsekunde Zeitversatz vom Sound finde ich verschmerzbar. (Ich persönlich sogar eine Viertelsekunde.) Und ja - das ist nicht ganz wie auf einer Spielkonsole. Dabei muß man aber bedenken, daß bei Spielkonsolen der Sound kurz getriggert wurde und dann wurde er abgespielt ohne daß die CPU noch etwas dafür tun mußte. (Sounds hatten oft eigene CPUs.) Auf dem PC muß man ja auch "aufpassen", damit der Sound nicht abläuft und man muß ihn selbst generieren bevor er abgespielt wird.
zatzen hat geschrieben:Als Ergebnis sind Bild und Ton absolut synchron wenn auf den neuen Puffer umgeschaltet und die neuen Bilddaten angezeigt werden.
Wie schon erwähnt - nichts auf einem PC oder Konsole ist synchron. Das wirkt nur so, weil die menschlichen Sinne zu träge sind. Man kann natürlich auch Spiele machen wollen, die von totalen Übermenschen gespielt werden...

Ich sags mal so: Zu WAS GENAU ist der Sound synchron? Zur Grafik kann der Sound ja nicht synchron sein, wenn man meint: "Sound darf nie 'hinterherhinken', da mach ich lieber Grafik mit nur 10 FPS." - dann mal bitte kurz diese Überlegung anstellen:
Wenn Grafik 10 FPS hat, dann wäre Sound mit einem Puffer von einer Zehntel Sekunde immer noch synchron zur Grafik. Denn wenn sich das Bild nur jede Zehntelsekunde ändert, "paßt" das Bild solange immer noch zum Sound. Und selbst mit einem Puffer einer Fünftel Sekunde Länge (also 0,2 Sekunden) wäre der Sound zur Grafik nur maximal 1 Frame unsynchron.
Wenn man das mal weiterspinnt: Wenn man ein Spiel mit 1 FPS machen würde, würde nur jede Sekunde ein anderes Bild da sein - da wäre der Sound ja quasi "dauersynchron", selbst mit fast 40 kByte Puffer...

Das ist es, was ich damit sagen will: Man kann natürlich das restliche Spiel runterdrehen bis zum Abwinken, niedrige Auflösung, niedrige Framerate, nur 5 Steuerabfragen pro Sekunde, usw. - aber je langsamer das restliche Spiel ist, umso weniger Soundsynchronität wäre nötig, weil es nichts gäbe, zu dem der Sound synchron sein muß.
zatzen hat geschrieben:Natürlich schränkt dieses Verfahren die Auflösung der Steuerung auf die Framerate ein, die wiederum durch die Länge des Soundpuffers festgelegt ist. Da ist man dann nicht so flexibel, aber für meinen Bedarf reichen Framerates zwischen 20 und 30 fps aus.
Mehr als 20 bis 30 FPS schaffe ich auf 386er oder langsamen 486ern auch nicht - kommt drauf an, wie komplex ich mit der Grafik hantiere. Bei 30 FPS wäre also bei 22050 Hz, 8Bit Mono eine Soundpufferhälfte 735 Bytes groß - dann wäre es "quasi-synchron", bei 20 FPS müßte der Halbpuffer 1103 Bytes groß sein. Ja, man kann natürlich mit festen Frameraten arbeiten - dann muß man es eben wirklich schaffen, daß auch alles in einem Frame abgearbeitet ist. Also: Schnellen 486er, schnelle Grafikkarte, schnellen Bus, schnellen Speicher voraussetzen.
zatzen hat geschrieben:Kollisionsabfragen etc. müsste man aber wohl intern mit einer höheren Auflösung erledigen, hier würde ich dazu übergehen das ganze vielleicht 10 mal so fein zu machen und einfach 10 Durchläufe pro Frame zu machen.
Man braucht nur so oft Kollisionsabfragen machen, wie sich im Spiel etwas "bewegt". Wenn jede Figur 20 Schritte pro Sekunde macht, passiert zwischen den Schritten ja nichts. D.h. das Verhältnis der Figuren zueinander ändert sich ja nur wenn sie sich bewegen und nur dann ist der "Kollisionszustand" wieder anders.
zatzen hat geschrieben:Nebenbei: So wie ich es mache hinkt nicht der Ton dem Bild hinterher, sondern alles insgesamt hinkt gewissermaßen sich selbst um eine Framedauer hinterher. Oder anders formuliert:
- Ton und Bild sind synchron
- Aber es gilt die Regel: Ich sehe die Situation und meine Entscheidungen zeigen sich erst im nächsten Frame.
Hmm, aber ist das nicht so oder so der Fall?
Hinkt dann überhaupt noch wirklich etwas bei meiner Herangehensweise?
Wie gesagt: Es hinkt immer. Bild und Ton können zwar zueinander "quasi-synchron" sein - aber nicht zur Steuerung. Wirkung kommt nach Ursache. Wenn der Spieler irgend etwas macht, was irgendwann später eine Explosion auslöst, muß erst die Steuerung erkennen, daß da eine Explosion kommen muß, und dann kann an Grafik und Sound weitergegeben werden, daß eine Explosion angezeigt und abgespielt werden muß.
zatzen hat geschrieben:Okay, ich denke ich habe Dein Prinzip mit der Grafik als "Momentaufnahme" verstanden. Ist auch logisch und gewissermaßen "verlockend" das so zu machen, dann würde ich dazu tendieren zu denken ich kann ruhig ordentlich Grafik im Spiel auffahren, notfalls geht's eben zwischendrin auf ne nur ne handvoll Frames runter.
Und dann verstehe ich auch das mit dem Soundpuffer besser, er macht dann wohl auch immer "Momentaufnahmen", nur dass es hier nicht ruckeln darf und dass es je nach Puffergröße immer eine gewisse Verzögerung und somit Asynchronität gibt.
Ja. Es gäbe zwar prinzipiell noch die Möglichkeit des "Dazumischens zum gerade gespielten Puffer", d.h. die Hintergrundmusik spielt so vor sich hin (die muß ja kaum 100% synchron sein zum Spielgeschehen, weil sie unabhängig davon ist) und die Soundeffekte werden proaktiv zum Soundpuffer dazugemischt in dem Moment wo sie passieren...

ABER! - Erstens bin ich mir nicht ganz sicher, ob man überhaupt in dem Speicher was zu suchen hat, wo der DMA grade rummacht (also, ob das nicht irgendwelche unschönen Nebeneffekte ergibt) und zweitens ist so Dazumischen auch nicht "mal eben so" gemacht, da muß ja wieder Clipping berücksichtigt werden und man bräuchte quasi 2 Soundgenerator-Unterprogramme: Eins für die Musik und eins für die Geräuscheffekte (kann auch dasselbe sein, 2 mal gestartet, wenn man nur lokale Werte benutzt und sie sichert)...

Ja - dann wäre man "aber mal so RICHTIG synchron" - quasi fast bytegenau! Und würde eine Menge Performance und Speicher verschenken und viele Dinge in Spielen nicht einbauen können, weil Rechenpower nicht reicht - könnte aber stolz drauf sein, fast bitsynchrone Effekte zu haben, was wahrscheinlich keinem anderen Spieler (außer dem Programmierer selbst) überhaupt auffallen würde, so daß niemand diese Mühe anerkennen würde. Den Spielern fiele wahrscheinlich eher die niedrige Framerate auf...

Will da auch nicht gegenreden - ich schildere nur meine persönlichen Gedanken dazu.
zatzen hat geschrieben:Vernünftiger und Ressourcen besser ausnutzend ist die von Dir erklärte Methode, aber wenn ich nunmal ein Spiel auf eine feste eher niedrige Framerate festlege und etwas Rechenkapazität verschwende bzw. der Rechner eine Mindestleistung haben muss damit nicht der Super GAU namens Soundpuffer-Ruckeln eintritt, dann erreiche ich für meine Begriffe wegen der perfekten Bild+Ton Synchronität eigentlich eine bessere Qualität für meine Ansprüche.
Wie in meinem obigen Gedankenexperiment erwähnt: Je weniger Bilder pro Sekunde, umso unwichtiger ist Synchronität. Oder um es ins Extreme zu steigern, damit man versteht, wie ich das meine: Wenn man einen Film hat, in dem sich nur jede Minute das Bild ändert und irgendwann ist ein Bild von einem Vogel zu sehen - dann hat der Sound 'ne ganze Minute Zeit, um irgendwann in dieser Minute ein Vogelzwitschern zu spielen und es wäre immer noch "synchron zum Bild".
Hmm... Wie erklär ich das nur noch besser:
Nehmen wir an, wir hätten 4 Prozesse. Einer (A) ist auf hundertstel Sekunden genau und die anderen 3 Prozesse (B,C,D) jeweils auf Zehntelsekunden. (A wäre der Sound, B wäre Grafik, C wäre Spielablauf, D wäre Spielersteuerung.) Zu was kann supergenauer Prozeß A hundertstelsekundengenau sein, wenn es nichts anderes gibt, was ebenfalls hundertstelsekundengenau ist?
zatzen hat geschrieben:Jedenfalls würde ich das so erstmal machen wollen, später dann "richtig" - sollte ich mich mit Zeitversatz von Bild und Ton anfreuden können.
Wenn Bildrefresh viel langsamer als Tonrefresh ist, ist der Zeitversatz ja schon alleine dadurch gegeben.
zatzen hat geschrieben:Ich habe noch einen DOS-Rechner im Keller.
Ich programmiere zur Zeit aber lieber in Dosbox.
Das hat zum einen den Vorteil dass ich nicht extra noch einen Computer hier laufen haben muss.
Zum anderen hat es mir in letzter Zeit erst meine Fortschritte in Assembler und anderweitiger hardwarenaher Programmierung ermöglicht, weil ein Absturz nur bedeutet "klick klick" und schon geht's weiter. Nimmt ein bisschen Adrenalin aus der Sache was mir ganz gut tut.
Naja, bei mir ist es umgekehrt. Wenn ich gleich nach'm Absturz weitermache, ist das Adrenalin noch da - wenn ich neu boote, hab ich 20 Sekunden Zeit, um das Adrenalin abzubauen und über den möglichen Fehler nachzudenken, bevor ich weitermache. (Ja, mein DOS-Rechner ist ja nicht wie Windows, wo Booten einige Minuten dauert.)
zatzen hat geschrieben:Je nach Datenmaterial kann es auch sehr praktisch sein dieses mit Windows-Tools zu sichten oder zu bearbeiten, ohne dafür einen Transfer von Rechner zu Rechner veranstalten zu müssen.
Ja, macht natürlich Sinn. Mich stört aber schon, daß DOSbox eben nicht 100% kompatibel ist (obwohl es schon sehr kompatibel ist) oder daß es Textmode scheinbar nicht mit 9. Zeichenspalte kann (oder ich habe eine Einstellung übersehen).
zatzen hat geschrieben:Ein größeres Projekt würde ich dann aber zumindest mal auf einem echten Rechner testen.
Das wäre ja auch das Mindeste. Ein (angebliches) DOS-Spiel, was nur auf einem Emulator, aber nicht unter dem echten System läuft - da hätte ich keine Worte dafür, um auszudrücken, wie lame ich das finden würde.
zatzen hat geschrieben:Spiele: Ja so Super Nintendo oder Amiga - das ist auch meine Ebene.
NES-Stil wäre in Verbindung mit ZVID interesannt, weil dann die Grafikkompression sehr gut
greifen würde (nur 1 Bit bis maximal 2 Bit).
Naja, ich verwende ja keine so komplexe Grafikkompression - das erkaufe ich mir mit mehr Möglichkeiten für meine Sprites. Sie sind eben dreh-/spiegel-/skalierbar. Und eine leichte "Kompression" habe ich ja auch drin: Die 16-farbigen Sprites (16 beliebige Farben aus der 256er Palette) sind ja ein Beispiel dafür. Ich könnte zwar auch noch andere Bitbreiten (1,2,3,5...) bedienen, aber das speichert/verarbeitet sich viel schlechter, wenn man quasi "wahlfreien" Pixelzugriff braucht (für drehen/skalieren).
zatzen hat geschrieben: Sound-Sicht:
Gewissermaßen bin ich schon ausgehungert nach anspruchsvollem Sound in Spielen, zumal ich aufgewachsen bin mit NES (1987) und PC (1989).
NES hatte zwar seinen netten Synthesizer für Musik, aber es hat mir an realistischen Sounds gefehlt.
Um realistischen Sound ging es mir nie. Mir ging es ja auch nie um fotorealistische Grafik.
zatzen hat geschrieben:Am PC hatte ich die ersten vier Jahre nur den Piepser, dann 1993 eine Soundblaster Pro. Auch wenn die Digisound konnte, boten die meisten Spiele zu der Zeit nur Adlib.
Ich liebe heute noch den Piepser - und benutze ihn auch, sowohl "digital" als auch "analog". Ich mag halt so "Computerzeug". Für mich muß nicht alles zwangsläufig wie das echte Leben sein, damit es mir Spaß macht (eher im Gegenteil: Was ist schon langweiliger als das "Real Life"?)
zatzen hat geschrieben:Bald hatte ich einen 486 und machte Bekanntschaft mit MODs. Das war eine ganz neue Welt und ich wollte auch unbedingt in diesem Format Musik machen können, war erst schwierig Software zu finden, so ganz ohne Internet, aber bald hat's dann doch geklappt.
Naja und dann war das ein ganz großes Hobby von mir das bis heute nicht versiegt ist.
Tha - ich dagegen habe so Konsolenspiele mit ihrem brachialen Computersynthiesound und ihrer Blocklevel/Sprite/Pixelgrafik gesehen und gedacht: "Super! Will ich auch machen."
Bei so fotorealistischen 3D-Spielen mit lebensechtem Sound (und ja, sowas habe ich auch hier) denke ich das nie. Macht zwar auch Spaß und so, aber ich hatte dabei noch nie den Gedanken: "Will/muß ich selber machen".
zatzen hat geschrieben: Wenn man es so betrachtet sollte es verständlich sein dass ich auch meine eigenen Spiele mit realistisch klingendem Ton ausstatten möchte und dafür vielleicht auch 200 KB anlegen würde (Musik + SFX).
Dann bleiben für die Grafik vielleicht noch 256, und mit ZVID könnte da einiges reinpassen.
Naja - nenn mich bekloppt - aber ich finde, "realistisch" klingender Sound paßt (meiner Meinung nach) nicht zu farbreduzierter Pixelgrafik. Das wirkt ebenso merkwürdig wie kinofilmartige Grafik mit altem 70er Atarisound.
zatzen hat geschrieben:Ich hatte nur bisher nicht die Geduld, ZVID auf Sprite-Clipping zu erweitern, d.h. ich stehe damit immer noch vor demselben Problem wie beim QuickBasic PUT, dass es nicht über die Bildschirmgrenzen hinausgehen darf, allerdings sind jetzt wenigstens schonmal transparente Sprites möglich.
Naja, Du hattest da ja auch schon Ansätze erwähnt, die ohne Clipping auskämen, mit fixen Bildschirmen, wo man sich von Bildschirm zu Bildschirm bewegt. An sich auch keine schlechte Idee. Mein C64-Spiel "Rockus" ist z.B. auch so (ich konnte noch kein Scrolling).
zatzen hat geschrieben:Um ein Spiel zu machen würde es bei mir zuerst an der Grafik scheitern. Ich bin einfach nicht (mehr) so begeisterungsfähig, Grafik zu machen. Auch deshalb würde ich bei einem Spiel nicht so viel Grafik auffahren, wäre aber in der Lage soundmäßig etwas mehr zu liefern.
Dinge wie diese sind wohl auch der Grund, wieso selbst damals meist mehrere Leute zusammen an einem Spiel gearbeitet haben. Ich sag nur: Trenz-Escher-Hülsbeck...

Vielleicht findest Du ja jemanden, der zwar nicht programmieren kann (oder können muß), aber dafür richtig gut mit Malprogrammen umgehen kann. Der in diesem Sinne Vorteil an Grafik im Gegensatz zu Sound ist, daß es bei Grafik wirklich scheißegal ist, womit man diese erstellt, weil es quasi ein Kinderspiel ist, eine Grafik in ein anderes Format zu konvertieren. Das liegt daran, daß eine Grafik ja nur ein einzelnes "Bild" und nicht etwas, was einen "Verlauf" hat, wie ein Musikstück/Klangeffekt. D.h. wenn irgend ein Grafiker sein Lieblingsmalprogramm benutzen will, reicht es, ihm ein paar wenige Vorgaben zu machen, z.B. falls man selbst Paletten nutzt und er in Truecolor arbeitet, daß er dann möglichst nahe genug an den gewählten Palettenfarben bleibt. Oder, andere Methode: Man läßt ganz am Schluß die ganzen Grafiken durch einen Konverter jagen und scannt nach den besten UND "bestverteilten" Farben und generiert daraus eine Palette daraus, die die Grafiken auch farbreduziert bestmöglich darstellen kann. (Und ja, ich habe ein Programm geschrieben, das so etwas macht.)
zatzen hat geschrieben:Allerdings, je kleiner die Sprites werden, desto einfacher wird es zumindest für mich, etwas zu pixeln. Deshalb strebe ich vielleicht vorerst soetwas an wie ein NES Spiel, nur in 256 Farben.
Niedrige Auflösungen (d.h. alles zwischen 160 und 400 Pixel Breite) und maximal 256 Farben sind sowieso alles was ich jemals (als Spiel) machen werde. (VESA ist nett, aber selbst mit 640x480 ist mit einem 486er kaum etwas wirklich performantes zu bauen...). Und - geht mir bloß weg mit Hicolor/Truecolor! Von mir wird es keine DOS-Spiele mit 16 Millionen Farben geben. Da muß man auch mal realistisch sein und daran denken, was so'n DOS-Rechner hergibt. Selbst wenn die Grafikkarte (wie meine) am PCI-Port hängt... auch der hat nur einen begrenzten Datendurchsatz...
zatzen hat geschrieben:Ich bin mal gespannt auf Dein neues Projekt!
Und ich erst!
Ich bin mindestens genauso gespannt auf mein neues Projekt wie Du. Ich weiß bisher auch noch nicht, was genau es werden wird. Erst einmal sollen ja die Einzelteile funktionieren und an meinem letzten Einzelteil bin ich ja noch am Feilen.
Der Plan sieht zumindest vor, ein Shoot'em'up und ein Jump'n'run damit zu bauen, wobei das Jump'n'run das komplexere von beiden werden soll. Allerdings ist auch der Plan, daß das Jump'n'run ebenfalls mindestens ein "Fluglevel" (wie Shoot'em'up) erhalten soll, so daß ich überlege, ob ich gleich mit dem komplexen Jump'n'run starte oder ob ich erst ein einfacheres, ausschließliches Shoot'em'up damit bauen sollte.

Allerdings bin ich - wie ja bereits mehrmals erwähnt - hier ein Einzelkämpfer und auch wenn ich die ganzen "Bauteile" für ein Spiel bald fertig habe, heißt das nicht, daß dann auch gleich ein Spiel fertig ist. Levels und Sprites müssen ja ebenfalls gebaut werden, Effekte und Musik müssen erstellt werden und das Steuerskript baut sich auch nicht von allein.

"Der Weg ist das Ziel" - wohl fast nirgends paßt diese Bemerkung besser als zu meiner Spieleentwicklung. Meine vielen kleinen Spiele wurden einfach (fast) planlos auf die Maschine geworfen und "funktionieren irgendwie". Mein eines großes Spiel (Xpyderz) ist eben nur groß, aber ebenfalls mit kaum mehr Plan auf die Schaltkreise losgelassen worden (auch wenn ich dabei nebenher viel gelernt und entwickelt habe, was mir in zukünftigen Projekten eine Hilfe sein wird, ich sage nur: Meine Arcade-Unit). Aber selbst Xpyderz hat nicht mal Levels (außer welche, die man sich zufällig erstellen lassen kann) und es hat nicht einmal Klangeffekte, geschweige denn Musik... - was will ich damit sagen?

Nun ja, Spieleentwicklung ist ein Prozeß - in meinem Fall ein LANGER Prozeß. Bedingt duch auch viele schlechte Erfahrungen bei großen Projekten dauert es jetzt länger: Xpyderz sollte eigentlich auch modular programmiert werden, ist aber viel weniger modular angelegt als es eigentlich nötig und vernünftig wäre - so ist eine Menge fast unwartbarer Code entstanden, wo künstliche Verbindungen untereinder bestehen und wo keine vernünftigen Schnittstellen, sondern grausig zusammengeknüppelte Workarounds die einzelnen Teile zur Zusammenarbeit zwingen. Das soll bei meinen neuen größeren Projekten vermieden werden - zum Einen, weil man sich dann während der Spieleentwicklung wirklich auf das SPIEL konzentrieren kann (anstatt schlechte Funktionen selbstprogrammierter Dinge die ganze Zeit programmiererisch "umschiffen" zu müssen) und zum Anderen im Hinblick auf mögliche zukünftige wie auch immer geartete Zusammenarbeit mit anderen interessierten (DOS-) Spieleentwicklern.

Ich hätte EIGENTLICH nicht einmal ein Problem damit, neben meinen eigenen Spielen auch einem Spielprojekt eines anderen meine Dinge zur Verfügung zu stellen - also, falls jemand Spielideen, Grafiken, Sounds hat (oder zumindest irgend etwas davon), diese, in Zusammenarbeit mit mir, mit meinen Routinen zu SEINEM Spiel zu machen - d.h. mich von der Programmierer-/"Engine"-Seite her (und vielleicht auch mehr, kommt drauf an) an einem anderen Spielprojekt zu beteiligen...

- ABER -

Allerdings ist das sowieso nur reine Theorie und wird es wohl auch bleiben. Es gibt einfach zu viele Leute da draußen, die eine völlig unrealistische Vorstellung davon haben, was so ein "DOS-Rechner" (386er/486er) wirklich zu leisten imstande ist und wie "wenig" sich 600 kByte anfühlen, wenn jemand meint, "sowas wie World-of-Warcraft" für DOS umsetzen zu wollen. Aber dieses ganze Geheule, wenn man sich auf 256 Farben (oder bei manchem auf 16 von 256 Farben) beschränken muß, der Sound momentan nur Mono sein kann oder man sich, zumindest für die Steuerung, auf ein paar "pseudo-programmiererische" Überlegungen und Aspekte einlassen müßte. Das ganze Gejammer, daß man nicht genau so ein Spiel machen kann, wie es heute auf Windowsrechnern üblich ist: mit Speicher im Gigabyte-, Festplattenplatz im Terabyte-Bereich, Grafikkarten die hardwaremäßig mehr können als unter DOS softwaremäßig geht... - dies und auf diese ganze Featuritis-Wunschliste... da hätte ich keine Lust drauf, für sowas bin ich einfach zu alt. Da müßte schon jemand mit echtem Interesse daherkommen, dem es wirklich reicht, ein echtes DOS-Spiel zu machen, für den Realitätsnähe kein ausschlaggebendes Spaßkriterium an Spielen ist und der Dinge wie begrenzte Farben, kleine Auflösungen, Minimal-Sound, Speicher im kByte-Bereich usw. nicht als Einschränkung, sondern als Herausforderung betrachtet.

Und ja, ich weiß: Es gibt so Leute da draußen! Aber warum sind die nicht hier?

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 11. Aug 2018, 19:20
von zatzen
Es ging also wahrscheinlich nie wirklich nur um die "stimmensynchrone Trackeransicht", die bei prISM fehlt, um damit arbeiten zu können - sondern eher darum, daß alles, was nicht X-Tracker ist, sowieso nicht benutzbar ist.
Nein, das ist ja Quatsch... Da hast Du mich falsch verstanden. Es ist nur so dass ich X-Tracker wie im Schlaf beherrsche
weil ich ihn schon seit 24 Jahren benutze, und da dachte ich wenn noch alle Möglichkeiten offen sind und sich sonst
keiner äußert mach die Bedienung(!) so wie X-Tracker, dann geht mir das bei Atavism (sehr origineller und zynischer
Name) direkt sehr leicht von der Hand. Ich gucke mir gerade Atavism an.

Folgende Änderungen wären praktisch, zunächst was in den allermeisten Trackern so ist:

Notenwerte werden nicht so eingegeben, dass ein C durch die Taste C, ein D durch die Taste D eingegeben wird,
sondern die Tastatur wird wie eine Klaviatur belegt.
Man hat zwei Oktaven zur Verfügung:
YSXDCVGBHNM
und
Q2W3ER5T6ZU
entsprechend jeweils: C C# D D# E F F# G G# A A# H

So ist es einfacher, intuitiv Musik einzugeben.
YSXDC... schreibt Noten in der eingestellten Grundoktave und diese kann man mit zwei bestimmten Tasten (bei
X-Tracker , und .) weiter hoch oder runter schalten. Q2W3E... schreibt alles eine Oktave höher.

Die Entsprechungen können je nach Tracker variieren, ich habe hier dargestellt wie es in X-Tracker ist.

Um bei X-Tracker zu bleiben (siehe es als einen Vorschlag, nicht als "mach das so oder ich werde das Programm nicht nutzen":

- Die Taste links neben dem Y macht ein Note-Off, d.h. stoppt die Aktuelle Note, da wird es bei ISM
wohl in die Decay-Phase übergehen.
- man kann eine Quantisierung eingeben um nach der Eingabe einer Note direkt um eine bestimmte Anzahl
Zeilen weiterzuspringen.
- Taste Entf allein löscht den Eintrag auf dem man gerade steht und springt um die Quantisierung weiter
(Wenn ich eine Melodie programmiere gehe ich immer so vor: mit der linken Hand spiele ich die entsprechenden
Noten und fülle mit der rechten Hand an der Entf Taste die Pausen aus (ich zerlege alles in 8tel oder 16tel,
was auch immer. Gleichzeitig wird dabei eine bestehende Melodie auf der Spur gelöscht, falls vorhanden.
Es ist also ein gleichmäßiger Rhythmus in 8teln z.B. und je nach Rhytmisierung ist es entweder eine Note
oder die Entf Taste die ich im Wechsel anschlage.)
- Natürlich kann man auch mit den Pfeiltasten nach unten oder oben wandern, ohne etwas zu ändern
- Löschen eines Eintrages und "ziehen" der unteren Einträge nach oben um eine Zeile geschieht durch Strg+Entf
- Einfügen von einer Zeile geschieht durch Strg+Einfg
(- Wechseln der Spur geschieht durch einmaliges Drücken von <- bzw. -> und TAB öffnet ein Fenster für
Optionen/Effekte, Volume wird durch Alt+V eingegeben, man kann Effekt-Makros erstellen oder auch
Effekte von einem Ort zum anderen kopieren indem man einen Bereich vorher markiert, natürlich kann
auch ein ganzer Teil als ganzes kopiert werden. Alles nicht im Sinne von ISM mit der Kopiererei, ich weiss.)

Mehr wollte ich auch nicht meckern. Es ging mir nur um diese grundliegenden Dinge der Bedienbarkeit
beim Editieren der Patterns. Weiteres zum Sequencer etc. muss ich mir noch ansehen.
Ich kann mir vorstellen dass es nicht schön ist wenn man sein bisher programmiertes über den Haufen
werfen soll, das ist ungefähr so als wenn ich ein Spiel fertig habe und dann kommt jemand der vom
Programmieren keinen Schimmer hat und sagt: "Da muss aber noch Scrolling rein!".
Aber überleg mal ob Du Dich mit meinen Vorschlägen anfreunden kannst bzw. den Sinn darin siehst.
Jedenfalls ist der "Workflow" beim Editieren der Patterns am allerwichtigsten.

Aber Samples mit Melodien sind groß. Und die entsprechen auch nicht der eigentlich Idee hinter Module-Tracking.
Es hat sich so als Stil herauskristallisiert für mich, bzw. sind Samples in CD-Qualität auch gerne mal >100 KB groß,
ich bin da mit 1MB GUS RAM noch ziemlich bescheiden unterwegs, moderne Tracker wie OpenMPT oder
Renoise kennen da gar keine Grenzen mehr, da wird gleich 3 minütiger Gesang in 44100 Hz 16 Bit mit ins
Modul gepackt. Kommt alles auf den Anwendungszweck an - will ich eine Produktion für CD etc. machen
dann ist es wurscht wie groß das Modul ist, mache ich ein ZSM für ein Spiel, dann muss ich entweder
geschickt stückeln oder auf allzu organisches Gesampel verzichten.

MIDI gab es schon vor MOD. MIDI an sich ist ja nur ein Datenprotokoll, es enthält quasi nur Informationen
darüber, wie laut man welchen Ton anschlägt und wann man ihn wieder "loslässt". Damit kann man Synthesizer
(z.B. AdLib) ansteuern, aber auch Roboter die Musik dann "live" spielen.

Zum Rest schreibe ich später - das ist noch viel und ich habe gerade nicht die Zeit - Du kannst aber trotzdem
hierauf schon antworten. Ich möchte nur noch eine Ansicht erklären:
Für mich passt ZSM Musik sehr gut zu farbreduzierter Grafik, denn ZSM selbst ist alles andere als super
sauber im Klang. Die besten Ergebnisse hat man noch wenn man simple Dreickecks etc. Wellenformen
als Samples benutzt und somit NES-ähnlichen Sound hat - und dann passt es ja wieder.
Ich war auch fasziniert was man mit dem PC-Speaker alles machen kann, wie Lucasfilm Games
da scheinbar mehrstimmige Musik rausgeholt hat noch auf "analogem" Wege.
Aber echte Mehrstimmigkeit mit Option auf "realistischen" aber "LoFi" Sound habe ich nun mit ZSM
und wie weit ich es ausreize und wie groß die verwendeten Samples werden steht mir ja frei.
Das schöne ist die Mehrstimmigkeit.

Okay, eine Sache noch: Die Dosbox läuft für meine Spieleentwicklung auf 20000 Cycles. Ich glaube
ein echter 486DX25 kann mehr. Mir ist klar dass man das nicht genau abschätzen kann aber vielleicht
so ungefähr. Was ich jedenfalls damit sagen will: Ich werde zusehen dass man nicht mehr als einen
486er für meine Spiele benötigt. Würde ich eine Zeitreise ins Jahr 1989 machen würde ich mir natürlich
wünschen dass alles auch auf einem 286 läuft. Den 386er hab ich übrigens übersprungen, ich hatte
direkt einen 486er und habe vielleicht deshalb auch nicht so sehr den Einblick über die Sinnhaftigkeit,
Programme für solch ein System auszulegen.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 12. Aug 2018, 09:36
von DOSferatu
zatzen hat geschrieben:
Es ging also wahrscheinlich nie wirklich nur um die "stimmensynchrone Trackeransicht", die bei prISM fehlt, um damit arbeiten zu können - sondern eher darum, daß alles, was nicht X-Tracker ist, sowieso nicht benutzbar ist.
Nein, das ist ja Quatsch... Da hast Du mich falsch verstanden. Es ist nur so dass ich X-Tracker wie im Schlaf beherrsche weil ich ihn schon seit 24 Jahren benutze, und da dachte ich wenn noch alle Möglichkeiten offen sind und sich sonst keiner äußert mach die Bedienung(!) so wie X-Tracker,
Ja, die Bedienung geht nur teilweise wie bei X-Tracker zu machen (auch schon, weil X-Tracker mehr/andere Möglichkeiten hat). Ich habe z.B. ALT für das Kopfmenü reserviert - d.h. wenn man ALT gedrückt hält, erscheint das. Ich habe dazu unten (ALT+V) noch eine Anmerkung geschrieben.
zatzen hat geschrieben:dann geht mir das bei Atavism (sehr origineller und zynischer
Name) direkt sehr leicht von der Hand. Ich gucke mir gerade Atavism an.
Aha... Zynisch... Naja, ich habe, basierend auf ISM, einen weiteren Namen gesucht, der maximal 8 Zeichen hat. Mir erschien der Name passend.
zatzen hat geschrieben:Folgende Änderungen wären praktisch, zunächst was in den allermeisten Trackern so ist:
Notenwerte werden nicht so eingegeben, dass ein C durch die Taste C, ein D durch die Taste D eingegeben wird, sondern die Tastatur wird wie eine Klaviatur belegt.
Man hat zwei Oktaven zur Verfügung:
YSXDCVGBHNM
und
Q2W3ER5T6ZU
entsprechend jeweils: C C# D D# E F F# G G# A A# H

So ist es einfacher, intuitiv Musik einzugeben.
YSXDC... schreibt Noten in der eingestellten Grundoktave und diese kann man mit zwei bestimmten Tasten (bei X-Tracker , und .) weiter hoch oder runter schalten. Q2W3E... schreibt alles eine Oktave höher.
Du wirst lachen: Genau so einen Klaviatur-Modus hatte ich sowieso vor, alternativ einzubauen, umschaltbar. (Der Modus wird auch im Initfile gespeichert.)
Da muß ich wohl doch noch die "Direkt-Tasten" bemühen, damit die Tasten auch immer an der gleichen Stelle stehen (das Problem mit Englischer/Deutscher/Französischer Tastenbelegung). Da werd ich Scancodes benutzen.
zatzen hat geschrieben:Die Entsprechungen können je nach Tracker variieren, ich habe hier dargestellt wie es in X-Tracker ist.
Naja, das macht ja auch am meisten Sinn.
zatzen hat geschrieben:Um bei X-Tracker zu bleiben (siehe es als einen Vorschlag, nicht als "mach das so oder ich werde das Programm nicht nutzen":

- Die Taste links neben dem Y macht ein Note-Off, d.h. stoppt die Aktuelle Note, da wird es bei ISM
wohl in die Decay-Phase übergehen.
Decay ist Abschwellen (nach Attack). Release ist Ausklingen.
Kann ich machen - werde aber zusätzlich noch eine andere Taste, z.B. #, auch damit belegen. Grund: Die "links neben Y" Taste gibt es nicht auf jeder Tastatur (USA/UK hat die z.B. nicht).
Achja: Eigentlich gibt es in ISM zwei Möglichkeiten: Entweder Ausklingen oder Abbrechen. Ausklingen leitet Release ein. Abbrechen leitet Mute ein. (Kompletter Ton aus auf der Spur). Vielleicht mach ich's so, daß normales Release die Taste allein gedrückt wird und Mute, wenn man zusammen mit Shift drückt.
zatzen hat geschrieben:- man kann eine Quantisierung eingeben um nach der Eingabe einer Note direkt um eine bestimmte Anzahl Zeilen weiterzuspringen.
Mache ich vielleicht mit Strg+T aufrufbar. Sollen diese a) für jede Spur einzeln gelten, b) für jedes Pattern einzeln gelten oder c) immer nur ein einzelner Wert (für das ganze Stück geltend)? Soll der Wert in's Initfile gespeichert werden?
Soll die Anzahl Zeilen sowohl bei Eingabe einer Note als auch bei Eingabe einer "Leernote" (also Backspace) übersprungen werden?
Hinweis: Die untere Zeile im Sequenzer-Fenster enthält überall Achten (8).
Die können natürlich geändert werden. Die sind ein "Divisor" für 128. D.h. alles ist auf Sechzehntel eingestellt (128/8 = 16), d.h. eine Sechzehntel Note pro Zeile. Wenn man da z.B. 32 eingibt, dann ist jede Zeile eine Viertelnote (128/32 = 4). Das kann für jedes Pattern einzeln gemacht werden.
zatzen hat geschrieben:- Taste Entf allein löscht den Eintrag auf dem man gerade steht und springt um die Quantisierung weiter (Wenn ich eine Melodie programmiere gehe ich immer so vor: mit der linken Hand spiele ich die entsprechenden Noten und fülle mit der rechten Hand an der Entf Taste die Pausen aus (ich zerlege alles in 8tel oder 16tel, was auch immer. Gleichzeitig wird dabei eine bestehende Melodie auf der Spur gelöscht, falls vorhanden. Es ist also ein gleichmäßiger Rhythmus in 8teln z.B. und je nach Rhytmisierung ist es entweder eine Note oder die Entf Taste die ich im Wechsel anschlage.)
Verständlich. Macht auch Sinn. Ich habe aber Einfg/Entf mit umfangreichen Tastenkombis belegt, um zu kopieren/verschieben/löschen usw. Ginge hier auch stattdessen die Backspace-Taste?
zatzen hat geschrieben:- Natürlich kann man auch mit den Pfeiltasten nach unten oder oben wandern, ohne etwas zu ändern
Ja, das sollte ja klar sein...
zatzen hat geschrieben:- Löschen eines Eintrages und "ziehen" der unteren Einträge nach oben um eine Zeile geschieht durch Strg+Entf
- Einfügen von einer Zeile geschieht durch Strg+Einfg
Bei prISM/AtavISM geht das auch - aber ohne Strg.
zatzen hat geschrieben:(- Wechseln der Spur geschieht durch einmaliges Drücken von <- bzw. ->
Geht derzeit in AtavISM mit Strg+ <- bzw. -> (oder eben TAB/Shift+TAB)
zatzen hat geschrieben:und TAB öffnet ein Fenster für Optionen/Effekte,
Könnte man zwar machen, aber ISM (und prISM/AtavISM) haben ja quasi fast keine Optionen/Effekte. Portamento könnte man durch die (bei der Klaviatur unbenutzte) Taste P einschalten. Und ob man in MOD-artiger Eingabe überhaupt Transponieren benutzt, weiß ich nicht - das hatte ich nur der Vollständigkeit halber in AtavISM eingebaut, weil ISM es kann.
Derzeit ruft F4 übrigens das Menü auf, um das aktuelle Instrument oder Sample zu konfigurieren.
zatzen hat geschrieben:Volume wird durch Alt+V eingegeben,
Wie gesagt (siehe oben) ALT ist belegt. Ginge hier auch Strg+V?
zatzen hat geschrieben:man kann Effekt-Makros erstellen
Sind das einfach gespeicherte "Befehls"-Sequenzen (die dann einkopiert werden)? Wie werden diese gespeichert/aufgerufen? Mit einer/mehreren Tastenkombinationen? Aus einem Menü?
zatzen hat geschrieben:oder auch Effekte von einem Ort zum anderen kopieren indem man einen Bereich vorher markiert, natürlich kann auch ein ganzer Teil als ganzes kopiert werden. Alles nicht im Sinne von ISM mit der Kopiererei, ich weiss.)
Kopieren/Verschieben/Einfügen/Löschen usw. geht auch in prISM/AtavISM. (Ein Bereich markiert wird mit Cursortasten oder Bildtasten oder Pos1/Ende - alle jeweils zusammen mit Shift.) Danach wechselt man an das Ziel. Die Funktionen zum Kopieren/Verschieben usw. können dann entweder im Menü "Modify" abgerufen werden (Alt+M) oder, wenn man es schneller haben will (weil man geübt ist und sich die wichtigsten Kombinationen gemerkt hat), mit den verschiedenen Shift/Ctrl/Einfg/Entf Kombinationen (diese Tastenkombinationen werden auch, wenn man im Modify-Pulldown die einzelnen Werte anwählt, in der Statuszeile mit angezeigt).
zatzen hat geschrieben:Mehr wollte ich auch nicht meckern. Es ging mir nur um diese grundliegenden Dinge der Bedienbarkeit beim Editieren der Patterns.
Ja, das ist ja auch das Wichtigste, weil man dort die meiste Zeit arbeitet. Alles "außenherum" ist eben Gewöhnungssache - aber das benutzt man ja auch nicht ständig.
zatzen hat geschrieben:Weiteres zum Sequencer etc. muss ich mir noch ansehen.
Auch AtavISM hat ein Tutorial, genau wie prISM. Am einfachsten kann man es mit der ^-Taste an-/ausschalten. Es geht natürlich auch im Help-Menü (Alt+H, dann T).
zatzen hat geschrieben:Ich kann mir vorstellen dass es nicht schön ist wenn man sein bisher programmiertes über den Haufen werfen soll,
Naja, solange es im Rahmen der Machbarkeit mit dem bescheidenen GUI-System ist, kann man es auch machen. Anders ausgedrückt: Je weiter es von der normalen Machbarkeit abweicht, umso mehr zusätzlicher Programmcode ist nötig - der dann wieder Speicher belegt...
zatzen hat geschrieben:das ist ungefähr so als wenn ich ein Spiel fertig habe und dann kommt jemand der vom Programmieren keinen Schimmer hat und sagt: "Da muss aber noch Scrolling rein!".
Naja, das wäre ja noch einmal eine ganz andere Liga. Aber Leute ohne Ahnung von Programmieren kommen sowieso mit den abstrusesten Ideen um die Ecke. Manchmal kann das nützlich sein - weil man als Fachidiot auf manche guten Ideen schon gar nicht mehr kommt, wenn sie nicht naheliegend sind. Aber manchmal nervt es auch einfach - wenn irgendein unbedarfter Laie so lange rummeckert, bis man ein ganzes nützliches Tool oder gut funktionierendes Spiel nur für seine Wünsche "kaputtoptimiert" zu einem Haufen aufgeblasenen Datenmüll.
zatzen hat geschrieben:Aber überleg mal ob Du Dich mit meinen Vorschlägen anfreunden kannst bzw. den Sinn darin siehst. Jedenfalls ist der "Workflow" beim Editieren der Patterns am allerwichtigsten.
Ja, wie gesagt - das meiste bisher genannte liegt durchaus im Rahmen vorhandener Möglichkeiten.
zatzen hat geschrieben: Es hat sich so als Stil herauskristallisiert für mich, bzw. sind Samples in CD-Qualität auch gerne mal >100 KB groß,
Hinweis: ISM-Samples können (ohne Header) maximal 65520 Bytes groß werden - größere können von ISM nicht abgespielt werden. CD-Qualität-ISM-Samples kann man zwar erzeugen, weil das Format es hergibt - aber in ISM (bzw schon im Loader) werden diese herunterskaliert auf 4bit Mono. Es nützt also nichts, hier mehr einzustellen.
zatzen hat geschrieben:ich bin da mit 1MB GUS RAM noch ziemlich bescheiden unterwegs, moderne Tracker wie OpenMPT oder Renoise kennen da gar keine Grenzen mehr, da wird gleich 3 minütiger Gesang in 44100 Hz 16 Bit mit ins Modul gepackt.
Aber da ist Dir schon klar, daß das Mega-Lame ist, oder? Wozu braucht man da noch MOD? Das ist ja quasi nur ein WAV mit ein bißchen MOD-Header drumherum - da kann man ja auch gleich ein WAV nehmen.
zatzen hat geschrieben:Kommt alles auf den Anwendungszweck an - will ich eine Produktion für CD etc. machen dann ist es wurscht wie groß das Modul ist,
Solange ein Zielmedium es hergibt, ist Größe/Komplexität ja immer unerheblich.
zatzen hat geschrieben:mache ich ein ZSM für ein Spiel, dann muss ich entweder geschickt stückeln oder auf allzu organisches Gesampel verzichten.
Naja, wenn das Gerät einem technische Grenzen vorgibt, muß man diese einhalten, ob man will oder nicht - sonst funktioniert es nicht. Wenn man insgesamt 550 kByte für Samples benutzen will, muß sich alles andere eben den verbleibenden Speicher aufteilen. Daß man dann grafik-/level-mäßig nicht mehr allzuviel auffahren kann, versteht sich von selbst. Wenn es aber ein Spiel ist, bei dem es nur und fast ausschließlich um Klänge geht - wieso nicht...?
Der PC hat eben diese Von-Neumann-Architektur: Code und Daten müssen sich denselben Speicher teilen.
zatzen hat geschrieben:MIDI gab es schon vor MOD. MIDI an sich ist ja nur ein Datenprotokoll, es enthält quasi nur Informationen darüber, wie laut man welchen Ton anschlägt und wann man ihn wieder "loslässt". Damit kann man Synthesizer (z.B. AdLib) ansteuern, aber auch Roboter die Musik dann "live" spielen.
Ja, ich bezog mich eher darauf, daß MOD quasi (mit Abwandlungen) das gleiche macht: "Spiele jetzt Instrument X mit Tonhöhe Y". Das Instrument ist hier ein Sample. Aber das ist es bei den meisten Synthesizern auch.
zatzen hat geschrieben:Zum Rest schreibe ich später - das ist noch viel und ich habe gerade nicht die Zeit -
Kein Problem. Ich kenne ja meine Schwäche, in Foren riesige Romane zu schreiben. Zum Glück wird einem das im DOSforum nicht krummgenommen. (Ich habe da andere Foren erlebt, da mußte man ja quasi fast nur in Chatsprache "bellen" und wenn mal einer ausführlich geschrieben und vernünftiges Deutsch benutzt hat, wurde er gleich dumm angemacht...)
zatzen hat geschrieben:Du kannst aber trotzdem hierauf schon antworten.
Danke für die offizielle Erlaubnis... Hätte ich aber sowieso gemacht.
zatzen hat geschrieben:Ich möchte nur noch eine Ansicht erklären:
Für mich passt ZSM Musik sehr gut zu farbreduzierter Grafik, denn ZSM selbst ist alles andere als super sauber im Klang. Die besten Ergebnisse hat man noch wenn man simple Dreickecks etc. Wellenformen als Samples benutzt und somit NES-ähnlichen Sound hat - und dann passt es ja wieder.
Naja, ich meinte eben eher so realistischen Orchesterklang, "echte Instrumente", Sprachausgabe und all sowas - und das restliche Spiel sieht dann grafisch aus wie Strichmännchen und macht weniger als Pong (weil kein Speicher mehr da ist). Das wäre seltsam - da kann man auch gleich einen reinen Musikplayer schreiben. Aber so ein "Musikplayer" mit etwas angeflanschter kleiner Spielgelegenheit dran ... das würd' ich dann nicht direkt ein Spiel nennen.
zatzen hat geschrieben:Ich war auch fasziniert was man mit dem PC-Speaker alles machen kann, wie Lucasfilm Games da scheinbar mehrstimmige Musik rausgeholt hat noch auf "analogem" Wege.
Du kannst Dir ja mal "PLAYBOX" anschauen/anhören, da benutze ich "zweistimmigen"/"dreistimmigen" "Analog-"Speaker Sound.
zatzen hat geschrieben:Aber echte Mehrstimmigkeit mit Option auf "realistischen" aber "LoFi" Sound habe ich nun mit ZSM und wie weit ich es ausreize und wie groß die verwendeten Samples werden steht mir ja frei. Das schöne ist die Mehrstimmigkeit.
Ja, das stimmt. Mehrstimmigkeit hat schon was. Allerdings weiß ich oft mit mehr als 3 Stimmen kaum noch etwas anzufangen. Noch zu einem für mich eigentlich "fertig" wirkenden Stück noch eine weitere Stimme mit "irgendeinem Gedudel" hinzuzufügen, nur um mehr Stimmen zu haben ist meins so gar nicht. Öfter als man denkt ist weniger mehr.
zatzen hat geschrieben:Okay, eine Sache noch: Die Dosbox läuft für meine Spieleentwicklung auf 20000 Cycles. Ich glaube ein echter 486DX25 kann mehr.
Ja, diese Cycles sind nur ein DOSbox-interner Richtwert, um es schneller/langsamer einzustellen und hängt natürlich auch vom Hostsystem (dem Computer auf dem es läuft) ab.
zatzen hat geschrieben:Mir ist klar dass man das nicht genau abschätzen kann aber vielleicht so ungefähr. Was ich jedenfalls damit sagen will: Ich werde zusehen dass man nicht mehr als einen 486er für meine Spiele benötigt.
Naja, mach einfach die Rate beim Sound einstellbar. Wenn die Kiste für 44kHz zu langsam ist, kann man ja 33, 22 oder 11 kHz nehmen, damit das restliche Spiel auch noch geht. Kommst Du bei variabel einstellbarer Soundrate dann überhaupt mit dem Timing hin? Bei 11 kHz im Vergleich zu 44 kHz kommt der IRQ für "Puffer zu Ende" ja erst nach der vierfachen Zeit. Oder machst Du dann einfach den Puffer kleiner?
zatzen hat geschrieben:Würde ich eine Zeitreise ins Jahr 1989 machen würde ich mir natürlich wünschen dass alles auch auf einem 286 läuft.
Würde man 1989 leben, hätte man gar keinen 486er und ein 386er wäre unbezahlbar. Wenn der 286er das momentane "Maß der Dinge" ist, programmiert man eben so, daß es da läuft. Und viele Leute haben ja bewiesen, was man selbst mit einem 286er alles anstellen kann.
zatzen hat geschrieben:Den 386er hab ich übrigens übersprungen, ich hatte direkt einen 486er und habe vielleicht deshalb auch nicht so sehr den Einblick über die Sinnhaftigkeit, Programme für solch ein System auszulegen.
Naja, bei mir war es auch so, aber nicht, weil ich den 386er nicht mögen würde. Ich bin direkt vom 286er auf 486er gewechselt - was daran lag, daß ich alle meine Systeme damals von Kumpels geschenkt und zusammengeschraubt bekommen habe. Meinen eigenen 286er hatte ich ab 1996 und ich glaube so 1998 oder so ist es dann ein 486er geworden. (Vor/bis 1996 war es C64, davor (1989/1990) ein KC-85/4 - die habe ich auch beide noch. Der C64 steht hier direkt neben meinem 486er einsatzbereit.)
Der 386er war eben die Maschine, die als erste 32Bit-Register und -Adressierung hatte, sowie die erweiterten Segmentregister (FS, GS). Beides finde ich sehr nützlich und deshalb nutze ich es. Der 486er hat noch ein paar neue Befehle, die aber nicht so wichtig sind, als daß man sie nicht auch umgehen könnte - ABER: Ein 486er ist mit gleicher CPU-Taktfrequenz doppelt so schnell wie ein 386er (weil die Opcodes wesentlich weniger Takte brauchen) und zusätzlich gibt es ihn auch mit höheren Taktraten (386er maximal 40 MHz, 486er maximal 166 MHz, obwohl es angeblich sogar welche mit 180 MHz gegeben haben soll.)
D.h. es ist natürlich klar, daß mein 486-X5 (133 MHz, mit 33 MHz Bus und PCI-Grafikarte VGA/VESA und SoundBlaster AWE64) bestimmt fast 10x so schnell ist wie der schnellstmögliche 386er mit 40 MHz. (Ja, für ein System wie meinen DOS-Rechner hätten manche vor 25 Jahren ihr Erstgeborenes hergegeben...)

Aber: Ich behandle den 486er eben wie einen superschnellen 386er, indem ich keine 486er-Befehle benutze. Somit ist mein Zeug "Mindestanforderung DX 386", was aber nur heißt: Da stürzt es nicht ab, d.h. man kann es starten und es läuft irgendwie. Aber es performt eben gar nicht.

Also: Auch MEINE Spiele setzen wohl eher einen 486er mit schnellem Bus und vor allem schneller Grafikkarte (also schnellem Zugriff) voraus. Ob etwas, das ich mit meinem neuen Kombi-System (die Arcade-Grafikroutinen, die ISM-Soundroutinen, die GameSys2-Steuerroutinen und das ganze "Kleinzeug" ringsherum) auf einem 386er überhaupt irgendwie spielbar laufen wird/würde... hmmm - das müßte dann jemand testen, der einen 386er hat. Bei Xpyderz kann man ja die Grafik auf "LowRes" (160x200) stellen - technisch möglich wäre auch eine Verkleinerung des Bildschirms (inklusive Verkleinerung der Anzeige natürlich), es ist nur im Menü nicht auswählbar. Aber Xpyderz hat nicht einmal Musik. Und da Xpyderz auf einem 386er sowieso schon kaum noch performt, wäre es nicht auszudenken, wenn da jetzt noch ein Klangdatengenerator im Hintergrund laufen würde... Dann hätte man vielleicht eine Diashow.

Ich bin als Programmierer eben immer noch zu schlecht. Alles was ich mache wird, bei aller Mühe, trotzdem immer nur so ein halbgares Zeug. Zum Glück ist es nur ein Hobby - verkaufen könnt ich den Kram niemals, nichtmal vor 25 Jahren.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 12. Aug 2018, 20:03
von zatzen
Zum Thema Synchronität:

Ich handhabe das mit Bild und Ton meiner Spiele quasi wie ein steuerbares Video.
Bei einem Video wird ein Bild/Frame angezeigt, und passend zu diesem Frame das
entsprechende Tonsegment.
Gibt es ein Bild zu einer Explosion beispielsweise, also das erste Bild dazu, ist dies
der Zeitpunkt an dem der Explosions-Sound startet. Wir haben also das Bild und
dazu das Tonsegment, in dem der Explosionsssound gerade beginnt. Von daher IST
das synchron zumindest wenn es gerastert in Pufferlängen ist und ein Ereignis immer
nur an einer Framegrenze stattfinden kann. Ebenfalls ist das so bei einem ganz sensiblen
Thema was die Synchronität angeht, nämlich wenn man jemanden sieht der spricht.
Wenn es da 200 ms hinkt wird das schon sehr auffällig und störend. Aber auch hier
haben wir bei einem Video den Fall, dass beispielsweise ein P-Laut genau in dem
Moment beginnt, wenn der Sprecher seinen Mund entsprechend geformt hat.
Also immer: Entsprechendes Bild wird angezeigt, und dann wird ab genau diesem
Zeitpunkt das passende Klangereignis gespielt. Bei richtigen Videos eben auch mal
irgendwo dazwischen je nachdem, weil sich nicht alles perfekt in meinetwegen 25
fps rastern lässt.
Ein Einspielen der Klänge in den gerade abgespielten Puffer hinein ist gar nicht
nötig, diese kämen dann einfach nur zu früh bzw. noch während das vorherige Bild angezeigt wird.
Was die Synchronität bzgl. der Steuerung oder der Echtzeit angeht ist das noch eine
andere Sache, man muss nach meiner Methode damit leben dass man immer erst
eine Pufferlänge später die Ergebnisse seiner Handlungen sieht.
Und natürlich "weiss" der Computer gewisssermaßen immer schon mehr oder weniger
eine Frame-Länge voraus was im Spiel passiert.
Gesetzt den Fall wir hätten nur 1 fps. Dann wäre es eben so, dass ich eine "Diashow"
hätte und ein Bild nach dem anderen vorgesetzt bekomme, und ich muss dann eben
meine Handlungen gut überlegen weil sie vielleicht gröber ausfallen. Aber immer noch,
wenn ich sehe da steht eine Tretmine und ich bewege mich da absichtlich hinein,
kommt im nächsten "Standbild" die grafische Darstellung der Explosion und ohne
Verzögerung der entsprechende Sound. Das funktioniert natürlich nur, wenn ich
mich rechtzeitig entscheide, innerhalb dieser Sekunde in die Tretmine zu treten,
und die Steuerung müsste ja das erste sein, was in einem Frame abgefragt wird,
damit noch genug Zeit für die Berechnungen sind. Daher wird man letztlich seine
Entscheidungen effektiv erst im übernächsten Frame sehen. Von daher gebe ich Dir Recht,
dass da etwas mit der Synchronität nicht so ist wie ich es mir wünschen würde,
aber Bild und Ton selbst wären, wie oben am Beispiel des Videos, für sich genommen
synchron, nach meiner Art und Weise vorzugehen.

Das mit der Steuerung ist natürlich blöd. Du hast da ein anderes Vorgehen beschrieben,
das werde ich mir nochmal durchlesen.

Ich hab's eben ein wenig mit Bild/Ton Synchronität auch wegen meiner Videos auf youtube.com/videocuts2010
DOSferatu hat geschrieben:Man braucht nur so oft Kollisionsabfragen machen, wie sich im Spiel etwas "bewegt". Wenn jede Figur 20 Schritte pro Sekunde macht, passiert zwischen den Schritten ja nichts. D.h. das Verhältnis der Figuren zueinander ändert sich ja nur wenn sie sich bewegen und nur dann ist der "Kollisionszustand" wieder anders.
Ich denke noch immer so wie früher, dass ich z.B. abprallen einer Wand mit Pixelabfrage überprüfe. Wenn sich nun wegen relativ geringer Framerate die Figuren mal schneller als mit 1 Pixel/Frame bewegen dachte ich, ich müsste das intern interpolieren.
DOSferatu hat geschrieben:Bei so fotorealistischen 3D-Spielen mit lebensechtem Sound
Nein, das wird mir dann auch langweilig. Da geh ich lieber ins Kino und guck mir Star Wars an, da ist die CGI
wenigstens richtig gut. 320x200x256 in 2D ist schon perfekt für mich, und ein bisschen rotziger Digisound dabei.
DOSferatu hat geschrieben:Naja, Du hattest da ja auch schon Ansätze erwähnt, die ohne Clipping auskämen, mit fixen Bildschirmen, wo man sich von Bildschirm zu Bildschirm bewegt.
Ja, Scrolling würde mir auch einfach zu viel Rechenleistung fressen. Das kann man auf nem Pentium machen,
aber das ist dann fast schon wieder Windows-Niveau. Vielleicht hab ich mal die Geduld ZVID wenigstens auf
blockweises Clipping zu erweitern, also dass am Rand dann alles in 8 Pixel Einheiten verschwindet. Ein kleiner
Rahmen um den Screen und es wäre gut.

Grafik: Evtl. meine Schwester. Aber ich muss erstmal ein Konzept haben. Ein kleines Problemchen ist noch
dass es eben vertikal nur 200 Pixel sind, aber alle gängigen Grafikprogramme quadratische Pixel haben.

Niedrige Auflösungen: 320x200 ist mein absoluter Standard. Und da drin dann eben auch kleine Sprites.
Also vielleicht 12x16 Pixel. Oder meinetwegen auch 16x24, dann passt es besser mit ZVID...

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 18. Aug 2018, 12:00
von DOSferatu
zatzen hat geschrieben:Zum Thema Synchronität: [...]
Ich verstehe, worauf Du hinauswillst. Und ja, für Videos ist das auch alles richtig.
Aber: Videos und Spiele unterscheiden sich dadurch, daß Videos einfach "ablaufen", während Spiele interaktiv sind. Also, bei Videos kann man natürlich bereits im Vorfeld "planen", wann der Klang erfolgt. Bei Videos weiß man auch vorher jederzeit, was wann passieren wird. Somit kann der Klang- und Grafikpuffer um den jeweiligen Zeitversatz vorher gefüllt werden, damit dann beim Abspielen alles 100% gleichzeitig passiert.

Bei Spielen ist das nicht so (außer bei Cutscenes, die aber natürlich in den Bereich Video gehören). Hier kann der Programmierer nicht 100% planen, was wann passiert - weil er ja nicht vorher weiß, was der Spieler wann tut. Und je komplexer ein Spiel ist, d.h. je mehr aktive Elemente (Spieler und andere Elemente) miteinander interagieren, ist das auch für die anderen Elemente immer weniger direkt vorhersehbar. Außerdem kommt zusätzlich zum Video bei Spielen ja noch die Steuerung (sowohl der Spieler als auch der restlichen Elemente) hinzu, was auch ein wichtiger Programmteil ist (und bei Spielen natürlich unverzichtbar) - und auch die Steuerung benötigt einen gewissen Anteil der CPU-Rechenzeit, die ist nicht "einfach so da und passiert so nebenher".

Zur Lippensynchronität: Da kommt es darauf an, ob es nur in Cutscenes (was ja Videos sind) benutzt werden soll oder auch direkt im Spiel. Ich sage mal so: In Trickfilmen haben die Figuren meist nur so 2 bis 5 Mundeinstellungen, das soll nur verdeutlichen, daß sie gerade reden, da ist von Lippensynchronität kaum die Rede. Bei synchronisierten Filmen kann man das Ganze wegen der unterschiedlichen Sprachen auch nur ungefähr angleichen. - Aber bei einem SPIEL mit 320x200er Auflösung und niedriger Framerate - da soll so etwas entscheidend und wichtig für die Qualität sein? Entschuldige hier meine Ausdrucksweise, aber: Das ist lächerlich!

Und: Bevor man ein Spiel mit Sprachausgabe macht, sollte erst einmal überhaupt das Spiel an sich "fertig" oder zumindest spielbar/benutzbar sein. Sprachausgabe ist etwas, das man hinterher immer noch "draufpflanzen" kann. Oder, mal anders ausgedrückt: Man sollte (meiner Meinung nach) bei einem Spiel nicht mit der Sprachausgabe und den Klangeffekten anfangen und dann "das Spiel drumherum" bauen. Wenn man ein Haus baut, fängt man ja auch nicht mit dem Dach oder den Fenstern an.

Früher, als ich vergleichsweise sehr jung war, bin ich auch auf diese "Design über Funktion" Denkweise hereingefallen, bzw. dachte, man müsse ein Spiel in der Reihenfolge bauen wie es der Spieler sieht... Was lustigerweise dazu führte, daß ich auf meinen alten Rechnern (KC85/4 und C64 und sogar auch meinen Anfängen auf PC) haufenweise selbstgemachte TITELBILDER und INTROS habe für Spiele, die nie erschienen sind.

Meiner Meinung nach ist ein Spiel (ein interaktives Aktionsspiel) nicht so etwas wie: Man baut um irgend etwas, das einem wichtig erscheint (also quasi den "Magnetkern") alles drumherum und dran. Kann man zwar so machen, aber meiner bescheidenen Meinung nach verzettelt man sich dabei - dann reicht am Ende Speicher und Rechenkraft nicht aus oder das "drumherum" muß immer komplexer gemacht werden, damit es auch noch zum "Magnetkern" paßt.

Die (meiner Meinung nach) bessere - erfolgversprechendere - Methode (wobei Erfolg=das Spiel wird fertig und funktioniert) ist eher die, daß man alle Hauptkomponenten des Spiels gleichwertig behandelt und schon von Anfang an, bzw. in einer sehr frühen Entwicklungsphase festlegt, was Hauptkomponenten und was Beiwerk ist. Ein Kuchen mit Zuckerstreuseln ist nett, aber das Wichtige ist der Kuchen und nicht die Zuckerstreusel.

Bei einem normalen 2D-"Arcade"Spiel sind Hauptkomponenten:
- Steuerung
- Grafik
Ja, da Klang (Sound) nicht mit aufgeführt! Wieso?
Naja, ohne Steuerung kann der Spieler nichts machen - da ist es also kein Spiel. Und ohne Grafik kann er nicht sehen, was er macht, wohin die Figur springt, was die anderen Figuren machen usw. Aber es ist ohne Klänge immer noch spielbar. Aber eben nicht ohne Grafik. (OK, das wäre auch einmal etwas: Ein Spiel speziell für Blinde, mit schwarzem Bildschirm und man spielt nach Gehör! Wäre 'ne Revolution und Neuerung! Weiß nicht, ob es so etwas jemals gegeben hat, aber das wäre mal WIRKLICH eine neue Spielidee.)

Aber bleiben wir bei den normalen "Arcade-2D-Spielen". Also: Mit Steuerung und Grafik allein kann der Spieler spielen. Musik und Klangeffekte machen es besser, sind aber nicht nötig um ein spielbares 2D-Arcade-Spiel zu machen.

Grafik kann auch zweifarbig sein (einfarbig macht keinen Sinn, klar...), dann ist es auch schon spielbar - aber natürlich kann man es schöner machen, wenn man mehr Farben benutzt (und Ahnung hat, wie man diese Farben einsetzt - es gibt Leute, die brauchen 24bit-Farbtiefe, aber nicht, um abwechslungsreiche Grafiken zu erstellen, sondern nur, um alles mit langweiligen glatten Farbverläufen füllen zu können... sieht nicht wirklich gut aus.)

Auf die Steuerung kann man aber nicht verzichten. Man kann sie einfach halten - je simpler die Möglichkeiten, umso einfacher das Spiel.

Beispiel: Schwarzer Bildschirm, links und rechts je eine weißer senkrechter Streifen, der hoch und runter bewegt werden kann, in der Mitte eine grob gepunktete weiße Linie, oben mittig eine einfache Punkteanzeige und ein beweglicher weißer (wenn es das System nur hergibt, eckiger) Punkt... Steuerung ist einzig eine quasi-stufenlose Auf-/Abwärtsbewegung einer der Linien pro Spieler... - und die Steuerung bestimmt, wie sich der Punkt im Verhältnis zu den weißen Linien und den Bildrändern verhält - schon hat man ein spielbares Spiel. (Nicht schwer zu erkennen, welches ich meine.) Jetzt kann man auch noch Klänge hinzufügen, die bestimmte Aktionen mit einem Klang untermalt.

Die Punkteanzeige ist eigentlich auch schon "Luxus" und für ein Spiel nicht von Belang - sie ist quasi der erste Vorläufer des "Belohnungssystems", das quasi fast alle Spiele haben. - Das kann man in Spielen beliebig ausweiten:
a) zu sammelnde Objekte (Münzen, Kisten, Murmeln) oder auch Dinge, die nicht nur einen Punktestand erhöhen, sondern die Fähigkeiten der Spielfigur steigern.
b) Aufteilen in Spielstufen ("Levels"), die zu absolvieren sind
c) Geheimnisse, die nicht zum Absolvieren des Spiels nötig sind, aber Extrapunkte und Extraerfolgserlebnis bringen
und so weiter...

Wenn man den Begriff "Spiel" nun etwas weiter faßt - und sich nicht auf "2D-Arcade" beschränkt oder auf das Steuern einer Spielfigur - so ist es durchaus möglich, Grafik komplett wegzulassen oder sie z.B. auf reine Anzeige der Steuermöglichkeiten zu reduzieren. Dann kann ein Spiel im Kern z.B. auch bestehen aus:
- Steuerung
- Klang
Und könnte ein rein auf Klänge basierendes Spiel sein - Erkennen von Klängen, Kombinieren von Klängen zu neuen Klängen... Die "Bewertung" des Ganzen ist - wie bei allen Spielen - natürlich subjektiv und vom Programmierer vorgegeben. Ein musischer Mensch, ein "Klangfetischist" könnte an so einem Spiel denkbar seine helle Freude haben. - den meisten durchschnittlichen Spielern ist Musik und Klang in Spielen eher als "Untermalung" wichtig, aber sie hätten spielerisch erfahrungsgemäß gern mehr "Action" - und das kommt dann meist ohne Grafik nicht mehr aus.

Wie würde ich also vorgehen, wenn ich ein 2D-Arcade-Spiel bauen wollte?
Zunächst: Es müssen erst einmal programmiererisch genügend Komponenten vorhanden sein, um überhaupt ein steuerbares Spiel zu bauen. Das setze ich jetzt erst einmal voraus.

Nun baut man ein Level. Das Level muß nicht schön sein, die Elemente sollten schon ihre Funktion haben, aber können grafisch auch einfache "Platzhalter" sein. Klingt häßlich - ist es auch.

Dann entwickelt man eine Steuerung für eine Spielfigur und eine "Gegen-Spielfigur", d.h. Unterprogramme, die diese Figuren auf Levelelemente und auf andere Figuren reagieren lassen. Diese Reaktion muß noch nicht irgend etwas "brauchbares" auslösen - es reicht, wenn sie dem Entwickler durch irgend eine Ausgabe angezeigt wird. Die Spiel-/Gegen-Spielfiguren können ebenfalls Platzhalter sein, z.B. Rechtecke oder Kreise/Ellipsen in der Größe ihrer "Hitbox". (Als Hitbox wird der Bereich einer Figur bezeichnet, der abgefragt wird um Kollision mit anderen Figuren/Levelelementen festzustellen. Pixelgenaue Kollisionsabfrage ist oft unnötig, macht das Spiel für Spieler nur schwerer und davon abgesehen auch aufwendig zu programmieren und damit langsam.)

Ja, das ist NOCH häßlicher! Aber daran sieht man, was der Kern eines 2D-Arcade-Spiels ist und was "Beiwerk". Man kann ein Spiel ohne "Beiwerk" spielen - aber eben nicht ohne den Kern. Klar?

Wenn man es nun geschafft hat, daß Spielklotz und Antispielklotz auf Levelelemente und auf einander korrekt (d.h. nachvollziehbar) reagieren - ja, ERST DANN! - kann man das Spiel erweitern: Schafft man es, daß es mehrere Antispielklötze gibt, die ebenfalls noch so funktionieren wie der eine, unabhängig voneinander? (Von mehreren SPIELER-Figuren rede ich hier noch gar nicht - Mehrspieler ist noch einmal eine ganz andere Liga.)

Und wenn DAS ALLES funktioniert, dann hat man eine Grundlage, mit der man arbeiten kann!

Wenn man nun plant, daß das Spiel Klänge (Musik/Klangeffekte) haben soll, dann baut man irgend einen "Dummy-"Klangeffekt (oder mehrere) und außerdem baut man das Abspielen der Klangausgabe in die Hauptschleife ein. Soll statt einem Ticker (oder Timerschleife) die Klangausgabe das Timing übernehmen, so muß diese natürlich schon vorher in der Hauptschleife sein - aber um die wirkliche Ausgabe des Sounds sollte man sich erst kümmern, wenn man Levels und Spielfiguren (als Dummy-Klötze) darstellen und bewegen kann! (D.h. der Sound gibt in dem Fall an diesem Punkt der Entwicklung meinetwegen nur immer Stille oder immer das gleiche Sample aus.)

So! Nun haben wir ja die Figuren/Antifiguren und Level so weit, daß sie Aktionen und Reaktionen erzeugen können. Weil wir auf einem Computer sind, ist eine Reaktion sowieso immer irgend etwas digitales - also im weitesten Sinne eine Zahl. Je nachdem wie diese Zahl aussieht, kann man sie dann an den Klanggenerator weiterleiten, der einen Klang auslöst und/oder auch gleichzeitig in der Steuerung benutzen, um Figuren auszuschalten oder neue Figuren anzuschalten.

Die Steuerung selbst geschieht dabei "intern" und völlig unabhängig von Grafik oder Klang. Eine Spielfigurensteuerung ist sozusagen das Ändern von numerischen Figurenwerten in einer Figurenwert-Datenbank - bezugnehmend auf die Verhältnisse dieser Werte zueinander. Eine Figurenkollision ist nicht das Überlappen zweier "Sprites", sondern das Sich-Annähern der Koordinatenwerte zweier Figuren. (Außer bei pixelgenauer Kollision - da muß die Steuerung ein "Feedback", d.h. einen Zugriff auf die grafischen Figurenmatrizen, also die "Texturen" erhalten.)

Die Grafikroutine selbst holt nur, wenn sie "grad dran ist", die Werte der Koordinaten und der Sprite-Texturen, sowie evtl. einiger Darstellungs-Modi, aus der "Figurenwert-Datenbank", d.h. sie hat Nur-Lese-Zugriff darauf (die Steuerroutine hat Lese- und Schreibzugriff) - und gibt dann die Figuren an den jeweiligen Positionen mit den gewünschten Werten aus.

Das wird übrigens selbst auf den einfachsten Konsolen (und auch z.B. dem C64) schon so gemacht - nur daß die Grafikroutine hier direkt in Hardware umgesetzt im Grafikchip existiert. Der Grafikchip des C64 enthält 17 8-Bit-Register für die Spritepositionen von 8 Sprites auf dem Bildschirm. 8x X-Koordinate (horizontal), 8x Y-Koordinate (vertikal) und dann noch ein Register, das die "oberen Bits" für die X-Koordinaten enthält, weil das Bild breiter als 256 Pixel ist. Dann sind noch 8 Register für die Farben drin und über "Umwege" werden auch die Posiitonen, an denen sich die Bitmaps/Texturen der Sprites befinden, angegeben. (Dann sind da noch Register, die die Sprites an/ausschalten oder einige Darstellungs-Modi vorgeben.)

Also: Völlig unabhängig davon, was der restliche Computer gerade tut, werden die Sprites über (oder alternativ auch "unter"/"zwischen") dem Bild angezeigt. Praktisch, oder? (Für mehr Sprites als 8 muß man einen Programmiertrick anwenden, der aber aufgrund der Beschaffenheit des Grafikchips nicht schwer umsetzbar ist,)

Ja, wäre schick, so etwas auch auf der VGA zu haben.... - Hat man aber nicht!
Man hat einen OPL3-Chip ("AdLib"), der ähnliche Dinge tun kann wie der Klangchip des C64 (nur daß der SID wesentlich einfacher anzusteuern ist). Da hat man nun die Wahl: Stößt man immer wieder einen Ton im OPL3 an? Oder entscheidet man sich für völlig "digitale" Klangausgabe? Im letzteren Fall gibt es mal wieder NICHTS auf dem PC, was diese Klänge erzeugt,,,
- Halt! Gibt es doch! Wavetable und Gravis Ultrasound geben so etwas her - aber die GUS war/ist schon nicht mehr gängige "Normalausstattung" eines DOS-Spiele-PCs. Vom Vorhandensein einer SoundBlaster- (oder kompatiblen) Karte konnte man aber ab einem bestimmten Punkt ausgehen. Allerdings müssen dafür die Klänge wieder "manuell" erzeugt werden.

Was will ich mit all diesem Geschreibsel sagen?
Ja, es gibt Spielkonsolen und Rechner (8-Bit) mit "Spielkonsolen-"Qualitäten"/ Fähigkeiten!

Aber: Der PC gehört NICHT dazu! Der PC (bzw die PC-Peripherie) hat NICHT:
(A) hardwaremäßige Darstellung von patternbasierten Levels in vielen Farben.
Er hat etwas ähnliches - den Textmode. Das ist das, was der hardwaremäßigen Darstellung von definierten Matrizen in Kacheln am nächsten kommt. Der Textmode ist auch etwas viel komplexeres als alle VGA/VESA-Grafikmodi zusammen. Der komplexere Grafikmode ist der palettenbasierte (also z.B. 16 oder 256 Farben in Farbpalette. Die schaltungstechnisch simpelsten Grafikmodi sind Hicolor (15/16Bit Direktfarben) und Truecolor (24/32Bit Direktfarben).

(B) hardwaremäßige Darstellung von unabhängig von der restlichen Grafik darstellbaren/verschiebbaren Objekten beliebiger Größe und Farbe ("Sprites") - abgesehen von in manchen Grafikarten hardwaremäßig vorhandenen "Mauszeiger"-Sprite.

(C) automatische Klangerzeugung beliebig definierbarer Klänge durch simples Aktivieren.

(Ich rede hier natürlich vom Standard "DOS"-PC, nicht von PCs mit modernen 3D-Grafikkarten oder Soundchips/Soundkarten - die generell nicht in die Kategorie fallen, für die "DOS-Spiele" geschrieben wurden und werden.)

Was bedeutet das alles? Naja, wenn es hardwaremäßig nicht vorhanden ist, muß es per Software nachgebildet werden. Die Hardware könnte alle Dinge quasi gleichzeitig machen: der C64-Grafikchip stellt mit voller Framerate sein Bild dar, inklusive Sprites - unabhängig davon, was die CPU oder der Soundchip gerade macht. Der Soundchip spielt die festgelegten Klänge auch mit voller Frequenz ab, komplett unabhängig davon, was der Grafikchip oder die CPU gerade macht. Und die CPU macht auch alles (fast) komplett unabhängig davon, was Grafikchip und Soundchip gerade machen. (Ausnahme: Der Grafikchip kann für die CPU ab und zu Speicherzugriffe blockieren, wenn er selbst mehr Zugriffe braucht als in dem ihm zustehenden Halbzyklus. Allerdings "merkt" die CPU davon nichts, weil sie für diesen Zeitraum "totgelegt" wird.

Tja - und auf dem PC geht das alles NICHT gleichzeitig und unabhängig voneinander, muß in Software nachgebildet werden und das bedeutet: Alles muß durch die CPU! Diese kann das nicht alles gleichzeitig machen, auch wenn es im Spiel dann so aussehen/klingen soll, als wäre alles gleichzeitig. Deshalb muß eine Art "Multitasking" passieren, d.h. die einzelnen Teile werden nacheinander in einer sich ständig wiederholenden Schleife abgearbeitet und - ob man es will oder nicht - jedes davon klaut sich dafür etwas CPU-Rechenzeit. Natürlich muß nicht jedes Sub-Element in jedem Schleifendurchlauf aufgerufen werden - sondern nur dann, wenn ein "Auslöser" es triggert.

Der Auslöser für die Grafik dürfte der Vertikale Retrace sein - den man bei den meisten VGA nur durch Polling abfragen kann - leider kein IRQ dafür vorhanden - blöd. Häufiger als der VR muß die Grafik nicht generiert werden. Möglicherweise wird sie aber seltener generiert, wenn man nicht mit voller Framerate spielt, weil der Rechner zu langsam ist.

Der Auslöser für den Klang ist das Ablaufen des Klangpuffers, d.h. wenn die Soundkarte mit dem Abspielen es aktuellen Puffers fertig ist. Hierfür wird zum Glück ein IRQ erzeugt.

Der Auslöser für die Steuerung sollte auch irgend ein Ticker sein - was man dafür benutzt, ist so ziemlich egal - es muß nur ein regelmäßig auftretender Auslöser sein (Soundkarten-IRQ, Timer, usw.) Das ist nur dann wichtig, wenn man verhindern will, daß das Spiel sich langsamer steuert, wenn gerade viel Rechenzeit verbraucht (gerade viele Sprites dargestellt werden müssen oder in diesem Durchlauf der Klangpuffer neu generiert wird) wird und schneller, wenn es weniger ist - das geht zwar auch, aber dann hat man einen sehr eigenwilligen Spielfluß. (Es sei denn, die Rechenzeit reicht selbst bei Vollbelastung durch alle Unterprogramme jederzeit aus, um zwischen zwei "Ticks" alles zu erledigen,)

D.h. ob man es will oder nicht, auf PCs wird nichts gleichzeitig ausgeführt, sondern immer nacheinander. (Ja, ich weiß, daß es CPUs mit mehreren Kernen gibt. Sind das DOS-PCs? Nein. Und selbst wenn: Das schonmal selbst programmiert? Selbst auf den sogenannten "modernen" PCs wird die Lastverteilung auf die Kerne von den meisten Programmen dem OS überlassen.)

Weil nun aber alles nacheinander in einer Dauerschleife ausgeführt wird, wird es immer Verzögerungen geben. Man kann natürlich die Verzögerungen kurz halten, indem man immer kleine Puffer für alles benutzt: Klang, Grafil, Steuerung... - Also: Kleine Klangpuffer, bei Grafik vom Bild nur wenige Zeilen generieren, dann wieder raus... usw, damit man es "synchroner" bekommt. Allerdings muß jedes Unterprogramm ja wieder bei Aufruf einen gewissen "Init-Teil" durchlaufen und umso häufiger, je öfter es aufgerufen wird. Das macht es zwar insgesamt synchroner, aber auch insgesamt langsamer.

Um also z.B. die Generierung der Grafik (die meist wirklich der Pferdefuß an dem Ganzen ist, weil sie oft am längsten dauert und damit direkt die FPS des Spiels bestimmt) nicht mit der Soundgenerierung kollidieren zu lassen, ein Vorschlag:
(Mit "Kollidieren" meine ich: Inzwischen ist der Klangpuffer abgelaufen und es müßte eigentlich ein neuer generiert werden, aber die CPU ist immer noch gerade am Berechnen des nächsten Bilds der Grafik. )
Die Grafikgenerierung "stückelbar" machen. D.h. es wird nur ein Teil des Levels gezeichnet. Danach werden immer nur 8 Sprites, dann die nächsten 8... usw. gezeichnet und erst wenn das "Bild" fertig ist, wird umkopiert/umgeschaltet. Auf diese Art verbraucht die Grafikroutine in der Hauptschleife auch weniger Zeit. Aber: Das Ganze erkauft man sich eben dadurch, daß ein teilweises Zeichnen und immer wieder Neustarten/Initialisieren einer Routine nicht so effizient ist, als wenn man sie "durcharbeiten" ließe. Das Gesamtprogramm wird damit synchroner, aber noch langsamer.

D.h. bei schnellen Rechnern wird die Hauptschleife gegebenenfalls auch oft durchlaufen ohne daß eine der Subroutinen irgend etwas tun muß.

Frage dazu: Wenn bei Deinen Programmen der Soundpuffer voll ist und auf den neuen Puffer umgeschaltet wird, wo werden dann die neuen Klangdaten generiert? Gleich im IRQ oder wird ein Signalflag gesetzt und das Hauptprogramm ruft dazu etwas in der Hauptschleife auf, wenn das Signalflag da ist?
zatzen hat geschrieben:
DOSferatu hat geschrieben:Man braucht nur so oft Kollisionsabfragen machen, wie sich im Spiel etwas "bewegt". Wenn jede Figur 20 Schritte pro Sekunde macht, passiert zwischen den Schritten ja nichts. D.h. das Verhältnis der Figuren zueinander ändert sich ja nur wenn sie sich bewegen und nur dann ist der "Kollisionszustand" wieder anders.
Ich denke noch immer so wie früher, dass ich z.B. abprallen einer Wand mit Pixelabfrage überprüfe. Wenn sich nun wegen relativ geringer Framerate die Figuren mal schneller als mit 1 Pixel/Frame bewegen dachte ich, ich müsste das intern interpolieren.
Naja, wie Du ja auch schon festgestellt hast, kann man die Steuerung der Figuren auch mit einer höheren Rate anstellen als die FPS der Bildanzeige es erlauben. Wenn ich ein Spiel mit 50 Steps/Sekunde mache, werden die immer gemacht, egal ob die Grafik nur 10 FPS schafft.
Außerdem interpoliere ich sowieso immer (seit Xpyderz). In früheren Spielen habe ich Depp da immer irgendwelche komischen anderen Tricks gemacht, weil eine Figur ja nicht immer mit 50 Pixeln oder mehr pro Sekunde rennt/fliegt.

Heutzutage benutze ich dafür einfach "Nachkommastellen", die bei der Grafikanzeige nicht mit abgefragt werden, sondern für die Steuerung da sind. Bei Xpyderz sind es z.B. 3 Nachkommabits. Die Koordinaten waren 16bit, mit Vorzeichen, also -32768 bis 32767. Ein Level kann maximal 128x128 Blocks groß sein, ein Block hat 32x32 Pixel. Somit ist das obere Byte gleich der Block, das untere Byte sind die Pixel innerhalb des Blocks (obere 5 bit) und die "Nachkommabits" (untere 3 Bit).

Das erlaubt es, auch bei schrägen Bewegungen die (fast) gleiche Geschwindigkeit zu haben. Wenn man geradeaus mit 1 Pixel pro Step fährt, muß man ja bei 45°-Richtung (Xpyderz ist ja in "Draufsicht") in jede der Richtungen mit ca. 0,707 Pixeln pro Step fahren, damit es gleich schnell ist - also sin(45°) bzw. Wurzel(2)/2. (Dafür habe ich natürlich eine Sinustabelle für meine 256 möglichen Drehwinkel, Ich rechne ja nicht "live" Sinuswerte aus - bin ja nicht bescheuert...)

Das neue System (GameSys2) ist da noch etwas "genauer" und flexibler:
a) Es hat immer 8 Nachkommabits. (Kann man benutzen, muß man nicht. Wenn nicht, sind schräge/kreisförmige/Sprung- Bewegungen eben nicht genau und man muß langsame Bewegungen irgendwie anders lösen.)
b) Es hat immer 16 Vorkommabits. Somit wären Levels mit maximal 65536*65536 Pixeln möglich.
c) Es wird natürlich von "block"/"kachel" basierten Levels ausgegangen, d.h. von Levels, die intern aus quadratischen Einzelteilen bestehen. ("Vollbildgrafik"-Levels sind einfach Schwachsinn und nur geeignet, wenn kein Scrolling passiert. Sie brauchen abartig viel Speicher und sind außerdem unflexibel.) Hier ist in 2er-Potenzen einstellbar, wie groß die Kacheln in Pixeln sind, z.B. 4 für 16x16-Pixel Blocks oder 5 für 32x32-Pixel-Blocks.

Der Steuerroutine könnte so etwas eigentlich egal sein - aber weil bei der Steuerung auch gleich Kollisionsabfragen mit unterstützt werden und weil diese nicht nur für Figur-zu-Figur, sondern auch für Figur-zu-Level passieren, müssen gewisse Eckdaten über die Beschaffenheit des angezeigten Levels auch der Steuerroutine bekannt sein.

Erklärung dazu: Man kann theoretisch "Bonusgegenstände" nicht nur als Sprites darstellen, sondern auch als Level-Elemente. Außerdem können "Türen" und ähnliches Teil des Levels sein und eine Figzr muß darauf reagieren können. Das Wichtigste sind aber wohl die "blockierenden"/"nicht blockierenden" Elemente eines Levels. D.h. was ist eine Wand und wo kann man durchlaufen. Bzw: Ist das eine Plattform, auf der man stehen kann oder ist unter der Figur ein "frei" Block, und die Figur fällt herunter? Desweiteren kann man auch so Elemente wie irgendwelche Spitzen/Stacheln/Wasser/Säure usw. direkt als Levelelement darstellen und die Figur kann darauf mit Verlust von Hitpoints reagieren (oder Sudden Death...)

Natürlich ginge technisch gesehen auch hier wieder eine pixelgenaue Abfrage - aber welcher Spieler kann/will schon pixelgenau steuern? Und wenn man sowieso schon mit Rechenpower und Speicher aufpassen muß, muß dann so etwas wirklich auch noch sein?

GameSys2 enthält hat dafür eine andere Methode:
Es werden maximal 256 verschiedene Blocks/Kacheln pro Level erlaubt. Zu jeder Kachelart kann man jetzt noch einen 16bit und einen 8bit Wert definieren, d.h. je 256 Werte. Diese werden "gedacht" intern über eine Kachel gelegt, wenn eine Kollisionsabfrage erfolgt und eine Kachel wird damit in 16 "Unterteile" aufgeteilt - die Größe dieser Unterteile hängt von der Größe der gesamten Kachel ab:

Das sind die 16 Bits aus dem einen Wert:
00 01 02 03
04 05 06 07
08 09 10 11
12 13 14 15

Bei einer 16x16-Pixel Kachel ("Block") steht also jedes Bit für 4x4 Pixel innerhalb der Kachel. Bei 32x32-Pixel-Kacheln entspricht ein Bit einem 8x8-Pixel-Bereich.
Nun kann dieses Bit also jeweils 0 oder 1 sein. Und da kommt der andere (der 8bit) Wert ins Spiel. Ist das Bit=0, ist das "Kollisionsergebnis" das untere Nybble des Bytes, ist das Bit=1, wird als "Kollisionsergebnis" das obere Nybble geliefert.
Somit kann eine Kachel also geteilt sein und auf zwei Arten reagieren. In meinem kleinen Demospiel "TGAME.EXE" was ich vor einiger Zeit, als es um GameSys2 ging, mal hochgeladen habe, sieht man das Ganze deutlich: Die kleinen Levelelemente reagieren nur an der Stelle, wo sie "nicht durchsichtig" sind.

Nun gäbe es noch die Möglichkeit einer pixelgenauen Erweiterung, die ich aber (noch) nicht eingebaut habe: Da man diese 16-Bit-Matrix invertieren kann und dazu dann beim 8-Bit Wert nur die Nybbles vertauschen muß, um am Ende auf dasselbe Kollisionsergebnis zu kommen, könnte man z.B. ein Bit der 16-Bit-Matrix definieren (z.B. das oberste, weil leicht abzufragen), um auf pixelgenaue Abfrage zu schalten. Dann wäre das unterste Byte der 16-Bit-Matrix eine Farbnummer, die "leer" entspricht und alle "Leer"-Pixel im Block würden mit dem unteren Nybble, alle anderen mit dem oberen Nybble gemeldet werden. Allerdings müßte man dann die Kollisionsabfrage wieder zusätzlich mit den Levelkachel(grafik)daten vernetzen, was sie weniger flexibel machen würde, weil man dann bei den Kachelgrafikdaten wieder auf bestimmte Formate beschränkt wäre, die die Kollisionsabfrage alle kennen müßte (und bei den Abfragen wieder Segmentwechsel aufs Kacheldatensegment, evtl. auf Farbtabellen.... usw.)

Wieso ich nur mit 16 Kollisionswerten arbeite? Nun, es gibt ja 256 Kacheln, aber ich will ja nicht für jede Kacheln einzeln wissen müssen, wie diese reagiert. Dann bekommen also alle "Wand"-Kacheln einen Wert, alle "tödlich"-Kacheln einen Wert (bzw eigentlich immer zwei 4-Bit-Werte, wovon der eine ja meist für die "durchsichtigen" Teile ist), einen Wert für Türen usw... Man wird feststellen, daß man mehr als 16 Werte gar nicht braucht, um den "Typ" der Kacheln festzulegen.

Die Figuren haben etwas ähnliches. Es gibt 255 unterschiedliche Figuren (natürlich können von einer Figur mehrere dargestellt werden) und jede dieser Figuren hat auch einen 4-Bit-Typ.

Bei der Kollisionsabfrage kann man nun mit einem 16-Bit Wert angeben, welche Typen abgefragt werden sollen. D.h. es werden dann nur Kollisionen abgefragt, die zum Typ passen. Wenn es Elemente gibt, die auf eine Figur gar keinen Effekt hätten, muß deren Typ also gar nicht mit abgefragt werden, das Bit im o.g. 16-Bit Wert läßt man dann 0 - somit entfällt eine interne aufwendige Kollisionsabfrage und es entfällt auch ein Programmteil, der darauf reagieren müßte (indem er nichts tut).

So sieht für mich intelligente Programmierung aus. (Die Kollisionsmatrix, die selbst in riesigen Leveln die theoretische Kollision von "alles mit allem" erlaubt, und deren Vorstufe ich in Xpyderz benutzt habe, das bis zu 1600 freibewegliche Elemente haben kann, wurde für GameSys2 nochmals entscheidend verbessert/erweitert, u.a. mit den o.g. Dingen.)

Ja, es ist viel Text. Ich will damit nur sagen: Natürlich kann man bei Kollisionsabfragen beliebig genau ins Detail gehen und ich bin mir auch darüber bewußt, daß man hier immer genauer werden kann. Wenn man bei Xpyderz schräg auf die Wände ballert und schon einen oder mehrere "Deflection" Boni eingesammelt hat, kann man sehen, daß das schon recht genau gemacht ist und auch bei niedriger Framerate ändert sich daran nichts, d.h. die Projektile werden immer im korrekten Winkel von den Wänden zurückgeworfen.

ABER: Wenn man z.B. ein Jump'n'run oder ähnliches schreibt, wird kein Spieler böse sein, wenn nicht die Spielfigur sofort tot umfällt, sobald eine ihrer Haarspitzen von einem Geschoß oder einer Wand berührt wird. Selbst in 3D-Spielen werden übrigens fast nur Hitboxen (hier eben nicht 2D-Polygone, sondern einfache 3D-Körper) für Kollisionsabfragen benutzt, keiner ist da so bekloppt und fragt jede Subkoordinate einzeln ab...
zatzen hat geschrieben:
DOSferatu hat geschrieben:Bei so fotorealistischen 3D-Spielen mit lebensechtem Sound
Nein, das wird mir dann auch langweilig. Da geh ich lieber ins Kino und guck mir Star Wars an, da ist die CGI wenigstens richtig gut. 320x200x256 in 2D ist schon perfekt für mich, und ein bisschen rotziger Digisound dabei.
Ja, dagegen spricht Deine "Synchron-um-jeden-Preis" Einstellung. Bei dieser Art Spiele macht es überhaupt nichts, wenn der Klang nicht total synchron ist. Die Musik betrifft es ja sowieso nicht und die Klangeffekte wirken trotzdem noch. Die Grafik "hinkt" ja genauso hinterher wie der Sound, bei niedriger Framerate eigentlich sogar noch mehr als der Sound. Denn auch die Grafik kann ja erst generiert werden, wenn die Spielsituation klar ist und kann erst angezeigt werden, wenn sie fertig gezeichnet ist.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Naja, Du hattest da ja auch schon Ansätze erwähnt, die ohne Clipping auskämen, mit fixen Bildschirmen, wo man sich von Bildschirm zu Bildschirm bewegt.
Ja, Scrolling würde mir auch einfach zu viel Rechenleistung fressen. Das kann man auf nem Pentium machen, aber das ist dann fast schon wieder Windows-Niveau. Vielleicht hab ich mal die Geduld ZVID wenigstens auf blockweises Clipping zu erweitern, also dass am Rand dann alles in 8 Pixel Einheiten verschwindet. Ein kleiner Rahmen um den Screen und es wäre gut.
Ja, das Sprite-Clipping war für mich anfangs auch ein totaler "Pain-in-the-Ass". Da meine Sprites aber inzwischen mit einer ganz anderen "Logik" gezeichnet werden, hat sich das irgendwann von selbst erledigt. Natürlich sind meine Sprites dafür nicht so stark gepackt wie sie es vielleicht mit ZVID wären - dafür können meine Sprites aber auch skaliert, gezerrt, gespiegelt und vor allem gedreht werden - darauf würde ich ungern verzichten.
zatzen hat geschrieben:Grafik: Evtl. meine Schwester.
Kann Deine Schwester zeichnen? Oder arbeitet sie sogar mit Grafikprogrammen?
Anm.: Ich habe zwei Scanner hier. Einen Handscanner (monochrom, einstellbar auf "gerastert" für Halbtöne), alt, für DOS. Und einen Flachbettscanner (farbig), an USB anschließbar, für Windows.
Ich habe schon überlegt, Grafiken/Figuren auf Papier zu zeichnen zu scannen und dann im Malprogramm nur nachzubearbeiten. Da wäre ich ggf. schneller als mit Pixeln.
Andererseits lohnt sich das bei so niedrigen Auflösungen vielleicht gar nicht wirklich.
Da bin ich noch am Überlegen.

zatzen hat geschrieben:Aber ich muss erstmal ein Konzept haben. Ein kleines Problemchen ist noch dass es eben vertikal nur 200 Pixel sind, aber alle gängigen Grafikprogramme quadratische Pixel haben.
Naja, man muß hier nicht der totale Perfektionist sein. JA - die Pixel bei 320x200 sind nicht absolut quadratisch... sie sind 1,2 mal so hoch wie sie breit sind. Das kann natürlich etwas störend sein, aber wenn man einerseits mit so niedrigen Auflösungen und Anforderungen an die Grafik arbeitet und sich dann andererseits an "nicht ganz quadratischen" Pixeln stört... Das ist irgendwie Perfektionismus an der falschen Stelle.

Achja: Mein selbstgebautes Malprogramm hier (nur palettenbasiert! also max. 256 Farben, natürlich selbst wählbar) supportet Auflösungen: 320x200, 640x400, 640x480, 800x600, 1024x768 und 1280x1024. Die erste, zweite und letzte Auflösung haben nichtquadratische Pixel, d.h. wenn man darin zeichnet, sieht es dann da genauso aus wie später im Spiel. Unterstützte Grafikformate sind derzeit PCX und BMP, es können auch 24bit Grafiken geladen werden, die werden entsprechend angepaßt. Außerdem werden noch ein paar meiner eigenen einfachen Grafikformate unterstützt. Das Ganze ist natürlich ein totales "Computerfreak-Tool": Alles tastenbasiert, Mausunterstützung zwar rudimentär vorhanden (aber z.B. nicht für die Menüs)...
Damit mache ich seit Jahren/Jahrzehnten alle meine Grafiken, erweitere es auch immer mal wieder... Aber weil es eben so ein Freak-Tool ist, habe ich es noch nicht auf meine Webseite gestellt. Da kämen dann bloß wieder Leute angelaufen, die sich zu fein sind, das so zu nutzen wie es ist und wollen diese und jene Spezialfunktion und das Menüsystem windowsmäßiger und ähnlichen Mist... - und mir gefällt das Ding genau so wie es ist - und es gibt viel zu wenige Freak-Programme und viel zu viel total überkandideltes Zeug in der Richtung. Achja, für alles außer 320x200 (da kann es vier Seiten darstellen) braucht es natürlich VESA und es kann natürlich nur die Grafikmodi unterstützen, die VESA auch anbietet. (Hinweis: Auch DOSbox supportet VESA und mein Malprogramm läuft auch in DOSbox.) Das Malprogramm unterstützt zwar mehrere "Bilder", aber nutzt als Bildpuffer direkt den Grafikspeicher selbst, d.h. es kann pro Grafikmodus nur so viele Bilder haben, wie es der Grafikspeicher hergibt, Und bei 320x200 sind es immer nur 4 Bilder, weil es dafür den Mode-X benutzt.
Alle komischen Features die das Ding insgesamt hat zu erklären würde hier den Rahmen bei weitem sprengen - und es ist immer noch unfertig und wird auch nie fertig werden.
Ich wollte das nur erwähnen - es gäbe also durchaus eine Möglichkeit, ein Grafikprogramm für 320x200 Auflösung zu nutzen.
zatzen hat geschrieben:Niedrige Auflösungen: 320x200 ist mein absoluter Standard. Und da drin dann eben auch kleine Sprites. Also vielleicht 12x16 Pixel. Oder meinetwegen auch 16x24, dann passt es besser mit ZVID...
Naja, je niedriger die Auflösung, umso kleiner sind natürlich auch die Sprites. Ein 200x200 Pixel Sprite wirkt in 1024x768 nunmal ganz anders als in 320x200.

So, jetzt habe ich wieder einen überlangen, wahrscheinlich zu 80% nutzlosen Text geschrieben. Ob das überhaupt irgendwer liest?

Achja, ein Hinweis:
Im Thread "Warum keine aktuellen DOS-Spiele?" oder so ähnlich hat Wobo eine sehr gute Antwort dazu geschrieben, die auch zu dem paßt, was ich auch immer sage:
Konsolen/alte 8bit-Rechner sind nicht zu vergleichen mit PCs. Eine monolithische Maschine mit absolut identischen Parametern kann ganz anders programmiert werden als ein PC mit seinen austauschbaren Komponenten. Und ja, es ist wirklich so: Auch wenn ein PC eine VGA enthält, so ist es ein Unterschied, WELCHE VGA und in welchem Slot (ISA, VLB, PCI) sie steckt und der Unterschied im Datendurchsatz von mindestens Faktor 10 ist eine sehr realistische Einschätzung.

Mein erster 486er (66 MHz) hatte immer noch die gleiche VGA (ISA) drin, die ich auch im 286er davor hatte. Ich hatte dafür so ein Test-Tool. Und in der "besten" (also niedrigsten) Auflösung 320x200 hatte die einen Durchsatz von 0,5 MB pro Sekunde. Das heißt: Bei 10 FPS kann man da 50000 Pixel hinschieben (und dann nichts anderes mehr machen) oder weniger als 50000 Pixel schieben oder weniger als 10 FPS haben und dafür noch irgendwas anderes mit der CPU machen, (Und 320x200 hat schon 64000 Pixel.)

Und selbst bei PCI-Grafikkarten gibt es ja extreme Unterschiede im Chipsatz, die sind auch nicht alle gleich schnell.

Und eine 486er ist auch nicht das gleiche wie eine 486-X5. Und 33 MHz sind nunmal nur 1/4 von 133 MHz. Wer mit 133 MHz 10 FPS schafft, schafft also mit dem sonst gleichen Rechner bei 33 Mhz 2,5 FPS. Und ein 386er mit 33 MHz ist nur halb so schnell wie ein 486er mit 33 MHz - klingt komisch, ist aber so.
Der Chipsatz des Motherboards spielt auch noch in dem Spiel mit - hat einen nicht unerheblichen Einfluß auf den Speicherzugriff. Und ein Rechner mit 100 MHz kann unter Umständen langsamer sein als einer mit 80 MHz. Weil der mit 80 MHz vielleicht einen mit 40 MHz getakteten Bus hat und der mit 100 MHz hat einen 33 MHz-Bus.... und so weiter.

Soviel dazu, falls man denkt: DOS-Rechner = CPU+VGA+SB = Monolithische Kiste mit etwa gleichen Werten. x86-PCs sind sowas von nicht-monolithisch, die könnten als Beispiel für Unterschiedlichkeit im Lexikon abgebildet sein. Selbst 486er ist nicht gleich 486er.

Und genau deshalb (und nicht um zu nerven oder so) meine ganzen Anmerkungen zu möglichst variablem Einsatz von Unterprogrammen und möglichst "äußerem" Timing, das sich nicht auf die Geschwindigkeit irgendeines Bauteils im PC verläßt. Und auch genau deshalb meine Anmerkungen dazu, daß Synchronität schon auf einem DOS-Rechner nicht erreicht werden kann, sondern man sich ihr nur annähern kann. (Unter Multitasking-Rechnern wäre das erst recht nicht möglich, da geht quasi gar nichts "in Echtzeit", weil man jederzeit mit Unterbrechung durch andere Prozesse zu rechnen hat.)

Aber inzwischen habe ich verstanden, wie und wieso Du auf diese Ideen kommst - weil Du von Videos ausgehst. Bei interaktiven Spielen ist aber eine komplett andere Herangehensweise als bei Videos nötig.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Fr 24. Aug 2018, 19:14
von zatzen
Doppelpost - gelöscht

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Fr 24. Aug 2018, 19:16
von zatzen
Hallo DOSferatu!

Ersteinmal zum vorherigen Post, den anderen werde ich mir ausdrucken und ganz in Ruhe lesen:

In X-Tracker ist die ESC-Taste damit belegt, dass alle gerade klingenden Töne gestoppt werden.
Weiss ich gerade nicht ob das bei AtavISM auch so ist, aber es ist ein wichtiges Feature.
DOSferatu hat geschrieben:Aha... Zynisch... Naja, ich habe, basierend auf ISM, einen weiteren Namen gesucht, der maximal 8 Zeichen hat. Mir erschien der Name passend.
Wikipedia: "Ein Atavismus (von lateinisch atavus ‚Urahn‘[2]), veraltet auch Rückschlag, ist das Wiederauftreten von anatomischen Merkmalen bei einem Lebewesen, die bei entfernteren stammesgeschichtlichen Vorfahren ausgebildet waren, bei den unmittelbaren Vorfahren jedoch reduziert wurden, da sie für die gegenwärtige Entwicklungsstufe keinerlei Funktion mehr besitzen.[2] Häufig werden Atavismen daher als Missbildung wahrgenommen."

Keinerlei Funktion, Missbildung. Das hätte ich als zynisch verstanden, zumal ISM ja bewusst eigentlich
ein nicht-Tracker System ist.
DOSferatu hat geschrieben:Mache ich vielleicht mit Strg+T aufrufbar. Sollen diese a) für jede Spur einzeln gelten, b) für jedes Pattern einzeln gelten oder c) immer nur ein einzelner Wert (für das ganze Stück geltend)? Soll der Wert in's Initfile gespeichert werden?
Soll die Anzahl Zeilen sowohl bei Eingabe einer Note als auch bei Eingabe einer "Leernote" (also Backspace) übersprungen werden?
Hinweis: Die untere Zeile im Sequenzer-Fenster enthält überall Achten (8).
Die können natürlich geändert werden. Die sind ein "Divisor" für 128. D.h. alles ist auf Sechzehntel eingestellt (128/8 = 16), d.h. eine Sechzehntel Note pro Zeile. Wenn man da z.B. 32 eingibt, dann ist jede Zeile eine Viertelnote (128/32 = 4). Das kann für jedes Pattern einzeln gemacht werden.
Bei X-Tracker gilt die Quantisierung global, wird aber nicht gespeichert. Es ist ja kein Ding das schnell einzustellen
(bei X-Tracker geht das mit F4), ich hab es meistens auf 2 stehen, weil... und da kommen wir zum nächsten Punkt:
Wieviel Zeilen welche Notenlänge ergeben, ist bei X-Tracker pro Pattern über "Ticks per Beat" konfigurierbar,
wobei Tick = Zeile ist, und "Beat" einer Viertelnote entspricht. Ich hab das meistens auf 8 stehen und meine
Patterns sind 128 Zeilen lang, also habe ich pro Pattern 16 Beats = 16 Viertelnoten und somit 4 ganze Takte.
Ich stelle die Quantisierung auf 2, dann sind es sechzehntel, nur selten mache ich mal 32tel, vielleicht mal
bei Hihats eine dazwischen oder mal nen Träller. Wichtig ist noch, dass wenn Quantisiert wird, man trotzdem
in die "Zwischenräume" kann und von dort aus gestartet mit dem Quantize-Wert in den Zeilen weitergehen kann.
Praktisch sind Quantisierungen von 8 z.B. wenn man eine simple Bassdrum-Spur hat, dann geht man nur
an den Pattern-Anfang (Pos1-Taste, Ende Taste fürs Pattern Ende, sehr wichtige Funktionen auf die ich nicht
verzichten möchte) und drückt ein paar mal z.B. auf Y.
Patterns zu haben mit 32teln pro Zeile ist meistens etwas "luftig", weil man meistens nur 16tel braucht.
Viele MODs haben 16tel pro Zeile und nutzen für 32tel bei Schlagzeug einen Retrigger-Effekt, der ein
Sample zweimal pro Zeile anschlägt.
Aber ich glaube aufgrund der unterliegenden Datenstruktur von ISM macht es kaum einen Unterschied
ob man in atavISM mit 4 oder 8 Zeilen pro Viertelnote arbeitet.
DOSferatu hat geschrieben:Verständlich. Macht auch Sinn. Ich habe aber Einfg/Entf mit umfangreichen Tastenkombis belegt, um zu kopieren/verschieben/löschen usw. Ginge hier auch stattdessen die Backspace-Taste?
Damit könnte ich mich anfreunden, allerdings ist Backspace in X-Tracker belegt mit Alle Effekte (ink. Volume)
löschen und eine Zeile weiterspringen (unabhängig von Quantize), die "nackte" Note bleibt stehen.
DOSferatu hat geschrieben:
zatzen hat geschrieben:(- Wechseln der Spur geschieht durch einmaliges Drücken von <- bzw. ->
Geht derzeit in AtavISM mit Strg+ <- bzw. -> (oder eben TAB/Shift+TAB)
Müsste man sich dran gewöhnen, im Moment schätze ich es sehr dass man ein sehr intuitives
Gefühl hat die Spuren zu wechseln, und dass umgekehrt die Effekte gewissermaßen abgesichert
sind, weil man sie nur über ein PopUp (über TAB) erreicht, vom Laustärkebefehl mal abgesehen.

Transponieren: Das geht in X-Tracker nur "offline", man markiert einen Block und wählt dann
über ein Menü aus wieviele Halbtöne höher oder tiefer man den Bereich haben will.
DOSferatu hat geschrieben:Wie gesagt (siehe oben) ALT ist belegt. Ginge hier auch Strg+V?
Alt: Bei X-Tracker wird das Kopfmenü durch F10 aktiviert. Ich will Dein Programm nicht umwälzen,
wie könnte ich mir das rausnehmen, aber nur so als Gedanke, dann hätten wir Alt frei.
Aber ich glaube Du hast auch direkte Shortcuts mit Alt, das geht natürlich mit F10 nicht.
Strg+V würde aber natürlich auch gehen für Lautstärke.

Makros:
DOSferatu hat geschrieben:Sind das einfach gespeicherte "Befehls"-Sequenzen (die dann einkopiert werden)? Wie werden diese gespeichert/aufgerufen? Mit einer/mehreren Tastenkombinationen? Aus einem Menü?
Es sind tatsählich Effekte inkl. Lautstärke. X-Tracker hat 3 Effektkategorien die man parallel nutzen kann und den
Lautstärkebefehl, also 4 mögliche Befehle pro Makro. Diese Makros kann man auf die Tastenkombinationen
Alt+1 bis 9 bzw. 0 legen. Tatsächlich benutzt habe ich in der Vergangenheit aber nur Panning, drei verschiedene,
links mitte rechts, weil ich das oft brauchte. In letzter Zeit benutze ich das gar nicht mehr.
Ich erwähne aber noch eine Tasten-Kombi die ich schon eher häufig benutze:
Alt+W. Wiederholt den letzten Lautstärke-Befehl, egal auf welchem Kanal.

In X-Tracker markiert man mit F7 den Startpunkt und mit F8 den Endpunkt, das geht auch über
mehrere Kanäle. Wollte ich nur der Vollständigkeit halber erwähnen, alles Gewöhnungssache.

DOSferatu hat geschrieben:Kommst Du bei variabel einstellbarer Soundrate dann überhaupt mit dem Timing hin? Bei 11 kHz im Vergleich zu 44 kHz kommt der IRQ für "Puffer zu Ende" ja erst nach der vierfachen Zeit. Oder machst Du dann einfach den Puffer kleiner?
Ja, ich mach den Puffer kleiner. Deswegen halte ich den auch möglichst auf irgendeiner durch ein vielfaches von
zwei teilbaren Größe.

Ich hatte 1997 schon einen Pentium 200 MMX mit CD-Brenner.
Zu der Zeit habe ich dann meinen Renderer für X-Tracker Module geschrieben.
Der kann beliebig große 16 Bit Samples verwerten, die ich mir mit einem weiteren
Programm in die DMFs reingesetzt habe, d.h. die vorliegenden 8 Bit Samples
mit größtenteils niedriger Samplerate durch hochqualitative Kopien ersetzt.
Dem Renderer ging noch einer vor den ich in QBASIC programmiert habe, noch
zu Zeiten des 486ers.
Naja, den 1997er Renderer benutze ich bis heute. Es war ziemlich aufwendig
die ganzen Effekte richtigklingend zu implementieren. Die Interpolation
ist nur linear, aber damit ein ganz guter Kompromiss zwischen Kosinus-Interpolation
bei der niedrige Sampleraten oft dumpf klingen, und gar keiner Interpolation
wo es dann so klingt wie auf dem Amiga.
Ich hatte schonmal angefangen mit Freepascal eine 32 Bit Version von dem
Renderer zu programmieren, denn der DOS-Renderer liest die Samples
von der Festplatte (zum Glück gibt es Cache) und hält sie nicht im Speicher,
was langsam ist, und nochmals langsamer ist weil das ganze auf meinem
Rechner nur in Dosbox läuft.
Aber die Zeit, die paar Stunden für ein ausproduziertes Musikstück,
habe ich meistens, weshalb ich mich nicht so motiviert fühle die Freepascal
Version zu machen.


486er Befehle: In meinem Assembler-Buch stehen so wenige drin, und die
ergaben für mich auch keinen sinnvollen Anwendungszweck.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 25. Aug 2018, 10:06
von DOSferatu
zatzen hat geschrieben:Hallo DOSferatu!
Hallo zatzen!

(Hinweis: Es gibt eine "Vorschau" Funktion, dann braucht man's nicht doppelt posten... Und die zwei kleinen Schreibfehler hättest sowieso ruhig drinlassen können, das wäre nicht so schlimm gewesen.)
zatzen hat geschrieben:Ersteinmal zum vorherigen Post, den anderen werde ich mir ausdrucken und ganz in Ruhe lesen:
Ahja. Zu kompliziert? Wie ich schon mal erwähnte: Ich will Dich eigentlich nicht nerven oder so.
zatzen hat geschrieben:In X-Tracker ist die ESC-Taste damit belegt, dass alle gerade klingenden Töne gestoppt werden. Weiss ich gerade nicht ob das bei AtavISM auch so ist, aber es ist ein wichtiges Feature.
Naja, ich weiß nicht, wie es bei X-Tracker ist. In prISM und AtavISM hört man NICHTS, während man die Töne eingibt - sondern erst, wenn man das Stück abspielt. Und wenn man das Stück abspielt, kann man es ja mit vielen Tasten stoppen, unter anderem mit ESC. Und wenn ein abgespieltes Stück gestoppt ist, klingt auch nicht noch irgendeine "Loop-Schleife" nach - naja, außer wenn das Programm abstürzen würde und die Soundblaster gerade am Abspielen wäre, nehme ich an.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Aha... Zynisch... Naja, ich habe, basierend auf ISM, einen weiteren Namen gesucht, der maximal 8 Zeichen hat. Mir erschien der Name passend.
Wikipedia: "Ein Atavismus (von lateinisch atavus ‚Urahn‘[2]), veraltet auch Rückschlag, ist das Wiederauftreten von anatomischen Merkmalen bei einem Lebewesen, die bei entfernteren stammesgeschichtlichen Vorfahren ausgebildet waren, bei den unmittelbaren Vorfahren jedoch reduziert wurden, da sie für die gegenwärtige Entwicklungsstufe keinerlei Funktion mehr besitzen.[2] Häufig werden Atavismen daher als Missbildung wahrgenommen."
Ich habe hier die Übersetzungsvariante Rückschritt/Rückschlag gemeint. AtavISM ist eine Rückentwicklung gegenüber prISM, weil mindestens 60%-70% von dem, was ISM eigentlich kann, in AtavISM nicht berücksichtigt werden kann und man stattdessen auf Blöcke mit fester Länge und repetativer Eingabe reduziert ist. Die Variante mit dem internen ISM-Codecontainer ist quasi eine "Krücke", damit man in so gerasterter Art/Ansicht arbeiten kann - was für ISM in Wirklichkeit ja nicht nötig wäre und nur daran liegt, weil ein 30 Jahre altes und nicht optimales Format das einzige ist, was viele sich zum Musikmachen vorstellen können. Daher sowohl "Urahn" (weil erstes Format), als auch "Rückschritt".
zatzen hat geschrieben:Keinerlei Funktion, Missbildung. Das hätte ich als zynisch verstanden, zumal ISM ja bewusst eigentlich ein nicht-Tracker System ist.
Ja, und damit dem Tracker in seinen Fähigkeiten überlegen: Alles, was ISM von sich aus nicht schon kann, kann durch "ISM-Befehle" nachgebildet werden - sogar zusätzliche Effekte, die vielleicht noch niemand benutzt hat. Man kann jedes Stück Musik, egal ob es so groß wie ein Pattern oder z.B. nur 3 Noten lang ist, an jeder Stelle mit jedem Instrument/Sample in jeder Lautstärke spielen - ohne es extra nochmals eingeben zu müssen, usw.
Natürlich hat ISM auch entscheidende Nachteile: Die Klangqualität ist sehr reduziert, weil der Sound mit nur 4-Bit-Genauigkeit generiert wird, außerdem ist Stereo (noch) nicht eingebaut - aber das liegt weniger am Grundkonzept von ISM, sondern an der bewußten Entscheidung für "Minimalelektro"-Klänge, angelehnt an alte Konsolen. D.h. mit derselben "ISM-Sprache", aber erweitertem Programmcode könnte auch 16-Bit-Sound erzeugt werden. Aber daran habe ich kein Interesse.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Mache ich vielleicht mit Strg+T aufrufbar. Sollen diese a) für jede Spur einzeln gelten, b) für jedes Pattern einzeln gelten oder c) immer nur ein einzelner Wert (für das ganze Stück geltend)? Soll der Wert in's Initfile gespeichert werden?
Soll die Anzahl Zeilen sowohl bei Eingabe einer Note als auch bei Eingabe einer "Leernote" (also Backspace) übersprungen werden?
Hinweis: Die untere Zeile im Sequenzer-Fenster enthält überall Achten (8).
Die können natürlich geändert werden. Die sind ein "Divisor" für 128. D.h. alles ist auf Sechzehntel eingestellt (128/8 = 16), d.h. eine Sechzehntel Note pro Zeile. Wenn man da z.B. 32 eingibt, dann ist jede Zeile eine Viertelnote (128/32 = 4). Das kann für jedes Pattern einzeln gemacht werden.
Bei X-Tracker gilt die Quantisierung global, wird aber nicht gespeichert. Es ist ja kein Ding das schnell einzustellen (bei X-Tracker geht das mit F4),
F4 find ich gut. Die war bei mir sowieso noch frei und ich nutze sie derzeit in AtavISM nur, um das Instrument/Sample zu wählen und einzustellen. Mal sehen, ob ich das um ein Pulldown erweitere. Pulldowns gibt es in prISM/AtavISM ja sowieso, d.h. dafür muß ich nicht Extrafunktionalität einbauen.
zatzen hat geschrieben:ich hab es meistens auf 2 stehen, weil... und da kommen wir zum nächsten Punkt: Wieviel Zeilen welche Notenlänge ergeben, ist bei X-Tracker pro Pattern über "Ticks per Beat" konfigurierbar, wobei Tick = Zeile ist, und "Beat" einer Viertelnote entspricht. Ich hab das meistens auf 8 stehen und meine Patterns sind 128 Zeilen lang, also habe ich pro Pattern 16 Beats = 16 Viertelnoten und somit 4 ganze Takte.
Ich stelle die Quantisierung auf 2, dann sind es sechzehntel, nur selten mache ich mal 32tel, vielleicht mal bei Hihats eine dazwischen oder mal nen Träller. Wichtig ist noch, dass wenn Quantisiert wird, man trotzdem in die "Zwischenräume" kann und von dort aus gestartet mit dem Quantize-Wert in den Zeilen weitergehen kann.
Die Patterns von AtavISM sind nur 64 Zeilen lang, immer. (Das hat u.a. technische Gründe, die mit dem derzeitigen ISM-CodeContainer und dem internen "Interpreter" zusammenhängen.)
Man sollte das hier nicht verwechseln: Das ist keine unterschiedliche Anzeige, wo nur jede 2. oder jede 4. Zeile oder so angezeigt wird - es werden immer alle 64 Zeilen angezeigt. Der "Speed"-Wert im Sequenzer bestimmt nur, mit welcher Geschwindigkeit diese 64 Zeilen abgespielt werden. Eine Zeile ist dabei eine 1/128-Note, multipliziert (also dann eigentlich dividiert) mit dem Wert. Will sagen: Wert 1 = 1/128 Note, Wert 2=doppelt so lange, also 1/64 Note. Wert 8 sind also 8/128 Note, bzw. 1/16 Note. Wert 16 wären 16/128, also 1/8 (Achtelnote), 32 wäre VIertelnote usw.
Null bewirkt derzeit dasselbe wie 1, eine Geschwindigkeit von Reziproke von 0 habe ich nicht unterstützt, hatte die Befürchtung, daß sich dann Zeit und Raum krümmen...
zatzen hat geschrieben:Praktisch sind Quantisierungen von 8 z.B. wenn man eine simple Bassdrum-Spur hat, dann geht man nur an den Pattern-Anfang (Pos1-Taste, Ende Taste fürs Pattern Ende, sehr wichtige Funktionen auf die ich nicht verzichten möchte) und drückt ein paar mal z.B. auf Y.
Ja, die Funktion von Pos1/Ende kann man auch so legen. Derzeit ist das mit Strg+Pos1/Strg+Ende gelöst (weil Pos1/Ende an linke/rechte Seite der Spur/Track springen - was aber bei der alternativen Eingabe nicht nötig sein sollte)
zatzen hat geschrieben:Patterns zu haben mit 32teln pro Zeile ist meistens etwas "luftig", weil man meistens nur 16tel braucht. Viele MODs haben 16tel pro Zeile und nutzen für 32tel bei Schlagzeug einen Retrigger-Effekt, der ein Sample zweimal pro Zeile anschlägt.
Ja, das sind wieder so "von hinten durch die Brust ins Auge" Varianten, weil man auf ein starres Format beschränkt ist... Naja, wie Du ja weißt (und sicher auch schon gesehen hast, in dieser ganz rechten Spalte, die den ISM-Code vereinfacht darstellt), machen die Abstände in den Patterns nichts aus, weil der Note bei größerem Abstand einfach automatisch ein größerer Längenparameter zugewiesen wird.
zatzen hat geschrieben:Aber ich glaube aufgrund der unterliegenden Datenstruktur von ISM macht es kaum einen Unterschied ob man in atavISM mit 4 oder 8 Zeilen pro Viertelnote arbeitet.
Stimmt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Verständlich. Macht auch Sinn. Ich habe aber Einfg/Entf mit umfangreichen Tastenkombis belegt, um zu kopieren/verschieben/löschen usw. Ginge hier auch stattdessen die Backspace-Taste?
Damit könnte ich mich anfreunden, allerdings ist Backspace in X-Tracker belegt mit Alle Effekte (ink. Volume) löschen und eine Zeile weiterspringen (unabhängig von Quantize), die "nackte" Note bleibt stehen.
Ja, ich werde wohl nicht komplett alles 1:1 wie in X-Tracker umsetzen können - ODER ich verzichte auf die praktischen Möglichkeiten der Ins/Del-Kombinationen, die Kopieren/Verschieben/Löschen usw. ohne nötigen Menüaufruf aktivieren und dann muß man das im "X-Tracker-Mode" eben immer aus dem Modify-Menü anwählen.
zatzen hat geschrieben:
DOSferatu hat geschrieben:
zatzen hat geschrieben:(- Wechseln der Spur geschieht durch einmaliges Drücken von <- bzw. ->
Geht derzeit in AtavISM mit Strg+ <- bzw. -> (oder eben TAB/Shift+TAB)
Müsste man sich dran gewöhnen, im Moment schätze ich es sehr dass man ein sehr intuitives
Gefühl hat die Spuren zu wechseln, und dass umgekehrt die Effekte gewissermaßen abgesichert
sind, weil man sie nur über ein PopUp (über TAB) erreicht, vom Laustärkebefehl mal abgesehen.
Ja, auch hier: Genau wie bei Pos1/Ende: Wenn man sowieso im "X-Tracker-Mode" immer auf der mitteltsten (Noten-)spalte bleibt und der Rest ausschließlich per Menüs/Pulldowns angewählt wird, werden <-/-> frei und man kann sie auch ohne Strg zum Spurwechsel nutzen.
zatzen hat geschrieben:Transponieren: Das geht in X-Tracker nur "offline", man markiert einen Block und wählt dann über ein Menü aus wieviele Halbtöne höher oder tiefer man den Bereich haben will.
Ja, kein Problem. Das Transponieren ist in AtavISM sowieso etwas umständlich gelöst.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Wie gesagt (siehe oben) ALT ist belegt. Ginge hier auch Strg+V?
Alt: Bei X-Tracker wird das Kopfmenü durch F10 aktiviert. Ich will Dein Programm nicht umwälzen, wie könnte ich mir das rausnehmen, aber nur so als Gedanke, dann hätten wir Alt frei. Aber ich glaube Du hast auch direkte Shortcuts mit Alt, das geht natürlich mit F10 nicht.
Selbstverständlich ginge das theoretisch auch mit F10 (schließlich würde ich da sowieso "direkte" Tastenabfrage machen), aber F10 als "Umschalttaste" fände ich crazy.
Naja, Alt+F, Alt+V. Alt+M, Alt+D... usw aktivieren ja die Pulldowns des "Kopfmenüs", Alt alleine zeigt es nur schonmal an, damit man sieht, was man da aktiviert. Das wird eben nicht die ganze Zeit eingeblendet, damit oben Platz ist für ein paar andere Anzeigen.
zatzen hat geschrieben:Strg+V würde aber natürlich auch gehen für Lautstärke.
Oh - ein Kompromiß. Daß ich das noch erleben kann...
zatzen hat geschrieben:Makros:
DOSferatu hat geschrieben:Sind das einfach gespeicherte "Befehls"-Sequenzen (die dann einkopiert werden)? Wie werden diese gespeichert/aufgerufen? Mit einer/mehreren Tastenkombinationen? Aus einem Menü?
Es sind tatsählich Effekte inkl. Lautstärke. X-Tracker hat 3 Effektkategorien die man parallel nutzen kann und den Lautstärkebefehl, also 4 mögliche Befehle pro Makro. Diese Makros kann man auf die Tastenkombinationen Alt+1 bis 9 bzw. 0 legen.
Wäre technisch möglich - allerdings gibt's ja kaum Effekte in AtavISM. Die einzig nennenswerten sind Release, Mute und Portamento und die kann man auch mit Tasten abbilden.
zatzen hat geschrieben:Tatsächlich benutzt habe ich in der Vergangenheit aber nur Panning, drei verschiedene,links mitte rechts, weil ich das oft brauchte. In letzter Zeit benutze ich das gar nicht mehr.
Panning wird in ISM (derzeit noch nicht in AtavISM) angezeigt - allerdings noch nicht supportet. D.h. ISM ist zwar darauf "vorbereitet", daß so etwas mal kommen könnte - allerdings unterstützt es ja (noch) kein Stereo und wer weiß ob ich das jemals einbaue und ohne Stereo macht Panning ja keinen Sinn...
zatzen hat geschrieben:Ich erwähne aber noch eine Tasten-Kombi die ich schon eher häufig benutze:
Alt+W. Wiederholt den letzten Lautstärke-Befehl, egal auf welchem Kanal.
Auch hier wieder... Technisch möglich, müßte dann aber wohl eine andere Taste werden.
Strg+R, Strg+S und Strg+W sind belegt, um das "Interface" anzuzeigen/benutzen.
Könnte das natürlich auch in AtavISM ausschalten, weil die entsprechenden ISM-Befehle da sowieso nicht benutzt werden.
zatzen hat geschrieben:In X-Tracker markiert man mit F7 den Startpunkt und mit F8 den Endpunkt, das geht auch über mehrere Kanäle. Wollte ich nur der Vollständigkeit halber erwähnen, alles Gewöhnungssache.
Was meinst Du mit Start- und Endpunkt?
Startpunkt ist bei mir das erste Pattern im Sequenzer, Endpunkt das letzte Pattern. Wenn man will, daß sich nach dem Endpunkt etwas von vorn (oder von irgendeinem Pattern in der Mitte) wiederholt, kann man das im Sequenzer einstellen untere Zeile, 2. Wert von links, über "RepSq":
0=keine Wiederholung, 1-64 (hex. 1-40) ist die Position im Sequenzer, ab wo wiederholt wird.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Kommst Du bei variabel einstellbarer Soundrate dann überhaupt mit dem Timing hin? Bei 11 kHz im Vergleich zu 44 kHz kommt der IRQ für "Puffer zu Ende" ja erst nach der vierfachen Zeit. Oder machst Du dann einfach den Puffer kleiner?
Ja, ich mach den Puffer kleiner. Deswegen halte ich den auch möglichst auf irgendeiner durch ein vielfaches von zwei teilbaren Größe.
Ich neige bei allem größeren (Puffer, Tabelle, usw.), was im Speicher liegt, sowieso dazu, es auf /16 teilbare Größe zu stellen und auf /16 teilbare Positionen zu lesen. Wieso, kann man sich ja leicht denken...
zatzen hat geschrieben:Ich hatte 1997 schon einen Pentium 200 MMX mit CD-Brenner.
Zu der Zeit habe ich dann meinen Renderer für X-Tracker Module geschrieben. [...]
Du meinst, ein Programm, das aus einem X-Tracker-MODfile ein WAV macht?

zatzen hat geschrieben:486er Befehle: In meinem Assembler-Buch stehen so wenige drin, und die ergaben für mich auch keinen sinnvollen Anwendungszweck.
Ja, sind einige, die sehr "speziell" sind und an manchen Stellen vielleicht ein wenig Platz und ein paar Zyklen sparen würden. Aber nur dafür alleine werd ich die nicht einsetzen (und dann dafür keine 386er-Funktionalität mehr haben). Solange Assemblerbefehle außerhalb von Schleifen stehen, sollte man zwar trotzdem immer effizient programmieren, aber da fällt ein Zyklus mehr nicht so sehr ins Gewicht wie wenn die Befehle innerhalb einer Schleife stehen (wo die benötigten CPU-Zyklen mit der Anzahl Schleifendurchläufe multipliziert werden).

Dazu fällt mir noch ein schönes Rechenbeispiel zum Nachdenken ein:
D.h. z.B. bei einem 486er mit 100MHz, wenn eine Befehlssequenz innerhalb einer Schleife EINEN Zyklus mehr braucht und die Schleife wird 10000mal durchlaufen, dann braucht die CPU 0,1 Millisekunden länger. Es gibt keine 10000er oder größere Schleifen? 320x200 sind 64000... also: Eine Schleife die 0,64 Millisekunden langsamer ist als vorher - klingt pillepalle? Klar, schon. Der MCGA-Mode (320x200x256) läuft auf einem CRT mit 70Hz, d.h. ein Bildaufbau braucht knapp 14,3 Millisekunden - in denen alles andere inklusive der Berechnung des nächsten Bilds erledigt sein muß, wenn es nicht ruckeln soll. diese 14,3 Millisekunden, genauer: 1428571 Zyklen (ABZÜGLICH denen, die durch zwischenzeitliche Aufrufe irgendwelcher IRQs - Timer, Soundblaster, Keyboard- verlorengehen!) hat man zwischen zwei Bildern Zeit, alles andere zu erledigen - WENN es ein 100MHz Rechner ist. Und nicht jeder Befehl braucht nur 1 Zyklus, selbst auf 486ern nicht.
Und übrigens sind Zugriffe auf den Grafikspeicher vergleichsweise ziemlich langsam - selbst bei PCI. Schon alleine der Bustakt ist bei 100MHz ja nur 1/3 des CPU-Takts... Da klingen 1,4 Mio Takte plötzlich gar nicht mehr so viel...

Achja, was wobo auch in diesem "Warum so wenig aktuelle DOS-Spiele" Thread auch schon sagte: In DOSbox werden bei Zugriffen auf den Speicher (und vor allem auch Grafikkartenspeicher) nicht irgendwelche Verzögerungen durch den langsamen Bus oder den allgemein langsameren Zugriff auf Grafikkartenspeicher emuliert - d.h. es wird da genauso schnell ausgeführt als wäre es ein Zugriff auf ein CPU-Register... - was unrealistisch ist, dazu dient, daß DOSbox etwas mehr performt. Nur hat das den Nachteil, daß, wenn man DOSbox nicht nur zum Abspielen/Nutzen von DOS-Software nutzt, sondern zum (systemnahen) Programmieren, daß man dann nicht wirklich sehen kann, ob und wie das was man da macht, auf einem realen System performen würde. Gerade Grafikkartenzugriffe sind ein bekannter Hemmschuh - jedem (DOS-)Programmierer ist das leidlich bewußt.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 25. Aug 2018, 19:36
von zatzen
DOSferatu hat geschrieben:Es gibt eine "Vorschau" Funktion, dann braucht man's nicht doppelt posten...
Ja, ich hab diesmal irgendwie Mist gebaut. Bisher hatte ich nicht die Option "angemeldet bleiben" gesehen
und ich wurde daher bisher immer während ich schrieb ausgeloggt, musste meinen Text sichern und dann
wieder reinkopieren, ich schätze daher rührt der Doppelpost. Mal sehen ob ich ihn lösche.
DOSferatu hat geschrieben:Zu kompliziert? Wie ich schon mal erwähnte: Ich will Dich eigentlich nicht nerven oder so.
Nein, ich denke der Text ist aufschlussreich, von dem her was ich bisher überflogen habe.
Mir ist ja kürzlich erst das Problem bewusst geworden mit der Tatsache dass man bei meinem Vorgehen
die Auswirkungen seiner Steuerungen erst im übernächsten Frame sieht, was für mich nur okay wäre
wenn man die Framerate in Richtung 50 fps hochschrauben würde.
DOSferatu hat geschrieben:In prISM und AtavISM hört man NICHTS, während man die Töne eingibt
Das ist beim Eingeben der Noten natürlich ein wenig Tappen im Dunklen, wenig intuitiv.
Aber es ist wahrscheinlich mit ISM nicht ohne weiteres anders machbar.
DOSferatu hat geschrieben:F4 find ich gut. Die war bei mir sowieso noch frei und ich nutze sie derzeit in AtavISM nur, um das Instrument/Sample zu wählen und einzustellen. Mal sehen, ob ich das um ein Pulldown erweitere.
In X-Tracker wird die Sample-Liste durch einen Druck auf Enter eingeblendet. Dort kann man per Pfeiltasten
hoch/runter PgUp/Dn Pos1/End ein Sample auswählen und wenn man will dessen Parameter bearbeiten.
Außerdem kann man auch hier schon das Sample per Klaviaturtasten abspielen. Schlägt man eine andere
Note an, stoppt das bisherige und die neue Note spielt.
Bei manch anderen Trackern spielt das Sample so lange wie man die entsprechende Taste gedrückt
hält und man kann auch mehrere Tasten gleichzeitig drücken so dass eine Polyphonie entsteht.
Ich persönlich komme damit nicht so gut klar weil im Pattern selbst pro Track Monophonie gilt
und auch die Samples so lange klingen bis man sie per Befehl stoppt - ich finde es angenehmer
wenn ich um ein Sample klingen zu lassen nur die entsprechende Taste kurz anschlagen muss.
DOSferatu hat geschrieben:Die Patterns von AtavISM sind nur 64 Zeilen lang, immer.
MOD-Patterns sind auch immer 64 Zeilen lang, was aber sinnvoll wäre, wäre wenn man sie kürzen könnte
oder einen Break setzen könnte. Beispielsweise für einen Auftakt am Anfang eines Musikstücks der z.B. nur 8 Zeilen
lang ist.
DOSferatu hat geschrieben:Ja, ich werde wohl nicht komplett alles 1:1 wie in X-Tracker umsetzen können - ODER ich verzichte auf die praktischen Möglichkeiten der Ins/Del-Kombinationen, die Kopieren/Verschieben/Löschen usw. ohne nötigen Menüaufruf aktivieren und dann muß man das im "X-Tracker-Mode" eben immer aus dem Modify-Menü anwählen.
Bei X-Tracker funktioniert das Verschieben eines Blocks über Alt+M.
Willst Du Dir wirklich die Mühe machen, einen X-Tracker Mode zu implementieren?
Vielleicht schaffen wir es ja stattdessen, eine schlüssige allgemeine Bedienung herauszuarbeiten.
Ansonsten hätte ich natürlich auch nichts dagegen wenn es so einen Mode gäbe in dem ich intuitiv arbeiten kann.
Aber ich bin ja nicht der einzige User von AtavISM.
DOSferatu hat geschrieben:Was meinst Du mit Start- und Endpunkt?
Das ist, wie man in X-Tracker in einem Pattern Blöcke markiert.
F7 setzt den oberen linken Punkt, F8 den unteren rechten.
So markiert man ein Rechteck, was sich auf einen Kanal beschränken,
sich aber auch über mehrere nebeneinanderliegende Kanäle erstrecken kann.
DOSferatu hat geschrieben:Du meinst, ein Programm, das aus einem X-Tracker-MODfile ein WAV macht?
Ja, genau. Und das war wesentlich komplexer als mein ZSM-Player, wegen der ganzen Effekte die auch
Sinusfunktionen involvierten. Ich habe da ohne Tabellen gearbeitet, alles auf höchste Präzision ausgelegt,
und u.a. deshalb war an Echtzeit-Ausgabe nicht zu denken, selbst auf einem Pentium nicht.


Okay, dann gibt es also noch eine weitere Unsicherheit beim Programmieren in Dosbox: Die Geschwindigkeit
der Grafik.
Ich frage mich nur, ob ich nicht immer noch mit den 20000 Cycles (die meines Wissens eine gewisse Genauigkeit
haben und eher nicht von der Geschwindkeit des Host-Computers abhängen, vielmehr setzt dieser die Beschränkung
der Maximalgeschwindigkeit fest), einen sehr bescheidenen 486er (wenn nicht sogar 386er) emuliere, mit
unterm Strich eher realistischer Grafikgeschwindigkeit. Das ist natürlich alles nur Spekulation, aber XPYDERS
performt bei 20000 Cycles mit etwa 10 fps, bei 40000 Cycles sieht es dagegen schon ziemlich flüssig aus.
Das macht einem natürlich Lust, sein Spiel so zu gestalten dass die Framerate lieber sinkt als dass irgendwas
ausfällt, aber wenn mein Spiel bei 20000 Cycles oder etwas weniger keine Probleme macht würde ich es als
grundsätzlich 486er tauglich einschätzen.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Mo 27. Aug 2018, 08:24
von DOSferatu
zatzen hat geschrieben:
DOSferatu hat geschrieben:Zu kompliziert? Wie ich schon mal erwähnte: Ich will Dich eigentlich nicht nerven oder so.
Nein, ich denke der Text ist aufschlussreich, von dem her was ich bisher überflogen habe. Mir ist ja kürzlich erst das Problem bewusst geworden mit der Tatsache dass man bei meinem Vorgehen die Auswirkungen seiner Steuerungen erst im übernächsten Frame sieht, was für mich nur okay wäre wenn man die Framerate in Richtung 50 fps hochschrauben würde.
zatzen hat geschrieben:
DOSferatu hat geschrieben:In prISM und AtavISM hört man NICHTS, während man die Töne eingibt
Das ist beim Eingeben der Noten natürlich ein wenig Tappen im Dunklen, wenig intuitiv.
Aber es ist wahrscheinlich mit ISM nicht ohne weiteres anders machbar.
Die großen Komponisten haben Musikstücke für ganze Orchester aus dem Kopf heraus auf Notenblätter geschrieben und dabei den Klang im Kopf gehabt. Ludwig van Beethoven hatte ein schlechtes (und immer schlechter werdendes) Gehör - als er seine berühmte neunte Sinfonie komponiert hat, war er bereits komplett taub. (Nimm Dir 'n Beispiel daran...)
Nö, mal im Ernst: prISM und AtavISM sind bewußt sehr einfach gehalten. Während des Menüs interaktiv den Klangpuffer zu bedienen wäre zwar möglich, aber würde einen nicht unerheblichen Umbau erfordern. Und wenn das erledigt wäre, käme als nächstes: "Ja, und eigentlich müßten die anderen Stimmen mit spielen, während ich an der einen arbeite" und dann fang' ich wieder von vorn an... Irgendwann ist auch mal gut mit Featuritis.

Ich hatte immer gedacht, so "Musikleute" hören immer schon im Kopf die Noten und wenn sie ein paar Noten sehen, wissen sie schon, wie sich das anhören würde. Ich bin z.B. überhaupt kein Musikmensch, sondern eher so mathematisch angelegt und selbst ich kann mir da schon vorstellen, wie es in etwa klingt wenn ich die (Computer-)noten, also C-3, D-3, F#3 usw. sehe.
zatzen hat geschrieben:
DOSferatu hat geschrieben:F4 find ich gut. Die war bei mir sowieso noch frei und ich nutze sie derzeit in AtavISM nur, um das Instrument/Sample zu wählen und einzustellen. Mal sehen, ob ich das um ein Pulldown erweitere.
In X-Tracker wird die Sample-Liste durch einen Druck auf Enter eingeblendet. Dort kann man per Pfeiltasten hoch/runter PgUp/Dn Pos1/End ein Sample auswählen und wenn man will dessen Parameter bearbeiten.
Enter wechselt bei prISM/AtavISM in die nächste Zeile. Allerdings kann das ja auch genauso durch Eingabe von Tönen oder durch Cursor-runter erfolgen. Im Klaviermode könnte man da auch Enter für das Pulldown nutzen.
Und, wie ein Pulldown funktioniert, ist ja klar. Meine sind da auch nicht anders. Allerdings kann man bei mir bisher keine Sample-Parameter bearbeiten. Die Samples müssen extern erstellt werden. Und, wie ich ja immer wieder betone, sind Samples sowieso nur so eine "nachträgliche Dreingabe" gewesen - das komplette ISM und prISM (und auch AtavISM) unterstützen Samples eher "stiefmütterlich", weil das Hauptaugenmerk immer auf digitaler Klangsynthese lag und liegen soll. Aber das hatte ich ja bereits mehrmals (wahrscheinlich schon zu oft) erwähnt.
Seit v0.13 können Samples jetzt auch normale Filenamen haben - allerdings werden sie natürlich in ISM/prISM/AtavISM weiterhin numeriert angesprochen.
zatzen hat geschrieben:Außerdem kann man auch hier schon das Sample per Klaviaturtasten abspielen. Schlägt man eine andere Note an, stoppt das bisherige und die neue Note spielt.
Tja - nett.
Alles Dinge, die AtavISM (und prISM) nicht haben. Ich hatte so etwas mal angedacht - aber im Gegensatz z.B. zum C64, wo der Soundchip völlig selbständig arbeitet, sobald man Töne "angestoßen" hat, muß man ja beim PC ständig den Puffer im Auge behalten und "nachfüllen". Wenn, dann würde ich das in die Tastenabfragewarteschleife einbauen müssen. Aber das wird dann wieder insgesamt etwas mehr Aufwand. Das "Standalone" Abspielen von Samples ist nicht vorgesehen, also müßte hier mit einem intenen Pseudo-ISM-File gearbeitet werden. Außerdem haben Samples bei mir keine eigene Frequenz - sie werden nur mit einer Referenzfrequenz gespeichert, weil ISM ja sowieso das Sample auf die entsprechend gewünschte Höhe pitchen muß.
zatzen hat geschrieben:Bei manch anderen Trackern spielt das Sample so lange wie man die entsprechende Taste gedrückt hält und man kann auch mehrere Tasten gleichzeitig drücken so dass eine Polyphonie entsteht.
Tja, würde ja auch nichts bringen, weil AtavISM derzeit sowieso keine solchen Dinge unterstützt, d.h. Mehrklang auf einer Stimme.
zatzen hat geschrieben:Ich persönlich komme damit nicht so gut klar weil im Pattern selbst pro Track Monophonie gilt
Sehe ich genauso.
zatzen hat geschrieben:und auch die Samples so lange klingen bis man sie per Befehl stoppt - ich finde es angenehmer wenn ich um ein Sample klingen zu lassen nur die entsprechende Taste kurz anschlagen muss.
Tja... Allerdings wird ESC gebraucht, um Markierungen zu löschen, Funktionen rückzusetzen usw. Da müßte es dann eine weitere ESC-"Stufe" geben: Wenn eine Note klingt, wird diese erst gestoppt, bevor etwas anderes passiert.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Die Patterns von AtavISM sind nur 64 Zeilen lang, immer.
MOD-Patterns sind auch immer 64 Zeilen lang, was aber sinnvoll wäre, wäre wenn man sie kürzen könnte oder einen Break setzen könnte. Beispielsweise für einen Auftakt am Anfang eines Musikstücks der z.B. nur 8 Zeilen lang ist.
Tja, ICH hab das nicht so entwickelt - bei ISM gibt es gar keine Patterns, da kann alles und jedes so lang sein wie es will. Die "Besonderheit" von ISM ist ja, daß sich die Stimmen untereinander nicht "kennen", d.h. sie wissen nicht, was die andere Stimme gerade macht - es gibt keine kontrollierende "Hauptstimme" oder ähnliches. Das bedeutet: In AtavISM ist ein Pattern nichts wirklich "zusammenhängendes": Es sind in Wahrheit bis zu 8 (je nachdem wieviele Stimmen man hat) Einzelstücken, die einzeln vorliegen, bei denen durch AtavISM "außenherum" dafür gesorgt wird, daß sie alle die gleiche Länge (64 Ticks) haben und die dann in die entsprechende Stelle einsortiert werden. Gleiche Blocks werden nur einmalig gespeichert. Würde man so einen Break wollen (technisch durchaus möglich), müßte man den manuell in allen Stimmen an der gleichen Stelle, d.h. gleichen Zeile, setzen - anderenfalls würde das ganze Stück unsynchron.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ja, ich werde wohl nicht komplett alles 1:1 wie in X-Tracker umsetzen können - ODER ich verzichte auf die praktischen Möglichkeiten der Ins/Del-Kombinationen, die Kopieren/Verschieben/Löschen usw. ohne nötigen Menüaufruf aktivieren und dann muß man das im "X-Tracker-Mode" eben immer aus dem Modify-Menü anwählen.
Bei X-Tracker funktioniert das Verschieben eines Blocks über Alt+M.
Willst Du Dir wirklich die Mühe machen, einen X-Tracker Mode zu implementieren?
Vielleicht schaffen wir es ja stattdessen, eine schlüssige allgemeine Bedienung herauszuarbeiten.
Naja, es wird kein X-Tracker Mode, weil ich nicht die komplette Funktionalität des X-Trackers übernehmen kann (und will). Vielleicht nenne ich ihn Klaviermodus (piano mode) oder so.
zatzen hat geschrieben:Ansonsten hätte ich natürlich auch nichts dagegen wenn es so einen Mode gäbe in dem ich intuitiv arbeiten kann. Aber ich bin ja nicht der einzige User von AtavISM.
Wahrscheinlich bist Du das doch. Ich habe es nur programmiert - für mich wäre diese patternbasierte Schachtelung zu sperrig und gibt mir zu wenig Freiheiten. Und ich kann mir nicht vorstellen, daß irgendwer sonst noch so einen "Beinahe-Tracker" benutzen will, (wenn er auch einen richtigen Tracker benutzen könnte) nur um VIELLEICHT mal Musik für irgendein DOS-Spiel zu machen, das VIELLEICHT mal irgendwann kommt oder nicht.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Was meinst Du mit Start- und Endpunkt?
Das ist, wie man in X-Tracker in einem Pattern Blöcke markiert.
F7 setzt den oberen linken Punkt, F8 den unteren rechten.
So markiert man ein Rechteck, was sich auf einen Kanal beschränken, sich aber auch über mehrere nebeneinanderliegende Kanäle erstrecken kann.
Kapiere ich immer noch nicht ganz. Ich vermute mal, daß hier gemeint ist, daß man nicht nur einen Bereich aus einem Kanal kopieren kann, sondern quasi über mehrere Kanäle hinweg.
Nun, das wird es bei mir wohl so nicht geben - dazu sind prISM/AtavISM einfach zu verschieden zu X-Tracker gebaut.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Du meinst, ein Programm, das aus einem X-Tracker-MODfile ein WAV macht?
Ja, genau. Und das war wesentlich komplexer als mein ZSM-Player, wegen der ganzen Effekte die auch Sinusfunktionen involvierten. Ich habe da ohne Tabellen gearbeitet, alles auf höchste Präzision ausgelegt, und u.a. deshalb war an Echtzeit-Ausgabe nicht zu denken, selbst auf einem Pentium nicht.
Ahja. Na gut, wenn man natürlich ein MOD oder ähnliches Trackerfile auf eine (Musik-)CD legen will, ist das ja auch nötig, daß es in reinem WAV vorliegt - da macht das natürlich Sinn.
zatzen hat geschrieben:Okay, dann gibt es also noch eine weitere Unsicherheit beim Programmieren in Dosbox: Die Geschwindigkeit der Grafik.
Ich frage mich nur, ob ich nicht immer noch mit den 20000 Cycles (die meines Wissens eine gewisse Genauigkeit haben und eher nicht von der Geschwindkeit des Host-Computers abhängen, vielmehr setzt dieser die Beschränkung der Maximalgeschwindigkeit fest), einen sehr bescheidenen 486er (wenn nicht sogar 386er) emuliere,
Ich habe noch nicht genau verstanden, was die Referenz-Einheit für diese Cycles ist. Taktzyklen pro Sekunde können es ja kaum sein, denn ca. 20000 Taktzyklen hat ein schon ein C64 in 1/50 Sekunde.
zatzen hat geschrieben:mit unterm Strich eher realistischer Grafikgeschwindigkeit. Das ist natürlich alles nur Spekulation, aber XPYDERS performt bei 20000 Cycles mit etwa 10 fps, bei 40000 Cycles sieht es dagegen schon ziemlich flüssig aus.
Naja, wie Wobo schon sagte: Es dient wohl eher dazu, einen relativen Wert zu haben, um Spiele, die damals ohne Timing programmiert wurden (bei 286er und darunter gab es so etwas öfters - ich sage nur "Wing Commander") entsprechend anpassen zu können. Aber: Ich gehe davon aus, daß man damit lediglich eine relative CPU-Geschwindigkeit einstellt - mit der Grafikkarte oder Busgeschwindigkeit hat das kaum etwas zu tun. Und - ich kann mich auch irren - daß bei Zugriff auf Speicher nicht explizit getestet wird, ob es Grafikkartenspeicher oder normaler RAM ist. Ersterer ist normalerweise langsamer - Zugriffe auf Speicher mit $000A oder $000B als Bits 16-31 werden auf x86-PCs ja auf Grafikkartenspeicher "umgemappt", greifen dann also auf den Speicher der gesteckten Grafikkarte zu, was je nach Busgeschwindigkeit natürlich bremst. ISA, VLB und PCI unterscheiden sich hier auf echten Rechnern erheblich - das ist in DOSbox nicht einmal einstellbar.
Desweiteren kann man leider DOSbox auch nicht veranlassen, z.B. einen 286er zu emulieren - bei dem ich erwarten würde, daß er bei Nutzung von 386er-Befehlen (32bit, "verbotene" Segmentregister) abstürzt oder z.B. Sachen wie Shiftbefehle oder Stackbefehle 286er-mäßig behandelt, inklusive der "Hardwarebugs". Nur dann kann man ja feststellen, ob es auch im realen System funktionieren würde und wie es performen würde.
DOSbox ist also sehr gut, um bereits fertige und funktionierende Programme (Spiele oder wasauchimmer) darauf laufen zu lassen - als Entwicklungsumgebung ist es dagegen (wegen o.g. Dinge) nur mäßig geeignet.
zatzen hat geschrieben:Das macht einem natürlich Lust, sein Spiel so zu gestalten dass die Framerate lieber sinkt als dass irgendwas ausfällt, aber wenn mein Spiel bei 20000 Cycles oder etwas weniger keine Probleme macht würde ich es als grundsätzlich 486er tauglich einschätzen.
Tja, wie gesagt - ich weiß nicht genau, worauf sich die Cycles hier beziehen, aber schon allein, weil man nicht explizit weitere Einstellungen für Busgeschwindigkeit, Grafikkartenzugriffsgeschwindigkeit und weitere "Systembremsen" hat, dürfte das Ergebnis wenig realistisch sein. Ich nehme auch an, daß jedes noch so besch... programmierte Programm mit AdLib-Zugriffen, das auf einer realen Maschine wegen Nichtbeachtung der "AdLib-Erholungsphasen" ständig mit hängenden Noten oder komplett abgestürztem OPL3 (AdLib-Chip) zu kämpfen hätte, würde auf DOSbox laufen, weil man solche Hardwaremängel aus Performancegründen hier nicht mitemuliert.

Einfacher Test: Monkey Island 1 mal mit 40000 Cycles (was laut Deiner Information quasi wie "guter 486er" wäre) auf DOSbox mit AdLib-Einstellung laufen lassen. Selbst mit Patch (der verhindert, daß wegen zu schneller Maschine mit DIV0-Error abgestürzt wird), sollte die (emulierte) AdLib hier "hängenbleiben", weil die Timerschleife zu kurz ist. Ich gehe davon aus, daß sie das nicht tut.

Bei Xpyderz ist das noch mal eine ganz andere Geschichte: Hier bremst ja nicht nur der Grafikkartenzugriff, sondern auch die Berechnung der Grafik (also Level und Sprites), d.h. mit schnellerer CPU (Cycles) sollte es fast linear schneller werden. In Wirklichkeit (auf echter Maschine) wäre das aber nicht so, weil ein nicht unerheblicher Teil der "Bremse" hier auf den Grafikkartenzugriff entfällt, der auch bei schneller CPU mit gleicher Grafikkarte genauso langsam ist. Ich hatte es ja mal erwähnt: Auf meinem ersten 486er 66 MHz hatte ich Doom laufen, aber mit der gleichen VGA, die ich in meinem 286er vorher drin hatte. Ich kam nie über so 8 FPS raus - obwohl der 486er für Doom mehr schnell genug war (id Software können eben programmieren). Der Grund ist, daß nach jedem Zugriff der CPU auf die Grafikkarte gewartet werden muß, bis der Wert geschrieben ist (denn theoretisch könnte beim nächsten Zugriff der gleiche Wert gelesen werden sollen - dann muß er ja da sein). Viel später, mit neuer Grafikkarte hatte ich dann flüssiges Spiel. Also ist so etwas nicht irgendwie "vernachlässigbar" oder ein unwichtiger Wert, der sich von allein wegrechnet. Und das ist der Grund, wieso ich auf PC nur modular programmiere - ich kann nie wissen, was für eine krude Hardware meine Software vorfinden wird: Es wird aber meist nichts wie diese fehlertolerante DOSbox sein.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 1. Sep 2018, 21:48
von zatzen
Abspielen während der Eingabe:
Ich bin kein großer Komponist... Nur einer der während des Trackerns auch viel improvisiert, und da ist
es hilfreich wenn man hören kann wie es klingt und nicht nur wie man es sich vorstellt. Die mittelgroßen
Komponisten haben meistens auch ein Instrument vor sich sitzen gehabt beim Komponieren.
Beethoven war da vielleicht anders, ihm kamen Melodien bei Spaziergängen - ja mir passiert das auch,
aber wie gesagt wird soetwas wie Begleitung auch gerne mal improvisiert.
Es muss aber nicht gefeaturet werden, dann funktioniert es eben über "auf gut Glück" eingeben oder eben
mit etwas mehr Bemühung von Hirnschmalz, und dann abspielen. Naja gerade dass man in "meinem" Tracker
die entsprechenden Tonhöhen bzw. Sampleklänge direkt hört, hat mich ziemlich vom Notendenken weggebracht -
ich muss gar nicht mehr hingucken was für eine Notenbezeichnung da notiert wird.
Das kann man als fortschrittlich sehen weil ich Musik nun freigeistiger betrachte und die ganze Komposition
intuitiver erfolgt und sich nicht auf irgendwelche Tricks und Formeln stützt. Oder auch als Rückschritt,
weil ich durch mein Musikschaffen keine Noten lerne.
Vorstellen kann ich mir auch wie z.B. C - E - G klingt, aber bei etwas weniger gängigen Folgen muss ich
schon nachdenken, und das blockiert wieder den Arbeitsfluss - zumindest bei mir weil ich zu faul bin
Noten zu verinnerlichen, aber mal ehrlich gesagt, habe ich eine Abneigung gegenüber der klassischen
Notenschrift. Tatsächlich habe ich gar keine Ahnung was ich technisch beim Musikmachen veranstalte,
bis dann jemand kommt und es analysiert.


Samples: Ich stelle mir die Arbeit in AtavISM sowieso nicht sehr Sample-lastig vor, bisher habe ich mir
eher Gedanken darüber gemacht wie ich auch ohne Samples Klangfülle reinbringen kann, weil ich in
den letzten einigen Jahren für meine Produktionen (nicht für Spiele sondern für den "Endhörer") eher
in die Richtung gegangen bin, mit Samples, die selbst schon mehr als nur einen isolierten Ton enthalten,
interessante, atmosphärische Klanggebilde zu schaffen. Das kann man aus der Sicht dass ein "Modul"
nur 64K haben sollte verteufeln, man muss es aber nicht wenn es nur um die Kunst geht und man dabei
beliebige Techniken mit beliebig viel Ressourcen einsetzen kann.

Die ZSM-Engine funktioniert so, dass man auch im aktuellen ZSM-Player während er spielt problemlos
per irgendeiner Taste zusätzlich ein oder mehrere Samples auf beliebiger Tonhöhe starten und auch
wieder stoppen könnte. Das liegt an der zugrundeliegenden Art und Weise, wie der Puffer gefüttert
wird, theoretisch sind beliebig viele Samples möglich, solange es intern im 16 Bit Puffer keinen Überlauf gibt.
Die Patternstruktur ist weniger technisch bedingt zu verstehen, als vielmehr nur als Informationsleitfaden,
wann welche Samples gespielt und gestoppt werden.
Wenn ich einen Tracker bauen wollte, müsste ich wohl nur den Player als Grundlage nehmen und die
Player-Engine permanent laufen lassen, evtl. mit Ausnahme solcher Situationen wenn ein neues Sample geladen wird.

Pattern Break:
Ja, der gilt selbstverständlich Stimmenumfassend, so wie er in MOD Patterns das ganze Pattern
verkürzt und nicht nur einen Kanal (was da gar nicht möglich wäre).
Du könntest ja dann auf den Spuren wo nichts passiert eine Pause definieren.

Markierungen mit F7 / F8:
Eigentlich ist es auch nicht so wichtig.
Man kann eben einen Bereich innerhalb eines Kanals markieren, aber auch einen rechteckigen
Bereich der über mehrere Kanäle hinweg geht also z.B. Kanal 1-3 ab Zeile 4 bis Zeile 57, wie auch immer.
Der Witz daran ist, neben der Möglichkeit z.B. eine mehrkanälige Schlagzeugstruktur innerhalb eines
Patterns zu kopieren, auch die Möglichkeit, mehrere Kanäle in ein anderes Pattern zu kopieren, d.h.
die Kopierfunktion ist Pattern-übergreifend.
Bei vielen Musikstücken ist es nunmal so, dass einige Elemente eine sich wiederholende Struktur bilden.

Zu Dosbox:
Rough dependency between cycles and emulated CPU.
Different applications, even their parts, may have different this dependency.

Emulated CPU Cycles
8088 4.77 MHz 315
286 12.5 MHz 2750
386 33 MHz 7800
486 66 MHz 26800
Pentium 100 77000
Pentium II 300 200000
Ich meine ich hatte damals einen 486 DX 50.


Seit meines Bewusstwerdens mit dem "man sieht erst im übernächsten Frame die Auswirkungen seiner
Entscheidungen" bin ich mir gar nicht mehr sicher, ob ich überhaupt noch ernsthaft ein Spiel machen
möchte. Irgendwie muss dieses Problem erst gelöst werden, entweder indem ich alles so löse wie Du,
oder vielleicht fällt mir doch nach langer Grübelei noch eine Alternative ein.
Aber generell gilt: Ich programmiere wirklich nur zum Spaß und nebenbei, es ist nur vielleicht 20% meiner
Hobbyaktivität. Deshalb wäre ich auf dem Gebiet schon froh, etwas vorzeigbares zu haben, auch wenn
es trotz viel Assembler die Ressourcen nicht voll ausnutzt.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 2. Sep 2018, 13:20
von DOSferatu
zatzen hat geschrieben:Abspielen während der Eingabe:
Ich bin kein großer Komponist... Nur einer der während des Trackerns auch viel improvisiert, und da ist es hilfreich wenn man hören kann wie es klingt und nicht nur wie man es sich vorstellt. Die mittelgroßen Komponisten haben meistens auch ein Instrument vor sich sitzen gehabt beim Komponieren.
Ja, das stimmt natürlich.
zatzen hat geschrieben:Beethoven war da vielleicht anders, ihm kamen Melodien bei Spaziergängen - ja mir passiert das auch,
Mir ebenfalls. Deshalb habe ich jetzt oft ein Diktiergerät bei mir.
zatzen hat geschrieben:aber wie gesagt wird soetwas wie Begleitung auch gerne mal improvisiert.
Es war ja auch eher als Scherz gemeint. Ich erwarte nicht, daß jemand hier Musik in der Qualität eines Beethoven komponiert (und mit einer "Qualität" von ISM wäre das wohl auch kaum möglich).
zatzen hat geschrieben:Es muss aber nicht gefeaturet werden, dann funktioniert es eben über "auf gut Glück" eingeben oder eben mit etwas mehr Bemühung von Hirnschmalz, und dann abspielen.
Naja, ich überlege bereits, wie ich die ganzen Dinge möglichst effektiv und speichersparend unter einen Hut bekomme, so daß trotzdem noch alles kompatibel bleibt. Bisher habe ich an AtavISM noch nicht eine neue Codezeile gebaut. Erstens muß ich dazu in der richtigen "Schaffensstimmung" sein (also nicht müde, keine Kopfschmerzen oder ähnliches) und zweitens plane ich in letzter Zeit viele Dinge vorher, um zu vermeiden, "angeflanschten Spaghetticode" einzubauen, mit dem man dann nichts mehr anfangen kann, sobald eine neue Erweiterung benötigt wird.
zatzen hat geschrieben:Naja gerade dass man in "meinem" Tracker die entsprechenden Tonhöhen bzw. Sampleklänge direkt hört, hat mich ziemlich vom Notendenken weggebracht -
ich muss gar nicht mehr hingucken was für eine Notenbezeichnung da notiert wird. Das kann man als fortschrittlich sehen weil ich Musik nun freigeistiger betrachte und die ganze Komposition intuitiver erfolgt und sich nicht auf irgendwelche Tricks und Formeln stützt. Oder auch als Rückschritt, weil ich durch mein Musikschaffen keine Noten lerne.
Naja, mit den Noten der Notenschrift habe ich mich nie richtig befaßt. Es mag sein, daß sie Sinn macht - man gibt die "Tonlage" und "Dur/Moll" an und die Notenschrift ist dann ein 7-Noten-System, das pro Notenlinie maximal 2 Oktaven umfassen kann (daher dann noch der Violin- und Baßschlüssel davor, um die Oktavenverschiebung anzugeben...)
- ABER -
ich finde das viel zu kompliziert gelöst. Eine Oktave hat 12 Töne, von denen man je nach Tonart und Tonlage manche nicht benutzt. Man kann zwischendurch jederzeit die Tonart/Tonlage ändern ohne zusätzliche Kennzeichnung. Und die "schwarzen" Töne, die bei Dur anders als bei Moll heißen, obwohl es DIE GLEICHEN TÖNE SIND, fand ich auch schon immer schwachsinnig. Daher finde ich die "Computernoten"
C, C#, D, D#, E, F, F#, G, G#, A, A#, H (plus jeweilige Oktave)
auch angenehmer und logischer.
zatzen hat geschrieben:Vorstellen kann ich mir auch wie z.B. C - E - G klingt, aber bei etwas weniger gängigen Folgen muss ich schon nachdenken, und das blockiert wieder den Arbeitsfluss - zumindest bei mir weil ich zu faul bin Noten zu verinnerlichen, aber mal ehrlich gesagt, habe ich eine Abneigung gegenüber der klassischen
Notenschrift. Tatsächlich habe ich gar keine Ahnung was ich technisch beim Musikmachen veranstalte, bis dann jemand kommt und es analysiert.
Ja, wie gesagt - die klassische Notenschrift mag ihre Daseinsberechtigung haben. Irgendwer hat sich das mal ausgedacht, es wird seit hunderten Jahren benutzt... Aber auch MOD hat sich mal irgendwer ausgedacht und trotzdem ist es nicht die einzige Art, Töne/Musik darzustellen. Ich denke, viele "elektronische" Musiker pfeifen ebenfalls auf die klassische Notenschrift. Und, solange der Ton getroffen wird, ist es ja egal, wie der "Sourcecode" dafür aussieht.

zatzen hat geschrieben:Samples: Ich stelle mir die Arbeit in AtavISM sowieso nicht sehr Sample-lastig vor,
Ja, ich auch nicht. Ich weiß auch nicht, ob alles, was Samples betrifft, in ISM schon vernünftig funktioniert. Dieser "HLD" Befehl scheint bei Samples manchmal blöde Sachen zu machen (wenn man mitten im Sample noch irgendwelche Änderungen macht). Aber, wie ich ja schon erwähnte, ist die Sampleunterstützung in ISM nur "der Vollständigkeit halber". Ich denke da eher an Soundeffekte, die man vielleicht nicht allein per Synthese so hinbekommt, wie man sie gern hätte. Und ohne Sample wären für manche Soundeffekte vielleicht mehrere Stimmen nötig, wo mit Sample eine einzige reichen würde.
zatzen hat geschrieben:bisher habe ich mir eher Gedanken darüber gemacht wie ich auch ohne Samples Klangfülle reinbringen kann, weil ich in den letzten einigen Jahren für meine Produktionen (nicht für Spiele sondern für den "Endhörer") eher in die Richtung gegangen bin, mit Samples, die selbst schon mehr als nur einen isolierten Ton enthalten, interessante, atmosphärische Klanggebilde zu schaffen.
Bei "Standalone" Musiken ist die Grenze das Universum. Wenn sie irgendwo "eingebaut" werden und mit anderen Dingen zusammen funktionieren soll, wird man immer Beschränkungen erleben. Ob und wie man damit umgeht - ob man es als Einengung der Kreativität sieht oder als Herausforderung - das macht den Unterschied. Ein Chris Hülsbeck hat es geschafft, mit einem insgesamt 3-stimmigen Soundchip (SID) tolle Musiken und Soundeffekte GLEICHZEITIG zu erzeugen, für Spiele wie Katakis und R-Type. Und der SID hat keine Samples/Wavetable, sondern NUR Klangsynthese. Das ist es, was ich so meine. Und ich habe mir "Soundmonitor" (den Musik-Editor von Hülsbeck) nie angesehen, aber ich denke, hier wurde sicher auch nicht "mit Nullen gefüllt, wenn gerade nichts kommt". Das kann man sich auf einer Maschine mit INSGESAMT 64 kByte RAM nicht erlauben. Und auf PC reichen vielen Leuten 64 kByte nicht einmal, um einen EINZIGEN Ton zu generieren - und DAS finde ich eben armselig.
zatzen hat geschrieben:Das kann man aus der Sicht dass ein "Modul" nur 64K haben sollte verteufeln, man muss es aber nicht wenn es nur um die Kunst geht und man dabei
beliebige Techniken mit beliebig viel Ressourcen einsetzen kann.
Nichts wird "verteufelt" - man kann doch machen, was man will. Es ist nicht so, daß ich nicht wüßte, wie ich in 1024x768 mit 16777216 Farben schalte und wie ich darin Grafik darstelle/erzeuge (Habe auch eigene Units dafür hier.) Nur schränke ich mich eben bei der Grafik auch ein: Auflösungen im Bereich bis max. 400 Breite und 300 Höhe (eher weniger), Farbtiefe palettenbasiertes 8-Bit, dabei für die meisten Grafikelemente nur 16 Farben dieser 256 usw. und habe Grafiken im Speicher quasi teilweise gepackt. Ich baue auch extra Systeme in 100% Assembler, um die Steuerung möglichst klein und schnell zu bekommen oder Systeme, ebenfalls in 100% Assembler, um Parser klein und schnell zu bekommen. Die Darstellung der Grafik erfolgt in Assembler, die Berechnung der Musik erfolgt in Assembler - alles kleine, schnelle Subroutinen - weil ich weiß, daß Levels und Grafiken eben trotzdem einiges an Speicher brauchen und weil aufgrund der Performance und Benutzbartkeit nicht alles gepackt sein kann (z.B. 8-Wege-Levels)...

Und wenn ich mir nun schon diese ganze Mühe mache, um die Einzelteile klein und schnell zu bekommen, damit ein Gesamtspiel immer noch mit DOS-Hardware (CPU RealMode bzw V86 /Speicher/Grafikkarte/Soundkarte/Peripherie) auskommt, sollte man einfach verstehen, daß ich dann auch nicht einsehen kann, wenn/falls ein einzelner Unterbereich aus all dem sich so "wichtig nimmt", daß nur alle anderen Bereiche sich einzuschränken haben, nur der eine nicht. Also (Extremfall), daß man z.B. nur winzige Levels mit mit ein paar wenigen immer gleichen Kacheln und ein paar wenige winzige Figuren haben könnte ohne großartige Bewegungsanimation und schlichtestem Spielprogrammcode - nur damit der restliche Speicher ausreicht, um 400 kByte mit zahlreichen riesigen Samples vollzuknallen.. Das wäre dann kein Spiel, auf das ich Lust hätte, es zu programmieren oder zu spielen.
zatzen hat geschrieben:Die ZSM-Engine funktioniert so, dass man auch im aktuellen ZSM-Player während er spielt problemlos per irgendeiner Taste zusätzlich ein oder mehrere Samples auf beliebiger Tonhöhe starten und auch wieder stoppen könnte.
Ja, das ist in ISM auch so. Man kann "jederzeit" neue Stimmen starten oder alte beenden. Mit "jederzeit" ist natürlich gemeint: Nur immer zwischen den einzelnen Puffergenerierungen. ABER: ISM hat sogar einen Synchronisations-Modus, wo "befehlsgenau"/"taktgenau" (d.h. auf 1/128 Sekunde genau) etwas gestartet werden kann. Allerdings kann man das auch nur ZWISCHEN den Aufrufen des Generators aktivieren. Während der Generator läuft (also den nächsten Puffer berechnet) zwischendurch einzugreifen - das war mir zu crazy, das wird nicht unterstützt. Der Sync-Mode dient eher dazu, daß wenn Dinge innerhalb der Klanggenerierung mehrere Stimmen betreffen (z.B. an-/abschalten) daß dies dann am genau gleichen Zeitindex in jeder Stimme passiert. Eigentlich braucht man das nicht, weil im Normalfall alle zu einem Musikstück gehörenden Stimmen bereits am Anfang aktiviert werden. Wenn man das nicht macht (z.B. Stimmen erst später dazuschaltet/aktiviert) entstünde Unsynchronität zwischen den Stimmen bei zu großen Soundpuffern. (Andererseits kann dem auch mit dem JET Befehl entgegengewirkt werden.)
zatzen hat geschrieben:Das liegt an der zugrundeliegenden Art und Weise, wie der Puffer gefüttert
wird, theoretisch sind beliebig viele Samples möglich, solange es intern im 16 Bit Puffer keinen Überlauf gibt.
Naja, von der Art und Weise wie ISM aufgebaut ist (die Stimmen "kennen sich untereinander nicht") wären hier auch viel mehr Stimmen möglich. Allerdings sind die Reichweiten der Parameter natürlich begrenzt und die Reichweite der "Kombinator-Tabelle" natürlich auch. D.h. daß Stimmen "zusammengehören" wird nur in einem einzelnen Array erfaßt - es ist 16 Words groß und für jede Stimme sind Bits gesetzt, welche Stimmen zum "Tune" gehören. (Somit kann man auch mehrere Musiken gleichzeitig abspielen - es ist aber natürlich eher dazu gedacht, Musiken und Klangeffekte zusammen abspielen zu können.)
zatzen hat geschrieben:Die Patternstruktur ist weniger technisch bedingt zu verstehen, als vielmehr nur als Informationsleitfaden, wann welche Samples gespielt und gestoppt werden.
Ja, das ist ja genau das, was MOD macht. ISM macht es auch nicht anders - es stellt es nur anders dar. Bei ISM kann man nicht sagen: "An genau dieser Position in den Daten/Zeit relativ zum Anfang startet dieser Ton", sondern, wann die Töne starten hängt von allem ab, was vorher gespielt wurde. Da es hier auch Schleifen/Unterprogramme gibt, ist das Ganze nicht so trivial, das ist mir natürlich klar. prISM (und AtavISM) haben ja eine Option, um einen gewissen "stillen Zeitvorlauf" zu haben. D.h. man kann angeben, ab welcher Sekunde man das Stück anhören will und der ganze Vorlauf wird dann nur "blind" schnell generiert, ohne abzuspielen (die Timecode Optionen im Play-Menü).
zatzen hat geschrieben:Wenn ich einen Tracker bauen wollte, müsste ich wohl nur den Player als Grundlage nehmen und die Player-Engine permanent laufen lassen, evtl. mit Ausnahme solcher Situationen wenn ein neues Sample geladen wird.
Wäre bei AtavISM auch so.
zatzen hat geschrieben:Pattern Break:
Ja, der gilt selbstverständlich Stimmenumfassend, so wie er in MOD Patterns das ganze Pattern verkürzt und nicht nur einen Kanal (was da gar nicht möglich wäre). Du könntest ja dann auf den Spuren wo nichts passiert eine Pause definieren.
Naja, eine Pause würde ja für den Zeitraum Stille erzeugen.
Wie gesagt: Es wäre technisch möglich, einen Break zu setzen - prinzipiell würde aus dem Pattern einfach früher zurückgesprungen werden. D.h. ein Break wäre nur ein früherer Return-Befehl. Nur sind es eben z.B. bei 8 Stimmen 8 Returns und die müßten alle in die gleiche Zeile gesetzt werden, damit alles Nachfolgende immer noch synchron wäre. Oder anders ausgedrückt: Hier müßte einfach nur das Pattern kürzer gemacht werden, also eine einstellbare Patternlänge. Der Parser/Generator, der daraus ISM-Daten macht, hätte damit an sich keine Probleme.
Es liegt eben alles daran, daß die Patterndarstellung in AtavISM nur eine "Krücke" ist, die auf dem eigentlichen ISM aufgesetzt ist.
zatzen hat geschrieben:Markierungen mit F7 / F8:
Eigentlich ist es auch nicht so wichtig.
Man kann eben einen Bereich innerhalb eines Kanals markieren, aber auch einen rechteckigen Bereich der über mehrere Kanäle hinweg geht also z.B. Kanal 1-3 ab Zeile 4 bis Zeile 57, wie auch immer.

Der Witz daran ist, neben der Möglichkeit z.B. eine mehrkanälige Schlagzeugstruktur innerhalb eines Patterns zu kopieren, auch die Möglichkeit, mehrere Kanäle in ein anderes Pattern zu kopieren, d.h. die Kopierfunktion ist Pattern-übergreifend.
Bei vielen Musikstücken ist es nunmal so, dass einige Elemente eine sich wiederholende Struktur bilden.
Ja, theoretisch ist das natürlich möglich, es wäre eine Mehrfachausführung der Kopierfunktion. Allerdings widerspricht das vollständig den bereits vorhandenen Funktionen - die Spuren sind in prISM/AtavISM völlig voneinander unabhängige "Fenster", bei denen bei AtavISM nur "außenherum" so eine Zusammenführung angeflanscht wurde, damit es wie ein Pattern wirkt. In mehreren Fenstern gleichzeitig eine Markierung zu haben, widerspricht nun wieder der kompletten Markierfunktion.
zatzen hat geschrieben:Zu Dosbox:
Rough dependency between cycles and emulated CPU.
Different applications, even their parts, may have different this dependency.

Emulated CPU Cycles
8088 4.77 MHz 315
286 12.5 MHz 2750
386 33 MHz 7800
486 66 MHz 26800
Pentium 100 77000
Pentium II 300 200000
Ich meine ich hatte damals einen 486 DX 50.
Ja, daran allein sieht man ja schon die Unterschiede - ALLEIN, was schon nur die CPU angeht: Ein 386er mit der halben Taktfrequenz ist nur zwischen 1/3 und 1/4 so schnell wie der 486er. Der Pentium 100, der eine 8x so hohe Taktfrequenz hat wie der 286er, hat nicht den Wert 22000, sondern 77000, er ist also nicht nur 8x, sondern 28x so schnell wie der 286er - was daran liegt, daß Befehle weniger Takte brauchen, der Prefetch Queue und die Caches großer sind und es Pairing gibt.
Und, da steht: "Different applications, even their parts, may have different this dependency."
Also hängt es natürlich im Einzelnen davon ab, WELCHE Befehle eingesetzt werden, weil die Taktzyklen, die Befehle auf neuen Rechnern weniger brauchen, natürlich nicht "linear" sind - hinzu kommt, daß es manche Befehle oder Adressierungsarten auf älteren CPUs noch gar nicht gab und man durch Befehle, die "mehr können" oder durch mehr verfügbare und größere Register auch mehr Rechenleistung einsparen kann.
Und das betrifft nur die CPU!

Es gibt ja auch noch den Bustakt - und der bestimmt die Geschwindigkeit von allem was außerhalb der CPU passiert, was eine ganze Menge ist: Alle RAM-Zugriffe, Zugriffe auf Peripherie und Kartenslots... usw. Bei Zugriffen auf RAM kann die CPU teilweise "cachen", bei Zugriffen auf Grafikspeicher-RAM aber nicht. Die Grafikkarte liest nicht im CPU-Cache nach, ob vielleicht manches noch nicht "zurückgeschrieben" ist, die erwartet alles in ihrem RAM. Das gleiche gilt für Soundpuffer: Der DMA schaut auch nicht in der CPU nach - die Daten müssen im RAM liegen.

Das sind alles Dinge, die man, wenn man einen PC emuliert nur schätzen kann, weil jedes Programm (also auch jedes Spiel) auf jedem PC anders performt, weil alle Hardwarekomponenten da mit reinspielen. Daher gibt es Mindestanforderungen, weil man natürlich bei einem komplexen Programm gewisse Mindestvoraussetzungen festlegen muß - es sei denn, es soll alles auf Hercules-Mono mit PC-Speaker auf einem PC XT mit 8088 CPU, 4,77 MHz laufen (und die ersten PCs hatten übrigens nicht mal alle die vollen 640 kB RAM!)
Je mehr das Programm können soll, umso mehr Systemleistung/Speicher usw. wird mindestens benötigt.

So ein 486er ist schon eine recht passable Maschine, damit läßt sich viel anfangen und an sich ist er geeignet, um jedes denkbare 2D-Spiel abzuspielen. Allerdings gibt es 486er eben auch in vielen Ausführungen mit vielen Grafik- und Soundkarten, mehr oder weniger Speicher, mehr oder weniger CPU- und Bustakt. Und der Unterschied zwischen einem 486SX 25MHz mit orginal VGA (ISA) und einem 486-X5 133MHz mit SVGA (PCI) sind WELTEN. (Ohne Übertreibung.)
zatzen hat geschrieben:Seit meines Bewusstwerdens mit dem "man sieht erst im übernächsten Frame die Auswirkungen seiner Entscheidungen" bin ich mir gar nicht mehr sicher, ob ich überhaupt noch ernsthaft ein Spiel machen möchte.
Irgendwie muss dieses Problem erst gelöst werden, entweder indem ich alles so löse wie Du,
oder vielleicht fällt mir doch nach langer Grübelei noch eine Alternative ein.
Naja, mein Ansatz ist ja nicht das "Maß der Dinge" und auch lange nicht die einzige Möglichkeit, Spiele zu schreiben.
Beispiele:
Wenn man nicht mehr als 10 bis 30 Sprites auf dem Bildschirm vorraussetzt (und viele normale 2D-Spiele haben kaum mehr!) und auch kein Scrolling benutzt, so hat man schon einmal die Notwendigkeit eliminiert, jedes Bildframe komplett neu zu generieren, sondern kann das Ganze auch lösen, indem man nur die Sprites löscht und setzt.

Wenn man bestimmte Dinge ausnutzt, die die Grafikkarte hardwaremäßig kann, so kann man noch einiges mehr "sparen". Die Grafikkarte hat z.B. auch "Softscrollregister", d.h. man kann den Bildschirm nach links/rechts hardwaremäßig hin und her verschieben - eigentlich um 0 bis 8 Pixel (ja, nicht 0-7 sondern 0-8, also insgesamt 9 Pixel Reichweite) - aber weil der MCGA (320x200x256), also der Mode $13, ein "Spezialmode" ist, den man aus CGA und EGA zusammengewurstelt hat und der nicht nur Zeilen, sondern auch Spalten verdoppelt, sind es nur 0-3 Pixel.
ABER: Auch wenn man 0-3 Pixel schieben kann, dann könnte man, geschickte Programmierung vorausgesetzt, ja trotzdem effiziente, auf "4er" ausgelegte Routinen schreiben, die immer nur an /4 teilbare Positionen schreiben und alles als DWords, indem man zusätzlich die Softscrollregister ausnutzt...
Das "Blanken" an der linken/rechten Seite sollte noch das geringste Problem sein (C64 hat so etwas hardwaremäßig, weiß gerade nicht, ob die VGA sowas nicht hat, aber es sollte doch mit dem Teufel zugehen, wenn nicht. Normal kann man da jeden Scheiß einstellen...)

In Kombination mit dem Mode-X wäre es noch effizienter. Und ja, das klingt immer wie Hexenwerk. Aber der Mode-X erfordert nur 4 Dinge, nämlich einmal: Wechsel auf normalen 320x200x256 (Mode 13h) und danach Zugriffe auf 3 verschiedene VGA-Register. Und das nur einmalig, dann ist der Mode gesetzt. Da hat man dann 4x64kByte Speicher, nur etwas komisch angeordnet: Jede Speicherstelle gibt es 4x an derselben Stelle, nur auf einer anderen "Plane". Wenn man seine ganzen Routinen aber so baut, daß sie senkrecht arbeiten, dann braucht man die Plane nur in jeder Spalte wechseln. Wenn man es noch schlauer macht, und von der Grafik immer jede 4. Spalte zeichnet und dann die Plane wechselt und dann wieder jede 4. Spalte... Dann braucht man noch weniger Planewechsel...

Und weil man ja "mit plötzlich so viel Grafikspeicher" Platz für mehr als eine Grafikseite hat, braucht man nicht einmal irgendwelche RAM-Puffer haben, die man am Ende in die Grafikkarte kopiert, sondern "zeichnet" einfach auf dem Grafikspeicherbereich, der gerade nicht als Bild angezeigt wird und schaltet um, wenn man fertig ist... - also: RAM gespart UND Umkopieren gespart.

Und ob Grafiken nun waagerecht oder senkrecht irgendwo gespeichert sind, sollte ja egal sein. Wie man sein Zeug anordnet, das kann man ja vorher durch einen Computer entsprechend machen lassen. Nehmen wir an, man hätte eine fertige Routine (ZVID oder wasauchimmer) die gepackte Grafiken darstellt. Man könnte sie einfach um 90° gedreht arbeiten lassen d.h. spaltenweise statt zeilenweise arbeiten, und zusätzlich nach jeder Spalte die Plane wechseln (und nach 4 Spalten den Speicher-Offset) und alles was man ändern müßte, wäre, die Grafik dafür im Speicher um 90° in die andere Richtung gedreht vorliegen zu haben (was ja auch kein Hexenwerk ist), und es würde genauso aussehen, könnte aber mit Mode-X arbeiten. Und in Mode-X, weil man ja 256 kByte Speicher hat, könnte man die Scanline auch so breit machen wie man will und das Scrolling wäre kein Problem.

Wieso? Naja, um 0-3 Pixel scrollen geht ja hardwaremäßig. Und um 4 Pixel scrollen geht ja, indem man einfach die Speicherstartadresse des Bildes um 1 Byte erhöht. Schon hätte man 8-Pixel-Scrolling und könnte alles auf 8-Pixel-Breite/Höhe auslegen. Die paar VGA-Portzugriffe sind PillePalle, das kann man überall nachlesen - auch der nette DOSferatu hat das alles da...

Klar - damit geht natürlich dann NICHT sowas wie "Scrolling mit mehreren Ebenen" und wenn man überlappende Sprites hat, muß man beim Löschen/Setzen aufpassen... Wollte nur sagen: Es ist nicht so, als gäbe es nicht auch andere, teils hardwareseitige Wege, um Dinge performant zu machen.
Wer Turrican 2 für DOS gesehen hat und dann sieht, auf was für Maschinen das Ding immer noch flüssig läuft und das mit DIESER Grafik und DIESEM Sound - der kann einschätzen, was mit einer DOS-Maschine WIRKLICH möglich ist, wenn man sich bemüht.
zatzen hat geschrieben:Aber generell gilt: Ich programmiere wirklich nur zum Spaß und nebenbei, es ist nur vielleicht 20% meiner Hobbyaktivität.
Naja, ich programmiere auch nur zum Spaß. Ich verdiene kein Geld damit und bin kein Profi. Alles nur Hobbykram und natürlich bin ich auf viele Dinge, die ich benutze, NICHT selbst gekommen. Aber es gibt ja die ASM86FAQ (und ja, da steht auch drin wie Mode-X gemacht wird!) und die SWAG (umfangreiche Sammlung von Lösungen für Pascal ohne oder mit Assembler) und ähnliches Zeug. Manches habe ich auch aus anderen Dokus/Listen zusammengekratzt und zusammengefaßt.
zatzen hat geschrieben:Deshalb wäre ich auf dem Gebiet schon froh, etwas vorzeigbares zu haben, auch wenn es trotz viel Assembler die Ressourcen nicht voll ausnutzt.
Geht mir doch auch nicht anders. Wer weiß, ob der Kram, den ich hier so einzeln herumliegen habe, wenn ich ihn zusammenschraube und alles zusammenarbeiten muß, überhaupt noch genügend performt? Kann ich nicht sagen - weiß ich einfach nicht.

Man weiß eben nur: Alles, was ein Programm machen muß, wird unweigerlich Platz im Speicher belegen UND CPU-Zeit beanspruchen. Und wenn alles zusammengenommen immer noch zusammenarbeitet, ohne daß eins das andere behindert und ohne daß wichtige Prozesse nicht angestoßen werden, weil gerade noch andere Prozesse zu beschäftigt sind, dann funktionierts. Und wenn es so nicht funktioniert, kann man entweder sagen: Mindestanforderung: Maschine X und für alles unter X eine Fehlermeldung ausgeben
- ODER -
Optimalanforderung: Maschine X, Mindestanforderung; Maschine Y, mit gewissen Einschränkungen.

Auf C64 konnte man natürlich sagen: Läuft immer und überall (OK, leichte Unterschiede zwischen NTSC- und PAL-Version), weil CPU immer gleich schnell, Speicher immer gleich groß, Chips immer gleiches Verhalten, Ansteuerung braucht immer gleiche Zeit... usw. Auf Maschinen mit variabler Hardware ist das eben nicht so - da ist Programmieren "am Limit" eher ein totaler Pain-in-the-Ass.

Und ICH finde es immer cool (kann jeder anders sehen), wenn jemand, der die Super-Maschine hat, diese auch richtig ausnutzen kann, weil dann eben alles möglich ist (Musik volle 44kHz, Grafik volle Auflösung, volle Hintergründe usw) und jemand, der NICHT die Super-Maschine hat, sondern irgendso ein Worst-Case-Modell, der dann eben bestimmte Reduzierungen einstellen kann, aber trotzdem das Spiel haben/testen kann.

Wenn man andererseits alles für "hinterletzte Maschine" baut, kann man eben immer nur kleines langsames Zeug machen, das nicht viel hermacht, weil es die Hardware nicht hergibt und was auch auf "besseren" Maschinen nicht besser aussieht oder klingt. Das beschränkt natürlich die Möglichkeiten, die man am Ende hätte.

Zusätzliche Off-Topic-Information:
Momentan arbeite ich am "Rahmen" für die Komplett-Spiel-Engine, die dann also alles, was Steuerung, Grafik, Sound usw. hergibt und irgendwie von mir gemacht und dafür brauchbar ist, enthalten kann. Das ganze Ding wird am Ende wohl wirklich auf ein "Game-Maker" artiges Ding hinauslaufen, allerdings nicht nur mit einem "Fertigdatenfile", das mit einer EXE verbunden wird, sondern die EXE wird abhängig von einem Skript compiliert (in Pascal natürlich, also von TPC.EXE), mit vielen Compilerschaltern und zusätzlich einfügbarem Code. Die ganzen Datenfiles sind von externen Tools zu erstellen, die aber innerhalb der ganzen Entwickungsumgebung aufgerufen werden.

Ich will keinen "Universell-EXE-Klotz" haben, weil man dann viel Zeug supporten muß, was vielleicht für das zu bauende Spiel gerade gar nicht gebraucht wird, was dann aber Speicher belegt, den man für Zeug, das man wirklich gern hätte, nicht mehr hat. Daher die Lösung mit dem EXE-Template. Die Units werden dann entsprechend (je nachdem, ob benötigt) eingebunden.

Das Ganze wird natüriich modular sein, ist deshalb auch für künftige Dinge erweiterbar - d.h. falls es mal neue Grafikroutinen oder Soundroutinen geben sollte, könnten diese natürlich ebenfalls angepaßt und eingebaut werden.

Und ja, das wird jetzt nochmal ein mittlerer Aufwand - aber ich sehe kaum eine andere Möglichkeit, um da einen vernünftigen "Workflow" am Spiel selbst zu ermöglichen. Wenn man sich ständig um Dinge kümmern müßte, die eigentlich genau durch die Units und die schon vorgegebenen Dinge erledigt werden sollten, käme man wieder nicht darum, das eigentliche Spiel zu machen, sondern wäre immer nur dabei, es lauffähig zu bekommen.

Allerdings wird das Ganze kein richtiger Game-Maker werden - Kenntnisse in Programmierung und (Spiele-)Entwicklung, sowie zur Funktionsweise von PCs, von (Turbo-)Pascal usw. werden vorausgesetzt. Eine gewisse "Nacharbeit" wird man immer noch haben. Das Szenario "oben irgendwelche Daten reinschmeißen und unten kommt das fertige Spiel raus" wäre eher etwas für sehr moderne, sehr schnelle Rechner, die jeden Kram emulieren können. So etwas ist meines Erachtens auf einem durchschnittlichen DOS-Rechner nicht möglich.

OK - dem steht entgegen, daß es unter DOS auch Emulatoren gibt, die komplette 8bit/16bit-Konsolen-Spiele oder C64-Spiele emulieren können - ABER: Diese Konsolenspiele oder C64-Spiele wurden eben auch auf den Originalsystemen sehr systemnah und performant entwickelt.

Das heißt: Ich KÖNNTE natürlich aus diesem neuen "Spielrahmen" eine Art "virtuelle Maschine" machen, die in etwa Fähigkeiten wie eine Konsole hat, mit einstellbaren festgelegten Grafikmodes, Sprites, Leveldarstellung, Grafik, Sounds, Steuerung... und: Teilweise ist wird es auch genau das! Aber ich will es nicht vollständig so etwas werden lassen. Das wäre zwar möglich - aber dann müßte man als Spiele-Entwickler eben auch damit entwickeln wie für so eine Konsole und man wäre auf die eingestellten Möglichkeiten beschränkt.

Ich bin da immer noch am Überlegen. Das Ding heißt nicht umsonst SLOT. Es ist quasi ein gedachter "Game-Slot", ein Steckplatz, wo man das Spielmodul einsteckt und es funktioniert, Weil die "Konsole" aber nur Software ist, ist das einzig "echte" der Steckplatz selbst, daher SLOT. Aber aus o.g. Gründen (weil dann eben im Speicher auch Zeug liegen würde, was man evtl nie benutzt) wähle ich den leicht abgeänderten Ansatz. Im konkreten Fall wird es so aussehen, daß ein Skript angibt, was gemacht werden soll, woran dann auch erkannt wird, was gebraucht wird, und nur diese Teile werden eincompiliert.

Im fertigen Produkt könnte der "Code" dann also nicht auf Dinge zugreifen, die nicht eincompiliert wurden, was aber nicht passieren wird, weil man das ja selbst festlegt. Da muß man dann eben abwägen: Wer "alles mit allem" will (ohne daß er's braucht) steht am Ende ohne Speicher da...

Ich kann es vielleicht nicht so gut erklären, weil es so theoretisch ist und da das Ding noch nicht 100% fertig ist, will ich da noch nicht zu konkret werden, weil ich mich da bei manchen Dingen selbst noch nicht festgelegt habe.

Im besten Fall könnte dabei aber wirklich eine Entwicklungsumgebung herausfallen, mit der jeder, der einigermaßen programmieren kann, ein 2D-DOS-Spiel hinbekommen könnte.
Achja: Eine 2D-Adventure-Subunit habe ich übrigens noch nicht gebaut. Für Adventures wäre also hier noch etwas mehr "Eigeninitiative" nötig. Allerdings wüßte ich schon 100%, wie ich ein Adventure bauen würde.

Und ja, das war wahrscheinlich wieder mehr Text als nötig.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 2. Sep 2018, 15:01
von zatzen
Noten:
Ich verwende(te, vor allem früher) gerne auch mal einfach einen kompletten Dur-Akkord als
Sample, mit dem ich dann auf verschiedenen Tonhöhen unterwegs war. Klingt auch nach Musik,
ist aber total gegen die Regel der Klassik mit ihren Tonarten.

Ich mag SID Musik auch... Naja und die Pattern-Darstellung mit ihren vielen Nullen dient
einfach der Übersicht und Intuition, und moderne Tracker gingen ja dann auch dazu über
die Patterns einfach aber effektiv zu komprimieren. Es gibt da auch irgendeine trackerartige
Software wo alles datenmäßig sehr kompakt gehalten wird durch Makros etc. Aber das
wäre mir zu hoch bzw. zu unintuitiv. Letztlich will ich Musik machen - zum Programmieren
und Großhirn anstrengen habe ich Pascal und Assembler.

Spiel mit Samples zuknallen:
Ich würde es eher anvisieren, ein Spiel mit relativ wenig Grafikdaten (Vielleicht 128K) zu machen
und dazu 64K Sound - als Herausforderung, datenmäßig beim Ton auch minimalistisch und
sparsam vorzugehen. ZSMs die nur große Samples aneinanderstückeln finde ich ja auch
technisch langweilig.

Jederzeit in ZSM Samples starten:
Das geht "von außen" natürlich immer nur am Anfang des nächsten Puffers.
Was ZSM aus den Patterns liest kommt aber absolut zeitrichtig in den Puffer,
auch mehrere Sample-Starts innerhalb einer Pufferlänge, sonst würde das
ganze ja auch nicht funktionieren.

ISM hat also sozusagen eine serielle Datenverarbeitung, bezogen auf eine Stimme.
Und die muss dann vereinfacht gesagt nur die Informationen Länge und Tonhöhe haben.
Ist mir von Anfang an auch klar gewesen, und ich kann diesen Ansatz verstehen, er
erscheint am logischsten zumindest wenn man ihn direkt mit unkomprimierten
MOD Patterns vergleicht, wo eine "Leernote" direkt 4 Byte frisst.
Zudem entspricht er eher der Idee der Notenschrift, wo im Zweifelsfall die Notenlängen
zählen, und nicht unbedingt was parallel notiert wird.
Bei meiner ZSM Komprimierung ergibt sich aber unterm Strich sehr wenig Datenauflauf,
weil je nachdem die Tonhöhenparameter mit wenigen Bits auskommen und Leerzeilen
entweder Track-Weise mit nur einem Bit vermerkt sind oder auch ein einzelnes Bit
eine komplette Leerzeile einer ganzen Patternbreite deklariert.
Eine simple Hihat-Spur wo einfach eine Hihat auf jedes 8tel kommt würdest Du
wohl in ISM als Schleifenfunktion programmieren. Bei ZSM ergibt das Redundanz,
allerdings würde die gesamte Hihat-Spur nur 1 Bit pro Zeile verschlingen, und
somit nur 8 Byte aufs ganze 64-Zeilen-Pattern gerechnet. Okay, eins darf ich
nicht verschweigen: Jede Spur braucht pro Pattern und Spur eine Tabelle, für diese
Hihat enthält diese allerdings auch nur einmal die Information, auf welcher Frequenz
sie gespielt wird, das wird mit 5 Bit beschrieben, da die Frequency Tables
maximal 32 Werte haben dürfen. Aber das weißt Du schon alles, es macht
nur irgendwie Spaß... u.a. soetwas ist eben der Grund warum ich gerne programmiere,
es sind meistens Dinge von denen der User gar nichts mitbekommt.

Nur zur crazy Pufferaktion: Für eine klangliche Vorschau für das was man ins Pattern
programmiert würde es auch reichen, wenn man es erst im nächsten Puffer hört.
Vorausgesetzt der Puffer ist nicht allzu groß.

Im ZSM Player kann man Kanäle aus und an schalten, ich meine es wird dann einfach
bei einem wiedereingeschalteten Kanal gewartet, bis ein Sample wieder "auf dem Plan steht".

Pattern Break:
Das ist auch eigentlich nur ein MOD-Relikt, weil da die Patterns klotzig und steif immer
1024 Byte sein mussten. Bei X-Tracker gibt es keinen Break Befehl, sondern man kann die
Länge eines Patterns zwischen 1 und 256 Zeilen variieren.

10-30 Sprites:
Ich denke, mehr Ansprüche hätte ich da auch nicht.
Wie würde das mit dem nur Löschen und Setzen der Sprites aussehen?
Die einfachste Methode sieht man ja zu hauf an vielen Amateur-Spielen:
Es flackert.

Die weiteren Methoden, auch mit Scrolling, die Du angeführt hast, sind interessant,
aber im Moment noch zu hoch für mich, da ich ja überhaupt erstmal ein Spiel mit
transparanten Sprites und Hintergrundgrafik machen will.

Ich glaube, das mit SLOT verstehe ich schon einigermaßen. Man könnte sagen, Du
könntest die individuellen Features als Units optional reinpacken, aber ich glaube
das Finetuning ist noch genauer.