Morgen. In den letzten Tagen hab ich eine relativ witzige Starfield Simulation zusammengeschustert, welche ich euch nicht vorenthalten will. Das besondere an dieser Starfield Simulation ist, das die Geschwindigkeit der Darstellung nicht von der Anzahl der Sterne abhänig ist, was bei den meisten, gängigen Starfield Simulationen der Fall ist.




Anstatt jeden Stern einzeln zu zeichnen erstelle ich am Anfang des Programms 30 relativ große Sprites in denen eine größere Anzahl von Sternen abgebildet ist. Diese werden dann mit Hilfe einer Funktion gezoomt, welche vom Strahlensatz abgeleitet ist, um so die Illusion von Dreidimensionalität zu erzeugen. Desweiteren werden diese Sprites immer öfters gezeichnet umso näher sie der Kamera kommen um einen Motion Blur Effekt zu erzeugen.

Um das ganze zu realisieren brauchen wir folgende Funktionen:

SCR_CreateStarfield:
Diese Funktion erzeugt das Starfield Objekt.

SCR_Starfield_Step
Diese Funktion manipuliert das Starfield während des Step Events

SCR_Starfield_Draw
Ihr dürft raten was diese Funktion macht...

SCR_RandStarfield
Erzeugt eine neue Starfield Ebene, wenn eine Alte an der "Kamera" vorbei geflogen ist.

SCR_CreateStarfield:
Eine der Komplizierteren Funktionen in diesem System, da sie Tonnen von Parametern Futtert, um das Starfield gut Customizen zu können. Dazu gehören:

argument 0:
Anzahl der Sterne. Diese wird auf die Anzahl der Ebenen verteilt. Hat außer bei der Generierung der Starfield Surfaces keine Auswirkung auf die Performance.
argument 1:
Anzahl der Ebenen. Umso mehr Ebenen eine Starfield Simulation besitzt, umso dynamischer sieht sie aus. Normalerweise reichen 5 - 8 Ebenen, danach kämpft das System schon mit erheblichen Performance Problemen.
argument 2:
Tiefe. Die Maximale Sichtweite der Starfield Simulation.
argument 3 und 4:
die Fixierte und Zufällige größer der Einzelnen Sterne. Ein wert von 4 und 3 ergibt Sterne in der Größe von 4 - 7 Pixel.
argument 5:
Die Geschwindigkeit der Starfield Simulation.
argument 6:
Detailgrad. 1 Ist das Maximum, nach obenhin ist die skalierung offen. Um so höher der Wert, um so niedriger sind die Details. Hat Massive Auswirkungen auf die Performance.
argument 7 und 8:
größe der View in der sich die Simulation befinden soll.
argument 9:
Leerraum für Sterne. Bei 0% können sich Sterne auch im Zentrum der Kamera befinden (was oft störend wirkt), bei 99% sind sie nur am Rand der Simulation.



SCR_Starfield_Step:
Diese Funktion überürpft ob eine Sternenebene an der Kamera vorbeigezischt ist bzw. im nichts verschwindet und erzeugt dann eine neue.

SCR_RandStarfield:
Diese Funktion erzeugt eine neue Sternenebene


SCR_Starfield_Draw:
Und diese Funktion zeichnet das ganze


Die Funktion SCR_Starfield_Step und SCR_Starfield_Draw gehören in das Step und Draw Event eines Objekt namens OBJ_Starfield.

Durch Manipulation der Variablen MoveX und MoveY kann die Starfield Simulation Kurven fliegen, die Geschwindigkeit kann durch die Manipulation der Variable Speed verändert werden. Dabei ist aber anzumerken, das die Simulation bei einer Geschwindigkeit von 1/-1 unheimlich ... fad ... aussieht und bei 0 gänzlich verschwindet.

Wenn sich irgendwer Fragt warum einige Variablen den Namen Fog haben, ursprünglich hätte das eine Nebel Simulation werden sollen ... ist dann aber irgendwie doch keine geworden.

Das Ganze Teil ist mit der SGPL lizensiert (Shoba General Public License) :3.

@ Blackspark: Als GML Fortgeschrittener solltest du kein Problem haben meinen erklärungen zu Folgen, wo welche Funktionen hingehören (was übrigens im Example steht). Das mit der GM6 Datei hat den einfachen grund, das ich nach meinem Letzten System Crash gar keinen GM6 mehr installiert habe.

@Dragoon: 2-3 Stunden. Den Hauptteil hatte ich schon nach ner 1/2, aber optimieren und verschönern kostet einiges an zeit. Wenn du den Detailgrad auf 5 und die ebenen auch auf 5 stellst, sollte es ohne gröbere probleme auch flüssig laufen.

@Verwurster: Die Anzahl der Sprites hängt von der Anzahl der gewählten ebenen und der Geschwindigkeit hab. Umso näher eine Ebene bei der "Kamera" ist, und um so schneller sich diese bewegt, umso mehr Sprites werden gezeichnet, um den Blur besser darzustellen.

@Jokohono: Ist "Leihbar" unter der SGPL, mit einem eintrag irgendwo in den Credits. Obs für ein Spiel brauchbar ist is fraglich, da es doch einiges an Resourcen frißt. Ich habs eher für Abspänne oder Intros entwickelt.

Gut, zeig mal? Aber so braucht das Programm kaum Speicherplatz, was letztendlich für den, der Runterlädt von vorteil ist. Wenn ich jetzt Fix Sprites ins Programm einbaue, wird das einfach nur größer.

Hat irgendwer von euch den Source überhaupt verstanden? Zur laufzeit werden eh keine Surfaces benutzt. Die werden nur im Create Event erzeugt, um die Sprites darzustellen. Nachdem all diese Surfaces auch im Create wieder eingestampft werden, ist der rest irrelevant.

Sorry auch meinerseits, war gestern etwas gestresst, was für Sonntage ein ganz schlechtes Zeichen ist.

Also, nur zur Erklärung: Die Surfaces werde nur benutzt um die Sprites, welche die Sterne beinhalten zu zeichnen.
Der Grund warum es ohne Surface wahrscheinlich nicht funktioniert ist, das die Sprites bei einer Detailstufe von 1 doppelt so groß sind, wie die aktuelle View (also bei 320x240 sind sie 640x480, beu 800x600 1600x1200 und so weiter ... ). Weiters ist die Create_Sprite_from_Screen funktion unheimlich langsam ... was, sofern man das Starfield ganz am Anfang des Programms generiert, irrelevant ist.

Braucht man eh nicht, eine Detailstufe von 3 oder 4 tut es normalerweise auch. Ich hab jetzt mal das Surface_create aus der Schleife raus genommen, das sieht dann so aus:



Geschwindigkeitsmäßig erkenne ich jetzt auf Anhieb keinen unterschied, da immer nur 30 Surfaces erschaffen wurden. Auch deren Anzahl könnte