DOS-Forum

Das hört sich doch schonmal gut an. Die Kombination von Klangsynthese und eher spärliche Nutzung
für Samples (vielleicht für Drums) ist für den Real Mode sehr klug. Ich würde auch gern musikalisch
tätig in dem Format (und könnte auch Auftragsarbeiten machen, d.h. "Conversions", bestimmte
bestehende Musik einprogrammieren - ich höre da ziemlich gut alle Töne und Harmonien usw. raus),
allerdings fühle ich mich nur in einer Tracker-Umgebung wohl, und zwar wirklich nur da, auch eine
klassische Notenschrift wäre mir zu umständlich. Ich weiss nicht ob dir das widerstreben würde
wenn es für dein Format einen Tracker gäbe - letztlich könnte man die Daten sicherlich immer noch
im Opcode-Format exportieren.
Mit etwas Ruhe und modularer Strukturierung beim Programmieren (anders als das Spaghettizeugs
was ich früher gemacht habe) könnte ich mir auch vorstellen, einen Tracker zu schreiben. Dann
könnte ich wenigstens mit dem umgehen. Und wäre entsprechend motiviert, dein Format selbst
zu verwenden.

Wie war das noch, kann ich nicht einfach einen Type definieren, ein 0..1 Array vom Typ Word und
dann absolute ... ? Für Vor- und Nachkomma ist es dann sowieso praktisch, wenn man da direkt
drauf zugreifen kann.

Wo ich übrigens im Moment wirklich noch hänge ist beim Thema Videoformat die Sache mit der
Palette. Das einzig gute ist, auf die Palette wird, egal wie sie erstellt wurde, immer per einem
Offset zugegriffen, es hängt nur von der "Intelligenz" des Encoders ab und ist auf- und abwärtskompatibel.
Ich habe mich wegen dieser Sache jetzt auch beim Coding Board gemeldet, aber die Sache scheint
mir sehr schwierig zu sein... Vielleicht läuft es darauf hinaus, dass der Computer tausende von
Kombinationsmöglichkeiten einfach dumm durchlaufen muss, bis die kompakteste gefunden ist.
Ich weiss es nicht. Dazu lieber mehr in entsprechendem Thread.
Jedenfalls bin ich mit diesen Formaten motiviert, meine Spiel-Engine zu machen.
Die Grafik-Routinen mögen manchem unsinnig erscheinen, aber ich mag dieses idiotensichere
"Nur-So-Viel-Speichern-Wie-Nötig-Und-Trotzdem-So-Viel-Farben-Und-Formen-Wie-Man-Will".

zatzen hat geschrieben:Das hört sich doch schonmal gut an. Die Kombination von Klangsynthese und eher spärliche Nutzung für Samples (vielleicht für Drums) ist für den Real Mode sehr klug.

Ja, ich mag es auch irgendwie. Auf dem C64 hat man übrigens sogar Drums (bzw sämtliche Percussion) mit Klangsynthese hinbekommen - hier haben die dann mit Wechsel der Wellenform gearbeitet (z.B. kurz tiefe Dreieckwelle, danach hohes Rauschen, usw).

zatzen hat geschrieben:Ich würde auch gern musikalisch tätig in dem Format (und könnte auch Auftragsarbeiten machen, d.h. "Conversions", bestimmte bestehende Musik einprogrammieren - ich höre da ziemlich gut alle Töne und Harmonien usw. raus), allerdings fühle ich mich nur in einer Tracker-Umgebung wohl, und zwar wirklich nur da, auch eine klassische Notenschrift wäre mir zu umständlich.

Irgendwie hast Du beim letzten Mai scheinbar etwas mißverstanden.
1.) Daß ich die "Befehle" in diesem Ding als "Opcodes" bezeichne, liegt nur daran, daß mir kein besseres Wort dafür eingefallen ist, weil sie eben genau das sind.
2.) Selbstverständlich muß man die Musik dann NICHT in irgendeiner Compiler-Umgebung als "Quelltext" verfassen - mein Editor wird natürlich so eine Art Tracker sein.
3.) Genau aus diesem Grund haben die Befehle auch alle die gleiche "Breite" (16bit) - damit sie quasi "hintereinander"/"untereinander" stehen können und es da keine Mißverständnisse geben kann, was Befehl und was Parameter ist.
4.) Notenschrift kann ich selbst auch nur ansatzweise - ich verwende selbstverständlich die im Computermusikbereich übliche Notenschreibweise.
(Beispiel für 4. Oktave: C-4, C#4, D-4, D#4, E-4, F-4, F#4, G-4, G#4, A-4, A#4, H-4)
Also nichts mit komischen Dur- und Moll- "Vorzeichen" vor einzelnen Noten oder Takten (b und # usw).

Bei meinen Trackern (habe auch schon einen sehr alten für 3-stimminge Speaker-Musik gebaut, den ich in meinen alten Spielen verwendet habe) habe ich mich entfernt an einem Tracker für den C64 orientiert - mit dem ich damals die Musik für mein Spiel "Rockus - The Game" gemacht habe.
Auch der neue Tracker ist so/wird so sein: Hohe schmale "Fenster" für jede Stimme, die nebeneinander stehen. Dort stehen dann untereinander die Noten und die anderen "Befehle".
Man mache sich bitte nicht mit diesen "Befehlen" verrückt - im Normalfall wird man höchstens mal einen "Sprung"Befehl brauchen oder einen "Unterprogramm" Befehl (also einen, der eine bestimmte Sequenz an einer Stelle aufruft, damit man die nicht etliche Male schreiben muß, wenn man sie mehrmals braucht.)
Und es gibt auch so "Schleifen" Befehle, wenn sich eine Sequenz wiederholen soll.

An der Bedienung des Ganzen soll es wirklich nicht scheitern. Da ich selbst eher semi-talentiert bin, was das Erstellen von Benutzeroberflächen angeht, wäre ich da auch für Vorschläge offen, wenn jemand dieses Ding wirklich benutzen will und ihm da einige Bedienschwächen auffallen oder Dinge, die man noch nachträglich einfügen könnte. Der Tracker wird nicht dazu gedacht sein, in einen Mathekurs auszuarten.

Was eventuell anders ist bei meinem Tracker und bei anderen, die ich so gesehen habe:
Manche Tracker stellen die Spuren so nebeneinander dar, so daß die Takte der Spuren genau auf gleicher Höhe nebeneinanderliegen, damit man sieht, welche Noten gleichzeitig gespielt werden. (D.h. zwischen den Noten wird dort immer Platz gelassen, wenn z.B. auf einer Seite eine ganze Note und auf der anderen gleichzeitig 4 Viertelnoten gespielt werden.)

Mein Formatkonzept ist allerdings so nicht angelegt, da die Verwendung von Schleifen und Sprüngen und "Unterprogrammen" das verhindern. Außerdem enthält eine "Note" bei mir immer gleich die Länge, mit der sie gespielt wird.

ABER - es wäre durchaus technisch möglich, einen Anzeigemodus zu machen, der genau so aussieht (vielleicht an den Seitenlinien dann mit so Hinweis-Zeichen, die angeben, daß es sich hierbei um wiederholte/von anderer Stelle "aufgerufene" Bereiche handelt).

zatzen hat geschrieben:Ich weiss nicht ob dir das widerstreben würde wenn es für dein Format einen Tracker gäbe - letztlich könnte man die Daten sicherlich immer noch im Opcode-Format exportieren.

Wie gesagt - eigentlich gar nicht nötig.
Die "Opcodes" sind ja quasi auch nur die Noten und die Dinge, die so zusätzlich gebraucht werden - z.B. Wechsel des "Instruments", Ändern der Lautstärke, "Verbinden" der Noten/Töne (Portamento) usw. - und - wenn man will - auch eben so Sprünge, Aufrufe, Schleifen. (Es ist eben so, daß, wenn man Dinge, die mehrmals gebraucht werden, nur einmal schreibt, man [a] sich Arbeit spart und auch Speicher spart.)

zatzen hat geschrieben:Mit etwas Ruhe und modularer Strukturierung beim Programmieren (anders als das Spaghettizeugs was ich früher gemacht habe) könnte ich mir auch vorstellen, einen Tracker zu schreiben. Dann könnte ich wenigstens mit dem umgehen. Und wäre entsprechend motiviert, dein Format selbst
zu verwenden.

Da ich das Format ja offenlege, bzw schon offengelegt habe (es könnte in diesem mittelfrühen Entwicklungsstadium noch sein, daß ich an manchen der Befehle noch geringfügige Änderungen vornehme - was aber das Gesamtkonzept nicht beeinflussen wird)

zatzen hat geschrieben:Wie war das noch, kann ich nicht einfach einen Type definieren, ein 0..1 Array vom Typ Word und dann absolute ... ? Für Vor- und Nachkomma ist es dann sowieso praktisch, wenn man da direkt
drauf zugreifen kann.

So arbeite ich schon seit Jahren. Ich benutze fast nur noch Festkomma - gerade im Grafikbereich. (Es gibt ja sowieso keine "halben Pixel").
Beispiel:
var Xcoord:longint;
var Xco:record XL:word;XH:integer;end absolute Xcoord;
schon hat man zwei Variablen (Xco.XL und Xco.XH) für Nachkomma/Vorkomma von Xcoord. Vorkomma dabei diesesmal mit Vorzeichen.
Es geht natürlich auch:
var Beispiel:longint;
var Bi:record L,H:word;end absolute Beispiel;
usw.
Und natürlich, wie Du schon erwähntes:
var Beispiel:longint;
var Ba:array[0..1]of word absolute Beispiel;

Ich benutze z.B. auch sehr gerne dies:
var h:string; lh:byte absolute h; hx:boolean absolute h;
Dann enthält lh gleich die Länge des Strings. Und ich kann ihn verkürzen (oder verlängern), indem ich lh ändere. Und da in Pascal Booleans=FALSE sind, wenn sie Wert 0 entsprechen und in allen anderen Fällen als TRUE zählen (wenn man sie selbst auf TRUE setzt, werden sie 1), kann man mit hx dann gleich unkompliziert testen, ob der string h leer ist oder nicht. (Das liegt daran, daß die Länge bei Pascal-Strings im ersten Byte (also im nullten) gespeichert wird.

Und ja: Linienroutinen u.ä. habe ich in Pascal auch mit diesen obengenannten "Festkomma-Tricks" gemacht - ich benutz' doch kein Fließkomma, wenn es schnell werden soll, bin ja nicht irre...

In Assembler hat man diese "Probleme" ja nicht so - da ist ein Byte, Word, DWord oder auch Register das, was man haben will - es hängt ja nur davon ab, wie man es liest bzw verwendet... Natürlich muß man sich dafür dann auch selbst mit der Variablenverwaltung beschäftigen, wenn man welche haben will.

zatzen hat geschrieben:Wo ich übrigens im Moment wirklich noch hänge ist beim Thema Videoformat die Sache mit der Palette. Das einzig gute ist, auf die Palette wird, egal wie sie erstellt wurde, immer per einem
Offset zugegriffen, es hängt nur von der "Intelligenz" des Encoders ab und ist auf- und abwärtskompatibel.
Ich habe mich wegen dieser Sache jetzt auch beim Coding Board gemeldet, aber die Sache scheint
mir sehr schwierig zu sein... Vielleicht läuft es darauf hinaus, dass der Computer tausende von
Kombinationsmöglichkeiten einfach dumm durchlaufen muss, bis die kompakteste gefunden ist.

Im Normalfall ja - zumindest, wenn man wirklich die effizienteste "Packrate" haben will. Das liegt daran, daß Videodaten ja quasi "alles mögliche" sein können und das Programm vorher (bevor die Daten gelesen sind) ja noch nicht wissen kann, in welche Richtung man diese optimieren kann.

zatzen hat geschrieben:Ich weiss es nicht. Dazu lieber mehr in entsprechendem Thread.

Ja, wahrscheinlich besser - sonst kommt man mit den verschiedenen Themen (Musikformat/Videoformat) am Ende zu sehr durcheinander.

zatzen hat geschrieben:Jedenfalls bin ich mit diesen Formaten motiviert, meine Spiel-Engine zu machen.
Die Grafik-Routinen mögen manchem unsinnig erscheinen, aber ich mag dieses idiotensichere
"Nur-So-Viel-Speichern-Wie-Nötig-Und-Trotzdem-So-Viel-Farben-Und-Formen-Wie-Man-Will".

Ja, geht mir ja ähnlich. Ich finde immer: Am besten ist, Daten im Vorfeld so aufzubereiten, daß die "Abspielroutine" (egal ob Grafik oder Sound) damit "so wenig Arbeit wie möglich" hat und der Speicher so wenig wie möglich belastet wird.

Denn: Es ist ja schließlich egal, wieviel man "außerhalb des Spiels" an Daten braucht, um das alles hinzukriegen - während man die Grafik baut, baut man nichts am Sound, während man am Sound baut, baut man nichts an der Grafik. Und die Spielsteuerung kann man auch unabhängig davon machen. So können die Entwickler-Tools natürlich mit Komfort und vernünftig lesbaren und verwendbaren Daten aufwarten und das Endprodukt (Spiel), wo die Daten durch Programme verwendet werden - denen es egal ist, wie "menschenlesbar" sie dann noch sind - können die Daten dann im gepackten/vorbereiteten Zustand genutzt werden.

Auf diese Art bleibt genügend Platz für das Spiel selbst und es wird vermieden, daß sich die einzelnen Bereiche (Grafik, Sound, Steuerung) um den vorhandenen Speicher bzw die Rechenzeitressourcen "prügeln müssen".

Es sollte meiner Meinung nach sowieso immer so programmiert werden, daß am Ende immer noch etwas "Luft" bleibt - denn: Es kann passieren, daß man im Nachgang noch etwas erweitern will - und das soll möglich sein, ohne die bereits vorhandenen Funktionen einzuschränken. Und: Man sollte immer daran denken, daß die eigene Maschine, auf der man gerade etwas entwickelt, nicht immer als "das Maß der Dinge" anzusehen ist. Nehmen wir an, man hat selbsteinen 486er, 133MHz. Muß es dann wirklich sein, daß das entwickelte Spiel dann auf einem 486er mit 75 oder 100 MHz bereits unspielbar ist? Ich meine nein.

Und ja - mit diesem "minimalistischen Denken" werde ich wohl nie ein neues World-of-Warcraft oder DOOM 5 bauen wollen. Aber solange man das auch gar nicht will - und sich im Klaren darüber ist - stellt das auch kein Problem dar.

Für das Problem mit den Palettendaten scheine ich jetzt eine erstmal gute Lösung gefunden zu haben.
Werde ich bald mal umsetzen und dann weiter im entsprechenden Tread vorstellen.
Das Format wird dreigeteilt, Blockdaten, mehrfach vorkommende Blockdaten, Paletten.
Somit hat man theoretisch 3 * 64K für ein Bild bzw. Animation zur Verfügung, und so
können Animationen sehr lang sein, wenn es sich nicht gerade um bildschirmfüllenden
Fotorealismus handelt. Das mit der 3-3-2 Palette ist nur noch optional und nur sinnvoll,
wenn ich ohne viel Tabellenarbeit direkt Transparenzeffekte einbauen will.

Mich inspirieren die Schranken des Real Mode. Allein schon die Grafik, bei 320x200
muss man sich schon gut überlegen, wie man die Pixel setzt, und es kann manchmal
einfacher sein, eine geringere Auflösung erleichtert einem die Entscheidung und es
sieht schneller "nach was aus". Ein 16x32 Pixel großes Sprite lässt sich schneller
und mit mehr konkreten Ideen füllen als ein gleichgroßes mit 8x so viel Auflösung.
Zudem denke ich mir, solch beischeidene Hardwareanforderungen könnten sich irgendwann
auszahlen, man denke nur daran dass heutige Handys schon etwa so Leistungsstark
sind wie die Computer von damals. Will heissen: Die Programme die wir schreiben
sind letztlich einfacher auf andere System zu portieren... Wenn man das will.

Noch ein für mich schöner Nebeneffekt ist, dass ich die erzeugten Daten meiner
Programme auch mal im Hex-Editor einsehen kann, und da tatsächlich dann überschau-
bare Strukturen vorfinde.

Den Grafik Converter schreibe ich gerade noch in Free Pascal, möchte ihn am Ende
aber für BP70 umsetzen. Hier ist Multitasking aber gerade sehr praktisch, nebenbei
habe ich ein Grafikprogramm laufen um die Bilder zu analysieren, den Hex-Editor,
den Log meines Programms... Und ist gerade schwierig hier, ich kann im Moment nur
DOSbox benutzen, mein Pentium hat sich vor ein paar Wochen verabschiedet.
Das wollte ich auch zum Anlass nehmen, mal auf einen modernen Tracker umzusteigen.
Hätte ja Vorteile, praktisch unbegrenzter Sample-Speicher und ein Haufen Features.
Aber die Bedienung... Mein bisheriger Tracker war genial, die "GUI" (Textmodus)
war an Borland angelehnt, und die empfinde ich als sehr ergonomisch, ich konnte
mit dem Tracker so gut umgehen, dass ich musikalische Ideen wie im Schlaf
einprogrammien konnte.
Das ist mir sehr wichtig bei einem Tracker, allerdings ist mir soetwas wie mit
in Schleifen programmierten Patterns fremd.

Die meisten Tracker die ich kenne, funktionieren so, dass Noten, die gleichzeitig
angeschlagen werden, auf einer horizontalen Linie liegen. Wie bei einer Walzen-
spieluhr.

Ich schreib hier mal die wichtigsten Tastenbelegungen und Shortcuts vom X-Tracker auf:

Sample abspielen / einprogrammieren:

C C# D D# E F F# usw... : YSXDCVGBHNJM
Oktave drüber: Q2W3ER5T6Z...

Oktave höher schalten: .
Oktave runter schalten: ,

Samples auswählen Dialog (toggle): Enter

Sequencer anwählen (Toggle) : F6

Pattern abspielen: Alt(Gr) + F9

Song von Anfang an anspielen: Strg + F9

Ein Pattern weiter schalten: Numpad +
Ein Patterm zurück schalten: Numpad -


Naja da gibts noch ein paar mehr...
Die Navigation im Pattern selbst ist am wichtigsten, aber obige Kürzel sind mir schonmal
sehr wichtig, um mich wohl zu fühlen, und vielleicht merkst du eine Verwandschaft zu Borland.

Hier ein Bild:

Naja, wie gesagt - so ist mein Tracker halt nicht. Ich werde auch bestimmt nicht einen anderen Tracker "nachbauen". Allerdings kann ich mir gut vorstellen (ist sowieso geplant) einen Konverter einzubauen.
(Für mein eigenes - altes - Musikformat, das ich früher benutzt habe. Und eben auch für andere Formate. Aber ich muß erst einmal sehen, ob sich das überhaupt lohnt...)

Und ja, wie gesagt - auch wenn es Dir "fremd erscheinen mag"... Ich lehne mich da teilweise an einen Tracker an, den ich auf dem C64 benutzt habe. Bedingt durch den ständig knappen Speicherplatz hat man hier halt sehr komprimiert gebaut - es wäre niemandem auch nur im Traum eingefallen, Musikdaten mit so "Nulldaten dazwischen" irgendwo zu speichern, nur damit es im Tracker schöner aussieht...
Oft hat man für Musik die für Grafikdaten nicht nutzbaren Bereiche ($1000-$1FFF bzw $9000-$9FFF) benutzt - d.h. 4kByte. Oder weniger.

Sprites mit mehreren Bewegungsphasen sind eben schon ein wahrer Speicherfresser, da beißt die Maus keinen Faden ab. Kommen dann auch noch die Grafikdaten für den Hintergrund dazu, ist da mal ganz schnell eine Menge Platz verbraten. Die Leveldaten liegen ja auch ungepackt vor - denn ein 2D-Level ständig bei der Anzeige "live zu entpacken" wäre die Hölle und ist quasi nicht realisierbar, wenn man 8-Wege-Scrolling will. Das mußte auf C64 alles berücksichtigt werden.

Und ich finde, trotz (oder vielleicht auch WEGEN) dieser "Einschränkungen" haben es manche Entwickler dort zu wahren Meisterwerken gebracht. Programmcode, Grafik, Sound und andere Daten sind quasi zu einer ganzen Einheit zusammengebaut worden, wo das Eine das Andere nicht stören oder behindern sollte/durfte, sondern wo jedes seinen Platz hatte.

Man hat es sich damals nie "leicht gemacht" - aber darum ging es auch gar nicht. Es ging darum, mit den gegebenen Möglichkeiten das beste herauszuholen, das man schaffen konnte. Ob es dazu externer Dinge vonnöten war, war egal - solange das "Endprodukt" dann nicht darunter zu leiden hatte. (Ich habe die selbstgebauten Sprite-Editoren gesehen - und habe sie hier! - die Manfred Trenz für seine Spiele wie z.B. Katakis gebaut hatte und benutzt hat. So etwas würde keiner der verweichlichten angeblichen "Computerfreaks" von heute mit der Kneifzange anfassen...)

Und ja, natürlich kann und darf und soll man sich als Programmierer/Entwickler auch die Arbeit erleichtern, um Zeit zu haben, mehr tolle Dinge zu machen. Es sollte sich dann nur nicht auf die Dinge auswirken, die man macht.

Mir fällt irgendwie gerade dieser Teil einer bekannten Rede von John F. Kennedy ein:
"We choose to go to the moon in this decade and do the other things - not because they are easy, but because they are hard!"

Das Zeitalter des C64 hatte ich nur ein paar Jahre, so ab 1987, bei Freunden mitbekommen.
Und da war ich 7, habe zwar davon geträumt, selber etwas zu machen, aber damals
wäre ich fasziniert genug gewesen, die Grafiken einfach ändern zu können...

1989 gab's dann schon nen PC.
Hab dann so ca. 1991 mit QBASIC angefangen.
Und in dem Alter eben tatsächlich erstmal nach dem Prinzip, möglichst schnell was zustande bringen.
Letztlich war ich aber immer eher so drauf, dass ich mehr künstlerisch tätig sein wollte, zumindest
wenn es um Gameplay vs. Grafiken / Musik ging, das technische hat mich schon fasziniert, aber ich
denke, erst heute habe ich wirklich vernünftige Konzepte. Je nachdem.

Ich habe irgendwo schonmal einen Tracker gesehen, TFMX, ich denke der hat noch etwas Verwandschaft
damit, die Musik etwas kompakter zu programmieren. Mit Makros und so. Das ist, wenigstens für C64,
der keine 300K Sampledaten verwendet, ein sinnvoller Ansatz. Für mich würde das aber die Spontaneität
zerstören, denn die besten musikalischen Ideen kommen mir meistens beim Trackern, und wenn ich das
so kompakt programmieren müsste, wäre da einfach kein guter Workflow und ich hätte das meiste wieder
vergessen bevor ich es festhalten könnte.

Irgendwo bin ich da aber im Mittelfeld, die klassischen MODs speichern einfach ihre 4-Kanal-64-Zeilen
Patterns mit vollen 1024 Byte ab, ich hab für mein Format eine Komprimierung eingebaut, die, weil
es relativ wenig Daten in der Sekunde sind (vielleicht im Schnitt 20 Byte), auch schnell genug entpackt
werden. Sieht jeder heutige Informatiker als Blödsinn an, aber gerade bei Chiptunes wäre soetwas
gut gewesen. Und mit Chiptune-Samples würde ich auch ausführliche Musik in wenige KB packen können.

Ich denke du redest hier vom C64, ansonsten habe ich aber vor, dieses 8x8 Block Dingens auch
in Echtzeit zu verwenden. Ich habe da aber auch andere Ansprüche, strebe keine Framerate von
50 fps oder höher an. Liegt auch daran, dass ich selten Actionspiele spiele.
Und dann gibts da beispielsweise Captain Comic, das hat ne Framerate von 10, Scrolling mit
8 oder sogar 16 Pixeln Schrittweite, und ist trotzdem spielbar. Sicher keine Kunst, Schrott,
verglichen mit soetwas wie Katakis, aber es hat auch seine Fans und war 1989 eines der
wenigen Spiele auf dem PC den wir hatten, und wir haben es gespielt, obwohl wir schon
seit 3 Jahren ein flüssig scrollendes NES hatten... Naja, um die 20 fps werd ich wohl hinkriegen,
dann gibt's nicht so schlimme Kopfschmerzen.

Ich kann mich nicht (mehr) als Computerfreak bezeichnen. Konnte ich zu Schulzeiten vielleicht,
weil ich im Dorf der größte Computerfreak war. Aber heute... Ich bin jetzt mehr zum Tonmensch
mutiert, das ist etwas was mir mehr liegt auf Dauer, eher irrationale Arbeit, mein Hirn verkrampft
bei zu viel logischem Denken.
Aber irgendwas treibt mich dazu an, immer mal wieder was zu programmieren.
Ist halt ab und zu mal ne gute Übung.
Daher aber eben mein eigenes Spiele-Bau-Set, ich bin man gespannt ob ich das hinkriege
dass man mit ein paar Textdateien als Definition und entsprechenden Grafik und Musik-
daten ein Spiel bauen kann. Eigentlich erdenke ich mittlerweile nur Dinge, die sich auch
machen lassen.

Das beste herauszuholen, was man schaffen kann... Ist ja heute witzlos am PC irgendwie.
Die Grenzen sind nicht fest. Ich fühle mich nur mit dem 8x8 Ding ein bisschen verbunden
mit den alten 8 Bit Rechnern. Auch wenn ich von denen nicht so viel Ahnung habe.

Aber ich glaube ich rechtfertige mich hier irgendwie zu viel, ich bin halt am PC vor allem
in den 90ern aufgewachsen und das hat mich geprägt. Die echten Grenzen des Real Mode.
Die Spiele zu der Zeit haben mich beeindruckt, irgendwie mehr als die nach Mitte der 90er,
als alles 3D und hochauflösend wurde.
Und da bin ich froh dass ich jetzt (viel zu spät) wenigstens etwas für den Standard machen
kann, das sich (wahrscheinlich) sehen lassen kann. Jahrelange Programmierarbeit am
Stück würde mich zermartern, daher lieber ne Engine bauen und dann zwischendurch
immer mal wieder Spiel basteln, vielleicht mal die Engine updaten usw. Ist für mich
gerade der vernünftigste Weg, mit meinen Programmierkenntnissen in meinem Leben
noch etwas sinnvolles anzufangen.


Was den Tracker angeht: Ich könnte wirklich nur Musik machen, wenn es so einer wäre
mit Nullen drin. Ist einfach eine rhythmische Sache. Für Tracker-Anfänger ist es schon
schwer genug, in diesem System überhaupt die richtigen Notenlängen hinzukriegen.
Wenn du einen Converter machen kannst, okay. Ich habe nur gedacht, das wäre eher
schwierig, weil ich ja deinen kompletten Synthesizer als Samples bräuchte um zu wissen
wie es hinterher klingt.
Einen SID könnte man nicht so einfach samplen, auch kein OPL Chip, ich weiss nicht
wie komplex deiner sein wird. Deshalb dachte ich, dass ich vielleicht einen Tracker
schreiben würde. Die Abspielroutinen wären ja von dir gegeben, ich bräuchte also
im Prinzip nur die Oberfläche etc. machen. Macht aber keinen Sinn wenn das Format
intelligent komprimiert programmiert werden muss.

zatzen hat geschrieben:Das Zeitalter des C64 hatte ich nur ein paar Jahre, so ab 1987, bei Freunden mitbekommen.
Und da war ich 7, habe zwar davon geträumt, selber etwas zu machen, aber damals
wäre ich fasziniert genug gewesen, die Grafiken einfach ändern zu können...

Auf dem C64 habe ich kaum mal etwas wirklich cooles gemacht, muß ich im Nachgang sagen - jedenfalls kaum etwas, das dann ein fertiges Spiel geworden ist. Einzige Ausnahme ist wohl dieses "Rockus" - aber selbst das ist, zumindest was die Programmierung angeht, die totale Grütze.

zatzen hat geschrieben:1989 gab's dann schon nen PC.
Hab dann so ca. 1991 mit QBASIC angefangen.

1986 - 1989: "Computer-AG" (1x pro Woche donnerstags für 2 Stunden nach der Schule hingefahren, um programmieren zu können. Hatte meine Programme schon vorher auf Papier geschrieben, damit ich sie dort eingeben kann. Computer: KC 85/1, monochrom, Interpreter-BASIC...)

1989-1990: erster eigener Computer KC 85/4 (24-farbig, habe da auch einiges programmiert - nur in BASIC. Zu der Zeit war "Assembler"/"Maschinencode" immer noch ein Buch mit sieben Siegeln für mich. Und zu Assembler auf den Ostcomputern war quasi auch KEINE Dokumentation irgendwo zu bekommen...

1990-1996: C64. Da habe ich lange und intensiv programmiert - ohne wirklich etwas zustande zu bekommen, was man der Außenwelt hätte antun wollen. War trotzdem jedesmal stolz wenn ich meine lahmarschigen Spiele in BASIC (wo sich kaum etwas bewegte) irgendjemandem präsentieren konnte. Meine Familie hatte - völlig verständlicherweise - eher wenig Interesse an diesem ... Kram.

1993/1994: "Informatik"-Unterricht an der Schule - an echten PCs! (286er, Textmode, Monochrom am Bernsteinmonitor). Programmierung in PASCAL. Habe als Abschlußprojekt sogar ein Spiel geschrieben (Raumschiffballerspiel IM TEXTMODE) - dafür habe ich eine 1+ erhalten. Naja, in "Informatik" habe ich immer eine 1+ erhalten, weil ich irgendwie mehr Ahnung hatte als der Lehrer. Die mußten damals dann Informatikunterricht einführen und da waren dann ein paar Mathelehrer im Crashkurs geschult worden...

Ende 1996: Erster eigener PC (neben C64). Habe dann eine Zeitlang "hybrid" gearbeitet, am C64 und am PC. Der PC war ein von einem Kumpel aus Ersatzteilen zusammengebauter 286er, mit 40MB Festplatte, altem Monitor, Original-VGA Karte, ohne Soundkarte... Da habe ich dann - von den Dingen aus dem "Informatik"-Unterricht abgesehen - meine ersten PC-Programme gebaut. Alles in PASCAL. Und irgendwie bin ich auch später bei PASCAL hängengeblieben - nur daß inzwischen auch Assembler hinzugekommen ist. Auf dem PC habe ich zwar einiges an "Spielen" zustandegekriegt und auch einige Tools. Aber so wirklich "besonders" ist auch nichts davon.
Eine Ausnahme ist wohl dieses "Xpyderz", mit dem ich viel Zeit verbracht habe, das zwar jetzt spielbar ist, aber nie fertig wurde. (Und eigentlich sollte es einmal Multiplayer werden.) Inzwischen habe ich kaum noch Lust, den Code da anzufassen - erstens ist er sehr alt und zweitens irgendwann Spaghetticode geworden. Das Problem war irgendwann, daß PASCAL diese Eigenart hat, daß ein "Programm" eine Speichergrenze für Code hat, die man zwar erweitern kann, aber nur, wenn man Zeug in Units auslagert. Und irgendwann war ich nur noch am "Auslagern" und genauso sieht der Code auch aus. Das liegt daran, daß "Xpyderz" eigentlich eine Art "Unfall" gewesen ist - es war keinerlei "Planung" dabei. Das ist der Grund, wieso ich damit "so weit gekommen" war (keine Zeit für Planung "verschwendet"), aber eben auch, wieso der Kram codetechnisch jetzt so eine quasi unwartbare Grütze geworden ist (jedes neue Feature einfach "irgendwo reingequetscht").
Erklärung: Damals[tm], Mitte/Ende 90er, haben wir mit ein paar Kumpels mal Netzwerkspiele gespielt - es war nur ein einziger Tag. DOOM, Duke3D, und dieses NL-Snipes (Textmode-Labyrinth-Jage-Abschieß-Spiel, was dem NWLITE-Paket beigelegt war). Und bei diesem Snipes sagte mein einer Kumpel später mal: Macht Bock, irgendwer sollte sowas mal grafisch umsetzen. Unabhängig davon hatte er auch später nochmal eine Idee, irgendwas mit Spinnen zu machen (ich hatte ihm da auch ein paar Grafiken gemacht - aber er hat da nie irgend etwas damit angestellt).
Jedenfalls: Als ich 2001 bei Kumpels übernachtet hatte und die früh noch alle pennten und mir langweilig war, fiel mir das alles wieder ein und: ich hatte meinen 486er COMPAQ-Laptop (75 MHz) dabei. Da habe ich das Spielprinzip von NL-Snipes mit Grafik kombiniert - und zwar mit Spinnen - und hatte nach ca. 4 Stunden ein spielbares Spieldemo (was daran lag, daß ich natürlich vorher schon einige Units hatte, die ich über die Jahre so gemacht habe). Man konnte mit dem Panzer durch die Labyrinthe rumfahren und Spinnen abschießen und so weiter...
Naja, jedenfalls: NL-Snipes war ja ein Netzwerk-Spiel für bis zu 5 Spielern. Und ich Wahnsinniger wollte es auch als Mehrspieler-Spiel machen. Für seriellen Port und/oder Modem. Später brachte mich dann ein Kumpel auf den Trichter, daß man es ja auch internetfähig machen könnte... Und ich habe dann wirklich JAHRE damit zugebracht, mir das alles draufzuschaffen - und ein stabiles Spieldatenprotokoll zu entwickeln. Ich habe 4 reine SeriellerPort/Modem Protokolle gebaut, bevor das 5. dann ein "Internet"-Protokoll wurde. Aber irgendwie hatte ich da immer wieder Verbindungsabbrüche... Naja, das Ende vom Lied ist, daß ich einen ganzen Haufen sehr schönen Code und schicke Ideen hier rumliegen habe und viele kleine Spiele und ein großes unfertiges Spiel - das ich zwar selbst immer mal wieder spiele, das mich aber auch ständig wie ein Mahnmal an meine Unfähigkeit und Mittelmäßigkeit erinnert.

Das mag der Grund sein, wieso ich danach nur noch sehr kleine Projekte/Spiele gemacht habe - weil ich mir inzwischen mit der Planung (zu)viel Zeit lasse.
Im Klartext: Ich habe schon sehr viel fertiges Zeug hier, aus dem man ein Spiel bauen könnte - UND ich habe Ideen für Spiele im Kopf und teilweise schon als Grafiken hier - die über zehn Jahre alt sind! Und nichts davon ist ein Spiel geworden.

Und momentan arbeite ich - wenn ich neben meinem Job noch die Kraft finde (eigentlich bin ich immer nur müde) - an zwei Projekten:
Das eine ist dieser Blockgrafik/Sprites/Level-Editor (der selbst ist zu... 95% fertig - da fehlt aber noch manches an Hilfstext [das Ding enthält eine Hilfe] ).
Das andere ist etwas, das ich schon eher mal hätte machen sollen: Diese Sound-Unit (nebst Editor)- denn alle meine PC-Spiele (bis auf die zwei, die diese PC-SPEAKER-MUSIK haben) sind sehr sehr stumm.

Das war jetzt wieder sehr viel Geschwafel. Es zeigt: Ich bin (leider) jemand, den die ganzen "inneren Abläufe" von Programmen/Spielen mehr interessieren als das fertige Endprodukt. Ich habe viele Dinge hier herumliegen, die sehr nützlich sein könnten - wenn man sie eben auch mal BENUTZEN würde...
Bei meinem musikalischen Talent sehe ich auch kommen, daß die Musik meiner Spiele wohl auch nicht gerade "Ohrwurm-Charakter" haben wird - weil ich Musik genauso mache wie alles andere in meinem Leben: Mathematisch...

zatzen hat geschrieben:Und in dem Alter eben tatsächlich erstmal nach dem Prinzip, möglichst schnell was zustande bringen. Letztlich war ich aber immer eher so drauf, dass ich mehr künstlerisch tätig sein wollte, zumindest wenn es um Gameplay vs. Grafiken / Musik ging, das technische hat mich schon fasziniert, aber ich denke, erst heute habe ich wirklich vernünftige Konzepte. Je nachdem.

Ja, früher[tm] war es bei mir genauso: Möglichst kurzfristig und schnell etwas hinbekommen. Dann war es halbfertig und sah so aus wie "könnte etwas gescheites werden" - und dann daran verzweifeln, daß es als so ein halbgares Gerüst zusammengetackert war, an dem man nichts mehr retten/ändern konnte - sondern es nur noch in einer Art fatalistischer Ergebenheit "fertig machen", damit es nicht ganz umsonst war. Ich habe ganz früher allen Ernstes viel zu selten mit Konstanten und so gearbeitet - alles immer gleich zu Anfang irgendwohin größendimensioniert - wenn irgend etwas mal erweitert werden mußte, mußte man das halbe Programm wieder auseinanderreißen und den ganzen Code durchforsten und 30% davon ändern, damit dann z.B. Platz und "Array-Größe" usw. für ein weiteres Feature reichte...
Heutzutage dagegen plane und plane und plane und plane ich - damit mir so etwas nicht mehr andauernd passiert - dafür komme ich heutzutage dann aber leider auch zu gar nichts mehr. Das GameSys2 müßte eigentlich auch schon GameSys5 heißen - so oft, wie ich das Grundkonzept da schon umgeschmissen hatte, weil ich es "diesmal endlich mal richtig" machen wollte...

zatzen hat geschrieben:Ich habe irgendwo schonmal einen Tracker gesehen, TFMX, ich denke der hat noch etwas Verwandschaft damit, die Musik etwas kompakter zu programmieren. Mit Makros und so.

Hm - vom Namen her sagt der mir was.
Aber: Abgesehen von "diesem einen Tracker", den ich auf C64 benutzt habe, kenne ich andere Tracker nur von Screenshots her - habe also keinen davon je benutzt oder "in Aktion" gesehen.
Viele meiner Programme haben ihre Bedienung nur, weil "ich dachte, daß es so am besten gehen müßte" - ich habe da (leider!) zu wenig Vorbilder...
Erklärung: Ich selbst bin ein totaler 80er-Jahre-Computerfreak. Maus gab's damals nicht, Windows auch nicht usw. Tastaturbedienung war das A und O - und kein Programm war irgendwie von der Bedienung her mit einem anderen vergleichbar. Und MIR SELBST reicht irgendein grobes häßliches Teil voller Hex-Ausgaben und undokumentierter Hotkey-Bedienung, ohne Sicherheitsabfragen etc...

Deshalb würde ich auch gerne öfter mal meine Tools (wenn ich wirklich mal welche mit einer GUI baue) von Leuten testen/benutzen lassen, die öfter mit GUI-Tools arbeiten und sich mit vernünftiger "zeitgemäßer" Bedienung etwas besser auskennen. Ich habe zwar einen Kumpel, der so etwas baut (viele Tools mit GUI, für Windows) und benutzt und den habe ich auch meinen obengenannten Block/Sprite/Level Editor mal testen lassen - das Problem ist nur, daß er keine Spiele macht und das ganze zwar "von der Bedienung OK" findet, aber nichts so richtig damit anfangen kann... So daß ein ausführlicher Test da eher nicht so möglich war.
Er sagte so etwas wie, daß es gut wäre, wenn das Ding nicht nur eine Hilfe, sondern so ein Anfänger-Tutorial hätte. Naja - es ist so:
1.) Programmtechnisch wäre es für mich kein Problem, auch so ein Tutorial zu programmieren
2.) ABER: ich schreibe mir schon bereits an der englisch/deutschen Hilfe seit Wochen die Finger wund.
3.) ABER²: Ich bin jetzt schon ständig am Speichersparen, denn es soll ja außer dem Programm selbst auch noch Speicher übrig sein für die Daten, die man mit dem Ding erzeugen will. Für das Tutorial müßte ich wieder noch irgendwo aufwendigen Code reinquetschen. Desweiteren würde man das ja nur 1-2mal brauchen, danach nie wieder benutzen, und dann wäre das ein Programmteil, der nur "sinnlos herumliegt und Codespeicher verbraucht".
Ich sage es mal so: Wahrscheinlich müßte ich das Ding von jemandem testen lassen, der es gewöhnt ist GUI-Tools zu benutzen (oder gar zu bauen) - UND sich gleichzeitig auch mit 2D-Spielen befaßt/befaßt hat und der Erstellung derselben.

zatzen hat geschrieben:Das ist, wenigstens für C64, der keine 300K Sampledaten verwendet, ein sinnvoller Ansatz. Für mich würde das aber die Spontaneität zerstören, denn die besten musikalischen Ideen kommen mir meistens beim Trackern, und wenn ich das so kompakt programmieren müsste, wäre da einfach kein guter Workflow und ich hätte das meiste wieder vergessen bevor ich es festhalten könnte.

Ja, das verstehe ich natürlich.
Ich sage es mal so: Viele Musik zeichnet sich dadurch aus, daß sich durch das ganze Stück ein bestimmtes "Thema" immer mal wiederholt oder daß die "Begleitstimmen" eine gewisse Kontinuität aufweisen. Gerade bei Spiel-Musik fände ich das auch gut, da diese ja das Spiel "untermalen" soll, ohne zu nerven. Auf diese Art hat das Stück so eine "Einzigartigkeit" - man kann an jeder Stelle immer noch hören, um welches Stück es sich handelt, weil es eben "in sich einen Charakter" hat.
Diese Eigenschaft ist aber auch gleichzeitig gut geeignet, um den Umstand auszunutzen, daß sich bestimmte Elemente der Musik wiederholen und daher nicht 20x, sondern nur 1x angegeben/gespeichert werden müßten, mit Wiederholung des Patterns/Unterprogramms oder einer Schleife drumherum.
(Übrigens werden Wiederholungen selbst bei "klassischer Musik" nicht doppelt oder so aufs Notenblatt geschrieben - da gibt es so Wiederhol-Zeichen...)

Ich bitte darum, sowohl bei Grafik als auch bei Musik daran zu denken, daß es sich hierbei nicht um ein Gemälde und ein Orchesterstück handelt - sondern es um ein 2D-Spiellevel und Arcade-Spielemusik geht / gehen soll. Sich wiederholende Patterns sind sowohl bei Spiellevels als auch bei Spielmusik für mich durchaus akzeptabel und gewollt.

zatzen hat geschrieben:Irgendwo bin ich da aber im Mittelfeld, die klassischen MODs speichern einfach ihre 4-Kanal-64-Zeilen Patterns mit vollen 1024 Byte ab, ich hab für mein Format eine Komprimierung eingebaut, die, weil es relativ wenig Daten in der Sekunde sind (vielleicht im Schnitt 20 Byte), auch schnell genug entpackt werden. Sieht jeder heutige Informatiker als Blödsinn an, aber gerade bei Chiptunes wäre soetwas gut gewesen. Und mit Chiptune-Samples würde ich auch ausführliche Musik in wenige KB packen können.

Naja, wie gesagt: Ich bin es irgendwie komplett "andersherum" gewöhnt. Bei mir enthält die Note / der Ton auch gleich seine Länge - auf diese Art sind "Zwischen-Nullen" nicht erforderlich und ich bin bei der Notenlänge etwas flexibler und nicht auf "Taktlängen" eines Patterns angewiesen.
Ich sage es aber mal so: Prinzipiell wäre das Ganze nur eine Frage der Darstellung - denn natürlich kann man die Töne auch ohne Längenparameter und dafür "mit Abstand" im Editor/Tracker darstellen.
(Ich habe aber z.B. einen "Überparameter" für Geschwindigkeit - d.h. ich kann mit einem zusätzlichen "Multiplikationsparameter" festlegen, ob eine bestimmte Sequenz schneller oder langsamer abgespielt wird - da wüßte ich dann schon wieder nicht, wie ich das mit den Abständen machen soll. Außerdem mag ich auch so etwas wie "punktierte" Noten, d.h. ich baue auch ganz gerne mal eine 3/4 oder 1/8 Note irgendwo ein, damit es dynamischer klingt und wenn dann das Pattern auf 2/4-Takt oder 4/4-Takt ausgelegt ist, kann ich die Note ja schlecht auf "halbe Zeile" setzen - und müßte dann wegen dieser einen Note die Darstellung "auseinanderziehen" auf den nächstkleineren Takt...
Irgendwie muß mir das nochmal jemand richtig erklären, wie das funktionieren sollte mit dieser "Noten nebeneinander" Darstellung - so daß es in jeder musikalischen Konstellation noch funktioniert...

zatzen hat geschrieben:Ich denke du redest hier vom C64, ansonsten habe ich aber vor, dieses 8x8 Block Dingens auch in Echtzeit zu verwenden.

Ach, ich rede von allem - den C64 und diese Dinge habe ich nur als Beispiel angeführt. Ich mag auch so altes Konsolenzeugs wie Sega Master System (SMS) oder Super Nintendo Entertainment System (SNES) und so. Und Zeug in dieser Art will ich auch machen. Mir ist es total wurst, wie unmodern das Leute finden, die ihre fotorealistischen Kriegssimulationen spielen - die sind ja überhaupt nicht meine Zielgruppe.

zatzen hat geschrieben:Ich habe da aber auch andere Ansprüche, strebe keine Framerate von 50 fps oder höher an. Liegt auch daran, dass ich selten Actionspiele spiele.

Ach, wen interessieren schon Framerates? Ich spiele gern diese Arcade-Spiele mit Scrolling. Und ich programmiere sie so, daß, wenn der Rechner schnell genug ist, scrollt es eben mit voller Framerate - und wenn nicht, scrollt es immer noch und ruckelt etwas - ist aber immer noch spielbar (anstatt einfach auszugeben: "Ihr Rechner ist zu langsam und ich kann kein Timing programmieren, kaufen Sie sich bitte ein schnelleres System, um dieses Spiel zu spielen.")

zatzen hat geschrieben:Und dann gibts da beispielsweise Captain Comic, das hat ne Framerate von 10, Scrolling mit 8 oder sogar 16 Pixeln Schrittweite, und ist trotzdem spielbar.

Kenne ich (leider) nicht. Würde mich aber auch nicht stören, wenn es nur so "Pattern-Scrolling" hat.
Erinnert auch irgendwie an "Thexder II" alias "Firehawk"...

zatzen hat geschrieben:Sicher keine Kunst, Schrott, verglichen mit soetwas wie Katakis, aber es hat auch seine Fans und war 1989 eines der wenigen Spiele auf dem PC den wir hatten, und wir haben es gespielt, obwohl wir schon seit 3 Jahren ein flüssig scrollendes NES hatten... Naja, um die 20 fps werd ich wohl hinkriegen, dann gibt's nicht so schlimme Kopfschmerzen.

Ach, schlimmes Scrolling und niedrige Frameraten machen mir keine Kopfschmerzen. Ich kenne Leute, die wirklich Kopfschmerzen davon bekommen - naja, alles verweichlichte Leute. 16 Farben, niedrige Auflösung, 8-pixel-weises Scrolling - schon finden die es unspielbar. "Sieht ja so unecht aus..."
Ja - Leute ohne Phantasie und Vorstellungskraft brauchen immer alles "echt und hochauflösend" vorgekaut - weil sie sich nicht einfach an einem Spielprinzip erfreuen können, sondern immer alles so realitätsbezogen sein muß, daß es die Bezeichnung "Spiel" eigentlich schon gar nicht mehr verdient...

zatzen hat geschrieben:Ich kann mich nicht (mehr) als Computerfreak bezeichnen. Konnte ich zu Schulzeiten vielleicht, weil ich im Dorf der größte Computerfreak war.

So geht's mir auch - aber aus anderen Gründen:
Früher[tm] habe ich quasi jede Minute meiner Freizeit ausschließlich mit Programmieren (vielleicht 5% oder weniger mit Spielen!) verbracht. Und: Früher[tm] habe ich Zeug programmiert, das auch andere Leute, die man so kennt, auch noch benutzen konnten (C64, Anfänge PC).
Inzwischen bin ich alt und müde geworden - ich habe nicht mehr die Kraft dazu. Der Job laugt mich aus und nimmt mir meine ganze Lebenskraft. Wenn ich werktags nach Hause komme, kann ich einfach nicht mehr - ich WÜRDE gern aber KANN nicht mehr! Das ist so traurig. Und am Wochenende - bin ich zwar auch müde, aber ZWINGE mich quasi dazu, etwas am Rechner zu machen - nur um nicht das Gefühl zu haben, daß mein ganzes Leben erbärmlicherweise nur aus dem Job und Schlafen bestehen würde.
Schade ist dabei nur, daß Programmieren eigentlich mein Hobby ist - und ich nicht will, daß ich mich quasi "dazu aufraffen" muß, mal wieder irgend etwas zu leisten.
Ich merke es ja auch, sobald ich mal etwas mehr als ein Wochenende frei habe: Plötzlich geht es mir wieder besser, ich habe Kraft und Energie und programmiere wieder genau wie früher[tm]. (War letztens erst so: Da hatte ich, zusätzlich zum Wochenende, noch 2 Tage frei bekommen - sollte mal Überstunden abbauen - und schon habe ich die restlichen Dinge an der Soundunit fertiggemacht, einen großen Teil der Hilfe des anderen Editors weitergeschrieben, dort einige Bugs entfernt und kleine Features eingebaut, die ich da schon lange wollte UND sogar das eine Projekt für den einen Kumpel um eine neue Version verbessert - und zwar ohne, daß er mich darum gebeten hatte!
Tja - Jobs stören einen in seiner Kreativität, saugen einem die Kraft aus wie Vampire, machen einem das ganze Leben kaputt. Man läuft die ganze restliche Zeit nur noch herum wie ein seelenloser Zombie, der versucht, sich irgendwie am Leben zu erhalten und sich selbst zwingt, seinem Leben irgendeinen Sinn zu geben, um nicht auf den Gedanken zu kommen, daß die ganze Existenz eigentlich komplett ohne jeden Daseinszweck ist - weil es jeder MASCHINE der Welt besser geht als einem selbst - die zwar, genau wie man selbst, auch nur "stupide vor sich hin funktionieren" - aber wenigstens merken sie nichts davon...
Jobs - Eigentlich sollten sie verboten werden...

zatzen hat geschrieben:Aber heute... Ich bin jetzt mehr zum Tonmensch mutiert, das ist etwas was mir mehr liegt auf Dauer, eher irrationale Arbeit, mein Hirn verkrampft bei zu viel logischem Denken.

Bei mir ist es umgekehrt: Früher[tm] habe ich auch öfter mal viel Zeit damit verbracht, Grafiken zu bauen, die dann nie irgendwo verwendet wurden und manchmal auch Musiken zu machen, für die es dann keine Plattform gab.
Heute ist es eher so, daß ich total gern NUR NOCH programmiere: die ganzen internen Abläufe baue und Darstellungsroutinen für Grafikelemente und Generator-Routinen für Musik - aber quasi kaum noch Zeit und Lust habe, wirklich Grafiken zu erstellen und Musiken zu machen...

zatzen hat geschrieben:Aber irgendwas treibt mich dazu an, immer mal wieder was zu programmieren.
Ist halt ab und zu mal ne gute Übung.

Das sowieso. Ich habe es auch manchmal fertiggebracht, wochenlang nichts zu programmieren. Aber irgendwann bekomme ich dann regelrechte Entzugserscheinungen und muß dann - "wenigstens etwas Kleines" - programmieren, damit - wie der Alkoholiker sagen würde: "das Zittern aufhört"...

zatzen hat geschrieben:Daher aber eben mein eigenes Spiele-Bau-Set, ich bin man gespannt ob ich das hinkriege
dass man mit ein paar Textdateien als Definition und entsprechenden Grafik und Musik-daten ein Spiel bauen kann. Eigentlich erdenke ich mittlerweile nur Dinge, die sich auch machen lassen.

Naja, ich hatte auch mal irgendwann daran gedacht, den ganzen Kram, den ich so mache, als einen GameMaker anzulegen. Ich habe mich aus einigen Gründen dagegen entschieden:
1.) Vor lauter am-GameMaker-Bauen würde ich irgendwann gar nicht mehr dazu kommen, auch wirklich mal wieder ein Spiel zu machen (was ich sehr schade fände).
2.) Wenn man so etwas macht, nimmt man in Kauf, die Möglichkeiten eines Spiels auf die des GameMakers zu reduzieren (was ich noch viel schaderererer fände).
3.) Generalisierte Routinen, die dafür ja zweifellos nötig wären, haben leider oft die Eigenschaft, den Speicherverbrauch hoch- und die Performance runterzudrehen (was ich am allerschadetesten fände).

Aber das ist natürlich nur meine persönliche Meinung dazu, die mich irgendwann dazu gebracht hat, mich gegen den Bau eines GameMakers zu entscheiden. (Und ja - daran gedacht hatte ich auch schon öfter mal.)

Ich habe mich jetzt eher dafür entschieden, für die einzelnen Spielkomponenten einzelne Tools zu bauen. Der Grund ist der, daß das Tool selbst natürlich Speicher braucht (für seinen Programmcode) und noch möglichst ausreichend Speicher für die vom "User" erzeugten Daten übrigbleiben soll. Ein kompletter GameMaker müßte erst einmal ALLES an Features enthalten, was so ein Spiel enthalten kann (wäre dann wohl ein riesiges Programm) und außerdem müßte er dann selbst die "Verknüpfung" der ganzen Dinge untereinander machen. Das Ganze würde dann meiner Meinung nach in eine Richtung ausarten, daß die Spiele, die man damit macht, keine "ausführbare EXE" , wären, sondern daß man quasi immer so eine "Interpreter-EXE" hätte, die dann das "Spielskript" ausführt. (OK, kann man auch als Overlay an die EXE anhängen.) Ist zwar eine Idee - und auch umsetzbar. Aber mir tut schon alles weh, wenn ich daran denke, wie das auf einem 486er oder 386er performen würde...
Und dabei habe ich hier wirklich Dinge, mit denen man so eine "Interpreter-EXE" bauen könnte. Denn dieses GameSys2 ist ja quasi schon irgendwie so ein Interpreter (für die Steuerung)... Und Grafik und Sound werden ja auch von Subroutinen abgespielt...
Aber, sobald ich mal irgend etwas anderes noch einbauen wollen würde... naja. Müßte echt mal sehen, ob das Sinn macht.

Letztens hatte ich mal eine Idee, wie ich aus meinem ganzen Kram so einen "GameMaker" bauen könnte: Indem ich es mache wie der Norton Commander 5: Eine kleine EXE, die je nach Wunsch die großen EXEn aufruft...

Naja, wie gesagt: An sich auch alles machbar - aber irgendwie dauert mir dieser ganze Entwicklungsprozeß mittlerweile dann doch schon wieder etwas zu lange - ich will endlich mal wieder ein Spiel machen! Ich habe so viele Ideen, die rauswollen...

zatzen hat geschrieben:Das beste herauszuholen, was man schaffen kann... Ist ja heute witzlos am PC irgendwie. Die Grenzen sind nicht fest. Ich fühle mich nur mit dem 8x8 Ding ein bisschen verbunden
mit den alten 8 Bit Rechnern. Auch wenn ich von denen nicht so viel Ahnung habe.

Naja, irgendwie wird heute an diesen superschnellen PCs meiner Meinung nach viel zu oft mit der Prämisse programmiert: "Leistung und Speicher ist ja mehr als genug vorhanden, machen wir doch mal ein Tool/Spiel, das aus 5 ineinander verschachtelten Skripten und 10 sich gegenseitig behindernden Libraries besteht - Hauptsache, es dauert nicht zu lange..." -
Anders kann ich mir Dinge wie "Lotus Notes" einfach nicht erklären...

zatzen hat geschrieben:Aber ich glaube ich rechtfertige mich hier irgendwie zu viel, ich bin halt am PC vor allem
in den 90ern aufgewachsen und das hat mich geprägt. Die echten Grenzen des Real Mode. Die Spiele zu der Zeit haben mich beeindruckt, irgendwie mehr als die nach Mitte der 90er, als alles 3D und hochauflösend wurde.

Hier braucht sich doch niemand für etwas rechtfertigen, das er als sein Hobby macht. So lange es einem Spaß und Freude macht - und bestenfalls auch noch ein gelegentliches Erfolgserlebnis bringt - ist die Aufgabe eines Hobbys meiner Meinung nach bereits vollständig erfüllt.
Daß dann dabei noch etwas "herauskommt", das etwas wie ein "Endprodukt" ist, das man anderen zeigen/geben kann und das diese "anderen" dann vielleicht sogar mögen/schätzen, wäre quasi nur noch das Sahnehäubchen. Aber je nachdem, wie "populär" das ist, was man da anstellt, muß man sich klarmachen, daß man auch eventuell ganz ohne Sahnehäubchen auskommen muß. Wenn man das abkann, ist es OK.

zatzen hat geschrieben:Und da bin ich froh dass ich jetzt (viel zu spät) wenigstens etwas für den Standard machen kann, das sich (wahrscheinlich) sehen lassen kann. Jahrelange Programmierarbeit am
Stück würde mich zermartern, daher lieber ne Engine bauen und dann zwischendurch immer mal wieder Spiel basteln, vielleicht mal die Engine updaten usw. Ist für mich gerade der vernünftigste Weg, mit meinen Programmierkenntnissen in meinem Leben noch etwas sinnvolles anzufangen.

Ja - seufz - wäre es für mich auch. Leider neige ich inzwischen dazu, aufgrund der obengenannten "schlechten Erfahrungen" die ich gemacht habe(halbfertiges Zeug schnell irgendwo reingestopft, danach Code gehabt, den man nicht mehr anfassen will und daher etliche unfertige Projekte herumliegen haben), alles "gleich richtig", bzw "gleich so, wie es sein soll" machen zu wollen - und plane und ändere und überdenke und verwerfe... um nicht schon wieder mein Zeug irgendwo einzubauen mit dem Wissen, daß ich damit eigentlich noch nicht zufrieden war.

zatzen hat geschrieben:Was den Tracker angeht: Ich könnte wirklich nur Musik machen, wenn es so einer wäre
mit Nullen drin. Ist einfach eine rhythmische Sache.

Ja, wie gesagt: Jeder macht das basierend auf seinen Erfahrungen. Da gibt es eben kein "richtig" oder "falsch". Richtig ist, wenn es funktioniert - und es gibt dabei mehrere Arten, richtig zu sein.

zatzen hat geschrieben:Für Tracker-Anfänger ist es schon schwer genug, in diesem System überhaupt die richtigen Notenlängen hinzukriegen.

Naja, ich addiere immer im Kopf...

zatzen hat geschrieben:Wenn du einen Converter machen kannst, okay. Ich habe nur gedacht, das wäre eher
schwierig, weil ich ja deinen kompletten Synthesizer als Samples bräuchte um zu wissen wie es hinterher klingt.

In der Tat. Ich erlaube jeweils 16 Werte für Attack, Decay, Sustain und Release und zusätzlich kann man noch 4 von 7 Wellenformen miteinander mit unterschiedlichen "Auflösungen" zueinander kombinieren und Noise käme auch dazu. Natürlich gäbe es da auch viele "Doppelungen", aber im Allgemeinen käme man wohl derzeit auf vielleicht so zwischen 2000 und 3000 Kombinationen alleine der Wellenformen (von denen einige mehr oder weniger sinnvoll sind), gar nicht zu reden von den ADSR-Werten, die im Sample ja noch dazukämen...
Ich habe das bei Weitem noch nicht alles ausprobiert - ich wollte nur möglichst viele Möglichkeiten für die Klangsynthese schaffen, damit nicht alles klingt wie Pong.

zatzen hat geschrieben:Einen SID könnte man nicht so einfach samplen, auch kein OPL Chip, ich weiss nicht wie komplex deiner sein wird.

Naja, die "Komplexität" sieht man ja an dem Beschreibungsfile, das ich vor einiger Zeit mal hochgeladen habe. (Ich habe mittlerweile noch geringfügige Änderungen vorgenommen.)
Das - und NUR DAS - kann diese Soundunit - bzw wird sie mal können.

zatzen hat geschrieben:Deshalb dachte ich, dass ich vielleicht einen Tracker schreiben würde. Die Abspielroutinen wären ja von dir gegeben, ich bräuchte also im Prinzip nur die Oberfläche etc. machen. Macht aber keinen Sinn wenn das Format intelligent komprimiert programmiert werden muss.

Naja, das einzige, was hier "komprimiert" ist (was ich gar nicht mal als Komprimierung ansehe), ist, daß die Notenlängen (und Pausenlängen etc) gleich mit bei den Noten stehen. Ich bin schon mittlerweile in Versuchung, meinen Soundeditor mit zwei Modi auszustatten: Meinem "Coder" Mode und diesem "Tracker" Mode... Intern würden dieselben Daten verwendet werden, aber angezeigt eben im entsprechenden Modus.

Soweit ich das auf diesem Bild erkennen kann, stehen da in den Tracks die Noten und davor so Zahlen. Ich vermute einfach mal kackenfrech, daß diese Zahlen jeweils für ein "Instrument" stehen (prinzipiell in diesem Fall also für ein Sample). Es wird also in jedem "Befehl"/""Frame" zum Ton zusätzlich das Sample/Instrument angegeben, dafür nicht die Länge.

(Hm - bei mir ist es genau umgekehrt. Wenn man das Instrument wechseln will, gibt es dafür einen Befehl. Man kann die Werte zwar auch einzeln einstellen - man kann aber auch ADSR, Wellenform und Filter (oder alternativ ein Sample) einstellen und es als "Instrument" speichern. Dann gibt es nur einen "Instrument" Aufruf.)

Frage dazu: Ich sehe pro Track 3 "Bahnen". Linke Bahn ist das Instrument. Mittlere Bahn ist die Note. Was macht die rechte Bahn?
Außerdem: Wie/wo definiert man die Geschwindigkeit? Ich meine: Ein Abstand zwischen zwei Noten muß ja quasi die kürzestmögliche Note sein. Wenn es aber ein schnelles Stück ist, bräuchte man vielleicht Achtel- und Sechzehntel-Noten. Bei so einer Auflösung wäre aber ein langsames Stück quasi fest nur mit Leerräumen gefüllt. Editiert sich das dann überhaupt noch?

Irgendwie scheint dieses ganze gängige Tracker-Konzept eine echte Herausforderung zu sein, wenn man mein Musikformat mit so einem Tracker darstellen/editieren wollen würde. Nicht unmöglich - aber eine ziemliche Herausforderung...

Hätte auch gerne mal irgendeine "Datenbeschreibung" dieses Formats, damit ich sehen kann, womit man es zu tun hätte.

Und: Ich habe auch keine Ahnung, ob ein Musikenthusiast wie Du auch wirklich mit einem derartig eingeschränkten Klangbild, das mein krudes Teil da liefert, überhaupt umgehen könnte, bzw überhaupt wollen würde. Es wird nicht nach Filmorchester klingen...

Ersteinmal zu dem Tracker:

Bei der Track-Dastellung siehst du ersteinmal links die Sample-Nummer, dann die Note,
und daneben ist noch Platz für Effekte bzw. Lautstärkebefehle. Bei dem Screenshot
ist nur gerade weder Lautstärke noch Effekt programmiert.
Es können dabei 3 Effekte gleichzeitig drin sein und ein Lautstärke-Befehl.
Ich habe das nur für das Video (screenshot ist von einem Youtube Video)
so eingestellt dass es etwas kompakter wird, damit man mehr Kanäle
gleichzeitig sieht.

Jetzt ist es so, die Parameter, vor allem die Sample-Nummern, können
natürlich eine gewisse Redundanz aufweisen. Und in meinem eigenen
Trackerformat, um nicht für jede Note permanent noch ein Byte dazu
speichern zu müssen, habe ich nur vermerkt mit einem Bit, dass die
Note gespielt werden soll. Und die Sample-Nummer wird auch nur
gewechselt in meinem Format, ebenso die Note, so dass z.B. Track 4
hier jeweils mit nur 1 Bit schon definiert ist.

Das Klangbild deines Synthesizers wäre sicher kein Problem, ich bin gerne
auch experimentell und mag klassische Instrumente gar nicht so unbedingt.

Die Geschwindigkeit im Tracker kann in jeder Zeile definiert werden.
Festgelegt werden muss vorab fürs ganze Pattern, wieviele Zeilen eine
Viertelnote haben soll. Ich verwende da heutzutage meistens 8, so dass
die kleinste Note eine 32tel sein kann. In der Praxis kommen aber eher
meistens nur 16tel vor, es gibt da Befehle die Samples mehrfach pro
Zeile triggern, aber wenn ich 32tel habe brauche ich das eigentlich nie.
Bei einem langsamen Stück läuft ja auch das ganze Pattern langsamer,
wenn ich statt 140 BPM meinetwegen 80 BPM einstelle.

Eine drei-viertel-Note realisiere ich so, dass ich, betrachten wir mal
8 Zeilen, in Zeile 0 das Sample starte und in Zeile 6 ein "Note Off"
setze.

Das klassische Notensystem macht das alles quasi doppelt, man ordnet
(meistens) die Noten so an, dass sie an der richtigen Position stehen,
so dass wenn man gleichmäßig von links nach rechts durchgeht diese
zur richtigen Zeit erklingen, gleichzeitig haben sie aber auch ihre
Längen durch ihre Form und Pause definiert.

Zum Dateiformat kann ich dir vielleicht einfach mal das gute alte Amiga MOD-Format
empfehlen. Dazu dürfte es im Internet genügend Lektüre geben. Für den X-Tracker
heissen die Dokumente DMFDOCS.ZIP, die darf ich hier aber weder anhängen, noch
finde ich gerade eine vertrauliche Seite im Netz dazu.

Was ich vielleicht interessant fände: Ein Converter, der automatisch redundante Strukturen
in einem Musikstück findet. Das ist kein Ding der Unmöglichkeit, weil Musik die Eigenschaft
hat, meistens alle 4, 8 16 oder usw. Zeilen Redundanz zu besitzen.
Ich habe es aber der Einfachheit halber bei meinem kleinen Trackerformat linear gehalten,
so dass ich Zeile für Zeile lese und nicht immer wieder Unterpatterns laden muss.


Meine Game-Engine könnte von daher relativ einfach und doch gut funktionierend sein, weil
ich einen gewissen Stil voraussetze. Grob gesehen soll es Jump&Run werden, nur ein bisschen
weniger auf Skill getrimmt und dafür mit mehr Unterhaltung. Ich muss aber eben nicht alles
definierbar machen, sondern grundsätzlich soll es von der Seite zu sehen sein mit Plattformen.
Die Aufmachung soll ansonsten aber auch ein bisschen in Richtung Adventure gehen.
Ich möchte nicht für alles, was ich in das Spiel neu reinbringe, programmieren und somit
das Programm wieder von der Pike auf verstehen müssen. Aber nichtsdestotrotz werde
ich mir Mühe geben, alles so in Units aufzuteilen, dass ich nur jeweils die kleinen Units
in sich überblicken muss, und nicht den kompletten Code wälzen.
Die Spieldaten würden natürlich kompiliert, lägen also am Ende nicht als Textdatei vor,
sondern Binär, und das "Abspielprogramm" lässt sich dann einfach tarnen indem man
es so nennt wie die Datendatei.
Es ist vielleicht ein anderer Ansatz, ich möchte weniger mit Scripting arbeiten, als
vielmehr mit Variablendefinitionen, welche die Engine einfach in Datenfelder lädt,
die nötigenfalls auch mit Assembler abgearbeitet werden können.
Also wie gesagt, Probleme mit Generalisierung hätte ich eher nicht, weil es ja nur ein
spezieller Typ von Spiel werden soll, den ich damit realisieren kann. Und der mir aber
auch genügt. Und der "Game Maker" wächst mit dem ersten Spiel. Für den Anfang wird
es mir genügen, ersteinmal eine Figur auf einer Plattform vor einem Hintergrund bewegen
zu können. Meine Idee dabei ist ersteinmal, alle vorkommenden Objekte vielmehr
als Subjekte zu betrachten, so dass diese aus ihrer Sicht auf andere reagieren.
Ich werde sehen ob sich das mit der Rechenzeit vereinbaren lässt. Herkömmliche
Ansätze fände ich ersteinmal langweilig.

Was immer auch an Programmierarbeit ich machen möchte: Ich möchte es jetzt
für mich human gestalten. Es macht richtig Spass, kleine Programmteile zu schreiben.
Aber wenn man ein einziges 1000 Zeilen Programm vor sich hat, wird man irgendwann
rational blind. Ich jedenfalls. Das ist überhaupt meine Schwierigkeit beim Programmieren,
dieses Doppel-Denken: Man sieht den Code, muss sich aber vorstellen, was dabei im
Computer passiert.

Was Informatik in der Schule angeht, das hatte ich dort ein Jahr. Das war das Sprungbrett zu Pascal,
ich hatte schon vorher Pascal gesehen, es hatte mir aber nicht zugesagt. Ich hatte ein Buch, wie man
darin Spiele programmiert, darin war aber nur beschrieben wie man den PC-Speaker benutzt und
wie man Grafik mit den Pascal eigenen Zeichenroutinen macht. Und solche Strichgrafik find ich einfach
öde. Ähnlich ist es ja bei 3D, diese "Luftmatratzen"...

Ein wenig später hatte ein Lehrer mal gestaunt, was ich mit eher hardwarenaher Programmierung
zustande brachte (einlesen eines undokumentierten Grafikformates etc.), aber solche typischen
Informatik-Dinge wie "Türme von Hanoi" hab ich nicht gerafft.


Ich habe auch ein paar auf der Strecke gebliebenen Spiele. Das liegt aber einfach daran, dass ich
Hals über Kopf daran gegangen bin. Da habe ich mir gedacht, mache ich schonmal ein paar Grafiken
damit ich die beim Programmieren verwenden kann... Aber das Programmieren selbst war dann
wieder so eine große Hürde... Ich habe jetzt ein gutes Gefühl damit wenn ich erstmal alle benötigten
"Engine"-Teile fertigstelle.
Grafiken habe ich vor allem früher in Deluxe Paint II gemacht. Was erzeugbare Farbverläufe angeht
ist es bis heute noch sehr attraktiv, und auch weil es Kreise mit der richtigen Aspect Ratio für
320x200 macht. Ich habe nebenbei gedacht, meinen Grafik-Converter werde ich für PCX als
Quelldateien auslegen, die sind, weil sie nicht so viel Headerzeugs und sowas haben, trotz
der Lauflängenkomprimierung einfacher als BMP zu handhaben. Aber, und das auch weil ich
es mir mit heutiger Massenspeicherplatztechnologie leisten kann, denke ich, werde ich das
so machen dass ich jede Grafik, auch einzelne Bewegungsphasen, jeweils als ein PCX
speichere, und nicht mehrere Sprite-Phasen auf ein Bild.

Grundsätzlich würden mich aber deine ganzen Tools schon interessieren.

Das mit den Framerates hat mich jetzt ein bisschen erstaunt. Und manchmal denke ich auch, so eine
saubere Framerate wie bei Konsolenspielen ist beneidenswert. Aber ähnlich wie bei einem C64 fühle
ich mich eher wohl, wenn ich eine bestimmte Entwicklungsphase des PC als monolithisch ansehe
und da schon, wenigstens erstmal für mich selbst, eine Mindestleistung voraussetzen kann.
Es ist für mich gerade einfacher. Ich habe keine Erfahrung mit Timer umbiegen, habe auch früher
in meinen QBASIC programmen einfach SOUND 0, 1 oder sowas benutzt um Verzögerungen
einzubauen, oder ausgemessene Warteschleifen, was die schlechteste Lösung war.
Würde ich es mit dem Timer lösen, ist mir noch ein Rätsel, wie ich dann noch den Ton
Synchron mache. Ich habe es bei anderen Spielen erlebt, dass der Sound hinterherhinkt.
Irgendwie stört mich das schon. Beispielsweise bei einem Flipper, man bewegt einen,
und es macht "tack" wenn der schon längst wieder ruhig liegt.
Meine Engine realisiere ich ersteinmal so. Die Performance langsamer Rechner ausser
acht gelassen, ist es eigentlich sogar richtiger, wenn man den Sound als Timer nimmt.
So als wäre es ein spielbares Video. Bei einem Video, mit Sprache vor allem, stört
es enorm, wenn Bild und Ton auch nur ein oder zwei Frames auseinandergehen,
d.h. schon ab etwa 50 ms Versatz. Videos sind oft so verschachtelt, dass Bild-
und Tondaten jeweils Bildweise hintereinander kommen.
Da es eine Engine ist, die nicht mit den erzeugten Spielen "zusammenklebt", kann
ich mit mehr Weisheit später alles noch so umprogrammieren, dass es auch auf 386ern
mit ner Framerate von 8 oder so spielbar ist.
Eine Kompromisslösung wäre noch, die Performance vorher auszumessen und die
Framerate auf einen entsprechend niedrigeren Wert festzulegen. Ich habe nämlich
auch eine Aversion gegen ständig wechselnde Framerates, bei Sierra Games
der 90er sieht man das oft, dass Animationen mit den unterschiedlichsten
Framerates laufen, das sieht irgendwie "unecht" aus, gefällt mir nicht.
So hat jeder seinen Geschmack. Ich finde es reizvoll, wenn ein Spiel einen
Hauch von "das ist ein interaktiver Film" hat.

zatzen hat geschrieben:Das Klangbild deines Synthesizers wäre sicher kein Problem, ich bin gerne
auch experimentell und mag klassische Instrumente gar nicht so unbedingt.

Naja, erwarte da mal lieber nicht zu viel. Für einen Sound-Gourmet ist das sicher nicht gerade ein Ohrenschmaus oder so. Von CD-Qualität WEIT entfernt.

zatzen hat geschrieben:Die Geschwindigkeit im Tracker kann in jeder Zeile definiert werden.
Festgelegt werden muss vorab fürs ganze Pattern, wieviele Zeilen eine Viertelnote haben soll. Ich verwende da heutzutage meistens 8, so dass die kleinste Note eine 32tel sein kann. In der Praxis kommen aber eher meistens nur 16tel vor, es gibt da Befehle die Samples mehrfach pro Zeile triggern, aber wenn ich 32tel habe brauche ich das eigentlich nie. Bei einem langsamen Stück läuft ja auch das ganze Pattern langsamer, wenn ich statt 140 BPM meinetwegen 80 BPM einstelle.

Eine drei-viertel-Note realisiere ich so, dass ich, betrachten wir mal
8 Zeilen, in Zeile 0 das Sample starte und in Zeile 6 ein "Note Off"
setze.

Ich habe mir neulich mal einen Text über das "aktuellst gültige" MOD-Format heruntergeladen.
Ja, ich verstehe komplett, wie es funktioniert. Und ja, mein Format ist da sehr anders. Und mein Format hat nicht ganz so viele Möglichkeiten. An gleichzeitiges Frequenz- und Volume-Gleiten habe ich z.B. nie gedacht.

zatzen hat geschrieben:Das klassische Notensystem macht das alles quasi doppelt,

Finde ich nicht. Die Noten stehen immer direkt hintereinander. Ihre Länge wird NUR durch ihre Form definiert. Es gibt keine "Nullbereiche". Lediglich wenn mehrstimmig gespielt wird, stehen die entsprechenden Noten in den verbundenen Notenlinien direkt untereinander, um dies zu verdeutlichen. Allerdings wird nicht ein großer leerer Abstand irgendwo eingestellt, wenn eine Note lange dauern soll - das passiert höchstens, wenn auf der anderen Linie gleichzeitig viele kurze Noten gespielt werden sollen - damit diese Platz haben. Aber die horizontale Notenposition wird immer "platzsparend" gesetzt und hat nichts mit der Länge zu tun. Es wäre für einen Musiker auch extrem schwer, alleine aus den Abständen der Noten voneinander die genaue Tonlänge abzuschätzen - dies wird allein nur durch die Form (leerer/voller Kopf, Hals/kein Hals, keine/ein/mehrere Fähnchen)
Und die Frequenz (Tonhöhe) wird durch die vertikale Position auf der den Notenlinien dargestellt. Wo ist da etwas doppelt?

zatzen hat geschrieben:Zum Dateiformat kann ich dir vielleicht einfach mal das gute alte Amiga MOD-Format empfehlen. Dazu dürfte es im Internet genügend Lektüre geben. Für den X-Tracker heissen die Dokumente DMFDOCS.ZIP, die darf ich hier aber weder anhängen, noch finde ich gerade eine vertrauliche Seite im Netz dazu.

Ja, wie bereits oben erwähnt habe ich dazu letztens eine ausführliche Dokumentation gefunden.

zatzen hat geschrieben:Was ich vielleicht interessant fände: Ein Converter, der automatisch redundante Strukturen in einem Musikstück findet. Das ist kein Ding der Unmöglichkeit, weil Musik die Eigenschaft
hat, meistens alle 4, 8 16 oder usw. Zeilen Redundanz zu besitzen.

Ich habe an so etwas schon mal gedacht - wäre ja dann auch nützlich, wenn man z.B. das MOD-Format in mein Format wandelt und dabei Wiederholungen in Schleifen oder "Untersektionen" ("Unterprogramme") legt. Aber zunächst erst einmal soll mein Editor überhaupt erst einmal so funktionieren, wie er soll, damit man überhaupt erst einmal etwas damit anfangen kann. Die Erweiterungen/Konverter kommen dann auch noch.

zatzen hat geschrieben:Ich habe es aber der Einfachheit halber bei meinem kleinen Trackerformat linear gehalten, so dass ich Zeile für Zeile lese und nicht immer wieder Unterpatterns laden muss.

Ja, schon klar.

zatzen hat geschrieben:Meine Game-Engine könnte von daher relativ einfach und doch gut funktionierend sein, weil ich einen gewissen Stil voraussetze. Grob gesehen soll es Jump&Run werden, nur ein bisschen weniger auf Skill getrimmt und dafür mit mehr Unterhaltung. Ich muss aber eben nicht alles definierbar machen, sondern grundsätzlich soll es von der Seite zu sehen sein mit Plattformen.

Die Aufmachung soll ansonsten aber auch ein bisschen in Richtung Adventure gehen.
Ich möchte nicht für alles, was ich in das Spiel neu reinbringe, programmieren und somit das Programm wieder von der Pike auf verstehen müssen. Aber nichtsdestotrotz werde ich mir Mühe geben, alles so in Units aufzuteilen, dass ich nur jeweils die kleinen Units in sich überblicken muss, und nicht den kompletten Code wälzen.
Die Spieldaten würden natürlich kompiliert, lägen also am Ende nicht als Textdatei vor, sondern Binär, und das "Abspielprogramm" lässt sich dann einfach tarnen indem man es so nennt wie die Datendatei.

Im Prinzip beschreibst Du damit genau das, was meine Spielengine bereits tut.
In einer "Textdatei" (im Prinzip also dem "Sourcecode" für die Figurenbewegung/Figurensteuerung) schreibt man das "Programm" (bzw die Programme) für die Figuren und sonstigen beweglichen Elemente - inklusive der Spielerfigur selbst. Dies wird dann in Bytecode "compiliert"/"assembliert" und von dem entsprechenden Interpreter (der wie eine VM arbeitet) namens GameSys2 ausgeführt.

Ja - ich könnte jetzt auch einen vorläufige Doku-Text zu GameSys2 hier verlinken - sogar deutsch. Nur ist das Ganze reichlich technisch und sieht irgendwie schon wie eine Doku zu einer "Software-CPU" aus. Und der Text ist in der "bereinigten" Form knapp 180 kByte groß, die Form mit Angabe zusätzlicher interner Funktionsweisen ist derzeit ca. 195 kByte groß.
Ich glaube nicht, daß sich das jetzt jemand durchlesen wollen wird. (Außerdem werde ich wahrscheinlich an den Texten noch hier und da an ein paar Ecken feilen, vielleicht auch die Reihenfolgen der Abschnitte etwas ändern oder manche Redundanzen aus dem Text entfernen.)

zatzen hat geschrieben:Es ist vielleicht ein anderer Ansatz, ich möchte weniger mit Scripting arbeiten, als vielmehr mit Variablendefinitionen, welche die Engine einfach in Datenfelder lädt, die nötigenfalls auch mit Assembler abgearbeitet werden können.

Naja, wie man es nennt, ist schlußendlich eigentlich egal. Die Grenzen zwischen einer Interpretersprache und Skripting sind eigentlich fließend.

Ich sage es mal so: Ich habe bei vielen Dingen, die ich gemacht habe, anfangs immer gedacht, daß ich es "nur ganz einfach mache", mit ein paar Eckparameter-Definitionen usw. - Fast jede meiner "Sprachen"/"Darstellungs-Skripte" etc. habe ich dann im Nachgang "außenherum" erweitert (erweitern müssen), weil dann wieder irgend etwas spezielles nicht darstellbar war oder einen extremen Aufwand bedeutet hätte, es aus den wenigen vorhandenen "Sub-Elementen" zusammenzuklöppeln. Diese "Erweiterungen" waren dann so "außenherum angeflanscht" - und sowohl der "Sourcecode" als auch der "Interpreter" wurden dadurch nicht schöner... Das sind aber nur meine persönlichen Erfahrungen mit dieser Materie. - Mittlerweile (wie bereits mehrfach erwähnt) plane ich solche Dinge immer im Vorfeld und versuche, so viel wie möglich Features bei so wenig wie möglich Speicher/Rechenzeit-Aufwand zu ermöglichen - so daß ich am Ende einen guten Kompromiß zwischen Funktionalität und Ressourcenaufwand erreiche. Und ja: Diese Planerei kostet leider Zeit. Und mitunter schmeiße ich auch wirklich mal etwas weg, in dessen theoretische Ausarbeitung/Entwicklung ich einiges an Mühe investiert habe - wenn ich dann merke, daß es so nicht geht, bzw nicht gut wird.

zatzen hat geschrieben:Also wie gesagt, Probleme mit Generalisierung hätte ich eher nicht, weil es ja nur ein spezieller Typ von Spiel werden soll, den ich damit realisieren kann. Und der mir aber auch genügt. Und der "Game Maker" wächst mit dem ersten Spiel.

Naja, eine gewisse Generalisierung gibt es bei mir in jedem Fall auch - da natürlich immer die gleichen/ähnlichen Subroutinen verwendet werden und dementsprechend auch die gleichen/ähnlichen Formate. - Anders ist es quasi gar nicht möglich, überhaupt einmal irgendwann "zu etwas zu kommen", also ein Projekt fertigzubekommen. Erfindet/entwickelt man für JEDES Projekt neue Tools, neue Formate, neue Subroutinen - quasi OHNE Wiederverwendung bereits entwickelter Strukturen - wird dies ein sehr sehr mühseliges Unterfangen. - Und dann könnte man auch gleich ohne jegliche Vorbereitung alles "direkt auf die kalte Maschine" coden.

zatzen hat geschrieben:Für den Anfang wird es mir genügen, ersteinmal eine Figur auf einer Plattform vor einem Hintergrund bewegen zu können. Meine Idee dabei ist ersteinmal, alle vorkommenden Objekte vielmehr
als Subjekte zu betrachten, so dass diese aus ihrer Sicht auf andere reagieren.

Hm... Ja, wie gesagt. Diese Funktionalität hat z.B. GameSys2 (bzw Arcade01, die "dazugehörige" Grafikengine) schon eingebaut: Bewegung von Objekten - gegenseitig aufeinander und auf das Level bezugnehmend. Also z.B. Reaktion auf "Kollision" (also Koordinatenannäherung) zweier (oder mehrerer) Objekte - kann je nach Typ Aufsammeln eines Bonus, Treffen mit einem "Schuß", Schubsen von Figuren, Daraufspringen bedeuten). Oder Reaktion auf Level (z.B. ob die Figur (noch) auf der Plattform steht oder nicht (mehr), eine Treppe/Schräge hochläuft, auf gefährliche "Spitzen" tritt, eine Tür öffnet/Schalter auslöst...

zatzen hat geschrieben:Ich werde sehen ob sich das mit der Rechenzeit vereinbaren lässt. Herkömmliche Ansätze fände ich ersteinmal langweilig.

Ich weiß gar nicht, ob es hierfür überhaupt "herkömmliche" Ansätze gibt, also eine feste Vorgehensweise, um solche Dinge zu koordinieren. Ich selbst habe z.B. einfach nur etwas entwickelt, von dem ich denke, daß es für den Zweck brauchbar ist - aber für meine Figurenbewegungs-/Steuerungs-/"Befehle" oder Kollisionsbearbeitung habe ich kein "Standardformat"/"Standardarbeitsweise" benutzt - (ich weiß nicht, ob es dafür überhaupt eine solche gibt), sondern habe einfach getan, was ich "für richtig hielt". Daß es offensichtlich funktioniert (siehe mein Beispielprogramm TGAME.EXE) zeigt, daß es wohl nicht die schlechteste Idee war...

zatzen hat geschrieben:Was immer auch an Programmierarbeit ich machen möchte: Ich möchte es jetzt für mich human gestalten.

Das ist eine recht seltsame Definition...

zatzen hat geschrieben:Es macht richtig Spass, kleine Programmteile zu schreiben.
Aber wenn man ein einziges 1000 Zeilen Programm vor sich hat, wird man irgendwann rational blind. Ich jedenfalls.

Ich pflege dabei immer wieder zu sagen: Ich denke dabei wie ein Mathematiker:
1.) Um ein großes (scheinbar) unlösbares Problem zu lösen, sollte man es in kleine, lösbare Probleme zerlegen.
2.) Das Ganze funktioniert iterativ. Das bedeutet: Sind die kleineren Probleme immer noch (scheinbar) unlösbar, kann man sie weiter in noch kleinere Probleme zerlegen.
3.) Irgendwann ist jedes Problem so klein, daß es lösbar ist.
4.) Die gelösten Teilprobleme, also Teilelemente, kann man dann wieder rückwärts zu den größeren Elementen zusammensetzen.
Ist man dabei besten Wissens "diszipliniert" und vernünftig vorgegangen, ist das Problem gelöst.

zatzen hat geschrieben:Das ist überhaupt meine Schwierigkeit beim Programmieren, dieses Doppel-Denken: Man sieht den Code, muss sich aber vorstellen, was dabei im Computer passiert.

Woran liegt es nur, daß mir beim Wort "Doppel-Denken" die Zahlenfolge 1 9 8 4 in den Sinn kommt...?

Und: Für mich ist es quasi überhaupt keine Schwierigkeit, mir vorzustellen, was der Code dann im Computer anstellt. Das ist ja auch der Grund, wieso ich so gern "systemnah" programmiere und warum ich mit abstrakten systemfernen Skriptsprachen, neumodischen Designersprachen u.ä. nichts anfangen kann: Ich kann nicht mehr sehen, was genau die Skriptinterpreter bzw die ganzen Abstraktionslevel, die dieser Pseudocode durchläuft, mit diesem anstellen und als was er dann schließlich "auf der blanken Maschine" aufschlägt. Man nenne mich deshalb ruhig paranoid - aber ich fühle mich da unsicher, wenn ich etwas "einfach nur als grobes Konzept" irgendwo eingebe/anweise und es dem System und den zwischengeschalteten "Blackbox"artigen Layern quasi völlig überlassen soll, zu "erraten", was die Anweisungen bedeuten sollen.
(Hm... Da fällt mir ein: Dinge wie diese sind übrigens der Stoff, aus dem Horrorvisionen wie SkyNet entstanden sind...)

Auf den nächsten Eintrag antworte ich später (morgen oder am vielleicht am Wochenende).

Da noch eine Antwort von dir ansteht, antworte ich nur kurz:

Dieses "Doppel-Denken" ist vielmehr so zu verstehen, dass ich mehr oder weniger Probleme habe,
etwas abstrahiert nachzuvollziehen. Wenn ich in der realen Welt etwas bastle, dann sehe ich
Gegenstände, wie ich diese zusammenbaue, kann sie in ihrer Gestalt sehen und so weiter.
Wenn ich aber programmiere ist das einzige was ich sehe ersteinmal der Programmcode.
Ich kann mir, was im Computer wirklich passiert, aber vielleicht am ehesten nur so vorstellen,
wie ein Hex-Editor eine Datei darstellt, also ein Feld von Zahlen. Das wird wohl auch der Grund
sein, warum ich mir so gerne Dateiformate ausdenke, denn Dateien sind für mich "begreifbar",
ich kann sie in verschiedensten Formen darstellen lassen und so auch nicht-abstrakt betrachten.


Zu der Sound-Qualität deines Synths: Es wäre wirklich kein Problem, wenn das rauscht und sonstwas,
ich habe zwar ein sehr geschultes Gehör sowohl musikalisch als auch klangtechnisch, aber ich
habe auch kein Problem mit niedriger Klangqualität. Ich bin mit dem Soundblaster Pro aufgewachsen
mit 8 Bit und niedrigen Samplerates, und CD Qualität hat sich mir erst ca. 5 Jahre später erschlossen.
Mein eigenes Trackerformat bzw. der Player und so wie die Module gestaltet werden müssen um nicht
zu viel Speicher zu belegen, das wird auch sehr bescheiden klingen, aber Hauptsache es ist unterhaltend.
Nebenbei... Ich bin nicht nur mit dem Soundblaster Pro aufgewachsen sondern längere Zeit davor
auch nur mit dem PC-Speaker, und überhaupt dann irgendwann einmal etwas anderes als nur
Rechteck-Piepsen über diesen Speaker zu hören war sehr beeindruckend und faszinierend.

Deine Spiele-Engine würde ich nutzen, wenn ich wirklich in erster Linie bzw. nur künstlerisch kreativ
tätig werden wollte. Ich denke, deine Routinen sind auch sehr gut programmiert und in ihrem Konzept
sinnvoller als das was ich mache. Für mich besteht aber, s.o., der Reiz nicht zuletzt darin, selbst
an Datenstrukturen und Formaten zu tüfteln und diese dann zu verwenden. Allein aus diesem Gefühl
heraus programmiere ich ja überhaupt und auch für den Real Mode. Sonst würde ich mir ja einfach
direkt einen Game-Maker der neuesten Windows-Generation hernehmen, der dank heutiger Rechnerleistung
letztlich potenter ist, als alles was ich selbst für den Real Mode programmieren könnte. Oder aber,
würden wir die Zeit mal 20 Jahre zurückschrauben, dann hätte ich diese Routinen gerne verwendet, weil
es mir genügt hätte, mich beim Programmieren auf die Gameplay-spezifischen Routinen zu beschränken,
und ansonsten auf das Künstlerische.
Generell kann ich aber auch wohl nichts programmieren, was du nicht genauso oder besser hinkriegen würdest.
Der einzige Sinn für mich zu programmieren ist die Motivation, dass ich Sachen programmiere, auf die du keine
Lust hättest oder sie nicht als sinnvoll ansehen würdest.
Ich glaube ich brauche eigentlich nicht zu sagen, dass ich gerne als Musiker oder überhaupt Sound-Designer
an einem Spiel mitwirken würde. Lediglich habe ich die letzten Jahre über die Erfahrung gemacht,
dass Musiker für ein Spiel höchstens an aller letzter Stelle gesucht werden.


Meine Denkweise für meine "Spiel Engine" kommt wohl daher, dass ich meine bisherigen Spiele immer
eher durch Datenfelder-Definitionen realisiert habe. Ich wünsche mir einfach, dass man ein Spiel
definieren könnte so wie in einer CONFIG einer Anwendung. Da werde ich einfach mal sehen ob das
geht, einen Versuch ist es mir wert.

zatzen hat geschrieben:Was Informatik in der Schule angeht, das hatte ich dort ein Jahr. Das war das Sprungbrett zu Pascal,
ich hatte schon vorher Pascal gesehen, es hatte mir aber nicht zugesagt. Ich hatte ein Buch, wie man
darin Spiele programmiert, darin war aber nur beschrieben wie man den PC-Speaker benutzt und
wie man Grafik mit den Pascal eigenen Zeichenroutinen macht. Und solche Strichgrafik find ich einfach
öde. Ähnlich ist es ja bei 3D, diese "Luftmatratzen"...

Pascal wurde von Niklaus Wirth ja als Lehr- und Lernsprache konzipiert - daher macht es wohl auch Sinn, daß sie damals im "Informatik"-Unterricht an Schule die Programmiersprache der Wahl eingesetzt wurde.
Heutzutage, da Borland seine Version des Pascalcompilers seit 1993 nicht mehr weiterentwickelt hat - und die "Nachfolger" Pascals nicht so kompatibel sind, wie es schön wäre... Fristet Pascal ein Nischendasein - und das eigentlich unverdienterweise, wie ich finde.

zatzen hat geschrieben:Ein wenig später hatte ein Lehrer mal gestaunt, was ich mit eher hardwarenaher Programmierung zustande brachte (einlesen eines undokumentierten Grafikformates etc.), aber solche typischen Informatik-Dinge wie "Türme von Hanoi" hab ich nicht gerafft.

Naja, mein "Informatiklehrer" hatte ja nicht wirklich viel drauf. Er konnte nichts dafür. Er wurde quasi im
Blitzverfahren auf "Informatik" umgeschult und daher konnte er nur gerade das, was im Lehrplan gerade als nächstes dran war.
Aber "Türme von Hanoi" finde ich jetzt nicht wirklich so eine Herausforderung...

zatzen hat geschrieben:Ich habe auch ein paar auf der Strecke gebliebenen Spiele. Das liegt aber einfach daran, dass ich Hals über Kopf daran gegangen bin. Da habe ich mir gedacht, mache ich schonmal ein paar Grafiken damit ich die beim Programmieren verwenden kann...

Wenn es bei mir nur "ein paar" wären, fände ich es nicht so schlimm. Ich habe abartig viele angefangene Projekte hier herumliegen. Und sehr viele Ideen in meinem Kopf. Ich komme auch einfach zu gar nichts mehr...

zatzen hat geschrieben:Aber das Programmieren selbst war dann wieder so eine große Hürde... Ich habe jetzt ein gutes Gefühl damit wenn ich erstmal alle benötigten "Engine"-Teile fertigstelle.

Bei mir ist es eher die Zeit. Ich habe kaum noch die Zeit und Kraft.... Und bin auch oft sehr müde.
Naja, das macht eben dieser Job mit einem...

zatzen hat geschrieben:Grafiken habe ich vor allem früher in Deluxe Paint II gemacht. Was erzeugbare Farbverläufe angeht ist es bis heute noch sehr attraktiv, und auch weil es Kreise mit der richtigen Aspect Ratio für 320x200 macht.

Ach, richtige Kreisratio ist ja kein Hexenwerk...
Aber Farbverläufe sind mir ehrlich gesagt ein Greuel. Es sieht dann immer so nach "im Malprogramm gefüllt" aus und da mag ich mehr diese handgepixelten Sachen. Ja, das dauert länger und macht mehr Mühe. Aber es sieht auch besser und "lebendiger" aus, wenn nicht alles total "geometrisch perfekt konstruiert" aussieht. So "Cliparts"-artige Grafik würde ich meinen Spielen nicht antun...
Ich benutze für meine Grafiken auf PC seit jeher ein selbstprogrammiertes Malprogramm - und andere, ebenfalls selbstprogrammierte "Werkzeuge" (Tools).

zatzen hat geschrieben:Ich habe nebenbei gedacht, meinen Grafik-Converter werde ich für PCX als Quelldateien auslegen, die sind, weil sie nicht so viel Headerzeugs und sowas haben, trotz der Lauflängenkomprimierung einfacher als BMP zu handhaben. Aber, und das auch weil ich es mir mit heutiger Massenspeicherplatztechnologie leisten kann, denke ich, werde ich das so machen dass ich jede Grafik, auch einzelne Bewegungsphasen, jeweils als ein PCX speichere, und nicht mehrere Sprite-Phasen auf ein Bild.

Ich mag PCX ebenfalls. Die Lauflängencodierung ist ja ein Kinderspiel. (Außerdem habe ich in meiner File-Unit auch Leseroutinen, die gleich "beim Lesen entpacken" und "beim Schreiben packen" können. Und wenn ich da "Modus 7" einstelle, entspricht das genau der Lauflängencodierung von PCX. Das heißt, beim Lesen sieht es so aus als würde eine "ungepackte Bitmap" gelesen. Beim Schreiben kann man das Bild so schreiben und es wird automatisch "PCX-gepackt". Es gibt dabei natürlich auch viele andere Pack- und/oder verschlüsselungs-Modi, die nach dem gleichen Prinzip arbeiten.)

zatzen hat geschrieben:Grundsätzlich würden mich aber deine ganzen Tools schon interessieren.

Naja, manche sind von der Bedienung her eher "sowas von: Die 80'er". Ich bin halt sehr altmodisch.
Und manche sind auch noch nicht so richtig fertig, werden aber trotzdem bereits benutzt.
Nicht alle meiner Tools haben "ein Netz und doppelten Boden" - also mitunter gibt es keine Sicherheitsabfragen usw. Ich programmiere eben manches eher "aus der Notwendigkeit heraus" - ein reiner "User" hätte mit manchen dieser Sachen sicher seine Probleme.
Manche meiner Tools kann man ja auf meiner Webseite finden. (http://www.imperial-games.de)

zatzen hat geschrieben:Das mit den Framerates hat mich jetzt ein bisschen erstaunt.

Wieso denn dieses?
Ich sage es mal so: PC's sind von vornherein "Flickwerk". Sie sind und waren schon immer auf dieser Basis konzipiert. Jeder baut ein anderes Motherboard, eine andere CPU, andere Grafikkarte, Soundkarte und sonstige interne und externe Peripherie an das Gerät. Es gibt verschiedene Generationen von CPUs, verschieden leistungsfähige Grafikkarten und auch verschieden gute "Verträglichkeiten" der einzelnen in einen PC eingebauten Komponenten. Auch die Einstellungen im BIOS haben einen nicht unwesentlichen Anteil an Performance - aber eben auch der "Unterschiedlichkeit" von PCs.
Es gibt wahrscheinlich auf der Welt keine zwei PCs, die wirklich absolut identisch sind und absolut "synchron" laufen - nicht einmal dann, wenn quasi die gleiche Hardware eingebaut ist.
(Dann können ja z.B. immer noch deren Festplatte unterschiedlich stark fragmentiert sein usw.)

zatzen hat geschrieben:Und manchmal denke ich auch, so eine saubere Framerate wie bei Konsolenspielen ist beneidenswert. Aber ähnlich wie bei einem C64 fühle ich mich eher wohl, wenn ich eine bestimmte Entwicklungsphase des PC als monolithisch ansehe und da schon, wenigstens erstmal für mich selbst, eine Mindestleistung voraussetzen kann.

Das ist meiner persönlichen Meinung nach für Programmierung (und Spieleentwicklung) auf PC der komplett falsche Ansatz. Ansichten und Methoden wie diese sind ja auch - leider - der Hauptgrund für die Existenz dieser vielen ganzen schlimmen, nichtperformanten Software, die es so gibt - und von der es leider immer mehr gibt, da als Rechtfertigung die Existenz schneller Rechner als gültig angesehen wird.

Die Systemvoraussetzungen, die heutzutage manchmal an einen Rechner für simple 2D-Spiele gestellt werden, klingen schon wie der Witz des Jahrhunderts - Dinge, die auf einem C64 flüssig laufen würden (und auch nicht anders aussehen würden!), brauchen auf PCs dann manchmal - dank Skripterei und mehr Abstraktionsschichten als eine Zwiebel - Leistungen, die eigentlich denen von Codeknacker-Maschinen entsprechen. Diese ausufernde Verschwendung von Rechenpower, die einen PC zur Heizung werden läßt und den Akku jedes Notebooks/Laptop binnen kürzester Zeit aussaugt, widerspricht all meinen Prinzipien...

Aber gut - wie bereits oben erwähnt: Meine persönliche Meinung...

zatzen hat geschrieben:Es ist für mich gerade einfacher. Ich habe keine Erfahrung mit Timer umbiegen, habe auch früher in meinen QBASIC programmen einfach SOUND 0, 1 oder sowas benutzt um Verzögerungen
einzubauen, oder ausgemessene Warteschleifen, was die schlechteste Lösung war.

Ach, zum "Timer umbiegen" braucht man keine Erfahrung - sondern einfach bloß die paar popeligen Befehle zu kennen, die das machen...
Ich baue so etwas ja dann immer in Units ein. Und in meiner IGBIOS Unit ist da ein Befehl drin, der das so macht:
InstallTimer(x,y,z);
wobei x ein Pointer auf eine Routine ist, die dann zusätzlich vom Timer ausgeführt werden soll, y die Tickerrate ist (da muß man dann aber 1193180 div Rate eingeben. Oder 0, wenn man die normalen 18.2064.... behalten will. Und z ist der Modus. (1=an, 0=aus, wobei "aus" dann alles wieder "ausklinkt" aus dem Ticker).
Zusätzlich wird aber der normale Ticker weiter mit der normalen Frequenz aufgerufen, d.h. die Uhr geht z.B. weiterhin so wie sie soll.

zatzen hat geschrieben:Würde ich es mit dem Timer lösen, ist mir noch ein Rätsel, wie ich dann noch den Ton Synchron mache. Ich habe es bei anderen Spielen erlebt, dass der Sound hinterherhinkt.

Bei SPIELEN ist es total WURST, wie "synchron" die Musik ist. Die Musik begleitet das Spielgeschehen (nicht umgekehrt). Und ob dann ein gewisser Zeitversatz drin ist, da kann ich ehrlich gesagt wirklich sowas von GAR KEIN Problem drin sehen...

zatzen hat geschrieben:Irgendwie stört mich das schon. Beispielsweise bei einem Flipper, man bewegt einen,
und es macht "tack" wenn der schon längst wieder ruhig liegt.

Bei Soundeffekten ist es noch etwas anderes. ABER: Soundkarten (wie die SB), die ihre Musik/Sound per DMA aus dem Speicher (Soundpuffer) holen, haben IMMER und IMMER und IMMER einen Zeitversatz - egal wie kurz der ist. Punkt. Er ist umso kürzer, je kürzer man den Soundpuffer macht. ABER: Das kostet Rechenpower zu Lasten des restlichen Programms. Und wenn man das nicht wirklich sauber hinkriegt, hat man dann in der Frequenz der Länge des Puffers ein intervallmäßiges "Knacken" im Sound - und DAS klingt ja vielleicht erstmal Schei... (der Normalbürger wird natürlich mit - mindestens - double buffering arbeiten, davon gehe ich jetzt intelligenterweise einfach mal aus).

Und: Einen Soundeffekt kann man natürlich erst erzeugen, wenn man weiß, daß er gewünscht ist. Das bedeutet im Klartext: (Pazifisten mögen das Beispiel verzeihen und sich ihren Kommentar schenken) Wenn die Spielfigur auf etwas schießt und das dann explodiert, kann der Explosionseffekt natürlich erst in den "Soundstream" gemixt werden, wenn das Signal "jetzt explodieren" da ist. Und da man nicht direkt in den Puffer reingrätschen kann, den die Soundkarte gerade abspielt (ehrlich: Das ist wirklich eine Scheißidee...) wird man es natürlich in den "anderen" (wie gesagt: Double Buffer) reinmixen. Und selbstverständlich entsteht dabei ein Zeitversatz.

Wie komme ich dazu, zu behaupten, daß kleine/kurze Sound(ring-)buffer mehr Rechenzeit brauchen als große (lange) ?
Ganz einfach: Das "Füllen" das Puffers ist für den Mixer zwar in beiden Fällen die gleiche Arbeit. Aber der Mixer, der ja eine Subroutine ist, muß immer beim Aufrufen bestimmte Werte initialisieren, aus "internen Stacks" holen etc und am Ende den Puffer "bereinigen"/"glätten" (kommt drauf an, wie programmiert) und dann natürlich die Werte wieder retten. Dieses "INIT" und "EXIT" von Routinen kommt eben zusätzlich dazu und wird öfter ausgeführt.

Einfache Erklärung aus der "richtigen Welt": Ich habe mal als Drucker gearbeitet. Wenn ein Kunde 100 Visitenkarten oder 1000 Visitenkarten haben wollte, machte dies vom Preis und Produktionsdauer kaum einen Unterschied. Wieso? Die "fixen" Prozesse sind dieselben und dauern für 100 oder 1000 Karten genauso lange: Erstellen des Layouts, Belichten und Entwickeln der Filme und der Druckplatten, Einrichten der Maschine (Farbabgleich, Testdrucke usw.). Da die Karten nicht einzeln, sondern zu mehreren pro Bogen gedruckt werden, sind es selbst auf einer kleinen Maschine für 100 Karten vielleicht 10 Drucke, für 1000 Karten 100 Drucke. Der Druckprozeß dauert also in beiden Fällen unter eine Minute...
Das Schneiden am Ende ist auch nicht ganz so schlimm, weil die nicht einzeln geschnitten werden. Und man kann auch 100 Bogen gleichzeitig schneiden...

Das heißt für die Spieleprogrammierung:
Um einigermaßen performant zu arbeiten, werden die einzelnen Prozesse voneinander getrennt behandelt. Die Steuerung, die Grafikdarstellung, Sounddatengeneration sind einzelne Subroutinen. Die Soundkarte spielt ja "nebenher" ("außenherum") die Daten aus dem Soundpuffer ab - unbeeinflußt von den restlichen Prozessen. Und der Timer ist ja ein Hardware-Interrupt. Man kann die Steuerdaten des Spielers im Interrupt einlesen, um sie wirklich mit der "Spielfrequenz" einzulesen - und sie dann in einen Ringpuffer für die Steuerroutine zu hinterlassen. Im Idealfall enthält der Ringpuffer pro "Schleife" eben nur EIN "Spieldatum" pro Spieler. Aber bei geringerer Framerate der Grafikdarstellung wäre die Spielgeschwindigkeit selbst eben immer noch die gleiche. (Man muß ja in diesem Fall nicht immer von Extremen wie 5 fps ausgehen. Aber wenn ein Spiel auf einem 386er dann eben nicht 50 fps, sondern nur 40 oder 35 fps schafft, ist es ja trotzdem noch problemlos spielbar. "Nicht ganz softes Scrolling" ist meiner Meinung nach immer noch besser als "läuft gar nicht, weil Rechner zu langsam und Programmierer keine Lust auf Timing".)

Ws die "Synchronisierung" angeht: Man teilt ja der Soundkarte mit, mit welcher Frequenz sie den Puffer abspielen soll. Und aus Länge des Puffers und Frequenz kann man ja ermitteln, wie oft ein "Wechsel" erfolgt und den Rest (Timer etc) darauf abstimmen, wenn man will. Außerdem wirft die SB ja bei Puffer-Ende einen IRQ, den man auswerten kann.
Ja, ich weiß: Der Ticker wird dann auf eine "geringfügig krumme" Frequenz gesetzt, aber das kann man auch programmiererisch ausgleichen.

zatzen hat geschrieben:Meine Engine realisiere ich ersteinmal so.

Das bleibt Dir ja trotzdem unbenommen.

zatzen hat geschrieben:Die Performance langsamer Rechner ausser acht gelassen, ist es eigentlich sogar richtiger, wenn man den Sound als Timer nimmt.

Nein - es ist total falsch, den Sound, die Grafik oder sonstige AUSGABE-Dinge als Timer zu benutzen! Die Ausgabe und die "interne Berechnung/Steuerung" gehören total unabhängig. Kann ich einfach nicht anders finden. Eben aus obengenannten Gründen: PC = Stückwerk/Bastelkiste/Frankensteinmonster...
Außerdem: Genau DAS ist es ja, was modulare Programmierung letztendlich ausmacht. Und: Man hat dadurch die Möglichkeit, auch (später) andere Hardware zu unterstützen.
Und ja: Meine Spiele werden außer Soundblaster auch noch den PC-Speaker (!) als Ausgabeeinheit supporten. Und wie dieses?
Er spielt den Soundpuffer dann mit einer wählbaren Frequenz ab. Ja, da hat der Ticker dann 2 Funktionen: z.B. Speaker mit 14000 Hz abspielen und das Spiel z.B. mit 50 Hz (Ticks pro Sekunde halt). Wie das geht: Naja - Ticker auf 14000 Hz stellen. Jeder Tick spielt ein "Speaker-Frame" und jeder 280. Tick "zählt" einen Spiel-Tick... Und der Speaker würde dann ebenfalls nach Ende des Puffers ein Flag setzen, genau wie ich es im IRQ, den die Soundblaster auslöst machen lassen würde.
So kann es dem "Hauptprogramm" schon wieder total egal sein, wer oder was da den Sound abspielt - oder OB ÜBERHAUPT Sound abgespielt wird. Manche Leute haben eben keine Soundblaster und wollen keinen Speakersound. UND: Supportet man später auch andere Karten, kann das einfach nachgepflegt werden.

So ist es auch mit der Steuerung: Entkoppelt man die Steuerhardware "vom "Spiel", sondern läßt sie einfach generalisierte Signale (z.B. als Bitmuster) auf einen Ringpuffer tun, kann man auch später Steuerung durch Joystick, Maus oderwasauchimmer nachträglich einbauen, ohne das ganze Programm auseinandernehmen zu müssen. Und, wie ich vielleicht schonmal erwähnte: So ist es auch einfach möglich, so "Spiel-Demos" aufzunehmen und abzuspielen...

zatzen hat geschrieben:So als wäre es ein spielbares Video. Bei einem Video, mit Sprache vor allem, stört es enorm, wenn Bild und Ton auch nur ein oder zwei Frames auseinandergehen, d.h. schon ab etwa 50 ms Versatz. Videos sind oft so verschachtelt, dass Bild- und Tondaten jeweils Bildweise hintereinander kommen.

Hmm.... Will man so etwas tun, ist aber die gewählte Plattform (PC, 16bit, DOS....) wahrscheinlich eventuell nicht die ganz perfekte Wahl...

Ich selbst habe ja eher vor, Spiele zu machen, die man "richtig spielen" kann. Zwischensequenzen usw sind für mich eher "schmückendes Beiwerk" - kann man hinterher auch noch einfügen, wenn das Spiel selbst funktioniert. Und bei dem einen Spiel habe ich so etwas definitiv auch vor. Aber es wird dann trotzdem eher "auf Sprites basierend" funktionieren und der Sound dazu auch nicht ein komplettes Soundfile, das im Hintergrund läuft - sondern auch bestehend aus Musik/Effekten, genau wie im Spiel.
<b>SPRACHAUSGABE</b> - an solche Dinge denke ich erst einmal gar nicht. (Vielleicht höchstens so einzelne Sprüche/Wörter ... wie bei Street Fighter II [tm] - aber keine Konversation.)
Es liegt nicht daran, daß ich Sprachausgabe nicht mögen würde. Aber:
1.) Sprachausgabe - selbst wenn sie wenigstens einigermaßen vernünftig klingen soll - ist ein totaler Speicherfresser. Ich will nicht ein ganzes Spiel den Befindlichkeiten einer eventuell verfügbaren Sprachausgabe unterordnen. (Außerdem braucht die Art Spiele, die ich so machen will, eher kaum Sprachausgabe).
2.) Man braucht viele (zumindest einige) Leute, die das alles dann sprechen - damit das nicht alles klingt wie man selbst mit verstellter Stimme. Das klänge wirklich nicht gut und wäre nur unfreiwillig komisch/albern.
- Aber auch das muß natürlich jeder selbst wissen. -
Bei Adventures wäre es natürlich etwas anderes. Aber Adventures sind eine ganz andere Kategorie - die würde ich anders angehen als die Sachen, die ich momentan mache. (Aber trotzdem bräuchte man auch da für Sprachausgabe Leute, die das können. Und wollen. Und Zeit haben. Und ja, ich weiß, wovon ich rede: Es gibt unheimlich viele Leute, die "mal Lust hätten an so einem Spiel mitzumachen" - aber die, wenn es "ernst wird", dann "leider gerade keine Zeit" und "leider gerade etwas vor" haben... - es ist, gerade in der "privaten" Spieleentwicklung - unheimlich schwer, Leute zu finden, auf die man sich - auch längerfristig - mal verlassen kann. Das klingt böse. Aber ich rede (leider) aus Erfahrung... Und andere Leute können das (leider) ebenfalls bestätigen.

zatzen hat geschrieben:Da es eine Engine ist, die nicht mit den erzeugten Spielen "zusammenklebt", kann
ich mit mehr Weisheit später alles noch so umprogrammieren, dass es auch auf 386ern mit ner Framerate von 8 oder so spielbar ist.

Naja, dann kann man nur hoffen, daß sich das ganze Programm sich nicht dermaßen "darauf verläßt" und alles so "um den Sound herum" programmiert ist, daß man das Ganze am Ende nicht mehr "voneinander trennen" kann (oder es dermaßen in Arbeit ausarten würde, daß es einfacher wäre, das komplette Spiel noch einmal komplett neu zu programmieren.

zatzen hat geschrieben:Eine Kompromisslösung wäre noch, die Performance vorher auszumessen und die Framerate auf einen entsprechend niedrigeren Wert festzulegen. Ich habe nämlich auch eine Aversion gegen ständig wechselnde Framerates,

Naja, wie schon erwähnt: Dann ist der PC vielleicht die falsche Wahl als Plattform. Selbst DOS mit seiner "Single-Task-Mentalität" kann schon nichts gehen die ganzen semi-standardisierten Teile tun, aus denen so ein PC zusammengebacken wird.

Und sollte man es eventuell gar auf Multitasking-Plattformen/-Systeme abgesehen haben: Da kann man so totale Synchronität von IRGENDWAS ZU IRGENDWAS quasi komplett vergessen - da das darunterliegende OS ja die Zeitscheiben und Ressourcen verteilt und man alles so anlegen muß, daß ein Programm mit "egal, was es kriegt" zurechtkommen muß.

zatzen hat geschrieben:bei Sierra Games der 90er sieht man das oft, dass Animationen mit den unterschiedlichsten Framerates laufen, das sieht irgendwie "unecht" aus, gefällt mir nicht.

Naja, das ist und war eben der Tatsache geschuldet, daß nicht jeder zu Hause den absoluten High-End-PC mit der absoluten High-End-Grafikkarte hatte. Und damals[tm] hatten die Programmierer noch genügend Ehre im Leib, um nicht zu jedem neuen Spiel auch gleich einen neuen Computer mitkaufen mußte.

zatzen hat geschrieben:So hat jeder seinen Geschmack.

Hm. Dein Geschmack entspricht da aber nicht wirklich einem typischen "DOS-PC User" / "DOS-PC Programmierer". Meiner unmaßgeblichen Meinung nach.

zatzen hat geschrieben:Ich finde es reizvoll, wenn ein Spiel einen Hauch von "das ist ein interaktiver Film" hat.

Hm - genau das hat mich an (späteren) Spielen eigentlich immer am meisten angekotzt - weshalb ich Dinge wie "Cyberia" auch verabscheut habe: Zuviel "Film" und viel zu wenig "selbst Spielen". (Und das "selbst spielen" waren nur so primitive Zwischen-Spiele, damit es immer noch in vorgefertigten Filmsequenzen abgespielt werden konnte...
Boah, war das gruselig... Damit konnte ich irgendwie nie wirklich etwas anfangen. Nach kurzer Zeit setzte da bei mir extreme Langeweile ein. Tolle Grafik und Sound alleine retten eben leider kein besch.... Spielprinzip.

Hm. Mir ist gerade aufgefallen, daß ich heute etwas kritisch klinge... Naja. Es ist eben meine Meinung. Und Foren dienen ja dem Meinungsaustausch. Hätten alle die gleiche Meinung, gäbe es ja nichts zum Tauschen...

zatzen hat geschrieben:Dieses Doppel-Denken ist vielmehr so zu verstehen, dass ich mehr oder weniger Probleme habe, etwas abstrahiert nachzuvollziehen.

Ja, ich hab das ja auch eigentlich nur als Scherz gemeint - wahrscheinlich war die Pointe auch zu undeutlich.
Ich habe natürlich verstanden, was Du ursprünglich damit meintest. Ich bin halt nur ein Fan von Wortspielen usw...

zatzen hat geschrieben:Wenn ich in der realen Welt etwas bastle, dann sehe ich Gegenstände, wie ich diese zusammenbaue, kann sie in ihrer Gestalt sehen und so weiter.
Wenn ich aber programmiere ist das einzige was ich sehe ersteinmal der Programmcode.
Ich kann mir, was im Computer wirklich passiert, aber vielleicht am ehesten nur so vorstellen, wie ein Hex-Editor eine Datei darstellt, also ein Feld von Zahlen. Das wird wohl auch der Grund sein, warum ich mir so gerne Dateiformate ausdenke, denn Dateien sind für mich begreifbar, ich kann sie in verschiedensten Formen darstellen lassen und so auch nicht-abstrakt betrachten.

Naja, prinzipiell sind ALLES in einem Computer Daten. Ein Programm besteht auch nur aus Zahlen, die eine CPU in (mehr oder weniger sinnvolle) Aktionen umsetzen kann. (Man kann die auch genausogut als Bild anzeigen oder als Sound abspielen. Sieht aber meist als Bild eher nach Rauschen aus - und hört sich als Sound wohl auch so an...)
Wenn ich in Assembler programmiere, habe ich das schon im Kopf, was die CPU dann so in den Registern damit anstellt... Und ich sehe schon quasi die Bits der Zahlenwerte, die ich benutze. Ich programmiere schon in Pascal manchmal etwas neben dem Standard - in Assembler neige ich oft dazu, total um die Ecke zu programmieren. Ich habe da schon manchmal derart abstrakte Ideen gehabt... Aber wenn es funktioniert - und vielleicht sogar schneller/besser als der reguläre Weg, ist das für mich in Ordnung.

zatzen hat geschrieben:Zu der Sound-Qualität deines Synths Es wäre wirklich kein Problem, wenn das rauscht und sonstwas, ich habe zwar ein sehr geschultes Gehör sowohl musikalisch als auch klangtechnisch, aber ich habe auch kein Problem mit niedriger Klangqualität.

Behalte diesen Gedanken mal im Hinterkopf, wenn Du erst hörst, was mein Kram da so produziert...

zatzen hat geschrieben:Ich bin mit dem Soundblaster Pro aufgewachsen mit 8 Bit und niedrigen Samplerates, und CD Qualität hat sich mir erst ca. 5 Jahre später erschlossen.

8 Bit ist für mich quasi schon hohe Qualität... 16 Bit Sound ist wohl etwas, das ich nie selber (programmtechnisch) benutzen werde. Und stereo ist zwar in der Soundengine schon irgendwie angedacht. Aber erst einmal wird das mono natürlich vernünftig umgesetzt. Die Engine ist aber schon so angelegt, daß ich daraus eine zweite Engine machen kann, die Stereo-Option hat. Es hat für mich erst einmal nicht so hohe Priorität.

zatzen hat geschrieben:Mein eigenes Trackerformat bzw. der Player und so wie die Module gestaltet werden müssen um nicht zu viel Speicher zu belegen, das wird auch sehr bescheiden klingen, aber Hauptsache es ist unterhaltend.

Sehe ich genauso. Mal sehen, wie Du darüber denkst es findest, wenn Du erfährst, daß die Samples, die das Teil (meine Soundengine) benutzen kann/wird, 4 Bit sind...

zatzen hat geschrieben:Nebenbei... Ich bin nicht nur mit dem Soundblaster Pro aufgewachsen sondern längere Zeit davor auch nur mit dem PC-Speaker, und überhaupt dann irgendwann einmal etwas anderes als nur
Rechteck-Piepsen über diesen Speaker zu hören war sehr beeindruckend und faszinierend.

Ja, mit Speaker habe ich anfangs auch nur Piepsen gemacht. Mittlerweile weiß ich auch, wie man mit dem Ding Digital-Sound machen kann. Klingt recht beeindruckend. Man sollte dafür eben einen nicht zu leisen Speaker haben. Ich selbst habe immer Wert darauf gelegt, einen lauten Speaker zu haben - weil ich gern damit rumspiele.

zatzen hat geschrieben:Deine Spiele-Engine würde ich nutzen, wenn ich wirklich in erster Linie bzw. nur künstlerisch kreativ tätig werden wollte. Ich denke, deine Routinen sind auch sehr gut programmiert und in ihrem Konzept sinnvoller als das was ich mache.

Naja, meine Spiele-Engine... Ich sage es mal so Es ist nicht wie ein Game-Maker oder so.
Die Spiele-Engine steuert nur die Figuren. DARGESTELLT werden müssen sie dann von einer anderen Subroutine (das gibt einem die Freiheit, nicht darauf angewiesen zu sein, sondern selbst zu wählen, womit und wie man die Figurendas Level darstellt). Im Prinzip ALLES KANN - NICHTS MUß...

Das heißt Dieses GameSys2 ist quasi wie eine interne Koordinatenrechenmaschine oder so.
Die Programmiersprache, die es benutzt, hat mehr mit Assembler als mit Hochsprache zu tun.

Sie hat 128 Opcodes, pro Befehl 0 bis 4 Parameter (außer für die 2 Listen-Befehle) und die Parameter haben 30 verschiedene Adressierungsarten (Datengrößen-Angaben dabei noch nicht mitgerechnet).
Irgendwie plane ich aber (nur ich weiß nicht, ob und wann ich mal die Zeit dazu finde), dafür ein Hochsprachen-Frontend zu bauen - so daß quasi ein Compiler diese Hochsprache dann in meine GS2-Sprache da übersetzt (sie hat keinen eigenen Namen).

Und ja - ich weiß Das MAG ein wenig so klingen, als würde ich damit gegen meine eigenen Prinzipien verstoßen wollen - denn prinzipiell ist die GameSys2-Engine ja quasi ein Bytecode-Interpreter.
Aber Tests haben gezeigt, daß das verflixte Ding wahnsinnig schnell geworden ist.
Die große Stärke von GameSys2 ist die automatisce Spielfigurendatenverwaltung und natürlich auch die quasi-automatische Kollisionsabfrage und Möglichkeit der automatischen Reaktion darauf. Das spart eine ganze Menge doppelten und dreifachen Code ein, den man vielleicht in einem direkt als Programm geschriebenen Spiel machen würde, um das Ganze zu realisieren.

Und diese alles kann mit allem kollidieren Philisophie (die ich mit Hilfe meiner - quasi in Xpyderz schon patentierten - Kollisionsmatrix ermöglichen kann), gepaart mit der Möglichkeit, bis zu über 2000 freibewegliche Objekte darzustellensteuern, in Levels die größer werden können als... die von Turrican[tm] vielleicht... - sollten wohl ausreichen, um einigermaßen brauchbare 2D-Arcade-Spiele damit herzustellen.

Ich kommen unten noch einmal darauf (GameSys2, Arcade01) zurück.

zatzen hat geschrieben:Für mich besteht aber, s.o., der Reiz nicht zuletzt darin, selbst an Datenstrukturen und Formaten zu tüfteln und diese dann zu verwenden. Allein aus diesem Gefühl heraus programmiere ich ja überhaupt und auch für den Real Mode. Sonst würde ich mir ja einfach direkt einen Game-Maker der neuesten Windows-Generation hernehmen, der dank heutiger Rechnerleistung letztlich potenter ist, als alles was ich selbst für den Real Mode programmieren könnte.

Ja, mir geht es ja bei alledem auch vor allem um das ProgrammierenEntwickelnSelbermachen. Ginge es mir nur darum, quasi ohne Ansehen der Maschine so viele Spiele wie möglich in kürzester Zeit rauszuballern, da fände ich sicher den passenden GameMaker... Aber Das würde mir ja den ganzen Spaß an der Sache nehmen - weil ich mich selbst eben in erster Linie als Programmierer betrachte - und erst danach als Grafiker und ein bißchen Musiker.

zatzen hat geschrieben:Oder aber, würden wir die Zeit mal 20 Jahre zurückschrauben, dann hätte ich diese Routinen gerne verwendet, weil es mir genügt hätte, mich beim Programmieren auf die Gameplay-spezifischen Routinen zu beschränken, und ansonsten auf das Künstlerische.

Wenn ich das, was ich heute mache, vor 20-25 Jahren gemacht hätte (und zweifellos läuft Zeug, das ich heute mache, auf Rechnern von vor 25 Jahren!) und damals schon das Wissendie Kenntnissedie Fähigkeiten gehabt, die ich in dieser Hinsicht heute habe - ich wäre wohl (ohne zu übertreiben) DER TOTALE HELD gewesen... - aber es ist eben doch ein Unterschied, ob man auf Wissen und Erfahrung anderer Programmierer basierend sich Dinge aneignet (und mit eigenen Ideen weiterentwickelt), oder - wie die Leute vor 25 Jahren - sich wirklich alles mühsam selbst erarbeiten muß.

Ich meine Dinge wie z.B. der bekanntebeliebte Mode-X waren ja nicht einfach da - das sind durch Trial-And-Error oder Unfälle entdeckteentwickelte Modi, die sehr fähige Computerfreaks dann auch in Dokumentationen der Allgemeinheit zur Kenntnis gebracht haben... Das heißt Vor 25 Jahren war ich eben leider NICHT DER TOTALE HELD, sondern ein recht armseliger BASIC-Programmierer auf KC854 und C64...

zatzen hat geschrieben:Generell kann ich aber auch wohl nichts programmieren, was du nicht genauso oder besser hinkriegen würdest.

Ach, davon würde ich jetzt nicht so einfach von vornherein ausgehen. Du hast ja auch schon einige Dinge gemacht, die durchaus Respekt von Programmierer zu Programmierer verdienen.

zatzen hat geschrieben:Der einzige Sinn für mich zu programmieren ist die Motivation, dass ich Sachen programmiere, auf die du keine Lust hättest oder sie nicht als sinnvoll ansehen würdest.

Ach, was ist bei einem Hobby schon sinnvoll Solange es Spaß macht, hat ein Hobby seinen Sinn doch schon bereits vollständig erfüllt - kommt dabei noch etwas heraus, das auch andere Leute mögengut findenhaben oder benutzen wollen, dann ist der Sinn ja quasi bereits übererfüllt!

Wie es im Buddhismus unter anderem gesagt wird Der Weg ist das Ziel.
Ist die Programmierung an sich schon das, was einem Spaß macht - UND verbringt man seine Freizeit damit, zu programmieren, dann ist das Ziel ja bereits erreicht und wird ständig immer wieder erreicht. Seine Ziele zu übertreffen - das ist der zusätzliche Bonus, der einem dann noch ab und zu geschenkt wird.
Und das unterscheidet uns und ein Hobby wie unseres auch von Leuten, deren Hobby Fußball gucken und dabei Bier trinken ist. Denn es macht ihnen zwar möglicherweise auch Spaß - aber es wird niemals mehr daraus werden, als das, was es schon ist.

zatzen hat geschrieben:Ich glaube ich brauche eigentlich nicht zu sagen, dass ich gerne als Musiker oder überhaupt Sound-Designer an einem Spiel mitwirken würde. Lediglich habe ich die letzten Jahre über die Erfahrung gemacht, dass Musiker für ein Spiel höchstens an aller letzter Stelle gesucht werden.

Davon würde ich nicht ausgehen! - Eher im Gegenteil
Talentierte Leute - die auch noch Zeit und Lust in die Ausübung und Nutzung ihres Talents investieren wollen, denen es Spaß macht, was sie tun und die es aus dem Grund tun, etwas gutes oder großartiges abzuliefern oder beizutragen, ohne dabei daran zu denken, was sie dafür bekommen - weil das, was sie bekommen, der Spaß und die Herausforderung ist, mit etwas, das sie können und mögen, etwas zu schaffen, das auch andere mögen... - solche Leute kann es gar nicht genug geben! Und es gibt leider viel zu wenige davon.

Vielen Spielen, die an sich eine gute Idee hatten, hätte es gut getan, wenn sich ein fähiger Grafiker und Musiker ihrer angenommen hätte, um eine gute Spielidee mit gutem Aussehen und tollem Klang zu einem großartigen Gesamtkunstwerk zu machen!

Und es ist eben NICHT so, daß jeder, der gut programmiert und sich daher mit Computern beschäftigt, auch gleichzeitig aus einem Computer gute Klänge und gute Bilder herausholen kann. Man KANN ein guter Coder UND Grafiker UND Musiker sein - ABER Bestenfalls sind die Leute höchstens zweierlei davon, meistens aber - wenn überhaupt - ist es nur eine der Fähigkeiten.

zatzen hat geschrieben:Meine Denkweise für meine Spiel Engine kommt wohl daher, dass ich meine bisherigen Spiele immer eher durch Datenfelder-Definitionen realisiert habe. Ich wünsche mir einfach, dass man ein Spiel definieren könnte so wie in einer CONFIG einer Anwendung. Da werde ich einfach mal sehen ob das
geht, einen Versuch ist es mir wert.

Und an dieser Stelle komme ich nochmals auf mein GameSys2 und Arcade01 (und TheGame3) zurück
Meine derzeitige Herangehensweise an die Spieleprogrammierung scheinen in der Tat genau das abzubilden, was dieser Denkweise entspricht

Man baut ein Level, in das man praktisch nur die Startpunkte für Spielfiguren einsetzt, d.h. dort laufen die Figuren los. Die Steuerung (Bewegungen und Reaktionen der Figuren aufeinander, auf das Level und auf die Spielerfigur) wird nicht im Programm selbst programmiert, sondern liegt als ausführbarer Bytecode vor, der von GameSys2 ausgeführt wird. Setzt man also z.B. eine Figur z.B. mit Typ 42 (nur ein Beispiel) irgendwo hin, weiß GameSys2, daß hier das Programm für Figurentyp 42 gestartet wird und die Figur verhält sich, bezugnehmend auf ihre Umgebung (und im Rahmen ihrer Programmierung) wie Typ 42-Figuren sich eben verhalten.

Ich erkläre das mal an einem Beispiel
Nehmen wir an, man hätte 2 Typen Schildkröten - wie bei Super Mario World. (Ja, ich weiß, es gibt mehr...) dies sind Typ 1 (grüner Panzer) und Typ 2 (roter Panzer).
Beide haben ein Programm, das zunächst erst einmal dafür sorgt, daß sie in ihrer Laufrichtung geradeaus laufen (nach links oder rechts) und nach jedem Schritt prüfen, ob beim nächsten Schritt unter ihnen noch begehbares Level (also eine Plattform o.ä.) sein wird.
Ist dies nicht mehr der Fall, wird Typ 1 am Ende der Plattform zu einer Subroutine, die einen Sprung ausführt - d.h. die Figur springt von der Plattform herunter - und fällt so lange, bis wieder fester Boden unter der Figur ist (Plattform, Boden,...)-
Sollte es bei Typ 2 passieren, dann ist das Programm leicht anders Die Figur ändert ihre Richtung und läuft in die entgegengesetzte Richtung. So läuft sie auf einer Plattform hin und hier.

Es sind simple Bewegungen, die speziell für Koordinatenänderungen und Figurenumgebung prüfen vorgesehenen Befehle helfen dabei, das Ganze so simpel wie möglich zu encodieren - so daß einfache Bewegungen und Abfragen nicht zu komplizierten und endlosen Abfrage-Kaskaden werden müssen.

Figur-Figur-Kollision kann dabei einseitig ausgeführt werden, d.h. es ist nicht erforderlich, die Kollision von Figur 8 mit Figur 2 zu prüfen, wenn vorher bereits die Kollision von Figur 2 mit Figur 8 geprüft wurde. (Die Gründe sind offensichtlich.)

(Die Stärke der Kollisionsmatrix ist, daß Figuren außerhalb jedweder Reichweite gar nicht erst zu einer Kollisionsprüfung herangezogen werden. Dies spart viel Rechenzeit. Da diese quasi im Hintergrund und automatisch arbeitet, braucht man sich über deren Funktionsweise auch keine Gedanken zu machen. Ob und wie groß man sie dimensionieren will, hängt allein vom Spieleprogrammierer ab.

Auch das Level sind nur schlichte Daten. Wie bereits oben erwähnt In einem Computer sind ALLES Daten. Die Interpretation von Computerdaten (die IMMER nur Bits und Bytes etc sind) erfolgt nie durch die Daten selbst, sondern immer nur durch die RoutinenProgramme, die diese benutzen oder darstellen. Ansonsten sind Daten nur Einsen und Nullen, bzw Bits und Bytes und Words usw..., die irgendwo in Speicherbereichen herumliegen.

Und je nachdem, welche Möglichkeiten so ein Spiel haben soll, wäre es auch möglich, einen Spiel-Interpreter zu bauen, der ein simples Config artiges File liest und daraus einen Spielablauf generiert.
Man sollte aber bedenken, daß hier dann natürlich noch Grafik und evtl Sound vonnöten sein müßten.
Und natürlich könnte so ein Spiel dann nur so komplex werden, wie der Spiel-Interpreter es zuließe. Und mir persönlich wäre das Ganze schon wieder die entscheidende Abstraktionsstufe zu viel.
Und wollte man wirklich ein herausforderndes und nicht-langweiliges Spiel bauen, so wäre ein simpels Config-Format mit einigen Befehlen dafür sicher zu wenig. Und wenn man kompliziertere Dinge damit tun wollte, würde das Format, die Grammatik und Syntax dieser CONFIG-Sprache möglicherweise schlußendlich so kompliziert, daß man auch gleich den direkten Weg über Spielfiguren-Programmierung in GameSys2 gehen könnte.

Das war vorläufig erst einmal mein Senf dazu - auch wenn wir uns damit inzwischen teilweise vom eigentlichen Thema dieses Threads entfernt haben.

Anmerkung: Jemand hat das Eingabefeld komplett verhunzt - und weil ich weiß, daß C-Programmierer sich von jeher LEIDER auf ihren TOLLEN printf Befehl u.ä. verlassen und auf das "ESCAPING" durch Zeichen, vermute ich, daß es ein solcher war:
Kopiert man hier etwas heraus, um es in einem externen Editor zu bearbeiten und kopiert es wieder zurück - oder umgekehrt - scheint das Ding Doppelpunkte, Anführungszeichen und Schrägstriche zu entfernen, so daß der ganze Text total verhunzt wird und es eine Höllenarbeit ist, das Ganze wieder in Ordnung zu bringen. Wenn es nicht zuviel ausmacht, wäre es schön, wenn jemand diesen Unsinn abstellen könnte...

DOSferatu hat geschrieben: Naja, prinzipiell sind ALLES in einem Computer Daten. Ein Programm besteht auch nur aus Zahlen, die eine CPU in (mehr oder weniger sinnvolle) Aktionen umsetzen kann. (Man kann die auch genausogut als Bild anzeigen oder als Sound abspielen. Sieht aber meist als Bild eher nach Rauschen aus - und hört sich als Sound wohl auch so an...)

Ja, das ist klar. Ich habe auch einmal das Experiment gemacht, eine Exe-Datei auf eine Audio-CD gebrannt,
dann im CD-Player über optisches Digitalkabel wieder in den Computer gespielt, zurechtgeschnitten, und das
Programm lief einwandfrei. Ja, es war ein kratziges Rauschen, und damit war aber auch gleichzeitg
der Beweis erbracht, dass eine CD wirklich 100% Klangtreu ist, wenn sie sogar Daten fehlerfrei wiedergibt.
Und ich rede hier nicht von CD-ROM, sondern vom Red Book Format, das übliche Audio-Format mit abgespeckter
Fehlerkorrektur. High-End-Leute behaupten immer wieder, sie könnten einen Unterschied hören je nachdem
was für Kabel man verwendet, und sie machen da auch keinen Halt wenn es um Digitalkabel geht...
Mal ganz davon abgesehen, wie schlecht sie die CD überhaupt machen und wieviel überlegener die Schallplatte
sei...
Vor Maschinencode habe ich nur etwas Respekt weil da ja wirklich alles 100% stimmen muss, und zudem kenne
ich die Opcodes als Zahlen nicht alle auswendig. Daher betrachte ich mir eher selten ein kompiliertes Programm
im Hexedit. Beim Assembler-Programmieren fällt es mir wohl aber auch leichter, nachzuvollziehen, was da gerade
passiert.

DOSferatu hat geschrieben:

zatzen hat geschrieben:Zu der Sound-Qualität deines Synths Es wäre wirklich kein Problem, wenn das rauscht und sonstwas, ich habe zwar ein sehr geschultes Gehör sowohl musikalisch als auch klangtechnisch, aber ich habe auch kein Problem mit niedriger Klangqualität.

Behalte diesen Gedanken mal im Hinterkopf, wenn Du erst hörst, was mein Kram da so produziert...

Ich habe keine Angst davor... Habe wirklich alles schon ausprobiert mit Soundbearbeitung und kann auch schon
abschätzen wie das klingen wird.

DOSferatu hat geschrieben: 8 Bit ist für mich quasi schon hohe Qualität...

Ist es auch bei guter Aussteuerung. Ich habe jahrelang mit dem Tracker Musik gemacht und hatte nur
8 Bit Samples, es klang trotzdem nach "CD". Die Spuren wurden allerdings dann auf 16 Bit zusammengemischt,
so dass sie jeweils keine weitere Reduktion erfuhren.

DOSferatu hat geschrieben:Mal sehen, wie Du darüber denkst es findest, wenn Du erfährst, daß die Samples, die das Teil (meine Soundengine) benutzen kann/wird, 4 Bit sind...

Vielleicht erhält es letztlich einen interessanten und lebendigen Charakter wenn diese 4 Bit nochmals runterskaliert
werden aufgrund Lautstärkebefehlen. Ich könnte dir nur vorab schon eines sagen, ich glaube du hast 16 Kanäle.
In der Praxis werden sich die Kanäle aber nicht ständig auf volle 8 Bit Aussteuerung aufaddieren, realistischer
wären 6-7 Bit, so dass du generell einen Faktor von 2 oder 4 einbauen könntest - bräuchtest dann aber noch
Clipping, falls doch ab und zu etwas "übeschwappt". So werde ich das bei mir machen.

DOSferatu hat geschrieben:Und das unterscheidet uns und ein Hobby wie unseres auch von Leuten, deren Hobby Fußball gucken und dabei Bier trinken ist. Denn es macht ihnen zwar möglicherweise auch Spaß - aber es wird niemals mehr daraus werden, als das, was es schon ist.

Ich merke auch, ich habe NUR produktive Hobbys. Gesellschaftlich hätte ich es leichter, wenn ich mich z.B.
für Fußball interessieren würde. Es ist ein bisschen etwas Einsames, wenn man in seiner Freizeit nur Dinge macht,
die sonst keiner nachvollziehen kann. Aber gut, man kann auch schonmal so "Ausflüge" machen mit Leuten.
Trotzdem wollte ich immer schonmal gern ein Team-Projekt machen. Ich habe nur, als Musiker beispielsweise,
ein Problem damit, auf Knopfdruck genau solche Musik zu komponieren, wie sie andere haben wollen. Das ist dann
auch eine Teilmotivation für ein Spiel von mir, weil ich dann alles selber machen und so gestalten kann, wie es mir
gerade in den Sinn kommt.

DOSferatu hat geschrieben:Vielen Spielen, die an sich eine gute Idee hatten, hätte es gut getan, wenn sich ein fähiger Grafiker und Musiker ihrer angenommen hätte, um eine gute Spielidee mit gutem Aussehen und tollem Klang zu einem großartigen Gesamtkunstwerk zu machen!

Und trotz dessen was ich oben gerade geschrieben habe, wäre ich doch froh, wenn ich mal als "Knopfdruck"-Musiker
eingesetzt werden könnte. Das würde mit etwas Disziplin schon gehen. Aber eben nur als Musiker, denn das ist,
was mir im Computerbereich am besten von der Hand geht. Ich kann programmieren, ich kann wenn es
sein muss, schöne Grafiken Pixeln, aber Musik geht eben am besten. Schade, dass es bisher nie möglich war an
einem Spiel zu arbeiten, und leider sind wohl auch die Trackermodul-Zeiten vorbei - Heute klatscht man die
Musik meist einfach als MP3 oder Wave rein. Könnte ich auch bewerkstelligen, aber mehr Spass hätte ich wenn
ich eine schöne kompakte Trackerdatei abliefern müsste. Okay und noch ein Punkt, ich bin nicht der beste
wenn's um Gameplay geht. Das liegt daran dass ich ein Genießer bin und im Zweifelsfall auch einen Film im Kino
eher wegen der Atmosphäre als wegen der Handlung gucke.

Den Rest habe ich auch gelesen, darauf werde ich dann wenns um die Engine geht auch nochmal zurückkommen.
Ich mache mich aber nicht mehr, so wie früher, verrückt, dass ich das ganze Spiel auf einmal komplett im Kopf
haben muss, sondern ich unterteile mir das in Abschnitte für die ich mir dann jeweils in Ruhe Zeit nehme.
Dass ich Spiel und Code voneinander trenne, und so ein Spiel nur ein Modul für die Engine ist, ist etwas neues
für mich, aber ich würde es auch nicht mehr anders wollen.