zatzen hat geschrieben:Hallo!
Ja, hallo erstmal.
zatzen hat geschrieben: [...] mache ein neues Album daraus. Vielleicht schaffe ich das noch bis Ende dieses Jahres. Je nachdem sind das teilweise noch 4-Kanal MODs mit vielen 8 kHz Samples - ich suche die Quellen raus von denen ich damals gesamplet habe (habe einiges auf Kassetten gefunden und suche aber noch) und restauriere das alles. Ich erfülle mir da einen kleinen Traum, produziere nochmal die Sachen ab 1994 mit den technischen Möglichkeiten die ich heute habe. Das ist nicht nur nach dem Motto "Kristallsound" sondern erlaubt jetzt auch die uneingeschränkten gestalterischen Ideen, die damals technisch begrenzt waren.
Was meinst Du eigentlich immer mit "Album"? Gibt's CDs von Dir zu kaufen?
zatzen hat geschrieben:Programmiert habe ich mir dafür auch noch schnell etwas, ich brauchte ein Tool das mir die Samples aus X-Tracker Modulen als vernünftig benannte und mit korrekter Samplerate versehene WAV Dateien rausholt. Kein großes Ding, aber musste gemacht werden. Und dabei durfte ich nochmal erleben wie wunderbar klar sowas geht mit gut strukturierten Binärdateien. Ich hatte auch schon angefangen für Renoise ein Tool zu bauen (damit ich damit musikalische Videos machen kann) aber so ein XML erscheint mir doch etwas haarig. Irgendwie so seriell, eben wie HTML, Strukturen werden nicht angekündigt durch nen Zähler sondern sie kommen einfach. Irgendwie müsste ich da auch etwas System reinkriegen, bisher ist alles nur provisorisch. Man muss das wohl regelrecht "parsen" bzw. gewissermaßen kompilieren.
Nicht nur "gewissermaßen". Es muß geparst werden. XML ist ein total aufgeblasener Mist. Alles "menschenlesbare" Parameter - also braucht man ein großes "Wörterbuch"-File dafür, desweiteren akzeptiert/benutzt es Verschachtelung - aber ohne Definition, wie tief verschachtelt werden kann... usw. Dafür 'n Tool zu bauen, ist die reine Pestilenz.
Wieso wird dann dieser Scheiß benutzt? - Aus Faulheit: Die heutigen OS bieten den Kram gleich als API oder Ähnliches an und es braucht nur "eingebaut" zu werden. Daß es aufgeblasene Files erzeugt und daß sowohl zum Schreiben als auch zum Lesen intern ein extremer Aufwand betrieben werden muß, scheint ja keinen zu interessieren, solange irgendwer anders schon den Code dafür geschrieben hat...
Es gäbe andere, einfachere Möglichkeiten, z.B. in der Art der "INI"-Files. Auch "menschenlesbar" - aber auch
wirklich Menschen-editierbar. (Ehrlich: wer will so einen XML-Mist von Hand editieren?) - Wenn man's denn überhaupt menschenlesbar braucht.
Wenn's rein binär ist, ist der Vorteil: Kleinere Files, kein Parser nötig, keine "fehlerhaften" Dinge möglich. Da muß kein Parser "herumraten", ob man das vielleicht noch als valide Daten gelten lassen sollte oder nicht. (XML/HTML und eigentlich jeder Skript-Kram gehört ja zu den "fehlertoleranten" Markup-Codes.)
Wenn bei einem XML durch irgendwelche unsauberen Sachen das "Sublevel" nicht korrekt geschlossen wird (fehlende Klammer, fehlender Abschlußbefehl) - ist ein unübersehbares Chaos produziert... - das dann manche Parser noch versuchen, aufzuräumen. Ich frage mich wirklich, wieso immer noch Leute an diesem XML-Mist festhalten... - Das war mal so'ne Modeerscheinung, weil man dachte, verschachtelbare Einheiten und endlose Erweiterbarkeit wäre eine tolle Idee. Aber es hat eben zu dem geführt, was immer passiert, wenn man irgendwas mit "zu vielen Freiheiten" rausbringt: Dumme Leute reizen das bis zum Anschlag aus und erzeugen damit sinnlos abartige Datenmengen, die abartige Codeklumpen brauchen, um es zu verarbeiten.
Der Grund dafür ist auch, daß sich kaum noch einer mancher heutigen "Programmierer" (Quotes beabsichtigt!) die Mühe macht, zu verstehen, was sein komischer Skriptcode im Inneren der Maschine eigentlich anrichtet...
zatzen hat geschrieben:Sicherlich habe ich demnächst dann wohl viel mit Musik zu tun, aber das muss nicht heissen dass deswegen das Programmieren total versiegen wird. Ich denke eher, durch mehr kreative Aktivität kommt der Stein allgemein mehr ins Rollen. Trotzdem ist mein jetziger Standpunkt (der sich aber ändern kann), dass ich lieber ein kleines Spiel machen möchte das nicht so viel Arbeit bedeutet.
Ja, wenn man etwas findet, was einen begeistert (wie in Deinem Fall z.B. die Musik), verbessert das die allgemeine Laune/das allgemeine Befinden und gibt dann auch wieder Kraft für andere Projekte.
zatzen hat geschrieben:Ob Mode-X notwendig ist, ist fraglich.
Notwendig ist schonmal garnix. Hatte ich auch in anderen Threads/Beiträgen schon erwähnt: Es nur zu benutzten, "weil es geht", "weil jemand anders damit etwas hingekriegt hat" oder "weil's irgendwer cool findet", wäre der falsche Ansatz. Wenn man es nicht wirklich gebrauchen kann - d.h. die Besonderheiten einer bestimmten Technik/Modus/wasauchimmer nicht für seine Zwecke benutzen kann, bzw. keine Vorteile daraus ziehen kann, besteht keine Notwendigkeit, es zu benutzen.
zatzen hat geschrieben:Sauberes 4:3 mit quadratischen Pixeln wäre schön, aber mit meinen derzeitigen Kenntnissen über Mode-X würde die Erschliessung dessen möglicherweise halb so lange dauern wie die Programmierung des ganzen Spiels.
Du immer mit Deinen blöden quadratischen Pixeln! Auf C64 hat mich auch nie gestört, daß die Pixel nicht quadratisch sind und auch sonst ist das sowas von unwichtig und egal. (Ich weiß nicht, ob sich irgend ein Spieler bei DOOM oder Monkey Island oder den unzähligen anderen 320x200-DOS-Spielen jemals drüber aufgeregt hat "daß die Pixel nicht 100% quadratisch sind"...) komme später auch noch darauf zurück.
zatzen hat geschrieben:Motiviert wäre ich nach wie vor auch durch meine Spielerei mit ZVID2, die sich in Mode-X so wie ich das sehe ziemlich kompliziert gestalten würde.
Ja, wie schon erwähnt: Mode-X (bzw. alle "Mode-X"-artigen Modi, also alle "unchained") sind nur dann von Vorteil, wenn man seine Routinen direkt dafür schreibt oder direkt daran anpaßt. Generelles, vor allem auf "Zeilen"- oder "Block"-weise Abarbeitung ausgerichtetes Zeug (anstatt, wie bei Mode-X, eher spaltenweise und "split-block"-mäßig) wird, wenn man es einfach nur "auf Mode-X umbiegt" performancemäßig total in den Keller gehen.
Der Vorteil der Mode-X Dinge ist zweierlei:
1.) Durch das Unchaining kann man mit einem einzigen Befehl gleich 4-16 Pixel setzen.
2.) Man hat statt 64kB volle 256kB Grafik-RAM, dadurch Platz für größere Auflösungen als 320x200 und mehr als 1 Bildseite.
Nachteil ist: Weil der Mode-X eigentlich ein zurückge-"tweak"ter MCGA ist (der MCGA ist nämlich eigentlich ein Tweak), ist die Adressierung etwas gewöhnungsbedürftig.
zatzen hat geschrieben:Wie gesagt bin ich Mode-X absolut nicht abgeneigt, d.h. wenn ichs erstmal gerafft habe. Ansonsten freuen sich alle sicherlich am meisten wenn ich einfach ein Spiel raushaue das Spaß macht, selbst wenn es steinzeitliches MCGA ist oder gar per Soundpuffer getaktet - immerhin Sound abschaltbar und dann über Timer.
Wie schon gesagt: Außer Dir kenne ich keinen, der sich jemals über die nicht ganz quadratischen Pixel in 320x200 ereifert hätte. Man kann's auch echt übertreiben...
zatzen hat geschrieben:Mode-X und nicht-per-Soundpuffer timen sind meine Ziele, aber ich kann das aktuell noch nicht. Ich werde da keinem Ideal gerecht wenn ich es so mache wie ich es momentan nur kann, aber wenn das Spiel Spaß macht, was soll's. Es wird dann eher so sein dass es einen 486 braucht obwohl es anders programmiert auch auf einem langsamen 386 funktionieren würde.
Ach naja - mein Zeug braucht auch alles wohl schnellen 486er. Durch Vorhandensein einer solchen Kiste wird man irgendwie versaut. Wenn ich auf 386er entwickeln würde und
sehen würde, wo es bremst, wäre ich wohl ganz anders beim Optimieren. Aber mein 486/X5 (133 MHz) inkl. des Motherboards hier ist quasi so das beste unterhalb Pentium, was überhaupt zu haben ist...
Manchmal schäme ich mich für mein lames Zeug. Aber zum Glück interessiert sich kaum jemand für den Müll.
zatzen hat geschrieben:Oder - ich mache AdLib + One-Shot DMA Digisound. Naja, ich laber mich hier schon wieder aus allem raus. Einfach mal sehen was wird. Ich möchte ZVID2, das Ding mit den 4x4 Blöcken für Sprites verwenden - auch wenn das Performance kostet, aber das ist für mich interessanter, auch wenns keiner versteht.
Ja, um es mal ganz blasphemisch auszudrücken:
Ich kann mir nicht vorstellen, daß ein Zocker 2 Spiele sieht/spielt und das eine performt mehr (FPS) als das andere und der findet das andere besser - und zwar, weil, es die komplexeren internen Routinen hat. Wenn die komplexeren internen Routinen das Endergebnis nicht rechtfertigen, hab ich meine komplexeren Routinen auch schon öfter mal gegen etwas einfacheres (zurück-)getauscht.
Hatte es ja schonmal erwähnt: Habe schon Zeug gebaut, was Performance und Speicher sparen sollte - am Ende hat das Zeug (der Code) selber mehr Speicher verbraucht als er an Daten gespart hat UND war zusätzlich noch langsamer als vorher, weil aufwendigerer Code. Also am Ende: Gewinn Minus 200%. Da ist es dann zwar schade um die ganze Mühe. Aber wenn die Mühe nicht das gewünschte Ergebnis bringt, find ich's noch mehr schade, ein an sich gutgemeintes Projekt damit zu versauen, nur weil's mir um die Mühe leidtäte.
Aber das muß natürlich trotzdem jeder selbst wissen. Ich weiß auch, daß man ungern Zeug "wegschmeißt", in das mal so viel Mühe reingesteckt hat. Aber ich sag's, wie erwähnt, mal ganz blasphemisch:
Niemand außer einem selbst, wird das zu würdigen wissen. Die anderen sehen nur das Endergebnis - nicht den Code und auch nicht die Zeit+Mühe, die es gekostet hat.
zatzen hat geschrieben:Gleiche Sache mit ZSM, das kostet vor allem Performance wegen der Delta-Codierung der Samples. Aber auch da fasziniert mich dass es klein ist und trotzdem vernünftig klingt.
Naja, hier hat der einseitige Performanceverlust ja eindeutig einen anderseitigen Gewinn: Files auf weniger als die halbe Größe (Samples) zu kriegen und Daten noch kleiner - und das,
ohne daß das Endergebnis wirklich dermaßen reduziert klingt, wie es bei dieser Ersparnis eigentlich müßte - das ermöglicht mehr Platz für mehr Sound, Levels, Grafiken... Das ist also nicht "umsonst".
zatzen hat geschrieben:Mode Q fand ich noch interessant - nutzt komplette 64K und hat 256 Zeilen. Die direkte X/Y Adressierbarkeit spielt für mich wohl keine Rolle.
Und dabei ist das ziemlich cool, diese direkte Adressierbarkeit.
zatzen hat geschrieben: Wirklich interessant fände ich den Modus wenn er kein quadratisches sondern 4:3 Bild erzeugen würde und die Pixel dann auch jeweils 4:3 wären.
Der Modus erzeugt ja auch kein quadratisches, sondern ein 4:3-Bild! Und sieht dann genau so geil "8-Bit-konsolen-mäßig" aus, wie man denken würde!
Daß er bei Dir quadratisch aussieht, liegt daran, daß Du einen Emulator benutzt UND (aus Performancegründen?) die Ratio ausgeschaltet hast.
Mit anderen Worten: Auf der echten Maschine
IST der 4:3 und die Pixel auch!
zatzen hat geschrieben:Ich weiss nicht ob man das entsprechend "tweaken" kann, aber wenn, dann fände ich das interessant, es wäre dann ein ähnlicher Bildmodus wie das NES mit seinen 256x240, wobei da die Pixel glaube ich auch 4:3 sind.
Und das ist die Stelle, die ich oben erwähnt habe. Einerseits immer dieses (inzwischen zugegebenermaßen schon leicht nervige) "die Pixel sind nicht quadratisch, ogottogott, was solln die Leute denken?" - aber andererseits an dieser Stelle kein Problem mit den nichtquadratischen Konsolenmode-Pixeln haben. Daß die "Klötze" in Super Mario und Alex Kidd so cool rechteckig sind, liegt ja genau an diesem 256 breiten und 256/240 o.ä. hohen Bild, denn es sind intern natürlich 16x16-Pixel Klötze. Und ja, meine Unit, die die ganzen MCGA und Mode-X Dinge macht (verschiedenste Auflösungen) enthält auch den 256x256 (und auch 256x240 und 256x"n Haufen andere") und wenn Du willst, kannst Du das ja bei Dir testen, um zu sehen, wie das bei Dir aussieht.
zatzen hat geschrieben:DOSferatu hat geschrieben:Wie Dir ja schon selbst ausgefallen ist, hat das GW-BASIC,[...]
GW-BASIC wäre ja dieses C64-ähnliche Ding. Es handelt sich hier um QuickBASIC, da hat man schon eine komfortable IDE welche die Subroutinen gesondert anzeigt, zudem braucht man keine Zeilennummern.
Ja, schon klar. Aber auch dieses QuickBASIC macht gegenüber Borland/Turbo-Pascal nicht viel her. Das wollt' ich damit eigentlich bloß sagen. Auf PC hatte ich - wie bereits erwähnt - nie in BASIC programmiert.
zatzen hat geschrieben:Es ist allerlei möglich, ich habe aber zu den Zeiten als ich damit arbeitete keine Analogie zu Pascals GETMEM gefunden, daher war ich auf das kleine Datensegment angewiesen, und mangels Units auch auf 64 KB Codesegment, die oft viel zu schnell voll waren, zudem im Interpreter-Modus größere Programme zuliessen als man kompilieren konnte, das war oft ärgerlich.
Ja, wie Dir ja aufgefallen ist, ging's mir weniger darum, wie das BASIC jetzt genau hieß, sondern darum, daß ich weiß, daß viele mit diesem "PC-BASIC" angefangen haben (ich nicht, icb bin gleich bei Pascal gelandet. Hatte diverse Gründe) und dann gemerkt haben, daß man damit "nicht viel anfangen" kann, weil man irgendwie an Grenzen stößt. Wenn man sich da nicht total reinhängt und für sich selber irgendwelche Tricks findet, macht man damit nur so "kindergarten-mäßgen" Kram, den man am liebsten keinem zeigen würde.
zatzen hat geschrieben:Bei Pascal würde mich am ehesten stören, dass die IDE viel Speicher belegt und man daher vielleicht nur 300 KB Speicher frei hat, aber sobald man kompiliert hat und das Programm ausserhalb aufruft hat man entsprechend mehr.
Erstens: Wenn das Programm gestartet wird, nimmt sich die IDE zurück. Zweitens kann man von der IDE aus "in DOS wechseln", dann belegt die nur noch so knapp 10kB resident und man kann das kompilierte Ding in DOS starten (ich kompilier immer gleich auf Platte, nie "in Speicher"). Drittens kann man sich ne BAT reintun, die z.B. sowas
C:\BP\BIN\tpc.exe programm.pas /L
aufruft und damit quasi "extern" kompilieren, falls das Programm mal in der IDE "zu groß" wird.
Viertens: Das Wichtigste: Wenn das Programm so groß ist, daß es da nicht mehr reinpaßt - obwohl das fertige Programm ja noch Daten nachladen würde (Sound, Grafik, Levels...) sollte man sich überlegen, ob man da nicht zu viel Code gebaut hat, der keinen Platz mehr für Daten übrigläßt.
zatzen hat geschrieben:Das spricht im Prinzip für die Entwicklung von Engines, so dass man die Daten designt und testet ohne die Pascal IDE parallel laufen zu haben.
Naja, meiner Meinung nach spricht noch viel mehr für die Entwicklung von Engines, als bloß das Vorhandensein einer IDE.
zatzen hat geschrieben:DOSferatu hat geschrieben:[...]Nichtmal byteweise arbeiten zu dürfen[...]
In 64 Bit Zeiten und wenn man es nicht mit Speicherkritischen Daten zu tun hat vielleicht irgendwie verständlich. Vieles wird als DWORD gespeichert wo ein Byte reichen würde, und ich selbst nutze in Freepascal oft WORD oder DWORD wo vielleicht auch BYTE reichen würde, weil ich Überläufe bei Kalkulationen befürchte, die ich zumindest in DOS Pascal kenne.
Für mich nicht mal "irgendwie" verständlich - sondern total unverständlich: Mehr Möglichkeiten zu haben - nur um damit nicht etwa für den User/Speicher coole Dinge zu machen, sondern nur aus Faulheit beschisseneren Code schreiben zu dürfen - da denke ich immer: Wenn das der technische Fortschritt bedeutet, dann kann ich darauf verzichten... (nur meine persönliche Meinung)
zatzen hat geschrieben:Also wenn man Byte * Byte rechnet kann es passieren dass das Ergebnis ein übergelaufenes Byte wird statt einem Word, oder so ähnlich. Kennst Du bestimmt. Dafür gibts ja aber das "Typecasting" word() oder was auch immer.
Immer diese Hochsprachen-Typen mit ihrer Panik vor dem bösen Überlauf! Überlauf-Prüfung hab ich generell AUS. Oft benutze ich sogar absichtlich Überläufe für irgendwelche Dinge. Und ja, man kann natürlich Überläufe kriegen, die man NICHT will. Aber selbst da ist es kein Hexenwerk, sich auszurechen, wie weit es mit den gegebenen Werten überlaufen kann. Ich bin ja auch kein Freund davon, bei selbstprogrammiertem Zeug immer so viel zu prüfen. Lieber einmal abstürzen lassen und dann in Ordnung bringen, als dauernd 'n Sicherheitszaun um alles zu ziehen, der den Kram groß und langsam macht.
zatzen hat geschrieben:DOSferatu hat geschrieben:Ja, SO komplex hab' ich's bei AtavISM nicht gemacht
Klar. Das ging in meinem Fall auch vor allem deshalb, weil die Daten nicht mehr verändert werden mussten, deshalb das Bit-packing.
Ja, schon klar.
zatzen hat geschrieben:DOSferatu hat geschrieben:Meine Stücke bestehen aus ... [Hauptmelodie, Begleitmelodie,Percussion... repetative Stücke, daher praktisch, wenn nicht überall zu ändern müssen]
Ja, im Grunde ist so ein Vorgehen sehr effizient und nutzt den Speicher optimal.
Naja, wie ich versuchte, zu erklären: Um Speicher geht's mir dabei nur sekundär.
zatzen hat geschrieben: Ich habe auch viele repetetive Elemente wenn ich etwas trackere. Aber es gibt auch ständig Veränderungen, und da wäre es für mich etwas fummelig wenn ich z.B. wie im Beni Tracker jedes mal diese Veränderung definieren müsste und dazu noch wo sie genau reinkommt.
Ach, da muß ich nichts "definieren". Ich füge das einfach ein.
zatzen hat geschrieben:AtavISM gibt sich ja nach aussen hin wie ein normaler Tracker, und so bin ich das Arbeiten gewöhnt. Meistens habe ich in X-Tracker um weiterzukommen einfach das komplette letzte Pattern kopiert und dann entsprechend gewünschte Änderungen vorgenommen.
Ja eben, und immer das Pattern kopieren müssen wär mir zu blöd. Und wenn irgendwas mir nicht mehr gefällt, müßte ich's an ALLEN Pattern ändern... da hätt ich keinen Bock drauf. Wozu hab ich 'n Computer, wenn ich repetative Dinge dann trotzdem manuell machen muß...?
zatzen hat geschrieben:Das ergibt Speichertechnisch viele Redundanzen, und so existieren diese auch in ZSM, obwohl dort alles erstaunlich klein gehalten wird. Allerdings sind auch komplexe Musikstücke wie sie in der Klassik zu finden sind denkbar und diese würden dann nicht mehr beanspruchen als redundante Popularmusik.
Ja, ich finds einerseits erstaunlich, wie klein man Sachen mit ZSM kriegt - was mir aber andererseits auch das zeigt, was ich immer schon gesagt habe: Nämlich, wie abartig redundant MOD-artige Files sind.
zatzen hat geschrieben:DOSferatu hat geschrieben:Schade, daß kein "Covox Speech Thing" oder wie das Ding hieß habe und auch keinen so Nachbau. Wäre mal cool, diese Methode per LPT zu hören... Ja, ich weiß: Kann man sich auch selber löten - wenn man kann.
Ich habe mir so einen gelötet als ich 14 oder 15 war. Ziemlich einfach, man braucht nur einen LPT Stecker, Audiobuchse, Folienkondensator, und 20 oder so 1% Widerstände 10k oder was das war. Der Klang ist ziemlich gut, vor allem bei hohen Rates.
Ja, den Schaltplan für so Ding hab ich schon gesehen und eigentlich wär's kein Hexenwerk. Aber Ich hab eben noch nie gelötet.
zatzen hat geschrieben:Das ist auch mit der Grund warum ich es schade fand dass heutige PCs keine parallele Schnittstelle mehr haben. Man konnte so einfach elektronische Basteleien damit machen. Heute braucht man für alles einen Arduino oder sowas.
Naja, ich finde so einiges schade. Auch, daß die seriellen Schnittstelle weggefallen ist (oder, wie wir es früher nannten: Der COM-Port).
Stattdessen USB - was meiner Meinung nach viel zu kompliziert zum "Selbermachen" ist - immer gleich 'n ganzes Arsenal Elektronik auffahren, nur um 'ne blöde Daten-Schnittstelle zu benutzen. Nerv!
zatzen hat geschrieben:DOSferatu hat geschrieben:[Zatzens Beobachtung bei Pinball Dreams] Naja, es werden kurze Puffer sein. Aber dank Puffer-Vorberechnung und Puffer-DMA wird hat man eben trotzdem eine Verzögerung. (Das Ding mit Ursache und und Wirkung.) Bei der ganzen Dynamik eines Spiels fallen einem so Dinge wahrscheinlich nur nicht so auf.
Ich habe mit Dosbox ein Video mitgeschnitten. Ich kann das bei Gelegenheit mal ganz akkurat überprüfen, d.h. bei genau welcher Stelle sich z.B. ein Hebel bewegt und wann dazu der Sound einsetzt.
Und wie ich nicht müde werde zu betonen: DOSbox ist keine Referenz. Es emuliert keinen realen Rechner, sondern dient dazu, alte Spiele spielen zu können. Für so "Tests"/"Benchmarks" u.ä. ist es völlig ungeeignet. Der Soundversatz in Emulatoren ist ein generell bekanntes "Problem" und betrifft
alle Emulatoren - inklusive denen, die in diesen neuen "The C64" Dingern eingebaut sind. Also wieder: Keine Referenz für reale Dinge.
zatzen hat geschrieben:DOSferatu hat geschrieben:Wieso kann Dein aktueller Rechner kein 16 Bit DOS? Etwa so UEFI-Dreck statt BIOS?
Ja, tatsächlich UEFI. Aber allein schon Windows 7 verbietet 16 Bit Programme.
Über sowas wie einen modernen Rechner in Dos zu booten habe ich noch gar nicht nachgedacht. Bisher genügt mir da aber auch Dosbox.
Ja, man kann so ein Mehrfach-Boot Ding davorklemmen. Meine "Windows"-Rechner haben das alle.
zatzen hat geschrieben:DOSferatu hat geschrieben:Naja, für das, was ich so mache (Mehrwege-Scrolling) ist auch nichts anderes möglich als Komplettframe neuzeichnen. Obwohl es ja, wie gesagt, auch noch die Möglichkeit gibt, die Softscroll-Register der VGA zu benutzen, die Scanline mehrere Bildschirme breit zu machen usw...
Softscroll/Scanline mehrere Bildschirme - das geht dann aber auch nur in dem Sinne dass man den Bildbereich nur vergrößert, oder? Sonst hat man ja mittendrin einen kleinen Hänger wenn ein kompletter neuer Screen gezeichnet werden muss.Oder Stückeln? Müsste gehen... Aber das ist dann definitiv erst für mich möglich wenn ich Mode-X kapiert habe.
Naja. Das Verbreitern der Scanline kann z.B. das Problem des Clippings lösen. Und auch z.B. dafür sorgen, daß Zeilen an 2er-Potenz-Größen anfangen... Nur so'ne Idee...
zatzen hat geschrieben:[Sprites, Meta-Paletten...]Vielleicht bin ich als eigentlicher "Musiker" einfach nicht so ideal für die Grafikprogrammierung.
Naja, ich bin für gar nichts ideal. Ich kann ein bißchen coden, primitive Grafik und noch primitiveren Sound machen. Hält mich ja leider trotzdem nicht davon ab, Leute mit meiner Software zu belästigen...
zatzen hat geschrieben:Ich mache das ja irgendwie nur nebenbei. Ich spiele viel rum, experimentiere, manche haben schon gesagt ich soll nicht immer das Rad neu erfinden.
Wurde mir auch schon gesagt. ABER: Ich lerne viel mehr, wenn ich etwas selber mache, als wenn ich nur fertiges Zeug benutze. Damit kommt man zwar langsamer voran - aber mich interessiert eben auch, wie etwas funktioniert.
zatzen hat geschrieben:Beim Programmieren bin ich auf jeden Fall nicht professionell, mir macht da das Tüfteln Spaß, und gerade auch in Assembler, da schreibe ich gerne mehr oder weniger komplizierte Routinen wie z.B. Entpackroutinen, die dann trotz allem verhältnismäßig schnell sind, jedenfalls schneller und überhaupt erst tolerabel gegenüber dem als hätte man sie in Hochsprache geschrieben. Das macht so einen Teil der Faszination für mich aus. Es ist ein bisschen wie Rästelhefte lösen manchmal, nur dass die Ergebnisse nicht in der Tonne landen, sondern evtl. in einem Spiel, das dann vielleicht nicht performt wie ein professionelles, aber doch besser ist als nichts.
Performance ist ja nicht alles.
zatzen hat geschrieben:ZSM hat sich jedenfalls schon gelohnt, ich höre mir damit schonmal gerne ein bisschen Musik an. Ich könnte auch einfach die originalen MODs in Windows im Winamp abspielen, aber irgendwie mag ich das Interface meiner Software, die ganzen Anzeigen usw., die hat Winamp nicht, und letztlich hält mich wohl auch bei der Stange, dass ich genau dieses Format auch in ein Spiel bringen könnte, mit genau dem eigentümlichen Klang, und so verschaffe ich mir ein Gefühl dafür, was wie klingt und wieviel Speicher es braucht etc.
Ja, das ist doch gut. Und je mehr/öfter man etwas (selbstgebautes) benutzt/testet, umso eher fallen einem spontan Dinge ein, die man noch verbessern könnte - oder Bugs, die noch rausmüssen.
Ich habe hier echt selbstgeschriebene Tools, bei denen mir manche Bugs erst Jahre später aufgefallen sind. (Ich schreibe meine Tools ja quasi nie "nur aus Spaß", sondern immer, weil ich sie brauche. (D.h. ich
benutze sie auch mehr oder weniger regelmäßig.)
zatzen hat geschrieben:Über Emulatoren würde ich mir mal keine Sorgen machen. Vielleicht wenn irgendwann 256 Bit Windows kommt.
Achnaja, auch dann wird man noch Dinge emulieren können. Es läuft eben nur nicht mehr auf der realen Maschine - nicht, weil es nicht technisch möglich wäre, sondern wegen absichtlicher künstlicher Veralterung.
zatzen hat geschrieben:Ich habe mal den Ton vom Pinball Dreams Mitschnitt vermessen.
Ich bin da auf verschiedene Ergebnisse gekommen. Von 13 ms Versatz bis hin zu ca. 50 ms.
Ich vermute, dass die Länge des Puffers so gewählt ist dass die Frequenz der halben Bildwiederholrate entspricht, hier also ca. 35 Hz. Die Musik klingt für meine Ohren gerade bei eigentlich sauber zu erwartenden, geraden Tönen etwas unsauber, vielleicht wird hier kein Auto-Init-DMA angewendet sondern jedesmal die DMA Übertragung neu angeschubst, was kleinste Aussetzer verursacht, die dann den Klang ein wenig "zerstückeln" bzw. modulieren.
Ist vieles möglich. Sähe man nur, wenn man den Code analysiert. Aber daran solltest Du vielleicht schon erkennen, daß es auf PC ein Unterschied ist, mit einem Standalone-Tool Musik abzuspielen oder währenddessen "nebenher" auch noch ein interaktives Spiel abzuspielen. Die Generierung der Grafik und die Steuerung des Spiels braucht ebenfalls Platz und Performance - das ist
nicht "Musikroutinen mit ein bißchen Spiel drumherum".
zatzen hat geschrieben:Ich sehe da durchaus auch einen Grund: Man kann mit manuellem DMA-Auftrag den Sound per Timer takten, da so ein One-Shot-DMA nicht durchlaufen muss sondern abgebrochen wird sobald der nächste kommt. Das klingt zwar dann nur bei perfektem Timing optimal, orientiert sich aber eben immer fest am Timer und gallopiert nicht von selbst davon. Ob das für unabhängige Programmierung von Sound und Spieltiming ein Vorteil sein kann weiss ich noch nicht.
Ja, das hängt wahrscheinlich auch vom jeweiligen Anwendungsfall ab. So Pinball-Spiel stelle ich mir von der grafischen Programmierung her einfacher vor als andere Sachen: Den vertikalen Screen-Ausschnitt kann man selbst in VGA schon linienweise setzen - benutzt man Unchained "Mode-X" Varianten, so braucht man nur das feststehende Stück Anzeige immer rein/rauskopieren und den Rest könnte man mit nahezu Null Performanceverlust hoch-/runter-scrollen und hat einen 320x800-Pixel Pinball-Automaten.
zatzen hat geschrieben:Und wie gesagt ist das hier nur eine Vermutung, aber ich bin mir fast sicher, so einen "Stückelsound" früher einmal bei einem Spiel erlebt zu haben.
Wenn man sieht, wie erfolgreich viele DOS-Spiele waren, kann man davon ausgehen, daß 99% der Leute da nicht so empfindlich sind/waren wie Du ("oh weia, der Sound ist nicht framegenau"). Wenn man einerseits Sound-zu-Framegenaue Perfektion anstrebt, es einem aber andererseits egal ist, ob komplizierte Routinen die FPS runterziehen - dann ist das irgendwie ein Gegensatz - zu dem mir keine gescheiten Programmiertips mehr einfallen.
zatzen hat geschrieben:Ein Vorteil davon, den Soundpuffer per One-Shot einzubinden wäre, dass man sich beim Hängen von Frames keine nervigen Soundloops einhandelt.
Naja, IMHO: Wer so codet, daß er hängende Frames hat, hat es auch nicht verdient, vernünftigen nichtloopenden Sound zu haben.
zatzen hat geschrieben:Wenn das Timing per Interrupt gelöst wird und man eine verlässliche Samplerate bei der Soundkarte einstellt (was durchaus beachtet werden muss, da der Soundblaster mit seiner 256-Stufen Formel da eher ungenau ist)
Ich weiß. Keine Soundblaster hat jemals mit 44100 Hz gespielt. Die Frequenz kann man da nämlich nicht mal annähernd einstellen. Bei den meisten wirds dann 45454,545... Hz.
zatzen hat geschrieben:spricht eigentlich nichts dagegen, One Shot DMA zu nutzen - es sei denn so ein DMA-Befehl hat eine hörbare Verzögerung im einstelligen Millisekundenbereich.
Wenn Du a) Verzögerungen im einstelligen Millisekundenbereich hörst und b) das für Dich unerträglich ist, dann ist Spieleprogrammierung auf PC wohl nichts für Dich: Sowohl der SB als auch der Ticker arbeiten mit so einer Formel (nur der Ticker mit 65536 Stufen) und man kann ja nichts wirklich "gleichzeitig" machen. Diese Genauigkeit kann man selbst mit Standalone-Programmen auf einem PC quasi nicht erreichen - geschweige denn bei einem Spiel, wo außer Sound noch andere Dinge passieren.
zatzen hat geschrieben:Wenn das möglich wäre, käme mir jedenfalls erstmal, so wie ich das sehe, die ganze Geschichte etwas "zahmer" vor. Aber wenn ich's mir recht überlege, wenn man wirklich Bild und Ton unabhängig timen will ist Auto-Init-DMA klar im Vorteil.
Naja, solange die Musik nicht direkt vom Spiel abhängig ist oder umgekehrt, sollte es für den Spieler keinen Riesenunterschied machen, ob er beim Laufen grade an Steinchen 1 oder Steinchen 2 vorbeikommt, wenn Ton X oder Ton Y spielt. Bei Soundeffekten sieht's schon anders aus - aber, wie wir ja wissen: Je kürzer der Soundpuffer, desto schneller muß die Gesamtschleife sein, damit man rechtzeitig auf leeren Soundpuffer reagieren kann.
Meine Methode ist ja, alles, was an Klängen benötigt wird, als "Nummer" in einen Ringpuffer (in meinem Anwendungsfall ist es eher ein LIFO-Puffer ohne "Ring") zu schmeißen und wenn das nächste Soundpuffer-Stück zu generieren ist, wird das mit berücksichtigt. Wie gut oder schlecht das am Ende klingt, habe ich noch nicht testen können, weil ich ja noch kein genügend fertiges Spiel vorliegen habe, in dem ich das hören könnte.
zatzen hat geschrieben:Überhaupt, auch zum Thema Grafik, mache ich lieber alles Schritt für Schritt. Für mich steht da erstmal ein Spiel an bei dem ich die Möglichkeiten von Assemblerroutinen mit Transparenz auskoste, das ist für mich noch relativ neu, auch wenn ich das ein oder andere Testspiel vor 20 Jahren schon gemacht habe.
So gehe ich ja auch vor. Ich profitiere gern von Dingen, die ich schonmal gesehen habe oder Methoden, die ich irgendwo gelesen habe. Aber ich benutze so Zeug erst dann, wenn ich auch selbst verstanden habe, wie es funktioniert. Irgend etwas "einfach so einzubauen" und dann zu hoffen, daß schon nichts schiefgehen wird, ist auch für mich keine Option. Ich will nicht, daß etwas, das icb baue, dahingehend ausartet, daß ich irgend so eine "Master-Klotz" Routine habe, um die herum ich alles anzupassen habe, weil ich den Master-Klotz nicht verstehe, sondern nur benutze.
zatzen hat geschrieben:Deine bisherigen Erklärungen zu Mode-X, DOSferatu, sind nicht in den Ofen geschossen, auch nicht die zur unabhängigen Programmierung von Bild und Ton. Wenn man die Soundpuffer klein halten kann und sie dann wegen Unabhängigkeit trotzdem schnell berechnet werden sehe ich überhaupt kein Problem darin, dass ich das so mache.
Ja, wie gesagt: Kommt immer drauf an. Normalerweise hat man ja, während ein Puffer abgespielt hat, "genügend Zeit", den anderen zu füllen. Das muß ja nicht in der gleichen Nanosekunde passieren, wo man von Puffer1 auf Puffer2 umschaltet. Das Umschalten selbst MUß natürlich genau am Puffer-Ende passieren - aber dazu gibt's ja schließlich den Soundblaster-IRQ. Aber mit dem schalte ich eben nur von einem zum anderen Puffer um und setze/erhöhe einen Flag/Zähler. Und wenn in der Hauptschleife gefunden wird, daß dieses Flag/Zähler <>0 ist, wird neuer Sound für den anderen Puffer generiert. Das ist dann trotzdem noch zeitig genug - denn abgespielt wird er ja sowieso erst, wenn der andere wieder fertig ist.
Was Soundeffekte angeht: Ich werd's bei mir wohl nicht so kompliziert werden lassen, daß ich noch festlege, an welcher Stelle
INNERHALB eines Puffers ein Soundeffekt starten soll. (Wäre zwar möglich, aber mein Irrsinn hält sich dahingehend in Grenzen.) Also starten die immer alle am Anfang eines Puffers und eine genauere Auflösung zum Starten von Effekten als eine Pufferlänge wirds bei mir wohl nicht geben.
Grund ist. Die starten sowieso IMMER verspätet. Wieso? Na, weil die Dinge, die die SFX auslösen ja passieren, während ein Puffer abgespielt wird! Und zwar der, der gerade NICHT generiert wird - sondern der davor! Also ist ein SFX, selbst wenn er am Start des neu zu generierenden Puffers mit reingemixt wird, eigentlich schon zu spät. "Live" in den gerade abgespielten Puffer reinmixen - da wüßt ich nicht, ob das überhaupt geht - d.h. ob die SB das dann überhaupt noch mit einliest. Man weiß ja nicht, wo sie gerade liest - es sei denn man ist dermaßen lunatic, daß man dafür 'n Ticker setzt oder sowas hirnverbranntes.
Aber - wegen des verspäteten SFX: Auch die Grafik ist ja verspätet - die wird nämlich auch erst angezeigt, wenn das Frame fertig gezeichnet ist und nicht "mittendrin".
Und ja, damit bin ich
NICHT framegenau! - Weil meine Frames ja schon nicht feststehend sind. Denn wenn ich einen Puffer mache, der 1/50 Sekunde lang ist, mein Spiel aber auf dem Rechner eines Users nur 40 FPS schafft, dann bricht der Sound völlig ein. Also wird das bei mir wohl eher auf einen Puffer für 1/10 Sekunde hinauslaufen oder so - und einstellbar für langsame Kisten noch längere Puffer.
Die einzigen zwei Möglichkeiten, das zu vermeiden, wären:
a) Das von mir letztens beschriebene Multitasking mit 100% nebenläufigen Prozessen - das habe ich aber nicht vor (hatte auch die Gründe dargelegt).
b) Die Generierung des neuen Sounds gleich im IRQ. Da weiß ich noch nicht, ob ich das mag. Eigentlich find ich's Mist.
Und, wie gesagt: Die Grafik ist genauso "hinterher" wie der Sound - vielleicht sogar noch mehr.