Ich hatte ursprünglich auch die Fenstergröße einbezogen, weil ich wollte ja Vollbild machen. hab mich dann aber wegen der Geschwindigkeit für einen kleinen fixen Ausschnitt entschieden.
Naja, eben, daher war meine erste Version auch etwas umfangreicher als deine.
Das liegt an der Sinusberechung, das kostet.
Die hab ich ja dann auskommentiert. Aber wie kriegt man die Dinger sonst dazu, sich elegant auf der x-Achse zu bewegen? Und ist die Zufallszahlenerzeugung nicht langsamer als Sinus? Ausserdem brauch ich den Sinus ja nur ungefähr, man muss die unendliche Reihe ja nicht so weit fortführen... Ich könnte ja mal versuchen, die Sinusfunktion zu emulieren... Wenn ich mir mal was in den Kopf setze...
So eine Berechnung (sin, cos oder auch z.b. Wurzeln ziehen) ist immer aufwändig und zeitintensiv, sogar in Assembler. Die Zufallzahl dürfte um einige Faktoren schneller erzeugt sein.
Ausserdem bleiben die Schneeflocken nicht unten liegen, sondern bekommen dann ein neues Objekt zugewiesen und fangen wieder von oben an.
Auch das ist nicht optimal. Ständig delete und new aufrufen verzögert unnötig.
Ist ja nicht ständig, nur wenn eine unten ankommt, was ja pro Sekunde nicht so oft geschieht. Da ist die Sinusberechnung sicher langsamer.
Das stimmt. Aber du gibst den Speicher frei um ihn direkt danach wieder neu zu belegen. Dass ist überflüssig und auch nicht im Sinne von Objekt orientierter Programmierung.
...Oder aber man schenkt sich die Libraries ganz, nimmt nur den Kernel und greift direkt auf die Grafikkarte zu. Saukompliziert, und so viel Erfahrung hab ich damit auch noch nicht, aber schneller als das geht's nun wirklich nicht.
Naja, das ist natürlich etwas extrem anderes. Das wäre ungefähr so, wenn du sagst, der Trecker ist ganz schön langsam, mein Rennauto ist viel schneller, nur wirst du damit kaum einen Pflug ziehen können.
Machen kann man mit Assembler alles, daher ist das eher kein guter Vergleich. Ich würde eher sagen, das Rennauto ist viel schneller, dafür hast du aber auch mehr Arbeit mit der Wartung.
Meine Rede, du hast aber nur die Geschwindigkeit verglichen.
Ursprünglich hatte ich statt den Vergleichsoperatoren das bitweise UND verwendet, und statt allen Multiplikationen Bit-Shift-Operatoren (die wären sehr viel schneller gewesen, gehen hier aber leider nur für Integer... arrrrgh... da hab ich mir einige Haare ausgerissen, bis ich da draufgekommen bin). Das kommt auch alles von Assembler. Man kann ja überhaupt am Programmierstil gut erkennen, mit welchen anderen Programmiersprachen jemand viel zu tun hat.
Man kann in Assembler sicher auch keine Fließkommazahlen Bitweise bearbeiten, da der Aufbau dieser Zahlen unterschiedlich sein kann.
Statt Math.round kannst du in JS auch parseInt verwenden und dann sollte es gehen.
Struppi.
Javascript ist toll (Perl auch!)