Trackermodul-Engine (sehr einfach)

Diskussion zum Thema Programmierung unter DOS (Intel x86)
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

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
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

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.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

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
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

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.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

zatzen hat geschrieben: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.
Dann kann ich nichts damit anfangen. Der Protected Mode hat nicht nur Vorteile. Außerdem sind meine ganzen Units auf Real-Mode (und Segmentierung!) ausgelegt.
zatzen hat geschrieben: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.
Ja, aber so etwas verleitet auch leicht zu speicherverschwendender Programmierung - und dazu, daß man Programme schreibt, die auf Systemen mit weniger Speicher nicht mehr lauffähig sind (oder, wenn in Windows: Grottenlangsam werden, weil ständig "virtueller Speicher" aus-/eingelagert werden muß auf Festplatte)
zatzen hat geschrieben: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.
Ja, also nichts für mich. Ich dachte immer, das Ding kann Realmode (ab 386er, also mit 32bit Befehlen, erweiterten Segmentregistern, neuen Befehlen) UND Protected Mode.
zatzen hat geschrieben:Andere Dinge wie direkte Portzugriffe werden wohl durch das Betriebssystem verweigert und so in FP nicht angeboten [...]
Ja, und noch ein Grund für mich, es nicht zu wollen.

zatzen hat geschrieben: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.
Klar - weil das im Protected Mode kaum Sinn macht...
zatzen hat geschrieben: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.[...]
Schau mal in meinen Thread "Nicht Tracker..." rein. Da findest Du vielleicht etwas Interessantes.

Mehr später. Ich muß los.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

Freepascal kenne ich nur unter Windows. Gut, man könnte meinen, da wäre noch Real Mode möglich,
da ja auch gewisse Dos-Programme noch unter 32 Bit Windows laufen. Aber spätestens seit 64 Bit
ist da Schluss. Allerdings habe ich auch noch gar nicht nachgeprüft ob FPC nicht doch einen Real
Mode hat - wie auch immer, man muss wissen was man will, ich nutze FPC gerne für Tools die große
Datenmengen verarbeiten, wo es mit TP nur umständlich wäre und sonst keine Vorteile hätte.


Ich habe mich gerade hochmotiviert an AtavISM gesetzt und wollte ein 1-Pattern Dauerschleifen-
Stück aus meinem Repertoire umsetzen. Hat für die erste Spur auch wunderbar geklappt.
Mein Problem ist jetzt, dass außer der ersten Spur nichts abgespielt wird, auch wenn beim
Eingeben auf den anderen Spuren etwas zu hören ist.
EDIT: D.h. es ist nichts zu hören wenn ich ein bearbeitetes Instrument verwende, beim Standardklang schon.
Allerdings funktionieren bearbeitete Instrumente auf Kanal A.
EDIT2: Hier ist die Datei: http://www.zatzen.net/dauersng.zip
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

zatzen hat geschrieben:Freepascal kenne ich nur unter Windows. Gut, man könnte meinen, da wäre noch Real Mode möglich,
da ja auch gewisse Dos-Programme noch unter 32 Bit Windows laufen. Aber spätestens seit 64 Bit
ist da Schluss. Allerdings habe ich auch noch gar nicht nachgeprüft ob FPC nicht doch einen Real
Mode hat - wie auch immer, man muss wissen was man will, ich nutze FPC gerne für Tools die große
Datenmengen verarbeiten, wo es mit TP nur umständlich wäre und sonst keine Vorteile hätte.
Ich habe heute in der Pause auf Arbeit etwas recherchiert. Also offenbar gibts bei FreePascal auch 16bit (DOS). Aber da muß ich mich wohl noch mal belesen. Vielleicht geht's ja doch. Als ich damals (länger her) mit FP mein Zeug versucht habe zu compilieren, war es ein Alptraum.
zatzen hat geschrieben:Ich habe mich gerade hochmotiviert an AtavISM gesetzt und wollte ein 1-Pattern Dauerschleifen-
Stück aus meinem Repertoire umsetzen. Hat für die erste Spur auch wunderbar geklappt.
Mein Problem ist jetzt, dass außer der ersten Spur nichts abgespielt wird, auch wenn beim
Eingeben auf den anderen Spuren etwas zu hören ist.
EDIT: D.h. es ist nichts zu hören wenn ich ein bearbeitetes Instrument verwende, beim Standardklang schon.
Allerdings funktionieren bearbeitete Instrumente auf Kanal A.
EDIT2: Hier ist die Datei: http://www.zatzen.net/dauersng.zip
Ich würde das Problem gerne nachvollziehen können - aber bei mir funktioniert es. Einfach mit F5 abspielen.
(Oder bei Play die erste Einstellung.)
Ich habe die Sachen für F6, F7 und F8, die bei prISM gehen, noch nicht für AtavISM umgesetzt (Einzelstimmen, beliebige Startposition). Aber F9 geht auch (d.h. Abspielen ab einem bestimmten Zeitindex, damit man beim Testen nicht immer alles bis zur bestimmten Stelle durchspielen muß.)
Wenn ich das Problem nachvollziehen könnte, würde ich da was machen. Aber einen Fehler, den ich nicht sehe, kann ich natürlich auch nicht fixen.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

seltsam...
Dass wir uns nicht missverstehen, Kanal A tönt, B-D nicht, sollten aber.
Ob das an Dosbox liegt? Aber wohl eher nicht, der Klangpuffer wird ja
rechnerisch erzeugt und die Tonbildung unterliegt keinerlei Hardware-
konfiguration.
Ich könnte mir dann höchstens noch denken, dass AtavISM bei mir irgendwie
anders konfiguriert ist. Mal sehen ob ich da was "resetten" kann...
EDIT: Über F6 abgespielt klingt es laut und verzerrt. Ähnlich wie signed/unsigned gewandelt.
EDIT2: CFG gelöscht und Soundblaster neu eingestellt, immer noch nix auf B-D

...hier noch ein screenshot: http://www.zatzen.net/dauersng.png
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

zatzen hat geschrieben:seltsam...
Dass wir uns nicht missverstehen, Kanal A tönt, B-D nicht, sollten aber.
Ob das an Dosbox liegt? Aber wohl eher nicht, der Klangpuffer wird ja
rechnerisch erzeugt und die Tonbildung unterliegt keinerlei Hardware-
konfiguration.
Ich könnte mir dann höchstens noch denken, dass AtavISM bei mir irgendwie
anders konfiguriert ist. Mal sehen ob ich da was "resetten" kann...
EDIT: Über F6 abgespielt klingt es laut und verzerrt. Ähnlich wie signed/unsigned gewandelt.
EDIT2: CFG gelöscht und Soundblaster neu eingestellt, immer noch nix auf B-D

...hier noch ein screenshot: http://www.zatzen.net/dauersng.png
Tja... soviel zum Thema DOSbox ist total kompatibel.
Unter reinem DOS läuft es (alle Stimmen).
Unter DOSbox 0.74 auf WinXP läuft es (alle Stimmen).
Unter DOSbox 0.74 auf Win7 ist nur die erste Stimme zu hören.
Selbes Programm, selbe Daten.
Nun sag mir einer, woran das liegt! An meiner Programmierung?
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

Nein, offensichtlich rafft Dosbox unter der Herrschaft von Windows 7 irgendwas weg
was eigentlich bleiben sollte. Oder irgendwie...

Dann werde ich einfach meinen XP Laptop für AtavISM verwenden.

Mir persönlich wäre zwar neben der echt-Dos Kompatibilität auch Zwecks Portabilität
das Funktionieren in Dosbox auf jedem Betriebssystem wichtig, aber gleichzeitig
stehe ich umsomehr auf Deiner Seite, wo wir hier sehen, dass nun tatsächlich
Unterschiede im Programmablauf zwischen echt und emuliert auftreten, und das
sogar auf Code-Ebene.

Interessant wäre trotzdem soetwas wie, welche Assembler-Befehle und Konstrukte
Du in den Mischroutinen (falls dort der "Fehler" liegen sollte) verwendet hast,
falls Du es preisgeben möchtest und Dich die weitere Erörterung überhaupt interessiert,
zumal Dir es ja eben gar nicht auf "Kompatibilität" zu Dosbox ankommt - wir haben hier
eher einen Fehler IN DOSBOX gefunden dem sich das Entwicklerteam annehmen sollte.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

So, hab nochmal getestet:
In der 32-bit Version von DOSbox funktioniert es auf dem (64bit) Win7.
In der 64-bit Version funktioniert es nicht.
Ich nehme einfach folgendes an:
Ich arbeite aus Gründen der Geschwindigkeit und des Registermangels in ISM oft mit selbstmodifizierenden Code-Stellen. CPUs haben einen Prefetch-Queue und daraufhin auch eine Befehls-/Sprung-Vorhersage.
Je neuer die CPU ist, um so "ausgefeilter" ist das - aber umso weniger gehen "Tricks".
Wenn ich eine Selbstmodifikation mache und danach folgt irgendwo ein Sprung, wird normalerweise der Prefetch-Queue der CPU geleert (der übrigens je nach Modell unterschiedlich lang ist). Falls da kein Sprung kommt, mache ich einen "Null-Sprung" (also gleich zur folgenden Adresse, also Verzweigen um 0 Bytes) um damit den Queue zu leeren. Das kommt an einigen Stellen vor.
Es könnte aber auch an VÖLLIG anderen Sachen liegen, denn in Stimme 0 scheint es ja zu funktionieren.
Herauszufinden, WELCHEN Opcode DOXbox (64bit) nicht korrekt emuliert... das dürfte schwierig werden...

- ABER -
Ich will auch nicht vorschnell DOSbox die Schuld geben.
Es kann auch durchaus an irgendwelchem Mist liegen, den ich selbst verbockt habe: z.B. Speicher nicht gelöscht oder sowas und in einer DOSbox löscht der den ganzen Speicher vorher und im anderen nicht oder umgekehrt - und deshalb bleiben bestimmte Variablen uninitialisiert.
Ja, da muß ich wohl am Wochenende mal die ganzen Debug-Ausgaben anschalten und mal schauen woran's liegt.
Du kannst es ja inzwischen mal mit der 32-bit-Version von DOSbox versuchen, die läuft auch auf 64-Bit Systemen.
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

So, ich habe es getestet. Und: Es ist in der Tat EIN BUG IN DOSBOX!
Habe mal ein Mini-Testprogramm gebaut:

Code: Alles auswählen

var a,b:byte;
begin writeln;
for a:=127 to 129 do
    begin
    asm
    mov b,0;
    ror a,8;
    rcr b,1;
    end;
    writeln(a:4,b:4);
    end;
readln;
end.
Ausgabe DOS:
127 0
128 128
129 128
(also korrekt)

Ausgabe DOSbox 32bit unter WinXP:
127 0
128 128
129 128
(also korrekt)

Ausgabe DOSbox 32bit unter Win7:
127 0
128 128
129 128
(also korrekt)

Ausgabe DOSbox 64bit unter Win7:
127 128
128 128
129 128
(also FALSCH!)

Das heißt: Die 64bit-Version von DOSBOX hat einen Bug beim ROR Befehl.
(Vielleicht auch noch bei anderen!)

Was macht der o.g. Kram? Naja, wenn man ein Byte um 8 nach rechts rotiert, bleibt das Byte erhalten - ABER das Carry-Bit ist dann das gleiche, das als letztes wieder reinrotiert wird. Muß bei Werten <=127 also =0 sein und bei Werten >=128 dann =1. (Wenn man danach mit RCR es wo reinrotiert, dann ist es 0 oder 128.)
Ich benutze an einer Stelle diesen Trick, um das obere Bit ins Carry zu kriegen, ohne den Wert der Stelle zu ändern. Und ich benutze solche Dinge öfters mal in meinen Programmen.
Also hier hat wohl einer kolossal Mist gebaut beim Emulieren des ROR-Befehls.

Mit einem weiteren Testprogramm habe ich getestet - bei ALLEN Werten, selbst bei 0 und wenn vorher Carry=0 war, wird es =1. Das ist sowas von falsch, das geht GARNICHT!
Und wer weiß, welche Bugs da noch so drin sind.

Und ich baue bestimmt nicht alle meine Programme so um, daß sie auch auf fehlerhaften Emulatoren laufen.

Also, mein Vorschlag: Benutze die 32bit-Version von DOSbox (die läuft auch unter 64bit-OS).

Wie ich auf den Fehler gekommen bin?
Naja, habe ein Hexdump der Registerinhalte von ISM gemacht und gesehen, daß in der DOSbox 64bit-Version etwas passiert, das genau diesen Fehler auslöst.

Erklärung:
Wie Du vielleicht weißt (vielleicht auch nicht, weiß nicht, wie sehr Du Dich schon mit ISM beschäftigt hast), supportet ISM die Zuordnung der einzelnen ISM-Stimmen zu jeweils einem "Device" (0 oder 1). Diese "Devices" haben jeweils ihre eigenen Ein- und Ausgabeinterfaces (d.h. Variablen). Also z.B. werden "Instrumente" und "Hüllkurven-Timeouts" für Device 1 anderswo gespeichert als die für Device 0. Das Ganze dient dazu, zwei "Musiken" quasi unabhängig voneinander auf die Stimmen zu verteilen - oder, besser gesagt, dazu, daß man bei Spielen ein Device für Musik und eins für Geräuscheffekte benutzen kann, ohne daß diese sich stören.

Der Befehl in ISM, der neue Stimmen zusätzlich zur vorhandenen Stimme initialisiert, d.h. ein "Tune" um neue Stimmen erweitert (und natürlich in AtavISM, sowie in jedem meiner Stücke benutzt wird (wo die erste Stimme die anderen startet), setzt das "Device" für die neuen Stimmen auf sein eigenes "Device", Standardmäßig also Device 0. Das ist nur in einem einzelnen Bit in der Stimme gespeichert. Weil ich das Device mit besagtem "Stunt" hole (also ein ROR s,8 und danach ein RCR d,1), wird damit das neue Register (d) auf 0 oder 128 gesetzt (es ist vorher 0, weil eine neue Stimme komplett auf Nullen initialisiert wird, mit Ausnahme des Stop-Bits und des Device-Bits). Diese 128 (also das oberste Bit des Ziel-Registers) ist das "Device"-Bit. Wenn aber, durch den Bug der 64bit-Version von DOSbox nach einem Byte-ROR 8 IMMER das Carry=1 ist, dann wird ein RCR 1 danach auch IMMER das oberste Bit des Ziels setzen... Also wird bei allen neu initialisierten Stimmen das "Device" auf 1 gesetzt (die originale Stimme hat Device 0).

Das bedeutet genau das, was wir gesehen haben:
Wenn man keine Instrumente setzt, werden die Standardwerte benutzt, die quasi zu Anfang mit direkten Befehlen gesetzt werden.
Wenn man aber in prISM/AtavISM Instrumente definiert, werden diese in den Bereich für Device 0 gelegt. weil nur in Device 0 entwickelt wird. (Man kann ja später Device von außerhalb setzen für die Start-Stimme - alle anderen erhalten dann das gleiche Device.)
So, also landet ein definiertes Instrument 01 an der Stelle für Device 0.
Aber die Stimmen B,C,D, die auf Device 1 laufen, rufen natürlich das Instrument 01 auf, aber im Instrumentenspeicher für Device 1 - und da steht quasi nix, bzw. nur Nullen. Und DESHALB hört man auf Stimmen B,C,D nichts.

Also, wie schon gesagt: Hier versagt nicht AtavISM oder ISM, sondern DOSbox-64bit.

Und ich programmiere/optimiere bestimmt nicht für fehlerhafte Emulatoren, sondern für die echte Maschine.
Manawyrm
Norton Commander
Beiträge: 101
Registriert: Sa 23. Jul 2011, 21:03

Re: Trackermodul-Engine (sehr einfach)

Beitrag von Manawyrm »

Hallo DOSferatu,

das ist natürlich äußerst putzig.
Sehr interessant, dass das bisher noch nicht so negativ in Erscheinung getreten ist.

Das ist auf jeden Fall ein Bug in DosBox, den man fixen müsste.
Ich habe eben mal in den Bugtracker geschaut und konnte auf Anhieb keinen offenen Report zum ROR-Opcode finden.

Es wäre super, wenn du einen Bugreport unter https://sourceforge.net/p/dosbox/bugs/ anlegen könntest, oder evtl. eine kompilierte Version von deinem kurzen Testsnippet hochladen würdest.
Dann könnte man das mal genauer analysieren und gleich fixen.
Die Tatsache, dass das Problem von der Host-CPU-Architektur abzuhängen scheint, lässt mich nichts gutes ahnen.

Viele Grüße,
Manawyrm
Zuletzt geändert von Manawyrm am Fr 4. Aug 2023, 18:53, insgesamt 1-mal geändert.
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von DOSferatu »

Manawyrm hat geschrieben:Hallo DOSferatu,

das ist natürlich äußerst putzig.
Sehr interessant, dass das bisher noch nicht so negativ in Erscheinung getreten ist.

Das ist auf jeden Fall ein Bug in DosBox, den man fixen müsste.
Ich habe eben mal in den Bugtracker geschaut und konnte auf Anhieb keinen offenen Report zum ROR-Opcode finden.
Ich habe mir jetzt nicht explizit die Mühe gemacht, zu testen, ob es auch für ROL zutrifft oder auch für Words und DWords.
Manawyrm hat geschrieben:Es wäre super, wenn du einen Bugreport unter https://sourceforge.net/p/dosbox/bugs/ anlegen könntest, oder evtl. eine kompilierte Version von deinem kurzen Testsnippet hochladen würdest.
Dann könnte man das mal genauer analysieren und gleich fixen.
Ich weiß nicht genau, wie kompliziert die das haben wollen und ob es Regeln gibt für so einen Bugreport.
Hab auch gerade mal den Link versucht. Keine Ahnung, wo ich den Bugreport eingeben muß. Ich fürchte, da muß man sich dann auch noch anmelden... Ich bin nicht gerne in jeder Ecke des Internets irgendwo angemeldet.
Manawyrm hat geschrieben:Die Tatsache, dass das Problem von der Host-CPU-Architektur abzuhängen scheint, lässt mich nichts gutes ahnen.
Es hängt ja nicht von der Host-CPU ab. Die 32bit-Version läuft auf beiden Systemen (also auf 32bit und auf 64bit), zumindest, was diese Befehle angeht, fehlerfrei.
Die 64bit-Version kann man natürlich nur auf dem 64bit-System testen.

Na jedenfalls - wie schon erwähnt - habe ich keine Lust, meine ganzen Tools gegen fehlerbehaftete Emulatoren zu testen. Wenn etwas auf realem System fehlerfrei läuft und der Emulator Fehler macht, ist der Emulator schuld, weil der ja das emulierte System fehlerfrei darstellen soll. Ich weiß natürlich, daß es ein Riesenaufwand ist, jeden möglichen Befehl unter allen Umständen gegenzutesten und daß so ein Emulator eines kompletten Systems (noch dazu mit so einer "gewachsenen" CPU wie es die x86-Generation ist) kein Pappenstiel ist. Aber ich verwende eben öfter mal etwas "kreative Tricks", um Performance, Speicher oder Register zu sparen - Optimierung eben (auch wenn ich nicht gerade John Carmack bin). Und daß ich aufhören muß, alle Möglichkeiten der x86-CPUs auszuschöpfen, nur weil vielleicht ein Emulator sich dran stößt, sehe ich nicht ein.

Ich meine: Nächstes Mal gibt's an anderer Stelle noch einen "Bug" und der liegt dann vielleicht erneut an einem nicht vollständig emulierten Opcode... Da werd' ich ja nie fertig.
Gerade mit so Bits und Flags wurstel ich ziemlich und gern herum. Das sind ja Alles so Dinge, die Hochsprachen nicht können.

Beispiel: Wenn man ein Monochrom-Display hat, in dem alle Pixel in aufeinanderfolgenden Bytes dargestellt werden, kann man ein Byte-Register A als Maske nehmen, mit $80 laden und ein Indexregister B als Speicheradresse. Und weiterzählen mit: ror A,1;adc B,0
(wobei man die 0 auch noch, wenn mans schnell haben will durch ein anderes Register ersetzen kann, das man vorher auf 0 setzt, falls man noch ein freies Register hat)

Somit hat man einen Zähler, der die Pixel zählt, bei der Adresse weiterzählt und braucht nur 2 Befehle. Zu B wird 7x einfach 0 addiert (eigentlich sinnlos) und beim 8. Mal dann 1 (und die Adresse erhöht), weil ja das "herausfallende" Bit von A (das zusätzlich wieder reinrotiert wird) beim ADC dazuaddiert wird. So vermeidet man, daß man hier springen muß (Sprungbefehle bremsen mehr als alles andere). Indem man nun statt ADC (statt INC) für die Erhöhung benutzt, kann man festlegen, wann erhöht wird und hat zusätzlich noch mehr gesetzte Flags danach (ADD/ADC setzen mehr Flags als INC), so daß man, zusätzlich zu diesem Trick einen weiteren benutzen kann, den ich öfter nutze: Die oberen 16 Bit von B als Rückwärtszähler zu benutzen, indem man sie zu Anfang auf die Anzahl Durchläufe setzt und den Befehl adc B,$FFFF0000 setzt. Dann einen dritten Befehl dazu: jc @startloop
der wieder vor den ror springt. Schon hat man eine Mini-Schleife aus 3 Befehlen, die eine ganze, größeneinstellbare Bitmaske abfragt. (Natürlich braucht's dann Befehle zur Auswertung/Ausführung dazu, je nachdem, was man damit machen will.)

Wenn nun so einfache Dinge schon nicht mehr gehen (und scheinbar geht's ja wohl nicht in der 64bit-DOSbox-Version), dann nervt mich das schon etwas. Ich habe auch schon Dinge programmiert, wo ich nach einer Operation das Flagregister in ein anderes (Index-fähiges) Register geholt habe und dann abhängig von einer Entscheidungstabelle gesprungen bin. Das ist, zugegeben, nichts Besonderes. Aber es kann an zeitkritischen Stellen Zyklen sparen, wenn man so kaskadierte Einzelabfragen vermeidet. Aber dann muß das eben auch so funktionieren wie es von den Befehlen vorgesehen ist.

Und wenn ein 386er/486er emuliert werden soll, müssen eben auch Befehle, die es vielleicht nicht (oder nicht mehr in der Form/Auslegung) im 64bit-Mode gibt, so emuliert werden, wie sie ein 386er/486er ausführen würde. Ich habe z.B. mal gelesen, daß es im 64bit-Mode nicht mehr die LAHF/SAHF-Befehle gibt. In Emulatoren werden sie natürlich emuliert.
Aber meiner Meinung nach (natürlich wie immer nur persönliche Ansicht), hat man mit diesem nicht abwärtskompatiblen 64bit-Mode der Welt keinen Gefallen getan. Und technisch wäre Abwärtskompatibilität möglich gewesen.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Trackermodul-Engine (sehr einfach)

Beitrag von zatzen »

Irgendwie ist die Benachrichtung in meinen emails nicht richtig angekommen, deswegen
komme ich erst jetzt zufällig in den Thread.

Ich habe Dein kleines Programm mal abgetippt und kann den Fehler in meiner Dosbox
Version bestätigen. Wenn man den Umweg über ein Register (AL) geht, funktioniert
die Sache aber, Dosbox versaubeutelt hier also scheinbar mit dem ROR Befehl nur etwas
wenn es mit Speicherzugriff zusammenhängt.

Dann habe ich noch ein Problem: Für mich sieht es so aus als gäbe es Dosbox überhaupt nur
in 32 Bit. Bei den Downloads finde ich nur den "32 Bit Windows installer". Was aber nicht
unbedingt heissen muss dass das Programm selbst auch 32 Bit sein muss.
Vielleicht hast Du für mich einen Link zu einer definitiven 32 Bit Version.
Komischerweise funkioniert AtavISM auf meinem Windows XP Laptop auch nicht wunschgemäß
in der Dosbox, wo man eigentlich erwarten müsste dass es kein 64 Bit Dosbox ist.
Es ist nämlich ein 32 Bit Windows.
Vielleicht ist es auch eine Frage der Dosbox-Version.

Gerne würde ich ein bisschen Musik in AtavISM machen.

Mittlerweile habe ich mich mal etwas weiter aus dem Fenster gelehnt was Assembler
innerhalb Freepascal angeht.
Auf Datenfelder zugreifen geht über z.B. LEA EBX, <arrayname> und dann MOV AX, DS:[EBX]
oder auch solche umfangreichen Konstrukte wie ADD EAX, DS:[OFFSET <arrayname> + EBX + EBX]
sind möglich und syntaktisch erlaubt.
Ich frage mich da nur was schneller ist - wenn ich einmal das EBX (oder ESI, EDI) Register fülle oder
wenn ich jedesmal OFFSET in der Addressierung verwende.
Noch eine Sache, ich weiss nicht ob es sich bei TP genauso verhält:
Ich hatte während einer For... Schleife ein paar Zeilen Assembler, in denen ich AX und BX
veränderte. Dadurch funktionierte die Schleife nicht mehr richtig.

Übrigens hab ich Dein Programm auch mal in Freepascal geschrieben, und dort
funktioniert es korrekt. Könnte also beweisen, dass zumindest 32 Bit Code auf einem
64 Bit Rechner korrekt und gewissermaßen abwärtskomatibel funktioniert.
mov ax, 13h
int 10h

while vorne_frei do vor;
Antworten