Comentarii

Copiați linkul Citat răspuns

sharpdx

Patogen David comentat 26 mai 2014

În primul rând, îmi cer scuze dacă s-a mai discutat despre acest lucru sau dacă există deja un efort continuu pentru a face ceea ce descriu. Nu am putut găsi nimic legat de asta.

În al doilea rând, postez mai ales acest lucru, deoarece oricum fac aceste modificări la o versiune personală a SharpDX. Am crezut că ar trebui să încep o discuție pentru a determina dacă ar trebui să fac modificările mele într-un mod care să le permită să fie integrate la depozitul principal SharpDX la un moment dat. Îmi dau seama că ceea ce propun este o schimbare într-o oarecare măsură, dar m-am gândit că ar trebui să spun ceva în cazul în care Alexandre lucrează deja la ceva similar la Silicon Studio sau există un interes general în acest sens.

SharpDX se face publicitate ca „un proiect open-source care furnizează API-ul DirectX complet sub platforma .Net”. În timp ce SharpDX îndeplinește cu siguranță acest obiectiv, acesta vine, de asemenea, cu o tonă de cod utilitar pentru a facilita dezvoltarea mai ușoară a aplicațiilor grafice. Cele mai multe dintre acestea sunt SharpDX Toolkit, dar există încă o mare parte din ansamblurile principale SharpDX.

Acest cod inutil pare să provină din trei locații principale:

  1. Lucruri suplimentare de matematică care au fost aduse la adăugarea bibliotecii de matematică SlimDX. Acestea sunt tipuri care pot fi utile pentru matematica 3D, dar care nu sunt niciodată utilizate de niciunul dintre ansamblurile de legare. (Exemplu: unghi)
  2. Cod utilitar care servește utilizări interne restrânse pentru Toolkit. (Exemplu: TaskUtil)
  3. Cod general de utilitate pentru a ușura anumite lucruri (Exemplu: RandomUtil)

De exemplu, următoarele fișiere nu sunt necesare pentru construirea și utilizarea legărilor SharpDX:

S-ar putea să fie mai multe, dar acestea sunt ceea ce am găsit în timp ce slăbeam SharpDX pentru propriul meu proiect. Am stabilit mai mult sau mai puțin acest lucru printr-o combinație a instrumentului „Găsiți toate referințele” din Visual Studio și eliminând + re-adăugând lucruri în timp ce construiți pentru fiecare platformă țintă. Am eliminat, de asemenea, o mare parte din interdependențele dintre biții bibliotecii matematice și orice folosind serializarea pur și simplu pentru a face lucrurile oase goale.

Propunerea mea ar fi:

  • Mutați toate structurile/clasele legate de matematică într-un ansamblu SharpDX.Math. (Continuarea utilizării potențiale a namespce-ului SharpDX pentru a preveni ruperea aplicațiilor tatălui decât o referință bibliotecă lipsă.)
  • Mutați serializarea într-un ansamblu separat. (Acest lucru s-ar putea să nu fie foarte realist, dar ar fi bine să includeți o bibliotecă de legare DirectX fără a obține, de asemenea, o bibliotecă de serializare.)
  • Mutați utilitățile Direct3D într-un ansamblu separat. (Păstrați lucrurile grafice separate.)
  • Mutați clasele multimedia într-un ansamblu separat. (Păstrați lucrurile audio separate.)
  • Mutați toate lucrurile generale de utilitate în SharpDX.Toolkit.Utilities
  • Mutați lucrurile mai potrivite pentru toolkit (SharpDX.Windows) în noua bibliotecă Toolkit.
  • Separați setul de instrumente într-un depozit complet separat (similar cu modul în care mostrele sunt complet separate.)

Motivațiile personale principale pentru acest lucru sunt:

  • Pentru a îmbunătăți consistența diviziei SharpDX/Toolkit
  • Scoateți bagajele inutile din ansamblul de bază. (Deci, de exemplu, puteți utiliza DirectX11 fără un ansamblu care include, de asemenea, o grămadă de lucruri audio.)
  • Îmbunătățiți separarea intereselor în baza de cod.
  • Faceți-o astfel încât un proiect să poată integra SharpDX mai ușor fără a utiliza biblioteca matematică SharpDX. (Aceasta este cea mai mare motivație a mea, principalul beneficiu al acestui lucru este pentru motoarele de jocuri pe mai multe platforme care nu doresc să se bazeze pe o altă implementare matematică. Din păcate, C # nu vă lasă să fudgeți acest lucru folosind proiecte hacky precum SharpDX: Culoare * c = (SharpDX: Culoare _) (void _) & myColorThatHasSameMemoryLayout; deci nu există proiecte „gratuite”.)

Cred că obiectivul general este de a face SharpDX mai mult dintr-o legare gestionată direct de DirectX, mai degrabă decât „legarea gestionată DirectX (Și mai mult!)” Că este chiar acum.

Încă o dată, nu postez acest număr, deoarece încerc să vă spun cum să vă întrețineți biblioteca. Îl postez pentru că, dacă este ceva ce doresc întreținătorii principali, sunt dispus să depun mai mult efort în „a face bine”, mai degrabă decât să-mi fac propriul furcul personalizat al SharpDX.

TL; DR: Ansamblul principal SharpDX vă asigură o mulțime de greutăți inutile, îl reduc în scopuri proprii și vreau să știu dacă există interes ca acest lucru să fie făcut în repo-ul principal.

Textul a fost actualizat cu succes, dar s-au întâlnit aceste erori:

xoofx comentat 26 mai 2014

Vă mulțumim pentru feedback-ul dumneavoastră!

Într-adevăr, aproape tot ceea ce faceți referire a existat de câteva ori (unele părți au fost în discuții pe skype/e-mail cu @ArtiomCiumac, alte părți sunt probleme binecunoscute pe care le am în cap) și au fost de fapt parțial programate pentru acest an, doar că nu am avut timp să începem această refactorizare mare sau chiar să le împărtășim aici, așa că, dacă sunteți dispus să ajutați cu această refactorizare, aș fi bucuros să inițiez procesul. Propunerea dvs. este binevenită!

De asemenea, am avut în acest an planul de a face SharpDX să fie compatibil cu PCL, deci este foarte legat de această refactorizare mare.

Pentru fundal, sunt de acord că SharpDX a crescut puțin în afara limitelor sale inițiale. Multe dintre lucrurile care se află în bibliotecă au provenit și din designul SlimDX, mai ales pentru că am vrut să am o anumită compatibilitate înapoi cu această bibliotecă și, de asemenea, a ajutat la bootstrap-ul proiectului (cum ar fi portul SlimMath) Deși SlimDX a fost o grăsime mare asamblare, am vrut să o împart și să o decupez. Acestea fiind spuse, urăsc să gestionez un ansamblu suplimentar doar pentru a decupla lucrurile pentru a stoca doar 3-4 clase în acest nou ansamblu, așa că dacă am putea evita un astfel de caz, aș fi fericit. Setul de instrumente a adus, de asemenea, un anumit cod inutil la ansamblul de bază (serializare și unele matematici de utilizare). Multimedia nu este ideal. Direct3D nu este o problemă uriașă aici, deoarece este doar 2-3 clase, dar ar putea fi într-adevăr mutat într-un ansamblu direct Direct3D. etc. Aș putea discuta despre acest lucru ore în șir, așa că mă bucur că ai ocazia să ajute aici.

La Silicon Studio, am copiat din nou cursurile de matematică de la SharpDX în propriile noastre ansambluri (un ansamblu SliconStudio.Mathematics), așa că văd pe deplin îngrijorarea dvs. cu privire la duplicare.

Mutați toate structurile/clasele legate de matematică într-un ansamblu SharpDX.Math. (Continuarea utilizării potențiale a namespce-ului SharpDX pentru a preveni ruperea aplicațiilor tatălui decât o referință bibliotecă lipsă.)

Da. Am avut proiecte grozave pentru matematică (în principal pentru a aduce niște interoperabilități native de matematică pentru a accelera lucrurile), dar lipsa de timp nu m-a ajutat să împing lucrurile aici. Există unele considerații pentru a integra ulterior următorul SIMD .NET în ansamblul Math, deci acest lucru va necesita o anumită refactorizare atunci când .NET SIMD va fi cu adevărat gata. Deci, în general, sunt de acord că, dacă putem face separarea, ar fi mai bine. Nu mă deranjează nici măcar să schimb spațiul de nume. Există câteva lucruri care ar putea fi făcute pentru a evita chiar utilizarea SharpDX.Math în unele situații. De exemplu, dacă o metodă ia un parametru precum Color4 sau Vector4, putem oferi doar o metodă care va lua un generic și doar verificăm dacă acest generic are 16 octeți (și explicăm în document că tipul așteaptă să aibă 4 plutește în interior). A fost realizat într-o parte a codului SharpDX. Este mai problematic pentru unele ansambluri care utilizează aceste tipuri ca struct de câmp, dar am putea încerca să găsim o soluție acolo. Dacă am putea evita complet ansamblul SharpDX.Math pentru DXGI/D3DCompiler/D3D11, ar fi deja minunat. Pentru alte ansambluri vechi (Direct3D9, Direct3D10. Etc.), nu ar trebui să ne deranjăm.

Mutați serializarea într-un ansamblu separat. (Acest lucru s-ar putea să nu fie foarte realist, dar ar fi bine să includeți o bibliotecă de legare DirectX fără a obține, de asemenea, o bibliotecă de serializare.)

Sunt de acord. Serializarea a fost un hack rapid pentru a putea serializa date în Toolkit, astfel încât să putem muta clase în ansamblul SharpDX.Toolkit. Din păcate, designul a fost cam murdar de la început, deci există o cuplare puternică între tip și serializator (deci toate matematica, de exemplu, îl folosesc), dar acest lucru ar trebui să fie ușor de gestionat pentru a avea serializatori în afara tipurilor și pentru a le înregistra. la o fabrică în schimb.

Mutați utilitățile Direct3D într-un ansamblu separat. (Păstrați lucrurile grafice separate.)

Nu sunt complet mulțumit de acest lucru, deoarece ar necesita crearea unui ansamblu SharpDX.Direct3D pentru doar 2-3 clase. dar bine, de ce nu.

Mutați clasele multimedia într-un ansamblu separat. (Păstrați lucrurile audio separate.)

Da. Există câteva dependențe pe care ar trebui să le eliminăm (De exemplu, D3DCompiler folosește doar un mic decodor FourCC, dar am putea elimina această dependență).

Mutați toate lucrurile generale de utilitate în SharpDX.Toolkit.Utilities

Da, deși majoritatea metodelor sunt utilizate nu de Toolkit, ci de stratul interop din SharpDX, dar nu există nicio problemă să le împărțiți.

Mutați lucrurile mai potrivite pentru toolkit (SharpDX.Windows) în noua bibliotecă Toolkit.

Hm, nu este strict legat de Toolkit, deci ar trebui să rămână în propriul ansamblu SharpDX.Windows. O mulțime de eșantioane în SharpDX ar necesita în continuare să utilizați o fereastră, fără a utiliza setul de instrumente.

Separați setul de instrumente într-un depozit complet separat (similar cu modul în care mostrele sunt complet separate.)

Da. Setul de instrumente accesează anumite elemente interne din ansamblurile de bază, deci s-ar putea să fie nevoie să expunem aceste elemente interne (dar este bine).

Un lucru este să verificați dacă toate platformele se dezvoltă bine. Atâta timp cât faceți acest lucru pentru toate refacerile majore, va fi bine.

De asemenea, totul ar trebui să păstreze întregul istoric al git (folosind subarborele git. Etc.), așa că aș prefera probabil să configurez o ramură cu o curățare inițială brută a ansamblurilor, astfel încât, dacă doriți să intrați în detalii, veți putea să ajuta acolo. Ce crezi?