spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

According to Microsoft, "Floating-point arithmetic overflow or division by zero never throws an exception, because floating-point types are based on IEEE 754 and so have provisions for representing infinity and NaN (Not a Number)."

	Quellcode
1	uvsArray[i] = new Vector2(vertices[i].x / uvScale, vertices[i].y / uvScale);

Zitat von »David Scherfgen«

Wie sieht es denn bei einer Skalierung von 0 aus, verglichen mit einer Skalierung von z. B. 0.001? Eigentlich dürftest du dann gar keine Textur mehr sehen, weil ja alles Vertices dieselben UV-Koordinaten von "unendlich" kriegen.

Zitat von »Audori«

c# hat einige Features um ganz automatisch bestimmte Stolpersteine bei Spezialsituationen, an die man normalerweise garnicht Denkt, selber zu lösen. z.B. kann man Math.Abs(float.NaN) aufrufen, und der Rückgabewert wird nicht zu noch mehr Blödsinn, sondern bleibt float.NaN.
Und auch Bit-Operatoren, berücksichtigen automatisch die CPU-Architektur, so das man z.B. auf einen BigEndian System und einen LittleEndian System, den exakt gleichen Programmcode eintippen kann, und es kommt sozusagen das gleiche Ergebnis raus. So das man da also garnichts beachten muss. Selbst diese Daten dann per Netzwerk an einen Rechner mit anderer CPU-Architektur zu senden, funktioniert problemlos. Lediglich wenn man bewust sehr tief runter geht um z.B. eine eigene Binäre Serialisierung zu programmieren, müsste man da einwenig darauf achten.

Was nun float und 0 angeht... muss man sich meist auch keine Gedanken machen. Erst bei sowas wie Modulo 0 (z.B. float x = 7f % 0f) weiß auch c# nichtmehr wie man das Sinnvoll handhaben kann und wirft eine Exception.
Grundsätzlich kann man bei c# eigentlich immer davon ausgehen, wenn es irgendeine Sinvolle Möglichkeit gibt mit einer besonderen Situation bei einer Operation umzugehen, dann wurde das auch implementiert. Und nur wenn es keine Sinnvolle Möglichkeit gibt, oder mehrere unterschiedliche aber "gleich gute Lösungsergebnisse" bei denen c# nicht Wissen kann was der Programmierer beforzugt, erst dann wird eine Exception geworfen.

Oben drauf kommt da dann nun Unity, was auch nochmal einige kleine versteckte aber schöne Verbesserungen mit sich bringt. z.B. haben alle primitive Datentypen, ganz besonders float, in sich eingebaut eine performance optimierung auf ihre Operatoren bekommen. Zusätzlich dann noch die Mathf welche man anstelle von Math nutzen kann/sollte (Math.Abs() -> Mathf.Abs()) da dort dann auch diese weiteren Funktionen Performanceoptimiert sind.


Übrigens, schon mal Gedanken gemacht über sowas hier?
if(anyFloat == 7.0f)

Normalerweise wäre das gefährlicher Code, da aufgrund der unumgänglichen minimalen Ungenauigkeiten bei Fließkommazahlen, eine exaktes == sehr problematisch ist. Doch in c#/Unity ist der == Operator implementiert mit sozusagen der Logik: "A ist auf +/- 1.401298E-45F ungefähr gleich zu B"
Solche Dinge meine ich mit Stolpersteine bei Spezialsituationen an die man normalerweise garnicht Denkt, die aber automatisch für einen gelöst werden


Was nun deine 0 und Texturskalierung angeht.... da kommt nun auch noch der Shader dazu. Die in Unity mitgelieferten Shader, und ebenso auch bei den Shadern deren Code man in Unity selber schreibt, läuft eine wirklich extreme optimierung drüber wenn sie compiliert werden. Und ja, an den Code der Unity Shader kommt man ran und die nutzen die gleiche Magie/Mittel/Funktione/etc. wie die Shader die man selber schreibt. Und eben bei diesen extremen optimierungen beim compilieren, werden auch wieder einige (leider nicht alle) Stolpersteine berücksichtigt. Hier kommt es sehr darauf an, welche Funktionen man selber in seinem Shader Code aufruft. Am ehesten noch problematisch sind hier Bereichsüberläufe bei Farben/Licht/Schatten ... wenn also z.B. aus einem "gaaaanzzz schwarz und dunkel", plötzlich ein "strahlend weißer Pixel" wird. Was z.B. dann passiert wenn man einen Shader für HDR schreibt, aber im Shader z.B. eine NICHT-Color-Funktionen nutzt um einen Color Wert zu ändern (im Shader kann man z.B. ein Float3-Lerp() auch auf ein Color anwenden, anstelle eines Color-Lerp()).

Worauf ich hinaus will ist, auch bei den Shadern wird vieles automatisch berücksichtigt. Daher vermute ich das bei dem Shader den du da gerade nutzt, die 0 bei Texturskalierungen berücksichtigt wird und es deswegen zu keinen Problemen kommt. Wundere dich also nicht zuuu viel

Trotzdem würde ich dir empfehlen, bei allem immer trotzdem zu versuchen plausible Zahlen einzugeben, auch wenn du keinen Unterschied siehst. Irgendwo ganz anders oder erst im Zusammenhang mit dem aktivieren eines ganz anderen Features könnte es dann eine Rolle spielen. ...z.B. wenn du jetzt alles im Gamma Farbraum machst ... und in einem halben Jahr auf die Idee kommst auf Linear Farbraum zu wechseln (oder Umgekehrt, von Linar auf Gamma -> z.B. weil Gamma für deinen Geschmack/Spiel schöner aussieht, oder das Spiel für Mobiltelefon oder Tablet sein soll).