Daniela: Kann nicht auf "style"-Attribut zugreifen

Beitrag lesen

http://jstruebig.de/web/javascript/spielereien/schneeflocken/schneeflocken.html

geht bei mir auch mit 250 Flocken.

Wow, das hat ja viermal mehr Variablen als meins und ist viel schwieriger.

Das einzige was schwieriger ist und mehr Variabeln erfordert, ist das ich die Fenstergröße mit berechnet habe.

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.

Ich hab das mir der Fenstergrößenberechnung und mit dem prototyp rausgenommen woei, wenn du schon Objekte deklarierst gehört das natürlich dazu.

Immer langsam mit den jungen Pferden, ich hab gestern das erste Mal ein Objekt deklariert.

.... Bei meiner Version (unten angehängt) hab ich Schneeflocken verschiedener Größen und die kleinen bewegen sich langsamer.

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...

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.

...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.

So, und hier mein Schneegestöber (nicht wundern, ich hab 'nen kleinen Zweierpotenzentick):

Ich hab's gemerkt ;-) (kommt wohl vom Assembler programmieren)
und auch in meiner Version eingebaut.

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.