Nicht-Tracker prISM

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Mi 7. Dez 2016, 20:05

zatzen hat geschrieben:Sorry, das war etwas Off-Topic.

Naja, in Deinen Threads zu ZVID und ZVM habe ich mich ja auch schon desöfteren zu Off-Topic verleiten lassen,
ich bin da nicht so empfindlich, wenn ein Thema mal ETWAS neben die Spur gerät. Das passiert schon mal.

zatzen hat geschrieben:Da du selbst sagst, dass der Editor eigentlich nicht das wichtigste ist,
wäre vielleicht so nebenbei ein halbwegs intelligenter Converter Trackermodul -> ISM sinnvoll,
der die Vorzüge deines Programmiersprachen-ähnlichen Konzepts berücksichtigt und die
Daten entsprechend effizienter codiert?

Wie ich schon angedeutet hatte, bin ich von dieser Idee allenfalls semi-begeistert, da auf diese Art
die Stärken von ISM überhaupt nicht ausgenutzt werden und ca. 80% bis 90% der Features die ISM
bietet gar nicht nutzbar wären. Desweiteren setzen MOD-artige Tracker ausschließlich auf Nutzung
von Samples - in ISM hingegen soll dies ja durch elektronische Klangsynthese kompensiert werden
und Samplenutzung eher eine Nebenrolle spielen.
Außerdem hat das ursprüngliche MOD-Format inzwischen einen derartigen Wildwuchs erlebt, daß
ich mich vor eine etwas größere Aufgabe gestellt sehe, diesen ganzen Kram für einen Konverter
wieder intern auf einen "gemeinsamen Nenner" zu bringen. Vom anschließender Datenoptimierung,
um Schleifen/Sprünge/Wiederholungen geschickt zu finden und in ISM dann einzusetzen ist an
diesem Punkt noch nicht einmal die Rede.

zatzen hat geschrieben:Dazu müsste ich das Format natürlich ersteinmal gänzlich verstehen, und der prISM
Editor wäre letztlich doch immer noch sinnvoll, allein schon wegen der Kontrolle
oder Optimierung der konvertierten Daten.

Naja, das von mir mitgelieferte ZIP enthält ja netterweise sogar einen Text, der das komplette Format
der Befehle und Register beschreibt, sowie auch einen Text, der das von prISM genutzte Fileformat
erklärt.

zatzen hat geschrieben:ISM kann z.B. Portamento, das kann mein ZSM nicht, aber mein eigentlicher Tracker
in dem ich Musik programmiere kann es.

ISM kann aber einiges nicht "direkt", was in MOD Standard ist - ich denke da z.B. an Vibrato.
Da ISM aber so "programmiert" werden kann, also frei belegbare Register und Schleifen hat, kann
so etwas nachgebildet werden.
Den HLD ("Hold") Befehl, den es anfangs nicht gab, habe ich extra noch nachträglich eingebaut. Dieser
kann einen beendeten Ton wiederaufnehmen = weiterspielen. Somit besteht auch für ISM die Möglichkeit,
während der Laufzeit eines Tons einige seiner Parameter zu ändern.
Portamento wollte ich aber unbedingt "direkt" haben, da die "Nachbildung" zu eklig zu organisieren
gewesen wäre und man es selbst dann wohl nicht so "stufenlos" (bzw quasi-stufenlos) wie in ISM selbst
hinbekommen würde.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon zatzen » So 11. Dez 2016, 21:04

DOSferatu hat geschrieben:Ein Spiel? Cool!

Erwarte mal nicht zu viel. Ich werde zwar einiges an Sound und Grafik auftischen, habe
mir auf die Schnelle aber kein besonders komplexes Spielprinzip einfallen lassen.
Alles sehr improvisiert und ist eher als ein kleiner Gag zu verstehen, es ist
alles nur entstanden weil ich mich mal etwas mit ZSMPLAY und ZVIDVIEW austoben wollte.
Zu jedem Musikstück soll eine Highscore gespeichert werden können, wobei
die Tabelle in einer Datei ZSMPLAY.HSC gespeichert wird. Dabei fehlt mir
noch das Know-How über CRC32, was ich gerne verwenden würde um z.B.
anhand der Patterndaten die Musikstücke eindeutig identifizieren zu können.
Ich habe noch nicht sonderlich viel dazu recherchiert, bis jetzt scheint mir:
- zu prüfende Daten kann man als eine seeeehr große Zahl verstehen,
die man durch das 32 (oder 33?)- Bit Polynom dividiert.
- das ganze passiert in der Praxis schrittweise durch Shiften und XOR
- Der Divisionsrest ergibt die Prüfsumme (?)

DOSferatu hat geschrieben:Ja, wie gesagt: Es eilt nicht. Daß ich meine Programme hier präsentiere verpflichtet nicht zur Benutzung.

Es wäre aber mal ganz spannend, ISM komplexe Musik spielen zu hören.
Dass ich mich in prISM noch nicht so gut zurechtfinde und man dort nicht einfach so drauflos
improvisieren kann ist allerdings eine Hürde. Statt eines Converters von Tracker nach ISM
wäre ein Tool sinnvoll, welches meine Trackerstücke analysiert und mir das ganze auf eine
übersichtliche Weise darstellt, was ich mir dann z.B. ausdrucken könnte, um es dann in
prISM unter Benutzung aller Möglichkeiten einzuprogrammieren.
Wenn ich etwas im Tracker "komponiere", dann achte ich nämlich gar nicht auf die
Notennamen und Oktaven etc., ich höre nur hin wie es klingt, und kann im Nachhinein
gar nicht sagen welche Noten oder Harmonien ich da verwendet habe.
Eine Vorbereitungsmaßnahme für diesen Musikstück-Darsteller wäre, dass man im
Sample-Namen die Note vermerkt, welche das Sample tatsächlich auf C-3 spielt.
Meine Samples sind nämlich wild durcheinander getunet und nur so, dass sie
zusammen nicht schief klingen.

DOSferatu hat geschrieben:
zatzen hat geschrieben:Dabei habe ich noch eine kleine Frage.
Ich habe hier z.B. die obige Procedure zsm_playfx(sample: byte; freq: word; vol: byte);
Wenn ich diese nun auch mal innerhalb asm aufrufen will, wie übergebe ich dann die Parameter?

Code: Alles auswählen
push sample; push freq; push vol; call zsm_playfx;

Zur Beachtung: Wenn die Procedure als FAR deklariert ist (also entweder genereller Compilerschalter {$F+} oder FAR hinter der Procedure angegeben) muß der Call in Assembler natürlich call far ptr heißen.
Weiterhin zu beachten: Auf den Stack können nur Words (oder DWords) geschoben werden, keine Bytes. D.h. sample und vol müssen dann als Words gePUSHt werden, so geschieht es auch in Pascal selbst.
also dann eigentlich:
Code: Alles auswählen
push word ptr sample; push freq; push word ptr vol; call zsm_playfx;

In dem Fall werden sample und vol als Words gePUSHt, das Lowbyte ist der Inhalt der Variable, das Highbyte ist das Byte, das zufällig nach der Variable im Speicher steht. Sollte eigentlich nichts ausmachen, weil die Procedure selbst ja nur die Lowbytes verwendet.

Das funktioniert aber prima, ich habe einfach die Variablen gepusht, "word ptr" davor war nicht nötig.
Für eine asm-Routine ohne Stackrahmen setzt man wohl einfach entsprechende Register oder Variablen
vorher, wenn ich mich nicht irre. Eigentlich klar.
Zum Verständnis nur noch etwas: Wenn ich mir deine XPYDERZ.EXE mit ihren 166K ansehe, dann dünkt
es mir, dass man in Pascal mehr als 64K Code haben kann.
Aber dafür muss ja dann zwischendurch das Code-Segment geändert werden.
Geschieht das evtl. für jede TPU? Und wäre dann nicht jeder Funktionsaufruf aus einer TPU ein FAR Call?
DOSferatu hat geschrieben:IF-Kaskaden kann man unter anderem mit sogenannten Entscheidungstabellen verhindern.
Kann das bei Bedarf gern mal genauer erklären.

Ich habe das bei ZVIDVIEW auch schon umgesetzt, allerdings nicht mit Sprüngen sondern
mit CALLs. Ich weiss nicht genau was schneller ist, Sprünge oder eben CALLs.
Für einfache Sprünge anhand Entscheidungstabellen fehlt mir das Wissen, wie
man die Adressen von Labels innerhalb von asm Anweisungen ermittelt.
Bzw. wie man einen JMP formuliert, der nicht an ein Label sondern an eine
Adresse springt, die sich z.B. in einem Register befindet.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Nicht-Tracker prISM

Beitragvon zatzen » So 11. Dez 2016, 21:19

Du erwähntest noch das Programmieren der AdLib Karte.
So schwierig ist das gar nicht, für mich war es leicht weil man nichts mit Samples
und Software Mixing zu tun hat. Also reicht es, wenn man keine Portamento-Effekte
machen will, wie auch bei meinem ZSM, nur jede neue Zeile einen Befehl zu senden.
Der FM-Synthesizer verlangt ca. einen dutzend Parameter pro Stimme, aber da bekommt
man nach kurzer Übung schnell brauchbare Sounds hin.
Ich habe 1995 einen simplen Tracker in QuickBASIC geschrieben, die Musik habe
ich in Kotzman II benutzt.
Das einzig dumme an der AdLib ist, zumindest so wie sie in dem Buch beschrieben
wurde, dass man für bestimmte Register ein Delay einarbeiten muss, weil die
Daten sonst nicht richtig ankommen. Und ich hatte dann auch noch das Problem,
dass es beim ändern der Parameter für einen Kanal zu Soundmüll kam wenn
man das zwischendurch machte, bzw. habe ich damals auch die Delays so
eingeschätzt, dass sie sich nicht in den Ablauf eines Musikstücks integrieren
lassen. Deshalb habe ich für jeden Kanal nur einen festen Klang definiert.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Sa 14. Jan 2017, 10:38

zatzen hat geschrieben:Dabei fehlt mir noch das Know-How über CRC32, was ich gerne verwenden würde um z.B.
anhand der Patterndaten die Musikstücke eindeutig identifizieren zu können.
Ich habe noch nicht sonderlich viel dazu recherchiert, bis jetzt scheint mir:
- zu prüfende Daten kann man als eine seeeehr große Zahl verstehen,
die man durch das 32 (oder 33?)- Bit Polynom dividiert.
- das ganze passiert in der Praxis schrittweise durch Shiften und XOR
- Der Divisionsrest ergibt die Prüfsumme (?)

Ja, so in der Art. In der Praxis verwendet man da eine Tabelle mit 256 DWord-Werten.
Ich kann Dir mal ein Programmbeispiel zeigen.

zatzen hat geschrieben:
DOSferatu hat geschrieben:Ja, wie gesagt: Es eilt nicht. Daß ich meine Programme hier präsentiere verpflichtet nicht zur Benutzung.

Es wäre aber mal ganz spannend, ISM komplexe Musik spielen zu hören.

Ja, für mich auch.
zatzen hat geschrieben:Dass ich mich in prISM noch nicht so gut zurechtfinde und man dort nicht einfach so drauflos
improvisieren kann ist allerdings eine Hürde. Statt eines Converters von Tracker nach ISM
wäre ein Tool sinnvoll, welches meine Trackerstücke analysiert und mir das ganze auf eine
übersichtliche Weise darstellt, was ich mir dann z.B. ausdrucken könnte, um es dann in
prISM unter Benutzung aller Möglichkeiten einzuprogrammieren.


Naja, wie gesagt: ISM/prISM ist eigentlich nicht so sehr für Samples ausgelegt - während die normalen, "MOD"-artigen Tracker ja ausschließlich mit Samples arbeiten - teilweise mit leider viel zu großen Samples.
Ja, ich weiß: Samples sind nicht zu groß, solange 15 oder 31 Samples zusammen in die unteren 640 kByte passen... ABER: ISM ist zur Verwendung in Spielen gedacht. Spiele haben außer Musik auch noch Grafik, Steuerung und eine Menge "Drumherum", das dann ebenfalls noch in den Speicher passen muß und ich für meinen Teil bin NICHT bereit, 80%-90% des Speichers für große lange Samples bereitzustellen, so daß sich alles andere zusammen dann 50 bis 60 kByte teilen müßte.
Um "Real-Mode" (16-bit) Spiele zu machen, muß JEDER Bereich sparen: Meine Grafiken, mit ihrer 4-Bit-Option, meine Steuerung, die über ASM-artigen Bytecode in einer in 100% ASM programmierten VM erfolgt und eben auch Musiken/Soundeffekte, die mit Synthesizing und allemal kleinen Samples arbeiten sollten.

Das heißt natürlich nicht, daß man mit ISM nicht auch größere "standalone" "Musikprojekte machen könnte/sollte.

Und, wie bereits erwähnt: Mit den Einfg/Entf-Tasten sollte das "Improvisieren" dann einfacher gehen.

zatzen hat geschrieben:Wenn ich etwas im Tracker "komponiere", dann achte ich nämlich gar nicht auf die
Notennamen und Oktaven etc., ich höre nur hin wie es klingt, und kann im Nachhinein
gar nicht sagen welche Noten oder Harmonien ich da verwendet habe.


Naja - ich muß immer alles berechnen, anders traue ich dem Frieden nicht --- obwohl die normale "Tracker"-Ansicht natürlich auch etwas für sich hat - man sieht die Töne nebeneinander und wann sie einsetzen. Allerdings sind im "normalen MOD" Wiederholungen nur dann möglich, wenn sie gleichzeitig alle Stimmen betreffen und - mal abgesehen von den "ein Pattern in der Mitte starten/unterbrechen" Sub-Befehlen - nur auf ganze Patterns bezogen.
Was besser oder schlechter ist, läßt sich schwer beurteilen - wahrscheinlich die "MOD-Variante", weil so viele Leute sie seit Jahrzehnten erfolgreich benutzen ... - manche allerdings vielleicht auch, weil es die einzige Variante ist, die sie bisher kennen.

ISM ist eben ein komplett anderer Ansatz - und ja, mir ist bewußt, daß mit Trackern erfahrene Musiker hier eventuell Schwierigkeiten haben könnten. Aber siehe dazu meinen nächsten/neuen Beitrag.

zatzen hat geschrieben:Zum Verständnis nur noch etwas: Wenn ich mir deine XPYDERZ.EXE mit ihren 166K ansehe, dann dünkt
es mir, dass man in Pascal mehr als 64K Code haben kann.

So ist es.
zatzen hat geschrieben:Aber dafür muss ja dann zwischendurch das Code-Segment geändert werden.

Genau!
zatzen hat geschrieben:Geschieht das evtl. für jede TPU?

Jein. Man kann einstellen, ob es für jede TPU passiert oder diese auch "gruppieren", d.h. Pascal sucht dann aus, was noch alles in das gleiche Segment paßt.
zatzen hat geschrieben:Und wäre dann nicht jeder Funktionsaufruf aus einer TPU ein FAR Call?

Soweit ich weiß, schon (außer vielleicht, wenn alles in's gleiche Segment compiliert werden konnte).
Das "Problem" ist hier, daß eine Subroutine einer TPU ja "von überall im Programm" aufrufbar sein muß, auch von Stellen, die "zu weit entfernt" für einen near call sind. Man kann eine Subroutine aber leider nicht so programmieren, daß sie sowohl als near als auch als far aufgerufen werden kann - das liegt an den verschiedenen RET-Befehlen am Ende. Der "near RET" holt ja nur den Offset zurück (geht ins gleiche Segment), der "far RET" holt den Offset und das Segment. Selbst WENN man einen Mechanismus an's Ende einer Routine (procedure/function) manuell bastelt, der dann entscheiden würde, ob near oder far, muß die Routine ja auch WISSEN, als was sie aufgerufen wurde, um am Ende entsprechend zurückzuspringen.
D.h. man müßte der Routine das beim Aufruf mitteilen und am Ende wäre dann eine Entscheidung (evtl auch mit bedingten Sprüngen), die das ganze managt. --- Ob man DAMIT dann die Zeit rausholen würde, die einem durch den FAR CALL (statt NEAR CALL) "verlorengeht", wage ich ernsthaft zu bezweifeln.

Anmerkung: Mit dem Compilerschalter $G kann man die "Gruppierung" anschalten und die Units nennen, die zur gleichen "Gruppe" gehören sollen (funktioniert natürlich nur so lange, wie alle aus den entsprechenden Units eincompilierten procedures/functions in ein Segment passen). Diese Segmentgrößen werden mit $S festgelegt (default ist 16 kByte).
Dazu einmal mal die Hilfen zu $G und $S in Pascal aufrufen, jeweils die erste (also "Unitsegmente gruppieren" und "Segmentgröße").
Diese Schalter haben noch eine zweite Funktion, wenn man sie mit direkt folgendem + oder - benutzt (286er-Code generieren und Stack-Prüfung), das hat mit diesem Gruppieren nichts zu tun.

zatzen hat geschrieben:
DOSferatu hat geschrieben:IF-Kaskaden kann man unter anderem mit sogenannten Entscheidungstabellen verhindern.
Kann das bei Bedarf gern mal genauer erklären.

Ich habe das bei ZVIDVIEW auch schon umgesetzt, allerdings nicht mit Sprüngen sondern
mit CALLs. Ich weiss nicht genau was schneller ist, Sprünge oder eben CALLs.

CALLs sind natürlich etwas langsamer als Sprünge, weil bei CALLs der "Ausgangspunkt" vorher
auf den Stack gesichert wird, was bei Sprüngen entfällt. Sprünge "wissen" dafür nicht mehr,
wo sie hergekommen sind. Wenn die "Ziele" (also wohin gesprungen wird) immer nur von
einer einzigem Stelle aus angesprungen werden, ist ein kombinierter Sprung und Rücksprung
besser/schneller als ein CALL.

Anmerkung: Ich habe "Doppelrücksprünge" schon öfters mit PUSHs gelöst (z.B. benutze ich das öfter in GAMESYS).
Erklärung: Man springt irgendwo hin, innerhalb dieser Untersektion werden verschiedene CALLs
durchgeführt, die irgendetwas tun. Ist das letzte, was diese "Untersektion" macht, ebenfalls ein CALL und danach
folgt gleich ein Sprung oder Rücksprung zu X, habe ich das statt so:
Code: Alles auswählen
CALL Beispiel; JMP X;

so gelöst:
Code: Alles auswählen
PUSH CS:offset X; JMP Beispiel;

(der obige CALL ist in dem Fall ein NEAR CALL).
Was passiert? Ich lege die Rücksprungadresse auf den Stack. Und anstatt Beispiel zu "CALLen", springe ich nur dahin.
Am Ende von Beispiel (die ja eigentlich eine Subroutine ist, die einen CALL erwartet), ist ein RET. Und dieser RET holt sich dann X vom Stack und springt zurück. Somit habe ich mir einiges an Sprüngen/Aufrufen eingespart.

zatzen hat geschrieben:Für einfache Sprünge anhand Entscheidungstabellen fehlt mir das Wissen, wie
man die Adressen von Labels innerhalb von asm Anweisungen ermittelt.
Bzw. wie man einen JMP formuliert, der nicht an ein Label sondern an eine
Adresse springt, die sich z.B. in einem Register befindet.

Labeladresse in ein Register laden:
Code: Alles auswählen
mov BX,CS:offset @labelname;

Wenn es um eine "dynamische" Adresse geht, die erst zur Laufzeit des Programms (also nicht
während des Compilierens) bekannt ist, hilft natürlich LEA:
Code: Alles auswählen
lea BX,irgendwas;

Vor "irgendwas" setzt man dann das Segmentpräfix für das gewünschte Segment. lea ermittelt dann den Offset, den "irgendwas" zum Segment hat. Oder anders ausgedrückt: Wenn man
Code: Alles auswählen
lea BX,CS:@irgendwas;

benutzt, steht danach in CS:[BX] die Adresse, wo @irgendwas anfängt. Ich weiß gerade nicht, ob hier ein Fehler ausgelöst wird, falls sich @irgendwas nicht gar nicht im Segment (also in den 64kByte ab Segmentanfang) befindet oder nicht.

zatzen hat geschrieben:Du erwähntest noch das Programmieren der AdLib Karte.
So schwierig ist das gar nicht, für mich war es leicht weil man nichts mit Samples
und Software Mixing zu tun hat. Also reicht es, wenn man keine Portamento-Effekte
machen will, wie auch bei meinem ZSM, nur jede neue Zeile einen Befehl zu senden.
Der FM-Synthesizer verlangt ca. einen dutzend Parameter pro Stimme, aber da bekommt
man nach kurzer Übung schnell brauchbare Sounds hin.

Mir geht es da weniger um die Programmierung/Ansteuerung der AdLib Register.
Und diese Warteschleifen-Problematik habe ich auch schon gelöst. Aber ich als
Formel-Mensch komme mit diesen komischen Dingen, wo ich aus zwei kombinierten
Sinuswellen einen Klang generieren soll, nicht klar - da habe ich keinen Nerv dafür,
wie ich mir dann daraus sowas unnatürliches wie Dreieck-/Rechteck-/Sägezahnwellen
basteln könnte, das ist mir zu kraß. Dafür müßte ich mir wohl ein Tool bauen.

zatzen hat geschrieben:Ich habe 1995 einen simplen Tracker in QuickBASIC geschrieben, die Musik habe
ich in Kotzman II benutzt.
Das einzig dumme an der AdLib ist, zumindest so wie sie in dem Buch beschrieben
wurde, dass man für bestimmte Register ein Delay einarbeiten muss, weil die
Daten sonst nicht richtig ankommen. Und ich hatte dann auch noch das Problem,
dass es beim ändern der Parameter für einen Kanal zu Soundmüll kam wenn
man das zwischendurch machte, bzw. habe ich damals auch die Delays so
eingeschätzt, dass sie sich nicht in den Ablauf eines Musikstücks integrieren
lassen. Deshalb habe ich für jeden Kanal nur einen festen Klang definiert.

Ja, das ist ein bekanntes "Problem". Oft wurden solche Dinge früher[tm] auch entweder
GAR NICHT eingebaut (weil die Rechner so langsam waren, daß diese Wartezeit
allein schon durch den Abstand zweier Befehle alleine erreicht wurde) oder mit
Warteschleifen - die auf zu schnellen Rechnern dann Über- oder Unterläufe
produzierten (ja, wir ALLE kennen die besagten Spiele, die man dann im SlowMode
laufen lassen muß, weil sie sonst mit Fehlermeldung aussteigen und selbst im
Slow hat man dann wenn man Pech hat, noch diese schicken "hängenden Noten"...)

Aber gut - genug erstmal davon. In meinem nächsten Beitrag geht es wieder um ISM/prISM...
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Sa 14. Jan 2017, 15:30

Neu: prISM v0.10 jetzt offiziell auf meiner Website freigegeben!
http://www.imperial-games.de
Dort in Sektion MS-DOS, dann in Sektion Tools prISM suchen.
Direkter Link: http://www.imperial-games.de/html/dosa27.htm
(Der direkte Link kann sich ändern, da neue Tools hier immer alphebetisch einsortiert werden.)

Es gab noch einige kleinere Änderungen am Code von ISM, aber viele Änderungen an prISM !

Die auffälligste Änderung ist das Tutorial (englisch und deutsch), das quasi die ganze Zeit in der untersten Zeile eingeblendet sein kann und das schrittweise an die Arbeit mit prISM heranführt - zuerst mit den einfachsten Befehlen, die komplexeren werden später erklärt, alles auch teilweise anhand von Beispielen zum Selbermachen.

Damit habe ich mir viel Mühe gegeben und sehr viel Zeit aufgewendet.
Und vielleicht hilft es dem einen oder anderen, prISM / ISM am Ende doch noch etwas zu mögen.

Achja, noch etwas: Es besteht ebenfalls die Möglichkeit, die in prISM enthaltenen Texte auszudrucken - mit dem Programm ISMPRINT, das sich dafür nur im gleichen Verzeichnis wie prISM befinden muß.
Das Tutorial sieht ausgedruckt natürlich etwas "kompakt" aus, da es ja eigentlich für die zeilenweise Anzeige in einer einzigen Bildschirmzeile konzipiert ist. Vielleicht baue ich noch einen Modus ein, der das Ganze nach Sätzen trennt und entsprechende Absätze macht - mal sehen.

Über Feedback zu prISM und den neuen Features (hauptsächlich neu ist das Tutorial) würde ich mich selbstredend wie immer freuen. Aber ich weiß natürlich, daß man auch noch andere Verpflichtungen hat als krude privatgemachte Fremdsoftware zu testen/nutzen.

Trotzdem viel Spaß damit.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon zatzen » Sa 4. Feb 2017, 15:40

Mir ist aufgefallen, dass PRISM.EXE 643 KB groß ist.
Das passt ja eigentlich gar nicht in den Speicher.
Und mir wäre auch ein Rätsel wie ein Programm kompiliert so
groß werden würde, da müsste man ja Monate lang Code schreiben...
Vielleicht hast Du an die Datei etwas angehängt,
oder irgendwie etwas darin verlinkt. Oder für verschiedene
Konfigurationen den Code eher redundant mehrmals kompiliert,
so dass beim Start nur ein Teil der EXE geladen wird.
Ich kenne mich in dem Bereich nicht (mehr) so aus, aber es wäre
interessant zu erfahren, wie Du es schaffst, solche großen EXE Dateien zu machen.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » So 5. Feb 2017, 14:11

zatzen hat geschrieben:Mir ist aufgefallen, dass PRISM.EXE 643 KB groß ist.
Das passt ja eigentlich gar nicht in den Speicher.

Am Anfang von DOS-EXEn steht ja immer, wieviel Speicher sie belegen. Nur das wird von DOS geladen - egal, ob man zusätzlich etwas anhängt.

zatzen hat geschrieben:Und mir wäre auch ein Rätsel wie ein Programm kompiliert so groß werden würde, da müsste man ja Monate lang Code schreiben...

Eher Jahrzehnte... Immerhin enthält prISM auch einige meiner Units, die ich über die letzten 20 Jahre entwickelt habe.

zatzen hat geschrieben:Vielleicht hast Du an die Datei etwas angehängt,

Selbstverständlich.
Wenn man sich mal XPYDERZ anschaut, ist zusätzlich zu XPYDERZ.EXE ein ziemlich großes File namens XPYDERZ.FSY im selben Verzeichnis - dies enthält alle möglichen Daten für das Spiel. Die von mir entwickelten *.FSY Files kann man sich so vorstellen wie die *.WAD-Files bei DOOM[tm] und ähnlichen. Es ist quasi ein kleines "Filesystem im File", das verschiedene Files enthält, wahlweise auch gepackt und/oder verschlüsselt. Meine File-Unit kann diese lesen, als wären es normale Files - sie entpackt auch gleich beim Lesen (und packt beim Schreiben), so daß es für das Programm aussieht, als würde man das File "in Reinform" lesen/schreiben. Die neuere Version meiner File-Unit erlaubt nun auch, diese FSY an eine EXE anzuhängen und trotzdem von dort lesen zu können. So muß die EXE nicht immer ein zusätzliches FSY "mitschleppen", sondern es ist gleich an der EXE dran. Das ist die ganz Magie dahinter.

zatzen hat geschrieben:oder irgendwie etwas darin verlinkt.

Ja, prISM selbst lädt aus diesem Anhang verschiedene Sachen. So muß nicht immer alles im Speicher gehalten werden, was gerade nicht gebraucht wird.

zatzen hat geschrieben:Oder für verschiedene Konfigurationen den Code eher redundant mehrmals kompiliert, so dass beim Start nur ein Teil der EXE geladen wird.

Das eher nicht.

zatzen hat geschrieben:Ich kenne mich in dem Bereich nicht (mehr) so aus, aber es wäre interessant zu erfahren, wie Du es schaffst, solche großen EXE Dateien zu machen.

Während ich an der EXE arbeite (in der Entwicklungsumgebung) liegen diese ganzen Files einfach im Verzeichnis herum. Ich gestalte meine EXEn dann so, daß sie im Entwicklungsmodus die Files normal aus dem Verzeichnis lesen und wenn sie als "Compilat" auf die Reise gehen, dann aus dem angehängten Overlay.
Die ganzen Files da einzeln zu packen, so daß nach dem Entpacken dann ein ganzes Verzeichnis voller kryptischer Datenfiles herumliegt, das war nie so meins - daher bin ich froh, daß ich vor etwas über 15 Jahren mein FSY erfunden habe und vor 6 oder 7 Jahren dann noch die Option, es gleich an die EXE zu hängen.

Die PRISM.EXE selbst ist nur etwas über 188 kByte groß - der Anhang enthält z.B. die ganze Hilfe/Tutorial und die Skripte, um die Befehle/Parameter darzustellen, außerdem die Texte _ISM.TXT und _ISMFILE.TXT, die quasi das "Datenblatt" für ISM sind.

Wie ich ja bereits erwähnte, habe ich hier unzählige nützliche Programme und Units herumliegen, die ich nur noch einzusetzen brauche, falls nötig. Auf diese Art kann ich kleinere Tools oft in wenigen Stunden zurechtzaubern.

Und auch diese Tools selbst sind oft ganz hilfreich und brauchbar.
Außer mir selbst will das Zeug ja keiner haben oder benutzen - teilweise natürlich, weil viele (genau wie ich) eher auf selbstgemachtes Zeug vertrauen und daher nicht mit Fremdsoftware oder Fremdcode herumbauen wollen.

Und teilweise wohl auch, weil man sich dazu eventuell auf meine selbstentwickelten Formate oder Schnittstellen einlassen müßte - was wohl auch zuviel Mühe ist/wäre für jemanden, der da quasi "neu dazukommt".

@Alle:
Momentan arbeite ich übrigens gerade an meinem "Spiel-Rahmen" - also ein generalisiertes Stück Code, das (wahlweise) alle meine (für Spiele geeigneten) Units benutzt/Formate unterstützt. Hier werden auch gleich die Schnittstellen zwischen den einzelnen Teilen automatisch eingebunden und müssen nicht extra vom Programmierer jedesmal neu manuell "verbunden" werden.

Das wird dann sozusagen das "Grundgerüst" für meine künftig geplanten Spiele. Und ja, ich weiß, daß das Ganze schon sehr nach "Game-Maker" aussieht - aber es wird immer noch compiliert werden. Es wird also keine "generalisierte" EXE, die als Spiel dann den jeweiligen Datenklotz mit sich schleppt. Ich will bei alledem trotzdem flexibel bleiben und mir die Option, zusätzliche Dinge einzubauen, jederzeit offenhalten. Diese "zusätzlichen Dinge" sind es erst, die ein Spiel "besonders" machen. Game-Maker Spiele neigen irgendwann dazu, "alle gleich auszusehen". Will sagen: Sowohl ein Xpyderz, ein R-Type, ein Turrican, ein Zelda oder ein Maniac Mansion werden noch gleichermaßen möglich sein.

(Und ja, ich habe auch meine (alten) 3D-Routinen hier. Sollte ich die erstmal in 100% Assembler umsetzen, dann wären auch DOOM[tm]-artige Levels möglich... - aber das ist noch Zukunftsmusik.)

Inzwischen habe ich alles beisammen, was ich für ein gescheites Arcade-2D-Spiel im Stile der NES / SNES-Ära brauche (sowohl Tools als auch Units). An sich eine nette Sache, finde ich. Und für viele Leute, die viele Spielideen haben, gerne mal ein Spiel machen wollten, aber an Dingen wie Sprites, Scrolling, Steuerung, Kollisionsabfrage, Klanggeneration/-ausgabe usw. scheitern, könnte das wohl eigentlich ein Fest sein - sollte man vielleicht meinen...

In Wirklichkeit kann man natürlich heutzutage mit Spielen, die lediglich unter DOS/DOSbox oder bis max. WinXP laufen, kaum noch Ruhm/Ehre/Geld gewinnen und außerdem macht ein Spiel zu entwickeln, selbst wenn 95% der nötigen Programmierung jemand anderes getan hat, immer noch Mühe - denn Levels/Grafiken/Musiken/Steuerskripte etstellen sich auch nicht von alleine. Und so wie ich es sehe, hat kaum jemand ein wirkliches Interesse bzw. übrige Zeit, um an einem selbstgemachten DOS-Spiel mitzuwirken...

Schon damals[tm] vor über 15 Jahren gab es viele Leute, die "prinzipiell" schon gern an einem Spiel mitgemacht hätten, nur hatten sie gerade nie Zeit. Ihren Namen als "Ideengeber" unter dem fertigen Produkt hätten sie natürlich trotzdem gern gelesen. - Nur: Ideen habe ich selbst - ich habe so viele davon, daß ich 3 Leben bräuchte, um die alle umzusetzen. Quasi von allem was ich für ein Spiel brauche, sind das allerwenigste neue Spielideen. Grafiker / Musiker / Levelbauer wären viel eher gefragt - aber so etwas artet ja auch irgendwie in Arbeit aus...

Kurzum: Sobald der "Rahmen"/das "Gerüst" (Arbeitstitel: SLOT - und ja, mal wieder ein Wortspiel) fertig ist (kann sich nur noch um Wochen handeln), schmeiße ich mich auf die Bastelei meines ersten Spiels "der neuen Art".
Meine Prognose: Wenn es fertig ist, werden es wohl maximal 10 Leute (Schätzung nach oben aufgerundet) herunterladen, 5 Minuten anspielen, 3 davon werden etwas sagen wie "Ja, ganz nett." und das war's. Da kann ich echt froh sein, daß das ein Hobby ist und es mir mehr ums "Machen" geht als um alles andere...

Ja, manche halten Leute wie mich deshalb für verrückt oder schlagen vor, daß ich so Zeug lieber für ANDROID u.ä. machen soll (wegen des größeren Publikums und der Verdienstmöglichkeiten). Das sind wohl auch Leute, die nie verstehen werden, daß man Dinge auch einfach aus Spaß an der Sache machen kann, ohne eine zusätzliche Belohnung (Ruhm/Geld) zu brauchen und daß, wenn etwas nach mühsamer Arbeit funktioniert und es so geworden ist wie man dachte (oder vielleicht sogar besser), so etwas Belohnung genug sein kann. Natürlich freut es einen, gerade wenn man ein SPIEL macht, wenn möglichst viele Leute es auch spielen - denn das ist ja der eigentliche Zweck. -

Aber in der heutigen schnellebigen Zeit, wo kaum noch jemand Zeit hat oder sich ausreichend Zeit für etwas nimmt, wo alles gleich und sofort da sein und gehen muß, da muß man natürlich auch verstehen, daß jedes neue "Produkt" (und dann auch noch privatgemacht) nur eines von Millionen ist und natürlich auch kaum jemand die Zeit und das Interesse hat, alles zu testen, "was da ist" - und hinzu kommt ja auch noch der große Kreis von Personen, die sich für (Computer-)spiele gar nicht interessieren und der ebenfalls große Kreis von Personen, für die jedes Spiel, das älter ist als 2 Jahre bzw. dem technischen Stand von vor mehr als 2 Jahren entspricht (oder auch 1 Jahr), alter Müll ist, der ist nicht wert ist, gestartet zu werden oder Festplattenplatz zu belegen.

Andererseits ist man als Spielemacher (im alten Stil) so auch in einer "bequemen" Lage: Niemand wartet auf dein Spiel, niemand drängelt dich, wann es endlich fertig ist - im Gegenteil: Sollte man wirklich mal etwas vorzeigbares/spielbares haben, muß man quasi die Leute damit schon aktiv belästigen und es ihnen quasi aufdrängen, damit jemand überhaupt Notiz davon nimmt. Ich überlege da jedes Mal, wie ich die Information, daß etwas Neues von mir da ist, formulieren soll, damit es als Hinweis und nicht als aufdringliche Werbung empfunden wird. Ist auch gar nicht so einfach...

OK, das soll's erstmal von mir gewesen sein für heute.

Hinweis zum Schluß (um wenigstens mal kurz On-Topic zu sein) :
prISM gilt in der vorliegenden Version als "vorläufig fertig". Alles, was damit hergestellt wird, wird in dieser Form auch in SLOT (s.o.) und ähnlichem verwendbar sein. Eventuell noch nachgelieferte Konverter oder vielleicht später hinzugefügte alternative Editor-Ansichten werden am Format nichts mehr ändern - mit Ausnahme des WFI (Filter) Befehls, der noch endgültig definiert wird, sobald Softwarefilter in ISM impementiert sind.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Vorherige

Zurück zu Programmierung

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast