Trackermodul-Engine (sehr einfach)

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

Re: Trackermodul-Engine (sehr einfach)

Beitragvon DOSferatu » Mo 3. Sep 2018, 21:02

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

Ja, kann man machen. Ich mag z.B. auch diesen sogenannten "Orchesterschlag" und wenn er als "Instrument" eingesetzt wird.

zatzen hat geschrieben:Ich mag SID Musik auch... Naja und die Pattern-Darstellung mit ihren vielen Nullen dient einfach der Übersicht und Intuition,

Ich weiß.
zatzen hat geschrieben:und moderne Tracker gingen ja dann auch dazu über die Patterns einfach aber effektiv zu komprimieren.

Ja, wie eben z.B. der X-Tracker von Delusion.

zatzen hat geschrieben:Es gibt da auch irgendeine trackerartige Software wo alles datenmäßig sehr kompakt gehalten wird durch Makros etc. Aber das wäre mir zu hoch bzw. zu unintuitiv. Letztlich will ich Musik machen - zum Programmieren und Großhirn anstrengen habe ich Pascal und Assembler.

Naja - für mich macht das keinen Unterschied. Aber das mag auch daran liegen, daß ich selten bis nie irgend etwas "intuitiv" mache. Bei mir hat (fast) alles einen Plan.
Ich weiß - ich bin langweilig.

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

Naja, solange der Speicher da ist, kann man ihn auch nutzen. Man muß es eben nur im Blickfeld behalten, damit es am Ende noch reicht. Und, sagen wir mal so: 620 kByte Heap-Speicheranforderung sind nicht gerade optimal - nicht jeder hat so viel "unteren" Speicher frei (obwohl die Leute, die heutzutage DOS benutzen, so langsam wissen dürften, wie man Speicher freimacht). Ich denke, so 600 kByte ist eine gute Obergrenze. Allerdings muß man immer bedenken: Auch Programmcode braucht Speicher, der ist nicht "einfach so da" - der Code klaut ebenfalls der Grafik und dem Sound Speicher.

Beispiel: Man schreibt eine Subroutine, die total komplex ist und die dafür sorgt, daß die Grafik ultraklein gepackt werden kann, so daß man vielleicht 50 kByte einspart. Die Subroutine selbst enthält komplexen Code und Tabellen braucht insgesamt 80 kByte...
Da hätte man nichts gewonnen - man hätte 30 kByte zusätzlichen Speicherbedarf UND eine komplizierte Routine, die auch noch zusätzlich mehr Rechenleistung erfordert.
Anderes, nicht ganz so krasses Beispiel: Man hat Grafik, die 100 kByte braucht, schreibt eine komplizierte Routine und braucht damit 80 kByte, die Routine ist 10 kByte groß. Also spart man 10 kByte - allerdings verbraucht die Routine so viel Rechenleistung, daß die Anzeigeframerate halbiert wird.
Hier muß man immer mal abwägen: Kompliziert kann gut sein - ZU kompliziert kann wieder ins Gegenteil umkippen.

zatzen hat geschrieben:Jederzeit in ZSM Samples starten:
Das geht "von außen" natürlich immer nur am Anfang des nächsten Puffers.

Ja, wie in ISM. Alles andere macht meiner Meinung nach auch keinen Sinn. (In den laufenden Prozeß eingreifen wäre einfach zu crazy und man kann es mit der "Synchronität" auch übertreiben...)

zatzen hat geschrieben:Was ZSM aus den Patterns liest kommt aber absolut zeitrichtig in den Puffer, auch mehrere Sample-Starts innerhalb einer Pufferlänge, sonst würde das ganze ja auch nicht funktionieren.

Klar - wäre es anders, hätte es keinen Wert.

zatzen hat geschrieben:ISM hat also sozusagen eine serielle Datenverarbeitung, bezogen auf eine Stimme.

So ist es.

zatzen hat geschrieben:Und die muss dann vereinfacht gesagt nur die Informationen Länge und Tonhöhe haben.

Genau. Nur daß ISM eben zusätzlich "Nullzeit-Befehle" hat, die dazwischenstehen können, nichts am Puffer ändern, sondern nur an Einstellungen/Arbeitsweise/Daten des ISM-Generators an sich etwas ändern. Dazu gehören auch die verschiedenen Sprungbefehle, aber eben auch andere.

zatzen hat geschrieben:Ist mir von Anfang an auch klar gewesen, und ich kann diesen Ansatz verstehen, er erscheint am logischsten zumindest wenn man ihn direkt mit unkomprimierten MOD Patterns vergleicht, wo eine "Leernote" direkt 4 Byte frisst.

Naja, mir ging es hier sekundär um Speichersparen - primär darum, daß ich gleiche Teile nicht mehrmals eingeben muß und wiederverwenden kann - und das auch in jeder Länge und Lage, nicht nur auf feste "Patterngrößen" beschränkt und nicht nur zusammenhängend mit anderen Stimmen.
So kann ich die Begleitung ändern ohne die Hauptstimme zu ändern - oder umgekehrt - und habe damit einen neuen Musikabschnitt, der wieder neu und anders klingt ohne zusätzlich etwas einzugeben. Ich kann einen Teil langsam oder schnell spielen, höher oder tiefer. Ich kann eine Begleitung haben und die gleiche Melodie langsamer und tiefer als Hauptteil haben. Ich kann einen Teil haben und den gleichen Teil leiser und leicht zeitversetzt auf der nächsten Stimme spielen - schon habe ich ein Echo. Ich kann Schleifen oder Schleifen um Schleifen und dazu noch einen Stack benutzen, kann ein Unterprogramm bauen und jederzeit aufrufen, das einen Ton als Tremolo oder ähnliches spielt, indem ich den Effekt programmiererisch nachbilde und kann neue Effekte bauen, die z.B. das MOD- oder ähnliche Formate noch gar nicht vorgesehen haben... Alles Dinge, die so einfach gehen, wenn man sich nicht auf eine starre MOD-Rastermatrix beschränkt. Es ist also, genau wie MOD-trackern, ebenfalls kreativ - nur eben anders.

zatzen hat geschrieben:Zudem entspricht er eher der Idee der Notenschrift, wo im Zweifelsfall die Notenlängen zählen, und nicht unbedingt was parallel notiert wird.

Naja, Noten, die zur gleichen Zeit gespielt werden, stehen auch in der Notenschrift direkt untereinander. Es ist nur eben so, daß die Noten nicht "breiter" werden oder mehr Platz brauchen, wenn sie einen längeren Ton spielen - AUßER, wenn auf der anderen Notenlinie gleichzeitig viele kurze Noten gespielt werden sollen... Dann wird natürlich Platz gelassen. Aber wenn in einem schnellen Musikstück ein langsamer Part kommt, der nur aus langen Noten besteht, wird natürlich kein riesiger Zwischenraum gelassen, sondern man erkennt an der Notenform, welche Länge die Töne haben sollen.
Ich persönlich kann, wie gesagt, auch mit der Notenschreibweise nichts anfangen. Ich kann sie zwar lesen und könnte sie "abschreiben" und als Melodie umsetzen. Aber ich könnte sie nie "live" spielen - also während ich sie "lese" live mitspielen. Dazu ist sie meiner Meinung nach einfach zu kompliziert gelöst. (Es muß einen Weg geben - Millionen von Musikern auf der Welt benutzen sie und haben damit scheinbar keine Probleme.)

zatzen hat geschrieben:Bei meiner ZSM Komprimierung ergibt sich aber unterm Strich sehr wenig Datenauflauf, weil je nachdem die Tonhöhenparameter mit wenigen Bits auskommen und Leerzeilen entweder Track-Weise mit nur einem Bit vermerkt sind oder auch ein einzelnes Bit eine komplette Leerzeile einer ganzen Patternbreite deklariert. Eine simple Hihat-Spur wo einfach eine Hihat auf jedes 8tel kommt würdest Du wohl in ISM als Schleifenfunktion programmieren.

Klar. Und das Schöne ist: Ich könnte sogar eine Begleitung machen, wo z.B. immer 2x HiHat, einmal Baßschlag, dann nochmal HiHat und köntne eine Schleife drum machen - obwohl ich darin 2x das Instrument wechsle und evtl. verschiedene Frequenzen benutzen würde. Und bräuchte dafür 8 Befehle (2 für Schleifeanfang/-ende, je einen für den Instrumentwechsel und die 4 Notenbefehle. Und könnte damit eine Begleitung bauen, die das für maximal 256x4 Töne durchhält und wenn ich eine weitere Schleife um die erste Schleife baue, dann bis zu 65536x4 Töne und das dann mit insgesamt 10 Befehlen (entspricht 20 Bytes).

Aber klar, so eine eintönige Dauerbegleitung würd ich nicht machen. Aber, nochwas: Ich könnte diese Begleitung einsetzen, dann auf eine andere wechseln und dann wieder die vorige nehmen ("Unterprogramme") ohne zusätzlichen Code (abgesehen von den Aufrufen und dem Rücksprungbefehl am Ende) und ich könnte die Anzahl Durchläufe vorher festlegen und dann zum Unterprogramm springen, so daß ich die Begleitung für underschiedlich lange machen könnte.

Und wenn mir das nicht gefällt, gehe ich an EINE EINZIGE STELLE im "Code" (in den Musikdaten) und ändere EINE Zahl ab und schon ist es ganz anders.

Für mich macht das irgendwie so viel mehr Sinn. Aber das kann natürlich jeder anders sehen. Ich bin noch nie auf die Idee gekommen, das "live" mit einer Art "Klaviatur" zu spielen, das wäre mir zu kompliziert. Aber Menschen sind eben unterschiedlich.

zatzen hat geschrieben:Bei ZSM ergibt das Redundanz, allerdings würde die gesamte Hihat-Spur nur 1 Bit pro Zeile verschlingen, und somit nur 8 Byte aufs ganze 64-Zeilen-Pattern gerechnet. Okay, eins darf ich nicht verschweigen: Jede Spur braucht pro Pattern und Spur eine Tabelle, für diese Hihat enthält diese allerdings auch nur einmal die Information, auf welcher Frequenz sie gespielt wird, das wird mit 5 Bit beschrieben, da die Frequency Tables maximal 32 Werte haben dürfen.

Naja, mir stehen jederzeit alle 96 Töne (8 Oktaven á 12 Halbtöne) zur Verfügung, mit Transponieren sogar über 10 Oktaven. Allerdings klingt das nur bei Klangsynthese gut. Samples werden, um die richtige Frequenz zu bekommen, ja schneller oder langsamer gespielt, da ist der nutzbare Frequenzbereich pro Sample natürlich beschränkt, damit es nicht zu schräg klingt.

RICHTIGES Pitchen, d.h. Samples bei gleicher Geschwindigkeit trotzdem in unterschiedlichen Höhen zu spielen, "das ist schon eine Wissenschaft für sich - da kann nich jeder mit um"[tm]. Ja, ich weiß, daß es da Möglichkeiten gibt, aber die richtig GUTEN Möglichkeiten fressen Rechenpower ohne Ende (also nichts für DOS-Maschinen) und die halbguten Möglichkeiten klingen nicht wirklich toll, fressen aber trotzdem noch Rechenzeit.

zatzen hat geschrieben:Aber das weißt Du schon alles, es macht nur irgendwie Spaß... u.a. soetwas ist eben der Grund warum ich gerne programmiere, es sind meistens Dinge von denen der User gar nichts mitbekommt.

Ein richtig gutes Programm/Spiel erkennt man daran, daß dem Anwender/Spieler nicht auffällt, wie kompliziert das Ding ist (persönliche Meinung).
Anders ausgedrückt: Wenn ein Programm/Spiel zu kompliziert erscheint, ist nicht der User/Player schuld, sondern der Coder.

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

Zu große Puffer machen "Sound-Lags", ist ja klar. Außerdem kann der Sound dann nur "unzureichend gleichzeitig" auf das Spiel reagieren.
Zu kleine Puffer dagegen bremsen das restliche Programm aus, weil dann das Programm die ganze Zeit nur in Dauerpanik ist, ja den Puffer nicht ablaufen zu lassen und deshalb zwischenzeitlich nicht viele andere Dinge tun kann.

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

Naja, wenn in ISM eine Stimme IN einem Tune gerade still ist, geht da nur ein Zähler runter, der Zähler wird mit dem Restpuffer verglichen. Ist er höher oder gleich, wird der Restpuffer vom Zähler abgezogen und zum Ende gesprungen = Stimme fertig. Ist er kleiner, wird die Pufferposition um den Zähler erhöht und es wird zur Stelle gesprungen, wo der nächste Befehl geholt wird. D.h. die Stimme macht in diesem Moment (fast) nichts außer eine Handvoll Maschinenbefehle.
wenn eine Stimme WIRKLICH aus ist (also unbenutzt), dann tut sie wirklich nichts, dann wird sie übersprungen. Solche Stimmen können nur von außen oder von anderen Stimmen aus (re-)aktiviert werden.

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

Naja, in AtavISM könnte man das einbauen, allerdings (derzeit) nur zwischen 1 und 64 Zeilen. Das liegt daran, wie die "Einzelteile" gespeichert werden, diese können maximal nur je 256 ISM-Befehle enthalten, und wenn eine Spur "voll belegt" wäre (alles komplett belegt, jede Zeile enthält Note, Effekt und Instrumentwechsel), kommt das Ding ans Limit. Hier müßte ich die Variablen aufbohren, um mehr Zeilen zu ermöglichen.
(Wie ich ja schon oben erwähnte: Speicher in Daten sparen nützt nur etwas, wenn der Programmcode, der dazu nötig ist, nicht größer oder gleich dem gesparten Speicherplatz ist.)

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

Genau so. Es würde flackern... halt!
Also, ausführliche Erklärung:
Methode A: (simpel)
Alles in einen RAM-Puffer machen. Erst Level hinmalen. Dann Sprites drauf und immer letztes Sprite X bis 1 löschen, dann wieder Sprite 1 bis X setzen. Am Ende alles mit einem REP MOVSD in den Grafikspeicher kopieren.
- Vorteil: Flackert nicht, Sprites dürfen sich überdecken, Pixel werden nur 1x in die Grafikkarte geschrieben, Sprites können mit beliebiger Routine gezeichnet werden.
- Nachteil: Evtl. etwas langsam, großer RAM-Puffer benötigt, zusätzlich Platz zum "Retten" des Bildinhalts unter den Sprites benötigt.

Methode B: (tricky)
Alles direkt im MCGA machen (320x200x256), aber ohne verdeckte Sprites (also Sprites dürfen sich nicht überlappen). Als erstes: Level hinmalen. Dann Sprites hinmalen. Beim Versetzen eines Sprites, löschen und wieder hinmalen.
Vorgehensweise: Man braucht 4 (vier!) Routinen, die Sprites zeichnen und/oder Hintergründe retten.
Routine 1: Zeichnet Sprite, rettet dabei Hintergrund.
Routine 2: VORWÄRTS: Zeichnet Sprite, holt Hintergrund zurück, rettet neuen Hintergrund (bei jedem Pixel ein Schritt, der alle 3 Dinge tut).
Routine 3: RÜCKWÄRTS: Zeichnet Sprite, holt Hintergrund zurück, rettet neuen Hintergrund (bei jedem Pixel ein Schritt, der alle 3 Dinge tut).
Routine 4: holt Hintergrund zurück, ohne Sprite neu zu setzen.
Ja, das ginge auch mit EINER Routine - aber dann wären wieder ein Haufen Entscheidungen drin bei jedem Schritt, also langsam und sinnlos.
Routine 1 wird benutzt, um ein Sprite neu zu setzen, das noch nie da war.
Routine 4 wird benutzt, um ein Sprite entgültig zu löschen (das ab dem nächsten Schritt nicht mehr gebraucht wird)
Routinen 2 und 3 werden benutzt, um das Sprite zu bewegen. Die letzte Position des Sprites wird irgendwo gespeichert, am besten als absoluter Wert (0 bis 63999). Die neue Position wird mit der letzten verglichen. Ist sie größer/höher als die alte Position, wird Routine 3 benutzt, ist sie kleiner/niedriger, Routine 2. (Ist sie gleich, wird gar nichts gemacht.)
Sprites liegen dabei dann "linear" irgendwo rum, jede Figur erhält einen Puffer in Spritegröße.
Ein Sprite wird gezeichnet, indem man alle Pixel zeichnet (transparente überspringt, siehe *X), bei Erreichen der Breite dann (320-Breite) addiert, sonst nur 1 (kann man auch wieder mit dem "Trick" machen, der 32bit-Adder, wo die oberen 16 Bit als Zähler funktionieren) und außerdem an der alten Position gleichzeitig "wiederherstellt".
Routine 2 (vorwärts) macht das von der oberen linken Ecke, Routine 3 macht das ganze nur rückwärts, d.h. von der unteren rechten Ecke aus.
Auf diese Art werden mit der gleichen Schleife 3 Dinge getan: Wiederherstellen-Retten-Pixeln.
So, jetzt noch das *X: Beim Überspringen der zu pixelnden Bereiche am besten trotzdem den Hintergrund retten. Grund ist einfach: Soll das Sprite animiert werden (natürlich gleiche Größe!), geht das Wiederherstellen trotzdem noch und auch Routine 4 wird einfacher. Andererseits kann man auch einfach Mit-speichern, welches Image beim letzten Mal benutzt wurde, das macht dann aber die Routnen2+3 komplizierter (und langsamer) weil man auf 2 verschiedene Images zugreifen muß und mehr Sprünge hat.

- Vorteil: Alles direkt im Bild (kein Kopieren), kein zusätzlicher Bild-RAM-Puffer, nur Sprites müssen neu gezeichnet werden. Unbewegte Sprites brauchen nicht beachtet werden, relativ schnell
- Nachteil: Falls zufällig der Rasterstrahl an einer der beiden Stellen ist, wo man gerade pixelt, kann es kurz flackern - ABER - der Rasterstrahl ist VIEL langsamer als eine kleine ASM-Schleife und: Ich setze z.B. meine Mauspfeile auch so und da flackert garnix. Anderer Nachteil: Sprites können kaum gepackt werden (höchstens vielleicht weniger Farben und dann bitweise, aber eben kein ZVID-mäßiges, blockweises o.ä.

Methode C: (Mehrbildschirm, so mache ich es)
Mode-X oder VESA oder ähnliches benutzen, das Platz für mehrere Bilder im Speicher ermöglicht. Dann immer im nicht sichtbaren Bild Level zeichnen und Sprites drüberzeichnen und wenn fertig, auf das Bild umschalten und im nicht sichtbaren das neue Bild zeichnen.
- Vorteil: Kein Flackern, kein RAM-Puffer, kein "Bildrettungs-"Puffer, Sprites mit beliebiger Routine zu zeichnen, Sprites müssen nicht gelöscht werden, Sprites können sich überlappen, kein Lesen aus Grafikspeicher nötig, "Scrolling" einfach durch verschobenes Level darstellbar, auch das Level kann "sich bewegen/ändern"
- Nachteil: Benötigt andere Modi als den praktischen MCGA (z.B. Mode X), es muß immer ein ganzes Bild gezeichnet werden, d.h. X*Y Levelpixel PLUS alle Spritepixel direkt an Grafikspeicher, Performance je nach Grafikspeicher-Übertragungsrate.

Methode D: (z.B. Kotzman II)
Sprites mit Rand in Hintergrundfarbe, löschen ihre "Reste" selbst weg beim Neuzeichnen.
- Vorteil: Level muß nie nachgezeichnet werden, Sprites brauchen nicht gelöscht werden, unbewegte Sprites brauchen nicht neugezeichnet werden, MCGA möglich, beliebige Spriteroutine möglich, hohe Ausführungsgeschwindigkeit
- Nachteil: Sprites dürfen nicht überlappen, "begehbarer" Hintergrund darf nur einfarbig sein, Spriterand muß mindestens so breit sein wie sich Sprite in Pixeln bewegen kann (daher keine "Berührung" von Levelelementen möglich in Bewegungsrichtung)

Von dem Ganzen gäbe es noch Mischformen und Abwandlungen. Das wären so die Dinge, die mir spontan dazu einfallen. Methode B ist z.B. etwas tricky, hier müßten viele Dinge berücksichtigt werden - aber wenn's funktioniert, kann es für ein Nicht-Scrolling-Spiel wohl eine gute Idee sein.
Allgemein ist ein "Nicht-Überlappen-Dürfen" ein Pain-In-The-Ass für unabhängige Steuerroutinen. Da muß dann ständig darauf geachtet werden, daß das nicht passiert, sonst gibts Grafikfehler. Das wird umso ekkiger, je mehr bewegliche Elemente/Figuren man hat.

Würde ich eine Weile darüber nachdenken, fielen mir sicher noch mehr Möglichkeiten ein. Das war jetzt nur das, was ich so spontan dazu habe.

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

Ja, man kann hier beliebig einfach oder komplex abgehen. Einfache Regel: Mehr Performance kann man sich durch mehr Speicher erkaufen, Speicher sparen durch geringere Performance.
Je weniger gepackt Daten sind, umso einfacher der Zugriff, umso simpler (und schneller) die Routinen.
Komplexes Packen spart viel Speicher, allerdings brauchen komplexe Routinen mehr Ausführzeit.
Ich versuche hier immer, einen guten Mittelweg zu finden.
Beispiel: Ein 8-Wege-scrollbares Level kann ich nicht packen. Ich muß in jede Richtung können und wissen was da kommt. Wenn man da packt, wird man wahnsinnig. Und ja, da sind dann eben auch mal ein ganzer Haufen Nullblöcke wenn da ein freier Raum ist.
Aber: Ein 2-Wege-scrollbares Level kann man in begrenztem Maße packen.
Und: Ein 1-Wege-scrollbares Level (nur in eine Richtung, nicht rückwärts) kann man sehr gut packen, weil es nicht "von hinten/oben/unten/schräg" lesbar sein muß, sondern nur von einer Seite. Bei Katakis (C64-Spiel) sind die Level so wahnsinnig gepackt, das ist super. Manfred Trenz hat die einzelnen Levelelemente zu "Modulen" gemacht, die verschiedene Größen (X*Y) haben können und die auch wiederholt werden können usw. Da wird einfach an der Stelle wo es beginnen soll, der Startpunkt hingesetzt und das Modul wird dann reingezeichnet während des Scrollings. Geniale Methode. Tricky, aber geil. So sieht das aus, wenn jemand wenig Speicher und wenig Rechenpower hat und dafür stattdessen sein Gehirn benutzt.

Für so Levels mit festen Bildschirmen hätt ich schon wieder eine Idee. Levels haben Blocks aus 16x16 Pixeln. Somit 20x12=240 Blocks. Dann noch 16 Extrabytes, die sind die 4 Startpunkte für die Figur (je nachdem aus welcher Richtung sie reinkommt) und 0 bis 6 Startpunkte für "Gegner"/"Gegnerformationen", immer 2 Bytes (Position, Gegnertyp). Die Positionen sind "block-genau". Wenn es weniger sind, ist Position>=240. Somit hätte ein "Raum" genau 256 Bytes und wäre 320x192 Pixel groß. Die restliche Zeile (oben oder unten) kann man für Anzeige (Punkte, Restleben usw.) benutzen.

Um etwas zu bauen, was das eben beschrieben grafisch macht, in Assembler, für Levelanzeige und Sprites (Methode B) bräucht ich keine Woche. Die Grafiken/Sprites irgendwo malen natürlich nicht mitgerechnet, nur die Programmierung.
Wenn auch Sprites nur 16x16 (bzw Vielfache davon) sein würden, könnt man sowohl die Levelklötze als auch die Sprites einfach in 320x200er Bilder pixeln und die Routine würde das da auslesen. Leseroutine wäre dann super-easy, weil der Zeilenoffset der Sprites und Blocks der gleiche wäre wie beim Bildschirm...
Da könnt man auch z.B. festlegen daß es 16 verschiedene Arten von Figuren gibt und Blocks 0-239 wären normale Blocks und Blocks 240-254 wären Gegner und 255 wäre Spieler. (Weil bei 320x200-Bild nur 240 Blocks darstellbar wären.) An diesen Positionen wären dann Gegner (darunter wäre bei Start eben immer ein 0-Block)...
Ja, so ein Ding würde ich, grafisch/datentechnisch recht einfach hermachen.

Es macht schon einen ziemlichen Unterschied, wenn man kein Scrolling benutzt, Figuren nie außerhalb des sichtbaren Bereichs sein können und alles in "Matrix"-Abmessungen ist, die Figuren keine Sonderfunktionen haben wie Spiegeln, Drehen oder so... naja, was auch immer. Aber das wäre dann eben nur die Ausgabe. Die Steuerung wäre dann noch etwas anderes.

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

Naja, Turbo-Pascal ist ja so schlau und bindet nur Dinge (Variablen, Prozeduren, Funktionen) ein, die auch mindestens einmal irgendwo benutzt werden, d.h. wenn man eine Unit einbindet und nichts daraus benutzt, wird EIGENTLICH auch kein zusätzlicher Speicher verbraucht... Aber manche Units haben eben auch einen Init- und Exit-Teil, um die Variablen oder bestimmte Dinge zu initialisieren oder nach Programmende vernünftig zurückzulassen und das würde z.B. trotzdem ausgeführt werden und die entsprechenden, ansonsten nie genutzten Variablen würden angelegt usw. Daher auch die Option, eine Unit komplett weglassen zu können, wenn nichts davon je benutzt werden soll.

Teile der Units kann man dann auch noch "ausblenden", d.h. wenn man nur einen Grafikmodus/Levelmodus benutzt, den man auch nie umschalten will, braucht man nicht die Routinen für die anderen Modi mit einbinden.
Zusätzlich enthält das Template auch noch numerierte Platzhalter (in Kommentaren), um eigenen Code an bestimmte Stellen einbinden zu können.

Das Ganze bekommt dann wahrscheinlich so eine Art "Hauptprogramm", von dem aus man die verschiedenen Editoren starten kann. Allerdings wird es eben trotzdem eher ein "freakiges Ding" werden - weil ich natürlich nicht soviel Speicherplatz für irgendwelche hübschen, idiotensicheren Sachen verschwenden will. Diese Entwicklungsumgebung ist ja eher für mich. Wer auch immer das dann benutzen will, kann es natürlich tun. Aber das wäre dann ohne Garantie, weil's eben KEIN "schicker Game-Maker" wäre. Ich will ja endlich mal ein Spiel machen und habe mich mit den nötigen "Einzelteilen" schon jahrelang aufgehalten - nun wird's Zeit für den Endspurt. Es ist 2018 - zehn Jahre her seit meines letzten großen Spielprojekts. Danach nur so kleine Spielchen, viele Tools... und eben einige "Engines" für verschiedenste Zwecke, die zwar an sich toll sind, aber bisher nirgends eingesetzt werden, so daß eben nichts "nach außen" kommt von dem, womit ich mich die letzten Monate und Jahre beschäftigt habe. Also: Das "Hauptprogramm" (für die Entwicklerseite) wird keine Mausunterstützung, keine grafische oder Textoberfläche haben, es wird sehr simpel werden.
Benutzeravatar
zatzen
617K-Frei-Haber
Beiträge: 328
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitragvon zatzen » Mo 10. Sep 2018, 23:49

Intuitiv:
Ich finde nicht dass jemand langweilig ist, der etwas überlegter handelt.
Bloß beim Komponieren und dort vor allem beim Improvisieren ist es
leichter wenn der Weg seine gerade aufgekeimten Ideen festzunageln
so einfach wie möglich ist.
Aber es ist okay wenn AtavISM keine "live" Abspielmöglichkeit hat.
Ich würde die Musik dann im Zweifelsfall einfach im X-Tracker
vorher trackern, dann ist es konkretisiert, und ich kann es überlegt
und mit aller Zeit der Welt in AtavISM einprogrammieren - was für
mich immer noch bedeutend einfacher ist als in prISM - also nicht,
dass Du denkst, AtavISM wäre jetzt unsinnig wenn man doch vorher
die Musik in einem anderen Programm "erfindet". Es ist nur einfacher,
wenn ich in AtavISM vorher einfach schon weiss, was ich überhaupt
umsetzen will.

Hast Du bei AtavISM eine Art Brute Force Vorgehensweise um die
Daten in den Patterns effizient in Befehle umzuwandeln?

ISM ist, abgesehen von MODs die fast komplett und nicht-redundant voll mit
Noteninformationen sind, auf jeden Fall die effektivere Variante.
Und ich kann es absolut nachvollziehen wenn man ein Musikstück
wie einen Programmcode betrachtet und handhabt. Und das funktioniert
auch prima wenn man die Ruhe hat und eine konkrete Vorstellung davon,
wie es klingen soll. Bei einem klassischen Tracker sind es eben einfach
Daten, die Zeile für Zeile ablaufen. Das ist je nachdem sehr redundant,
ist aber dann von Vorteil, wenn man einfach ins Blaue hinein direkt
im Tracker selber ein neues Musikstück erfinden will und die Inspiration
während der Sitzung erst kommt. Und das war eben bei mir bisher
fast immer so.

Ich pitche im Tracker auf die "billige" Weise, höher gespielte Samples werden kürzer etc.
Das kann manchmal bei komplexeren Samples zu neuen Ideen inspirieren, oder man
muss versuchen die Rhythmik durch Verschieben entsprechend auszugleichen.

64 Zeilen sind schon okay, ich habe mich in X-Tracker auf 128 (8 Zeilen pro Viertelnote)
eingeschossen, nutze aber nicht immer 32tel... Die braucht ein Musikstück nicht unbedingt.


Danke für Deine wertvollen Erklärungen zum Thema nur-Sprites-setzen!
Ich bin in diesem Post etwas kurz angebunden weil der Grund warum ich schreibe
eigentlich der ist, dass ich eine Idee für ein Spieleformat hätte, das mein Problem
mit der Synchronität vs. Steuerung umgehen würde:
Was ich sowieso schonmal in Erwägung gezogen hatte und sich jetzt vielleicht
manifestiert - eine Art Gesellschaftspiel wo erst die Spieler abwechselnd
einen oder mehrere Kommandos an Roboter oder was auch immer vorgeben können
und dann irgendwann alles ausgeführt wird. Prinzipiell wäre auch soetwas wie Worms
denkbar, aber das ist ja schon ausgelutscht. Vielleicht fällt mir da ja was nettes ein,
ich sehe da eigentlich viel Potential, man muss nur mal groß ausholen bei Ideen sammeln.
DOSferatu
DOS-Übermensch
Beiträge: 1135
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitragvon DOSferatu » Sa 15. Sep 2018, 15:03

zatzen hat geschrieben:Intuitiv:
Ich finde nicht dass jemand langweilig ist, der etwas überlegter handelt.
Bloß beim Komponieren und dort vor allem beim Improvisieren ist es leichter wenn der Weg seine gerade aufgekeimten Ideen festzunageln so einfach wie möglich ist.

Ja, mag sein. Das macht wahrscheinlich jeder anders. Mir macht es Spaß, einzelne Musikteile zu haben und sie immer wieder neu und anders kombinieren zu können und ausprobieren zu können, wie sie zusammen klingen (ohne sie jedesmal neu schreiben oder kopieren zu müssen).

zatzen hat geschrieben:Aber es ist okay wenn AtavISM keine "live" Abspielmöglichkeit hat.

Naja, theoretisch wäre es möglich. Muß mal sehen, ob ich die WAIT Routine dementsprechend erweitert bekomme. (Bis jetzt habe ich IMMER NOCH NICHTS an AtavISM neu gemacht! Fehlende Inspiration - und "jetzt einfach mal so hinschlunzen" ist mir der Mühe nicht wert.) Außer den regulären Units gibt es auch eine prISM/AtavISM-Unit, die gar keine "richtige" Unit ist, sondern nur zum Auslagern gedacht ist, weil Pascal sonst diese Codesegmentgrößen-Probleme bekommt. Wenn Teile in dieser Unit ausgelagert sind, muß ich dann wieder "künstliche Brücken" bauen... usw.
Es ist nicht so einfach, ein etwas umfangreicheres Programm zu schreiben, wenn man an solche Dinge gebunden ist. (Ja ich weiß: Könnte ja Free-Pascal benutzen. Es ist nur leider bei weitem nicht so kompatibel wie ich's mir wünschen würde: Keins meiner getesteten Programme/Units compiliert da ohne Fehler. So toll können die Entwickler nicht sein, wenn man nicht mal einen "Turbopascal-Modus" einstellen kann, der sowohl TP, inklusive den MEM-/PORT-Pseudobefehlen, sowie eingebundenen Assembler im Intelformat versteht. Keine Ahnung, wieso die Leute alle so von FP begeistert sind...)

zatzen hat geschrieben:Ich würde die Musik dann im Zweifelsfall einfach im X-Tracker vorher trackern, dann ist es konkretisiert, und ich kann es überlegt und mit aller Zeit der Welt in AtavISM einprogrammieren - was für
mich immer noch bedeutend einfacher ist als in prISM - also nicht, dass Du denkst, AtavISM wäre jetzt unsinnig wenn man doch vorher die Musik in einem anderen Programm "erfindet".

Ja, läuft dann aber wieder nur auf Sampling hinaus...

zatzen hat geschrieben:Es ist nur einfacher, wenn ich in AtavISM vorher einfach schon weiss, was ich überhaupt umsetzen will.

Naja, also lag es nicht nur am prISM-"Programmformat" - denn AtavISM ist ja nun Track-/Pattern-förmig. Bei Tools versuche ich immer einen Trade-Off zwischen Bequemlichkeit und Speicherverschwendung zu bekommen, damit auch noch etwas Platz für die eigentlichen Daten übrigbleibt. Und solange das Ding sich nicht fast identisch wie X-Tracker bedient - inklusive allem "User-Zuckerguß" - wird es wohl offenbar "unbenutzbar" bleiben...

zatzen hat geschrieben:Hast Du bei AtavISM eine Art Brute Force Vorgehensweise um die Daten in den Patterns effizient in Befehle umzuwandeln?

Selbstverständlich.
Die Befehle durchlaufen 1 bis 4 Schleifen. Schleife 1 wandelt alle Befehle erst einmal in ISM-Format um, indem es z.B. Abstände zu Längenparametern macht usw. Schleifen 2+3 testen, ob durch Schleifen Einsparungen möglich sind. Zwei Schleifen, weil es zwei "Register" gibt, so daß man Schleifen auch verschachteln kann. Kann mit Strg+L gewechselt werden, wieviele Schleifen man maximal haben will (0, 1 oder 2). Und dann am Ende (mit Strg+J wechselbar zwischen 0 und 1) kommt noch eine vierte Testschleife, die prüft, ob Auslagerung in Unterprogramme möglich ist. In allen Fällen wird natürlich geprüft, ob die "Zusatzmaßnahmen" wirklich Einsparungen bringen. Also wenn man drei gleiche Töne hat, wird keine Schleife drum gemacht. Wieso? Naja: Ein Befehl Schleifenstart, ein Befehl Ton, ein Befehl Schleifenende. Wären ebenfalls 3 Befehle - da spart man ja nix und bemüht zusätzlich extra die Schleife. Außerdem sind da "tricky" Dinge drin, die erst nach größeren, dann nach kleineren Einsparungen suchen usw. Die Größe eines "Tracks" (derzeit 64 Zeilen) ist dabei egal, d.h. diese Routine käme auch mit anderen Größen zurecht - das ist selbstverständlich schon so vorbereitet, falls ich mich mal entscheiden sollte, andere Größen zu benutzen. (Ja, alles modular. Nichts mit starren Konstanten. Also: Konstante an EINER Stelle im Code und wenn das mal geändert werden soll, dann braucht man nur diese eine Stelle ändern und alles ändert sich mit. Und so wie ich programmiere, "programmiere" ich eben auch Musik in ISM..,)

LEIDER ist das natürlich trotzdem nicht ideal, weil es das Ganze nur für den aktuellen Track testet und nicht mit den restlichen Daten. Das wäre zwar möglich - aber zu aufwendig. Wenn man herausfindet: "Ah, da ist ja noch ein anderer Teil, den man wiederverwenden könnte", könnte ein Sprung dahin gemacht werden - ABER: Wenn dieser andere Teil (der in einem ganz anderen Track liegt) gelöscht/geändert würde, müßte das überwacht werden. Das ginge, bräuchte aber zu viele Daten - am Ende mehr Daten, als man anderweitig spart.

WAS aber getan wird, ist, den GANZEN "kompilierten" Track gegen andere vorhandene Tracks zu testen und bei Gleichheit einfach die Nummer dieses Tracks intern zu benutzen, also keine zusätzlichen Daten anzulegen. Dazu hat jeder Trackstart einen internen Zähler, der angibt, an wievielen Stellen er verwendet wird. Geht dieser auf 0, wird er gelöscht (und Speicher natürlich "nachgeschoben"). Wird er an einer Stelle geändert, wird der Track um 1 verringert und ein neuer Track angelegt, mit den geänderten Daten. Intern passiert dabei so eine Art Speichernanagement. Das ist natürlich nur "AtavISM-Zeug", das wird nicht mitgespeichert. Beim Laden einer Musik wird das dann wieder automatisch rekonstruiert.

Ja, so ist das, wenn man das Ganze halbwegs intelligent macht. Wie gesagt: Da wäre noch viel mehr möglich - aber alles dann wieder zu Lasten des Speichers: Denn wenn ich Datenspeicher spare, indem ich ihn durch noch mehr Codespeicher ersetze, habe ich nichts gewonnen.
Das bedeutet: AtavISM versucht, die Daten einigermaßen effektiv zu speichern - aber aus verschiedenen technischen Gründen (und der Unterschiedlichkeit von MOD und ISM) wird trotzdem etwas Speicher verschwendet. Die Effektivität ist also bei Weitem nicht vergleichbar mit der eines echten ISM-Files, das ohne das "Framework" auskommt und ohne diese ganze "Spielerei".

zatzen hat geschrieben:ISM ist, abgesehen von MODs die fast komplett und nicht-redundant voll mit Noteninformationen sind, auf jeden Fall die effektivere Variante.

Naja, außer wenn in einem MOD in jeder Zeile das Instrument gewechselt würde oder ein anderer Effekt gespielt würde, ist ISM selbst einem total vollgepacktem MOD immer noch überlegen. Eine ISM-Note braucht 2 Bytes. Die Instrument-Angabe braucht auch 2 Bytes, muß aber nur gemacht werden, wenn das Instrument wechselt. (Da gibt es also kein leeres Feld, wenn das Instrument gleichbleibt.) Ein komplizierter Effekt (außer Portamento) braucht natürlich mehr als bei MOD, weil da die Effekte alle im Player hardcoded sind, also nicht im MOD-File selbst enthalten. Dafür ist man bei ISM bei den Effekten relativ frei und kann da erfinden, was immer man will. Und WENN ein Effekt erstmal existiert, dann braucht er auch nur, wenn benötigt, 2 oder 4 Bytes zum Aufruf...
Egal... Die wirkliche Dateneffizienz oder einen Vergleich dazu kann man schlecht abschätzen, weil es natürlich immer an den Daten selbst liegt - und die können natürlich von Musikstück zu Musikstück extrem unterschiedlich sein.

zatzen hat geschrieben:Und ich kann es absolut nachvollziehen wenn man ein Musikstück wie einen Programmcode betrachtet und handhabt.

Naja, die meisten "Musiker" können das wohl nicht. Ich weiß. das Konzept ist ungewöhnlich. Für mich ist es angenehmer, aber ich bin ja auch kein richtiger Musiker.

Wenn man mit meinem Kram ein Spiel bauen wollen würde, muß man sich auf eine MENGE "programmartiger" Dinge einlassen - ich glaube kaum, daß außer mir selbst jemals das Zeug anfassen wollen wird. (Die Steuerung der Spielfiguren muß z.B. auch als Programm gemacht werden!) So wie Leute heutzutage drauf sind... - mein einer Kumpel nennt diesen Effekt, der so seit 20 Jahren in den Leuten drin ist "Instant Gratification": Alles muß gleich und sofort da sein und funktionieren. Nichts darf irgendwie schwierig sein oder Mühe machen. Das Smartphone ist die plastikgewordene Manifestation dieser Denkweise: Nicht 100 Tasten, nicht 10 Tasten, nicht 3 Tasten - nein: NULL Tasten! MEHR kann man Leuten heutzutage offenbar nicht mehr zumuten.

Dem entspricht auch die Denkart: "Wenn ich etwas entwickle (Grafik, Steuerung, Musik) "und ich sehe nicht während ich entwickle 1:1 was passiert, sondern muß mir extra die Mühe machen, das extra anderweitig anzusehen /abzuspielen, dann geht das nicht."

Damit wird es sehr schwer, ein DOS-Spiel zu machen: Zu DOS-Zeiten hatten die Leute kein "Drumherum". Da gab es den Rechner und den Speicher und man mußte damit auskommen. Gleichzeitig das ganze Spiel UND die Editoren im Speicher zu haben - davon hat man vielleicht GETRÄUMT - aber das ist ja nicht möglich, wenn Editoren, Spiel und Spieldaten alle den gleichen Speicher belegen. Dann wird man nie ein Spiel machen können, was das System richtig ausnutzt - sondern immer nur eins, das alles benutzt MINUS dem, was die Entwicklertools an Speicher, Performance usw. brauchen. ("Featuritis" kann heutzutage gar nicht genug betrieben werden - das artet teilweise in Programme aus, die derart viele Funktionen haben, daß sie nicht mehr unheimlich praktisch sind (wie man vielleicht vermuten würde), sondern für den Durchschnittsmenschen quasi unbenutzbar werden. Und ja, Adobe: Ich meine z.B. Euch!)

Ja ich weiß - klingt alles bescheiden. Es ist eben so: Wenn man auf einer Maschine die Grenzen dieser Maschine ausnutzen möchte, muß man etwas Mühe reinstecken. Da kann noch soviel "Inspiration" da sein: Die muß man dann eben aufschreiben oder aufzeichnen oder aufnehmen oder wasweißich und dann einzeln umsetzen. Und ja, das macht Arbeit. Ein Spiel zu bauen ist nicht das gleiche wie ein Spiel zu spielen. (Auch wenn manche das scheinbar denken.) Ich käme auch nie auf die Idee, irgendeinen Spieleentwickler (egal welchen Bereich des Spiels er entwickelt) zu "belächeln", weil er "ja nur Spiele" macht.

Denn Spiele sind meiner Meinung nach das Anspruchsvollste, was man überhaupt auf einem Computer machen kann. Der Grund ist ganz einfach: Der Computer ist eine Rechenmaschine und Datenspeichermaschine. Und das heißt: Je mehr das was man damit macht, Rechnen und Daten speichern ist (ohne zusätzlich etwas anderes), umso "computermäßiger" ist es, d.h. umso einfacher ist es, das in "Computerform" zu bringen. Also ist sowas wie eine Datenbank, eine Tabellenkalkulation, ein Schreibprogramm usw. das quasi "einfachste", was man damit machen kann - bezugnehmend auf ein Spiel. Ein Spiel ist sowas von "nicht-computer-like", d.h. da muß man eine Menge tun, damit diese "Rechen- und Datenspeichermaschine" sich so verhält, daß man damit auch spielen kann.

Das ist ja auch der Grund, wieso man, wenn man Spiele ENTWICKELT (im Gegensatz zum Spielen der Spiele), viele Dinge tun muß, die (aus Sicht eines Spielers) überhaupt nichts mit "Spielen" zu tun haben: Intern werden für Levels, Grafikdaten, Musikdaten, Figurendaten quasi "Datenbanken" angelegt und Routinen, die diese auslesen und darstellen/abspielen können. Alles, was man intern macht, basiert auf ZAHLEN - seien es Noten, Farben, Figurenpositionen, Spielereingaben usw. - weil das Ding eben eine zahlenbasierte Rechen-/Speicher-Maschine ist.

Wenn also jemand kommt mit: "Schau, ich hab auf dem Computer ein Rechenprogramm gebaut", da denke ich eher: "Ja, na und? Rechnen kann das Ding sowieso von alleine - das bißchen Ein-/Ausgabe ist eigentlich meist auch schon vorhanden - also für mich kaum der Rede wert." Wenn aber jemand käme mit: "Schau, ich habe ein Spiel programmiert, 4farbig, grobe Auflösung, aber einige einfache Figuren, Levels, Klänge..." da weiß ich: Da steckt WIRKLICH Arbeit und Hirnschmalz drin - weil man den Rechenknecht dazu gebracht hat. etwas zu tun, das er eben NICHT "einfach so" von alleine kann... Und da ist das simpelste Spiel immer noch komplexer als das meiste andere, was man so mit Computern machen kann. (Liegt u.a. daran, daß man für ein Spiel sozusagen Multifähigkeiten haben muß für die verschiedenen benötigten Einzelteile/Einzelaspekte.)

Und wenn dann jemand da ist und zeigt: "Schau mal, hab die zehnte Version eines OS mit grafischer Benutzeroberfläche und wackelig funktionierenden Multitaskings, sowie kaum noch zu überwachender Sicherheitslücken gebaut" - da denke ich: "Gähn! Und was kann das Ding mehr als das, was vor 20 Jahren gemacht wurde - außer mehr Speicher und mehr Rechenleistung verbrauchen?" Das wirkt auf mich so, als wenn man den Leuten immer wieder das gleiche Programm andrehen will, nur jedesmal von außen anders angemalt... - Da respektiere ich JEDEN Spieleentwickler hundertmal mehr.

zatzen hat geschrieben:Und das funktioniert auch prima wenn man die Ruhe hat und eine konkrete Vorstellung davon,
wie es klingen soll. Bei einem klassischen Tracker sind es eben einfach Daten, die Zeile für Zeile ablaufen. Das ist je nachdem sehr redundant, ist aber dann von Vorteil, wenn man einfach ins Blaue hinein direkt im Tracker selber ein neues Musikstück erfinden will und die Inspiration während der Sitzung erst kommt. Und das war eben bei mir bisher fast immer so.

Naja, wie oben beschrieben kommt die Inspiration bei mir auch während des Entwickelns - nur eben anders: Ich baue Dinge, die erstmal als Monostimme schonmal gut klingen. Dann baue ich weitere Teile und kombiniere sie dazu, rekombiniere, spiele die gleichen Teile mit anderen Instrumenten oder anderen Oktaven ab usw. Am Ende kommt ein abwechslungsreiches Stück heraus, manchmal auch etwas, das viel besser ist, als ich selbst anfangs damit gerechnet habe... - Und wenn ich da immer wieder das gleiche dauernd neu eingeben/kopieren usw. müßte bzw. jedesmal, wenn mir z.B. die Begleitung nicht ganz gefällt und ich eine schnelle andere Inspiration hätte - und dann diese an 20 Stellen manuell ändern müßte, damit es so wird, wie ich will und wenn es schief ist, das wieder an 20 Stellen manuell zurückändern müßte... - das wär mir echt zu blöd...
Aber jeder hat da wohl eine andere Vorgehensweise, wie er Musik macht - für Kunst gibt es keine Vorschrift.

zatzen hat geschrieben:Ich pitche im Tracker auf die "billige" Weise, höher gespielte Samples werden kürzer etc.

Ich auch.

zatzen hat geschrieben:Das kann manchmal bei komplexeren Samples zu neuen Ideen inspirieren, oder man muss versuchen die Rhythmik durch Verschieben entsprechend auszugleichen.

Ja, wie im Stück "ID" von Skaven (einer der 2 Musiker von Future Crew) das "Scream-of-Agony" Sample verschieden eingesetzt wird, finde ich immer noch total faszinierend. Das ist SOWAS ist cool. (Langsam, normal schnell, doppelt... tja, manche Leute haben's einfach drauf - und verstanden, was die eigentliche Idee hinter MOD, Midi usw ist: Wiederverwenden. Also: Für jeden 3. Ton 'n neues anderes Sample ist Bullshit.)

zatzen hat geschrieben:64 Zeilen sind schon okay, ich habe mich in X-Tracker auf 128 (8 Zeilen pro Viertelnote)
eingeschossen, nutze aber nicht immer 32tel... Die braucht ein Musikstück nicht unbedingt.

Naja, wie bereits erwähnt: Man ist in der Wahl, was eine Zeile für eine "kleinste Note" sein kann, bei AtavISM relativ frei: Alles von 1/128 bis 255/128 ist möglich. (255/128 bedeutet: Eine Zeile=knapp 2 Sekunden. Wird man kaum nutzen. Der Wert hat eben diese Reichweite.) Das heißt: Mit Wert 8 sind es 16tel (8/128 = 1/16), mit Wert 4 sind es eben 32tel (4/128 = 1/32). usw. Es ist eben so, daß die Gesamtspiellänge des Patterns sich verkürzt, je kleinere Werte man nimmt. Also bei 16tel sind es 4 Sekunden (64/16=4), bei 32 eben nur 2 Sekunden (64/32=2).

Das ist eben wieder ein Nachteil von MOD: Ein ganzes Pattern kann nur halb so lange dauern und braucht dafür doppelt soviele (99% "Leer"-) Daten - sobald zwischen vielen maximal 16tel Noten nur mal eine einzige 32tel gebraucht wird. In ISM, wo es keine Tracks/Patterns gibt. wäre das nicht nötig - allerdings natürlich leider in AtavISM, weil es sich ja dem Patternformat anpassen muß.

zatzen hat geschrieben:Danke für Deine wertvollen Erklärungen zum Thema nur-Sprites-setzen!

Ja, weiß jetzt gerade nicht, auf welche der vorgeschlagenen Methoden in meinem Text Du Dich da gerade beziehst... - aber trotzdem: Gern geschehen! - Und wie gesagt: Wenn ich mich noch eine Weile damit beschäftigen würde, fiele mir sicher noch mehr dazu ein. Aber ich selbst habe ja bereits meine Sprite-/Level- usw. Routinen und muß deshalb nicht drüber nachdenken. Natürlich schließt das nie aus, daß ich für ein Spiel mal eine andere, einfachere (oder kompliziertere) Sprite-Routine verwenden könnte. Weil ich ja modular programmiere, kann ich die Routinen auch einfach austauschen. Nur weil SLOT verschiedene Dinge ANBIETET, muß man sie nicht alle benutzen - es ist absichtlich "offen" konzipiert, damit man auch eigene, andere Dinge da einbringen kann. Das soll bewirken, daß es kein starres "Game-Maker"-artiges "Fertigprodukt" wird, in dem irgendwie alle Spiele "gleich aussehen"... (Ihr wißt, was ich meine.)

zatzen hat geschrieben:Ich bin in diesem Post etwas kurz angebunden weil der Grund warum ich schreibe eigentlich der ist, dass ich eine Idee für ein Spieleformat hätte, das mein Problem mit der Synchronität vs. Steuerung umgehen würde:

Neue Ideen sind immer gut! (Außer neue Ideen zur noch effizienteren Kriegsführung - solchen Leuten würde ich gerne die Menschenrechte aberkennen und sie von der Menschheit ausbürgern.)

zatzen hat geschrieben:Was ich sowieso schonmal in Erwägung gezogen hatte und sich jetzt vielleicht manifestiert - eine Art Gesellschaftspiel wo erst die Spieler abwechselnd einen oder mehrere Kommandos an Roboter oder was auch immer vorgeben können und dann irgendwann alles ausgeführt wird. Prinzipiell wäre auch soetwas wie Worms
denkbar, aber das ist ja schon ausgelutscht. Vielleicht fällt mir da ja was nettes ein, ich sehe da eigentlich viel Potential, man muss nur mal groß ausholen bei Ideen sammeln.

Naja - schon mal "Lemmings" gespielt?

Ich sage mal so: Für mich wäre das genannte Spielprinzip wohl nichts - ich kann mit Spielen nichts anfangen, wo man immer zusätzlich jemanden braucht, um es zu spielen. Ich brauche Singleplayer-Spiele. Etwas ähnliches wie das obengenannte hatte ich vor Jahren mal vorgehabt (und teilweise programmiert/entwickelt) : Eine Art stark erweitertes "Game of Life", wo man verschiedene Lebewesen hat, die unterschiedlich miteinander interagieren (Fressen, Ausweichen, Düngen, Fortpflanzen usw). Jeder Spieler hätte anfangs eine festgelegte Art und Anzahl Lebewesen (oder "Lebenspunkte") und je nach Art des Lebewesens bräuchte man so viele Punkte, um es zu generieren, da kann man dann eben viele kleine oder wenige große oder Mischformen bauen. Jeder Spieler hätte eine eigene Farbe. Die Farbe oder Farbschattierung, die am Ende noch am meisten vorhanden wäre, hätte gewonnen. Nach dem Start des "Spiels" könnte man nur noch wenig in das Spiel eingreifen, sondern müßte sehen wie es sich entwickelt.

Angedacht waren:
Kohlköpfe. Diese vermehren sich so wie die "Zellen" in "Conway's Game of Life", d.h. wachsen, vermehren sich, sterben ab, wenn zu viele auf einem Haufen... usw. eben nach den bekannten Regeln.
Schlangen. Diese funktionieren wie die Schlange in "Snake": bewegt sich weiter, wird länger, wenn sie frißt. Muß aufpassen, daß sie sich nicht selbst beißt oder "einkesselt". Kann sich mit anderen Schlangen vermehren (Schlangeneier, aus denen nach einer Weile Schlangen schlüpfen.)
Hasen. Futter sind Kohlköpfe. Hasen sind wiederum Futter für Schlangen.
Ameisen/Insekten... - können Schlangeneier befallen... Hatte irgendwie noch mehr Ideen.
Hatte die Grafiken UND Grafikengine (VGA UND VESA!) dafür schon fertig. Ein Spielfeld ist max. 128x128 Felder, kann auch hin- und her scrollen. Auflösungen 320x200, 640x480, 800x600, 1024x768. War sehr schnell, weil 8-pixel-weises (weiches!) Scrollen. Steuerung war in ASM. Naja. bis jetzt sind sichtbar nur die Kohlköpfe, also ist es quasi derzeit ein cooles schnelles "Conway's Game of Life". Wenn sich irgendwas mit irgendwas vermehrt (kreuzt), werden die Farben miteinander nach vorgegebenen Regeln vermischt.
Habe das hier noch herumliegen.

Naja, ich hatte das - wie so viele Projekte - nie fertiggemacht, weil dann immer entweder jemand kam, der "mal ein kleines Tool brauchte" (ja, damals kam da wirklich manchmal einer) oder weil ich selbst dann wieder neue Ideen für andere Sachen hatte. Ich habe so viele Ideen... Es ist so: Ich kann inzwischen (ohne zu übertreiben) recht viel, also eigentlich ALLES, was zum Bauen eines 2D-Spiels erforderlich wäre, sowie eines 3D-Spiels, solange es nicht über Grafikfähigkeiten von Doom hinausgehen würde - ABER: Spieleentwicklung dauert lange - nur weil programmtechnisch alles da ist und man "den Rest" auch noch irgendwie programmieren könnte, der das alles "zusammenkittet", muß ja auch irgendwer die Grafiken machen, die Musiken/Sounds machen, die Levels bauen, die Figuren bauen inkl. Steuerung usw. - und DAMALS gab es viele Leute (lange her), die sagten oft sowas wie "cool, Spiele machen!" und hätten gern "mitgemacht". Nur "mitmachen" wäre bei denen gewesen: Ideengeber. Und dann am Ende in den Credits auftauchen als "Idee" - ohne irgend etwas von der restlichen Arbeit zu machen. Und, wie ich schon mal erwähnte: Das, was ich für ein Spiel (oder 10 Spiele!) am wenigsten brauche, ist ein "Ideengeber" - ich habe so viele Ideen, da bräuchte ich 5 Leben, um die alle umzusetzen, Nur daß das "Umsetzen" dann eben die meiste Arbeit ist und darauf hat keiner Lust: Nach (lockeren) Vorgaben an etwas bestehendem mitzuarbeiten. ---

Und damit schließt sich der Kreis, da bin ich wieder bei der genannten "Instant Gratification" (= "Sofortige Belohnung") angekommen. So etwas wie GEDULD kennt man heute gar nicht mehr. Daß irgend etwas mal länger dauert oder etwas mehr Mühe macht, das ist eher etwas für die etwas ältere Generation. Wenn aktuell nicht der kleinste Aufwand sofort mit irgend etwas belohnt wird, wird es schon als "nicht den Aufwand wert" angesehen.

Eine zusätzliche Schwierigkeit ergibt sich aus der "Generation App": Wieso einfach mal irgend etwas nur aus Spaß an der Freunde oder an der Sache an sich machen? Wieso einfach etwas machen, das "einfach nur cool" ist und es der Welt schenken (so wie dieser coole Schwede von Wintergatan mit seiner Marble Machine - ja, Martin Molin)? NEIN! Geht ja nicht! Für UMSONST irgendwas machen? Wo man kein Geld dafür kriegt? Wo man vorher nicht GARANTIERT kriegt, daß man der totale Held der Massen wird? Wo man sich vielleicht einfach mal die Mühe macht, einfach weil es einen SELBST interessiert, was rauskommt, was man schaffen kann und wo es egal ist, wie "massenpopulär" es ist? Undenkbar! Schließlich leben wir im Kapitalismus! Die "Generation Smartphone" wäre gar nicht fähig, etwas ebenso Weltumfassendes wie das Smartphone selbst zu erfinden, weiterzuentwickeln usw. - Das dauert ja viel zu lange! Von dieser Generation wird GAR NICHTS mehr kommen. Sie wurde zum 100%igen Konsumenten erzogen. Etwas selbst erschaffen, am Ende noch kostenlos für alle - damit ginge man ja in Konkurrenz zur Industrie! Da wundert es kaum, daß die Industrie kein Interesse daran hat, Leute zum "Selbermachen" zu animieren. Stumpfes Nutzen und Verbrauchen ist das Credo. Und alles, was mehr Mühe macht, als ein Wischen mit dem Zeigefinger ist es nicht mehr wert, überhaupt anzufangen... ---

Da wird es schon schwierig, jemanden zu gewinnen für ein Ding, wo von vornherein klar ist, daß es nicht die geringste Belohnung dafür geben wird und auch zu 99% sicher ist, daß man nicht mal "der Held" dafür wird (die 1% "Glücksfall", daß etwas zufällig mal, wie man heute sagt "viral" wird, kann man nicht voraussetzen). Und DOS-Spiele gehören zweifelsfrei in diese Sparte.

Und nein - diese aktuelle Generation paßt sich (natürlich) nicht der "alten" Generation an - das muß sie auch nicht, das erwartet auch keiner. Das eigentlich Bedauernswerte ist, daß die "alte" Generation so langsam Verfallserscheinungen zeigt - indem sie sich der aktuellen Generation anpaßt: D.h. Omi und Opi, Mami und Papi müssen jetzt den gleichen Mist haben und die gleiche Lebenseinstellung teilen wie die aktuellen Zombie-Kids. Daß ein 20-jähriger OHNE Smartphone, OHNE 4k-HDMI-TV und OHNE weiteren Firlefanz von seinen Gleichaltrigen ausgelacht wird, könnte man ja noch verstehen, weil das schon immer so war bei "Unangepaßtheit" von Gleichaltrigen...

Aber daß inzwischen 40jährige oder 60jährige sich auch schon (vor anderen 40- und 60-jährigen!) dafür rechtfertigen müssen, daß sie den Zombie-Kids-Quatsch NICHT mitmachen und NICHT genauso hirntot und antriebsresistent sind wie ein aktueller 20jähriger... das ist schon albern - aber trotzdem leider wahr.

Und mein Fazit daraus: Für mich selbst, den Geduldigen - und leider aus Gründen von Zeitmangel, Müdigkeit, Kraftmangel auch weniger Produktiven als er's gerne wäre - stellt sich inzwischen nicht mehr die Frage oder das Ansinnen, jemanden zu finden, der bereit ist, "auf DOS-Niveau", mit "DOS-Tools" und "Mühe wie man sie vor 30 Jahren brauchte" zusammen Spiele zu machen. Also Fazit: Wenn der Aufwand ein gewisses Level übersteigt (komische Tools, die einem NICHT alles fast fertig vorkauen) und das Ergebnis sich NICHT mit aktuellen Spielen auf aktuellen Systemen messen lassen kann (kein Ruckeln, volle Framerate, kleine und (scheinbar ja ganz wichtig!) UNBEDINGT QUADRATISCHE! Pixel, Musik/Effekte in CD-Qualität. bzw zumindest immer 44 kHz, mindestens tausende, wenn nicht Millionen von Farben) - also alles Dinge, die SO GAR NICHTS sowohl mit Entwicklung als auch mit Spielen auf einer typischen DOS-Maschine zu tun haben... - dann wird sich keiner finden, der eben WIRKLICH (wie man es für meine Systeme und Arbeitsweise leider sein müßte) "DOS-mäßig" und "1993-mäßig" drauf ist, sondern eher nur, so wie das heute so schön genannt wird:
"RETRO" - was scheinbar bedeutet: "Wie früher[tm], aber bitte ohne die ganze Arbeit und bitte auf modernen Systemen mit modernen Parametern".

Ja, ich weiß: Ich bin immer nur am Meckern. Liegt bestimmt am Alter...
Benutzeravatar
zatzen
617K-Frei-Haber
Beiträge: 328
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitragvon zatzen » Sa 15. Sep 2018, 20:16

FreePascal:
Die Inkompatibilität zu TP wird daher rühren, dass Free Pascal im Protected Mode läuft bzw. in Windows,
oder je nach Compiler für andere Plattformen. Ich finde an FP praktisch dass man ganz einfach 4 GB Speicher
nutzen kann, damit ist man für reine Datenverarbeitungs-Tools sehr flexibel. Arrays können praktisch
beliebig groß sein, und soetwas wie getmem braucht man eigentlich gar nicht mehr.
Gleichzeitig ist natürlich auch der Assembler ein anderer. Da müsste man sich wohl mit dem Assembler
des Protected Modes auskennen und wie Assembler bei linearer Speicherarchitektur funktioniert bzw.
ohne klassische Strukturierung mit Segmentregistern. Ich glaube so ein Befehl wie LES funktioniert
in Freepascal gar nicht, oder ganz anders als im Real Mode.
Andere Dinge wie direkte Portzugriffe werden wohl durch das Betriebssystem verweigert und so in FP nicht angeboten -
und hier erklärt sich auch für mich, warum ich, trotz der theoretisch grenzenlosen Möglichkeiten
in Freepascal, multimediale Dinge immer noch lieber im "uralten" Dos-System programmiere:
Ich hab einfach keine Lust, mich zu belesen wie ich innerhalb Windows irgendwelche DLLs
benutzen "darf" um dann damit "schön" in Hochsprache Grafik oder Ton zu zaubern. Es ist
viel faszinierender wenn man direkt mit der Hardware kommunizieren kann und weiss was wirklich
im Computer passiert, und dabei auch noch selbst mit geschickter Programmierung dazu
beitragen kann, dass alles möglichst performant wird, wenn man dabei etwas über die Computerarchitektur
versteht, immer wieder dazulernt, und nicht immer nur wieder und wieder neue Bibliotheken benutzt,
die irgendwas machen, aber man weiss nicht wie sie es machen.
Zum Assembler: Das hatte ich schonmal geschrieben, man kann in FP den Assembler auf Intel Syntax
umkonfigurieren. Dann sind einfach Dinge wie "mov variable, wert" oder dergleichen möglich,
jedoch müsste man sich schlau machen wie komplexere Dinge wie das Arbeiten mit Speicheradressen
gemacht werden muss - da man sich hier ja nicht mehr im Real Mode befindet.
Mem[ ] gibt es, allerdings nur noch mit einem Wert drin und nicht mit Segment und Offset,
und von der Benutzung wird abgeraten.

Musik "vortrackern":
Nein, es läuft nicht unbedingt auf Sampling raus. Es geht mir nur darum, ein konkretes Musikstück
erarbeitet zu haben, bevor ich es in AtavISM programmiere. Wenn Du mir sagen würdest, mach mal
dieses oder jenes schon existente bekannte Musikstück in AtavISM, dann müsste ich nicht vortrackern.
Aber im Tracker Musik zu erfinden ist meine persönliche vorgehensweise des Komponierens, und dass
ich da Samples benutze ist nur systembedingt. Ich würde dann eben nicht komplexe Samples verwenden
sondern praktisch nur "Töne", damit auch eine Transfermöglichkeit zu (Atav)ISM besteht, ohne Samples
zu verwenden.
Nebenbei habe ich mir ja selber auch zwei OPL3 Tracker geschrieben und damit überhaupt keine
Probleme gehabt.

Bei Trackern fängt es übrigens auch schon an dass man kein richtiger Musiker ist...

Ich glaube ich kenne das mit der Speicherbeschränkung nur zu gut:
Ich habe damals in QuickBasic programmiert (immerhin Compiler, kein Interpreter), aber
trotzdem war ich entweder zu blöd oder es war so: Der Code konnte nicht größer als 64 KB sein
und es gab nur Arrays die ihrerseits in 64 KB bleiben mussten. Also insgesamt nur 128 KB zur Verfügung.
Hab ich dann so gelöst dass jedes Level eine andere EXE war. Natürlich getarnt durch Umbenennen und gesichert
durch eine kleine Datei mit "Schlüssel"...

Klar, Spiele haben einen sehr viel komplexeren Ablauf... Bei einer Tabellenkalkulation ist es ja einfach
ein linearer Ablauf, Formeln, die durchgerechnet werden, und dann ist wieder Ende.

Musik-Vorgehensweise: Ja, jeder ist da anders. Für mich ist es eher ein linearer Prozess. Ich probiere
herum bis mir etwas wirklich gefällt und gehe dann weiter. Probiere wieder usw. Irgendwann ändere
ich was usw. Das ist nur meine Vorgehensweise, hat sich so entwickelt.

Lemmings habe ich einige Zeit begeistert gespielt. Aber das war auch zu der Zeit wo mich die
320x200x256 Auflösung total vom Hocker gehauen hat, gerade weil sie pixelig war und alles ein
wenig nach zauberhaft durchsichtigen kleinen quadraten aussah - das nur nebenbei.
Lemmings mit meiner "Engine" zu realisieren fände ich schon wieder ein bisschen kritisch,
weil das Anklicken der kleinen Männchen schon wieder etwas hinterherhinken würde.

Es wäre für so ein angedachtes Spiel von mir natürlich auch erstrebenswert eine KI zu implementieren
für den Single Spieler. Aber was ich mit ausholendem Nachdenken über Ideen meinte: Nicht-Echtzeit
Spiele können eine Mischung aus allem möglichen sein: Sei es etwas mit Worms, The Incredible Machine,
Bundesliga-Manager Pro, oder auch, dass man die Spielfiguren mit einer Pseudo-KI programmiert, d.h.
was sollen sie tun wenn sie vor eine Wand laufen usw.
Und Du hast ja selbst Deine Spielidee in diesem Rahmen beschrieben.

Ich hätte zum Ziel, dass das Spiel letztlich einen heiteren Unterhaltungswert hat, es also nicht in
erster Linie nur darum geht wer gewinnt und dass man mit möglichst viel Strategie und Intelligenz
rangeht, sondern dass man auch mal lachen kann wie z.B. bei Worms wenn die irrwitzigsten Kettenreaktionen
passieren. Ist nicht jedermann's Sache, aber ich würde es für mich und gleichgesinnte machen.

Nebenbei, etwas was ich gerne in FP realisieren würde (doch mir fehlt die Schnittstelle zum Ton):
Ich nehme aus Hörspielen Sätze auf, speichere diese ab und jeder Satz bekommt ein paar Tags,
bezogen auf ob und was derjenige Satz aussagt, fragt, welche Emotion er hat usw.
mit dem Ziel dass sich am Ende verschiedene Sprecher ewig miteinander unterhalten.
Das wäre auch wieder eine Sache die man nur dann nicht als sinnlos empfindet, wenn man
soetwas lustig finden kann. Ansonsten wäre für mich daran einfach interessant, ob sich durch
so eine simple Kategorisierung durch Tags tatsächlich einigermaßen sinnvolle Gespräche ergeben.
Natürlich liegt dabei die eigentliche "KI" in dem Programm das sich die Tags "ansieht" und den
Ablauf der einzelnen Sprachbeiträge entsprechend organisiert.
Die Schnittstelle zum Ton brauche ich eigentlich nicht, ich kann auch eine WAV erzeugen.

Mitmachen: Teamarbeit wäre schon schön. Aber dazu gehört dann eben auch Verantwortung übernehmen
und jeder muss seine klare Aufgabe haben, die er zuende bringen muss.

Ich tue so ziemlich alles was ich freiwillig tue auch nur aus Spaß an der Freude.
Und ich will hier nicht rumheulen aber es kann mich schon ein bisschen ärgern wenn
jemand sagt soetwas wie ZSM wäre sinnlos weil es kein Format ist das sich großartig etablieren wird.
Nein, ich habe es gemacht als Realisierung meines ganz persönlichen kleinen Traumes, überhaupt
mal einen "MOD" Player geschrieben zu haben, und mittlerweile hat es für mich spätestens seit
der 4 Bit Sample Speicherung einen deutlichen Mehrwert.

Ja, als Retro wird bezeichnet was Retro aussieht. Also pixelig, aber trotzdem Millionen Farben und Orchestermusik.
Die Leute sind eben Augenmenschen.
Frust über die Situation kann ich schon nachvollziehen. Vielleicht habe ich nur schon meine Konsequenzen
gezogen und beschäftige mich mehr mit meinen anderen Hobbys. Oder ich ziehe immer noch genug Befriedigung
aus meinem ZSM-Player, der kein Spiel ist, aber für mich immer noch ein weiter Schritt nach vorn.
Ich bin darauf nicht stolz oder so aber es ist einfach etwas relativ neues, nie habe ich so viel und überlegt Assembler
geschrieben und mit selbigem so viel Datenumsatz gemacht, dass dabei ein flüssiger Player rauskommt.
Ich kann mich da eben immer noch dran erfreuen, nicht mehr so wie ganz am Anfang, aber eben immer noch
ein ganzes Stück.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast