Trackermodul-Engine (sehr einfach)

Diskussion zum Thema Programmierung unter DOS (Intel x86)
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 »

Was Super Mario angeht nehme ich gerne die Bezeichnung "unmenschlich" zurück, ich habe da wohl etwas über das Ziel
hinausgeschossen. Aber etwas unangenehm waren mir die meisten NES Spiele trotzdem.
DOSferatu hat geschrieben:Ja, mir reicht es. So eine Ein-Raum-Wohnung braucht keine Orchesterlautstärke. Falls man natürlich wie Du in einer Villa wohnt...
Größere Lautsprecher, entsprechend vernünftig konstruiert, klingen besser, und damit meine ich nicht einmal dass sie zu
Bass fähig sind, das können kleine auch. Der Physik Rechnung tragend ausreichend große Lautsprecher geben aber klanglich
unverfälschter und detaillierter wieder. Und dass sie lauter können ist nur ein Nebeneffekt den ich in meiner Wohnung auch
nicht brauche.
Bei Hörnern ergibt sich die Größe nach festen physikalischen Gesetzen, und eigentlich kann man froh sein dass der
menschliche Hörbereich und die Dichte der Luft auf diesem Planeten zufällig noch so von der Natur gebeben sind, dass
es möglich ist, solche Konstruktionen überhaupt passabel in Wohnungen unterzubringen.
Also, ich kann einfach das Argument "größer = bloß lauter" nicht so stehen lassen.
DOSferatu hat geschrieben:Mit Preßlufthammer-Lautstärke würde ich wohl meine Nachbarn verärgern.
Natürlich. Ich auch. Es soll nur verdeutlichen, was Wirkungsgrad bedeutet. Zu Zeiten der ersten Röhrenverstärker
waren Hörner hoch angesehen, da man nur ein paar Watt zur Verfügung hatte. Heute bezahlt man bei Verstärkern
pro Watt deutlich weniger als einen Euro, und das hat dazu geführt dass die Empfindlichkeit der Lautsprecher
vernachlässigt wurde, während man dann einfach immer mehr Leistung reinpumpt. Lautsprecher sind dann physikalisch
betrachtet ungelogen zu 99% Heizkörper und nur 1% Schallwandler. Das ist vielleicht ein bisschen vergleichbar mit der
heutigen ineffizienten Art und Weise des Programmierens, da ja genug Rechenpower vorhanden ist, die man einfach
verschwendet.
DOSferatu hat geschrieben:[...] - kannst Du das Tetris auch mit einem *.MSX als Parameter starten, dann wird das während des Spiels über PC-Speaker abgespielt (allerdings in der Xenon-2-Methode).
Funktioniert super, klingt gut auch hier in Windows XP. Bei manchen anderen Spielen klappt das mit dem PC Speaker
nicht so (also ich rede nicht von Deinen). TITLE4GW erinnert mich ein bisschen an Maniac Mansion. Lucasfilm Games
hatten sich ja wie keine anderen Mühe gegeben, auch den PC-Speaker zu berücksichtigen, und gestalteten die Pseudo-
Polyphonie sehr komplex mit teilweise auch sehr kurzen Tönchen. Das habe ich in manchen Programmierexperimenten
damals nachzuahmen versucht.

Centipede: Wenn ich nicht irre hätte man ja da auch nur die veränderten Blöcke im Grafikspeicher aktualisieren müssen.
Aber ob das irgendeinen Vorteil gebracht hätte ist fraglich.
DOSferatu hat geschrieben:Hattet Ihr in der Schule auch "Informatik"-Unterricht?
Ich war auf einem Gymnasium. Da konnte ich in der 9 Informatik oder Französisch wählen.
Weil es hieß, ich wäre ja schon so gut im Programmieren, hat man mich überredet Französisch zu wählen.
Naja, ich habe aber durch Freunde mitbekommen was der Stoff der 9-10 in Informatik war: BASIC, richtig klassisch
mit Zeilennummern, und zwar letztlich auch Motorensteuerung und ähnliches was mit Elektronik zusammenhängt.
Da hätte ich also durchaus noch was lernen können.
Ich habe mich dann aber in der 11 letztlich doch entschieden, Informatik zu wählen, und da war es tatsächlich Pascal
was gelehrt wurde. An uralten Computern, höchstens 286er waren es. Zeitinfo: Das war 1996. Es war alles ziemlich
theoretisch, nix mit Interface, nur dieses Lehrprogramm mit Niki dem Roboter der durch Labyrinthe läuft und Flaschen-
deckel sammelt, oder auch sowas wie Türme von Hanoi, was ich aber mal wieder nicht raffte da ich irgendwie ne
Blockade für rekursive Prozeduren habe.
Trotzdem war ich sehr gut in dem Fach, und dieses eine Jahr lernen von Pascal in der Schule hat mir zum Durchbruch
verholfen, mich von Qbasic zu verabschieden und fortan fast nur noch Pascal zu verwenden.
Was heutzutage da abgeht weiss ich nicht. Es wäre zu vermuten dass man heute die Schüler eher auf Scriptsprachen
vorbereitet. Man könnte ja auch meinen dass es zu einer Meuterei kommt, wenn die Schüler drauf lauern, endlich ihre
Handys programmieren zu können, aber der Lehrer stur eine 48 Jahre alte Sprache vermitteln will...
DOSferatu hat geschrieben:...während die anderen Dinge, wie eben die Grafiken/Levels/Figuren/Sounds/Musiken ja noch komplett nicht vorhanden wären.
2/5tel könnte ich Dir abnehmen. Kommt drauf an welche Soundengine verwendet wird. Bei ZSM wäre ich schon
allein motiviert etwas dafür zu machen, weil mich die Sache an sich begeistert, auch ohne Spiel. Sounddesign verlangt
zwar auch Arbeit und Aufwand, aber nicht so viel Inspiration wie komplette Musikstücke, das sollte also relativ schnell
und flexibel gehen, und bei Musik würde es hinkommen wenn ich einfach genug Zeit habe, d.h. innerhalb einiger
Monate würde ich schon ein paar gute Musikstücke hinbekommen, die ich dann aber auch immer wieder mit Dir abklären
würde, ob sie Dir schon oder noch gefallen.
Bei allem anderen - Grafik, Levels, Figuren, ich denke das kannst Du besser, zumindest für ein Spiel das Deinen Ideen
entspringt.
Soundmäßig ist es vielleicht einfach eine Geschmacksfrage ob man stilistisch eher auf der Synthesizer-Schiene
unterwegs ist (ISM) oder auf der Sampler-Schiene (ZSM). Ich kann nur sagen dass mich das Samplen schon immer
begeistert hat, ich hatte als 8jähriger das CASIO SK-10, ein Spielzeug-Sampling-Keyboard mit ca. 1 Sekunde
ultra Lo-Fi Sampling-Kapazität, aber das hat mich schon ziemlich zu einigen Dingen inspiriert. Als ich dann mit 13 ohne
Hilfe des Internets endlich trotzdem einen Tracker an Land ziehen konnte war es sozusagen um mich geschehen.
Deshalb dieser tiefe Einfluss auf mich was Musik aus Samples angeht, und auch bei Spielen war ich immer begeistert
wenn neben der AdLib Musik auch ein bisschen Digisound dazu kam.
DOSferatu hat geschrieben:Das Gleiche gilt für Musik: Als ich z.B. nur mal Dein "DAUERSND.ISM" gehört habe, habe ich gleich gedacht: Nur ein kurzes Stück, aber besser als alles, was ich jemals auf IRGENDEINEM Computer gemacht habe. So Akkorde und passende Harmonien habe ich einfach nicht drauf, bei mir wird alles nur "Hauptsache paßt mathematisch zusammen". Und ich habe KEINE AHNUNG, wie lange es dauert, so ein Musikstück zu machen - angefangen von der Idee, der Umsetzung, des Finetuning und dem Kampf mit dem Entwicklungstool.
Der Kampf mit dem Interface ist ein Faktor, das ist aber eine Sache der Gewöhnung. Aber man gewöhnt sich nicht mal
eben in 5 Minuten um, sondern das kann (bei mir) Monate dauern bis man einen annähernden Workflow erreicht.
Das ist als würde man ein neues Musikinstrument lernen. Deshalb hatte ich Dich gebeten AtavISM ähnlich wie X-Tracker
bedienbar zu machen. Ist man an das Interface gewöhnt, gibt es nur noch den Faktor der Inspiration. "Dauersong" ist
ursprünglich in etwa 30-45 Minuten im Frankus Tracker II enstanden, für komplette längere Musikstücke brauche ich
mehrere Stunden bis mehrere Tage, wobei ich natürlich nicht den ganzen Tag dran sitze.
DOSferatu hat geschrieben:ich kann nichts, was nicht 'zigtausende Leute auch oder besser können, so realistisch muß man da einfach mal sein. Niemand hat gerade auf mich gewartet.
So ähnlich geht's mir auch als Musiker gegenüber den ganzen studierten und virtuosen Instrumentalisten.
Das einzige womit ich mich abheben kann sind eigene Ideen, wodurch Musik von mir gewissermaßen einzigartig wird,
wenngleich sie immer noch weit unterhalb des Anspruchs großer anerkannter Komponisten bleibt. Aber für diese
eigenen Ideen lohnt es sich, am Ball zu bleiben.
DOSferatu hat geschrieben:Aber das Ding hat bei den ganzen Laien mehr Bewunderung erzeugt als meine viel komplexeren Dinge
Kenne ich - wieder aus dem Musikbereich. Oft sind die Stücke die ich nach Schema F mache die beliebtesten,
einmal habe ich sogar eins mit Absicht richtig "schlecht" gemacht und das wird dann als besonders eingängig
rezipiert. Kommt noch dazu dass ich vor allem früher noch viel Musik mit vor allem blödsinnigen Text gemacht habe
und deshalb Fans hatte, aber die Musik die sich hinter dem Text versteckt hat, hat wohl kaum einer wirklich
wertgeschätzt oder wahrgenommen. Nur das wenigste von mir ist wirklich experimentell, ich würde mich auch eher
im musikalischen Normalverständnis ansiedeln.
Aber als richtiger klassischer Musiker würde ich mich auch nicht bezeichnen, allein schon weil ich weniger konform
damit gehe, dass Noten, Klaviatur oder Gitarre als Symbol für Musik herhalten - nein: Musik, das sind harmonische
Schwingungen, und die stellt man besser mit dem Oszilloskop oder einer Spektralanalyse dar. Will einfach heissen:
Ich würde es als Behinderung empfinden, wenn ich Musik ausschliesslich mit Instrumenten machen müsste und
ständig alles in Noten aufzuschreiben hätte anstatt einfach nur hinzuhören.
Andersrum ist man am Computer natürlich auch behindert: Es fehlt der natürliche Groove, alles ist quantisiert,
und mit reinem Programmieren ist eben auch nicht wirklich dieses Erlebnis der Echtzeit-Improvisation möglich,
wie man sie z.B. beim Jazz haben kann. Aber mir fehlt das alles nicht, ich mache Musik so, wie ein Maler ein
Bild malt.
DOSferatu hat geschrieben:"(Sehr) gut klingen" ist sehr subjektiv. Geschmäcker sind grundverschieden. Also kann man das wohl kaum als objektives Bewertungskriterium heranziehen.
Es geht hier ja um die Konservierung von Klängen, und wenn man mal nicht vom einfachsten Fall ausgeht und einfach
nen SID aufnimmt: Reale Klänge muss man mit Mikrofonen aufnehmen, abmischen usw. Und dabei ist es eine Kunst,
einfach zu vermeiden, dass es "irgendwie komisch" klingt. Man muss sich also bei der Aufnahme und Übertragung auf
ein Zielmedium Mühe geben, damit das Resultat gut klingt bzw. einfach nur neutral klingt, das passiert nicht wie
selbstverständlich von selbst. Und dafür werden Toningenieure professionell ausgebildet, soetwas kann nicht jeder.

Und klar, mancher mag vielleicht lieber ein Synfonieorchester über sein Küchenradio hören
als über eine sehr gute Anlage. Aber die meisten wohl eher nicht.

Jetzt kann man sagen, ich mache ja auch Musik wo alles aus dem Computer kommt. Aber trotzdem muss
ich da die Dynamik, den Klang und die Lautstärke der einzelnen Sounds mit viel Liebe zum Detail gestalten,
das nennt sich dann Abmischen, was ein technisch-kreativer Vorgang ist.

Hmm, Dein Rechner ist vielleicht für Windows 7 dann "zu langsam", keine Ahnung, meiner ist von 2012, ist
glaube ich ein i5, war erst XP drauf, und Win7 hat er noch gepackt. NTFS brauche ich persönlich, da ich einige Dateien
> 4 GB habe.
Mir gefällt das alles auch nicht, aber ich habe einfach zu viel Windows-Software die ich gerne weiterbenutzen
würde. Auch wieder Gewohnheit, seit 1995 benutze ich Windows hin und wieder, seit etwa 2000 ziemlich regelmäßig,
jetzt auf Mac oder Linux umzusteigen - ich weiss nicht...
Mein Laptop ist mit XP und vor allem Internetgeschichten überfordert, da brauche ich Geduld. Bei meinem großen
Rechner merke ich nur manchmal dass der Lüfter mehr arbeitet, aber langsam ist da eigentlich nichts.
"Kann" Windows XP 64 Bit? Immer mehr Software-Hersteller unterstützen leider keine 32 Bit mehr.
Auf Windows 7 bin ich nur umgestiegen weil eine Software die für mich sehr wichtig war das verlangte.
Aber eigentlich bereue ich das nicht.

"ohne wirklich mehr zu können" - ja, genau wieder die Parallele zu Lautsprechern. Glühbirnen werden verboten,
aber bald können wir mit Lautsprechern heizen... Naja das ist vielleicht aktuell noch übertrieben, aber es
gibt tatsächlich schon Lautsprecher für die 500 Watt empfohlen sind, und die damit nur gehobene Zimmerlautstärke
machen, während man in den 80ern so viel gerade mal in Discotheken verbraten hat.
Aber ich glaube so sehr interessiert Dich das Thema Schallwandler und Musikproduktion auch nicht,
ich werde mich in Zukunft beherrschen.
Zuletzt geändert von zatzen am Mo 20. Mai 2019, 16:59, insgesamt 1-mal geändert.
mov ax, 13h
int 10h

while vorne_frei do vor;
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 »

ZSMPLAY Release v0.05ß


Neuerungen:


- Pattern Mode: Anzeige der Musikinformationen in Pattern-Form.
Am rechten Rand wird der Speicherverbrauch in Bits für jede
einzelne Zeile angezeigt und daneben in Bytes aufsummiert.

- Scope färbt sich nun entsprechend dominanter Frequenzen von rot über gelb und grün bis cyan

- Waveform Mode: Pro Frame wird ein Lautstärkeschnappschuss gemacht und das ganze vertikal
als "Wurst" oder "Tannenbaum" angezeigt, je nach Musikmaterial.

- Fireworks Mode: Pro Sample-Anschlag leuchtet an zufälliger Bildschirmposition ein
Symbol für jedes Sample auf und fadet wieder weg.
Nicht ganz ernst zu nehmen, verschwindet wohl in der nächsten Version zugunsten anderer Visualisierungen.

- Hauptlaustärke ist jetzt standardmäßig auf -8.5 dB eingestellt, das ist ein besserer Kompromiss
und wurde ermöglicht durch eine feinere Lautstärkeabstufung des Mischpuffers (Viertelschritte).

- Alle Modi sind ohne Umweg über den Main Mode sofort abrufbar





ZSMSTART v.03ß Neuerungen:


- Der gewünschte ZSMPLAY Modus kann eingestellt werden

- Strg+Enter spielt alle Titel der Liste auch ohne Playlist endlos
ab, mit Bild hoch / runter kann zum vorherigen/nächsten Titel
gesprungen werden, mit Esc wird das Abspielen beendet, der Cursor
steht dann beim zuletzt gespielten Song.




Downloads:

Diesmal Module und Programme gesondert. Source diesmal nicht dabei, gerne auf Anfrage.

ZSMPLAY + ZSMSTART: http://www.zatzen.net/zsmp005b/zsmp005b.zip

ZSM Module C-F: http://www.zatzen.net/zsmp005b/zsm_c-f.zip (6,78 MB, 284 Dateien, ungepackt: 8,36 MB)

wer die bisherigen Module nicht hat, die bei den Vorgängerversionen dabei waren:
ZSM Module 0-B: http://www.zatzen.net/zsmp005b/zsm_0-b.zip (9,54 MB, 310 Dateien, ungepackt: 11,6 MB)


Credits: Die allermeisten Module entstammen dem http://www.modarchive.org
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:Was Super Mario angeht nehme ich gerne die Bezeichnung "unmenschlich" zurück, ich habe da wohl etwas über das Ziel hinausgeschossen. Aber etwas unangenehm waren mir die meisten NES Spiele trotzdem.
Naja, jeder hat andere Präferenzen und jeder empfindet auch Spiele unterschiedlich. Nicht umsonst gibt es so viele verschiedene Spiel-Genres und alle davon haben ihr Publikum.

Ich z.B. habe gegen ein "gemütliches" Point&Click-Adventure nichts einzuwenden - solange man selbst nichts tut, tut das Spiel (meist) auch nichts. Dafür gibt es interessante Geschichten und Charaktere, schöne Grafiken/Musiken usw. - Vor allem natürlich die Werke von Lucas Arts - formerly known as Lucasfilm Games - haben es mir da angetan; aber auch die in den letzten Jahren unter Telltale Games und natürlich Daedalic Entertainment erschienenen Werke laden dazu ein, das Ganze auch mehrmals zu spielen.

Andererseits bin ich aber auch etwas mehr Action gegenüber nicht abgeneigt: So ein klassischer Weltraumshooter kann immer mein Interesse wecken, genau wie Plattformer, auch wenn sie etwas actionreicher sind.

Das einzige, was mich an manchen Spielen stört, ist, daß eine zu komplizierte oder undurchdachte Steuerung dem Spiel einen zusätzlichen Schwierigkeitsgrad einbringt, der nicht sein müßte - da fühlt man sich dann vom Spiel "betrogen", weil man genau wußte, was die Spielfigur hätte machen sollen, nur einem das Steuergerät (Tastatur / Stick / Pad) nicht die Möglichkeit gab, das umzusetzen. Leute, die die Spiellänge ihrer Spiele nur auf diese Art zu verlängern verstehen, indem sie eine unhandliche Figurensteuerung einbauen, sind nicht so mein Favorit. Da wirkt es dann immer so, als hätte man nicht genug Inhalt vorzuweisen gehabt und muß die Spielzeit durch komplizierte / unhandliche Steuerung erhöhen. (Mindest-Durchspielzeiten sind ja in so Bewertungen von Spieleforen/-zeitschriften immer eins der Kriterien.)

Aber das NES mit seinen 4 Richtungen und 2 Steuertasten kann da kaum zu komplexe Sachen verlangen. Allerdings muß ich sagen, daß ich generell mit alten Pads nie klargekommen bin und erst seit es die Playstation-Pads gibt, empfinde ich Pads als handfreundlich. Am Pad des Super-NES habe ich mir damals regelmäßig Blasen an den Händen geholt; und das sollte - auch bei längeren Spielsessions - nicht passieren.
zatzen hat geschrieben:Größere Lautsprecher, entsprechend vernünftig konstruiert, klingen besser, und damit meine ich nicht einmal dass sie zu Bass fähig sind, das können kleine auch. Der Physik Rechnung tragend ausreichend große Lautsprecher geben aber klanglich unverfälschter und detaillierter wieder.
Mir ist selbstverständlich klar, daß eine größere Membran schon physikalisch mehr Klangtiefe haben kann. Andererseits, wenn man bedenkt, wie klein ein Trommelfell ist, das diese Luftpartikelschwingungen aufnimmt, müßte man eigentlich nur Lautsprecher mit der gleichen Flexibilität wie ein Trommelfell bauen, den durch die Luftreibung verlorengehenden Anteil abziehen und hätte dann die maximal gebrauchte Lautsprechergröße.

Seltsam ist auch, daß man es nicht schafft, Membrane zu bauen, die gleichzeitig sehr tiefe und sehr hohe Töne sauber erzeugen können - die Ohren haben ja auch nicht verschiedene Trommelfelle für unterschiedliche Frequenzbereiche.
zatzen hat geschrieben:Es soll nur verdeutlichen, was Wirkungsgrad bedeutet. Zu Zeiten der ersten Röhrenverstärker waren Hörner hoch angesehen, da man nur ein paar Watt zur Verfügung hatte. Heute bezahlt man bei Verstärkern pro Watt deutlich weniger als einen Euro, und das hat dazu geführt dass die Empfindlichkeit der Lautsprecher
vernachlässigt wurde, während man dann einfach immer mehr Leistung reinpumpt. Lautsprecher sind dann physikalisch betrachtet ungelogen zu 99% Heizkörper und nur 1% Schallwandler.
Naja, ein Grund dafür mag sein, daß viele Leute zwar gern auch etwas Musik hören wollen, aber nicht jeder in seinem Wohnzimmer gern klobige mannshohe Lautsprecherboxen stehen haben möchte.

Aus dem gleichen Grund gibt es den Unterschied zwischen Codern/Gamern und den sog. "Normalos": Den Normalos reicht ein kleines flaches Notebook als Computer aus. Ein Coder oder Gamer würde mit diesen beschissenen kleinen Keyboards (wo manche Tasten fehlen, manche komisch angeordnet sind und ALLE zu klein sind und keinen gescheiten Hub haben) niemals vernünftig coden/zocken können - für die ist das nur eine Notlösung für "unterwegs". So'n "Normalo" empfindet aber Computertower und große Monitore in seinem Wohnbereich als zu häßlich - er will die Technik "wegtun" können. Für Computerfreaks ist das kein Thema: Deren Behausung ist eher ein Computertempel mit Wohngelegenheit - da hat man nicht nur EINEN Computer und da darf die ganze Technik auch gesehen werden.

Und ein Soundenthusiast hätte kein Problem damit, sich eine Wand aus Lautsprechern hinzubauen für einen gescheiten Raumklang - die restliche Möblierung hätte sich dem unterzuordnen.

Und deshalb gibt es für jeden Bedarf von allem auch eine miniaturisierte Variante. Wo eine Nachfrage besteht, wird irgendwer ein Angebot machen.

Meine Lautsprecher müssen auf meinen Computerschreibtisch hinter/neben die Computer passen. Ich sitze da etwa 1 Meter vor den Lautsprechern und habe eine 20 m² Bude. Da brauche ich auch keine mannshohen Boxen.

Ich weiß auch nicht genau, was "Hörner" in dem Zusammenhang sind. Sind die gedreht wie 'ne Abalone? Oder lang wie 'ne Tröte?

Habe da auch gehört, daß die Leute viel mehr von den feinen Dingen wahrnehmen, die man sonst nicht hören würde. Wie ist das dann bei Formaten wie MP3? Ich dachte, die Kompression basiert dabei darauf, die nicht bewußt hörbaren Dinge rauszurechnen, um die Files zu verkleinern. Machen dafür so superempfindliche Membranen dann überhaupt noch Sinn?

Mein Bildschirm z.B. ist ja auch ein 14-Zoll CRT. Was sollte ich auch mit einem 21-Zoll Monitor, wenn ich den fast vor der Nase kleben habe? Das Ganze ist bei mir also nicht nur auf Lautsprecher bezogen.
zatzen hat geschrieben:Centipede: Wenn ich nicht irre hätte man ja da auch nur die veränderten Blöcke im Grafikspeicher aktualisieren müssen. Aber ob das irgendeinen Vorteil gebracht hätte ist fraglich.
Ja, da hätte man nur ein zweites 1000-Bytes Feld gebraucht und nur wenn sich ein Byte in beiden Feldern unterscheidet, das neue Pattern setzen müssen (und das im zweiten Feld dann angleichen).

Es hat aber als Machbarkeitsstudie angefangen um zu sehen, wie performant ich das mit einem vollen Refresh hinbekommen würde - und dann hab ich ein Spiel draus gemacht. (Xpyderz hatte damals auch als Experiment angefangen.)
zatzen hat geschrieben:Ich war auf einem Gymnasium. Da konnte ich in der 9 Informatik oder Französisch wählen. Weil es hieß, ich wäre ja schon so gut im Programmieren, hat man mich überredet Französisch zu wählen.
Egal, wie gut oder schlecht ich schon hätte programmieren können - es hätte für mich KEINEN GRUND gegeben, Französisch zu lernen. Für Nicht-Franzosen ist die Sprache nur dazu da, den Notendurchschnitt zu senken. Es gibt nichts, wofür ich Französisch gebrauchen könnte und das hätte ich mir nie freiwillig angetan.
zatzen hat geschrieben:Naja, ich habe aber durch Freunde mitbekommen was der Stoff der 9-10 in Informatik war: BASIC, richtig klassisch mit Zeilennummern, und zwar letztlich auch Motorensteuerung und ähnliches was mit Elektronik zusammenhängt.
Da hätte ich also durchaus noch was lernen können.
Und es hätte mehr Spaß gemacht und wäre interessanter gewesen.
Die Wahl "Informatik" oder "Französisch" finde ich sowieso etwas abwegig.
zatzen hat geschrieben:Ich habe mich dann aber in der 11 letztlich doch entschieden, Informatik zu wählen, und da war es tatsächlich Pascal was gelehrt wurde. An uralten Computern, höchstens 286er waren es. Zeitinfo: Das war 1996.
Bei uns war es 1993-1995. Und es waren auch 286er - mit Monochrom-Monitoren.
Mein erster eigener PC war auch ein 286er. Und, Zeitinfo: Das war auch 1996.
zatzen hat geschrieben:Es war alles ziemlich theoretisch, nix mit Interface, nur dieses Lehrprogramm mit Niki dem Roboter der durch Labyrinthe läuft und Flaschen-
deckel sammelt,
Achduschande... (Glaube sogar, daß der Roboter nach dem Entwickler von Pascal (Niklaus Wirth) benannt wurde.)
Aber schade - mit Pascal geht so viel mehr als nur so Kram.
zatzen hat geschrieben:oder auch sowas wie Türme von Hanoi, was ich aber mal wieder nicht raffte da ich irgendwie ne Blockade für rekursive Prozeduren habe.
Naja, mit rekursiven Prozeduren hab ich keine Probleme. Inzwischen benutze ich die aber schon gar nicht mehr in der Form, sondern konstruiere mir da eigene Pseudo-Stacks. Damit habe ich z.B. auch für mein Malprogramm die Füllfunktion programmiert, die auch riesige und komplexe Formen füllen kann. Außerdem basiert meine Labyrinth-generier-Routine (die u.a. in Xpyderz verwendet wird, aber ursprünglich aus meinem Textmode-Labyrinth-Spiel stammt) auch auf so rekursiver Routine mit Pseudo-Stack.
zatzen hat geschrieben:Trotzdem war ich sehr gut in dem Fach, und dieses eine Jahr lernen von Pascal in der Schule hat mir zum Durchbruch verholfen, mich von Qbasic zu verabschieden und fortan fast nur noch Pascal zu verwenden.
Naja, sehr gut war ich da auch - was auch daran lag, daß ich (und zwei andere Computerfreaks) mehr Ahnung hatten als der Lehrer (das waren im Schnellschuß umgeschulte Mathelehrer, weil's da hieß, jetzt müsse Informatik gelehrt werden - und die hatten keine Lehrer dafür).

Und ja, die Programmierung auf 286er PCs brachte mich auch irgendwie zum PC. Zuerst hatte ich meinen 286er zu Hause nur, um meine auf C64 selbstgebaute serielle Übertragung zu testen (38400 Baud), mit so Terminalprogramm. Aber irgendwann fängt man dann an, auf dem neben dem C64 herumstehenden PC, auch Pascal zu coden. Aus der Zeit stammen viele unfertige Sachen, die ich nie online gestellt habe. Mein erstes Spiel auf PC war damals mein Unterrichtsprojekt: Ein Raumschiffshooter in Textmode. Mein erstes veröffentliches Spiel auf dem zu-Hause-PC war das "4 Gewinnt". Damals war das noch mit dem PAUSE-Befehl getimed... Glaube, ich habe das später durch einen eigenen Pause-Befehl ersetzt.
zatzen hat geschrieben:Was heutzutage da abgeht weiss ich nicht. Es wäre zu vermuten dass man heute die Schüler eher auf Scriptsprachen vorbereitet. Man könnte ja auch meinen dass es zu einer Meuterei kommt, wenn die Schüler drauf lauern, endlich ihre Handys programmieren zu können, aber der Lehrer stur eine 48 Jahre alte Sprache vermitteln will...
Naja, so wie junge Leute heutzutage drauf sind - glaubst Du da im Ernst, daß einer von denen die Geduld hätte, ein ganzes Spiel zu coden? Sobald etwas nicht gleich und sofort funktioniert, schmeißen sie es weg - das ist so die Mentalität. Nichts darf irgendwie Mühe machen - und, etwas dabei LERNEN? Bloß nicht!
zatzen hat geschrieben:
DOSferatu hat geschrieben:...während die anderen Dinge, wie eben die Grafiken/Levels/Figuren/Sounds/Musiken ja noch komplett nicht vorhanden wären.
2/5tel könnte ich Dir abnehmen. Kommt drauf an welche Soundengine verwendet wird. Bei ZSM wäre ich schon allein motiviert etwas dafür zu machen, weil mich die Sache an sich begeistert, auch ohne Spiel.
Naja, der komplette Text bezog sich nicht auf etwas Konkretes, sondern auf so eine allgemeine Einschätzung. Wenn ich heute ein Spiel machen würde (egal ob mit anderen zusammen oder allein), wäre die Hard-Programmierung der geringste Anteil daran - was einfach nur daran liegt, daß ich das alles schon in den letzten 20 Jahren gemacht habe - wogegen die ganzen Sachen wie Grafiken, Sounds, Levels, Steuerskripte immer noch zu machen wären. Das bedeutet: Würde ich eine Crew anheuern, die die verschiedenen Bereiche abdeckt, hätte ein Hard-Programmierer (also einer, der nicht skriptet, sondern direkt ausführbaren Code schreibt) am wenigsten zu tun, weil das zum allergrößten Teil schon vorliegt.

Allerdings ist das ja auch eigentlich normal: Einmal geschriebener Code, der bestimmte Subfunktionen abdeckt (Sprite zeichnen, Sound abspielen), kann immer wieder benutzt werden. Grafiken und Sounds dagegen werden in der Regel für jedes unterschiedliche Spiel komplett neu gemacht.
zatzen hat geschrieben:Sounddesign verlangt zwar auch Arbeit und Aufwand, aber nicht so viel Inspiration wie komplette Musikstücke, das sollte also relativ schnell und flexibel gehen, und bei Musik würde es hinkommen wenn ich einfach genug Zeit habe, d.h. innerhalb einiger Monate würde ich schon ein paar gute Musikstücke hinbekommen, die ich dann aber auch immer wieder mit Dir abklären würde, ob sie Dir schon oder noch gefallen.
Naja, wie gesagt, es handelte sich eher um eine generelle Einschätzung. Ich bezog mich damit u.a. auf Dein "Desaster" mit Deinen (Ex-) Freunden, was so Einschätzung der Arbeitsanteile der einzelnen Crewmitglieder wäre. Ich selbst würde so einen Einschätzung gar nicht abgeben - weil man es erstens vorher sowieso nicht richtig einschätzen kann, wie viel Arbeit ein einzelner Bereich (oder auch das gesamte Projekt) machen wird (und erfahrungsgemäß ist es meist am Ende sowieso wesentlich mehr als gedacht oder je geplant) und zweitens man zur Einschätzung der Arbeit der ANDEREN (die das machen, was man nicht selbst macht) nicht genug Einblick in das Thema hat.

Ich z.B. hätte keine Idee, wie lange so ein Grafiker brauchen würde, um Sprites zu erstellen für ein Spiel mit 1 Spielfigur, 10 Feindfiguren, 5 verschiedenen Spielfigurwaffenprojektilen, 5 verschiedenen Feindwaffenprojektilen und den zugehören Bonusgegenständen - zuzüglich der Animationsphasen für die Figuren. Für mich einfach unmöglich, abzuschätzen. Ich selbst bin eher ein primitiver Grafiker und arbeite da auch sehr langsam, mit viel Trial-and-Error, bis es "gut aussieht". Ein guter Grafiker kann da schon rein intuitiv viel schneller arbeiten - aber seine Arbeit ist auch gleichzeitig wesentlich mehr wert.

Genauso ist es mit Sounds. Für einen Raumschiffshooter mit 8 Levels bräuchte man z.B. 8 Musiken, die jeweils 1 Minute sind und in Schleife spielbar. Zusätzlich eine Titelmusik, die auch ruhig so 2-3 Minuten sein kann und eine Endmusik, die auch länger sein kann, für so "Abspann" und eine kurze dramatische "Endboß-Kampf" Musik mit kurzer Schleife für die Levelenden. Außerdem braucht es so zwischen 10 und 20 Soundeffekte. Ebenfalls unmöglich für mich, einzuschätzen, welche Zeit man dafür ansetzen sollte.

Und, sowohl bei Grafik als auch bei Musik/Sounds kommt ja noch dazu, daß beide Leute nie total "frei" in ihren Möglichkeiten wären:

Der Grafiker hätte sich auf bestimmte Farbanzahlen zu beschränken - je nach Objekt können das auch teilweise sehr wenige sein. Will man Figuren skalierbar/drehbar machen, dürfte der Grafiker (um den Farbmangel auszugleichen) nicht einmal mit Dithering arbeiten, weil das beim Skalieren/Drehen scheiße aussieht. Da finde man mal einen Grafiker, der bei all der Mühe, die er sich macht, gut aussehende Figuren machen will, die nur max. 15 Farben haben dürfen...

Der Musiker muß sich ebenfalls beschränken - teilweise noch stärker als der Grafiker! Wenn der Musiker Sound machen will für 22 kHz und Samples nutzen will, nützen ihm ja keine LowRes-Samples, denn was will man mit 5-kHz-Samples, wenn man 22 kHz Qualität haben will? Nur, ein einzelnes Mono-8-Bit-22-kHz Sample braucht für 1 Sekunde nunmal auch 22 kByte RAM. Allein 3 solcher Samples füllen schon ein komplettes Segment!

Wenn dann so ein Idiot wie ich der Projektleiter ist, der DOS-Spiele machen will, sind nur 9 bis 9,5 solcher Segmente insgesamt vorhanden! Ein Segment allein ist schon komplett belegt durch alle Grafikkacheln. Ein bis drei Segmente belegen Sprite-Animationsphasen (Oh ja, man glaubt nicht, wieviel Platz Grafik braucht - bis man's mal gesehen hat...) Gehen wir mal von zwei aus - weniger werden's nicht sein, wenn das Spiel kein völliger Müll sein soll. Sind also insgesamt 3.

Das Level besteht aus Kacheln. Die Grafik für diese Kacheln wurde ja oben genannt. Aber das Level selbst (d.h. der Speicher, der angibt, wo die Kacheln stehen) braucht ja auch Platz. Kann man zwar klein halten - aber: Ein Level braucht Breite X Höhe Bytes. Macht man ein Level nur 12 Blocks/Kacheln hoch (bei 16x16er Kacheln also 192 Pixel, von 200 möglichen bei 320x200 Mode), dann kann es 5461 Spalten breit werden. Ein "Bild" ist 20 Blocks breit, reicht für 372 Bilder. Klingt viel. Ist es auch. Wenn man mehrere Ebenen haben will, braucht man auch noch Speicher für diese dahinterliegenden Ebenen. So viel Speicher braucht das trotzdem nicht - für so einen Horizontalscroller jedenfalls. Wenn man große Levels haben will, die nicht nur nach links/rechts, sondern auch nach oben/unten gehen können (guter Plattformer), dann sollte man dem Ganzen schon ein Segment gönnen, ansonsten ist es eben etwa ein Viertelsegment oder etwas mehr.

Ein anderes Viertelsegment oder etwas weniger wird von Meta-Farbpaletten belegt - wenn man für Figuren/Kacheln usw. indirekte Farben benutzen will, um z.B. pro Pixel nur 4 Bit zu brauchen, müssen die "wirklichen" Farben irgendwo gespeichert werden. Außerdem brauchen die Sprite-Images auch noch Metadaten: Wo sie liegen, wie breit/hoch sie sind, wo der Hotspot ist, evtl. Flags. Auch diese Liste braucht etwas Speicher. Bei all dem kommen wir mindestens auf ein halbes Segment mehr.

Sind wir also bei 3,5 Segmenten.

Mein GameSys2 belegt (allein der CODE!) ca. 22 kByte - da ist NICHT der Speicher drin, der dann vom Bytecode belegt wird, der für die Steuerung der Figuren ausgeführt wird - der macht sicher das restliche Segment voll. Haben wir schon 4,5.

Die Routinen, die die Grafiken anzeigen, die äußere Spielsteuerung machen, den ganzen Menüskriptkram und alles - also auch die ganzen File-Operationen, Speichermanagement und all den ganzen Krempel - sind in Pascal geschrieben und ich bin nicht SO irre, daß ich das alles in Assembler umsetzen werde. Der ganze Kram braucht MINDESTENS ein ganzes Segment, aber ziehen wor das überstehende mal vom obengenannten Zeug ab (Leveldaten, Imagemetadaten, Metapaletten) und wir kommen hier auch auf ein Segment.
(Files werden intern übrigens blockweise über so Puffer geladen - byteweises Laden dauert ewig...) Puffer brauchen aber auch etwas Platz.

Sind wir, freundlich gerechnet, bei 5,5.

Musik/Sound: Meine ISM-Routine ist (derzeit!) ein paar Bytes größer als 16 kByte - da kommen noch ein paar Tabellen dazu und die Routine, die zum Laden/Speichern von Musik da ist. Ich würde mich wundern, wenn es nicht mind. 24 kByte insgesamt wären nur dafür. Da kommt ja noch das File dazu, das die Musikdaten enthält. Egal wie gepackt das auf Festplatte ist, im Speicher funktioniert es nur entpackt. Für einigermaßen gescheite Musik sollte man mindestens 8 kByte veranschlagen - und da wären wir bei den 32 kByte eines halben Segments.

Sind wir bei 6 Segmenten.

Haben wir Soundpuffer? Natürlich haben wir Soundpuffer! Ohne Doublebuffering kann man keinen lückenlosen Sound machen: Während der eine Puffer gefüllt wird, wird der andere gespielt. Anders kann ich es mir nicht vorstellen. Klar - der Sound ist dann nicht total synchron zum Spiel - aber ohne Puffern kommt man nicht hin in so einer Spielschleife. Was soll man machen, wenn die Grafik gerade aufgebaut wird und einem mittendrin die Daten für die Soundkarte ausgehen? Im Interrupt umschalten auf den anderen Puffer geht. Aber im Interrupt neue Soundpuffer berechnen/füllen? Wohl kaum.

Also - für ein Spiel: Bloß nicht die Soundpuffer zu klein machen! Je mehr Frequenz, umso größer der Puffer! Die Soundblaster kann keine 44,1 kHz, weil sie ihre Frequenz mit 1000000/x (x=Byte) bekommt und meist läuft es auf 45454 Hz hinaus. Eine Zehntelsekunde Puffer (da muß man dann aber auch JEDERZEIT (d.h. in JEDER Spielsituation!) mind. 10 FPS schaffen!) braucht also 4,5 kByte - aber nein! Wir brauchen Doublebuffering! Also 9 kByte. Wenn man wirklich glaubt, 44 kHz Sound hinzubekommen und jeweils - zusätzlich zur Grafik und Steuerung - in einer Zehntelsekunde zu berechnen.

Wir sind bei 6 bis 6,5 Segmenten angekommen - freundlich gerechnet, wohlgemerkt. Bleiben ja noch Sachen übrig wie Fonts, Anzeigen und andere kleine Dinge. Wie viele und wie schön man die Fonts haben will, das bestimmt, wieviel Speicher die brauchen werden. Man kann natürlich auch einen schnöden EGA-Font 8x8 Pixel nehmen, Zeichen unter 32 und über 127 abschneiden und hat dann 0,75 kByte für einen Font, was quasi nicht ins Gewicht fällt - oder man benutzt größere und schönere Fonts, wobei jede Verdoppelung der Farben den Speicher verdoppelt und der Größe den Speicher zusätzlich vervierfacht. Manche Spiele nutzen auch mehrere unterschiedlich große Fonts. - Kann jeder anders sehen - aber mich persönlich würd's ja nerven, so gar keine Ausgaben haben zu können, deshalb werde ich wohl Fonts haben wollen.

Freundlich gerechnet und gescheiten sparsamen Code berücksichtigt (z.B. ist mein Menüsystem über ein sparsames Skript steuerbar) werde ich trotzdem irgend etwas bei so ca. 7 Segmenten brauchen. Am Ende ist vieles sowieso mehr als man denkt: Ein paar Sprite-Images mehr und schon brauchts auch mehr Speicher... usw.

Da komme ich am Ende immer noch ca. 128 bis 160 kByte für eventuelle Samples (wenn so viel Heap frei ist), was eigentlich reichen sollte. Und das wäre dann wohl auch das Maximum, was ich dem Soundmenschen zugestehen würde, womit dann Musiken UND Soundeffekte gemacht werden müßten. Das KANN auch mehr werden, wenn das Level einfacher wird oder es weniger Spriteimages gibt oder kleinere Fonts oder oder oder...

ABER: Ich wäre da ein totaler Diktator - in der Hinsicht, daß ich nicht einsehen würde, ein kleines primitives Spiel mit winzigen Levels, wenigen verschiedenen Figuren und häßlichen Grafiken und Fonts machen zu müssen, damit der zugehörige Sound mit Samples und in CD-Qualität daherkommen kann. Will sagen: Ein Standalone-Musikstück, das für sich selbst den kompletten RAM braucht, kann durchaus sehr nett sein - ist für ein Spiel aber nicht mehr brauchbar.

Dann kommen wir zum Aspekt des Packens: Gepackte Daten müssen entpackt werden, um benutzt werden zu können. Solche Routinen brauchen zusätzlichen Platz - und, was schlimmer ist: zusätzliche Rechenzeit pro Frame. Deshalb ist meine Devise (kann ja jeder andere anders machen) : Möglichst nur "verkleinern" mit trotzdem möglichen wahlfreien Zugriff auf die Daten. Bei jeglicher komplizierterer Form des Packens von Daten, die "live" (d.h. in jedem Frame) gebraucht werden, überwiegen für mich die Nachteile.
zatzen hat geschrieben:Bei allem anderen - Grafik, Levels, Figuren, ich denke das kannst Du besser, zumindest für ein Spiel das Deinen Ideen entspringt.
Naja, so ein toller Levelbastler bin ich gerade nicht. Und meine Grafiken sind auch eher rudimentär - alles sehr schematisch...
zatzen hat geschrieben:Soundmäßig ist es vielleicht einfach eine Geschmacksfrage ob man stilistisch eher auf der Synthesizer-Schiene unterwegs ist (ISM) oder auf der Sampler-Schiene (ZSM). Ich kann nur sagen dass mich das Samplen schon immer begeistert hat,
Womit klar ist, was Deine Schiene wäre.
zatzen hat geschrieben:ich hatte als 8jähriger das CASIO SK-10, ein Spielzeug-Sampling-Keyboard mit ca. 1 Sekunde ultra Lo-Fi Sampling-Kapazität, aber das hat mich schon ziemlich zu einigen Dingen inspiriert. Als ich dann mit 13 ohne
Hilfe des Internets endlich trotzdem einen Tracker an Land ziehen konnte war es sozusagen um mich geschehen.
Bei mir war es anders: Ich habe gehört, was Leute allein mit diesem kleinen Synthesizer-Chip namens SID hinbekommen haben und habe da immer gedacht: "Der Wahnsinn! Wer braucht schon Samples, wenn er DAS machen kann?"
zatzen hat geschrieben:Deshalb dieser tiefe Einfluss auf mich was Musik aus Samples angeht, und auch bei Spielen war ich immer begeistert wenn neben der AdLib Musik auch ein bisschen Digisound dazu kam.
Ja, die Sprachausgabe bei "Day of the Tentacle" hat mir schon sehr gefallen. Auch die Sprecher waren gut gewählt. Allerdings muß ich trotzdem zugeben, daß ich das Spiel auch ohne die Sprachausgabe gespielt hätte.
zatzen hat geschrieben:Der Kampf mit dem Interface ist ein Faktor, das ist aber eine Sache der Gewöhnung. Aber man gewöhnt sich nicht mal eben in 5 Minuten um, sondern das kann (bei mir) Monate dauern bis man einen annähernden Workflow erreicht.
Das ist als würde man ein neues Musikinstrument lernen. Deshalb hatte ich Dich gebeten AtavISM ähnlich wie X-Tracker bedienbar zu machen. Ist man an das Interface gewöhnt, gibt es nur noch den Faktor der Inspiration.
Naja - nachdem prISM ja nun als für "Außenstehende" kaum benutzbar dasteht, scheint ja auch die ganze Mühe, die ich in den zweiten, alternativen Editor AtavISM gesteckt habe (inkl. Übernahme vieler Bedienelemente aus X-Tracker), trotzdem kaum dazu zu geführt zu haben, dieses Ding wirklich zur initialen Entwicklung von Musikstücken verwenden zu wollen/können. Nicht, daß es mich noch stört - aber es überrascht mich auch nicht sonderlich.
zatzen hat geschrieben:
DOSferatu hat geschrieben:"(Sehr) gut klingen" ist sehr subjektiv. Geschmäcker sind grundverschieden [...]
Es geht hier ja um die Konservierung von Klängen, und wenn man mal nicht vom einfachsten Fall ausgeht und einfach nen SID aufnimmt: Reale Klänge muss man mit Mikrofonen aufnehmen, abmischen usw. Und dabei ist es eine Kunst, einfach zu vermeiden, dass es "irgendwie komisch" klingt. Man muss sich also bei der Aufnahme und Übertragung auf ein Zielmedium Mühe geben, damit das Resultat gut klingt bzw. einfach nur neutral klingt, das passiert nicht wie selbstverständlich von selbst. Und dafür werden Toningenieure professionell ausgebildet, soetwas kann nicht jeder.
Ja, schon klar. Aber bei Klängen, die man selbst erzeugt, kann man ja auch selbst entscheiden, wie "gut/neutral" die zu klingen haben.
zatzen hat geschrieben:Und klar, mancher mag vielleicht lieber ein Synfonieorchester über sein Küchenradio hören als über eine sehr gute Anlage. Aber die meisten wohl eher nicht.
Ich habe noch nie eine "Anlage" besessen und habe auch nicht vor, mir irgendwann mal eine zuzulegen. Ich könnte mir so etwas zwar leisten - aber der erhaltene Mehrwert wäre für mich minimal. Ehrlich gesagt MAG ich diesen plastikartigen Klang der C64-Spiele aus dem Mono-Lautsprecher meines C64-Monitors, mit dieser krisseligen Resonanz und allem - und wenn ich das dann irgendwie "glattgebügelt" hören würde, würde es für mich gar nicht mehr "echt" klingen...
zatzen hat geschrieben:Jetzt kann man sagen, ich mache ja auch Musik wo alles aus dem Computer kommt. Aber trotzdem muss ich da die Dynamik, den Klang und die Lautstärke der einzelnen Sounds mit viel Liebe zum Detail gestalten, das nennt sich dann Abmischen, was ein technisch-kreativer Vorgang ist.
Ja, von so etwas habe ich keine Ahnung. Das ist auch der Grund, wieso ich den Sound in ISM mit "Sicherheitslevel" ausgebe, d.h. so berechne, daß selbst im Worst Case (auch wenn der in Wirklichkeit nie erreicht wird) kein Clipping passiert. Ich habe schon darüber nachgedacht, einen zusätzlichen "Overdrive" Wert für jedes Musikstück einstellbar zu machen, damit man angeben kann, bis zu welchem "Additionswert" die Musik abspielbar ist, ohne zu plärren. Aber ISM muß ja Musik UND Soundeffekte erzeugen und wie rechnet man das dann wieder gegen (um Clipping zu vermeiden), wenn gleichzeitig zur Musik ein (oder mehrere!) Effekte abgespielt werden soll...
zatzen hat geschrieben:Hmm, Dein Rechner ist vielleicht für Windows 7 dann "zu langsam",
Es gibt keine "zu langsame" Hardware. Es gibt nur zu schlecht programmierte Software.

Und wenn auf einem alten langsameren Rechner mit alter Software Dinge funktioniert haben und auf einem neuen schnelleren Rechner mit neuer Software die gleichen Dinge ruckeln und Zeit brauchen, kann's wohl kaum an der Hardware liegen.
zatzen hat geschrieben:keine Ahnung, meiner ist von 2012, ist glaube ich ein i5, war erst XP drauf, und Win7 hat er noch gepackt. NTFS brauche ich persönlich, da ich einige Dateien > 4 GB habe.
Ich frage mich zwar immer, was ein File > 4 GB so enthalten könnte - außer vielleicht gepackte Daten eines großen Spiels, aber die könnte man ja dann auch auf mehrere Files aufteilen.
zatzen hat geschrieben:Mir gefällt das alles auch nicht, aber ich habe einfach zu viel Windows-Software die ich gerne weiterbenutzen würde. Auch wieder Gewohnheit, seit 1995 benutze ich Windows hin und wieder, seit etwa 2000 ziemlich regelmäßig, jetzt auf Mac oder Linux umzusteigen - ich weiss nicht...
Naja, kein Fan von Windows zu sein, muß ja nicht bedeuten, daß man auf NOCH lahmeren Scheiß wie Mac oder NOCH benutzerunfreundlicheren Scheiß wie Linux steht...

Ich benutze ja auch Windows - das "Internet" ist ohne "moderne" Browser ja leider nicht mehr zu gebrauchen. Das Blöde daran ist, daß alles, was die Webseiten "zusätzlich" haben (was quasi so alte Browser wie z.B. Arachne nicht mehr können), genau das ist, was an den Seiten eigentlich das Nervige ist auf das ich gern verzichten würde und gern abschalten könnte. Nur leider funktionieren die Seiten ohne den Scheiß oft gar nicht mehr. Oder sie verwenden aus Faulheit neue Dinge, die mit uraltem HTML 0.9 auch schon zu machen wären. - Einfach alles Gesocks heutzutage!
zatzen hat geschrieben:Mein Laptop ist mit XP und vor allem Internetgeschichten überfordert,..
Tja. Mit dem Internet von vor 20 Jahren wäre er das sicher nicht. Es liegt an dem ganzen zusätzlichen Dreck, der da inzwischen entwickelt wurde.
zatzen hat geschrieben:"Kann" Windows XP 64 Bit? Immer mehr Software-Hersteller unterstützen leider keine 32 Bit mehr.
Die Frage kann man mit Nein und Ja beantworten.
Das normale Windows XP ist für 32 Bit gedacht.
Es gibt aber eine Windows XP Version für 64 Bit.
Allerdings würde auch 32 Bit Software auf 64 Bit laufen (nur eben keine 16bit mehr).
Was HERSTELLER machen, bzw. wie sie denken, ist doch klar: Die stehen schon morgens mit $$$-Zeichen in den Augen auf. Und außer $$$ interessiert die GARNIX. Billig herstellen, teuer verkaufen. Klavierlack dran, damit billig hergestelltes teuer genug aussieht, um den Preis zu rechtfertigen...
Zum Glück gibt es außer "Software-Herstellern" ja auch noch private Programmierer/Entwicklercrews - die teilweise viel bessere (und kostenlose!) Anwendungssoftware herausbringen als "Hersteller". Nur bei SPIELEN - da wird's natürlich eng. Spiele sind inzwischen so anspruchsvoll geworden (weil Spieler diese Ansprüche HABEN und unter dem nichts mehr gewollt wird), daß man als Nicht-"Hersteller" da nichts mehr machen kann, was irgend jemanden wirklich begeistern könnte. Und wer das will, bracht dann eben auch immer die aktuellste Hardware - wie von den Herstellern vorgegeben.
zatzen hat geschrieben:Auf Windows 7 bin ich nur umgestiegen weil eine Software die für mich sehr wichtig war das verlangte. Aber eigentlich bereue ich das nicht.
Windows 7 finde ich wesentlich weniger ausgereift als Windows XP.
Aber diese eine 64 Bit Kiste hier (die mir der eine Kumpel zusammengeschraubt hat) wäre mit einem 32 Bit System eben etwas unterfordert.
Leider hat der 64-Bit-Mode der PC-CPUs den entscheidenden Nachteil, in diesem Modus keinen 16-Bit Code mehr ausführen zu können. (Eigentlich wären die CPUs schnell genug, daß man das sogar in einem der Kerne anschaltbar als Hardware-Emulation hätte einbauen können.) Der 32-Bit-Mode konnte damals ja schließlich auch abwärtskompatibel gemacht werden.

Ich nehme eher an, daß es hier um die als "artificial obsoletion" = "künstliche Veralterung" bekannt gewordene Praxis geht. Damit wird verhindert, daß Leute immer noch ihr altes Zeug benutzen können und neues Zeug kaufen MÜSSEN - und gleichzeitig kaufen sie damit auch die Restriktionen, die beim neuen Zeug dabei sind:
Ein Windows 10 (glaub auch schon 8) ist z.B. nicht mehr installierbar, wenn die CPU das NX-Flag nicht unterstützt...
zatzen hat geschrieben:"ohne wirklich mehr zu können" - ja, genau wieder die Parallele zu Lautsprechern. Glühbirnen werden verboten, aber bald können wir mit Lautsprechern heizen... Naja das ist vielleicht aktuell noch übertrieben, aber es gibt tatsächlich schon Lautsprecher für die 500 Watt empfohlen sind,[...]
Naja, man knallt ja auch heutig massiv Rechenleistung selbst für die simpelsten Dinge drauf, weil alles immer gleich mit riesigen Frameworks, die irgendwelche Skripte abarbeiten, gemacht werden muß. Der Anteil an der Rechnenleistung dessen, was dann wirklich "gemacht wird", also nach außen für den User Nutzen bringt, liegt heutzutage bei oft weniger als 1%.
zatzen hat geschrieben:ZSMPLAY Release v0.05ß
Ja, hab mir den schon vor einer Weile heruntergeladen inkl. der Musikstücke.
Sind zugegeben diesmal weniger Stücke als beim letzten Mal dabei, die ich "dauerhören" könnte, aber ein paar Sachen haben mir auch gefallen.
zatzen hat geschrieben:- Alle Modi sind ohne Umweg über den Main Mode sofort abrufbar
Gute Idee.
zatzen hat geschrieben:Downloads:
Diesmal Module und Programme gesondert. Source diesmal nicht dabei, gerne auf Anfrage.
Ja, macht Sinn, Module und Programm zu trennen - zumindest, sobald die Module mit dem Programm abspielbar (kompatibel) bleiben, auch wenn das Programm mal weiterentwickelt werden sollte.

Das erst mal zu diesem Thread. Den "Grafik"-Thread beantworte ich demnächst.
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 »

DOSferatu hat geschrieben:[...]müßte man eigentlich nur Lautsprecher mit der gleichen Flexibilität wie ein Trommelfell bauen, den durch die Luftreibung verlorengehenden Anteil abziehen und hätte dann die maximal gebrauchte Lautsprechergröße.
Kopfhörer!
Aber sobald man diese beiseite legt krächzt und zischelt es nur noch. Direkt vor dem Ohr macht auch eine Hummel
oder vielmehr ein Käfer mächtig Bass, aber auf einen Meter Entfernung hört man kaum noch etwas davon.
Das Ohr ist praktisch ein Mikrofon, und bei denen gibt es den Effekt dass bei nahen Schallquellen der Bassbereich
stärker hervortritt.
Aber das eigentliche Phänomen hat mit dem Strahlungswiderstand und den Wellenlängen zu tun. Bei tiefer werdenden
Frequenzen weicht die Luft einem kleinen "Erzeuger" immer mehr einfach aus, als dass viel Luftmasse zum schwingen
angeregt werden würde. Und wie gesagt, Kopfhörer sind Lautsprecher, die mit einer Membran vom Bass bis in die Höhen
spielen, aber sie funktionieren nur direkt am Ohr. Es gibt allerdings Breitbandlautsprecher, die vielleicht von 80-10000 Hz
brauchbar sind und meinetwegen 10 cm groß, aber eine vernünftige Fläche für den Tiefmitten- und Bassbereich klingt
doch überzeugender.
Man kann sich die ganze Sache auch verbildlichen indem man es mit Wasser und Paddeln vergleicht - mit einem richtigen
Paddel kommt man besser voran als mit Teelöffeln. Aber es geht um Schwingungen, Wellen, nicht das bloße Abstoßen
innerhalb eines Mediums.

Und klar, leider, so wie ich das zu meinem Frust als Lautsprecherkonstrukteur erlebe, ist es so - Lautsprecher müssen in
die Möblierung passen, und zwar möglichst unauffällig. Sitzecke, Sessel, Schränke und auch der Fernseher dürfen
mächtig und klotzig sein, aber die Lautsprecher am besten unsichtbar. Als würde man sich dafür schämen, oder, als
würde man denken, was klein ist klingt besser, weil ja modern und neue Technologie, muss ja besser sein. Aber
wie wir wissen: $$$-Denken dominiert den Markt und kein Idealismus. Design und Klavierlack - das Auge hört bei
vielen scheinbar mehr als das Ohr.

Ich brauche aber "klare Sicht", großes Kino was Ton angeht. Was für andere das große Fenster mit Panoramablick im
Wohnzimmer ist, ist für mich die "Lautsprecherwand", da sie für mich das große Fenster ist, durch das ich alles gut
beurteilen kann.

So viel zu dem Thema... mal wieder.

Das Prinzip von akustischen Hörnern ist, eine kleine Lautsprecherfläche ohne Erhöhung der Membranmasse deutlich zu
vergrößern. Dabei erfährt die Lautsprechermembran eine höhere akustische Impedanz und kann so tiefere Töne
effektiver bzw. überhaupt wiedergeben, die sie mit ihrer eigentlich kleinen Fläche nur schlecht wiedergeben könnte.
Also eher Trööte, am Anfang der kleine Lautsprecher, am Ende die große Öffnung. Man denke einfach an eine Tuba. Mit
den bloßen Lippen macht man nur ein schnödes prrrrrpprrrp... Mit der Tuba dran einen satten, tiefen Ton der tatsächlich
nur von den Lippen kommt.

MP3 ist ja ähnlich wie JPG eigentlich. Macht ja auch bei JPG Sinn, einen guten Monitor zu haben, trotz mancher
geringer Artefakte. Der Vergleich Monitor vs. Lautsprecher hinkt ein wenig, weil man seinen Ohren durchaus eine 2,50
Meter breite Stereobasis auf ca. 2 Meter Abstand bieten kann, ohne dass man sich, wie bei einem so großen Monitor,
den Hals verrenken müsste. Der Unterschied von kleinen Lautsprechern vs. guten großen zeichnet sich für mein
Empfinden vielmehr in der Deutlichkeit und Differenziertheit des Klangs ab, die einzelnen Elemente sind bei letzteren
viel besser auseinanderzuhalten und auch "Unschönheiten" viel besser rauszuhören.

Also, genug Off-Topic.

Kommen wir mal zu einer Überlegung, die ich bisher kaum näher verfolgte, aber ich habe in letzter Zeit öfters davon
(nachts) geträumt, dass ich mit nem eigenen (ZSM) Tracker Musik gemacht hätte und das wäre ganz toll gewesen. Der
Tracker war bunti (320x200x256) aber nicht klicki. Ungeachtet der Tatsache, dass es rein pragmatisch wenig Sinn
macht, da ich auch einfach in X-Tracker was erstellen und dann konvertieren kann, mal folgende Überlegungen:
- Ich müsste entweder XMS oder einen "pagefile" benutzen. Gründe: Selbst bei interner leichter Kompression der
Patterns wäre die eigentliche Stärke von ZSM, ca. 500 Patterns halten zu können, nicht machbar. Ist klar, man wird
allemal nur 50 brauchen, aber es geht ums technische Prinzip. Weiterhin ist auch die dynamische Verwaltung der Samples
mit Problemen verbunden, zudem brauche ich Headroom für Funktionen wie Importieren von WAV zu 4 Bit Delta.
Letzlich würde ich lieber eine Auslagerungdatei und nicht XMS benutzen, Patterns würde ich somit daraus laden und
drin speichern, fragt sich nur ob das schnell genug ist, es müsste ja innerhalb einer Pufferzeit geseekt und geblockloadet
werden, und je nachdem entpackt - aber das zeilenweise, mal sehen.
- Da bei ZSM die Samples beschnitten werden, d.h. nur so viel gespeichert wird wie wirklich abgespielt wird, was nur an
einem fertigen Modul entschieden werden kann, liegt es nahe, intern ein anderes Format zu verwenden, und dann für
ZSM eine Exportierfunktion zu integrieren, oder einfach einen Converter beizulegen. Ein internes Format mit
ungekürzten 8 Bit Samples hätte immerhin den Vorteil, dass man die Stücke dann auch ohne Verlust in den Samples in
andere Formate wie DMF oder MOD exportieren könnte um sie evtl. weiter zu bearbeiten.
Tja, ein solcher Tracker wäre herzlich un-innovativ, aber vielleicht doch ganz reizvoll, aufgrund der Einfachheit, und der
Garantie, dass darin gemachte Musikstücke 100% ZSM kompatibel wären, auch mit Vorschaumöglichkeit des Klangs von
4 Bit Delta. Und ich hätte meinen ersten eigenen Sample-Tracker.
DOSferatu hat geschrieben:Nur, ein einzelnes Mono-8-Bit-22-kHz Sample braucht für 1 Sekunde nunmal auch 22 kByte RAM. Allein 3 solcher Samples füllen schon ein komplettes Segment!
Ist klar, dass ich da wieder einsteige: Man kommt mit 16 kHz bis auf ganz höhenlastige Sachen wie Rasseln oder sowas
sehr gut hin, das ist schon sehr gute Qualität. Wenn man bedenkt dass für Samples wie Bass 8 kHz reichen und sagen wir
im Schnitt haben wir 12 kHz, was auch für Sprache hinreichend ist in einem Spiel, dann kommen wir bei 4 Bit Delta auf
6000 Byte pro Sekunde, und damit auf knapp 11 Sekunden pro Segment.
Ja, das ist irgendwie gemogelt mit der Kompression, aber so auch mit der Grafik, bei Deiner Problematisierung des
Speichers erscheint es mir langsam wirklich sinnvoll, ernsthaft an soetwas wie ZVID2 weiterzumachen. Notfalls mache ich
vielleicht doch etwas in Richtung Adventure, wo es nicht auf hohe Framerates ankommt. Oder man ermutigt sich wieder
einmal angesichts Jump&Runs wie... Captain Comic mit seinen 10 fps und 8 Pixel-Scrolling. Total "outdatet", aber:

Sinn macht das Programmieren als Spielwiese für nicht mehr zeitgemäße Ergebnisse und scheinbare sinnlose
Datenverarbeitungsverfahren ohnehin, denn gleichermaßen könnte man sagen, die ganze Programmierung für Dos
wäre heutzutage sinnfrei. Sieht Du vielleicht anders, weil Du gerade in Dos versuchst, möglichst optimal zu
programmieren, so als würde es zu damaligen Zeiten verwendet werden. Bei mir haben sich die Hobby-Prioritäten
leider anders entwickelt, ich programmiere gerne, nicht zuletzt um etwas zu lernen (besonders in ASM), bin da aber
nicht so streng mit mir. Wenn ich Routinen schreibe mache ich das schon möglichst optimal, aber mir fehlt etwas der
Atem, um ein Spiel wirklich mit höchster Vernunft und Verzicht auf Spielereien wie ZVID und ZSM aufzuziehen.
Heisst also auch, ich möchte gerne mal meine Formätchen, die etwas Performance zugunsten Speicherplatz opfern, in
Action erleben.
Das ganze hängt damit zusammen, dass erst die Programmierung in Assembler mir solche eher komplizierten
Kompressionsverfahren bei einigermaßen vertretbarer Performance ermöglicht hat, und das ist dann für mich im
Moment noch neu und interessant, weil ich zuletzt bei Kotzman II noch kein Assembler konnte. Und nicht-transparente,
unkomprimierte Sprites mit PUT setzen war sowas von unspektakulär...

Deine auführliche Abhandlung über die Anforderungen eines Spiels wirken etwas pessimistisch. Ich habe nur die
Erfahrung dass ich bei Kotzman II mit nur einem(!) Datensegment immerhin etwas vorzeigbares hinbekommen habe.
Und mein Ziel ist ja eher nur, daran anzuschliessen, soetwas ähnliches nocheinmal zu machen, nur in jeder Hinsicht,
also Grafik, Sound, aber auch Spielgeschehen, etwas erweitert (und dafür die restlichen 7 Segmente zu verwenden...).
Deswegen mache ich mir da ersteinmal keine solchen Gedanken.
Ich brauche gar nicht erst versuchen einen "Blockbuster" zu programmieren, die Möglichkeiten von Real-Mode Dos
reissen heute keinen mehr vom Hocker, wenn man "fotorealistisches" 3D in Full HD erwartet.
Einfach nur ein kleines nettes liebevoll gestaltetes Spielchen.
Und ob nun ein Spiel auch auf einem 386er statt 486er flüssig laufen würde dürfte auch nur Leute wie Dich und mich
im Sinne von Idealismus kümmern, und da kann man selber abwägen wie wichtig einem das ist.
DOSferatu hat geschrieben:nachdem prISM ja nun als für "Außenstehende" kaum benutzbar dasteht, scheint ja auch die ganze Mühe, die ich in den zweiten, alternativen Editor AtavISM gesteckt habe (inkl. Übernahme vieler Bedienelemente aus X-Tracker), trotzdem kaum dazu zu geführt zu haben, dieses Ding wirklich zur initialen Entwicklung von Musikstücken verwenden zu wollen/können. Nicht, daß es mich noch stört - aber es überrascht mich auch nicht sonderlich.
Wenn Du ein Spiel machst, das ISM verwendet, und Du gerne Musik von mir gemacht haben möchtest, dann sollte es klar
sein, dass ich dann AtavISM verwende. Genauso ist es aber auch klar, dass ich nicht in AtavISM Musik komponiere, wenn
ich den Schwerpunkt auf Samples lege oder das ganze am Ende auf CD-Niveau ausproduzieren möchte.
Es ist "schade" dass es nicht so viele Leute gibt, die neue Software wie AtavISM benutzen, genauso würde es mir aber
auch mit dem "Zatzen simple Tracker" (s.o.) gehen. Es gibt eben heute massig kostenlose Tracker (sogar schon Online im
Browser) und Musikprogramme für Windows, die VST Instrumente und Gigabyte-weise Samples verarbeiten können.
Was für die Musiker ja auch sehr begrüßenswert ist, ich mache auch mehr und mehr mit Renoise, und habe es mir aber
auch so gut wie möglich wie X-Tracker konfiguriert, und soetwas wie Leertaste abspielen und wieder stoppen und Shift-
Leertaste abspielen ab Cursor ist relativ schnell gelernt und auch nicht viel dümmer als Alt+F9 und Esc zum wieder
Stoppen. Jedenfalls hat es für mich schon Vorteile wenn ich nicht vorab erstmal alle Samples auf 8 Bit und 11 kHz
runterrechnen muss nur um sie am Ende wieder durch 16 Bit 44 kHz auszutauschen.
Vielleicht hast Du diese Videos von mir gesehen, wo das Gesehene dem Ton entspricht, also praktisch Videos als Samples
benutzen. Sowas kann Renoise noch nicht, ich hatte das für X-Tracker auch nur selbst programmiert diese Möglichkeit.
Ich überlege ob ich sowas auch für Renoise mache. Da müsste ich mich durch das in XML gehaltene Dateiformat
durchwursteln und quasi einen Renderer schreiben, der Frame-Informationen die parallel in Samples gehalten werden
entsprechend zurechtrechnet.
Auch ein Zeichen der Zeit, dass die Dateien nicht binär sondern als XML gespeichert werden, also aufgeblasen wie sonst
was, naja, damit "menschenlesbar", kann ja auch ganz praktisch sein, 600K hab ich da bei einem kleinen Stück mit 4
Patterns, nur die Definitionen, ohne Samples.
Aber so ist es nunmal wenn heute so viel Speicher da ist, vor 30 Jahren waren 20 MB Festplatte viel, heute sind es 2 TB,
also Faktor 100.000. Verhältnismäßig wären die 600K dann 6 Byte, was ja ziemlich wenig ist.

Und eine Datei mit >4GB ist z.B. oft ein Video. Ich habe in letzter Zeit einige Videos von einer (auch heute längst
veralteten) Digital8 Kamera im DV Format auf eine externe Festplatte überspielt. Eine Minute braucht ca. 180 MB.
Da ist man bei einer Stunde schon bei > 10 GB. Klar könnte man das technisch durch aufteilen lösen, aber es ist schon
ganz praktikabel so.
Ich könnte mich ja selber über die "Jugend" aufregen dass nur noch in GB gedacht wird und vielleicht kaum noch einer
weiss was ein MB oder gar KB ist, und dass man sich übers Smartphone oder email einfach Videos von mehreren MB
Größe schickt, während ich mir immer noch Mühe gebe, den Anhang von emails so klein wie möglich zu halten.
Aber es ist eben mittlerweile möglich und ich kann selber nicht leugnen dass ich Nutznießer dieser modernen
Technologien/Bandbreiten/Kapazitäten bin, nicht zuletzt auch im Audio-Segment, wo 25 Jahre alte Hardware die Arbeit
schon etwas bremsen und einschränken und vor allem verkomplizieren würde.
Ja, kann man alles auch mit MIDI und nem Fuhrpark von Audio-Peripherie am Atari machen.
Hab ich aber nie so gemacht sondern seit 1993 alles in einem Computer ohne externe Hardware. Und jetzt geht eben
einfach mehr, damals nur rohe MODs mit LoFi 8 Bit Sound, heute uneingeschränkte Qualität und Möglichkeiten.
Aber parallel dazu vergesse ich die "alte Zeit" nie und daher habe ich auch Spaß daran, Daten kompakt zu halten im KB
Bereich.

ISM:
Vor Clipping habe ich wie hier oft schon erwähnt aufgrund meiner Erfahrung gerade im Lo-Fi Bereich keine Angst, es
muss eben nur wirklich geclippt (Pseudo: if a > 127 then a = 127; if a < -128 then a = -128) werden, was einen zweiten
Puffer in 16 Bit erfordert...
Was Du statt Clipping noch machen könntest, wäre eine momentane Verminderung der Lautstärke über die Pufferlänge.
Das käme dann in etwa einem Kompressor oder Limiter in der Audio-Technik gleich bzw. nahe, und würde statt
Verzerrung eher "pumpen" verursachen, wenn's zu laut wird.

Ich erinnere mich dass Du die Daten vorzeichenlos verarbeitest. Muss man dann evtl. anders rangehen.
DOSferatu hat geschrieben:Naja, kein Fan von Windows zu sein, muß ja nicht bedeuten, daß man auf NOCH lahmeren Scheiß wie Mac oder NOCH benutzerunfreundlicheren Scheiß wie Linux steht...
Das ist mal eine erfrischende Sichtweise!
Im Audio Bereich schwören alle auf Mac, und alle vermeintlichen Freaks die was auf sich halten machen alles mit Linux.
Das hatte mich als Microsoft USER schon leicht verunsichert...
mov ax, 13h
int 10h

while vorne_frei do vor;
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Trackermodul-Engine (sehr einfach)

Beitrag von wobo »

zatzen hat geschrieben: ... Also, genug Off-Topic.
Ich habe es leider nicht mehr geschafft, diesen Thread mitzuverfolgen. Aber immer, wenn ich kurz rein schaue und auf Deine "Off topic" -Ausführungen stosse, bleibe ich fasziniert hängen. Ich finde es absolut beeindruckend, was Du für einen Erfahrungsschatz und praktisches Know-How hast. Der Thread ist ja schon uralt und hat im Jahr 2012 begonnen. Damals hatte ich ja meinen Mod-Player versucht zu schreiben. Ich weiß, wie einfach Deine Ausführungen dazu, wie Du trackerst für mich enorm hilfreich waren. Z.B. waren es - unter anderem - so Sachen, wie und warum Du in bestimmten Situationen nur eine Note anschlägst ohne neue Angabe von Instrumentennummer und Lautstärke. Dies sind so Sachen, die einfach nicht in der Formatbeschreibung enthalten sind. Da ich nie einen Tracker benutzt habe und von Musik Null Ahnung habe, konnte ich mir quasi ein bisschen Deinen Erfahrungsschatz "leihen" und so endlich meinen Mod-Player fertig stellen.

Bei dieser Gelegenheit also ein ganz dickes Danke von mir!
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 »

Hallo wobo!
Schön mal wieder von Dir zu hören (lesen)!

Trackern: Durch nur-Noten-Änderung kann man praktisch Noten-Slides machen, also Tonhöhe
verändern während das Sample einfach weiterläuft. In MODs braucht man dafür einen Effekt,
bei X-Tracker kann man einfach die Instrumenten-Nummer weglassen.
Für ZSM konnte ich das leider nicht integrieren, der Grund ist:
Ich brauche für jede Tonhöhe auch die Sample-Nummer.
Denn ich lege für jedes Sample eine Schrittweiten-Tabelle an mit nur so viel Einträgen
wie auch an verschiedenen Tonhöhen vorhanden sind. Das ganze ist so gelöst, damit
ich auch andere Basisfrequenzen als 8363 Hz verwenden kann, was X-Tracker kann, und
was unheimlich praktisch ist, nicht zuletzt auch fürs Tuning.
Und ich brauche auf diese Weise keine generalisierte Period-Tabelle.
Eine Möglichkeit wäre gewesen, ähnlich wie bei MODs, das Sliden durch ein Bit zu flaggen.
Ich weiss auch nicht mehr genau, entweder war es wirklich schwierig zu integrieren
oder ich war etwas faul oder habe es nicht für erstrebenswert genug gehalten.
Vielleicht erweitere ich das Format und versuche den Player abwärtskompatibel zu halten.
Bis jetzt sind auch die Schrittweite-Tabellen auf 32 Einträge beschränkt, dadurch waren
ein paar MODs schonmal inkompatibel, wegen zu vielen Noten.
Eine Verdopplung der Grenze dürfte da aushelfen.

Gibt es eine neue Version von Deinem MOD-Player?
Ich hätte das ganze möglicherweise auch MOD-mäßig aufgezogen, mit
allen Effekten usw... Aber wie ich es verstehe ist so ein MOD in 50 Hz gerastert,
und beim Standard-MOD ergeben sich dann Tempi wie 107, 125, 150, 188 BPM.
Ich wollte aber beliebige BPM, und das gibt es ja auch bei MOD, aber wie geht das
dann wiederum mit 50 Hz Rasterung auf?

Rein theoretisch denkbar wäre ein ZSM2 mit (sagen wir fast) allen MOD-Effekten
mit den Speichervorteilen von 4 Bit Delta Samples und Bitweise komprimierten
Patterns, die aber je nach Effektaufkommen doch wieder etwas größer würden.
Das wäre dann vielleicht wirklich sinnvoll, wenn man auch die "Effekt-Kunstwerke"
nach ZSM(2) konvertieren könnte.
Naja, wie gesagt theoretisch. Ist schon ne Aufgabe, so ein MOD Player mit allen Effekten.
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:Kopfhörer!
Aber sobald man diese beiseite legt krächzt und zischelt es nur noch. Direkt vor dem Ohr macht auch eine Hummel oder vielmehr ein Käfer mächtig Bass, aber auf einen Meter Entfernung hört man kaum noch etwas davon.[...]
Ist mir schon klar.
zatzen hat geschrieben:Es gibt allerdings Breitbandlautsprecher, die vielleicht von 80-10000 Hz brauchbar sind und meinetwegen 10 cm groß, aber eine vernünftige Fläche für den Tiefmitten- und Bassbereich klingt doch überzeugender.
Man kann sich die ganze Sache auch verbildlichen indem man es mit Wasser und Paddeln vergleicht - mit einem richtigen Paddel kommt man besser voran als mit Teelöffeln. Aber es geht um Schwingungen, Wellen, nicht das bloße Abstoßen innerhalb eines Mediums.
Naja, ich sag's mal so:
Früher, mit 16, konnte ich, sozusagen "die Flöhe husten hören": Wenn in einem Raum ein Röhrenfernseher an war, konnte ich das hören - an diesem 15 kHz "Pfeifen". Heutzutage, in der Firma (Großraumbüro), lausche ich auf alles, was phonetisch so ähnlich klingt wie mein Name, damit es nicht heißt, ich reagiere nicht, wenn ich angesprochen werde. Meinst Du wirklich, daß es sich da noch lohnt, mannshohe Boxen mit kristallklarem Sound anzuschaffen?
zatzen hat geschrieben:Und klar, leider, so wie ich das zu meinem Frust als Lautsprecherkonstrukteur erlebe, ist es so - Lautsprecher müssen in die Möblierung passen, und zwar möglichst unauffällig. Sitzecke, Sessel, Schränke und auch der Fernseher dürfen mächtig und klotzig sein, aber die Lautsprecher am besten unsichtbar. Als würde man sich dafür schämen, oder, als würde man denken, was klein ist klingt besser, weil ja modern und neue Technologie, muss ja besser sein.
Oh, ich habe ja keinerlei Abscheu vor "zuviel Technik im Raum". Bei mir ist es eben so, daß die Lautsprecher noch Platz auf dem Schreibtisch finden müssen und auf dem stehen auch noch 3 Computer und 2 Monitore, ein Telefon, ein 4-fach Monitor/Keyboard/Maus-Switch, ein Modem usw. und ich sitze außerdem so ca. 70-80 cm (und wenn ich mich zurücklehne 1 m) von den Lautsprechern entfernt - und da brauche ich einfach keine riesigen Kisten.
zatzen hat geschrieben:Aber wie wir wissen: $$$-Denken dominiert den Markt und kein Idealismus. Design und Klavierlack - das Auge hört bei vielen scheinbar mehr als das Ohr.
Naja, so bin ich ja nicht. Ich besitze auch kein Smartphone. Und daß meine Playstation3 noch das alte Modell mit Klavierlack ist, liegt weniger am Klavierlack, sondern mehr daran, daß bei der neuen kleineren ein paar Anschlüsse wegrationalisiert wurden und sowas kann ich nun gar nicht ab.
zatzen hat geschrieben:Ich brauche aber "klare Sicht", großes Kino was Ton angeht. Was für andere das große Fenster mit Panoramablick im Wohnzimmer ist, ist für mich die "Lautsprecherwand", da sie für mich das große Fenster ist, durch das ich alles gut beurteilen kann.
Meine Fenster sind zugeklebt, damit es hier schön duster ist. Mein TV hat 15Zoll CRT, mein Monitor 14Zoll CRT, meine neueste Technik ist 15 Jahre alt oder so... Und im Gegensatz zu Dir lege ich nicht SO einen Wert auf Kristallsound. MIr reicht die Qualität aus, die meine Lautsprecher produzieren - ehrlich gesagt LIEBE ich sogar so Zeug aus dem PC-Speaker - deshalb wird der auch in meiner Spiel-Engine (neben der Sound Blaster) mit unterstützt.

Eigentlich reicht Sound Blaster (und kompatible) zu unterstützen ja schon aus, weil jemand, der DOS-Spiele spielt, sich sowieso irgend etwas SB-mäßiges holt. Aber, ich hatte immer mal überlegt, ob ich die GUS (Gravis Ultrasound) mit supporten sollte - aber habe dann gemerkt, daß ich dazu komplett anders vorgehen müßte - weil sie hardwaremäßig das macht (Samples abspielen/abmixen) was ich in Software mache und weil sie für diesen "Chiptune"-artigen (sample-freien) Sound, den ich eigentlich machen will, völlig ungeeignet ist.

Dann habe ich überlegt, ob man die AbLib unterstützen sollte. Wäre sicher cool - andererseits ist die "AdLib", die die meisten Leute benutzen, sowieso keine AbLib-Karte, sondern nur der entsprechende Chip, der auf allen Sound Blastern mit drauf ist. AdLib hätte wohl den entscheidenden Vorteil, auch auf langsamen Systemen gut zu performen, weil sie ja quasi so Zeug selbst generiert, was ich in Software mache - allerdings hat sie auch diese niedlichen Timing-Glitches beim Ansprechen mancher Register...

VIELLEICHT baue ich aber irgendwann mal eine Erweiterung in ISM ein, die für AdLib geeignet ist - aber momentan hat das einfach keine Priorität. Ich programmiere sowieso schon viel zu wenig in letzter Zeit. Aber daß ich mal die GUS supporte... Das wird wohl kaum passieren - außer, daß ich vielleicht einen "Blaster-mäßige" Hack benutze, d.h. die generierten Sounddaten dann nur auf einem Channel der GUS zyklisch ausgebe und den Rest das ISM machen lasse. Damit würde man die GUS zwar eher "mißbrauchen", weil man ihre Möglichkeiten gar nicht benutzt - es wäre quasi nur ein "Hack", um Leuten mit GUS-only System zu ermöglichen, Sound zu haben.

PC-Speaker ist sowieso eine "unsichere Kiste": Macht nur Sinn, wenn der Rechner schnell genug ist. So'n früher 386er kann wahrscheinlich gar nicht meine klotzartigen Routinen (Grafik, Sound, Steuerung) alle gleichzeitig bedienen in adäquater Geschwindigkeit.
zatzen hat geschrieben:Das Prinzip von akustischen Hörnern ist, eine kleine Lautsprecherfläche ohne Erhöhung der Membranmasse deutlich zu vergrößern. Dabei erfährt die Lautsprechermembran eine höhere akustische Impedanz und kann so tiefere Töne effektiver bzw. überhaupt wiedergeben, die sie mit ihrer eigentlich kleinen Fläche nur schlecht wiedergeben könnte.
Also eher Trööte, am Anfang der kleine Lautsprecher, am Ende die große Öffnung. Man denke einfach an eine Tuba.
Also sehen die quasi so aus wie diese Dinger, die an einem Grammophon dran sind?
zatzen hat geschrieben:MP3 ist ja ähnlich wie JPG eigentlich. Macht ja auch bei JPG Sinn, einen guten Monitor zu haben, trotz mancher geringer Artefakte.
Naja, was ich meine ist, daß MP3 (und MP2/MPG) ja quasi die Qualität reduziert - und eigentlich AUSSCHLIEßLICH dafür gedacht ist, Speicherplatz zu sparen. Niemand benutzt MP3, damit es besser klingt. Den besten (digitalen) Klang erreicht man mit ungepacktem WAV.

Das Prinzip von MPG (und nachfolgenden) basiert ja darauf, Dinge wegzulassen, die man nicht bewußt hört - nur so ist das "Packen" (bzw die Reduktion der Größe auf 1/10) möglich. Es wird quasi alles in einen Haufen von Wellen zerlegt und diese werden vereinfacht und quasi werden, einfach ausgedrückt, nur die "Formelwerte" einer Bildungsformel für diese Wellen gespeichert. Und diese Werte werden eben irgendwie "gerundet/geglättet", um weniger Platz zu brauchen. Und ich weiß auch nicht, wie viele Wellen gleichzeitig ein MP3 nebeneinander macht. Aber das ist auch der Grund, wieso bei jedem Percussion-Schlag die CPU-Auslastung (auf einem 386er/486er) kurz in die Höhe geht: Alles was "Rauschen"/"Noise" braucht, kann mit Sinuswellen schlechter abgebildet werden und braucht mehr Daten.
zatzen hat geschrieben:Der Unterschied von kleinen Lautsprechern vs. guten großen zeichnet sich für mein Empfinden vielmehr in der Deutlichkeit und Differenziertheit des Klangs ab, die einzelnen Elemente sind bei letzteren viel besser auseinanderzuhalten und auch "Unschönheiten" viel besser rauszuhören.
Ja, ich weiß - und deshalb meine Bemerkung mit MP3: Wenn diese Dinge sowieso "rausgerechnet" werden, brauchts vielleicht dafür auch keine entsprechend qualitativen Lautsprecher mehr.

Aber, wie gesagt: Mich stört es auch nicht, wenn jemand extremen Wert auf guten Sound legt und sich daher hochwertigere Lautsprecher holt (oder baut).
Ich bin, was Bild angeht, ja ähnlich: Heutzutage sagen viele Leute: Wozu CRT, gibt ja TFT, ist flacher und leichter. Aber ich (im Gegensatz zu "Windowsern") arbeite gern mit verschiedenen Bildauflösungen (Windowser nutzen ja nur die maximale, bzw. "native" auflösung ihres TFT).

Und bei allen Auflösungen, die geringer/anders sind als die native des TFT (d.h. die identisch mit seiner Pixelauflösung sind), sieht das Bild einfach mal SCHEIßE aus: Entweder er verkleinert das Bild zentriert in die Bildmitte (um nur ganzzahlige Pixel-Teiler zu haben) oder er streckt das Bild und dann sind die Pixel unregelmäßig breit/hoch bei nicht ganzzahligen Teilern oder er streckt das Bild und interpoliert die Pixel (dann sieht es verwaschen und schwammig aus). Und selbst bei ganzzahligen Teilern wirkt auf einem hochauflösenden TFT dann eine niedrige Auflösung klotzig, weil es keine Pixel, sondern scharf abgegrenzte Quadrate sind.

All diese Argumente sind den Leuten aber egal - man wird für seine Rückständigkeit ausgelacht, wenn man noch Kathodenstrahlröhren-Monitore benutzt.

Das Gleiche mit Touchscreens: Der 8-Bit-Guy hat neulich mal das Gleiche gesagt, was ich auch dazu immer sage: Er spielt lieber auf einem alten Handheld, als auf einem Smartphone.

Abgesehen davon, daß Spiele, die mit etwas Herumwischen/Herumdrücken aufm Bild meist eher simpel sind (gibt ein paar Ausnahmen), kommen folgende Dinge hinzu:

Man hat keine richtigen Knöpfe - d.h. es gibt keine taktile Wahrnehmung, ob man bedient hat oder nicht. Und: Man kann nicht "blind" die "Knöpfe" drücken, weil ja alles eine homogene glatte Fläche ist, muß also immer gucken, wo man drückt. OK, da guckt man ja sowieso - drittes Problem: Der Bildschirm, der zur Anzeige dient, ist gleichzeitig Bedienfeld, d.h. es sind immer Teile der Anzeige durch Finger verdeckt. Und das vierte, eher physikalische: Früher hieß es immer: "Nicht auf die Fensterscheibe/Bildschirm fassen, das gibt eklige Schmierschlieren." - Scheint heute keinen mehr zu jucken, daß der Anzeigebildschirm aussieht als hätte man sein Butterbrot drauf geschmiert...

Mein persönliches Argument, das nicht nur gegen Smartphones, sondern "Händies" allgemein spricht: Man hat quasi ständig einen mobilen Transponder, also Sender am Körper, der die Position durchfunkt. Da muß ich immer an den Film "Demolition Man" denken, wo man in der Zukunft allen Leuten ins Handgelenk einen Sender implantiert hat, damit die Leute jederzeit aufgefunden werden können. Und Phoenix oder so (der von Wesney Snipes gespielte "Bösewicht") war ja ausgebrochen und hatte keinen so Sender. Und als die Polizei da dann überlegte: "Ohne Sender? Wie konnte die Polizei nur früher Leute finden?", hat der Demolition Man (Sylvester Stallone) gesagt: "Na, wie schon? Sie haben gearbeitet. Sollten Sie vielleicht auch mal versuchen. Ich jedenfalls finde diese faschistische Scheiße zum Kotzen!"

Tja, und heute trägt jeder freiwillig so ein Ding mit sich rum - Implantation nicht nötig: reicht ja, wenn man Dummheit ins Gehirn implantiert, dann braucht's keinen Zwang von außen mehr...

Und all solche Argumente prallen auch an Leuten ab. Ich hab's da inzwischen aufgegeben, irgendwen von irgendwas überzeugen zu wollen. Das funktioniert sowieso nicht.

Bis heute kann ich z.B. Windows nicht ernstnehmen (und wundere mich immer noch, daß es überhaupt jemand ernstnimmt). Man muß es zwar benutzen, weil Webseiten derart Javaskript (und ähnliches) verseucht sind, daß alte Browser da kaum noch etwas darstellen können, aber von MÖGEN bin ich weit entfernt. Und wenn dann einer kommt mit "Nimm doch Linux"... naja - Linux macht das, was ich schon an Windows nicht leiden kann, noch mehr: Alle Zugriffe indirekt über etliche Abstraktionsstufen - das macht alles mit allem kompatibel. Aber es macht es auch lahm.
zatzen hat geschrieben:Kommen wir mal zu einer Überlegung, die ich bisher kaum näher verfolgte, aber ich habe in letzter Zeit öfters davon (nachts) geträumt, dass ich mit nem eigenen (ZSM) Tracker Musik gemacht hätte und das wäre ganz toll gewesen. Der Tracker war bunti (320x200x256) aber nicht klicki. Ungeachtet der Tatsache, dass es rein pragmatisch wenig Sinn macht, da ich auch einfach in X-Tracker was erstellen und dann konvertieren kann, mal folgende Überlegungen:

- Ich müsste entweder XMS oder einen "pagefile" benutzen. Gründe: Selbst bei interner leichter Kompression der Patterns wäre die eigentliche Stärke von ZSM, ca. 500 Patterns halten zu können, nicht machbar. Ist klar, man wird allemal nur 50 brauchen, aber es geht ums technische Prinzip.
Ja, so teilweises Auslagern (XMS, Festplatte) wäre hier wohl die Idee. Aber ich persönlich bin ja immer der Meinung, daß man, wenn man Dinge wesentlich größer dimensioniert als man sie braucht, genau immer die Fehler macht, die Microsoft macht: Alles wird ein Performance-/Speicherfresser, auch wenn es gar nicht nötig wäre, nur für eine theoretische Möglichkeit, "herumzuaasen". Wenn man schon ein Tool baut, das man vorrangig selbst benutzen will und nicht einmal selbst die Disziplin haben will, sich irgendwo auf ein vernünftiges Maß einzuschränken, braucht man sich auch nicht zu wundern, wenn alles so ausufert.

Ich weiß, daß "aus dem Vollen schöpfen" immer schön klingt. Meiner Erfahrung nach kommt man damit irgendwann an gewisse Grenzen, wenn man "alles auf einmal" will - und hat dann nachher seine liebe Not, an allen Ecken das Programm/die Daten zu beschneiden.

Ich sag's mal so: Geht alles - auf GHz-Maschinen mit GB-Speicher und TB-Platten. Das hat aber nichts mehr mit DOS zu tun...
zatzen hat geschrieben:Weiterhin ist auch die dynamische Verwaltung der Samples mit Problemen verbunden, zudem brauche ich Headroom für Funktionen wie Importieren von WAV zu 4 Bit Delta.
Naja - genau das wäre ja die Kunst, die disziplinierte Coder von Speicherschluderern unterscheidet.
Gerade letztens ist bei mir ein Ding fertig geworden, das ein SKRIPT ist (ja, ich weiß: Skript - IGITT!) Das Ding soll dazu dienen, Menüs und ähnliches nachladbar zu machen, d.h. der "Code" dafür ist in diesem Skript gemacht. Es gibt Variablen, sowohl interne als auch externe. Externe Variablen (mehrere Typen) haben, simpel ausgedrückt, einen Pointer und noch Daten zur Größe/Typ usw. D.h. man kann von dem Skript aus auf jede Variable/Speicherstelle zugreifen. Ebenfalls hat es Labels (für Sprünge) und alle Parameter können auch als Formel dargestellt werden, die Operationen, Funktionen, Konstanten und eben Variablen enthalten. Man kann einen Befehl entweder "intern" benutzen (gibt schon ein paar einprogrammierte z.B. für die Sprünge oder Variablenzuweisungen) oder direkt auf eine Pascal-Procedure verweisen und ihr die Parameter als Werte übergeben.

Der Skriptinterpreter/Ausführer ist in 100% Assembler - und, klar, das performt dann nicht so wie ein direktes Programm und braucht ja eben den Skriptinterprester. Aber es ist ja auch nicht dazu gedacht, damit ein Spiel zu schreiben, sondern nachladbare Programmteile zu haben, die man nur so lange im Speicher halten muß, wie sie gebraucht werden und die trotzdem unabhängig vom Hauptprogramm entwickelt/geändert werden können.

Etwas ähnliches - damals war der Interpreter aber noch in Pascal geschrieben - wird in den ganzen Menüs von Xpyderz benutzt und mein erster externer Skriptinterpreter, der sowas tut, war ebenfalls noch in Pascal (der wird in TheGame3, meinem Level/Sprite-Editor benutzt).

Jedenfalls ist der Sinn des Ganzen, ein Programm mit beliebig vielen Funktionen haben zu können, das trotzdem noch genügend Platz für die eigentlichen Daten übrigläßt, weil jede Funktion nur so lange im Speicher ist, wie sie gebraucht wird.

Vor einer Weile habe ich auch mal eine (eigentlich 4) ultraschnelle (ebenfalls 100% Assembler) Routine geschrieben, die sowohl für MCGA als auch für Mode-X Texte eines 4x8-Pixel Zeichensatzes ausgibt und auch eine - ebenfalls schnelle (100% Assembler), die mein spezielles Zeichensatzformat für Proportionalschrift benutzt, für Zeichensätze bis 32 Pixeln Höhe - allerdings skalierbar und optional mit Funktionen Fett, Kursiv, Unterstrichen, Invers, usw.

Das, in Kombination mit den anderen Funktionen, die ich da schon habe, könnte benutzt werden, um eine generalisierte 320x200x256 (bzw auch Mode-X-Auflösungen) GUI zu bauen...

Daran mußte ich so denken, als Du von Deinem Traum geschrieben hast.
zatzen hat geschrieben:Letzlich würde ich lieber eine Auslagerungdatei und nicht XMS benutzen, Patterns würde ich somit daraus laden und drin speichern, fragt sich nur ob das schnell genug ist, es müsste ja innerhalb einer Pufferzeit geseekt und geblockloadet werden, und je nachdem entpackt - aber das zeilenweise, mal sehen.
Naja, bei Tools sehe ich die Benutzung von XMS nicht so kritisch an wie bei Spielen. Wenn man sich selber Tools schreibt, können die ja so viel Speicher benutzen, wie in die Maschine eingebaut ist. Bei Spielen will man ja vielleicht auch, daß jemand anders sie benutzen kann - und es können umso mehr Leute ein Spiel benutzen, je geringer die Systemanforderungen (was ja Speicherbedarf einschließt) sind.

XMS (Himem.Sys) hat ja das "Problem", daß es darauf angewiesen ist, wie schnell die Hardware da umkopiert. - Das ist der Grund, wieso ich es ungern bei irgend etwas benutzen will, was vielleicht 50x pro Sekunde passieren soll. Bei einem Entwickler-Tool dagegen ist Echtzeitausführung ja nicht unbedingt ein Muß - da ist es wichtiger, daß einem möglichst viele Optionen offenstehen.

Das ist so meine Meinung dazu.
zatzen hat geschrieben:- Da bei ZSM die Samples beschnitten werden, d.h. nur so viel gespeichert wird wie wirklich abgespielt wird, was nur an einem fertigen Modul entschieden werden kann, liegt es nahe, intern ein anderes Format zu verwenden, und dann für ZSM eine Exportierfunktion zu integrieren, oder einfach einen Converter beizulegen. Ein internes Format mit ungekürzten 8 Bit Samples hätte immerhin den Vorteil, dass man die Stücke dann auch ohne Verlust in den Samples in andere Formate wie DMF oder MOD exportieren könnte um sie evtl. weiter zu bearbeiten.
Naja, auch in MOD wird vom Sample ja nur so viel abgespielt, wie gebraucht wird. D.h. auch dort würde es kein Problem machen, wenn die Samples entsprechend beschnitten wären. Es gibt ja keine "Standard-Samplegröße" - es ist dann einfach ein kürzeres Sample. Das Problem ergäbe sich nur bei einer nachfolgenden Bearbeitung, bei der ein Ton vielleicht verlängert werden soll - aber dieses Problem hätte man ja auch bei ZSM. Man kann nur Daten benutzen, die vorhanden sind.

Und, da gebe ich Dir recht: Bei so gepackten Formaten, die nicht nur "Packformat für ein anderes Ausgangsformat" sein sollen (wie z.B. MOD), also nicht nur konvertiert, sondern auch selbst erstellt werden sollen, würde es natürlich Sinn machen, entweder ein "Source-Format" dazu zu entwickeln, ODER einen "Rück-Konverter" einzubauen, das das gepackte Format (ZSM) in ein "editierbares" überführt - weil das Editieren in den komprimierten Daten wohl unmöglich wäre.

AtavISM hat da einen ganz eigenen Weg: Die Daten liegen im Speicher weiterhin die ganze Zeit im ISM-Format vor und nur das aktuelle "Pattern" wird jeweils "live" in ein Pattern-Format überführt und wieder zurückgeführt in ISM. Da ist intern eine ziemliche "Maschine" dahinter, die das alles zurechtmurkst, damit der Bediener nichts davon merkt, d.h. hier gibt es wirklich KEIN Source-Format. - Allerdings ist ISM ja auch nicht wirklich "gepackt" - eine eventuelle Speicherersparnis ergibt sich nur deshalb, weil die Daten statt in einer Patternstruktur in einer eher "Programmcode"-artigen Struktur vorliegen (Schleifen, Sprünge, Countdownwerte statt "Auslassen" usw.) Das bißchen "Packen", was ISM macht, passiert nur (optional) beim Speichern, wo gleiche Abfolgen von Befehlen zusammengefaßt werden - also simples Lauflängen-Packen, auf Word-Werte bezogen.
zatzen hat geschrieben:Tja, ein solcher Tracker wäre herzlich un-innovativ, aber vielleicht doch ganz reizvoll, aufgrund der Einfachheit, und der Garantie, dass darin gemachte Musikstücke 100% ZSM kompatibel wären, auch mit Vorschaumöglichkeit des Klangs von 4 Bit Delta. Und ich hätte meinen ersten eigenen Sample-Tracker.
Wäre natürlich cool. Aber da bin ich auch vorbelastet, weil ich es generell cool finde, wenn jemand etwas selbst programmiert.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Nur, ein einzelnes Mono-8-Bit-22-kHz Sample braucht für 1 Sekunde nunmal auch 22 kByte RAM. Allein 3 solcher Samples füllen schon ein komplettes Segment!
Ist klar, dass ich da wieder einsteige: Man kommt mit 16 kHz bis auf ganz höhenlastige Sachen wie Rasseln oder sowas sehr gut hin, das ist schon sehr gute Qualität. Wenn man bedenkt dass für Samples wie Bass 8 kHz reichen und sagen wir im Schnitt haben wir 12 kHz, was auch für Sprache hinreichend ist in einem Spiel, dann kommen wir bei 4 Bit Delta auf 6000 Byte pro Sekunde, und damit auf knapp 11 Sekunden pro Segment.
Naja, ich meinte damit ja etwas anderes:
Wenn die Ausgangsdaten nicht 22 kHz sind, sondern vielleicht nur 16 kHz, dann erreicht man, wenn man den Soundblaster auf 22 kHz einstellt, genau die gleiche Qualität wie wenn man ihn auf 16 kHz einstellt. D.h. eigentlich muß man bei der Soundausgabe nur die maximale Frequenz benutzen, die das höchst-aufgelöste Sample hat - denn besser wird's nicht.

Und andersrum ausgedrückt: Wenn man denn 44 kHz Soundqualität haben will, wird man die kaum erreichen, wenn die Samples selbst keine 44 kHz haben - das nachträgliche "Aufblasen" durch Mehrmalsspielen des gleichen Frames (z.B. 4x das Frame spielen bei einem 11 kHz-Sample) erhöht nicht die Qualität.
zatzen hat geschrieben:Ja, das ist irgendwie gemogelt mit der Kompression, aber so auch mit der Grafik, bei Deiner Problematisierung des Speichers erscheint es mir langsam wirklich sinnvoll, ernsthaft an soetwas wie ZVID2 weiterzumachen.
Naja, wie Du schon sagtest: Ich sehe das mit der Speicherauslastung vielleicht zu pessimistisch, weil Du ja auch Kotzman II mit nur 1 Segment hinbekommen hast.

Ich bin dabei nicht davon ausgegangen, wie jemand generell ein Spiel macht, sondern davon, wie mein SLOT aufgebaut ist. Das Ding braucht natürlich auch Speicher für die ganzen Programmroutinen. Man darf ja nicht vergessen, daß wir aufm PC mit einer "Von-Neumann-Architektur" arbeiten: Programmcode und Daten benutzen den gleichen RAM. Darauf versuche ich immer wieder direkt und indirekt hinzuweisen. Beispiel: Wenn man supergepackte Daten hat, aber die Entpackroutine so aufwendig ist, daß sie größer ist als die Daten wenn sie entpackt wären, ist es eine Überlegung wert, entweder nicht ganz so "super" zu packen (und damit die Packroutine zu verkleinern) oder sogar schlimmstenfalls ganz aufs Packen zu verzichten. Wenn also das Packen am Ende gar keine Speicherersparnis bringt (weil die Entpackroutine ja auch im Speicher liegen muß) und zusätzlich Performance kostet (weil Entpacken ja auch Rechenzeit braucht), muß man am Ende abwägen, wie sehr das nützt.

Und meine Programmroutinen brauchen eben auch Speicher: Die Steuerroutine (GameSys2) braucht ca. 21 kByte Speicher, das ISM (ohne die Laderoutinen!) braucht 10 oder 11 kByte. Die Grafikroutinen habe ich nicht ausgemessen, aber das wird wohl auch im zweistelligen kByte-Bereich sein.

Und naja - Sprites und Grafik selbst sind natürlich ein Speicherfresser par excellence. Und je mehr man hier bastelt, um das Einzugrenzen, umso mehr und aufwendigere (ebenfalls Speicher - und Rechenzeit - brauchende) Routinen werden gebraucht, um dann auf diese Daten zuzugreifen.

Das ist der Grund, wieso ich da so pessimistisch rangehe. So eine DOS-Maschine hat nun mal auch Grenzen in der Leistung UND beim Speicher. Ich weiß z.B. immer noch nicht, wo Du Deine Sounddaten erzeugst. Ich meine damit: Wenn die Blaster einen IRQ wirft ("Daten alle") und Du neue Daten in den Sound-Doublebuffer generierst, wo passiert das? Wird das gleich im IRQ gemacht, d.h. in der ISR oder im Hauptprogramm?

Ich selbst traue mich z.B. nicht, Dinge die verhältnismäßig viel Zeit brauchen, im IRQ auszuführen, deshalb haben bei mir die IRQs eher Signalfunktion und Umschaltfunktion und alles, was "generiert" werden muß, wird in der Hauptschleife aufgerufen, wenn signalisiert wurde, daß neue Daten (Grafik, Sound) gebraucht werden. Der Nachteil meiner Methode ist, daß ein Soundpuffer mindestens so lange "durchhalten" muß, wie ich maximal für das Erzeugen EINES Grafikframes brauche (das braucht die meiste Zeit). Habe auch schon für Sound an Triple-Buffering (statt Double) gedacht, aber je mehr "Vorlauf" man dem Sound gibt, umso unsynchroner wird er ja. Das ist bei Musik ja egal, weil die sowieso nur begleitet - aber die Soundeffekte sollten ja trotzdem noch einigermaßen zusammen mit den zugehörigen Aktionen kommen.

Eine andere Möglichkeit wäre, für das Ding quasi Multitasking zu bauen: Jeder Teil hat einen eigenen Stack, auf den auch immer alle Registerinhalte geworfen werden und der Ticker führt "im Kreis" alles aus, d.h. unterbricht eine Routine, schreibt aufn Stack, wechselt zum Stack der nächsten Routine, holt alles und springt zurück. Auf diese Art könnte jede Routine von jeder unterbrochen werden und man hätte das perfekte Timing.

Ich hatte schon wirklich darüber nachgedacht, das so zu machen - allerdings klingt das in der Theorie einfacher als es die Umsetzung in der Praxis ist. Und bestimmte Zugriffe müßte man dann vor Unterbrechungen schützen, weil z.B. manche aufeinanderfolgende Portzugriffe es nicht mögen, wenn da zwischendurch jemand anders reingrätscht, der vielleicht andere Portzugriffe macht... Ich frage mich manchmal sowieso, wie ein PC überhaupt funktionieren kann bei diesem ganzen Chaos...
zatzen hat geschrieben:Notfalls mache ich vielleicht doch etwas in Richtung Adventure, wo es nicht auf hohe Framerates ankommt.
Ach, ein Adventure zu machen, würde ich nicht als "notfalls" und "Notlösung" bezeichnen. Adventures sind toll. Habe ich auch schon selbst Ideen für einige Adventures. Wenn ich diesen Job nicht hätte und nicht immer so müde wäre (keine Ahnung, woran das liegt - vielleicht das Alter), hätte ich schon lange etwas in der Richtung gemacht.
zatzen hat geschrieben:Oder man ermutigt sich wieder einmal angesichts Jump&Runs wie... Captain Comic mit seinen 10 fps und 8 Pixel-Scrolling. Total "outdatet", aber:[...]
So lange es Spaß macht, finde ich solche "technischen Dinge" nebensächlich. Ich bin sowieso der Meinung, daß heutzutage Spiele viel zu sehr nach technischen Dingen als nach Spielideen bewertet werden. Immer die gleiche Spielidee mit immer besserer 3D-Grafik - das wird heute besser bewertet als eine neue Spielidee, die vielleicht zu simple Grafik/Sound hat. Das ist schon schade. Aber das ist eben der Grund, wieso der 'zigste hochauflösende Kriegs-Ego-Shooter gemacht wird...
zatzen hat geschrieben:Sinn macht das Programmieren als Spielwiese für nicht mehr zeitgemäße Ergebnisse und scheinbare sinnlose Datenverarbeitungsverfahren ohnehin, denn gleichermaßen könnte man sagen, die ganze Programmierung für Dos wäre heutzutage sinnfrei. Sieht Du vielleicht anders, weil Du gerade in Dos versuchst, möglichst optimal zu programmieren, so als würde es zu damaligen Zeiten verwendet werden.
Ach naja, ich bin ja kein so Coder-Gott wie vielleicht John Carmack. Das "Optimale" ist es nicht, worum es mir geht, obwohl das natürlich immer erstrebenswert ist. Mir geht es eher darum, daß Speicher und Performance der Maschine auch ausreichen für das was ich da machen will. Und wenn man bei jedem Einzelteil (z.B. eines Spiels) sagen würde: "Macht nichts, wenn's zuviel Speicher braucht und nicht performt", dann funktionieren alle Teile zusammen vielleicht nicht mehr als Spiel.

Früher[tm], als ich vom C64 auf PC kam und gesehen habe, daß der sogar wenn ich in Pascal code mehr performt als auf C64 in Assembler, hatte ich gedacht: Dann kann man ja auch gleich alles in Pascal machen - wozu noch Assembler lernen? Aber dazu muß man sagen, daß ich damals auf C64 in Assembler nicht wirklich gut war, sondern nur so naheliegende Sachen 1:1 in Asm so "umgesetzt" habe wie man sie in BASIC machen würde. Und weiterhin muß man ja sagen, daß der C64 Hardware-Sprites und für Spiele brauchbare Grafikmodes hatte (der Multicolor-Textmode hat ja quasi wie Kacheln funktioniert). Und der Soundchip hat ja alleine losgelegt, sobald man ihm die richtigen Daten gegeben hat. Der PC hat all so etwas ja nicht von sich aus - und da stößt man mit Pascal eben auch an gewisse Grenzen, falls man vorhat, ein nicht ganz so krüppeliges Spiel zu machen.

Naja, wer weiß, ob ich überhaupt noch mal dazu komme, ein Spiel in Angriff zu nehmen. Das bißchen, was ich in letzter Zeit programmiere/entwickle, ist immer noch nur so "Außenherum-Kram". - Ich kann mich einfach nicht dazu durchringen, mit einem Spiel anzufangen, wenn ich immer noch weiß, daß da unfertige Dinge "herumliegen", die ich dann "workarounden" müßte.

Diese blöden Workarounds, die unfertige/unschöne Teile umgehen, brauchen immer Platz und kosten Performance und das Rumgefrickel an den Workarounds, bis sie das machen, was sie sollen, kostet dann immer mehr Zeit als das eigentliche Spiel zu bauen - das minimiert den Spaß und die Kreativität beim Spielebauen enorm.

Xpyderz hat mich ja diesbezüglich sehr desillusioniert. Zu Anfang sah das noch gut aus usw. Und dann kamen viele Dinge dazu, die immer mehr Herumgemurks und "Code um den Code herum" Zeugs erforderten und jetzt kann ich den Kram nicht mehr sehen. Ich spiele das wirklich gerne noch ab und zu. Aber den Programmcode will ich nicht mehr anfassen - und so wird das Spiel wohl auch leider nie vollendet werden. Sollte ich jemals wieder etwas an Xpyderz machen, wird es wohl eher darauf hinauslaufen, daß ich die Grafiken nehme und in SLOT einbaue und den ganzen Rest (Steuerung und endlich auch mal Sound) dann in SLOT mache... Naja, schon wieder dieses Xpyderz... Sollte das nicht so oft erwähnen. Es ist eben meine "Referenz", so wie bei Dir "Kotzman II".
zatzen hat geschrieben:Bei mir haben sich die Hobby-Prioritäten leider anders entwickelt, ich programmiere gerne, nicht zuletzt um etwas zu lernen (besonders in ASM), bin da aber nicht so streng mit mir. Wenn ich Routinen schreibe mache ich das schon möglichst optimal, aber mir fehlt etwas der Atem, um ein Spiel wirklich mit höchster Vernunft und Verzicht auf Spielereien wie ZVID und ZSM aufzuziehen.
Naja, ich programmiere auch gern - nur wird es sehr anstrengend, wenn man so müde ist. Und wenn ich mich nicht richtig konzentrieren kann, kommt auch nichts Gescheites dabei raus. Da weiß ich nicht einmal, an welchem Ende ich anfangen soll und lasse es dann oft ganz sein, um nicht Stunden damit zu verbringen, totalen Bullshit für die Mülltonne zu fabrizieren.

Aber ich programmiere auch nicht "mit höchster Vernunft und Verzicht auf Spielereien". Bei mir ist das eher eine pragmatische Sache: Ich sehe, wie viel Speicher etwas braucht oder sehe, wie sehr etwas performt und dann muß ich ja irgendwie "einschreiten", wenn es nicht mehr paßt. Wenn irgendwann die Steuerung versagt oder der Sound Aussetzer kriegt, auf so ein Spiel hätte ich schon selbst keinen Bock.
zatzen hat geschrieben:Heisst also auch, ich möchte gerne mal meine Formätchen, die etwas Performance zugunsten Speicherplatz opfern, in Action erleben.
Klar - wer will das nicht? Andererseits muß ich auch sagen, daß ich schon oft aufwendig entwickelte Dinge "weggeschmissen" habe, wenn sie am Ende nicht das gemacht haben, was sie sollten - oder wenn sie z.B. selbst mehr Speicher brauchten als sie bei den Daten eingespart haben oder wenn sie so wenig performt haben, daß sie unbenutzbar wurden. Wenn ich an die ganzen Übertragungsprotokolle denke, die ich schon entwickelt und weggeschmissen habe...
Und, wie erwähnt, ist ja auch GameSys2 nicht wirklich die 2., sondern eher schon die 5. Generation...
zatzen hat geschrieben:Das ganze hängt damit zusammen, dass erst die Programmierung in Assembler mir solche eher komplizierten Kompressionsverfahren bei einigermaßen vertretbarer Performance ermöglicht hat, und das ist dann für mich im Moment noch neu und interessant, weil ich zuletzt bei Kotzman II noch kein Assembler konnte. Und nicht-transparente, unkomprimierte Sprites mit PUT setzen war sowas von unspektakulär...
Ja, man wächst mit seinen Aufgaben. Wir beide prokrastinieren hier quasi vor uns hin und halten uns mit "Nebensächlichkeiten" auf, weil wir uns nicht trauen, ein Spiel zu machen - weil wir wohl beide befürchten, daß es ein großer Haufen Mist wird...
zatzen hat geschrieben:Deine auführliche Abhandlung über die Anforderungen eines Spiels wirken etwas pessimistisch. Ich habe nur die Erfahrung dass ich bei Kotzman II mit nur einem(!) Datensegment immerhin etwas vorzeigbares hinbekommen habe.
Ja, wie schon oben erwähnt, bezog ich mich da eher auf MEINE Routinen. Damit ich auch mal mehrere meiner Spielideen umsetzen kann und nicht bei jedem quasi wieder "bei Null anfangen" muß, will ich eben gern etwas haben, das bestimmte Dinge generalisiert und abstrahiert. Das widerspricht zwar teilweise meiner Einstellung (so systemnah wie möglich), dem versuche ich aber durch Performance (durch 100% Assembler für diese Routinen) entgegenzuwirken.

Ich denke dabei so: Wenn sowieso viele meiner Spielideen mit gekachelten 2D-Levels, Sprites und Chiptune-Sound umsetzbar sind, dann macht es schon Sinn, die Routinen, die man dafür braucht, nicht jedesmal neu zu coden - und auch im Vorfeld schon quasi einen "Rahmen" zu haben, in dem ich testen kann, ob der ganze Kram auch wie gewünscht zusammenarbeitet - und zwar, BEVOR ich einen Haufen Mühe in Grafiken, Musiken u.ä. stecke, die ich dann nie benutzen kann, weil die technische Seite nicht funktioniert.

Das liegt bei mir daran, daß ich früher (leider) genau das gemacht habe: Ich habe schon schöne Grafiken (Sprites usw.) für Spiele erstellt (sowohl auf C64 als auch auf PC), die es dann nie gegeben hat - die Zeit hätte man sich sparen können und da tut es einem dann jedesmal weh um die schöne Idee und das ganze Zeug, wenn es unbenutzt auf irgend einer Diskette oder Festplatte verstaubt, weil man einfach noch nichts hat, wo es benutzt werden kann.
zatzen hat geschrieben:Und mein Ziel ist ja eher nur, daran anzuschliessen, soetwas ähnliches nocheinmal zu machen, nur in jeder Hinsicht, also Grafik, Sound, aber auch Spielgeschehen, etwas erweitert (und dafür die restlichen 7 Segmente zu verwenden...).
Wäre 'ne tolle Idee. Auch das komische "zu Anfang 'n Level laden" usw. war ja immer etwas crazy. Aber von der Spielidee her mag ich das ja. (Mag ja generell diese 2D-Jump'n'runs.)
zatzen hat geschrieben:Deswegen mache ich mir da ersteinmal keine solchen Gedanken.
Ich brauche gar nicht erst versuchen einen "Blockbuster" zu programmieren, die Möglichkeiten von Real-Mode Dos reissen heute keinen mehr vom Hocker, wenn man "fotorealistisches" 3D in Full HD erwartet.
Naja, ich weiß schon seit langer Zeit, daß zwischen Leuten wie Carmack und mir ganze Universen liegen und bin auch nicht so verrückt, zu glauben, daß ich irgendein Spiel machen könnte (egal auf welchem System), das irgendwen von irgendeinem Hocker reißt. Wie Du ja weißt, ist mein Ziel, Spiele in dem Genre wie diese SNES-Spiele zu machen - allerdings ist mir schon klar, daß ich da grafisch und musikmäßig natürlich nicht so talentiert bin wie die professionellen Entwickler.

Natürlich gibt einem dieses Wissen auch eine gewisse "Ruhe": Niemand drängelt einen, wann das Spiel endlich fertig ist, niemand hat auf ein neues "2D-Spiel unter MS-DOS" gewartet. Wahrscheinlich würde man auch mehr Motivation haben, WENN jemand drauf warten würde - dann wüßte man, daß es überhaupt jemanden interessiert, was man da macht und daß es wenigstens schon ein paar Leute gäbe, die das Ding spielen wollen würden. Nur kriegt man heutzutage so etwas viel leichter auch auf seinem SmartPhone - da wartet dann keiner auf ein Spiel für ein obsoletes System, das man auf einem aktuellen System nur mit einem Emulator zum Laufen kriegt, den man auch noch aufwendig konfigurieren muß.
zatzen hat geschrieben:Einfach nur ein kleines nettes liebevoll gestaltetes Spielchen.
Naja, daß man das LIEBEVOLL macht, versteht sich ja wohl von selbst!
zatzen hat geschrieben:Und ob nun ein Spiel auch auf einem 386er statt 486er flüssig laufen würde dürfte auch nur Leute wie Dich und mich im Sinne von Idealismus kümmern, und da kann man selber abwägen wie wichtig einem das ist.
Naja, das Problem ist, daß ich das auch nicht vorher planen kann. Ich kann zwar auf 486er-Opcodes verzichten (was ich auch tue), und habe damit eine "Mindestanforderung 386er", aber das bedeutet ja nicht, daß es auf 386er dann auch ausreichend performt. Wahrscheinlich sind meine ganzen Routinen hier schon "zuviel Geraffel" für 'n 386er. Bekanntermaßen ist ein 486er mit GLEICHER Taktfrequenz mind. doppelt so schnell wie ein 386er. Aber 386er gehen ja nur bis 40 MHz - und mein 486er hier hat 133 MHz und ist zusätzlich noch so ein X5. D.h. man kann davon ausgehen, daß meine Kiste ca. 10x so schnell ist wie der schnellstmögliche 386er. Oder anders ausgedrückt: Wenn ich 50 fps schaffen WÜRDE, dann wären's auf 386er 5 fps! Und das NUR DANN, wenn der 386er auch so eine coole PCI-Grafikkarte mit 16 MB/sek. Durchsatz hat - was er wahrscheinlich nicht hat, schon weil es sein kann, daß auf viele 386er-Motherboards kein PCI draufpaßt...
zatzen hat geschrieben:
DOSferatu hat geschrieben:[...]scheint ja auch die ganze Mühe, die ich in den zweiten, alternativen Editor AtavISM gesteckt habe [...] trotzdem kaum dazu zu geführt zu haben, [...] wirklich zur initialen Entwicklung von Musikstücken verwenden zu wollen/können.
Wenn Du ein Spiel machst, das ISM verwendet, und Du gerne Musik von mir gemacht haben möchtest, dann sollte es klar sein, dass ich dann AtavISM verwende. Genauso ist es aber auch klar, dass ich nicht in AtavISM Musik komponiere, wenn ich den Schwerpunkt auf Samples lege oder das ganze am Ende auf CD-Niveau ausproduzieren möchte.
Ja, schon klar. War auch nur eine Anmerkung. Den "Umbau" auf "Tracker-Ähnlichkeit" und "X-Tracker-Bedienung" habe ich ja hauptsächlich wegen Dir (zatzen) gemacht, weil Du der einzige bist, den das ganze Ding überhaupt wenigstens geringfügig interessiert hat.

Wenn ich Musik mache, muß es ja nicht CD-Niveau sein. Es gibt dermaßen viele Leute, die auf den Chiptune-Sound stehen und die genau diesen "retro-mäßigen" (wie man's heute nennt) Sound mögen. Deshalb fände ich es nicht schlimm, wenn auch heute jemand Musik in diesem Stil machen würde. Ich weiß zwar, daß es damals eher nur aufgrund technischer Beschränkungen so gemacht wurde, aber das ist für mich kein Anlaß, deshalb heute nur noch CD-Quali machen zu müssen. Das ist wie mit 2D-Pixelgrafik vs 3D-Fotorealismus: Kann man machen, muß man aber nicht.
zatzen hat geschrieben:Es ist "schade" dass es nicht so viele Leute gibt, die neue Software wie AtavISM benutzen, genauso würde es mir aber auch mit dem "Zatzen simple Tracker" (s.o.) gehen. Es gibt eben heute massig kostenlose Tracker (sogar schon Online im Browser) und Musikprogramme für Windows, die VST Instrumente und Gigabyte-weise Samples verarbeiten können.
Naja, daß Leute heutzutage kaum noch Tools benutzen, die nur unter DOS (bzw. bis maximal WinXP 32bit) funktionieren, hat ja auch noch andere Gründe...

Was soll jemand schon mit einem Tool, das nur in einem Emulator läuft und viel weniger kann als aktuelle Tools (die keinen Emulator brauchen) - um damit Daten zu machen, die ebenfalls nur mit Zeug in besagtem Emulator funktionieren? Da kann man die Leute schon verstehen, die so etwas nicht brauchen. Andere Leute sind viel praktischer veranlagt - denen geht es nicht um das OS oder die Programmierung dahinter, wo irgend etwas läuft, die sind eher ergebnisorientiert.

Für mich (und Dich wohl auch) gilt eher "Der Weg ist das Ziel" - und daß es einem mehr Wert ist, es selbst gemacht zu haben, auch wenn's nur auf einem System ist, das seit einem Vierteljahrhundert nicht mehr verkauft wird, als vorgefertigte Dinge zu benutzen, von denen man kaum eine vage Ahnung hat, wie sie funktionieren.

Allerdings muß man zugeben, daß ergebnisorientierte Leute einen wesentlich größeren Output an Software haben.
zatzen hat geschrieben:[...]Jedenfalls hat es für mich schon Vorteile wenn ich nicht vorab erstmal alle Samples auf 8 Bit und 11 kHz runterrechnen muss nur um sie am Ende wieder durch 16 Bit 44 kHz auszutauschen.
Naja, wie gesagt: Es muß ja nicht immer Qualität am Anschlag sein.
zatzen hat geschrieben:Vielleicht hast Du diese Videos von mir gesehen, wo das Gesehene dem Ton entspricht, also praktisch Videos als Samples benutzen. Sowas kann Renoise noch nicht, ich hatte das für X-Tracker auch nur selbst programmiert diese Möglichkeit.
Ja, ich weiß.
Naja, im Prinzip hat ISM solche Möglichkeiten, wenn man alle Features ausnutzt und im Prinzip könnte ich das auch in AtavISM als Befehl einbauen. Weil ISM ja eher eine programmartige Struktur hat, kann man da vieles "nachrüsten". Immerhin war AtavISM ja auch nur möglich, weil ISM so flexibel ist. Allerdings ist ISM nie dafür gedacht gewesen, als Video/Audio zu funktionieren, weil es von Anfang an für Spiele gedacht war. Allerdings könnte man natürlich auch nebenher eine Art Video laufen lassen. Wenn Ton und Bild gleich schnell laufen, bedarf es auch keiner Synchronisation zwischen Bild und Ton.
zatzen hat geschrieben:Ich überlege ob ich sowas auch für Renoise mache. Da müsste ich mich durch das in XML gehaltene Dateiformat durchwursteln und quasi einen Renderer schreiben, der Frame-Informationen die parallel in Samples gehalten werden entsprechend zurechtrechnet.
Auch ein Zeichen der Zeit, dass die Dateien nicht binär sondern als XML gespeichert werden, also aufgeblasen wie sonst was, naja, damit "menschenlesbar", kann ja auch ganz praktisch sein, 600K hab ich da bei einem kleinen Stück mit 4 Patterns, nur die Definitionen, ohne Samples.
Das liegt nicht daran, daß es menschenlesbar sein soll. Niemand ist so irre, die komplizierten XMLs, die heutzutage von Programmen erzeugt werden, wirklich noch von Hand zu editieren. Der Grund dafür ist schlicht FAULHEIT - weil XML schon quasi als API vom OS angeboten wird und man sich dann kein eigenes Format ausdenken muß. Klar wäre XML dann auch theoretisch kompatibel zu anderen Programmen, die XML benutzen - weil die aber andere Parameter haben, ist es das trotzdem nicht.

Meiner Meinung nach ist XML in jeder Hinsicht "mit Kanonen auf Spatzen geschossen": Es braucht einen umständlichen Parser und ist langsam beim Lesen und dadurch, daß es so ein umständliches Format hat, auch noch fehleranfällig. Da wäre jedes CSV (ebenfalls menschenlesbar, falls es einem darum geht) oder File im INI-Format viel simpler. Aber es ist eben momentane Modeerscheinung. Nehme an, daß Daten und Konfigurationen heutzutage nicht schon in so einem Kram wie PDF gespeichert werden, liegt nur daran, daß man da Lizenzen bezahlen müßte.
zatzen hat geschrieben:Aber so ist es nunmal wenn heute so viel Speicher da ist, vor 30 Jahren waren 20 MB Festplatte viel, heute sind es 2 TB, also Faktor 100.000. Verhältnismäßig wären die 600K dann 6 Byte, was ja ziemlich wenig ist.
Das mag ja sein, aber sinnlos Speicher verschwenden, nur "weil er da ist" (und Performance), ist für mich ein Zeichen von entweder Faulheit oder Blödheit (oder beides).
zatzen hat geschrieben:Und eine Datei mit >4GB ist z.B. oft ein Video. Ich habe in letzter Zeit einige Videos von einer (auch heute längst veralteten) Digital8 Kamera im DV Format auf eine externe Festplatte überspielt. Eine Minute braucht ca. 180 MB.
Achso, Videos.
zatzen hat geschrieben:Ich könnte mich ja selber über die "Jugend" aufregen dass nur noch in GB gedacht wird und vielleicht kaum noch einer weiss was ein MB oder gar KB ist, und dass man sich übers Smartphone oder email einfach Videos von mehreren MB Größe schickt, während ich mir immer noch Mühe gebe, den Anhang von emails so klein wie möglich zu halten.
Tja, wenn etwas "geht", wird's auch gemacht. Denkst Du, daß so Leute wirklich noch gescheit programmieren würden, für die alles unter GB schon Peanuts sind? Für die Industrie macht das aber nichts: "Kurbelt ja die Wirtschaft an". Solche Leute sind ja quasi die Rechtfertigung dafür, daß immer größere und schnellere Systeme "gebraucht werden".

Das ist doch auch allgemeiner Konsens: Wenn etwas auf einem Computer nicht richtig läuft, sagt heutzutage doch kaum einer "Das Betriebssystem ist beschissen" oder "Das Programm ist zu beschissen programmiert" - sondern immer: "Der Computer ist zu langsam".

Ist ja auch klar, für die heutigen "Coder": Schnelleren Computer bauen müssen ja DIE ANDEREN, gescheit programmieren lernen müßte man ja SELBER...
zatzen hat geschrieben:Aber es ist eben mittlerweile möglich und ich kann selber nicht leugnen dass ich Nutznießer dieser modernen Technologien/Bandbreiten/Kapazitäten bin, nicht zuletzt auch im Audio-Segment, wo 25 Jahre alte Hardware die Arbeit schon etwas bremsen und einschränken und vor allem verkomplizieren würde.
Tja, aber früher haben's die Leute auch gemacht. (Ja ich weiß: Früher gab's auch Plumpsklos und ich bin auch froh, daß ich ein Innenklo mit Wasserspülung habe.)
Was eher stört ist, daß heutzutage das Denken ist: Wenn etwas irgendwie Mühe machen würde, heißt es nicht "da muß man sich die Mühe machen", sondern immer gleich: "geht nicht".

Dinge, die nicht "wie von selbst" und "auf Anhieb" funktionieren, werden als "geht nicht" eingestuft - diese "Instant Gratification"-Mentalität spielt der Industrie aber in die Hände. Und das nimmt man auch gerne so an - denn wer will schon Konsumenten, die zu viel denken?
zatzen hat geschrieben:Ja, kann man alles auch mit MIDI und nem Fuhrpark von Audio-Peripherie am Atari machen. Hab ich aber nie so gemacht sondern seit 1993 alles in einem Computer ohne externe Hardware. Und jetzt geht eben einfach mehr, damals nur rohe MODs mit LoFi 8 Bit Sound, heute uneingeschränkte Qualität und Möglichkeiten.
Ja, wie gesagt... Gibt heutzutage viele Leute, die sagen: 44 / 48 kHz sind zu wenig, und 96 eigentlich auch. Es müssen 192 bzw 384 kHz sein! Und in ein paar Jahren muß 1 Sekunde Sound 1 GB brauchen und 64 Bit, weil da immer noch jemand "hören wird", daß das sonst unzureichend ist.

Selbes Ding mit Grafik: 24Bit (8-8-8) reicht auch nicht mehr aus heutzutage! Es muß 30Bit oder 48Bit oder 96Bit sein! 4,3 Millarden Farbabstufungen für jede Phase! Nicht mal das weitentwickelste TIER-Auge hat so eine Farbabstufung! Aber wenn irgendwer eine klug genug klingende Ausrede dafür hat, dann reicht das aus, um für die Entwicklung solcher Dinge genug Geld in die Industrie zu pumpen. Man muß ja die Wirtschaft ankurbeln. Klar, braucht alles 3x soviel Speicher (wir haben's ja...) und das menschliche Auge sieht nicht mal bei 24bit noch irgendwelche Stufen... - auch wenn mir diverse Spacken immer wieder weismachen wollen, daß es so wäre...

Na egal. In 20 Jahren wird keiner mehr in Einheiten von BYTE irgend etwas angeben. Da wird selbst eine Textseite schon 1 GB brauchen... - nicht, weil es nötig ist, sondern weil die Hersteller von RAM ja auch von irgendwas leben müssen...

Nicht falsch verstehen: Wo etwas wirklich Sinn macht, habe ich kein Problem damit, auch mal an eine Grenze zu gehen (auch wenn es meiner Meinung nach SEHR OFT unnötig ist) - aber bei vielen Dingen macht es selbst heute schon keinen Sinn mehr.
zatzen hat geschrieben:Aber parallel dazu vergesse ich die "alte Zeit" nie und daher habe ich auch Spaß daran, Daten kompakt zu halten im KB Bereich.
Naja, kommt eben auf das System an, auf dem es ausgeführt werden soll. Auf einem durchschnittlichen DOS-Rechner kann man nunmal nicht "mal eben so" davon ausgehen, daß man da 4 GB Speicher eingebaut hat (obwohl für 32bit-CPUs technisch möglich wäre).
zatzen hat geschrieben:ISM:
Vor Clipping habe ich wie hier oft schon erwähnt aufgrund meiner Erfahrung gerade im Lo-Fi Bereich keine Angst, es muss eben nur wirklich geclippt (Pseudo: if a > 127 then a = 127; if a < -128 then a = -128) werden, was einen zweiten Puffer in 16 Bit erfordert...
Naja, bei mir nicht, weil die Werte ja maximal 240 werden. Ich habe ja (vielleicht) schon mal erwähnt, daß ich einen "Overdrive" Wert mit angeben will, damit man die Musik auch über die Grenze aussteuern kann. Dann muß man aber selbst dafür sorgen, daß es nicht kratzt. Clipping auf die oben beschriebene Art verfälscht aber trotzdem die Töne.
zatzen hat geschrieben:Was Du statt Clipping noch machen könntest, wäre eine momentane Verminderung der Lautstärke über die Pufferlänge.
Wie ich schon erwähnt habe: Das möchte ich nicht. Ich möchte die Möglichkeit haben, leise und laute Töne zu haben und nicht, daß ein leiser Part "hochgezogen" oder ein lauter "runter" und alles gleich laut ist.
zatzen hat geschrieben:und würde statt Verzerrung eher "pumpen" verursachen, wenn's zu laut wird.
Und genau das soll's nicht.
zatzen hat geschrieben:Ich erinnere mich dass Du die Daten vorzeichenlos verarbeitest. Muss man dann evtl. anders rangehen.
1. Ich möchte nicht anders rangehen.
2. Ich verarbeite zuerst alles vorzeichenlos - dann - über die Lautstärketabellen - wird es vorzeichenbehaftet, damit es eine "Mitte" gibt. Am Schluß wird über das komplette Stück eine Fixierung angewendet (ebenfalls per Tabelle, die nur angepaßt wird, wenn sich Gesamtlautstärke oder Anzahl Stimmen ändert), die gleichzeitig die Werte "maximiert" und auf Mitte stellt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Naja, kein Fan von Windows zu sein, muß ja nicht bedeuten, daß man auf NOCH lahmeren Scheiß wie Mac oder NOCH benutzerunfreundlicheren Scheiß wie Linux steht...
Das ist mal eine erfrischende Sichtweise!
Naja...
zatzen hat geschrieben:Im Audio Bereich schwören alle auf Mac, und alle vermeintlichen Freaks die was auf sich halten machen alles mit Linux. Das hatte mich als Microsoft USER schon leicht verunsichert...
Naja, was soll man sagen? Vielleicht gibt es da irgend ein Programm unter Linux, das alle so toll finden? Keine Ahnung. Die meisten Leute, die auf irgend ein OS "schwören", haben sowieso keine Ahnung, wie das Ding technisch funktioniert und was die Vorzüge und Nachteile sind. Ich kenne mich z.B. viel zu wenig mit den Interna von Linux aus, um es deswegen zu mögen oder zu hassen - weil ich mich nie damit beschäftigt habe,

Für mich kommt Linux nicht in Frage, weil mein eigener Scheiß darauf nicht läuft und weil ich einfach zu alt bin, jetzt noch mal einen komplett neuen Ansatz zu fahren. Das was die OS heutzutage machen, nimmt sich - für den User - sowieso nicht mehr viel. Es geht eher nur noch um das "Drumherum". Linux ist mir einfach zu stressig.

Erklärung: Mir sind Betriebssysteme total egal. Ich bin auch kein DOS-Fan (auch wenn's so wirkt). Ein Betriebssystem soll mich einfach so weit wie möglich in Ruhe lassen und so wenig wie möglich nerven. Ich habe keine Lust, großartig an einem OS herumzukonfigurieren (dafür interessiert's mich zu wenig). Betriebssysteme erachte ich als "notwendiges Übel" und je weniger davon da ist, umso genehmer ist es mir.

Leider nehmen sich ALLE Betriebssysteme heutzutage zu wichtig und wollen den User immer nur gängeln - ist wohl leider eine Notwendigkeit, wenn man Multitasking will.

Aber, wie erwähnt: Der Grund für mich, den Kram von MS zu benutzen ist, weil der bis zu einem bestimmten Punkt noch Ähnlichkeiten/Kompatibilität zu dem hat, mit dem ich mein Zeug programmiere. Unter Linux (und anderen) könnte ich nur dummer User sein. Das wäre mir zu blöd.
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 »

DOSferatu hat geschrieben:Früher, mit 16, konnte ich, sozusagen "die Flöhe husten hören": Wenn in einem Raum ein Röhrenfernseher an war, konnte ich das hören - an diesem 15 kHz "Pfeifen". Heutzutage, in der Firma (Großraumbüro), lausche ich auf alles, was phonetisch so ähnlich klingt wie mein Name, damit es nicht heißt, ich reagiere nicht, wenn ich angesprochen werde. Meinst Du wirklich, daß es sich da noch lohnt, mannshohe Boxen mit kristallklarem Sound anzuschaffen?
Geht mir ähnlich. Ich höre heute auch keine 15 kHz mehr, aber selbst wenn ich mal Ü-60 bin und dann Glück habe wenn meine obere Grenzfrequenz noch bei 8 kHz liegt, lohnen sich gute Lautsprecher trotzdem, es geht ja nicht bloß um die ganz oberen Tönchen. Aber schon okay, ich war früher auch mit meinem Ghettoblaster zufrieden, der Anspruch kam einfach durch das Produzieren, Mischen und Mastern von Musik, was das Gehör sensibilisiert hat. Der Grund warum ich das jedem aufschwatzen will ist, dass es einfach ein unheimlicher Genuss ist, Musik aus richtig guten Lautsprechern zu hören, auf den ich nicht mehr verzichten möchte. Ich bin also begeistert, und möchte das anderen zuteil werden lassen.
Nebenbei: Die meisten "audiophilen" Leute sind alte Kerle, eben weil sie erst im Laufe des
Lebens herausgefunden haben, was wirklich guter Klang ist. Aber darunter gibt es auch Spinner...
DOSferatu hat geschrieben:Und im Gegensatz zu Dir lege ich nicht SO einen Wert auf Kristallsound. MIr reicht die Qualität aus, die meine Lautsprecher produzieren[...]
"Kristallsound", naja, es soll möglichst realistisch klingen, damit ich beim Abmischen und Mastern sofort merke, ob es gut oder nicht oder eben so klingt wie es sein soll. Ich könnte das auf kleinen Schreibtischlautsprechern nicht beurteilen.
DOSferatu hat geschrieben:[Hörner]Also sehen die quasi so aus wie diese Dinger, die an einem Grammophon dran sind?
Rein Prinzipiell ja, allerdings gibt es mannigfaltige Bauformen. Das Prinzip ist aber immer, dass sie sich von einer kleinen Fläche (dort sitzt der Lautsprecher) zu einer großen Fläche hin erweitern. Im PA-Bereich sind sie meist nicht rund sondern rechteckig, und im Bassbereich meistens gefaltet, weil es sonst z.B. 2 Meter tiefe Kisten wären.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Der Unterschied von kleinen Lautsprechern vs. guten großen zeichnet sich für mein Empfinden vielmehr in der Deutlichkeit und Differenziertheit des Klangs ab, die einzelnen Elemente sind bei letzteren viel besser auseinanderzuhalten und auch "Unschönheiten" viel besser rauszuhören.
Ja, ich weiß - und deshalb meine Bemerkung mit MP3: Wenn diese Dinge sowieso "rausgerechnet" werden, brauchts vielleicht dafür auch keine entsprechend qualitativen Lautsprecher mehr.
Lautsprecher sind immer das schwächste Glied in der Kette. Selbst wenn es hörbare MP3 Artefakte gibt, reissen schlechte Lautsprecher den Gesamt-Höreindruck noch einmal viel weiter runter. Sicherlich, wenn es nur irgendwie grob aus den Lautsprechern blökt hört man vielleicht bei keinem MP3 Artefakte.

Übrigens, kleine Geschichte der Hornlautsprecher: das Hornprinzip ist uralt, und wir alle tragen es gewissermaßen in uns, ohne den Hals der sich zum Mund hin aufweitet hätten wir nur seeehr leise und dünne Stimmen. Wie Du selber schon erwähntest, gab es neben klassischen Instrumenten wie Trompeten oder Tubas auch irgendwann das Grammophon, wo die rein mechanischen Schwingungen am Tonabnehmer durch einen Trichter hörbar gemacht wurden. Bald kamen die ersten Röhrenverstärker mit einer Leistung von vielleicht einem Watt. Man hatte nun elektrische Lautsprecher, machte aber noch ein Horn dran, damit es brauchbar laut war. Über die Jahrzehnte entwickelten sich die Verstärker weiter und wurden leistungsstärker, was die Nutzung von Hörnern zur Wirkungsgradsteigerung obsolet machte. Eine Renaissance hatten Hörner etwa in den 70er/80er Jahren in Discotheken oder Konzerten etwa, weil man damit mächtig Krach machen konnte mit nur ein paar hundert Watt. Mittlerweile sind Verstärker mit hoher Leistung aber immer billiger geworen, und gleichzeitig werden Lautsprecher gebaut, die immer mehr Leistung verkraften, so dass man wieder mehr auf Leistung setzt und weniger auf Wirkungsgrad, denn Hörner sind im Bassbereich sehr groß, und das hat man nicht gerne, man setzt da lieber auf Bassreflex. Trotzdem gibt es immer noch Hersteller die auf Horntechnologie setzen und damit sehr beliebt sind, es hat unbestreitbar klangliche Vorzüge.

Aber das hat mit Spielen nicht viel zu tun und gehört alles nicht hier her in die Kategorie "Programmieren", also lass ich das Thema mal sein.


AdLib: Ich habe mich tatsächlich zwischendurch auch mal gefragt, warum Du nicht einfach ein Musikprogramm für die AdLib machst. Quasi null Prozessorbelastung, und FM Synths können ja durchaus lebhafter oder organischer klingen als additive Synthese. Aber mit einem eigenen Synth bist Du natürlich unabhängig von der AdLib und bringst einen neuartigen Sound den nicht jedes Spiel hat.

Bildschirme: Da nutze ich im Moment einen 32" LED 16:9 Fernseher. 1920x1080. Grund war vor allem, damit man bei der Soundbearbeitung mehr Plugin-GUIs auf einmal sehen kann. Tatsächlich nutze ich nur die native Auflösung, da reines Dos auf Windows 7 ja gar nicht mehr läuft. Dosbox Textmodus oder 320x200 sieht im Vollbild für meinen Geschmack trotzdem gut aus. Eher noch schärfer als auf dem 14" CRT den ich früher hatte. Bei dem konnte man ab 640x??? keine Pixel mehr erkennen, und der Textmodus sah auch absolut glatt aus.
CRT's haben sicherlich unbestreitbare Vorteile, sind anders in der Bildqualität, auch was die Farben oder die Gradienten betrifft. Zu Zeiten als wir Jungs uns noch zu Netzwerktreffen versammelt haben waren TFTs aber ein Segen, wesentlich weniger zu schleppen... Zuletzt hatte ich einen 17" Eizo CRT.

Mein Problem mit Smartphones ist, dass ich etwas zitterig bin und ständig einen Buchstaben doppelt eintippen würde, ähnlich unsicher würde ich mich bei der allgemeinen Bedienung fühlen. Ich will das Prinzip generell nicht verteufeln, aber irgendwie vermisse ich nicht wirklich was ohne, immerhin sind meine Möglichkeiten (für das was ICH machen will) am richtigen PC doch weitaus größer. Ich habe ein Klapp-Handy, relativ kleines Ding. Damit nur wird telefoniert oder es wird schonmal als MP3 Player benutzt.
Wegen dem ganzen Touchscreen-Dingens (okay auch wegen Bildern angucken) sind die Smartphones alle so groß. Kommt mir manchmal albern vor, dass wir vor 15 Jahren oder so alle ganz kleine Handys hatten und sich jetzt alle doch wieder so einen Badelatschen ans Ohr halten.

Passt hier ganz gut rein: Was für eine Tastatur hast Du? Ich habe mittlerweile eine recht flache, ca. 4 mm dicke Tasten, auch ca. 3-4 mm Federweg. Kamen vor 15 Jahren etwa in Mode. Ich finde damit kann man ziemlich schnell schreiben, macht aber tendentiell mehr Fehler. Zudem konnte man mit einer "dicken" beim Trackern nahezu blind arbeiten, weil die Finger richtig gut ertasten konnten wo man sich befindet. Hast Du noch so eine gute alte Cherry, vergleichbar mit der eines C64?

Ich bin nicht zu sehr besorgt wegen meinem Handy von irgendwem verfolgt zu werden, aber es ist schon irgendwie dreist, wie sehr die Welt darauf ausgelegt wird, dass jeder ein Smartphone hat (haben müsste). Allein der Rückbau von Telefonzellen ist eigentlich ein Unding, musste aber wohl geschehen weil es sich angesichts der Minderheit handyloser Menschen nicht mehr rentiert. Aber es gibt auch andere Dinge, bei denen Smartphone-Besitzer ein klares Privileg genießen.
Aber ich will mal nicht meckern. Leute die mit Computern umgehen können und Internetzugang haben sind auch priviligiert.
DOSferatu hat geschrieben:[Anm. angedachter ZSM-Tracker, Patterns auslagern]Ja, so teilweises Auslagern (XMS, Festplatte) wäre hier wohl die Idee. Aber ich persönlich bin ja immer der Meinung, daß man, wenn man Dinge wesentlich größer dimensioniert als man sie braucht, genau immer die Fehler macht, die Microsoft macht: Alles wird ein Performance-/Speicherfresser, auch wenn es gar nicht nötig wäre, nur für eine theoretische Möglichkeit, "herumzuaasen". Wenn man schon ein Tool baut, das man vorrangig selbst benutzen will und nicht einmal selbst die Disziplin haben will, sich irgendwo auf ein vernünftiges Maß einzuschränken, braucht man sich auch nicht zu wundern, wenn alles so ausufert.
Ich würde schon gern die Möglichkeit zu hunderten Patterns haben. Aber Träume verblassen auch, ich bin nicht mehr unbedingt so motiviert, einen Tracker zu schreiben den sogar ich selbst letztlich kaum benutzen werde denn: X-Tracker bietet alles was ZSM benötigt, auch 1024 Patterns wenn ich nicht irre, und letztlich werden ZSMs ja direkt aus DMFs konvertiert. Ich muss nur auf Effekte verzichten und mir bewusst sein dass Lautstärken nur in den Stufen 255 192 128 96 64 48 32 24 16 12 8 6 4 3 2 1 gehen. Letztlich auch wurscht beim Trackern, weil der ZSM Converter alle Werte zwischen 1 und 255 sinnig auf die exponentiellen 16 rundet.
Vielleicht mach ich den Tracker, wenn ich wirklich mal Lust drauf habe, auch wenn es egal ist ob er benutzt wird oder nicht. Vor über 25 Jahren hätte ich noch eine Chance auf andere Benutzer gehabt, aber jetzt gibt es einfach zu viel Konkurrenz. Da mache ich doch lieber erstmal ein Spiel.
DOSferatu hat geschrieben:Jedenfalls ist der Sinn des Ganzen, ein Programm mit beliebig vielen Funktionen haben zu können, das trotzdem noch genügend Platz für die eigentlichen Daten übrigläßt, weil jede Funktion nur so lange im Speicher ist, wie sie gebraucht wird.
Hört sich gut an. Auf sowas bin ich natürlich noch nicht gekommen, mein Frankus Tracker II hat alle Menüs und Pulldowns etc. "hardcoded".
DOSferatu hat geschrieben:Und, da gebe ich Dir recht: Bei so gepackten Formaten, die nicht nur "Packformat für ein anderes Ausgangsformat" sein sollen (wie z.B. MOD), also nicht nur konvertiert, sondern auch selbst erstellt werden sollen, würde es natürlich Sinn machen, entweder ein "Source-Format" dazu zu entwickeln, ODER einen "Rück-Konverter" einzubauen, das das gepackte Format (ZSM) in ein "editierbares" überführt - weil das Editieren in den komprimierten Daten wohl unmöglich wäre.
ZSM ist ein absolutes Endformat, quasi kompiliert. Samples beschnitten, zu 4 Bit Delta runterkonvertiert und Patterns aufwendig geschrumpft. Die Patterns könnte man verlustfrei entpacken (mache ich ja beim Abspielen und in der neuen Playerversion zeige ich sie auch an), aber die Samples sind unwiederbringlich verstümmelt und datenreduziert. MOD dagegen hat volle 8 Bit in den Samples und ein Komponist (Trackerer) muss die Samples schon selber kürzen wenn er das will. Ein MOD kann man prima jederzeit remixen oder man kann sich vollwertige Samples daraus klauen.
DOSferatu hat geschrieben:AtavISM hat da einen ganz eigenen Weg: Die Daten liegen im Speicher weiterhin die ganze Zeit im ISM-Format vor und nur das aktuelle "Pattern" wird jeweils "live" in ein Pattern-Format überführt und wieder zurückgeführt in ISM. [...] Das bißchen "Packen", was ISM macht, passiert nur (optional) beim Speichern, wo gleiche Abfolgen von Befehlen zusammengefaßt werden - also simples Lauflängen-Packen, auf Word-Werte bezogen.
Ich glaube, X-Tracker packt die Patterns mehr oder weniger in Echtzeit, zumindest während der Bearbeitung, auch ohne dass man speichert. Das erscheint sinnig, weil 32 Kanäle möglich sind mit jeweils Informationen über Samplenummer, Tonhöhe, Lautstärke und 3 gleichzeitig mögliche Effekte + Parameter.
Also PI*Daumen ca. 10 Byte pro Kanal, * 32 = 320 Byte, und das ganze möglich bis 512 Zeilen = 163840 Byte, und dann davon bis 1024 Patterns (-> 160 MB) - wenn man da nicht packt, wo soll das hinführen...
Hin und wieder hat's da schon Datenfehler und Abstürze gegeben wenn man ein Pattern verlängern wollte, nicht ganz ausgegoren, aber man hat es irgendwann im Gefühl, die Bugs zu vermeiden.
DOSferatu hat geschrieben:Wenn die Ausgangsdaten nicht 22 kHz sind, sondern vielleicht nur 16 kHz, dann erreicht man, wenn man den Soundblaster auf 22 kHz einstellt, genau die gleiche Qualität wie wenn man ihn auf 16 kHz einstellt. D.h. eigentlich muß man bei der Soundausgabe nur die maximale Frequenz benutzen, die das höchst-aufgelöste Sample hat - denn besser wird's nicht.
Im Prinzip richtig, aber im konkreten Fall von 16 kHz Sample in 22 kHz reinmischen kann es schnell etwas anders kommen. Dazu muss ich schnell nochmal die Sache mit dem Aliasing bei Sound erklären. Zur sauberen Darstellung einer bestimmten Frequenz benötigt man mindestens eine Samplerate der doppelten Frequenz.
Ansonsten kommt es zu einer Spiegelfrequenz (Aliasing), die sich berechnet aus Abtastrate minus (zu hohe) abzutastende Frequenz.
Okay kann man denken, in einem 16 kHz Sample können nur bis 8 kHz vorkommen, also kein Problem für 22 kHz. Das stimmt im Prinzip auch auch so ohne weiteres. Die Sache ist nur, mein ZSM Player (wie auch der Paula Chip des Amiga) gibt beim Abspielen von Musik, also wenn die Samples in unterschiedlichen Höhen wiedergegeben werden, diese ungefiltert aus. Die Wellenformen sind dann keine glatten, interpolierten Kurven, sondern je nach Klang mehr oder minder stark gestuft, was die Sample-Frequenz selbst hörbar macht. Mischen wir also jetzt 16 kHz in 22 kHz, so entsteht eine Spiegelfrequenz von 22 - 16 = 6 kHz, was sich dann unnötigerweise als Verschlechterung auf das 16 kHz Sample legt, dessen Frequenz, 16 kHz, wir Opas ansonsten gar nicht hören würden.
Hab ich nun ein ganzes "Orchester" in ZSM spielen, wo Samples aller Art und Abtastrate munter umhergemischt werden, dann empfehle ich eben 44 kHz, weil dann diese "Matschereien" weitestgehend ausbleiben. Es klingt dann einfach transparenter und sauberer, weil es (fast) keine Spiegelfrequenzen gibt. Daher gebe ich das als Standard vor, wer es sich aus Performancegründen nicht leisten kann, kann die Mixrate runtersetzen.
Übrigens, auf Grafik übertragen wären diese Spiegelfrequenzen am ehesten mit Moiree Vergleichbar.
Schallwellen sind eben wie eher regelmäßige Muster.
DOSferatu hat geschrieben:Und andersrum ausgedrückt: Wenn man denn 44 kHz Soundqualität haben will, wird man die kaum erreichen, wenn die Samples selbst keine 44 kHz haben - das nachträgliche "Aufblasen" durch Mehrmalsspielen des gleichen Frames (z.B. 4x das Frame spielen bei einem 11 kHz-Sample) erhöht nicht die Qualität.
Sobald verschiedene Samplerates gemischt werden wird's kompliziert. Wenn ich nur 11 kHz Samples habe und die zusammen mische ist es klar dass ich keine 22 oder 44 kHz als Mischfrequenz nehme sondern eben 11 kHz. Aber wenn ich 11 kHz in z.B. 16 kHz mische habe ich wieder 5 kHz Spiegelfrequenz (bei ungefiltertem reinmischen!). Naja, wenn ich im ZSM Player die Mischfrequenz runterschraube wird es leider nicht bloß immer dumpfer, sondern auch immer matschiger und farbloser. So wie ein Moiree-Effekt wie ein störendes Gitter die Sicht verschleiert. Könnte man mit Interpolation beim Mischen stark abmildern oder durch Filter komplett beseitigen, aber das kostet zu viel Rechenleistung.
Es lohnt sich nicht, zumal selbst die von mir beschriebenen Spiegelfrequenzen bei weniger Anspruch an "Kristallsound" noch tolerabel sind. Ernsthaft würde ich für ein Spiel eher 22 kHz als Mixrate vorgeben.
DOSferatu hat geschrieben:Man darf ja nicht vergessen, daß wir aufm PC mit einer "Von-Neumann-Architektur" arbeiten: Programmcode und Daten benutzen den gleichen RAM. Darauf versuche ich immer wieder direkt und indirekt hinzuweisen. Beispiel: Wenn man supergepackte Daten hat, aber die Entpackroutine so aufwendig ist, daß sie größer ist als die Daten wenn sie entpackt wären, ist es eine Überlegung wert, entweder nicht ganz so "super" zu packen (und damit die Packroutine zu verkleinern) oder sogar schlimmstenfalls ganz aufs Packen zu verzichten.
Ich bin mir nicht sicher wie groß die ZVID2 Routine wird, aber ich denke mal vorsichtig unter 4 KB, wenn nicht sogar noch viel kleiner. Performance wäre für meine nächste Idee nicht so kritisch. Wir haben im Freundeskreis ein Memory-Spiel gebastelt, und da hatte ich eine Idee: Sound Memory...
Wird Dir vielleicht prinzipiell nicht gefallen, aber hier macht es ausnahmsweise mal Sinn wenn die Tondaten den Löwenanteil ausmachen und die Grafik eine Nebenfunktion erfüllt, dazu noch komprimiert gehalten wird. NATÜRLICH gibt es sowas schon. Bisher hab ich gesehen dass es das als Browser Spiel gibt oder für's Phone. Fast schon demotivierend. Aber ich hab trotzdem Lust das schön zu gestalten (auch mit Grafik). Ein paar Herausforderungen:
- Möglichkeit gegen den Computer zu spielen:
Verschieden starke "KI" - von Computer merkt sich alles bis zu Computer hat Demenz
- Laden von 32 Tondateien pro Spiel aus einer Datenbank von meinetwegen 250,
zufällig herausgepickt so dass es vielleicht 300-400 KB füllt (Sounds variieren in
der Speichergröße), muss ich mir nen Algorithmus einfallen lassen
Naja gut, also das wäre mal was zum Aufwärmen, wo ich wüsste dass es zumindest performen würde.
DOSferatu hat geschrieben:Ich selbst traue mich z.B. nicht, Dinge die verhältnismäßig viel Zeit brauchen, im IRQ auszuführen
Ich auch nicht. Ein IRQ soll ja möglichst nicht lange unterbrechen.
DOSferatu hat geschrieben:Ach, ein Adventure zu machen, würde ich nicht als "notfalls" und "Notlösung" bezeichnen. Adventures sind toll. Habe ich auch schon selbst Ideen für einige Adventures. Wenn ich diesen Job nicht hätte und nicht immer so müde wäre (keine Ahnung, woran das liegt - vielleicht das Alter), hätte ich schon lange etwas in der Richtung gemacht.
Adventures sind auch meine Lieblingsspiele, aber es sind ja praktisch interaktive Filme und daher auch entsprechend aufwendig. Ich könnte mir das nur im Team vorstellen, ein Hintergrundmaler, ein Sprite-Zeichner, und dann kann ich meinetwegen Code und Musik machen.
Lass Dir mal helfen wegen der Müdigkeit, das kann ein Zeichen irgendeiner Krankheit sein, oder irgendwelcher Mängel.
DOSferatu hat geschrieben:Wenn ich Musik mache, muß es ja nicht CD-Niveau sein. Es gibt dermaßen viele Leute, die auf den Chiptune-Sound stehen und die genau diesen "retro-mäßigen" (wie man's heute nennt) Sound mögen. Deshalb fände ich es nicht schlimm, wenn auch heute jemand Musik in diesem Stil machen würde. Ich weiß zwar, daß es damals eher nur aufgrund technischer Beschränkungen so gemacht wurde, aber das ist für mich kein Anlaß, deshalb heute nur noch CD-Quali machen zu müssen. Das ist wie mit 2D-Pixelgrafik vs 3D-Fotorealismus: Kann man machen, muß man aber nicht.
Da gebe ich Dir im Prinzip recht, aber ich möchte anmerken, dass z.B. ein SID, wie z.B. auch der NES Soundchip, eigentlich CD Qualität bringt. Nur die Klänge sind ein wenig simpel und "Lo Fi", aber die Eckdaten die es braucht um es astrein "einzufangen" gehen schon in die CD-Richtung. Auch heutige neue "8 Bit Style" Spiele verstehen das ganze eher als Cargo-Kult und machen zwar alles schön pixelig, aber in 24 Bit Farbtiefe (und auf aktuellen Rechnern).
DOSferatu hat geschrieben:Was soll jemand schon mit einem Tool, das nur in einem Emulator läuft und viel weniger kann als aktuelle Tools (die keinen Emulator brauchen) - um damit Daten zu machen, die ebenfalls nur mit Zeug in besagtem Emulator funktionieren?
Richtig, ich nutze auch nur noch wenige Tools im Emulator, aber immerhin. Deluxe Paint, weil es einfach perfekt ist für 320x200x256, Turbo Pascal, und natürlich X-Tracker (wobei ich ja langsam aber sicher auf Renoise umsiedle. Braucht keinen Emulator, kann mehr...)
DOSferatu hat geschrieben:Andere Leute sind viel praktischer veranlagt - denen geht es nicht um das OS oder die Programmierung dahinter, wo irgend etwas läuft, die sind eher ergebnisorientiert.
So geht es mir mit Tonbearbeitungs-Software. Was funktioniert, funktioniert. Und das Ergebnis ist dann von der Software entkoppelt, es ist eine Klangdatei. Und das schöne, so habe ich das in meiner Jugend realisiert, ist, dass diese Ergebnisse, also z.B. eine CD mit Musik drauf, oder die Musik auf einem beliebigen Tonträger, dann unabhängig ist vom Computer. Das war jedenfalls für mich etwas befreiend, mir hat es nicht immer so gut getan nur am Computer zu sitzen und zu grübeln.
Aber manchmal könnte ich so richtige Freaks auch beneiden, die wirklich nur das einzige Hobby Programmieren haben und da auch total begabt sind und sich total reinbohren, als gäbe es nichts anderes im Leben. Naja es kommt so rüber wenn man ein bisschen Wind von der "Szene" bekommen hat und auch schonmal auf so einer Party war wo die Größen der Demoszene sich versammeln und dann fleissig für Wettbewerbe eingereicht wird.
DOSferatu hat geschrieben:
zatzen hat geschrieben:Ja, kann man alles auch mit MIDI und nem Fuhrpark von Audio-Peripherie am Atari machen. Hab ich aber nie so gemacht sondern seit 1993 alles in einem Computer ohne externe Hardware. Und jetzt geht eben einfach mehr, damals nur rohe MODs mit LoFi 8 Bit Sound, heute uneingeschränkte Qualität und Möglichkeiten.
Ja, wie gesagt... Gibt heutzutage viele Leute, die sagen: 44 / 48 kHz sind zu wenig, und 96 eigentlich auch. Es müssen 192 bzw 384 kHz sein! Und in ein paar Jahren muß 1 Sekunde Sound 1 GB brauchen und 64 Bit, weil da immer noch jemand "hören wird", daß das sonst unzureichend ist.
Intern verwendet manche Software tatsächlich 64 Bit und 384 kHz (Oversampling), aber nur um Aliasing zu umgehen und keine Rundungsfehler zu machen. Aber sooo ein Feinschmecker bin ich ja auch nicht, immerhin hab ich selber ein gewisses Grundrauschen auf den Ohren (leichte Form von Tinnitus) und naja, ich hoffe nicht allzu früh obenrum so eingeschränkt zu sein dass ich meinen "Job" als Masteringtyp nicht mehr machen kann, weil ich keine Hihats oder so mehr höre.
Uneingeschränkte Qualität, damit meine ich schlichtweg CD-Qualität, nicht mehr, nicht weniger.
Und Möglichkeiten, sind z.B. Speicher. Früher mit den MODs, das war auf den Heap beschränkt. Da musste ich alles was ich in ein Lied bringen wollte in 500 KB quetschen -> Telefon"qualität".
Ist halt jetzt besser und einfacher mit mehreren GB. Immerhin empfinde ich ne handvoll GB noch als uneingeschränkt. Weil ich auch eher nur im MB-Bereich unterwegs bin. Wenn ich mal im Jahr 2000 geboren worden wäre... Was hätte ich dann als Kind schon fabrizieren können, vor allem mit dem Elan den man da noch hat. Aber es ist halt wie es ist. Die alte Schule und Schwierigkeiten umschiffen sind auch lehrreich.
DOSferatu hat geschrieben:Clipping auf die oben beschriebene Art verfälscht aber trotzdem die Töne.
Ja, es ist bei ZSMPLAY ein Tradeoff zwischen Übersteuerung und Rauschen/Detailverlust. Oft ist es bei einem Musikstück so, dass die lautesten Stellen nur kurz auftreten, da fällt Clipping auf die beschriebene Art (Wellenform oben und unten abschneiden) kaum auf. Im besten Fall generiert Clipping nur etwas harsche Obertöne, aber keine Störgeräusche (die kommen von Überläufen, gab's schonmal bei Soundkarten DAC's oder ADC's), im schlimmsten Fall werden höhere Töne von tieferen moduliert. Ist eben wirklich nicht so dramatisch, weil man auch im professionellen Bereich seit Menschengedenken bis heute mit Übersteuerung und dergleichen arbeitet, sogar um den Klang ansprechender zu gestalten, wenn man es wohl dosiert. Aber das nur als Info, ich will Dich zu nix überreden, und ich finde, bei ISM sollte der Klang auch verzerrungsfrei bleiben (wobei man klangliche Artefakte aufgrund weniger Bits auch zu Verzerrungen zählt, aber das sind wieder andere).
DOSferatu hat geschrieben:2. Ich verarbeite zuerst alles vorzeichenlos - dann - über die Lautstärketabellen - wird es vorzeichenbehaftet, damit es eine "Mitte" gibt.
Ich bin mir nicht sicher ob ich das richtig verstehe. Hast Du zwischenzeitlich bis zu 8 Puffer, einen für jeden Kanal? Ich addiere in meinen Routinen direkt alles in den finalen Puffer, deshalb muss das direkt Vorzeichenbehaftet sein und ich mache alles in 16 Bit, damit ich bei Lautstärkeabsenkung keine Details verliere. Wäre eine Überlegung wert das zu ändern, aber dann dürfte es deutlich mehr Störgeräusche und Geschmirgel geben, müsste ich mal durchspielen. Um die Sache mit der Lautstärke bei mir tabellarisch zu lösen bräuchte ich 16 mal 256 Words, also 8192 Byte, das ist mir irgendwie zu viel, da ich auch ZSMs habe die deutlich kleiner sind. Müsste man sich mal die Größe des Codes ansehen, in welchem Verhältnis das steht.
Aber gut, ich denke ich verstehe wie Du das machst. Du hast pro Wellenform 4 Bit, und ich nehme an wenn die Lautstärke eines Kanals auf 0 geht hast Du eine Linie mit dem Wert 7. Vielleicht.
DOSferatu hat geschrieben:Aber, wie erwähnt: Der Grund für mich, den Kram von MS zu benutzen ist, weil der bis zu einem bestimmten Punkt noch Ähnlichkeiten/Kompatibilität zu dem hat, mit dem ich mein Zeug programmiere. Unter Linux (und anderen) könnte ich nur dummer User sein. Das wäre mir zu blöd.
Geht mir genauso. Ich bin mit DOS aufgewachsen, hab das (denke ich) komplett verstanden, es konnte mir ein klares Bild von Dateisystemen vermitteln und auch die Programmierung unter DOS mit Pascal ist sehr geradlinig und klar. Windows bringt zwar irgendwie ein dickes Geschwür im System mit, aber vom Prinzip her versteht man die Handhabung immer noch prima wenn man einmal Dos verstanden hat. Was Linux angeht - ich sehe bisher keinen Grund mich damit zu beschäftigen, und neben MacOS wird die meiste Software auch für Windows angeboten.
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 »

Hallo zatzen!
Da bin ich (endlich) mal mit meiner Antwort zu diesem Thread.
zatzen hat geschrieben: [...Altersgehör...]
Der Grund warum ich das jedem aufschwatzen will ist, dass es einfach ein unheimlicher Genuss ist, Musik aus richtig guten Lautsprechern zu hören, auf den ich nicht mehr verzichten möchte. Ich bin also begeistert, und möchte das anderen zuteil werden lassen.
Ja, schon gut. Ich habe auch keinen HDMI-Monitor. Und mein TV ist ein CRT 15" (Monitor=CRT 14"). Und die kleinen Lautsprecher hier reichen mir eben auch. Aber das erwähnte ich ja schon...
zatzen hat geschrieben:"Kristallsound", naja, es soll möglichst realistisch klingen, damit ich beim Abmischen und Mastern sofort merke, ob es gut oder nicht oder eben so klingt wie es sein soll. Ich könnte das auf kleinen Schreibtischlautsprechern nicht beurteilen.
Naja, daß jemand, der selbst Sound produziert, auf solche Sachen etwas mehr Wert legt ist ja klar - als einfach nur sowas wie ich, der Sound eher nur "konsumiert" und wenn selbst macht, dann auf Niveau/Qualität 40 Jahre alter Chips...
zatzen hat geschrieben:Übrigens, kleine Geschichte der Hornlautsprecher [...]
Ja, bekannt. Und hatten wir auch schon mal thematisiert.
zatzen hat geschrieben:AdLib: Ich habe mich tatsächlich zwischendurch auch mal gefragt, warum Du nicht einfach ein Musikprogramm für die AdLib machst. Quasi null Prozessorbelastung, und FM Synths können ja durchaus lebhafter oder organischer klingen als additive Synthese. Aber mit einem eigenen Synth bist Du natürlich unabhängig von der AdLib und bringst einen neuartigen Sound den nicht jedes Spiel hat.
Ach naja, darum ging's mir nicht so. Dieses "Klangwellen zu irgendwas mixen mit Hüllkurve" und so kam mir eben bekannter vor (C64 SID). Als ich in dem Sound Blaster Buch hier den Teil über AdLib gelesen hab, dacht ich ab und zu: Du meine Güte...
Aber vielleicht baue ich ja irgendwann mal etwas für AdLib. Dadurch, daß mein Kram ja schon so "Chiptune-artig" gestaltet ist, sollte (abgesehen von Samples) die "Konvertierung" etwas einfacher sein als bei reinen "Module"-artigen Dingen. Aber das hat derzeit keine Priorität - will endlich mal wieder ein Spiel machen. Bin momentan auch dabei, dieses "Problem" zu umgehen/realisieren, was ich hatte. Ich thematisiere das später noch etwas.
zatzen hat geschrieben:Bildschirme: Da nutze ich im Moment einen 32" LED 16:9 Fernseher. 1920x1080. Grund war vor allem, damit man bei der Soundbearbeitung mehr Plugin-GUIs auf einmal sehen kann. Tatsächlich nutze ich nur die native Auflösung, da reines Dos auf Windows 7 ja gar nicht mehr läuft. Dosbox Textmodus oder 320x200 sieht im Vollbild für meinen Geschmack trotzdem gut aus.
16:9 - igitt...
zatzen hat geschrieben:Eher noch schärfer als auf dem 14" CRT den ich früher hatte. Bei dem konnte man ab 640x??? keine Pixel mehr erkennen, und der Textmodus sah auch absolut glatt aus.
Aber genau das stört mich ja an TFT/LED TV/Monitoren: Die eckigen Pixel, die wie kleine Quadrate sind. Geringe Auflösungen sehen da mosaikartig aus. Und auf 32" sind MCGA-Pixel groß wie Suppentassen... Nich so meins.
zatzen hat geschrieben:CRT's haben sicherlich unbestreitbare Vorteile, sind anders in der Bildqualität, auch was die Farben oder die Gradienten betrifft. Zu Zeiten als wir Jungs uns noch zu Netzwerktreffen versammelt haben waren TFTs aber ein Segen, wesentlich weniger zu schleppen...
Das ist natürlich klar. Aber ich schlepp den ja nicht durch die Gegend. Und mehr als 14" benötige ich nicht.
zatzen hat geschrieben:Zuletzt hatte ich einen 17" Eizo CRT.
Meine beiden 14" sind Sony Trinitron. SUPER Qualität
zatzen hat geschrieben:Mein Problem mit Smartphones ist, dass ich etwas zitterig bin und ständig einen Buchstaben doppelt eintippen würde, ähnlich unsicher würde ich mich bei der allgemeinen Bedienung fühlen. Ich will das Prinzip generell nicht verteufeln, aber irgendwie vermisse ich nicht wirklich was ohne, immerhin sind meine Möglichkeiten (für das was ICH machen will) am richtigen PC doch weitaus größer.
Ja, ich brauche auch eine richtige Tastatur. In richtiger Größe und mit fühlbaren Tasten. Und beim Zocken auch: Tasten (Tastatur) oder auch n Joystick/Joypad mit richtigen Tasten/Hebeln, die man spürt, ohne hinzugucken.

Außerdem: Es wurde immer gelästert über das kleine Keyboard des Commodore PET. Das ist aber insgesamt größer als ein Smartphone-Gehäuse. Und außerdem hat es drückbare Tasten. Und aufm Smartphone wird selbst wenn eine Tastatur eingeblendet wird, diese aufm Bildschirm, zusammen mit was anderem eingeblendet. Ist also mind 3x bis 4x kleiner, als die vom PET und absolut flach, ohne mechanische Funktion, Druckpunkt, Anschlag, irgendwas... - aber so ein Mist scheint OK für die Leute zu sein. - Ehrlich: So könnt ich nich arbeiten und auch nicht Zocken - das wär für mich die Hölle.
zatzen hat geschrieben:Ich habe ein Klapp-Handy, relativ kleines Ding. Damit nur wird telefoniert oder es wird schonmal als MP3 Player benutzt.
Ich habe gar kein Handy. Ich möchte kein Gerät an mir herumtragen, das wie ein Transponder die ganze Zeit meine Position funkt. Kennste "Nummer 5 lebt"? Der war schlau, hat seinen Transponder entfernt - weil's niemanden was angeht, wo er grade ist, außer er sagt es demjenigen selbst. Tja, schlauer als die meisten Leute, wie's aussieht...
zatzen hat geschrieben:Passt hier ganz gut rein: Was für eine Tastatur hast Du? Ich habe mittlerweile eine recht flache, ca. 4 mm dicke Tasten, auch ca. 3-4 mm Federweg. Kamen vor 15 Jahren etwa in Mode. Ich finde damit kann man ziemlich schnell schreiben, macht aber tendentiell mehr Fehler. Zudem konnte man mit einer "dicken" beim Trackern nahezu blind arbeiten, weil die Finger richtig gut ertasten konnten wo man sich befindet. Hast Du noch so eine gute alte Cherry, vergleichbar mit der eines C64?
Diese flachen, die Du meinst, mag ich nicht.
Und ja: SELBSTVERSTÄNDLICH habe ich so eine gute alte Cherry, und zwar die G80-3000 (mehrere). Wenn einer eine "drüber" hat - immer her damit! Aber nur die 102-Tasten-Version! (Windows-Tasten brauch ich nicht - die stören beim Zocken und Coden und .... eigentlich immer.)
zatzen hat geschrieben:Aber ich will mal nicht meckern. Leute die mit Computern umgehen können und Internetzugang haben sind auch priviligiert.
Naja, zumindest, wenn man nicht gerade in der sog. "Dritten Welt" lebt, ist Internetzugang heute kaum noch etwas Besonderes. Und "mit Computern umgehen können" hat nichts mit Privilegien zu tun - das kann man sich erarbeiten. Wenn jemand etwas nur deshalb nicht kann, weil er zu faul ist, es zu erlernen, dann braucht er niemanden beneiden, der es kann.

Andererseits ist der heutige Umgang mit Computernutzern ("Usern"...) nicht gerade dazu angehalten, daß Leute noch irgend ein technisches Verständnis entwickeln.
Hab da letztens einen sehr passenden und wahren Spruch gelesen:
"Steve Jobs hat USER hervorgebracht - Jack Tramiel EXPERTEN."
zatzen hat geschrieben:Ich würde schon gern die Möglichkeit zu hunderten Patterns haben. Aber Träume verblassen auch, ich bin nicht mehr unbedingt so motiviert, einen Tracker zu schreiben den sogar ich selbst letztlich kaum benutzen werde denn: X-Tracker bietet alles was ZSM benötigt, auch 1024 Patterns wenn ich nicht irre, und letztlich werden ZSMs ja direkt aus DMFs konvertiert. Ich muss nur auf Effekte verzichten und mir bewusst sein dass Lautstärken nur in den Stufen 255 192 128 96 64 48 32 24 16 12 8 6 4 3 2 1 gehen. Letztlich auch wurscht beim Trackern, weil der ZSM Converter alle Werte zwischen 1 und 255 sinnig auf die exponentiellen 16 rundet.
Ja, bin mir auch nicht sicher, wie sehr man bei 65 Lautstärken (0=aus) den Unterschied zwischen zwei direkten Stufen hört. Deine 16 Stufen finde ich da mehr als ausreichend. Meine sind ja nichtmal logarithmisch (obwohl das möglich wäre, weil ja bei mir aus Geschwindigkeitsgründen (und "System-Design-Gründen") alles über "Multiplikations-Tabellen" gelöst ist).

Ich finde, wenn man einerseits exorbitante Möglichkeiten bietet, andererseits aber das System aus Speicher-/Performancemangel abstürzt, sobald man 3 von 10 Möglichkeiten mal "auf Anschlag benutzt", dann ist das nichts, wie ich programmieren will.
zatzen hat geschrieben:Vielleicht mach ich den Tracker, wenn ich wirklich mal Lust drauf habe, auch wenn es egal ist ob er benutzt wird oder nicht. Vor über 25 Jahren hätte ich noch eine Chance auf andere Benutzer gehabt, aber jetzt gibt es einfach zu viel Konkurrenz. Da mache ich doch lieber erstmal ein Spiel.
Achnaja, die Konkurrenz ist es bei mir ja kaum noch. SO VIEL wird ja nicht grade für DOS neu rausgebracht. Und Windows, Linux & Co. empfinde ich ja nicht als Konkurrenz - da gibt es ja inzwischen nicht einmal mehr mittelbare Schnittpunkte...
zatzen hat geschrieben:
DOSferatu hat geschrieben:Jedenfalls ist der Sinn des Ganzen, ein Programm mit beliebig vielen Funktionen haben zu können, das trotzdem noch genügend Platz für die eigentlichen Daten übrigläßt, weil jede Funktion nur so lange im Speicher ist, wie sie gebraucht wird.
Hört sich gut an. Auf sowas bin ich natürlich noch nicht gekommen, mein Frankus Tracker II hat alle Menüs und Pulldowns etc. "hardcoded".
Natürlich ist "hardcoded" geil und schnell usw. Meine Engines sind ja auch "hardcoded" monolithische Blocks, dafür schnell. Und auf einem XT oder 286er (vor allem mit den damaligen Festplatten, bzw DISKETTEN!) wäre das Obengenannte wohl nur sehr bedingt empfehlenswert.
Und meine anderen Tools haben auch hardcoded Menüs/Pulldowns usw.

Aber gerade bei so Spiel-Entwicklern will ich gern möglichst viel RAM freilassen für die Daten. (Weil PCs ja "Von-Neumann-Struktur" haben, müssen sich Code und Daten den gleichen RAM teilen. Mehr Code = weniger Platz für Daten.) Und bei so Editoren kommt es ja nicht auf 50Hz-Echtzeit an, sondern eher auf vielfältigere Möglichkeiten und viel Platz für Daten. Deshalb diese Entscheidung.

Das gleiche Ding will ich aber auch evtl. in Spiele einbauen, damit man damit z.B. Parameter einstellen (weil es eben ermöglicht, auf alle Variablen/Speicher usw. zuzugreifen). Also eher so fr Titel-/Zwischenmenüs.
zatzen hat geschrieben:ZSM ist ein absolutes Endformat, quasi kompiliert. Samples beschnitten, zu 4 Bit Delta runterkonvertiert und Patterns aufwendig geschrumpft. Die Patterns könnte man verlustfrei entpacken (mache ich ja beim Abspielen und in der neuen Playerversion zeige ich sie auch an), aber die Samples sind unwiederbringlich verstümmelt und datenreduziert.
Ja, ich weiß.
zatzen hat geschrieben:MOD dagegen hat volle 8 Bit in den Samples und ein Komponist (Trackerer) muss die Samples schon selber kürzen wenn er das will. Ein MOD kann man prima jederzeit remixen oder man kann sich vollwertige Samples daraus klauen.
Wurde ja auch oft gemacht - auch wenn in den MODs oft stand, daß die Macher es sich verbitten, ihre Samples zu rippen usw.
zatzen hat geschrieben:Ich glaube, X-Tracker packt die Patterns mehr oder weniger in Echtzeit, zumindest während der Bearbeitung, auch ohne dass man speichert. Das erscheint sinnig, weil 32 Kanäle möglich sind mit jeweils Informationen über Samplenummer, Tonhöhe, Lautstärke und 3 gleichzeitig mögliche Effekte + Parameter.
Also PI*Daumen ca. 10 Byte pro Kanal, * 32 = 320 Byte, und das ganze möglich bis 512 Zeilen = 163840 Byte, und dann davon bis 1024 Patterns (-> 160 MB) - wenn man da nicht packt, wo soll das hinführen...
Hin und wieder hat's da schon Datenfehler und Abstürze gegeben wenn man ein Pattern verlängern wollte, nicht ganz ausgegoren, aber man hat es irgendwann im Gefühl, die Bugs zu vermeiden.
Ja, und genau sowas will ich NICHT coden - Zeug, bei dem man bei Benutzung selbständig aufpassen muß, irgendwelche Grenzen nicht zu überschreiten, weil sonst alles mit Datenverlust abrasselt.
zatzen hat geschrieben:Im Prinzip richtig, aber im konkreten Fall von 16 kHz Sample in 22 kHz reinmischen kann es schnell etwas anders kommen. Dazu muss ich schnell nochmal die Sache mit dem Aliasing bei Sound erklären. Zur sauberen Darstellung einer bestimmten Frequenz benötigt man mindestens eine Samplerate der doppelten Frequenz.
Ansonsten kommt es zu einer Spiegelfrequenz (Aliasing), die sich berechnet aus Abtastrate minus (zu hohe) abzutastende Frequenz.
Ja, das mit den Spiegelfrequenzen durch das "Sound-Moiré" ist mir schon klar. Aber bei der "Qualität", mit der ich soundmäßig in ISM arbeite, ist das auch schon egal.
Der Effekt ist gut hörbar, wenn man Digi-Sound über PC-Speaker ausgibt und die Abspielfrequenz (d.h. den Ticker) in den hörbaren Bereich schiebt. Schon irritierend, dieses Pfeifen...
zatzen hat geschrieben: [...] Hab ich nun ein ganzes "Orchester" in ZSM spielen, wo Samples aller Art und Abtastrate munter umhergemischt werden, dann empfehle ich eben 44 kHz, weil dann diese "Matschereien" weitestgehend ausbleiben. Es klingt dann einfach transparenter und sauberer, weil es (fast) keine Spiegelfrequenzen gibt. Daher gebe ich das als Standard vor, wer es sich aus Performancegründen nicht leisten kann, kann die Mixrate runtersetzen.
Naja, das was ich erzeuge, hat mit Orchestermusik ja kaum etwas zu tun: Relativ harte Wellen, wenig Stimmen. Das wird auch bei 44 kHz kaum besser als bei 11 kHz oder 22 kHz - und ja, ich hab's ausprobiert. Eher im Gegenteil: Im Niedrigfrequenzbereich klingt es irgendwie "brachialer" - und genau das will ich haben. Es SOLL plärren!
zatzen hat geschrieben:oder durch Filter komplett beseitigen, aber das kostet zu viel Rechenleistung.
Sobald ich eine schön schnelle Methode finde, Filter einzubauen, die keine Raketenwissenschaft benötigen (ich mach bestimmt KEINE Fourier-Frequenz-Analyse oder sowas!), werden diese in ISM noch mal umgesetzt. Dabei geht es mir gar nicht um irgendwelche Genauigkeiten, sondern eher darum, Sounds höhenlastig "hisssen" oder baßlastig "hummmen" zu lassen, um damit bestimmte Geräusche oder Instrumente pseudomäßig imitieren zu können. Weißes Rauschen kann ISM ja z.B. erzeugen - aber OHNE Baßpaß knallt das noch nicht so richtig.
zatzen hat geschrieben:Ich bin mir nicht sicher wie groß die ZVID2 Routine wird, aber ich denke mal vorsichtig unter 4 KB, wenn nicht sogar noch viel kleiner. Performance wäre für meine nächste Idee nicht so kritisch. Wir haben im Freundeskreis ein Memory-Spiel gebastelt, und da hatte ich eine Idee: Sound Memory...
Wird Dir vielleicht prinzipiell nicht gefallen, aber hier macht es ausnahmsweise mal Sinn wenn die Tondaten den Löwenanteil ausmachen und die Grafik eine Nebenfunktion erfüllt, dazu noch komprimiert gehalten wird. NATÜRLICH gibt es sowas schon. Bisher hab ich gesehen dass es das als Browser Spiel gibt oder für's Phone. Fast schon demotivierend. Aber ich hab trotzdem Lust das schön zu gestalten (auch mit Grafik).
Wieso sollte mir das nicht gefallen?
Daß ich mal gesagt habe, "Sound besser als letztes machen, wenn alles andere läuft", bezog sich ja vor allem auf 2D-Jump'n'Run/Shoot'em'up und ähnliches. Wenn da nur der Sound gut läuft, aber dann kein Platz/Leistung mehr für Grafik/Steuerung da ist, wäre es ja irgendwie Mist. Bei einem von vornherein auf die Idee von Sounds ausgelegtes Spiel mit "Still-Grafik" ist letzteres natürlich nebensächlich und da ist es dann genau umgekehrt.
zatzen hat geschrieben:Ein paar Herausforderungen:
- Möglichkeit gegen den Computer zu spielen:
Verschieden starke "KI" - von Computer merkt sich alles bis zu Computer hat Demenz
- Laden von 32 Tondateien pro Spiel aus einer Datenbank von meinetwegen 250,
zufällig herausgepickt so dass es vielleicht 300-400 KB füllt (Sounds variieren in
der Speichergröße), muss ich mir nen Algorithmus einfallen lassen
Naja gut, also das wäre mal was zum Aufwärmen, wo ich wüsste dass es zumindest performen würde.
Ja, klingt nach 'nem Plan. Und sowas macht bestimmt auch Spaß.
zatzen hat geschrieben:Adventures sind auch meine Lieblingsspiele, aber es sind ja praktisch interaktive Filme und daher auch entsprechend aufwendig. Ich könnte mir das nur im Team vorstellen, ein Hintergrundmaler, ein Sprite-Zeichner, und dann kann ich meinetwegen Code und Musik machen.
Ja, allein wäre das sehr aufwendig. Vom programmiererischen Standpunkt her wäre ein Point-and-Click-Adventure für mich überhaupt keine Herausforderung mehr - außer für die Animation der Spielfiguren würde ich da nicht mal Assembler bemühen - das ginge alles eher besser mit Pascal & Co. Aber, wie Du schon sagtest, die ganzen Dinge wie Grafiken, Sounds+Musiken, auch die Story... - das sind ja die Dinge, von denen ein gutes Adventure lebt und das macht viel Mühe. Allerdings habe ich auch einen Scanner hier und für Hintergrundgrafiken wäre das schon eine Hilfe.
zatzen hat geschrieben:Lass Dir mal helfen wegen der Müdigkeit, das kann ein Zeichen irgendeiner Krankheit sein, oder irgendwelcher Mängel.
Bin mir fast sicher, daß ich Mangel habe an: Vitamin D (weil ich absichtlich die Sonne/Tageslicht meide), Magnesium (weiß nicht, aber die Symptome sprechen dafür) und Eisen (hatte ich schon als Kind).
zatzen hat geschrieben:Auch heutige neue "8 Bit Style" Spiele verstehen das ganze eher als Cargo-Kult und machen zwar alles schön pixelig, aber in 24 Bit Farbtiefe (und auf aktuellen Rechnern).
Ja, und das ist uncool - und wirkt schon irgendwie so, als würde man sich über 8-Bit Zeug lustig machen wollen. Naja, solange es einen "Hype" gibt (egal welchen), gibt es immer eine Menge Leute, die drauf anspringen bzw. die damit Geld verdienen wollen. Für mich ist/war das ja nie ein Hype - und für mich ist es auch nicht "retro"/"retrospektiv". Das wäre es nur, wenn ich irgendwann mal zwischendurch damit aufgehört hätte und jetzt aus Nostalgie wieder damit anfangen würde. Aber ich hatte ja nie damit aufgehört, auch wenn ich mal größere "Durststrecken" hatte, in denen nicht viel geworden ist... - aber das hatte ich ja auch mal erwähnt.

Nur, ein "8-bit-artiges" Spiel machen, das so aussieht/klingt/sich spielt daß es auch auf 'ner fast 40 Jahre alten Kiste laufen könnte, aber in Wirklichkeit mehrere GHz CPU-Leistung und mehrere GB Speicher braucht - wie uncool ist das? Da kann man einen Porsche nehmen, einen Lkw ohne Reifen dranbinden und sich freuen, daß der Porsche zwar 100 Liter/100 Kilometer braucht, aber dafür genauso langsam vorankommt, wie ein 120 Jahre altes "Retro"-Auto...

Da bewundere ich eher die Leute, die auf den echten alten Maschinen heutzutage so super tolle Dinge machen, als Leute, die auf neuen total hochgebürsteten Maschinen Dinge machen, für die man eigentlich nur 1 MHz brauchen würde... - andererseits muß man sich ja auch schon freuen, wenn heutzutage überhaupt noch Leute privat irgendwas entwickeln und für wenig Geld oder gratis... Das "User-tum" greift ja immer mehr um sich... Naja, Millennials eben...
zatzen hat geschrieben:Richtig, ich nutze auch nur noch wenige Tools im Emulator, aber immerhin. Deluxe Paint, weil es einfach perfekt ist für 320x200x256, Turbo Pascal, und natürlich X-Tracker (wobei ich ja langsam aber sicher auf Renoise umsiedle. Braucht keinen Emulator, kann mehr...)
Ja, ich meinte damit: WENN ich ein Tool baue, dann bestimmt nicht nur dafür, damit es auf einem Emulator läuft - da kann man ja gleich das System benutzen, auf dem auch der Emulator läuft. Naja, X-Tracker braucht auch keinen Emulator. Daß er bei Dir einen Emulator braucht, liegt daran, daß Du das falsche Betriebssystem benutzt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Andere Leute sind viel praktischer veranlagt - denen geht es nicht um das OS oder die Programmierung dahinter, wo irgend etwas läuft, die sind eher ergebnisorientiert.
So geht es mir mit Tonbearbeitungs-Software. Was funktioniert, funktioniert. Und das Ergebnis ist dann von der Software entkoppelt, es ist eine Klangdatei. Und das schöne, so habe ich das in meiner Jugend realisiert, ist, dass diese Ergebnisse, also z.B. eine CD mit Musik drauf, oder die Musik auf einem beliebigen Tonträger, dann unabhängig ist vom Computer. Das war jedenfalls für mich etwas befreiend, mir hat es nicht immer so gut getan nur am Computer zu sitzen und zu grübeln.
Naja, ich bin eher nicht so ergebnisorientiert. Wenn ein Spiel fertig ist, da hab ich ja nichts davon. Die Freude ist das Machen. Wenn ich heute ein Spiel fertig hätte - wen juckt's? Ginge es mir um das Ergebnis, d.h. vorzeigbares Zeug für andere - dann müßte ich irgendwelche aktuellen Systeme benutzen. Ja, das klingt natürlich seltsam - Spiele macht man ja, damit Leute sie spielen. Aber für mich ist das Spiele-Machen eben das Hobby. Und ein Hobby betreibt man ja nur, solange es Spaß macht. Windows mit seinem abgekapselten System, alles mit mehrfach indirekten Zugriffen durch etliche Abstraktionsstufen... Das ist total unsexy.
zatzen hat geschrieben:Aber manchmal könnte ich so richtige Freaks auch beneiden, die wirklich nur das einzige Hobby Programmieren haben und da auch total begabt sind und sich total reinbohren, als gäbe es nichts anderes im Leben.
Ja, so war ich früher mal. Heute wäre ich es auch noch (und manchmal habe ich in der Tat noch so Phasen) - nur reicht es bei mir körperlich nicht mehr so.
zatzen hat geschrieben:Naja es kommt so rüber wenn man ein bisschen Wind von der "Szene" bekommen hat und auch schonmal auf so einer Party war wo die Größen der Demoszene sich versammeln und dann fleissig für Wettbewerbe eingereicht wird.
Naja, ich bin nicht besonders gesellig - so Menschenansammlungen sind mir eher ein Greuel, das muß ich nicht freiwillig haben.
zatzen hat geschrieben:Intern verwendet manche Software tatsächlich 64 Bit und 384 kHz (Oversampling), aber nur um Aliasing zu umgehen und keine Rundungsfehler zu machen.
Klar, das macht ja auch Sinn, daß man erst am Ende "runterrechnet". Macht man auch bei Grafik.
zatzen hat geschrieben:Uneingeschränkte Qualität, damit meine ich schlichtweg CD-Qualität, nicht mehr, nicht weniger.
Und Möglichkeiten, sind z.B. Speicher. Früher mit den MODs, das war auf den Heap beschränkt. Da musste ich alles was ich in ein Lied bringen wollte in 500 KB quetschen -> Telefon"qualität".
Naja, und ich denke dabei an die Leute, die aufm C64 Musik gemacht haben und meistens bei Spielen war da die Vorgabe, daß es in die bewußten 4kByte passen sollte (klar, da hat natürlich der SID die Wellenformen gemacht), aber trotzdem... Auch auf PC gab und gibt es so 4kB- und 64kB-Wettbewerbe, so Leute zeigen, was man an Grafik UND Sound gleichzeitig in so ein paar kByte unterbringen kann und es sieht geil aus und klingt geil. Und wenn ich so etwas sehe, kommen mir dann jedes Mal wieder Zweifel an der "NOTWENDIGKEIT" von Gigabyte und Gigahertz.
zatzen hat geschrieben:[...Clipping...] Aber das nur als Info, ich will Dich zu nix überreden, und ich finde, bei ISM sollte der Klang auch verzerrungsfrei bleiben (wobei man klangliche Artefakte aufgrund weniger Bits auch zu Verzerrungen zählt, aber das sind wieder andere).
Naja, ich will nicht, daß man da irgendwie "aufpassen muß, daß es nicht übersteuert". Aber ich habe geplant, in ISM noch so einen einstellbaren "Overdrive" Wert einzubauen, mit dem man die allgemeine (eingemixte) Lautstärke anheben kann, damit man auch mal bis Anschlag kommt. Da sowieso alles (bzw. vieles) in ISM mit Tabellen gelöst wird, wird das auch der Performance keinen Abbruch tun.
zatzen hat geschrieben:
DOSferatu hat geschrieben:2. Ich verarbeite zuerst alles vorzeichenlos - dann - über die Lautstärketabellen - wird es vorzeichenbehaftet, damit es eine "Mitte" gibt.
Ich bin mir nicht sicher ob ich das richtig verstehe. Hast Du zwischenzeitlich bis zu 8 Puffer, einen für jeden Kanal?
Nein. Ich fülle zu Anfang den ganzen Puffer mit Nullen. Von jeder einzelnen Stimme wird der Kram dazu-addiert. Die Lautstärketabellen geben aus einem 4-Bit-Sound und einer 4-Bit-Lautstärke wieder einen "Quasi-4-Bit"-Wert zurück, nur mit Reichweite -8...+7 (also 248...007). Die werden da "reinaddiert". Zum Schluß "weiß" ISM, wieviele Stimmen aktiv waren und dementsprechend geht der ganze Puffer nochmal durch eine (berechnete) Tabelle, die alle Werte auf die "Master-Lautstärke" hochzieht. Beim "Aufaddieren" kann kein Clipping passieren, weil die Werte alle ja quasi im Bereich 0-15 bleiben (nur eben um -8 versetzt) und bei 16 Stimmen immer noch maximal -128..112 sind. Die letzte Tabelle wird immer nur dann neuberechnet, wenn sich entweder die Masterlautstärke oder die Anzahl aktiver Stimmen ändert.

Weiß nicht, ob ich das nun einigermaßen verständlich erklärt habe. Zu Anfang hatte ich den Sound quasi "vorzeichenlos" erstellt, d.h. alle Stimmen einfach positiv aufaddiert. Daraus resultierte aber ein Sound, der keine "Mitte" hatte, sondern so "nach unten" gesteuert war und das klang schräg.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Unter Linux (und anderen) könnte ich nur dummer User sein. Das wäre mir zu blöd.
Geht mir genauso. Ich bin mit DOS aufgewachsen, hab das (denke ich) komplett verstanden, es konnte mir ein klares Bild von Dateisystemen vermitteln und auch die Programmierung unter DOS mit Pascal ist sehr geradlinig und klar. Windows bringt zwar irgendwie ein dickes Geschwür im System mit, aber vom Prinzip her versteht man die Handhabung immer noch prima wenn man einmal Dos verstanden hat. Was Linux angeht - ich sehe bisher keinen Grund mich damit zu beschäftigen, und neben MacOS wird die meiste Software auch für Windows angeboten.
Naja, ich bin kein Fan von Windows - aber zumindest bis WindowsXP (32bit) lief meine Software auch auf Windows (außer wenn ich den Ticker zu hoch gestellt habe, d.h. höher als 1kHz). Habe sogar Zeug hier, was auf Sound Blaster ausgibt - und wenn man in die AUTOEXEC.NT (funktioniert wie AUTOEXEC.BAT, wird von NTVDM benutzt, was 16-Bit Zeug (DOS) ausführt) eine BLASTER-Variable mit entsprechenden Werten setzt, wird unter Windows eine Sound Blaster mit genau diesen Werten quasi emuliert vom vorhandenen Sound-System - und Grafik konnte man auch im Vollbild mit (quasi-) Direktzugriffen machen, wie in DOS. Tja, zu XP-Zeiten haben die das hingekriegt - heute, mit den besseren, schnelleren Computern und den ach-so-tollen neuen Windows-Versionen geht das nicht mehr "nativ" im System (einfach eine 16bit-EXE anklicken und sie läuft), sondern man muß DOSBox und ähnliches bemühen.

Ich habe den Eindruck, bei Microsoft werden nach und nach die fähigen Leute rausgeschmissen und immer mehr Versager eingestellt. Die sind wahrscheinlich billiger.

Ach ja, ich hatte ja geschrieben, daß ich "später" noch darauf zurückkommen will, was ich da bei meinem Zeug "überwunden" habe. Mir ging es darum, daß ich bisher so einen "Level-Entwickler" habe/hatte, der die Daten zusammengefaßt für ein Level abspeichert. Nur gefällt mir das nicht so, aus folgendem Grund: Wenn ich bestimmte Dinge (Sounds, Sprites, Hintergrundgrafik-Kacheln) für mehrere Levels benutzen will, will ich die nicht jedes mal in jedes Level einbauen - das wäre ja dumm. Dann müßte man ja auch jede Änderung an einer Figur/Grafik, die mehrmals vorkommt, jedesmal überall machen. Und man würde das gleiche Zeug dann 5x speichern oder so.

Die neuere Idee ist jetzt, die einzelnen Teile als Einzel-Files zu lassen und ein Level ist quasi eher eine Beschreibung, welche der Einzel-Files zu laden sind, die ein Level kombinieren. So ist z.B. die Levelmatrix, als die Anordnung der Kacheln, sicher für jedes Level neu - aber die Kacheln selbst kann man ja für mehrere Unterlevel derselben "Welt" wiederverwenden. Genauso ist es z.B. mit den Soundeffekten. Es wird ein "Level Null" geben, das quasi nur ein Dummy ist und dazu da, generalisierte Daten, die in allen Levels benutzt werden, einmalig zu laden.

So ist es mit mir: Ich schreibe großartig funktionierende Engines, die als quasi "Black-Box" nur eingebaut werden und von sich alleine funktionieren und performen. Und dann scheitert das "Weiterkommen" mit dem Gesamtprojekt daran, sich den Kopf zu zerbrechen über so eine simple Sache wie das obengenannte. Ich bin sozusagen irgendwie ein schlechter "Organisator": Ich bin gut darin, funktionierende Einzelteile zu bauen - sogar mit Schnittstellen und allem. Aber für mich wird es dann schwierig, die "losen Enden" zu einem funktionierenden Ganzen zu verbinden.

Auch dieses Skriptsystem sollte ja dazu dienen. Ich meine: Wenn ich ein Spiel mache, ist es ja schön, daß es als "Demo" schon mal funktioniert. Trotzdem gehört ein Titel dazu, eine Möglichkeit, das Ding zu starten und zu pausieren oder neue aufeinanderfolgende Levels zu laden, wenn eins beendet ist. Man stelle sich gar vor: Ein Spiel, bei dem man den Spielstand speichern könnte! Klingt erstmal einfach. Aber so ein Spiel besteht aus etlichen Einzelteilen...

Naja, also das ist so das Zeug, mit dem ich mich momentan beschäftige. Der "Level-Loader" wird wieder in eine Unit ausgelagert. Ich habe ja auch schon einen Editor, der aber wie gesagt nur so generalisierte Levelklötze speichert - da bin ich noch am Überlegen, ob ich nun das Tool verbessere (hat auch intern so ein Skriptsystem, das aber alt und in Pascal ist) oder ein neues Tool baue, das das neue Skriptsystem benutzt. Ersteres könnte dauern, weil älterer Code und weil ja trotzdem Speicher gespart werdens soll, zweiteres könnte ebenfalls dauern, weil wieder Neuentwicklung eines Tools von Null an (wenn auch mit Erfahrungen aus den vorigen Dingen).
Das Ding hieße dann schon TheGame4 (ja, schon 3 quasi vollständig bzw. halbvollständig entwickelte Tools hier zum Levels/Spielgrafik/Sprites bauen und keins davon gefällt mir so richtig...)

Ach so, was ich noch schreiben wollte: Ich lese in letzter Zeit auch Eure Unterhaltungen mit dem User Thomas. Scheint also noch ein neuer Coder da zu sein, der auch das Gleiche macht wie ich: Spielecoden in Pascal+ASM, unter DOS, möglichst systemnah. Vielleicht sollte ich mich mal vorstellen - hätte auch sicher einige hilfreiche Anmerkungen... Andererseits will ich mich nicht in Eure Konversation so ungefragt reinhängen, käme mir unhöflich vor. Kannst ihn ja trotzdem mal grüßen.

So, das war's erst mal zu diesem Thread. Bitte entschuldige, daß meine Antwort dieses Mal so lange gedauert hat. Ich hatte in letzter Zeit einen ziemlichen Hänger, von dem ich mich erst so allmählich erhole. (Wochenlang nicht gecodet und so. Ganz schlimm.)
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 »

Hallo!
Ich bin noch beschäftigt mit der Portierung des Beni Tracker Players, dürfte soweit funktionieren, jetzt schreibe ich noch den wesentlichen Teil der Player-Routine in Assembler um. Ich weiss nicht wie sehr es sich lohnt, aber es ist auch ein bisschen eine Idealismus-Sache die mir gerade Spaß macht. Hochsprachen machen ja das Programm für den Programmierer z.B. bei Datenfeldzugriffen übersichtlicher, für die Maschine aber je nachdem nur komplizierter. Ich denke man kann den Code und die Ausführungsdauer schrumpfen, wenn man alles gut mitdenkt und z.B. Offset-Register für Array-Adressierungen auch einfach mal auf ihrem Wert belassen kann. Und IF/ELSE kann man auch schön gestalten, gerade in einer Routine, dann kann man sich einen Sprung sparen und vor dem ELSE Teil einfach schon mit RET zurückkehren. Ich habe die letzten Tage etwas intensiver in dem Assembler FAQ gelesen. Mir ist nur nicht ganz klar, welcher Typ von CALL es ist wenn ich in Pascal eine Procedure aufrufe bzw. in einem ASM Teil eben CALL (Assemblerroutine ohne Parameter) verwende. Es gibt da ja verschiedene, und die über einen Pointer brauchen um die 30 Takte, was nicht so toll ist.
DOSferatu hat geschrieben:Aber genau das stört mich ja an TFT/LED TV/Monitoren: Die eckigen Pixel, die wie kleine Quadrate sind. Geringe Auflösungen sehen da mosaikartig aus.
Ich glaube ich hatte als ich gerade Adventures entdeckte einen 15" CRT. Und bei mir ist es etwas anders, ich mochte immer diese Mosaik-Wirkung, zumindest wenn es Farbverläufe waren oder unscharfe Konturen, oder auch etwas, das gutes Anti-Aliasing hatte. Klar, zu große und scharfe Pixel gehen bei mir auch nur als Stilmittel durch. Dosbox zieht 320x200 allerdings auch nicht super scharf auf meine 1920x1080 hoch, von daher ist das durchaus noch genießbar.
Ich kann Dich aber sehr gut verstehen dass 16:9 zum Programmieren bescheuert ist. Was bei mir hier aber beim Programmieren durchaus praktisch sein kann, ist Multitasking, ein Fenster DOSBOX, und dabei noch irgendein Code den ich (s.o.) portiere, dazu noch die ASM FAQ...

Ja, diese Touchscreen-Sache ist ein Fluch. Es gibt jetzt auch schon Mäuse ohne Mechanik. Design-Wahnsinn...
Aber der Touchschreen hat Smartphones möglich gemacht. Was bleibt ist aber dass Touchscreen einfach gegen die Ergonomie ist, zumindest für alle, die nicht zu den Meistern des Wischens gehören.
DOSferatu hat geschrieben:Ja, bin mir auch nicht sicher, wie sehr man bei 65 Lautstärken (0=aus) den Unterschied zwischen zwei direkten Stufen hört.
Da Amiga-MODs es mit diesen Lautstärkestufen linear halten, hört man z.B. von 63 auf 62 so gut wie keinen Unterschied, wenn überhaupt. Zwischen 1 und 2, wenn man den Verstärker laut drehen würde, würde man aber einen großen Unterschied hören, nämlich die doppelte Amplitude (6 dB Unterschied). Deswegen habe ich das bei mir nichtlinear gemacht, ursprünglich ja um einfach mit Bitshifting die Lautstärke einstellen zu können, letztlich waren 6 dB Sprünge aber dann doch zu grob, daher habe ich noch eine Zwischenstufe eingeführt.
Man könnte auch sagen, ich gehe da relativ vor. Aber nicht additiv relativ, sondern multiplikativ. Ich könnte mir über eine Tabelle vielleicht ein Dutzend Takte sparen, aber diese Tabelle bräuchte 16 * 256 * 2 (16 Bit Integer) Bytes, das ist dann irgendwie nur gerechtfertigt wenn ich mich nicht mehr über ZSMs freuen will die kleiner als die Tabelle sind. Ich kann mir ja die Code-Zeilen nochmal ansehen.
DOSferatu hat geschrieben:Achnaja, die Konkurrenz ist es bei mir ja kaum noch. SO VIEL wird ja nicht grade für DOS neu rausgebracht.
So habe ich das noch gar nicht gesehen. Eher so, dass nur noch wenig Leute mit DOS arbeiten und die Konkurrenz gegeben ist durch die neuen Betriebssysteme und dass es auf denen eben z.B. Tracker gibt, mittlerweile sogar einer im Browser. Die Frage ist auch, wer setzt sich hin und macht Musik im ZSM-Format... Das müsste schon ein Liebhaber sein. Bisher ist es ja eher eine Spielerei wobei ich massenweise Musik darein konvertiere, die durch die Limitierungen des Formats nicht beschnitten werden. Die Limitierungen bestehen ja im wesentlichen darin, dass ich keine Effekte ausser Lautstärke verwende. Das liegt daran, dass die meisten Effekte mit 50 Hz gerastert sind. Die Portierung vom Beni Player hat mir gezeigt, wie einfach soetwas eigentlich zu machen ist, aber dann muss die Zeilendauer auch immer ein vielfaches von 20 Millisekunden (1 / 50 tel Sekunde) sein, und man ist somit auf bestimmte Geschwindigkeiten wie 94, 107, 125, 150 ... beschränkt. Und das wollte ich nicht. Und zugegeben, ohne Effekte ist es auch einfacher zu programmieren. Vielleicht verständlich für meinen ersten "MOD" Player überhaupt.
DOSferatu hat geschrieben:Dabei geht es mir gar nicht um irgendwelche Genauigkeiten, sondern eher darum, Sounds höhenlastig "hisssen" oder baßlastig "hummmen" zu lassen, um damit bestimmte Geräusche oder Instrumente pseudomäßig imitieren zu können.
Ein einfaches Hochpassfilter wäre, Deltas zu bilden. Und möglicherweise kann man einen Tiefpass machen, indem man von der Originalwelle diese Deltas abzieht.
DOSferatu hat geschrieben: Daß ich mal gesagt habe, "Sound besser als letztes machen, wenn alles andere läuft", bezog sich ja vor allem auf 2D-Jump'n'Run/Shoot'em'up und ähnliches. Wenn da nur der Sound gut läuft, aber dann kein Platz/Leistung mehr für Grafik/Steuerung da ist, wäre es ja irgendwie Mist.
So eine Portierung lohnt sich. Durch die Konfrontation mit einer Timer-Interrupt-Routine ist bei mir plötzlich der Groschen gefallen: Ich kann ja einfach ZSMPLAY quasi wie im Hintergrund sein Ding machen lassen, seinerseits getime't durch den Soundblaster Interrupt, und alles andere unabhängig davon timen, z.B. eben mit dem Timer. Der Ton mag dann hinterherhinken, aber das nehme ich dann mal in Kauf wenn die Performance insgesamt besser ist, und die Sound Puffergröße kann ja nach belieben eingestellt werden.
Vielleicht habe ich einen Fehler in der Überlegung.
DOSferatu hat geschrieben:Für mich ist/war das ja nie ein Hype - und für mich ist es auch nicht "retro"/"retrospektiv". Das wäre es nur, wenn ich irgendwann mal zwischendurch damit aufgehört hätte und jetzt aus Nostalgie wieder damit anfangen würde.
Bei mir ist es so dass ich viel Zeit mit "aktueller" Software verbringe, und für Datenverarbeitung schonmal Freepascal bemühe, aber damit bekomme ich kein Spiel hin, und es wäre für mich auch nicht interessant, auf einem 64 Bit Rechner ein Spiel zu programmieren das eigentlich nur einen 486er braucht und nur Realmode. Und genau, das wäre uncool... Ich habe zu Zeiten wo DOS noch nicht von Windows abgelöst wurde (bis etwa 1998) in DOS programmiert, aber erst gegen Ende dieser Zeit Erfahrungen mit Assembler gemacht.
DOSferatu hat geschrieben:Ja, ich meinte damit: WENN ich ein Tool baue, dann bestimmt nicht nur dafür, damit es auf einem Emulator läuft - da kann man ja gleich das System benutzen, auf dem auch der Emulator läuft.
Es ist eine Art Bequemlichkeit und Gewöhnung, dass ich momentan keinen echten DOS-Rechner verwende. Ich habe hier einen der mit dem Emulator im Grunde beides kann, Windumm und DOS, und das parallel und gleichzeitig, und mein letzter DOS Rechner funktioniert nicht mehr. Ich verwende nicht oft genug DOS um zu sagen, ich muss mir jetzt einen neuen (alten) Rechner besorgen der dann hier zusätzlich steht und läuft und wegen dem ich einen Multiswitch brauche. Aber wenn ich etwas im Emulator programmiere bzw. laufen lasse dann habe ich schon eher das Gefühl einer DOS-Umgebung. Oft habe ich allerdings schon Gedanken, dass alles viel mehr Sinn machen würde wenn wir die Zeit um knapp 30 Jahre zurückdrehen würden. Vielleicht muss ich da mal meine Sicht ändern. Weniger, dass 486er CPUs veraltet sind, sondern vielmehr nur eine zeitlose Kategorie für sich.

Gigabyte und Gigahertz spielen eben eine Rolle wenn man rein CPU-basiert mit Multimedia zu tun hat, also Videos oder eben Musik produzieren. Ich schweife hier lieber nicht wieder aus, aber es ist eben schon praktisch was man dank der Leistung und Kapazität eines "modernen" Rechners alles machen kann, wofür man früher einen Fuhrpark an teuren Geräten brauchte, und die man alle auch einzeln bedienen und konfigurieren musste, was jetzt einfach in einem Preset komplett abgespeichert und recallt werden kann. Das würde ich bei einem "alten" DOS-Rechner vermissen. Oder eben, früher hatte ich die GUS, die hatte ich auf ihre maximalen 1 MB Sample RAM aufgestockt, bald habe ich einen Renderer Programmiert und einen Sample-Austauscher um dieses Limit und die Limitierung auf 8 Bit zu umgehen. Das habe ich etwa 20 Jahre lang so betrieben, nun nutze ich einen Tracker für Windows und ich brauche diese ewige Fummelei nicht mehr und kann mich mehr auf die Kreativität konzentrieren. Ob dieser Windows Tracker wirklich meinen aktuellen Rechner braucht sei mal dahingestellt, 1 GB RAM und 1 GHz würden wohl auch reichen. Was natürlich auch schon lächerlich viel ist, verglichen mit den Ansprüchen für ein DOS-Programm, was wir programmieren wollen.

Ich denke ich habe das mit dem ISM Mixer verstanden. Vorzeichen ist immer gut wenn man Wellenform addiert.
DOSferatu hat geschrieben:heute, mit den besseren, schnelleren Computern und den ach-so-tollen neuen Windows-Versionen geht das nicht mehr "nativ" im System (einfach eine 16bit-EXE anklicken und sie läuft), sondern man muß DOSBox und ähnliches bemühen.
Können 64 Bit CPUs überhaupt noch 16 Bit Code ausführen?

Mir fällt es nicht ganz leicht, der Sache mit dem Level-Editor zu folgen. Es ist 25 Jahre her dass ich selber so ein Konzept hatte und es war ziemlich simpel. Gezwungenermaßen, in Basic, mit meinem wenigen Wissen, hatte ich jedes Level in eine eigene EXE verpackt und diese umbenannt und mit Passwort beim Starten geschützt. Der Editor hatte eben eine feste Ausstattung an Kacheln, Feinde waren auch Kacheln, und deren Aktionen hardcoded. Aber ich würde es wohl auch ähnlich machen, die Sprites(Kacheln) einzeln laden, und ich denke ZVID2 eignet sich ganz gut, da können ja entweder nur 1 oder mehrere Sprites drinstecken. Ich habe daran immer noch nicht weitergemacht, es funktioniert im Freepascal-Test, hat bisher nur die Funktion von einem Sprite, ich muss es noch auf mehrere erweitern, das ist eine kleine Hürde wegen der komplizierten Encoderei. Aber ich freue mich dann darauf, die Assembler Routine zu schreiben, und dafür übe ich ja gerade schon am Beni Player...
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:Hallo!
Ich bin noch beschäftigt mit der Portierung des Beni Tracker Players, dürfte soweit funktionieren, jetzt schreibe ich noch den wesentlichen Teil der Player-Routine in Assembler um.
Ja, habe das so nebenher mitbekommen. Wie weit bist Du?
zatzen hat geschrieben:Ich weiss nicht wie sehr es sich lohnt, aber es ist auch ein bisschen eine Idealismus-Sache die mir gerade Spaß macht.
Naja - heutige DOS-Programmierer bewerten generell doch nicht mehr in Kategorien von "sich lohnen"...
zatzen hat geschrieben:Hochsprachen machen ja das Programm für den Programmierer z.B. bei Datenfeldzugriffen übersichtlicher, für die Maschine aber je nachdem nur komplizierter. Ich denke man kann den Code und die Ausführungsdauer schrumpfen, wenn man alles gut mitdenkt und z.B. Offset-Register für Array-Adressierungen auch einfach mal auf ihrem Wert belassen kann. Und IF/ELSE kann man auch schön gestalten, gerade in einer Routine, dann kann man sich einen Sprung sparen und vor dem ELSE Teil einfach schon mit RET zurückkehren.
Tja, in Assembler (obwohl ja oft von so ... Typen ... behauptet wird, wie ach-so-schwer das ist und daß es keiner mehr braucht) kann man oft viele Dinge recht kreativ und elegant lösen, was man in manchen Hochsprachen umständlich umschreiben müßte.
zatzen hat geschrieben:Ich habe die letzten Tage etwas intensiver in dem Assembler FAQ gelesen. Mir ist nur nicht ganz klar, welcher Typ von CALL es ist wenn ich in Pascal eine Procedure aufrufe bzw. in einem ASM Teil eben CALL (Assemblerroutine ohne Parameter) verwende. Es gibt da ja verschiedene, und die über einen Pointer brauchen um die 30 Takte, was nicht so toll ist.
Hatte ich ja glaub schon im letzten Beitrag im anderen Thread beantwortet - in Pascal ist es FAR CALL (es sei denn, man hat generalisiert NEAR eingestellt, geht über Compilerschalter) - aber wie Dir ja klar sein dürfte, gehen NEAR CALLs nur so lange, wie man sich im gleichen Segment befindet. Und Zeug in Units wird generell FAR aufgerufen. CALLs innerhalb von "Assembler-Blöcken" (also etwas, das zwischen asm und end; steht) sind immer NEAR - außer wenn man's manuell anders angibt.
zatzen hat geschrieben:Ja, diese Touchscreen-Sache ist ein Fluch. Es gibt jetzt auch schon Mäuse ohne Mechanik. Design-Wahnsinn...
Igitt.
zatzen hat geschrieben:Aber der Touchschreen hat Smartphones möglich gemacht.
Ein weiterer Punkt, der gegen Touchscreens spricht. Smartphones sind das Pendant zu dem, was für die vorige Generation TV ist: gerätgewordene Volksverblödung...
zatzen hat geschrieben:Was bleibt ist aber dass Touchscreen einfach gegen die Ergonomie ist, zumindest für alle, die nicht zu den Meistern des Wischens gehören.
Ach, wenn jemand wischen will, kann er auch herkommen... Der Flur sieht schon wieder aus, könnte auch mal gewischt werden...
Ich brauche zur Bedienung etwas, das ich drücken kann und was dann irgendwie reagiert und was ich ertasten kann, ohne hinzugucken. Und ich will nicht gleichzeitig die Anzeige UND meine Hände sehen. Das nervt.
zatzen hat geschrieben:[Lautstärken...]Deswegen habe ich das bei mir nichtlinear gemacht, ursprünglich ja um einfach mit Bitshifting die Lautstärke einstellen zu können, letztlich waren 6 dB Sprünge aber dann doch zu grob, daher habe ich noch eine Zwischenstufe eingeführt.
Man könnte auch sagen, ich gehe da relativ vor. Aber nicht additiv relativ, sondern multiplikativ. Ich könnte mir über eine Tabelle vielleicht ein Dutzend Takte sparen, aber diese Tabelle bräuchte 16 * 256 * 2 (16 Bit Integer) Bytes, das ist dann irgendwie nur gerechtfertigt wenn ich mich nicht mehr über ZSMs freuen will die kleiner als die Tabelle sind. Ich kann mir ja die Code-Zeilen nochmal ansehen.
Klar. Bei mir sind es ja nur insgesamt 16 mögliche Lautstärken bei gleichzeitig auch mögliche Werte 0..15. Da geht relativ sowieso nicht. Könnte das zwar machen, weil es ja über eine Tabelle (256 Bytes) geht - aber dann funktioniert das mit dem Aufaddieren nicht mehr "gefahrlos" (ohne Clipping). Naja, bei ISM ist sowieso alles so primitiv wie möglich gelöst.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Achnaja, die Konkurrenz ist es bei mir ja kaum noch. SO VIEL wird ja nicht grade für DOS neu rausgebracht.
So habe ich das noch gar nicht gesehen. Eher so, dass nur noch wenig Leute mit DOS arbeiten und die Konkurrenz gegeben ist durch die neuen Betriebssysteme und dass es auf denen eben z.B. Tracker gibt, mittlerweile sogar einer im Browser.
So etwas zählt für mich gar nicht. Dinge wie Windows, MacOS oder Linux zähle ich nicht zu meiner direkten Konkurrenz - nichts davon nehme ich wirklich ernst.
zatzen hat geschrieben:Die Frage ist auch, wer setzt sich hin und macht Musik im ZSM-Format... Das müsste schon ein Liebhaber sein.
... oder jemand, der ZSM gebaut hat. Und die Musik für ein Spiel machen will. Aber ZSM hat ja soweit ich weiß keinen eigenen Editor, es nutzt ja quasi als Eingabedaten MODs, die mit anderen Trackern gemacht werden. Also ist (derzeit) "Musik im ZSM-Format machen" ja einfach nur: MODs machen, die außer Lautstärkeänderungen keinen der "MOD-Effekte" nutzt und es dann in ZSM konvertieren.

Aber mit ISM ist es ja ähnlich: Das hat zwar einen Editor (eigentlich sogar 2). Aber da würde sich wohl auch nur jemand damit abquälen, wenn er auf diesen Krüppelsound steht bzw. irgendwie Musik/SoundFX für meine Spiele machen wollen würde. D.h. da gehe ich davon aus, daß das auch keiner weiter außer der Entwickler (also ich) benutzen wird. - Obwohl Du ja damit auch schon etwas experimentiert hast. Aber das ist wohl auch insgesamt nicht so Deins. Kann ich auch verstehen. Als wirklicher Musiker hat man auch andere Ansprüche.
zatzen hat geschrieben:Bisher ist es ja eher eine Spielerei wobei ich massenweise Musik darein konvertiere, die durch die Limitierungen des Formats nicht beschnitten werden. Die Limitierungen bestehen ja im wesentlichen darin, dass ich keine Effekte ausser Lautstärke verwende. Das liegt daran, dass die meisten Effekte mit 50 Hz gerastert sind.
Die Rasterung auf 50 Hz (oder 60 Hz) macht ja auch Sinn - immerhin stammt MOD ja vom Amiga. Und Musik (für Spiele/Demos usw.) hat man oft zur Bildsynchronrate angepaßt, da konnte man es im Rasterzeileninterrupt laufen lassen - damit sich das nicht mit dem Bildrefresh und so Sachen überschneidet.

Ich finds 'ne steinkalte Schande, daß VGA keinen Rasterzeileninterrupt hat (oder wenigstens einen VR-Interrupt). Es soll wohl einige wenige Modelle von manchen Herstellern geben, die sowas haben, aber das bringt ja nichts, wenn es kein allgemein nutzbarer Standard ist.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Dabei geht es mir gar nicht um irgendwelche Genauigkeiten, sondern eher darum, Sounds höhenlastig "hisssen" oder baßlastig "hummmen" zu lassen, um damit bestimmte Geräusche oder Instrumente pseudomäßig imitieren zu können.
Ein einfaches Hochpassfilter wäre, Deltas zu bilden. Und möglicherweise kann man einen Tiefpass machen, indem man von der Originalwelle diese Deltas abzieht.
Naja, mein angedachter Ansatz wäre ja, Tiefpaß durch so "Mittelwert" Zeug zu machen und Hochpaß, indem man erst eine Berechnung wie für Tiefpaß macht und den realen (ungefilterten) Wert dann vom Tiefpaß abzieht (bzw. umgekehrt). Aber naja, diese Filtergeschichte, das werde ich mal IRGENDWANN in ISM einbauen. Momentan habe ich andere Prioritäten.
zatzen hat geschrieben:So eine Portierung lohnt sich. Durch die Konfrontation mit einer Timer-Interrupt-Routine ist bei mir plötzlich der Groschen gefallen: Ich kann ja einfach ZSMPLAY quasi wie im Hintergrund sein Ding machen lassen, seinerseits getime't durch den Soundblaster Interrupt, und alles andere unabhängig davon timen, z.B. eben mit dem Timer. Der Ton mag dann hinterherhinken, aber das nehme ich dann mal in Kauf wenn die Performance insgesamt besser ist, und die Sound Puffergröße kann ja nach belieben eingestellt werden.
Vielleicht habe ich einen Fehler in der Überlegung.
Naja, im Prinzip ist das, was Du da beschreibst genau das, was ich mache. Die "Spielroutine" wirft quasi ein Signal (über einen Puffer) raus, wenn etwas "außerhalb" passieren soll - z.B. eben ein Soundeffekt starten oder eine Musik oder so. Und die Hauptschleife ist dafür verantwortlich, das der Soundgenerator-Subroutine zu übermitteln. Und ich kann sowieso nicht "mitten in die Soundpuffergeneration hineingrätschen", sondern wenn etwas neues kommt (z.B. neuer Soundeffekt/Musik zu starten) passiert das nur zwischen zwei Puffergenerationen. D.h. der Minimalversatz ist eine Soundpufferlänge - aber EIGENTLICH sogar fast 2, denn der Puffer, den man als nächstes generiert, wird ja erst beim übernächsten Mal abgespielt (Doublebuffering):

A:Puffer_der_gerade_gespielt_wird
B:Puffer_der_momentan_generiert wird
C:Nächster_Puffer (auf dem Platz, wo A war)

In den ersten (A) Puffer kann man nichts hineinmuxen, der wird ja gerade abgespielt.
In den zweiten (B) Puffer kann man auch nichts hineinmuxen, der wird ja gerade berechnet.
D.h. man gibt ein Signal aus ("Soundeffekt gebraucht", "neue Musik starten") und das passiert, irgendwann während A gespielt und B generiert wird und wird quasi vom Soundgenerator "wahrgenommen", wenn er mit dem Bauen von B fertig ist. Er wechselt dann zum Abspielen von B (sobald A fertig gespielt ist), A wird dann vom nächsten Puffer (C) überschrieben und in diesen wird das neue Zeug (Soundeffekt(e), evtl. neue Musik) eingerechnet.

Deshalb ist der Versatz zwischen 1,0 und 1,9999 Puffer. Und anders geht's meiner Meinung nach wohl auch nicht. Das "live" Ausführen, sobald angefordert funktioniert auf alten Konsolen, weil die einen dedizierten Soundchip haben, der neben der CPU her arbeitet und sofort etwas macht, sobald man es will. Aber so Dinge wie die Sound Blaster wollen ja erst einen fertig berechneten Puffer.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Für mich ist/war das ja nie ein Hype - und für mich ist es auch nicht "retro"/"retrospektiv". [...]
Bei mir ist es so dass ich viel Zeit mit "aktueller" Software verbringe, und für Datenverarbeitung schonmal Freepascal bemühe, aber damit bekomme ich kein Spiel hin, und es wäre für mich auch nicht interessant, auf einem 64 Bit Rechner ein Spiel zu programmieren das eigentlich nur einen 486er braucht und nur Realmode. Und genau, das wäre uncool... Ich habe zu Zeiten wo DOS noch nicht von Windows abgelöst wurde (bis etwa 1998) in DOS programmiert, aber erst gegen Ende dieser Zeit Erfahrungen mit Assembler gemacht.
Ja, so richtig mit Programmieren auf PC (DOS) habe ich erst ca. 1996 angefangen (da hatte ich meinen ersten eigenen PC) und damals noch 100% in Pascal. (Davor, 1993-1994 nur auf PC in der Schule, auch in Pascal.) D.h. als ich mit Coden unter DOS auf PC angefangen habe, war Windows95 gerade draußen. Habe auch nie gedacht, daß diesen Kram mal jemand als Betriebssystem erstnehmen könnte. Und selbst heute funktioniert Windows noch nicht richtig, obwohl die schon etliche Versionen weiter sind.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ja, ich meinte damit: WENN ich ein Tool baue, dann bestimmt nicht nur dafür, damit es auf einem Emulator läuft - da kann man ja gleich das System benutzen, auf dem auch der Emulator läuft.
Es ist eine Art Bequemlichkeit und Gewöhnung, dass ich momentan keinen echten DOS-Rechner verwende.
Naja, was ich damit ausdrücken wollte, war: Ich optimiere bestimmt nicht für einen Emulator - sondern mein Zielsystem ist die echte Maschine. Wenn es die echte Maschine hinkriegt, der Emulator nicht, dann ist der Emulator schuld - nicht mein Programm und nicht die echte Maschine.

Hinweis: Die Macher von DOSbox haben den ROL/ROR Bug wohl gelöst und in selbstcompilierbaren Sourcen ist der schon raus - aber es gibt noch keine offizielle neue DOSBOX.EXE damit (also v0.75 oder so).
Aber man kann sich momentan damit behelfen, daß man bei der Einstellung in dosbox.conf beim Parameter core= immer dynamic nimmt. Da tritt der Bug auch jetzt schon nicht auf.
zatzen hat geschrieben:Ich habe hier einen der mit dem Emulator im Grunde beides kann, Windumm und DOS, und das parallel und gleichzeitig, und mein letzter DOS Rechner funktioniert nicht mehr. Ich verwende nicht oft genug DOS um zu sagen, ich muss mir jetzt einen neuen (alten) Rechner besorgen der dann hier zusätzlich steht und läuft und wegen dem ich einen Multiswitch brauche.
Naja, ich mußte mir keinen neuen (alten) Rechner besorgen. Der funktioniert ja hier seit Jahr und Tag vor sich hin. Wie schon gesagt: Hatte nie damit aufgehört und deshalb steht mein geliebter 486er immer hier auf dem Master-Platz. Es ist immer der erste Rechner, den ich einschalte und der letzte, den ich ausschalte.
zatzen hat geschrieben:Aber wenn ich etwas im Emulator programmiere bzw. laufen lasse dann habe ich schon eher das Gefühl einer DOS-Umgebung.
Für dieses Gefühl brauche ich keinen Emulator. Ich hab ja "the real thing" hier.
zatzen hat geschrieben:Oft habe ich allerdings schon Gedanken, dass alles viel mehr Sinn machen würde wenn wir die Zeit um knapp 30 Jahre zurückdrehen würden. Vielleicht muss ich da mal meine Sicht ändern. Weniger, dass 486er CPUs veraltet sind, sondern vielmehr nur eine zeitlose Kategorie für sich.
Mit Begriffen wie "veraltet" tue ich mich sowieso schwer. "Alt" ist für mich nicht das gleiche wie "veraltet". Nur weil etwas alt ist, muß es nicht veraltet sein. Veraltet - solche Wörter werden von Firmen benutzt, die Leuten ihr neues Zeug verkaufen wollen. So lange etwas funktioniert und tut, was ich will und brauche, ist es für mich nicht veraltet.
zatzen hat geschrieben:Ich denke ich habe das mit dem ISM Mixer verstanden. Vorzeichen ist immer gut wenn man Wellenform addiert.
Ja, sonst kommt der Sound "aus der Mitte heraus". Die "Todeslinie" beim Sound ist ja nicht "unten" oder "oben", sondern in der Mitte und die Wellen sind "drumherum". Und mein erster Ansatz hatte die eben "unten" (bei 0) und alles darauf aufaddiert. Aber habe das in so Programmen abgespielt. Es war hörbar, aber es klang teilweise schräg, mit so "wandernden Lautstärken" usw... - was aber auch klar ist, wenn man drüber nachdenkt.
zatzen hat geschrieben:
DOSferatu hat geschrieben:heute, mit den besseren, schnelleren Computern und den ach-so-tollen neuen Windows-Versionen geht das nicht mehr "nativ" im System (einfach eine 16bit-EXE anklicken und sie läuft), sondern man muß DOSBox und ähnliches bemühen.
Können 64 Bit CPUs überhaupt noch 16 Bit Code ausführen?
Jein.
Auch 64 Bit CPUs starten noch im sogenannten "Legacy Mode": 16bit bzw 16bit/32bit Mode. In diesem Modus sind sie abwärtskompatibel bis hin zur ältesten 8086 von 1981. Aber im nativen 64bit Mode können sie nur 64bit- und 32bit-Programme ausführen (außer die 32bit sind "zu komisch" programmiert), aber kein 16bit mehr. Bin mir nicht sicher, hab mal gehört, daß der V86-Mode irgendwie bei einer 64bit-CPU Generation kaputt war und die den deswegen abgeschaltet haben und nicht mehr supporten. Weil ja im 64bit der V86 sowieso nicht läuft, bin ich jetzt nicht sicher, ob das den "Legacy" Mode betrifft. Es würde bedeuten, daß zwar 16bit-Mode noch geht, aber nicht dieser V86-Mode, den so DOS-Leute so gern benutzen (weil der erst so Dinge ermöglicht wie UMB, HMA und so und damit das "Hochladen" von Zeug, was schön viel Heap freiäßt).
zatzen hat geschrieben:Mir fällt es nicht ganz leicht, der Sache mit dem Level-Editor zu folgen. Es ist 25 Jahre her dass ich selber so ein Konzept hatte und es war ziemlich simpel. Gezwungenermaßen, in Basic, mit meinem wenigen Wissen, hatte ich jedes Level in eine eigene EXE verpackt und diese umbenannt und mit Passwort beim Starten geschützt. Der Editor hatte eben eine feste Ausstattung an Kacheln, Feinde waren auch Kacheln, und deren Aktionen hardcoded.
Naja, ein 2D-Level ist für mich einfach wie ein gedachtes 2-dimensionales Array, in dem die Nummern der Kacheln drinstehen. Das ist ja nicht so kompliziert. Für ein "selbstscrollendes" (und nur in eine Richtung) Level gäbe es noch andere Möglichkeiten. (Manfred Trenz hat da für Katakis (C64) echt geile Ideen gehabt, kann ich mal erklären, wie das funktioniert hat, falls Interesse.)
zatzen hat geschrieben:Aber ich würde es wohl auch ähnlich machen, die Sprites(Kacheln) einzeln laden, und ich denke ZVID2 eignet sich ganz gut, da können ja entweder nur 1 oder mehrere Sprites drinstecken.
Naja, ich meinte, daß Levels aus verschiedenen Bestandteilen bestehen: Level, Levelkacheln, Sprites, Musiken, Soundeffekte. Und manches davon kann man in einem anderen Level weiter benutzen, ohne es nochmal extra in den Leveldaten des anderen Levels NOCHMALS mit einzubauen. Beispiel: Soundeffekte, da hat ja nicht jedes Level andere, weil wenn ähnliche Figuren vorkommen, sinds auch gleiche Effekte. Oder: Das Level (d.h. die "Matrix"/Anordnung) der Kacheln kann zwar anders sein im neuen Level, aber es kann ja die gleichen Kacheln benutzen, wenn es zur gleichen "Welt" gehört. Sowas wie: Eine "Welt" besteht aus je 3 Levels und das Spiel hat 5 "Welten", somit 15 Levels... Und manche Musiken (z.B. eine "Endgegner-Musik") kann ja auch mehrmals benutzt werden und braucht dann nicht 15x im Datenfile vorliegen.

Und meine neue Idee dazu ist eben, daß ein "Level" nicht die Daten enthält, sondern nur die Namen der Files (und ein paar Parameter), aus denen es besteht, bzw. die es braucht. Und die eigentlichen Files sind unabhängig davon im Datenfile verteilt. Eigentlich ist die Idee nicht so die totale Revolution oder so - aber vorher hatte ich daran eben nicht gedacht.
zatzen hat geschrieben:Ich habe daran immer noch nicht weitergemacht, es funktioniert im Freepascal-Test, hat bisher nur die Funktion von einem Sprite, ich muss es noch auf mehrere erweitern, das ist eine kleine Hürde wegen der komplizierten Encoderei. Aber ich freue mich dann darauf, die Assembler Routine zu schreiben, und dafür übe ich ja gerade schon am Beni Player...
Naja, wenn EIN Sprite funktioniert, funktionieren ja auch 100. Ist ja kein Hexenwerk, eine Spriteroutine mehrmals aufzurufen. Es sei denn, ich habe das "Problem" jetzt nicht ganz verstanden.

Meine ersten Sprites bei Xpyderz (in den Ur-Versionen) waren einzelne "Datenarrays" (also Länge*Breite Pixel), die einzeln vorlagen. Meine jetzigen Sprites liegen ja wie schon erwähnt in einem 256 Bytes (also Pixel) breiten flächigen Ding neben/über/untereinander als Images. Und so zusammenhängende Image-Planes kann ich dann eben auch einzeln nachladen - und, was noch wichtiger ist: ENT-laden. D.h. wenn ich in einem Level bestimmte Images nicht brauche, sind die auch nicht geladen. Sprite-Images sind ein totaler Speicherfresser - da muß man ziemlich aufpassen, vor allem wenn diese auch noch animiert sind. Jede Bewegungsphase braucht ja wieder ein neues Image.

Naja, und weil ich Speicher sparen will, gibt es ja auch meine 15-Farb (4bit) Sprites, die quasi nur halb so viel Speicherplatz brauchen, plus 16 Byte für eine Palette (von Farbnummern). Und wenn man so Paletten benutzt, kann man Images ja auch noch verschieden einfärben und hat gleich noch mehr Figuren, die sich nur im Farbschema unterscheiden. Es ist manchmal schon erstaunlich, was eine einfache andere Farbanordnung mit dem gleichen Image anzustellen vermag. Sieht man ja auch in diesem TGAME.EXE: Das ist alles das gleiche Männchen mit nur ein paar Bewegungsphasen und auch nur rechtsseitig. Der Rest passiert mit Spiegeln (für andere Richtung) und dann mit Paletten und man hat 8 verschiedene Männchen verschiedener "Nationalität".

Gut, das soll es erst einmal von mir gewesen sein. Auf den anderen Thread/Beitrag antworte ich auch demnächst mal.

P.S.: Mein Skript-Interpreter ist übrigens fertig und ich baue damit schon an den Submenüs des neuen Editors herum. Das Colors (Paletten) Menü funktioniert schon super. Da kann man auch so z.B. Farbverlaufs-Farben für die Palette erzeugen (von Farbe A bis Farbe B), linear, logarithmisch steigend/fallend/symmetrisch. Und Gamma-Anpassung usw). Naja. Muß man wohl selbst sehen. Und das macht alles das Skript mit den Befehlen. OK, das Skript hat schon teilweise was von Brainfuck, aber wenn man da gescheit baut, dann kann man cooles Zeug machen. Es supportet ja so Variablen verschiedenen Typs, auch Zugriffe auf die Pascal-Variablen und auf Speicher. Außerdem hat es Labels und die Parameter gehen durch einen Formelinterpreter... usw. Naja, es geht schon eine ganze Menge damit. Und das Ding ist in 100% Assembler gemacht.
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 »

Ich antworte hier schonmal...
DOSferatu hat geschrieben:[Portierung des Beni Tracker Players]Ja, habe das so nebenher mitbekommen. Wie weit bist Du?
Ich bin soweit fertig mit der Unit. Die eigentliche Abspielroutine habe ich erstmal nur 1:1 in Assembler umgeschrieben, aber dabei die Möglichkeiten von Assembler genutzt, Register öfters auf ihrem Wert belassen zu können, und auch Berechnungen beim Adressieren von Speicher stark zu vereinfachen oder zu vermeiden. Datenfeldadressierungen in Pascal arten ja je nachdem im Kompilat in Code mit MUL-Anweisungen aus. Ich dachte noch dran, die Abspielroutine ganz neu nach meinem eigenen Gutdünken zu schreiben, wenn ich die Vorgänge verstanden habe. Aber die Mühe schien mir vorerst zu groß. Aber so eine Unit kann man ja jederzeit updaten und trotzdem nach außen hin abwärtskompatibel halten. Immerhin ist das Kompilat durch die Umsetzung in Assembler schon um ein paar KB geschrumpft.
Was ich aber gemacht habe, und da kennst Du mich mittlerweile, ist dass ich die Patterndaten komprimiert im Speicher ablege. Diese werden vom Tracker schon relativ intelligent angelegt, nämlich Track-weise, und man muss selbst im Tracker ein mehrspuriges "Order" aus diesen Einzelspalten zusammenstellen. Diese Spalten-Patterns haben je 64 Einträge, die wiederum aus Note, Oktave, Instrument, Effektnummer und Effektdaten bestehen. Der Tracker speichert diese Informationen jeweils zusammengepackt in 3 Bytes, der Player expandiert das aber im Original auf 5 Bytes und legt es im EMS ab, zusätzlich richtet er einen Puffer im Datensegment ein für alle 9 Kanäle, der für jeden Order aus dem EMS gefüttert wird, also 5 Bytes * 64 * 9.
In BASIC kam dann noch Faktor zwei dazu, weil es nur Integer aber nicht Byte kennt. Ich mache ziemlich das Gegenteil, lege die Patterndaten auf den Heap, aber komprimiert: Jedes Spaltenpattern bekommt eine Tabelle, die alle Ereignisse (Byte-Triplets) enthält, aber mit jeglichen Redundanzen rausgekürzt. Dazu kommt 64 mal eine Info, welcher Tabelleneintrag zu welcher Zeile gehört, diese Info nur so viele Bit breit, wie zur Adressierung aller Tabelleneinträge nötig ist. Angenommen man hat typischerweise Tabelleneinträge < 17, dann reichen 4 Bit-Werte für die Adressierung und die Tabelle ist maximal 16*3 Bytes groß. Man hat dann also statt 192 Bytes für das unkomprimierte Pattern nur 16*3 + 32 Bytes = 80 Bytes, plus ein paar Bytes für die Deklaration der Bitbreite der Adressierung und der Offsets der Tabellen und Adressreferenzen. Insgesamt ergeben sich nicht selten Kompressionsraten auf geringer als 25%, da z.B. bei Schlagzeug oder simplen Melodien die Redundanzen noch stärker ausgeprägt sind. Nehmen wir ein Bassdrum-Pattern als Extrem, zwei Tabelleneinträge (Bassdrumereignis und Leerzeile), dazu eine 1 Bit Adressierung, also 6 + 8 Byte.
Und ich brauche keinen Puffer, die Daten werden für jede Zeile/Track sozusagen mit "random access" gelesen. Ein paar Offsets und Daten werden eingelesen und ein bisschen gerechnet. Wohl kaum langsamer als ein multidimensionaler Array-Zugriff in Pascal formuliert. Zumal nach der Bit-Fummelei (Byte-Offset berechnen (Bitposition SHR 3, wobei Bitposition = Bits * Zeile, kann man in ADDs statt MUL aufbrechen), dort ein Word einlesen, Bitversatz berechnen (Bitposition AND 7) und um diesen rechtsshiften, mit Bitmaske (1 shl bits - 1) ANDen) alle fünf Werte (Note, Oktave usw.) aus der Tabelle extrahiert werden, was wohl wiederum langsamer wäre wenn man dies in fünf Pascal-Anweisungen aus Arrays bezieht.
Hier noch die bisherige Interrupt-Routine:

Code: Alles auswählen

procedure introut_playtick; interrupt; assembler;
asm
  mov btplay_next_tick, 1
  call btplay_playtick
  mov ax, tickervalue
  add tickerwrap, ax
  jc @call_oldint
    mov al, 020h
    out 020h, al
    jmp @end
  @call_oldint:
    call old_intvec
  @end:
end;
RET oder IRET hat hier nicht funktioniert, daher JMP @end. Ist da vielleicht noch etwas auf dem Stack?
btplay_playtick ist die "dicke" Abspielroutine, der Kern der ganzen Sache.
DOSferatu hat geschrieben:Tja, in Assembler (obwohl ja oft von so ... Typen ... behauptet wird, wie ach-so-schwer das ist und daß es keiner mehr braucht) kann man oft viele Dinge recht kreativ und elegant lösen, was man in manchen Hochsprachen umständlich umschreiben müßte.
Wenn man es einmal verstanden hat ist es sehr einfach, nur muss man ja auch dazu noch eine Vorstellung haben was auf Low-Level-Ebene wirklich passiert. Mir hat mal jemand "zugesichert" dass heutige z.B. C-Compiler so intelligent wären, dass sie so optimal kompilieren dass man es auch in direktem Assembler nicht besser machen könnte. Möglicherweise trifft das auf 32 und 64 Bit Code tatsächlich zu, dass dieser "intelligent" aus einer Hochsprache hervorgehend optimal performt - vielleicht vor allem wenn es objektorientierte Programmierung ist, wovon ich aber keine Ahnung habe.
In DOS jedenfalls lohnt sich Assembler, wie ich schon gesehen habe, dass eine Zeile Pascal-Code auf mehr als doppelt so viel Takte und deutlich mehr Instruktionen gebläht wurde als dasselbe intelligent in Assembler formuliert.
Die Beni Tracker Player Portierung besteht zu ca. 95% aus Assembler, da bekommt man langsam Lust oder den Mut, sich komplett von Pascal zu verabschieden und alles in Assembler zu schreiben. Man müsste nur mehr kommentieren, sonst kann man bei den ganzen Anweisungen doch schonmal die Übersicht verlieren. Aber naja, selbst wenn alle Procedures in Assembler geschrieben sind ist ein bisschen Pascal-Code als Gerüst doch ganz nett.

CALLs: Wenn ich nicht irre (und ich meine so hab ich es auch im ASM FAQ gelesen) gilt RET sowohl für NEAR als auch für FAR CALLs. Mir schwirrte noch "RETF" im Kopf, aber das gibt es wohl gar nicht.
DOSferatu hat geschrieben:Dinge wie Windows, MacOS oder Linux zähle ich nicht zu meiner direkten Konkurrenz - nichts davon nehme ich wirklich ernst.
Der große Unterschied zu DOS ist das Multitasking (auch wenn es nur emuliert ist), das ich bei DOS vermissen würde. Bei DOS hatte man ja immerhin schon eine Faszination dafür, nämlich wenn man TSRs benutzt hat. Sei es um gleichzeitig Musik zu hören und etwas anderes tun zu können, oder einen Screengrabber zu nutzen. Ich würde mich mittlerweile schon etwas eingeschränkt fühlen wenn ich immer jedes Programm erst beenden müsste um ein anderes zu benutzen, vor allem wenn ich eigentlich beide eher parallel brauche.
DOSferatu hat geschrieben:[ISM]Obwohl Du ja damit auch schon etwas experimentiert hast. Aber das ist wohl auch insgesamt nicht so Deins. Kann ich auch verstehen. Als wirklicher Musiker hat man auch andere Ansprüche.
Ich verstehe mich eher als halber Musiker, bin zwar im Kopf musikalisch, spiele aber kein Instrument, und die Musik die ich mache ist meistens eher so dass sich die Strukturen alle paar Takte wiederholen und es keine großen Spannungsbögen gibt wie bei den großen klassischen Komponisten. Ich bin einfach in letzter Zeit nicht so kompositionswütig, selbst ganz "ernst gemeint" werfe ich vielleicht alle zwei Monate mal ein Liedchen ab was ich "professionell" ausproduziere, und entsprechend noch weniger mache ich dann etwas "zum Spaß".
DOSferatu hat geschrieben:Ich finds 'ne steinkalte Schande, daß VGA keinen Rasterzeileninterrupt hat
Ich habe vor Jahren mal in irgendeinem Code kommentiert gelesen "wait for vertical retrace". Ich bin mir nicht sicher ob das auch mit CRTs zu tun hatte und bei TFTs & Co. gar nicht funktioniert hätte.
DOSferatu hat geschrieben:[Soundpuffer]Das "live" Ausführen, sobald angefordert funktioniert auf alten Konsolen, weil die einen dedizierten Soundchip haben, der neben der CPU her arbeitet und sofort etwas macht, sobald man es will. Aber so Dinge wie die Sound Blaster wollen ja erst einen fertig berechneten Puffer.
Viele Spiele nutzen ja die Kombination Adlib + Digisound, und letzterer geht dann nicht über einen Mischpuffer sondern spielt nur per DMA direkt Sounddaten ab, das geht dann ohne Verzögerung, aber eben nur "einstimmig".

Was Puffer-berechneten Sound angeht muss ich mir mal ein paar Spiele ansehen, wie z.B. Pinball Dreams, die Konversion vom Amiga, bei dem ich mich an keine besonderen Verzögerungen erinnere.

Dosbox: Sehr erfreulich dass der ROR/ROL Bug wahrscheinlich demnächst raus ist.
Für mich stellt Dosbox ein wenig auch soetwas dar, wie meinetwegen Ende der 80er Leute z.B. für den C64 oder Konsolen in einer technisch fortschrittlicheren Umgebung programmierten. Es ist nicht ganz damit zu vergleichen aber ich habe vor allem zwei Vorteile: Ich kann einen Hex-Editor oder andere Daten-lesende Programme parallel laufen lassen ohne dass ich für einen Refresh der Daten Pascal beenden muss. Und was ich schonmal sagte, bei dummen Programmierfehlern, sei es in Assembler oder Pascal, die zu einem Absturz führen, muss ich keinen echten Rechner neu booten. Kurzgesagt, das Debugging innerhalb einer Multitasking-Umgebung ist für mich wenigstens einfacher.

Es wäre natürlich schön, wenn mein aktueller Rechner noch 16 Bit DOS könnte, selbst wenn man mal Soundblaster außen vor lässt. Mein DMF-Renderer wäre blitzschnell.
DOSferatu hat geschrieben:Naja, ein 2D-Level ist für mich einfach wie ein gedachtes 2-dimensionales Array, in dem die Nummern der Kacheln drinstehen. Das ist ja nicht so kompliziert. Für ein "selbstscrollendes" (und nur in eine Richtung) Level gäbe es noch andere Möglichkeiten. (Manfred Trenz hat da für Katakis (C64) echt geile Ideen gehabt, kann ich mal erklären, wie das funktioniert hat, falls Interesse.)
Nur in eine Richtung scrollend scheint technisch einen deutlichen Unterschied zu machen, ich denke da an Super Mario, da konnte man ja auch nur immer weiter nach rechts laufen. Das hatte wohl auch mit der Berechnung der Feindbewegungen zu tun, die somit minimiert werden konnten (Feinde bewegten sich auch erst sobald sie sichtbar waren). Ich bin aktuell eher noch am überlegen, wie ich den Grafikdatenumsatz minimal halte, und bei Scrolling sehe ich keinen anderen Weg als den ganzen Bildschirm für jeden Frame komplett neu zu zeichnen. Wenn ich dafür eine Lösung habe komme ich gerne nochmal auf die Ideen von Manfred Trenz zurück.
DOSferatu hat geschrieben:Und meine neue Idee dazu ist eben, daß ein "Level" nicht die Daten enthält, sondern nur die Namen der Files (und ein paar Parameter), aus denen es besteht, bzw. die es braucht. Und die eigentlichen Files sind unabhängig davon im Datenfile verteilt. Eigentlich ist die Idee nicht so die totale Revolution oder so - aber vorher hatte ich daran eben nicht gedacht.
Ja, ich glaube ich hätte das auch so gelöst wie Du es jetzt machst, auch wenn dadurch die Ladezeit vielleicht minimal länger wird. Oder, ein anderer Ansatz, wenn ich genug Speicher habe bzw. die Gesamtdaten klein genug - Alles am Anfang laden und dann beliebig in den Levels benutzen.
DOSferatu hat geschrieben:[ZVID2]Naja, wenn EIN Sprite funktioniert, funktionieren ja auch 100. Ist ja kein Hexenwerk, eine Spriteroutine mehrmals aufzurufen. Es sei denn, ich habe das "Problem" jetzt nicht ganz verstanden.
Es geht um das Codieren. Das (eher kleine) Problem ist, dass sich mehrere Sprites in einem Datensatz eine Meta-Palette teilen. Bisher habe ich den Encoder nur auf ein Sprite ausgelegt, bei mehreren muss die Meta-Palette je nachdem erweitert werden. Es funktioniert bisher gut für ein Sprite und für das Feature "mehrere" muss ich eben nochmal am Code rumfummeln mit der Gefahr dass Bugs reinkommen, das ist die kleine Hürde.
DOSferatu hat geschrieben:Sprite-Images sind ein totaler Speicherfresser - da muß man ziemlich aufpassen, vor allem wenn diese auch noch animiert sind. Jede Bewegungsphase braucht ja wieder ein neues Image.
Deswegen ja eben auch mein Ansatz der 4x4 Block-Kompression wodurch alles schonmal zwangsläufig nur die Hälfte belegt, jedenfalls netto. Bei Animationen wäre vielleicht auch das Rauskürzen redundanter (schonmal verwendeter) Blöcke sinnvoll, aber das wäre zu kompliziert zu realisieren im angedachten ZVID2-Format.
Aber ein wichtiger Vorteil Deiner Methode, die Grafik in Planes zu halten, ist die dass es ein festgelegter Bereich ist den man ohne Heap-Fragmentierung be- und entladen kann?
DOSferatu hat geschrieben:Es ist manchmal schon erstaunlich, was eine einfache andere Farbanordnung mit dem gleichen Image anzustellen vermag.
Ich könnte das bei ZVID2 durch ändern/austauschen der Metapalette machen, allerdings ist das doch eher umständlich und mein Grafikstil eher derjenige, der für alle Charaktere völlig eigene Bitmaps vorsieht. Hatte ich ja schonmal gesagt, und ich kenne die Umfärbung von Sprites eher nur von 8 Bit Konsolen wie NES, wo die Sprites aus 8x8 Blöcken bestehen die je nur 2 Bit haben und zwingend eine "Meta"-Palette brauchen. Aber natürlich gibt es auch andere sinnvolle Anwendungen, wenn Du "Battle Chess" kennst, die werden wahrscheinlich auch für die roten bzw. blauen Figuren auch nur anderen Paletten genommen haben.

Skript:
Ich weiss zwar jetzt aus dem Zusammenhang gerissen nicht genau, welchem Zweck so ein Script dient, aber Du sagst ja direkt einleitend dass es für einen Editor ist. Also wenn man so will für ein UI und was "dahinter" steckt. Klingt gut.
mov ax, 13h
int 10h

while vorne_frei do vor;
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Trackermodul-Engine (sehr einfach)

Beitrag von wobo »

zatzen hat geschrieben: Hier noch die bisherige Interrupt-Routine:

Code: Alles auswählen

procedure introut_playtick; interrupt; assembler;
asm
  mov btplay_next_tick, 1
  call btplay_playtick
  mov ax, tickervalue
  add tickerwrap, ax
  jc @call_oldint
    mov al, 020h
    out 020h, al
    jmp @end
  @call_oldint:
    call old_intvec
  @end:
end;
RET oder IRET hat hier nicht funktioniert, daher JMP @end. Ist da vielleicht noch etwas auf dem Stack?
Ja, die gesamten 16-bit Register, einschließlich Flags (wegen des "interrupt;").
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 »

Hallo Wobo!

Also müsste da noch rein:

Code: Alles auswählen

  popf
  popa
bzw. andersrum?

Oder gibt es auch eine Möglichkeit zu einer Interrupt-Routine, die nicht so Stack-intensiv ist?

Naja, ich seh mir auch nochmal Erklärungen im ASMFAQ zu IRET an.
mov ax, 13h
int 10h

while vorne_frei do vor;
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Trackermodul-Engine (sehr einfach)

Beitrag von wobo »

Hallo Zatzen!
Leider weiß ich das nicht. Ich habe schon mein gesamtes Wissen über TP mit meinem Einzeiler im Beitrag oben verbraten ;-).

Ich bin mir nicht einmal sicher, ob TP pusha, popa verwendet oder die Register einzelnen pusht. PUSHA und POP gibt es ja erst ab dem 286. Wahrscheinlich generiert TP Code je nach Compilerschalter. Auch wäre ich mir nicht sicher, ob BP 7.0 und TP 7.0 unebdingt denselben Code generieren.

Die Alternative ist nur, dass Du die Interrupt-Routine mit einem externen Assembler baust. Dann hast Du auch volle Kontrolle über das Code-Gerüst, das dir ja TP abnimmt.
Antworten