Trackermodul-Engine (sehr einfach)

DOSferatu
DOS-Übermensch
Beiträge: 1123
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitragvon DOSferatu » Do 2. Aug 2018, 21:06

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

Re: Trackermodul-Engine (sehr einfach)

Beitragvon zatzen » Di 7. Aug 2018, 20:27

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

Re: Trackermodul-Engine (sehr einfach)

Beitragvon DOSferatu » Sa 11. Aug 2018, 10:10

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

Re: Trackermodul-Engine (sehr einfach)

Beitragvon zatzen » Sa 11. Aug 2018, 19:20

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

Re: Trackermodul-Engine (sehr einfach)

Beitragvon DOSferatu » So 12. Aug 2018, 09:36

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

Re: Trackermodul-Engine (sehr einfach)

Beitragvon zatzen » So 12. Aug 2018, 20:03

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

Re: Trackermodul-Engine (sehr einfach)

Beitragvon DOSferatu » Sa 18. Aug 2018, 12:00

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.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast