Для схуднення SharpDX (основна збірка, а не проект) · Випуск # 398 · sharpdxSharpDX · GitHub

Коментарі

Копіювати посилання Цитувати відповідь

Збудник Давид прокоментував 26 травня 2014 року

По-перше, я прошу вибачення, якщо це вже обговорювалося раніше, або вже триває спроба зробити те, що я описую. Я не міг знайти нічого пов’язаного з цим.

По-друге, я в основному публікую це, оскільки я все одно вношу ці зміни в особисту версію SharpDX. Я подумав, що слід розпочати обговорення, щоб визначити, чи варто вносити зміни таким чином, щоб вони могли в якийсь момент інтегрувати їх в основне сховище SharpDX. Я усвідомлюю, що те, що я пропоную, є дещо суттєвою зміною, але я подумав, що повинен сказати щось на випадок, якщо Олександр вже працює над чимось подібним у Silicon Studio або є загальний інтерес у цьому.

SharpDX рекламує себе як "проект з відкритим кодом, що забезпечує повний API DirectX на платформі .Net". Хоча SharpDX, безумовно, досягає цієї мети, він також постачається з масою програмного коду для полегшення розробки графічних додатків. Більшість із них - набір інструментів SharpDX, але все ще є багато його в основних збірках SharpDX.

Здається, цей непотрібний код надходить із трьох основних місць:

Додаткові математичні матеріали, які були додані при додаванні математичної бібліотеки SlimDX. Це типи, які можуть бути корисними для тривимірної математики, але ніколи не використовуються жодною з зв’язкових збірок. (Приклад: Кут)
Код утиліти, який обслуговує вузьке внутрішнє використання інструментарію. (Приклад: TaskUtil)
Загальний код утиліти, який полегшує певні речі (Приклад: RandomUtil)

Наприклад, такі файли непотрібні для побудови та використання прив'язок SharpDX:

Може бути і більше, але це те, що я знайшов, схудшивши SharpDX для власного проекту. Я більш-менш визначив це за допомогою комбінації інструменту Visual Studio «Знайти всі посилання» та видалення + повторного додавання речей під час створення для кожної цільової платформи. Я також видалив більшу частину взаємозалежностей між бітами математичної бібліотеки та усім, використовуючи серіалізацію просто з метою зробити речі оголеними.

Я пропоную:

Перемістіть усі структури/класи, пов’язані з математикою, у збірку SharpDX.Math. (Потенційно продовжуючи використовувати SharpDX ім'я імені, щоб запобігти злому батьківського додатка, ніж відсутній посилання на бібліотеку.)
Перемістіть серіалізацію в окрему збірку. (Це може бути не надто реалістично, але було б непогано включити бібліотеку прив’язки DirectX, не отримуючи також бібліотеку серіалізації.)
Перемістіть утиліти Direct3D в окрему збірку. (Тримайте графічні матеріали окремо.)
Перемістіть мультимедійні класи в окрему збірку. (Зберігайте аудіо матеріали окремо.)
Перемістіть усі загальні утиліти в SharpDX.Toolkit.Utilities
Перемістіть речі, які більше підходять для набору інструментів (SharpDX.Windows), до нової бібліотеки наборів інструментів.
Відокремте набір інструментів у повністю окреме сховище (подібно до того, як зразки повністю відокремлені).

Мої особисті основні мотиви для цього:

Для подальшої узгодженості розділу SharpDX/Toolkit
Видаліть непотрібний багаж із сердечника. (Так, наприклад, ви можете використовувати DirectX11 без складання, яке також включає купу аудіоматеріалів.)
Посилити поділ інтересів у кодовій базі.
Зробіть так, щоб проект міг легше інтегрувати SharpDX, не використовуючи математичну бібліотеку SharpDX. (Це моя найбільша мотивація, головна перевага цього для крос-платформних ігрових движків, які не хочуть покладатися на іншу математичну реалізацію. На жаль, C # насправді не дозволяє вам обдурити це, використовуючи хакі, як SharpDX: Колір * c = (SharpDX: Color _) (void _) & myColorThatHasSameMemoryLayout; так що ніяких "безкоштовних" трансляцій.)

Я припускаю, що загальна мета полягає в тому, щоб зробити SharpDX більш чистим керованим DirectX, а не "керованим DirectX (і більше!)", Яким він є зараз.

Ще раз, я не публікую цю проблему, тому що намагаюся розповісти вам, як підтримувати вашу бібліотеку. Я публікую це, бо якщо це щось, на що бажають первинні супровідники, я готовий докласти більше зусиль, щоб "зробити це правильно", а не робити власну власну вилку SharpDX.