DOS-Forum

Das ist die Frage...
Erstmal, das Genre.

Bei Mir wäre das ganz grob Plattform - zweispieler Jump&Kill
oder 2 Spieler Plattform Jump & Help...

Aber wovon ich eigentlich schon ewig Träume wäre ein Adventure.

Nun ist die Frage, wenn ich wirklich ein Adventure machen will,
soll ich wirklich alles selbst coden mit all der Arbeit und den Bugfixes
bis das endlich mal läuft... Oder nutze ich die Allgemein frei zu Verfügung
stehende Enginge, natürlich Windows-Kompatibel, namens AGS (Adventure Game Studio).
Das wäre eigentlich das vernünftigste, wenn ich einfach mal eher zum Spass
ein solches Spiel desingen möchte. Natürlich brauche ich dazu erstmal eine
interessante Story die man vielleicht auch mit satirischen Elementen ausfüllen
kann - und daneben viel Geduld und Liebe zum Detail für die Grafiken.
AGS ist nach meinem (nicht weiter nachbestätigten Wissen) sehr flexibel,
man kann allerlei Dateiformate, auch für den Ton verwenden, wie z.B.
auch getrackterte Musik.

Viel mehr als ein DOS-fanatischer Programmierer zu sein bin ich einfach nur auf Pascal
eingeschossen, und mit Freepascal komme ich sehr gut klar. Ich habe mich nur noch nicht darum
gekümmert, wie ich davon aus Ton und Bild Ansteuere.

Nach wie vor liebe ich aber das sinnvolle und kompakte Strukturieren von Daten,
gerade so als müsse man sich mit 640K abgeben.


Wie seht ihr das?

Was würdet ihr an Spielen in die Tat umsetzen, und würdet ihr auf DOS beharren oder
doch einmal sowas wie Freepascal eine Chance geben, und die dort erweiterten Grenzen
sinnvoll(!) nutzen und nicht z.B. für Hintergrundmusik einfach eine 320kbps mp3 reinklatschen.

Wo wir bei Musik sind: @ DOSferatu:
Wie sieht mittlerweile dein geplanter Musikplayer aus? Du wolltest ja die Notendefinitionen
nicht so wie in einem Trackerpattern strukturieren sondern eher wie bei MIDI durch die
Länge einer Note definieren wie lang sie gespielt wird, wann die nächste kommt usw.
Ist das danm tatsächlich kleiner in den Daten? Und wie steht es mit Effekten wie
Portamento, Vibrato oder gar Arpeggio?

Liebe Weichnachtliche Grüße,

Zatzen

Hallo Zatzen,

ich kann als Programmierer deinen Wunsch ein neues Spiel zu kreiren gut nachvollziehen. Wenn es aber nicht gerade ein "Schiffe versenken" oder "Tic-Tac-Toe" spielen werden soll, sollte dir klar sein, daß es seeeeeeeeeeehr viel Arbeit ist und von dir alleine kaum zu schaffen sein wird.

Ich habe vor einigen Jahren mal ähnliche Pläne gehabt. Gescheitert ist das Projekt leider damals an mangelnden Grafikern. Was nützt die schönste Engine, wenn keiner ansehnliche Grafiken malen kann

Ich persönlich war von dem Remake "zak mckraken alien mindbenders" sehr angetan. Die benutzen zwar eine fertige Engine, aber die Möglichkeiten und letztendlich das Ergbnis ist fantastisch!

Wenn du doch lieber den Wunsch hast, etwas "eigenes" zu entwickeln, dann solltest du dir gut überlegen, wieviel Zeit und Ressourcen du die nächsten Monate dafür aufbringen kannst. Danach würde ich dann auch den Umfang des Spiels planen...

Grüße,
Hawk78

zatzen hat geschrieben:Das ist die Frage...
Erstmal, das Genre.

Bei Mir wäre das ganz grob Plattform - zweispieler Jump&Kill
oder 2 Spieler Plattform Jump & Help...

Bei mir ist es alles, was in 2D geht. Neulich habe ich einen "Animator" programmiert im Modus 400x300 (ModeX). Mit 400x300 kann man 2 Bildschirmseiten haben (also Double Buffering möglich). Ist einer der vielen VGA.Modes, die meine Grafik-Unit supportet. Wäre an sich schick - weil er aber ein Tweaked Mode ist, wäre natürlich fraglich, ob er auf "modernen Maschinen" läuft - nicht, daß das wirklich wichtig wäre, denn auf "modernen Maschinen" kann man meinen Mist sowieso nicht mehr spielen - außer im Emulator...

zatzen hat geschrieben:Aber wovon ich eigentlich schon ewig Träume wäre ein Adventure.

Nun ist die Frage, wenn ich wirklich ein Adventure machen will,
soll ich wirklich alles selbst coden mit all der Arbeit und den Bugfixes
bis das endlich mal läuft... Oder nutze ich die Allgemein frei zu Verfügung
stehende Enginge, natürlich Windows-Kompatibel, namens AGS (Adventure Game Studio)...

Ich für meinen Teil code nie direkt für Windows. Wenn's unter Windows läuft - Glück gehabt. Wenn nicht - es ist nunmal primär für DOS, d.h. man kann nicht erwarten, daß es auf einem Fremd-OS läuft, auch wenn rudimentäre DOS-Fragmente darin enthalten sind...

zatzen hat geschrieben:Viel mehr als ein DOS-fanatischer Programmierer zu sein bin ich einfach nur auf Pascal eingeschossen, und mit Freepascal komme ich sehr gut klar. Ich habe mich nur noch nicht darum gekümmert, wie ich davon aus Ton und Bild Ansteuere.

Ich bin auch nicht DOS-fanatisch. DOS ist sozusagen das "kleinste gemeinsame Vielfache". Das Gute an DOS ist für mich nicht das, was es hat - sondern das, was es nicht hat - als da wäre der völlig überflüssige und ressourcenfressende Überbau, den andere OS so benutzen (inkl. Dingen, die mich daran hindern, VGA-Grafikmodes abweichend der "Norm" zu nutzen oder den Ticker auf hoche Frequenzen zu setzen... - nur um einige Beispiele zu nennen). Ich weiß, daß dieser Kram nötig ist, um Multitasking zu realisieren - aber während man ein Spiel spielt, macht man ja ohnehin selten etwas anderes gleichzeitig auf dem Rechner - eine "Schalte in no-Multitask-Direkt-Modus"-Funktion, z.B. über einen INT, wäre sehr nützlich gewesen. Ja,ich weiß - das korrumpiert die Systemsicherheit. Zur Not kann man das ja vom OS sperren lassen, wenn man das nicht will... Ich habe zu viele Ideen...

zatzen hat geschrieben:Nach wie vor liebe ich aber das sinnvolle und kompakte Strukturieren von Daten, gerade so als müsse man sich mit 640K abgeben.

So geht's mir auch. Und ich muß mich ja in der Tat mit 640kB (bzw 600) abgeben (man kann nicht erwarten, daß jedser User es schafft, 610 oder 620 kB freizuschaufeln... auch wenn's schön wäre).
Ich code ja in RealMode (16bit)... höherer Speicher erschließt sich mir höchstens per XMS - und das ist natürlich nichts für "Echtzeit-Zugriffe"...

zatzen hat geschrieben:Wie seht ihr das?

Was würdet ihr an Spielen in die Tat umsetzen, und würdet ihr auf DOS beharren oder
doch einmal sowas wie Freepascal eine Chance geben, und die dort erweiterten Grenzen
sinnvoll(!) nutzen und nicht z.B. für Hintergrundmusik einfach eine 320kbps mp3 reinklatschen.

Das Problem ist, daß ich nicht nur Pascal, sondern auch ASM nutze - ASM, den ich direkt in den Pascal-Source einbauen bzw damit verzahnen kann. Mit FreePascal sehe ich da keine Möglichkeit, denn ich weiß nicht, inwieweit das dann noch kompatibel zu meinen "Tricks" wäre. Außerdem müßte man da, wenn ASM überhaupt supportet ist, dies wohl im PM machen - damit würden meine Routinen ja nicht arbeiten... Ja - ich bin wirklich von der Sorte, die sogar im Codesegment während der Laufzeit rummurksen - selbstmanipulierender Code - meist durch Registermangel...

zatzen hat geschrieben:Wo wir bei Musik sind: @ DOSferatu:
Wie sieht mittlerweile dein geplanter Musikplayer aus? Du wolltest ja die Notendefinitionen
nicht so wie in einem Trackerpattern strukturieren sondern eher wie bei MIDI durch die
Länge einer Note definieren wie lang sie gespielt wird, wann die nächste kommt usw.
Ist das danm tatsächlich kleiner in den Daten? Und wie steht es mit Effekten wie
Portamento, Vibrato oder gar Arpeggio?

Ich bin momentan noch gar nicht am Bauen des Musikplayers. Aber WENN - dann wird er wohl anders als das, was man von MOD so kennt... Das liegt einfach daran, daß ich aus der 8-Bit-Ära stamme und alles so mache wie damals. Und Musikdaten / -Player würde ich einfach instinktiv zu coden wie aufm C64. - Der Musik-Abspieler wäre in seiner Funktionsweise sowas wie der SID - auch wenn ich manche Funktionen wie Filter nur auf eine sehr kranke Weise simulieren würde/könnte, die Musikdaten wären dementsprechend so, wie man es von einem Tracker für C64-Mucke kennen würde. Ich habe von Musik und der ganzen Dynamik der Klangerzeugung wenig Ahnung, ich tue alles, was ich mache, auf rein mathematische Weise: Grafik, Musik, Steuerung... - ich kann nicht anders, weil mein Gehirn nur so funktioniert...

Aber momentan bin ich immer noch am Zusammenschustern des Sprite-/Block-/Leveleditors. Da sind noch einige Bugs, die wirklich nerven und die entfernt werden müssen. Außerdem will ich den längerfristig "zweigleisig" bauen - eine EXE für die Levels mit 16x16-Pixel-Blocks und eine EXE für die Levels mit 32x32-Pixel-Blocks. (d.h. mit Compilerschaltern). Will nicht beides gleichzeitig in dieselbe EXE tun: mehr Code = weniger Platz für Daten...
Das ganze Menüsystem (die GUI) ist schon komplett ausgelagert und wird mit so einer Art Mini-Skript gebaut. Selbst dafür habe ich einen Editor gebaut. D.h. der Editor ist nur dazu da, die Menüs zusammenzubauen (Fenster, Buttons, Eingabefelder, Pulldowns, etc...)

Also zu allem, was Klang angeht, habe ich hier noch keine aktuellen Sachen vorliegen. Geplant ist ein System, das aus 128 Befehlen besteht - mit 9bit breiten Daten, d.h. jeder Befehl belegt 16bit.
Die Befehle sind: 96, die einen Ton starten, diese enthalten gleich im Befehl den Ton selbst (96 = 12*8, also 12 Töne à 8 Oktaven), die Frequenzen werden aus einer Tabelle ausgelesen. Ich weiß, man kann die Frequenzen berechnen und auch, daß sich diese bei jeder Oktave verdoppelt - aber eine 192 Byte große Tabelle halte ich für vertretbar und es minimiert den Rechenzeitaufwand. Der Parameter des Ton-Befehls wäre die Länge.

Die restlichen 32 Befehle sind dann für administratives Zeug gedacht, z.B. um Schleifen und Subroutinen zu starten oder Dinge wie Portamento und +/-Transponieren zu ermöglichen u.ä.
Außerdem gibt es dann zwei "wechsle Instrument" Befehle. Einer generiert ein "Instrument", indem er eine 256 Byte große "Welle" erzeugt. Diese Welle kann dabei eine Mischung aus Dreieck, Sägezahn und Rechteck enthalten, mit "Umkehrpunkt"... oder eben Rauschen, das mit einem Zufallsgenerator erzeugt wird, andere legen die Hüllkurve fest - vielleicht wird es auch einen "Instrument-Header" geben. Der andere lädt Samples - nach Möglichkeit will ich Samples aber vermeiden, da diese bekanntermaßen wahre Speicherfresser sind. Abgespielt wird das auf die gleiche Art - d.h. die "Instrumente" werden auch als "Sample" generiert. Ich weiß nicht, ob ich es verständlich genug ausdrücken kann.

Das Ganze (die Daten) sieht am Ende dann jedenfalls aus wie eine Art von Maschinenprogramm, der "Player" holt die Klangwellen der einzelnen Stimmen und mischt sie zusammen. Das Ganze wird so minimalistisch ausgelegt, Lautstärken und Hüllkurven mit 4bit-Werten (um die Multiplikationstabellen nicht zu groß werden zu lassen). Für einen Klangfetischisten und Musikfanatiker wird das alles am Ende überhaupt nichts sein - meine Grafiken sind ja auch nur 8-Bit und sehen aus wie 5-Bit... alles sehr "alte Konsole" mäßig.

Ich ahne auch, daß sich die Begeisterung aller Anwesenden (außer echter "Retro" Fans) in engen Grenzen halten wird - etwas besseres als die häßliche Xpyderz-Grafik wird von meiner Seite kaum jemals zu erwarten sein, obwohl ich dieses Mal vorhabe, die Grafik von Hand zu zeichnen und zu scannen und dann mit dem Editor entsprechend auszuschneiden und in "Spielformat" für die Engines zu bringen. Und klangtechnisch ist von mir auch eher sehr Bescheidenes zu erwarten. Ich bin eben ein Coder, ich kann sonst nichts außer Coden - und selbst das nicht besonders gut..

Nun können sich freecrac und andere wieder über meinen altmodischen Müll auslassen - wird wahrscheinlich trotzdem nicht dazu führen, daß ich etwas anderes tue.

Übrigens bin ich immer noch am Überlegen, ob ich als erstes mein geplantes Jump&Run oder das Shoot'em'up (in der Art wie Katakis/R-Type/Gradius) umsetzen werden - die Engines/Editoren sind für beides ausgelegt. Das Shoot'em'up wird wohl einfacher werden, da es einfach nur das wird, "was es ist": Keine Story drumherum und keine der "krassen" Dinge, die ich mit dem Jump&Run vorhabe... Es wäre aber trotzdem auch mit Liebe und Hingabe gemacht (und mit Programmierung), und es wäre wenigstens erst einmal ein sichtbares Ergebnis meiner jahrelangen Bemühungen...

Anmerkung: Ich denke übrigens auch öfter mal wieder über Multiplayer-Systeme nach - aber das hat schon in Xpyderz nicht so geklappt wie es sollte (ja, Xpyderz war ursprünglich als Multiplayer für biszu 16 Spieler gedacht), muß da mal von Grund auf etwas an meinen IP-TCP/UDP Routinen ändern, sowie am darauf aufliegenden Multiplayer-Protokoll. Allerdings wäre die Realisierung dieser Dinge eine weitere Baustelle, die ich gern erst einmal auf später verschieben würde.

OK, erst einmal genug davon. Ich ahne schon: Wenn ich es überhaupt 2013 schaffen werden würde, ein fertiges Spiel zu präsentieren, wäre das schon eine großartige Sache... Momentan verliere ich mich wieder in Kleinigkeiten... Naja, der Fluch des Single-Programmierers. Im Team würde man sich wohl gegenseitig motivieren und etwas stringenter vorgehen - wenn es ein gutes Team ist.

Genug Gelaber für heute.

DOSferatu hat geschrieben:Ich weiß, daß dieser Kram nötig ist, um Multitasking zu realisieren - aber während man ein Spiel spielt, macht man ja ohnehin selten etwas anderes gleichzeitig auf dem Rechner - eine "Schalte in no-Multitask-Direkt-Modus"-Funktion, z.B. über einen INT, wäre sehr nützlich gewesen.

Aber auch die Spiele/Anwendungen können verschiedene Task und Threads benutzen und TSRs sind ja auch so eine Art koorperatives Multitasking, wo z.B. der Tastsaturtreiber die laufende Anwendung für einen Moment unterbricht.

Aber mit Windows/Linux ist das trotzdem nicht wirklich vergleichbar, da damit auch mehre User gleichzeitig vom OS unterstützt werden und der Rechner dann wirklich nicht nur zum Spielen von nur einem Spiel/Anwendung verwendet wird und dann auch die gesamte Leistung aufgeteilt wird.

zatzen hat geschrieben:Nach wie vor liebe ich aber das sinnvolle und kompakte Strukturieren von Daten, gerade so als müsse man sich mit 640K abgeben.

So geht's mir auch. Und ich muß mich ja in der Tat mit 640kB (bzw 600) abgeben (man kann nicht erwarten, daß jedser User es schafft, 610 oder 620 kB freizuschaufeln... auch wenn's schön wäre).

Ich code ja in RealMode (16bit)... höherer Speicher erschließt sich mir höchstens per XMS - und das ist natürlich nichts für "Echtzeit-Zugriffe"...

Dann könnte man ersatzweise auch den Unrealmode verwenden.
Oder wer hat einen 386+ Rechner mit mehr al 1 MB RAM auf dem der Unrealmode nicht funktioniert?

Dirk

Ja, den Unrealmode könnte man natürlich nutzen. Hat alles Vor- und Nachteile.
Ich muß z.B. für Dinge, die den Unrealmode (also den Flat 4G) benutzen, immer vorher neu booten mit anderer Konfiguration - da ich natürlich normalerweise EMM386 geladen habe und DOS und Treiber "nach oben" lade (um mehr Speicher "unten", also im Bereich unterhalb 640kB bzw unter $A000:$0000 freizuhaben).
Ich weiß auch, wie ich in den reinschalten müßte... Aber ich müßte auch den ganzen Kram, den ich bisher gecodet habe, darauf anpassen.
Es ist eben so: Kleine Dinge könnte man leicht umsetzen. Aber bei größeren Projekten setze ich eben Units ( = Pascal-Bibliotheken) ein, die ich schon über die Jahre so programmiert habe. Ich code ja kaum noch etwas "from Scratch", weil es natürlich Schwachsinn ist, Dinge, die man schon funktionstüchtig fertig gecodet hat, jedesmal nochmal neu zu coden...

Aber was solls. Am Ende zählt ohnehin nur "was rauskommt" - und es interessiert keinen / kaum einen, wie es gemacht wurde, solange es funktioniert. Und MEIN ZEUG funktioniert sowieso nicht mehr auf aktuellen Systemen. Und davon abgesehen: Mein Krempel funktioniert übrigens sogar bis Windows XP (32bit) ohne Emulator. Aber Schalten in den Unrealmode funktioniert natürlich NICHT, wenn darunter schon ein System läuft, das sich entweder bereits im V86-Mode befindet (EMM386 - siehe oben) und natürlich auch nicht, wenn es sich bereits im Protected Mode befindet (wie Windows es tut). Nur so als Anmerkung.
Und ja, ich weiß, daß mir der Unrealmode mehr Möglichkeiten eröffnen würde. Will nur erst einmal "mit dem, was ich habe" ein paar Sachen fertigbringen, damit ich überhaupt mal wieder ein Spiel rausbringe. Ich nenne mein Label ja IMPERIAL GAMES ... - und das hat schon seinen Grund.

Wenn ich mal zurückdenke an die Zeiten, als mich PC-Spiele am meisten fasziniert
haben, und an meine Behauptung, dass ich jetzt mit meinen Fähigkeiten nochmal in
diese Zeit zurückversetzt richtig tolle Spiele machen könnte, dann denke ich da vor
allem an die Zeit um 1992, und da war sowas wie "protected mode" noch ein Fremdwort,
zumindest für mich. Das hab ich eher zu Beginn der Windows-Ära kennengelernt,
z.B. bei Duke3D. Auch wenn es sich ergeben hat, dass ich sowas im "Clan" gegen
meine Freunde ziemlich oft gespielt habe, LAN-Treffen eben, finde ich doch den
Charme dieses Spiels nicht besonders angenehm.
Angenehme Spiele waren solche, die es z.B. auch parallel auf dem Amiga gab,
und wenn ich mich nicht täusche war damit automatisch das Auskommen mit
640K gesichert, denn der Amiga trug ja nicht ohne Grund die Zahl 500 ...

So könnte man sich den Real-Mode stilgebend als Plattform zum Ziel setzen,
und das Programmieren hat dann für mich auch mehr Reiz, als wenn man
einfach 8 MB Erweiterungsspeicher voraussetzt und diesen verschwenderisch
nutzt.
Ich war zwar 1998 erstmal begeistert, dass ich ne Anleitung für die XMS-
Nutzung gefunden habe, bin dann aber direkt in die Falle getappt:
Als Hintergrundmusik einfach fette 22kHz 8 Bit Mono WAVs und als
Hintergrundgrafik einfach ein zig-Bildschirme-großes unkomprimiertes
256 Farben Bild.

Ich denke, hier können Leistungs- und Speichereinschränkungen die
Kreativität fördern. Wer wirklich in DOS programmieren will sollte
diese Grenzen ruhig annehmen, denn sonst kann er gleich einen
Workshop in Windows-Programmierung nehmen und einfach
umsteigen. Für andere, vor allem nicht-Programmierer, zählt
nur die Fassade, während ich als Programmierer dabei ein
Gefühl habe, als wenn ich ein Gerät baue, und ich kann dabei
genießen, wie sorgfältig ich Datenstukturen anlege, wie
sauber und effizient der Code ist usw. Ich habe auch heute
noch ein technisches Vergnügen daran, bestimmte Daten-
dateien im HEX-Editor zu betrachten oder Sound-haltige
Dateien im Wave-Editor zu öffnen, auch wenn sie neben
dem Sound noch andere Daten enthalten. Mag dem ein oder
anderen vielleicht seltsam erscheinen, aber mein Verhalten
ist eben so erklärbar, dass ich gerne hinter die Fassaden
eines Spiels gucke.
Und so hat dann ein "Produkt" für mich eine ganzheitliche
Bedeutung und man bekommt ein bisschen das Gefühl,
dass es nicht nur virtuell sondern auch gegenständlich
existiert.
Das ist dann auch mein Problem mit reiner Hochsprachen-
programmierung wie sie wohl in Windows weit verbreitet
ist - ich kann überhaupt nicht mehr nachvollziehen, was
der Computer wirklich macht.

Ich selber sehe da für mich Möglichkeiten, zumindest mit dem
Speicher auszukommen und etwas zu realisieren was mir vorschwebt.
Glücklicherweise hat sich gezeigt, dass eine segmentierte, jeweils
mit Multiplikator versehene Sampledaten-Reduktion auf 4 Bit
erstaunlich wenig rauscht. Als Tonmensch ist er mir wichtig,
Trackermusik in einem Spiel zu haben. Mit dem Speicher käme
ich also wohl aus, jedoch werde ich wohl eine Leistungsanforderung
in der Nähe eines Pentium haben. Gegensätzlich, leider.
Es gibt wohl wenige "Pentium-Spiele" die nur 640K nutzen...

zatzen hat geschrieben:Wer wirklich in DOS programmieren will sollte
diese Grenzen ruhig annehmen, denn sonst kann er gleich einen
Workshop in Windows-Programmierung nehmen und einfach
umsteigen.

Von welchen DOS-Grenzen ist eigentlich die Rede, es gibt unter DOS doch gar keine solche Grenzen, ausser solche die man sich selber auferlegt, oder durch einen Mangel an Wissen über die Hardware vorhanden ist.

Es gibt aber genug DOS-Spiele die mehr als 1 MB RAM-Speicher benutzen und dafür den Unrealmode verwenden.
Weil es unter puren DOS gar keine Grenzen gibt den gesamzen Speicher zu verwenden.
Ein DOS-Spiel könnte auch selber in den 64 Bit-Mode schalten und auch mehrere CPU-Kerne verwenden.

DOS kann man deswegen wohl auch als eines der grenzenlosesten Betriebssysteme für x86-PCs bezeichnen.

Man muss mit einem grösseren Speicherbereich auch nicht unbedingt verschwenderisch umgehen, allerdings wenn vorhandener Speicher nicht anderweitig genutzt wird, dann ist es somit auch nicht von Bedeutung, ob und wie der Speicher benutzt wird, solange unsere Anwendung selber davon Gebrauch macht, bzw. andernfalls sonst dieser Speicher völlig ungenutzt bleibt.

..

Unter Windows darf man aber gar nicht selber direckt auf seine Hardware zugreifen, insofern kann es darüber auch keinen Workshop geben, weil dort darf man nur einen Teil der vorhandenen Resourcen die Windows uns erlaubt zu benutzen verwenden und so ist man bei der Windowsprogrammierung auf die Dienste von Windows begrenzt. Eine Windows-Anwendung für ein 32Bit-Windows darf und kann nicht selber in den 64 Bit-Mode schalten. Unter puren DOS gibt es diese vermeidbaren Grenzen nicht für DOS-Programme.

Die sicherheitsrelevanten Eigenschaften von Windows und Linux können für uns als reine Privat-Anwender doch völlig unwichtig sein und auch als völlig übertrieben wirken. Ich würde nicht auf die Idee kommen geschäftliche Aktivitäten von einem Computer abhängig machen zu wollen. Wer das tut und dabei gehackt wird hat doch selber Schuld. Ich bekomme von diesen Firmen nichts dafür diesen Sicherheitswahnsinn genauso mitzumachen, warum sollte ich es also tun? Von mir aus kann gerne die gesamte Wirtschaft weltweit in sich zusammen brechen und kollabieren. Je früher das passiert, desto eher können solche Fehler und die verheerenden Folgen davon, eine stetige Verarmung grosser Teile der Menschheit vermieden werden und durch eine humaneres Regelwerk und einer unendgeldllichen und (beinahe) bedingungslosen Verteilung aller überlebenswichtiger Güter abgelöst und ersetzt werden, womiit auch die kriminellen Aktivitäten der international agierenden Banken-Mafia und deren militärischen geführten Kriege gegen arme Menschen vermindert werden können.

Dirk

Okay, so weit hatte ich beim Thema Dos noch gar nicht gedacht, und als ich gerade begonnen hatte mich
über die 640K Grenze hinauszubewegen hatte sich Windows manifestiert. Das erste was mir dabei über
den Weg lief war Visual Basic, und ich versuchte es erst gar nicht weil mir die Multimediale Entwicklungs-
oberfläche überhaupt nicht zusagte.
So träumte ich weiterhin von besagten "beschränkten" Programmen aus der Zeit Anfang der 90er,
mich faszinieren die Tricks, wie die Entwickler Speicherplatz sparten, z.B. werden bei alten Sierra
Adventures die Hintergrundgrafiken mit Zeichenbefehlen gemalt und nicht als Bitmap gespeichert,
und bis heute ist diese Real-Mode Programmierung das, was ich am besten kann. Wohl auch aufgrund
mangelnden Wissens über die Hardware. Mir dieses Wissen anzueignen wird wohl ähnlich viel Aufwand
sein, wie zu lernen, unter Windows zu programmieren, und da bin ich in einem Entscheidungskonflikt.
Lieber würde ich unter Dos weitermachen, andererseits aber auch ein wenig Publikum haben wollen.

Also wäre es doch möglich, in Dos-Manier auf aktuellen Rechnern zu programmieren? Ich denke,
die Performance wäre dadurch mitunter besser als unter Windows, wenn man bedenkt, dass
die DOS-Performance Ende der 90er unter Dos besser war.
Verzeih mir meine Unwissenheit, aber wäre sowas denkbar, dass man ein Dos-Programm
für heutige Rechner codet und per Boot-CD-Rom lädt, bevor Windows hochgefahren wird?
Das würde DosBox obsolet machen und gleichzeitig eine sehr idiotensichere und einfache
Methode sein, auch heutigen Usern noch Dos-Anwendungen zugängig zu machen. Einfach
CD-Image runterladen, brennen, und Rechner neu booten. Fast zu schön um wahr zu sein
wäre das. Wenn das überhaupt ginge hätte man dann aber wohl das Problem, dass es
z.B. keine Soundblaster kompatible Karte mehr gibt. Da wird man wohl um Treiber nicht
herumkommen.

Es ist auch zweifelhaft, ob das, was heutzutage so unter "Grafikkarte" läuft (gerade in Klapprechnern sind es eher Grafikchips bzw manchmal auch CPUs mit Grafikerweiterung) überhaupt noch das ist, was für/unter DOS und RealMode erwartet wird (als da wäre registerkompatible VGA... und so.)
Das, was als Soundhardware vorhanden ist, wird mit an Sicherheit grenzender Wahrscheinlichkeit nichts sein, das irgend einem der zu "DOS Zeiten" etablierten "Quasi-Standards" entspricht. Ein sogenannter "moderner Rechner" hat OHNE Treiber etwa die Qualität eines sehr kompliziert aufgebauten und sehr teuren Briefbeschwerers / Türstoppers. Selbst Motherboards erwartet heutztage schon Treiber, soweit ich weiß...
Wenn man also etwas wirklich VERNÜNFTIGES machen will, hat man nur zwei Möglichkeiten:
1.) Sich diesem ganzen Windows/Linux/beliebiges_aktuelles_OS - Unfug anzuschließen, inklusive aller an Programmierer gestellten Restriktionen, Dogmen und Pseudo-Standards, die zum Zwecke der Ermöglichung einer Multitasking-simulation erforderlich sind.
ODER
2.) Das unter 1.) genannte völlig ignorieren und ohne besagte Restriktionen auf den Systemen programmieren, auf denen das wasman tun will, lauffähig ist.

Alles andere ginge zwar "irgendwie auch" - wäre aber nichts "VERNÜNFTIGES" - als da wäre z.B:
Mit einem Vielfachen der zur Problemlösung eigentlich erforderlichen Rechenleistung einen Emulator/virtuelle Maschine ein selbstgeschriebenes Programm abarbeiten lassen, das extrem speichersparend und rechenzeitsparend optimiert ist - optimiert auf ein System, das physisch gar nicht vorhanden ist - und man weiß dabei nicht einmal, ob diese für ein reales physisches Hardwaresystem gedachten Optimierungen sich auf die Performance des o.g. Emulators positiv oder negativ auswirken wird.

Man kann es heutzutage ja schon fast IMMER "irgendwie anflanschen, damit es läuft".
Ich bin mir dessen bewußt, daß niemand, der seine 64bit Rechner liebt und sein 64bit-Grafikspielerei-OS anbetet, Dinge wie meine Spiele je spielen wird. Zum Einen, da sie ja niedrig aufgelöst und 2D sind, zum Anderen, weil sie dafür nicht den Aufwand auf sich nehmen werden, dafür einen Emulator herunterzuladen und zu konfigurieren, bzw sich mit DOS zu beschäftigen, um zu verstehen, wie man den benutzt.
Eine Anleitung dazu zu schreiben hat prinzipiell keinen Sinn, da niemand dieser Leute Anleitungen liest, die länger sind als 3 Zeilen - danach setzt das Gehirn aus. Und wenn nicht schon dann, dann spätestens bei der Realisierung, daß kein Werbeflash und kein Video der Anleitung beiliegt. - und sich auch nichts selbst öffnet und nichts von selbst abspielt und nicht von selbst anfängt, etwas zu installieren...
Für Leute mit der Aufmerksamkeitsspanne einer Fliege und einer Begeisterungsfähigkeit, die so träge ist, daß sie erst ab einem besimmten Hard- und Softwareaufwand überhaupt reagiert, lohnt es sich von meiner Seite her gar nicht mehr, irgend etwas zu erschaffen. Es würe ohnehin an komplettem Desinteresse abprallen.

Trotzdem, ich hab den PC 1989 kennengelernt, und da gab es keine oder kaum Spiele die
den unreal mode nutzten. Wie ich schon sagte, damals dominierte was Spiele angeht der
Commodore oder NES und Sega - bei Sega weiss ich es nicht genau aber bei den anderen
schon, dass die nur 500 K RAM hatten oder weniger, und es ging auch.

Und wie war das noch, braucht der unreal-mode eine spezielle Boot-Konfiguration?
Das hatte man auch nicht gern damals.

Ich kann auch nochmal schreiben, dass es mich z.B. mehr reizt, ein sehr speichersparendes
Tracker-Musikformat zu entwickeln, als einfach ein modernes Format zu unterstützen, wo
die Module meist locker über 1 MB hinausgehen, und wo man allein für die Patterndaten
eine dreistellige KB Größe anlegen muss. Genausowas kann nämlich AGS, das Adventure
Game Studio, es unterstützt so ziemlich jedes Soundformat was es gibt, MIDI, MOD, XM, MP3,
und das ganze ist natürlich für Windows konzipiert, auch wenn die Grafiken 320x200 sind,
meistens - jedenfalls ist da Soundformat-mäßig eine ziemliche Unordnung und Dekadenz,
da wird für einen kleinen Gag einfach mal ne 5 MB mp3 in das Spiel reingehauen, und
dann auch noch einfach ein zu mp3 konvertiertes Tracker-Chiptune-Stück und natürlich
Stereo codiert, obwohl es mono ist - dem Spieler ist das sowieso egal, aber offensichtlich auch dem Entwickler.

Ich habe so gegen 1999 das ernsthafte Spiele-Programmieren mehr oder weniger an den
Nagel gehängt, eben wegen Windows. Davor war es noch anders, Dos war die Plattform,
und wenn ich etwas programmiert habe, hatte ich die Gewissheit, dass ich nicht der
einzige wäre, der es benutzt.
Und ich verstehe dass Windows angreifbar ist durch Hacker, aber das kümmert einen
doch recht wenig wenn es um Spiele geht.
Aber natürlich bin ich für Dos. Allein schon wirkte jedes Spiel einzigartig, weil man
irgendwie merkte dass die Entwickler ihre Spezialroutinen selbst geschrieben haben und
nicht einfach auf Windows-Dienste zugegriffen haben.

Wenn man programmieren mit Geräte basteln vergleichen will, dann ist das unter Windows
eher so, dass man sich einen riesigen Schrank als Gehäuse kauft und dort fertige kleinere
Geräte reinpackt. Bei Dos kann man hingegen bis hinunter zu den elektronischen Einzelteilen
Hand anlegen, diese optimieren, und das Gehäuse wird sehr viel kleiner und funktioniert
effektiver.

Ich fasse DOSferatus Aussage mal knapp zusammen: Dos Programme wird sich quasi keiner mehr ansehen.
Sehe ich ähnlich, und daher ist die einzige Möglichkeit zur Motivation: Den Kram für sich selbst programmieren.
Ein Spiel schaffen, welches man selber immer wieder spielen möchte. Ich glaube ich wiederhole mich.
Aber so ist es auch wenn ich Musik mache. Ich habe mehrere hundert Musikstücke gemacht und war
bei jedem einzelnen begeistert dabei. Und mich hat nie interessiert ob die auch jemand anders gut
fand. Okay, interessiert schon, aber das war nicht die Motivation. Ich habe Musik erschaffen, die es
noch nicht gab, und das ist meine Motivation. Ich könnte nicht Musik machen wie so ein Dieter
Bohlen, der möglicherweise seine eigene Musik gar nicht leiden kann, aber damit Geld scheffelt.
Andererseits habe ich auch die Erfahrung gemacht, dass Ideen, die einen wirklich faszinieren, auch
andere gut finden. Vielleicht nicht die meisten, aber die wenigen die fasziniert sind umso mehr.
Also wenn ein Spiel, dann nach einem "revolutionären" Konzept. Mit clones von bekannten
Jump&Runs etc. kann man sowieso keinen Vogel mehr abschiessen, gerade heute, wo die Grafik
der aktuellen Spiele alles übertrifft wovon man sich vor 15 Jahren zu träumen gewagt hätte.
Beispiel das aktuelle Remake von Giana Sisters "Twisted Dreams". Wenn ich sowas sehe denke
ich mir eher "nee du, versuch's erst gar nicht..." - Trotzdem, für mich macht das nicht
viel aus ob ein Spiel wie von 2012 oder wie von 1992 aussieht!
Für mich persönlich gibt es einen Trost: Was Sound und Musik angeht stagniert die Entwicklung längst,
oder auch, der Mensch soll ja ein Augentier sein, man kann ruhig heute noch sowas wie MOD nutzen
und es wird sich keiner beschweren.

Oh, ich meinte nicht, daß sich DOS-Spiele keiner mehr ansehen wird.
Aber ich befürchte, daß die Windows-User-Klientel seit Win Vista keine direkte Möglichkeit mehr dazu hat. (WinXP 32bit war das letzte Windows, auf dem DOS-Spiele DIREKT liefen.) Und da Windows-User gewöhnt sind, daß alles mit 1-3 Mausklicks geht, die Installation und Konfiguration eines DOSbox doch etwas mehr erfordert, werden sich die Windows-Only User diesen Kram nicht geben.
Die einzigen, die - wenn überhaupt "DOS"-Spiele anschauen/spielen werden, sind TEILE der ehemaligen DOS-User/Coder - und selbst die natürlich mit dem Bewußtsein des Heutzutage-Vorhandenseins von TrueColor 1600er 3D-Grafik und Surround-Sounds auf elektronischen Systemen.
D.h. wenn es nicht wirklich Leute sind, die sich an einem Spiel selbst begeistern können, sondern eher an Hardware-Overkill (und letztere sind nunmal die meisten), dann werden sie - wenn sie es überhaupt mal "antesten", es eher nur milde belächeln im Sinne von "naja, er hat sich Mühe gegeben..."

ICH bin mir dessen bewußt, daß ich heutzutage für meine Arbeit nicht die geringste Anerkennung erwarten darf - und eher froh sein kann, wenn es sich überhaupt jemand anschaut, und wenn auch nur, um es sich "mal zwischendurch" als eine lächerliche altmodische kleine Kuriosität zu geben. Begeisterung darf ich gar nicht erst erwarten - so etwas bekommen heute nur noch die Konzerne, die von hunderten von namenlosen Programmierern riesige Projekte stemmen lassen, die so zwischen 300 und 500 Mann-Jahre an Arbeit/Aufwand erfordern und zum Abspielen die neueste Hardware --- mit allem darunter gibt sich heutzutage niemand (von einigen wenigen Freaks abgesehen) mehr ab - eben höchsten noch als "das war ja damals alles gruselig"-Beispiel.

Aber für mich ist es ja sowieso nur ein Hobby. Ein Hobby muß Spaß machen und darf keine Bürde sein. Windows-Programmierung ist für mich eine Bürde (ja, ich habe es schon ausprobiert). Und wenn dabei irgendein Resultat herauskommt, stelle ich es auf meine Webseite und wen-auch-immer-es-interessiert, kann es sich herunterladen. Ich erwarte nichts dafür - aber mich interessiert auch nicht Spott und Häme, die daraus evtl. resultieren - das kann man alles für sich behalten. Man wird auf meiner Webseite ausdrücklich gewarnt und darüber in Kenntnis gesetzt, welcher Art die "Produkte" sind, die man zu erwarten hat, wenn man die "DOWNLOAD"-Schaltfläche triggert. - Also sollte man dann nicht allzu überrascht und/oder angewidert sein, wenn man genau das erhält, was einem prophezeiht wurde...

Du hattest mal geschrieben (oder war's auf deiner Homepage?) dass C64 Programmierung eigentlich
einfach sei. Mein Vorurteil war immer das Gegenteilige. Wahrscheinlich vor allem deshalb, weil ich
mir Programmierung mit so einer niedrigen Textmodus-Auflösung und vor einem flimmernden Bildschirm
sozusagen schmerzhaft vorgestellt habe.

Und dann noch das mit der Boot-CD auf heutigen Rechnern: Es macht zwar nicht viel Sinn, wenn
man Grafik und Sound nicht ansteuern kann - für den Rest kann man Freepascal nutzen, fast
1:1 wie zu Dos-Zeiten - aber generell würde mich interessieren ob man auf diese Weise
einen heutigen Leistungsboliden zu Dos "zwingen" kann.
Überhaupt habe ich da ein Bildungslücke, ob ein heutiger Rechner überhaupt noch
16 Bit Code verabeiten kann.

Noch etwas zum Thema Speicher bzw. unreal mode:
Ich mach das ja alles auch nur als Hobby, meine Stärken liegen eher im Irrationalen, ich könnte
niemals ein Profi-Programmierer sein, da würde mir täglich der Kopf gehörig rauchen,
mich treibt nur die Faszination an.
Und da habe ich eben Spass daran, Speicherverschwendung zu vermeiden.
Ich möchte es mir nicht nehmen lassen, mein jetzt schon oft genug zitiertes "ZEM"
Format weiter zu optimieren und immer mehr Luft rauszulassen, auch wenn dies
bereits auf Rechnern der 386er Generation nicht mehr nötig wäre, da man
ja den unreal mode nutzen könnte.
Es ist vielleicht ein bisschen so eine ähnliche Motivation, wie von jenen Leuten,
die an Contests mit 128 Byte Demos teilnehmen... Nur dass es bei mir noch
ein wenig mehr pragmatische Gründe hätte, da ich mir eben aus Faulheit,
dass ich den unreal mode nicht nutze, die Grenze von 640K auferlege, und darin
möglichst viel "Multimedia" unterbringen möchte.

zatzen hat geschrieben:Du hattest mal geschrieben (oder war's auf deiner Homepage?) dass C64 Programmierung eigentlich einfach sei. Mein Vorurteil war immer das Gegenteilige. Wahrscheinlich vor allem deshalb, weil ich mir Programmierung mit so einer niedrigen Textmodus-Auflösung und vor einem flimmernden Bildschirm sozusagen schmerzhaft vorgestellt habe.

Der C64 ist ein monolithisches System - es gibt keine komische Hardware und keine seltsamen Treiber. Der Maschinencode ist recht einfach gehalten, die Chips (VIC, SID, CIA1+2 usw) sind sehr übersichtlich geschaffen.

zatzen hat geschrieben:Und dann noch das mit der Boot-CD auf heutigen Rechnern: Es macht zwar nicht viel Sinn, wenn man Grafik und Sound nicht ansteuern kann - für den Rest kann man Freepascal nutzen, fast 1:1 wie zu Dos-Zeiten - aber generell würde mich interessieren ob man auf diese Weise einen heutigen Leistungsboliden zu Dos "zwingen" kann. Überhaupt habe ich da ein Bildungslücke, ob ein heutiger Rechner überhaupt noch 16 Bit Code verabeiten kann.

Ja, den Real Mode ("Real Address Mode") also den 16bit mode gibt es immer noch - und jeder PC wird per Default in diesem CPU-Mode gestartet. Da muß man nichts "zwingen".
Das Problem wird eher, auf die Festplatten zuzugreifen, falls sie in irgendeinem komischen Format formatiert sind. OK, es gibt zwar den "DOS-Unterbau" von Windows, den man mißbrauchen könnte und der auch größere Partitionen als 2 GB erlaubt...
Also PRINZIPIELL sollten auch heutige Rechner noch mit DOS klarkommen. Man müßte es eben testen.

zatzen hat geschrieben:Noch etwas zum Thema Speicher bzw. unreal mode:
Ich mach das ja alles auch nur als Hobby, meine Stärken liegen eher im Irrationalen, ich könnte
niemals ein Profi-Programmierer sein, da würde mir täglich der Kopf gehörig rauchen,
mich treibt nur die Faszination an.

dito

zatzen hat geschrieben:So träumte ich weiterhin von besagten "beschränkten" Programmen aus der Zeit Anfang der 90er,
mich faszinieren die Tricks, wie die Entwickler Speicherplatz sparten, z.B. werden bei alten Sierra
Adventures die Hintergrundgrafiken mit Zeichenbefehlen gemalt und nicht als Bitmap gespeichert,
und bis heute ist diese Real-Mode Programmierung das, was ich am besten kann. Wohl auch aufgrund
mangelnden Wissens über die Hardware. Mir dieses Wissen anzueignen wird wohl ähnlich viel Aufwand
sein, wie zu lernen, unter Windows zu programmieren, und da bin ich in einem Entscheidungskonflikt.

Zu lernen wie man für Windows etwas programmiert ist weitaus weniger schwer, als es zu lernen all die Dinge zu tun die Windows selber für uns unsichtbar im Hintergrund macht. In den Linux-Sourcen sind solche Dinge auch enthalten. Leider fällt es mir sehr schwer den C-Code zu verstehen. Wäre Linux nur mit Assembler oder Pascal programmiert worden, dann könnte ich das wohl auch etwas leichter lernen.

Lieber würde ich unter Dos weitermachen, andererseits aber auch ein wenig Publikum haben wollen.]

Mir geht es genauso, denn mir macht es kein Spaß etwas für Windows oder Linux zu programmieren. Vor allem weil man die Hardware nicht selber steuern darf, wegen dem übertriebenen Sicherheitskonzept. Ich hätte ja nichts dagegen wenn ich auch ersatzweise Systemdienste für den Zugriff auf die Hardware verwenden darf, doch das sollte keine Pflicht sein, sondern dem Programmierer zu überlassen, ob er die Dienste nutzen möchte, oder doch lieber selber die Hardware ansteuern möchte. Unter DOS dürfen wir den Festplattenconrtroller über Portzugriffe steuern und müssen nicht nur die DOS-Funktionen mit Datei-Handle verwenden.

Also wäre es doch möglich, in Dos-Manier auf aktuellen Rechnern zu programmieren?

Ja das ist schon möglich, allerdings hat sich die Hardware schon etwas geändert.
Z.B. wenn die Grafikkarten keinen CGA-Mode mehr unterstützen, dann kann man nur die vorhandenen Modi verwenden.

Bei meinem Mainboard von ASUS(Striker II formula) mit Intel Socket 775(und Core2quad-CPU) gibt es keine Floppy, keinen einzigen ISA-Steckplatz(nur PCIe und PCI), keine seriellen Ports(RS232), keine paralelle Ports(LPT) und auch keinen PS2-Anschluss, sondern nur noch USB. Mit der Bios-Einstellung USB lagacy enable kann man jedoch auch eine Mouse am USB-Anschluss als eine PS2-Mouse abgefragen und verwenden, z.B. mit dem Cutemouse-Treiber über die Bios-Funktionen vom Int 15h/C20?h.

Ich denke,die Performance wäre dadurch mitunter besser als unter Windows, wenn man bedenkt, dass
die DOS-Performance Ende der 90er unter Dos besser war.
Verzeih mir meine Unwissenheit, aber wäre sowas denkbar, dass man ein Dos-Programm
für heutige Rechner codet und per Boot-CD-Rom lädt, bevor Windows hochgefahren wird?

Unwissenheit ist keine Schande und da gibt es auch nichts zu verzeihen. Es gibt auch keine doofen Fragen, sondern allenfalls nur weniger präzisse Antworten.

Ich kann mit meinem Mainboard wahlweise von CD(auch CD-RW), oder einem 2 GB USB-Stick immer noch MS DOS 6.22 und auch MS DOS 7(von W98SE) und auch jedes selber erstellte, eigene Betriebsystem damit booten. Wenn das zukünftig nicht mehr gehen sollte, dann bezahle ich keinen einzigen Cent mehr für ein neues Mainboard und verzichte darauf lieber, als mich in diese unerwünschte Richtung nur noch lizensierte OS verwenden zu dürfen abdrängen zu lassen. Ich habe auch genug andere Interessen, wo ich selber entscheiden kann wie ich damit umzugehen habe und ich brauche ganz bestimmt keinen Hersteller der mich auf diese Weise zu etwas drängt, was ich als Kunde so nicht haben möchte.

Das würde DosBox obsolet machen und gleichzeitig eine sehr idiotensichere und einfache
Methode sein, auch heutigen Usern noch Dos-Anwendungen zugängig zu machen.

Ja mit FreeDOS und einem eigenen OS ist das möglich. Nur einen Datenträger mit MS-DOS darauf darf man nicht selber verbreiten, es sei denn man verkauft(oder verschenkt) sein gesamtes original MS DOS mit der Lizenz an einen Rechtsnachfolger.

Ich konnte es bisher auch nicht wirklich verstehen, worin der Reiz darin liegt die DosBox zu verwenden.
Warum werden in der DOSBox nicht die VESA-Modi von der verwendeten Grafikkarte zur Verfügung gestellt, sondern nur eine begrenzte Auswahl an Video-Modi und Auflösungen? Damit kann ich nicht die native Auflösung meines 28" LCDs von 1920x1200 wie unter puren DOS verwenden. Alle andere Auflösungen werden nur interpoliert dargestellt und haben damit keine für mich zumutbare Bildqualität mehr und damit möchte ich auch gar nicht erst anfangen, solche nur interpolierten Auflösungen zu verwenden. Wenn man unter WindowsXP(32bit) den Grafiktreiber für seine Karte(von ATI oder NVIDIA) installiert hat, dann werden doch auch alle auf der Karte sich befindeneden VESA-Modenummern wie gewünscht ausgegeben, wenn man die VESA-Funktion dafür aufruft und die Modenummern darüber ausliest. Somit wäre es bestimmt auch möglich alle solche VESA-Modi von der jeweiligen Karte in der DosBox zur Verfügung zu stellen.

Einfach CD-Image runterladen, brennen, und Rechner neu booten. Fast zu schön um wahr zu sein
wäre das. Wenn das überhaupt ginge hätte man dann aber wohl das Problem, dass es
z.B. keine Soundblaster kompatible Karte mehr gibt. Da wird man wohl um Treiber nicht
herumkommen.

Ich verwende all die Jahre durchgehend immer nur Soundkarten von Creative Labs und zur Zeit eine Sounblaster X-Fi Xtreme Audio. Davor habe ich eine Sounblaster Audigy 2 und davor eine Sounblaster Live 4.1 verwendet.

Ich weiss aber nicht wie man unter DOS diesen Karten ein Ton entlocken kann. Ich bin jetz aber kein besonders grosser Freund von Tracker-Sound. Aber mit ein paar Geräuschen bei der Bewegung von Bildteilen kann ein besserer Effekt damit erzielt werden, wenn visuelle und akkustische Reize miteinander kombiniert werden. So kann uns schon eine einfache Tonfolge uns an etwas erinnern, womit dann ganz bestimmte Gedanken angekoppelt werden können. Auf diese Weise kann es auch leichter werden etwas intuitiv zu erfassen, womit auch ein bestimmtes Spielverhalten angeregt werden kann.

Dirk