Du baust selbst Lautsprecher?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.
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: 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.
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:Dass Du eine Tracker GUI für ISM geschrieben hast ist doch großartig, zumindest für mich.
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: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, 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: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.
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: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.
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: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.
Das ist gut.zatzen hat geschrieben:Letztere kann man von außen triggern, unabhängig von der Musik, ja.
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.
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: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.
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:Ich bin erstmal überhaupt froh, eine performante Sache mit simplem "warten auf Tonpuffer abgespielt" bzw. "ist die Dauer eines Frames rum?" hinbekommen zu haben.
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:Du hast mir schon oft genug gesagt dass das ein No-Go ist,
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.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.
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".
Da denk ich grad an Ralph Ruthe's Figur Thorsten Dörnbach: "MÄNSCH, DAS IS DOCH DEIN ALTA JUGENDTRAUM!"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.
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...
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.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.
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!
Naja, ich weiß nicht, vielleicht kann ich es einfach nur schlecht erklären.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.
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...
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: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.
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: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.
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: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, 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: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.
Ja, damals habe ich das Internet kaum gekannt und auch nicht ernstgenommen. Heutzutage ist das Ding so totale Normalität geworden...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, 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: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.
Tja - wieso nicht?zatzen hat geschrieben: Spiel auf Sound auslegen:
Ich hatte sogar schonmal die Idee ein Text-Adventure zu machen mit Ton...
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: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.
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: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.
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: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.
Ja, "Jill of the Jungle" hatte auch so blockweises "scrolling" und sehr krasse (und laute!) Soundeffekte... aber wieso auch nicht?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.
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.
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: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).
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: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.
Naja, Du siehst das Ganze aus der Sound-Sicht, hab ich den Eindruck.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.
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.
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.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 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.