Pixi.js: Überarbeitung von APIs, die Bogenmaß verwenden, um stattdessen Grad zu verwenden

Ein paar Nachteile, die mir einfallen:

• integrierte Javascript-Mathematikfunktionen standardisieren auf Bogenmaß
• integrierte glsl-Funktionen standardisieren auf Radiant
• Bogenmaß ist ein bequemeres Format für den Umgang mit einigen Arten von Berechnungen (z. B. kann ich von 0 -> Math.pi * 2 lerp und eine volle Drehung im Uhrzeigersinn erhalten.)

Ich bin Mathematiker und bevorzuge es, entweder Grade 0..1 oder 0..512 zu verwenden, aus Gründen der Persistenz und des Shader-Formats. Wenn Sie mir vor zwei oder mehr Jahren dieselbe Frage gestellt haben, könnte ich sagen, dass Radiant besser ist, weil sie in mathematischer Bedeutung "rein" sind.

Das Speichern von 2 x Math.PI in Dateien ist jedoch ein Problem (Persistenz), und "360" ist nur schneller zu schreiben als 2 * PI, es kann nicht klar in binärer Form dargestellt werden.

Flash-basierte Engines arbeiten meist mit Abschlüssen:

https://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/graphics/g2d/Sprite.html#getRotation --

http://cocos2d-x.org/docs/programmers-guide/sprites/index.html

http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7def.html

https://www.youtube.com/watch?v=zAsDbHXlFWI

Auch Editoren wie Spine arbeiten und speichern Winkel im Bogenmaß.

Eine weitere seltsame Sache ist, dass wir SKEW verwenden, was Grafikdesigner-Ding ist und im mathematischen Sinne nur "(shear.y , -shear.x)" ist. Wir erlauben eine solche Abscheulichkeit und zwingen den Benutzer, gleichzeitig Rads zu verwenden.

Sein Konflikt zwischen "Low-Level-Renderer" und "2D-Grafik-Renderer mit eigener Bühne und Tools-Unterstützung", und ich denke, pixi liegt näher am zweiten.

@englercj An dem Code muss ich auch arbeiten, sowas habe ich schon in meinem Fork: https://github.com/gameofbombs/gobi/tree/master/src/core/transform
https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts

@mreinstein Ich muss mich auch diesen Code ansehen, da Sie etwas über Pixi-Transformationen wissen;)

Vorschläge von @bigtimebuddy & @GoodBoyDigital machen die API konfigurierbar:

// useDegrees
CONVERSION = Math.PI / 180;

// useRadiens
CONVERSION = 1;

set rotation(rot)
{
    this._rotation = rot * CONVERSION;
}

Vielleicht wie Phaser es tut? Der Winkel steht für Grad, die Drehung für das Bogenmaß.

@englercj Zustimmen . Das ist der einfachste Weg dorthin. Auf pixi basierende Engines können einfach ihre "CONVERSION"-Konstante korrigieren.

@englercj Processing macht dies, und ich denke, es ist eine wirklich schlechte Designentscheidung. Es schadet der Modularität. Wenn Sie einen Code haben, der etwas in eine Richtung tut, und versuchen, einen anderen Code (vielleicht in einer Bibliothek) zu verwenden, der die andere Richtung annimmt, wird es nicht funktionieren. Wenn Sie sicherstellen, dass der Einheitenmodus vor jedem Aufruf einer winkelbezogenen Funktion festgelegt wird, stellt dies möglicherweise sicher, dass Ihr Code funktioniert, bricht jedoch den Bibliothekscode. Und wenn es einen Bibliothekscode gibt, der Winkel verwendet, sollte er dann den Winkelmodus einstellen? Das könnte garantieren, dass sein Code wie beabsichtigt funktioniert, aber den Code des Benutzers bricht. Es ist fast wie das Gefangenendilemma des API-Designs.

@OSUBlake Das scheint vernünftiger zu sein. Während die Namen Winkel und Drehung keine Einheit explizit bezeichnen oder verbieten, gibt es definitiv Assoziationen, die dies vernünftiger machen als eine 50/50-Schätzung.

Ich denke jedoch, dass angleDeg und angleRad besser wären. Warum nicht explizit machen?

Der Winkel steht für Grad, die Drehung für das Bogenmaß.

Das mag Phaser so machen, aber das ist nicht allgemein anerkannt. Rotation ist die Aktion, und der Winkel ist der Betrag dieser Aktion, die stattgefunden hat. Manchmal auch als "Drehwinkel" bezeichnet. Technisch gesehen könnten Winkel oder Drehung also überladen werden, um sich auf dasselbe zu beziehen, und könnten in einer der beiden Einheiten (Grad oder Bogenmaß) ausgedrückt werden.

Alle mathematischen Operationen mit Rotationen sind mit Bogenmaß viel einfacher. Es ist wirklich nicht so schwer zu begreifen; Math.PI befindet sich in der Mitte des Kreises; Math.PI * 2 ist eine volle Umdrehung.

Der einzige Zeitgrad ist angemessen, wenn Sie eine visuelle Benutzeroberfläche Personen zur Verfügung stellen, die eine Rotation beinhaltet, und Ihr Publikum eine Gruppe ist, die die grundlegende Geometrie nicht versteht (dh die meisten Menschen).

Ich erkenne, dass dies eine Meinung ist, aber gehen Sie einfach mit Bogenmaß. Alle Math-APIs in Javascript arbeiten mit Bogenmaß, nicht mit Grad, wie die meisten Geometriebibliotheken, die kein Spielzeug sind.

Wenn wir wirklich alle für alles unterstützen müssen, dann stimme ich @1j01 zu, um es explizit zu machen. Vielleicht .degrees oder .radians ?

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

Dieser Thread wurde automatisch gesperrt, da nach dem Schließen in letzter Zeit keine Aktivität stattgefunden hat. Bitte öffnen Sie eine neue Ausgabe für verwandte Fehler.