Ja, kann man machen. Ich mag z.B. auch diesen sogenannten "Orchesterschlag" und wenn er als "Instrument" eingesetzt wird.zatzen hat geschrieben:Noten:
Ich verwende(te, vor allem früher) gerne auch mal einfach einen kompletten Dur-Akkord als
Sample, mit dem ich dann auf verschiedenen Tonhöhen unterwegs war. Klingt auch nach Musik,
ist aber total gegen die Regel der Klassik mit ihren Tonarten.
Ich weiß.zatzen hat geschrieben:Ich mag SID Musik auch... Naja und die Pattern-Darstellung mit ihren vielen Nullen dient einfach der Übersicht und Intuition,
Ja, wie eben z.B. der X-Tracker von Delusion.zatzen hat geschrieben:und moderne Tracker gingen ja dann auch dazu über die Patterns einfach aber effektiv zu komprimieren.
Naja - für mich macht das keinen Unterschied. Aber das mag auch daran liegen, daß ich selten bis nie irgend etwas "intuitiv" mache. Bei mir hat (fast) alles einen Plan.zatzen hat geschrieben:Es gibt da auch irgendeine trackerartige Software wo alles datenmäßig sehr kompakt gehalten wird durch Makros etc. Aber das wäre mir zu hoch bzw. zu unintuitiv. Letztlich will ich Musik machen - zum Programmieren und Großhirn anstrengen habe ich Pascal und Assembler.
Ich weiß - ich bin langweilig.
Naja, solange der Speicher da ist, kann man ihn auch nutzen. Man muß es eben nur im Blickfeld behalten, damit es am Ende noch reicht. Und, sagen wir mal so: 620 kByte Heap-Speicheranforderung sind nicht gerade optimal - nicht jeder hat so viel "unteren" Speicher frei (obwohl die Leute, die heutzutage DOS benutzen, so langsam wissen dürften, wie man Speicher freimacht). Ich denke, so 600 kByte ist eine gute Obergrenze. Allerdings muß man immer bedenken: Auch Programmcode braucht Speicher, der ist nicht "einfach so da" - der Code klaut ebenfalls der Grafik und dem Sound Speicher.zatzen hat geschrieben: Spiel mit Samples zuknallen:
Ich würde es eher anvisieren, ein Spiel mit relativ wenig Grafikdaten (Vielleicht 128K) zu machen und dazu 64K Sound - als Herausforderung, datenmäßig beim Ton auch minimalistisch und sparsam vorzugehen. ZSMs die nur große Samples aneinanderstückeln finde ich ja auch technisch langweilig.
Beispiel: Man schreibt eine Subroutine, die total komplex ist und die dafür sorgt, daß die Grafik ultraklein gepackt werden kann, so daß man vielleicht 50 kByte einspart. Die Subroutine selbst enthält komplexen Code und Tabellen braucht insgesamt 80 kByte...
Da hätte man nichts gewonnen - man hätte 30 kByte zusätzlichen Speicherbedarf UND eine komplizierte Routine, die auch noch zusätzlich mehr Rechenleistung erfordert.
Anderes, nicht ganz so krasses Beispiel: Man hat Grafik, die 100 kByte braucht, schreibt eine komplizierte Routine und braucht damit 80 kByte, die Routine ist 10 kByte groß. Also spart man 10 kByte - allerdings verbraucht die Routine so viel Rechenleistung, daß die Anzeigeframerate halbiert wird.
Hier muß man immer mal abwägen: Kompliziert kann gut sein - ZU kompliziert kann wieder ins Gegenteil umkippen.
Ja, wie in ISM. Alles andere macht meiner Meinung nach auch keinen Sinn. (In den laufenden Prozeß eingreifen wäre einfach zu crazy und man kann es mit der "Synchronität" auch übertreiben...)zatzen hat geschrieben:Jederzeit in ZSM Samples starten:
Das geht "von außen" natürlich immer nur am Anfang des nächsten Puffers.
Klar - wäre es anders, hätte es keinen Wert.zatzen hat geschrieben:Was ZSM aus den Patterns liest kommt aber absolut zeitrichtig in den Puffer, auch mehrere Sample-Starts innerhalb einer Pufferlänge, sonst würde das ganze ja auch nicht funktionieren.
So ist es.zatzen hat geschrieben:ISM hat also sozusagen eine serielle Datenverarbeitung, bezogen auf eine Stimme.
Genau. Nur daß ISM eben zusätzlich "Nullzeit-Befehle" hat, die dazwischenstehen können, nichts am Puffer ändern, sondern nur an Einstellungen/Arbeitsweise/Daten des ISM-Generators an sich etwas ändern. Dazu gehören auch die verschiedenen Sprungbefehle, aber eben auch andere.zatzen hat geschrieben:Und die muss dann vereinfacht gesagt nur die Informationen Länge und Tonhöhe haben.
Naja, mir ging es hier sekundär um Speichersparen - primär darum, daß ich gleiche Teile nicht mehrmals eingeben muß und wiederverwenden kann - und das auch in jeder Länge und Lage, nicht nur auf feste "Patterngrößen" beschränkt und nicht nur zusammenhängend mit anderen Stimmen.zatzen hat geschrieben:Ist mir von Anfang an auch klar gewesen, und ich kann diesen Ansatz verstehen, er erscheint am logischsten zumindest wenn man ihn direkt mit unkomprimierten MOD Patterns vergleicht, wo eine "Leernote" direkt 4 Byte frisst.
So kann ich die Begleitung ändern ohne die Hauptstimme zu ändern - oder umgekehrt - und habe damit einen neuen Musikabschnitt, der wieder neu und anders klingt ohne zusätzlich etwas einzugeben. Ich kann einen Teil langsam oder schnell spielen, höher oder tiefer. Ich kann eine Begleitung haben und die gleiche Melodie langsamer und tiefer als Hauptteil haben. Ich kann einen Teil haben und den gleichen Teil leiser und leicht zeitversetzt auf der nächsten Stimme spielen - schon habe ich ein Echo. Ich kann Schleifen oder Schleifen um Schleifen und dazu noch einen Stack benutzen, kann ein Unterprogramm bauen und jederzeit aufrufen, das einen Ton als Tremolo oder ähnliches spielt, indem ich den Effekt programmiererisch nachbilde und kann neue Effekte bauen, die z.B. das MOD- oder ähnliche Formate noch gar nicht vorgesehen haben... Alles Dinge, die so einfach gehen, wenn man sich nicht auf eine starre MOD-Rastermatrix beschränkt. Es ist also, genau wie MOD-trackern, ebenfalls kreativ - nur eben anders.
Naja, Noten, die zur gleichen Zeit gespielt werden, stehen auch in der Notenschrift direkt untereinander. Es ist nur eben so, daß die Noten nicht "breiter" werden oder mehr Platz brauchen, wenn sie einen längeren Ton spielen - AUßER, wenn auf der anderen Notenlinie gleichzeitig viele kurze Noten gespielt werden sollen... Dann wird natürlich Platz gelassen. Aber wenn in einem schnellen Musikstück ein langsamer Part kommt, der nur aus langen Noten besteht, wird natürlich kein riesiger Zwischenraum gelassen, sondern man erkennt an der Notenform, welche Länge die Töne haben sollen.zatzen hat geschrieben:Zudem entspricht er eher der Idee der Notenschrift, wo im Zweifelsfall die Notenlängen zählen, und nicht unbedingt was parallel notiert wird.
Ich persönlich kann, wie gesagt, auch mit der Notenschreibweise nichts anfangen. Ich kann sie zwar lesen und könnte sie "abschreiben" und als Melodie umsetzen. Aber ich könnte sie nie "live" spielen - also während ich sie "lese" live mitspielen. Dazu ist sie meiner Meinung nach einfach zu kompliziert gelöst. (Es muß einen Weg geben - Millionen von Musikern auf der Welt benutzen sie und haben damit scheinbar keine Probleme.)
Klar. Und das Schöne ist: Ich könnte sogar eine Begleitung machen, wo z.B. immer 2x HiHat, einmal Baßschlag, dann nochmal HiHat und köntne eine Schleife drum machen - obwohl ich darin 2x das Instrument wechsle und evtl. verschiedene Frequenzen benutzen würde. Und bräuchte dafür 8 Befehle (2 für Schleifeanfang/-ende, je einen für den Instrumentwechsel und die 4 Notenbefehle. Und könnte damit eine Begleitung bauen, die das für maximal 256x4 Töne durchhält und wenn ich eine weitere Schleife um die erste Schleife baue, dann bis zu 65536x4 Töne und das dann mit insgesamt 10 Befehlen (entspricht 20 Bytes).zatzen hat geschrieben:Bei meiner ZSM Komprimierung ergibt sich aber unterm Strich sehr wenig Datenauflauf, weil je nachdem die Tonhöhenparameter mit wenigen Bits auskommen und Leerzeilen entweder Track-Weise mit nur einem Bit vermerkt sind oder auch ein einzelnes Bit eine komplette Leerzeile einer ganzen Patternbreite deklariert. Eine simple Hihat-Spur wo einfach eine Hihat auf jedes 8tel kommt würdest Du wohl in ISM als Schleifenfunktion programmieren.
Aber klar, so eine eintönige Dauerbegleitung würd ich nicht machen. Aber, nochwas: Ich könnte diese Begleitung einsetzen, dann auf eine andere wechseln und dann wieder die vorige nehmen ("Unterprogramme") ohne zusätzlichen Code (abgesehen von den Aufrufen und dem Rücksprungbefehl am Ende) und ich könnte die Anzahl Durchläufe vorher festlegen und dann zum Unterprogramm springen, so daß ich die Begleitung für underschiedlich lange machen könnte.
Und wenn mir das nicht gefällt, gehe ich an EINE EINZIGE STELLE im "Code" (in den Musikdaten) und ändere EINE Zahl ab und schon ist es ganz anders.
Für mich macht das irgendwie so viel mehr Sinn. Aber das kann natürlich jeder anders sehen. Ich bin noch nie auf die Idee gekommen, das "live" mit einer Art "Klaviatur" zu spielen, das wäre mir zu kompliziert. Aber Menschen sind eben unterschiedlich.
Naja, mir stehen jederzeit alle 96 Töne (8 Oktaven á 12 Halbtöne) zur Verfügung, mit Transponieren sogar über 10 Oktaven. Allerdings klingt das nur bei Klangsynthese gut. Samples werden, um die richtige Frequenz zu bekommen, ja schneller oder langsamer gespielt, da ist der nutzbare Frequenzbereich pro Sample natürlich beschränkt, damit es nicht zu schräg klingt.zatzen hat geschrieben:Bei ZSM ergibt das Redundanz, allerdings würde die gesamte Hihat-Spur nur 1 Bit pro Zeile verschlingen, und somit nur 8 Byte aufs ganze 64-Zeilen-Pattern gerechnet. Okay, eins darf ich nicht verschweigen: Jede Spur braucht pro Pattern und Spur eine Tabelle, für diese Hihat enthält diese allerdings auch nur einmal die Information, auf welcher Frequenz sie gespielt wird, das wird mit 5 Bit beschrieben, da die Frequency Tables maximal 32 Werte haben dürfen.
RICHTIGES Pitchen, d.h. Samples bei gleicher Geschwindigkeit trotzdem in unterschiedlichen Höhen zu spielen, "das ist schon eine Wissenschaft für sich - da kann nich jeder mit um"[tm]. Ja, ich weiß, daß es da Möglichkeiten gibt, aber die richtig GUTEN Möglichkeiten fressen Rechenpower ohne Ende (also nichts für DOS-Maschinen) und die halbguten Möglichkeiten klingen nicht wirklich toll, fressen aber trotzdem noch Rechenzeit.
Ein richtig gutes Programm/Spiel erkennt man daran, daß dem Anwender/Spieler nicht auffällt, wie kompliziert das Ding ist (persönliche Meinung).zatzen hat geschrieben:Aber das weißt Du schon alles, es macht nur irgendwie Spaß... u.a. soetwas ist eben der Grund warum ich gerne programmiere, es sind meistens Dinge von denen der User gar nichts mitbekommt.
Anders ausgedrückt: Wenn ein Programm/Spiel zu kompliziert erscheint, ist nicht der User/Player schuld, sondern der Coder.
Zu große Puffer machen "Sound-Lags", ist ja klar. Außerdem kann der Sound dann nur "unzureichend gleichzeitig" auf das Spiel reagieren.zatzen hat geschrieben:Nur zur crazy Pufferaktion: Für eine klangliche Vorschau für das was man ins Pattern programmiert würde es auch reichen, wenn man es erst im nächsten Puffer hört. Vorausgesetzt der Puffer ist nicht allzu groß.
Zu kleine Puffer dagegen bremsen das restliche Programm aus, weil dann das Programm die ganze Zeit nur in Dauerpanik ist, ja den Puffer nicht ablaufen zu lassen und deshalb zwischenzeitlich nicht viele andere Dinge tun kann.
Naja, wenn in ISM eine Stimme IN einem Tune gerade still ist, geht da nur ein Zähler runter, der Zähler wird mit dem Restpuffer verglichen. Ist er höher oder gleich, wird der Restpuffer vom Zähler abgezogen und zum Ende gesprungen = Stimme fertig. Ist er kleiner, wird die Pufferposition um den Zähler erhöht und es wird zur Stelle gesprungen, wo der nächste Befehl geholt wird. D.h. die Stimme macht in diesem Moment (fast) nichts außer eine Handvoll Maschinenbefehle.zatzen hat geschrieben:Im ZSM Player kann man Kanäle aus und an schalten, ich meine es wird dann einfach bei einem wiedereingeschalteten Kanal gewartet, bis ein Sample wieder "auf dem Plan steht".
wenn eine Stimme WIRKLICH aus ist (also unbenutzt), dann tut sie wirklich nichts, dann wird sie übersprungen. Solche Stimmen können nur von außen oder von anderen Stimmen aus (re-)aktiviert werden.
Naja, in AtavISM könnte man das einbauen, allerdings (derzeit) nur zwischen 1 und 64 Zeilen. Das liegt daran, wie die "Einzelteile" gespeichert werden, diese können maximal nur je 256 ISM-Befehle enthalten, und wenn eine Spur "voll belegt" wäre (alles komplett belegt, jede Zeile enthält Note, Effekt und Instrumentwechsel), kommt das Ding ans Limit. Hier müßte ich die Variablen aufbohren, um mehr Zeilen zu ermöglichen.zatzen hat geschrieben:Pattern Break: Das ist auch eigentlich nur ein MOD-Relikt, weil da die Patterns klotzig und steif immer 1024 Byte sein mussten. Bei X-Tracker gibt es keinen Break Befehl, sondern man kann die
Länge eines Patterns zwischen 1 und 256 Zeilen variieren.
(Wie ich ja schon oben erwähnte: Speicher in Daten sparen nützt nur etwas, wenn der Programmcode, der dazu nötig ist, nicht größer oder gleich dem gesparten Speicherplatz ist.)
Genau so. Es würde flackern... halt!zatzen hat geschrieben:10-30 Sprites:
Ich denke, mehr Ansprüche hätte ich da auch nicht.
Wie würde das mit dem nur Löschen und Setzen der Sprites aussehen?
Die einfachste Methode sieht man ja zu hauf an vielen Amateur-Spielen:
Es flackert.
Also, ausführliche Erklärung:
Methode A: (simpel)
Alles in einen RAM-Puffer machen. Erst Level hinmalen. Dann Sprites drauf und immer letztes Sprite X bis 1 löschen, dann wieder Sprite 1 bis X setzen. Am Ende alles mit einem REP MOVSD in den Grafikspeicher kopieren.
- Vorteil: Flackert nicht, Sprites dürfen sich überdecken, Pixel werden nur 1x in die Grafikkarte geschrieben, Sprites können mit beliebiger Routine gezeichnet werden.
- Nachteil: Evtl. etwas langsam, großer RAM-Puffer benötigt, zusätzlich Platz zum "Retten" des Bildinhalts unter den Sprites benötigt.
Methode B: (tricky)
Alles direkt im MCGA machen (320x200x256), aber ohne verdeckte Sprites (also Sprites dürfen sich nicht überlappen). Als erstes: Level hinmalen. Dann Sprites hinmalen. Beim Versetzen eines Sprites, löschen und wieder hinmalen.
Vorgehensweise: Man braucht 4 (vier!) Routinen, die Sprites zeichnen und/oder Hintergründe retten.
Routine 1: Zeichnet Sprite, rettet dabei Hintergrund.
Routine 2: VORWÄRTS: Zeichnet Sprite, holt Hintergrund zurück, rettet neuen Hintergrund (bei jedem Pixel ein Schritt, der alle 3 Dinge tut).
Routine 3: RÜCKWÄRTS: Zeichnet Sprite, holt Hintergrund zurück, rettet neuen Hintergrund (bei jedem Pixel ein Schritt, der alle 3 Dinge tut).
Routine 4: holt Hintergrund zurück, ohne Sprite neu zu setzen.
Ja, das ginge auch mit EINER Routine - aber dann wären wieder ein Haufen Entscheidungen drin bei jedem Schritt, also langsam und sinnlos.
Routine 1 wird benutzt, um ein Sprite neu zu setzen, das noch nie da war.
Routine 4 wird benutzt, um ein Sprite entgültig zu löschen (das ab dem nächsten Schritt nicht mehr gebraucht wird)
Routinen 2 und 3 werden benutzt, um das Sprite zu bewegen. Die letzte Position des Sprites wird irgendwo gespeichert, am besten als absoluter Wert (0 bis 63999). Die neue Position wird mit der letzten verglichen. Ist sie größer/höher als die alte Position, wird Routine 3 benutzt, ist sie kleiner/niedriger, Routine 2. (Ist sie gleich, wird gar nichts gemacht.)
Sprites liegen dabei dann "linear" irgendwo rum, jede Figur erhält einen Puffer in Spritegröße.
Ein Sprite wird gezeichnet, indem man alle Pixel zeichnet (transparente überspringt, siehe *X), bei Erreichen der Breite dann (320-Breite) addiert, sonst nur 1 (kann man auch wieder mit dem "Trick" machen, der 32bit-Adder, wo die oberen 16 Bit als Zähler funktionieren) und außerdem an der alten Position gleichzeitig "wiederherstellt".
Routine 2 (vorwärts) macht das von der oberen linken Ecke, Routine 3 macht das ganze nur rückwärts, d.h. von der unteren rechten Ecke aus.
Auf diese Art werden mit der gleichen Schleife 3 Dinge getan: Wiederherstellen-Retten-Pixeln.
So, jetzt noch das *X: Beim Überspringen der zu pixelnden Bereiche am besten trotzdem den Hintergrund retten. Grund ist einfach: Soll das Sprite animiert werden (natürlich gleiche Größe!), geht das Wiederherstellen trotzdem noch und auch Routine 4 wird einfacher. Andererseits kann man auch einfach Mit-speichern, welches Image beim letzten Mal benutzt wurde, das macht dann aber die Routnen2+3 komplizierter (und langsamer) weil man auf 2 verschiedene Images zugreifen muß und mehr Sprünge hat.
- Vorteil: Alles direkt im Bild (kein Kopieren), kein zusätzlicher Bild-RAM-Puffer, nur Sprites müssen neu gezeichnet werden. Unbewegte Sprites brauchen nicht beachtet werden, relativ schnell
- Nachteil: Falls zufällig der Rasterstrahl an einer der beiden Stellen ist, wo man gerade pixelt, kann es kurz flackern - ABER - der Rasterstrahl ist VIEL langsamer als eine kleine ASM-Schleife und: Ich setze z.B. meine Mauspfeile auch so und da flackert garnix. Anderer Nachteil: Sprites können kaum gepackt werden (höchstens vielleicht weniger Farben und dann bitweise, aber eben kein ZVID-mäßiges, blockweises o.ä.
Methode C: (Mehrbildschirm, so mache ich es)
Mode-X oder VESA oder ähnliches benutzen, das Platz für mehrere Bilder im Speicher ermöglicht. Dann immer im nicht sichtbaren Bild Level zeichnen und Sprites drüberzeichnen und wenn fertig, auf das Bild umschalten und im nicht sichtbaren das neue Bild zeichnen.
- Vorteil: Kein Flackern, kein RAM-Puffer, kein "Bildrettungs-"Puffer, Sprites mit beliebiger Routine zu zeichnen, Sprites müssen nicht gelöscht werden, Sprites können sich überlappen, kein Lesen aus Grafikspeicher nötig, "Scrolling" einfach durch verschobenes Level darstellbar, auch das Level kann "sich bewegen/ändern"
- Nachteil: Benötigt andere Modi als den praktischen MCGA (z.B. Mode X), es muß immer ein ganzes Bild gezeichnet werden, d.h. X*Y Levelpixel PLUS alle Spritepixel direkt an Grafikspeicher, Performance je nach Grafikspeicher-Übertragungsrate.
Methode D: (z.B. Kotzman II)
Sprites mit Rand in Hintergrundfarbe, löschen ihre "Reste" selbst weg beim Neuzeichnen.
- Vorteil: Level muß nie nachgezeichnet werden, Sprites brauchen nicht gelöscht werden, unbewegte Sprites brauchen nicht neugezeichnet werden, MCGA möglich, beliebige Spriteroutine möglich, hohe Ausführungsgeschwindigkeit
- Nachteil: Sprites dürfen nicht überlappen, "begehbarer" Hintergrund darf nur einfarbig sein, Spriterand muß mindestens so breit sein wie sich Sprite in Pixeln bewegen kann (daher keine "Berührung" von Levelelementen möglich in Bewegungsrichtung)
Von dem Ganzen gäbe es noch Mischformen und Abwandlungen. Das wären so die Dinge, die mir spontan dazu einfallen. Methode B ist z.B. etwas tricky, hier müßten viele Dinge berücksichtigt werden - aber wenn's funktioniert, kann es für ein Nicht-Scrolling-Spiel wohl eine gute Idee sein.
Allgemein ist ein "Nicht-Überlappen-Dürfen" ein Pain-In-The-Ass für unabhängige Steuerroutinen. Da muß dann ständig darauf geachtet werden, daß das nicht passiert, sonst gibts Grafikfehler. Das wird umso ekkiger, je mehr bewegliche Elemente/Figuren man hat.
Würde ich eine Weile darüber nachdenken, fielen mir sicher noch mehr Möglichkeiten ein. Das war jetzt nur das, was ich so spontan dazu habe.
Ja, man kann hier beliebig einfach oder komplex abgehen. Einfache Regel: Mehr Performance kann man sich durch mehr Speicher erkaufen, Speicher sparen durch geringere Performance.zatzen hat geschrieben:Die weiteren Methoden, auch mit Scrolling, die Du angeführt hast, sind interessant, aber im Moment noch zu hoch für mich, da ich ja überhaupt erstmal ein Spiel mit transparanten Sprites und Hintergrundgrafik machen will.
Je weniger gepackt Daten sind, umso einfacher der Zugriff, umso simpler (und schneller) die Routinen.
Komplexes Packen spart viel Speicher, allerdings brauchen komplexe Routinen mehr Ausführzeit.
Ich versuche hier immer, einen guten Mittelweg zu finden.
Beispiel: Ein 8-Wege-scrollbares Level kann ich nicht packen. Ich muß in jede Richtung können und wissen was da kommt. Wenn man da packt, wird man wahnsinnig. Und ja, da sind dann eben auch mal ein ganzer Haufen Nullblöcke wenn da ein freier Raum ist.
Aber: Ein 2-Wege-scrollbares Level kann man in begrenztem Maße packen.
Und: Ein 1-Wege-scrollbares Level (nur in eine Richtung, nicht rückwärts) kann man sehr gut packen, weil es nicht "von hinten/oben/unten/schräg" lesbar sein muß, sondern nur von einer Seite. Bei Katakis (C64-Spiel) sind die Level so wahnsinnig gepackt, das ist super. Manfred Trenz hat die einzelnen Levelelemente zu "Modulen" gemacht, die verschiedene Größen (X*Y) haben können und die auch wiederholt werden können usw. Da wird einfach an der Stelle wo es beginnen soll, der Startpunkt hingesetzt und das Modul wird dann reingezeichnet während des Scrollings. Geniale Methode. Tricky, aber geil. So sieht das aus, wenn jemand wenig Speicher und wenig Rechenpower hat und dafür stattdessen sein Gehirn benutzt.
Für so Levels mit festen Bildschirmen hätt ich schon wieder eine Idee. Levels haben Blocks aus 16x16 Pixeln. Somit 20x12=240 Blocks. Dann noch 16 Extrabytes, die sind die 4 Startpunkte für die Figur (je nachdem aus welcher Richtung sie reinkommt) und 0 bis 6 Startpunkte für "Gegner"/"Gegnerformationen", immer 2 Bytes (Position, Gegnertyp). Die Positionen sind "block-genau". Wenn es weniger sind, ist Position>=240. Somit hätte ein "Raum" genau 256 Bytes und wäre 320x192 Pixel groß. Die restliche Zeile (oben oder unten) kann man für Anzeige (Punkte, Restleben usw.) benutzen.
Um etwas zu bauen, was das eben beschrieben grafisch macht, in Assembler, für Levelanzeige und Sprites (Methode B) bräucht ich keine Woche. Die Grafiken/Sprites irgendwo malen natürlich nicht mitgerechnet, nur die Programmierung.
Wenn auch Sprites nur 16x16 (bzw Vielfache davon) sein würden, könnt man sowohl die Levelklötze als auch die Sprites einfach in 320x200er Bilder pixeln und die Routine würde das da auslesen. Leseroutine wäre dann super-easy, weil der Zeilenoffset der Sprites und Blocks der gleiche wäre wie beim Bildschirm...
Da könnt man auch z.B. festlegen daß es 16 verschiedene Arten von Figuren gibt und Blocks 0-239 wären normale Blocks und Blocks 240-254 wären Gegner und 255 wäre Spieler. (Weil bei 320x200-Bild nur 240 Blocks darstellbar wären.) An diesen Positionen wären dann Gegner (darunter wäre bei Start eben immer ein 0-Block)...
Ja, so ein Ding würde ich, grafisch/datentechnisch recht einfach hermachen.
Es macht schon einen ziemlichen Unterschied, wenn man kein Scrolling benutzt, Figuren nie außerhalb des sichtbaren Bereichs sein können und alles in "Matrix"-Abmessungen ist, die Figuren keine Sonderfunktionen haben wie Spiegeln, Drehen oder so... naja, was auch immer. Aber das wäre dann eben nur die Ausgabe. Die Steuerung wäre dann noch etwas anderes.
Naja, Turbo-Pascal ist ja so schlau und bindet nur Dinge (Variablen, Prozeduren, Funktionen) ein, die auch mindestens einmal irgendwo benutzt werden, d.h. wenn man eine Unit einbindet und nichts daraus benutzt, wird EIGENTLICH auch kein zusätzlicher Speicher verbraucht... Aber manche Units haben eben auch einen Init- und Exit-Teil, um die Variablen oder bestimmte Dinge zu initialisieren oder nach Programmende vernünftig zurückzulassen und das würde z.B. trotzdem ausgeführt werden und die entsprechenden, ansonsten nie genutzten Variablen würden angelegt usw. Daher auch die Option, eine Unit komplett weglassen zu können, wenn nichts davon je benutzt werden soll.zatzen hat geschrieben:Ich glaube, das mit SLOT verstehe ich schon einigermaßen. Man könnte sagen, Du könntest die individuellen Features als Units optional reinpacken, aber ich glaube das Finetuning ist noch genauer.
Teile der Units kann man dann auch noch "ausblenden", d.h. wenn man nur einen Grafikmodus/Levelmodus benutzt, den man auch nie umschalten will, braucht man nicht die Routinen für die anderen Modi mit einbinden.
Zusätzlich enthält das Template auch noch numerierte Platzhalter (in Kommentaren), um eigenen Code an bestimmte Stellen einbinden zu können.
Das Ganze bekommt dann wahrscheinlich so eine Art "Hauptprogramm", von dem aus man die verschiedenen Editoren starten kann. Allerdings wird es eben trotzdem eher ein "freakiges Ding" werden - weil ich natürlich nicht soviel Speicherplatz für irgendwelche hübschen, idiotensicheren Sachen verschwenden will. Diese Entwicklungsumgebung ist ja eher für mich. Wer auch immer das dann benutzen will, kann es natürlich tun. Aber das wäre dann ohne Garantie, weil's eben KEIN "schicker Game-Maker" wäre. Ich will ja endlich mal ein Spiel machen und habe mich mit den nötigen "Einzelteilen" schon jahrelang aufgehalten - nun wird's Zeit für den Endspurt. Es ist 2018 - zehn Jahre her seit meines letzten großen Spielprojekts. Danach nur so kleine Spielchen, viele Tools... und eben einige "Engines" für verschiedenste Zwecke, die zwar an sich toll sind, aber bisher nirgends eingesetzt werden, so daß eben nichts "nach außen" kommt von dem, womit ich mich die letzten Monate und Jahre beschäftigt habe. Also: Das "Hauptprogramm" (für die Entwicklerseite) wird keine Mausunterstützung, keine grafische oder Textoberfläche haben, es wird sehr simpel werden.