Войти
ПрограммированиеФорумГрафика

Подскажите хороший туториал по Direct3d11 (4 стр)

Страницы: 1 2 3 4
#45
16:02, 19 янв. 2016

u960
> то ОГЛ сторонники это секта какая то.

Причём тут сторонники ? У человека были необоснованные наезды на GL - я поправил


#46
16:06, 19 янв. 2016

gammaker
> Да, вместе с заголовочными всего 5. Одна пара файлов отвечает за загрузку
> OpenGL ядра и расширений (всякие glew и подобные, которые это делают, я не
> использую), другая - за кроссплатформенную обёртку над контекстом OpenGL. Это
> один класс, который называется GraphicsGL и наследуется от абстрактного
> AGraphics. Он создаёт текстуры, буферы и все остальные сущности и возвращает
> хендлы на них. Он же содержит функции для работы с этими сущностями через их
> хендлы, а также отслеживает текущие стейты.
> Чтобы реализовать DX11, надо просто написать ещё 2 файла (GraphicsDX11.h +
> GraphicsDX11.cpp) с классом GraphicsDX11, унаследованным от AGraphics и
> определить около 50 методов. На этом теоретически DX11 должен быть готов но
> практически не решена проблема шейдеров. Либо придётся все шейдеры
> продублировать на HLSL, либо что-то придумывать с их конвертацией из GLSL. Это
> меня и останавливает от реализации DX11.
Ну, я не удивлён :) Извини, но писать в процедурном стиле я перестал 20 лет назад, когда прогал на асме и qbasic'е.
К тому же обычно в компаниях в код-стайле написано ограничение на длину файла кода. У тебя явно нарушения стиля, либо ты работаешь один и забиваешь на правила. Без обид, но хвастаться тем, что засунул кучу кода в пяток файлов это как минимум странно. Ты хотел показать, что для перехода на другое API придётся править всего 5 файлов (в отличие от 57 у меня), но в данном случае надо бы количество строк сравнивать, согласен?

#47
16:48, 19 янв. 2016

Мизраэль
> Ну, я не удивлён :) Извини, но писать в процедурном стиле я перестал 20 лет
> назад, когда прогал на асме и qbasic'е.
> К тому же обычно в компаниях в код-стайле написано ограничение на длину файла
> кода. У тебя явно нарушения стиля, либо ты работаешь один и забиваешь на
> правила.
Я пишу для себя и у меня свои правила, выработанные с годами личного опыта написания движка. К тому же слепо подчиняться правилам глупо. Нужно рассматривать каждый случай отдельно.
И мой опыт показывает, что для OpenGL такой стиль - это самый правильный вариант. Нельзя просто взять и поделить эту огромную машину состояний на части, когда эти состояния могут меняться в любом месте. Это одна сущность, а значит один класс. Из-за того, что кто-то пытается его поделить, и рождаются срачи по поводу того, что OpenGL говно, потому что в нём неразбериха со стейтами, которые надо каждый раз откатывать назад. У меня такой проблемы просто нет, все стейты в одном месте. Стейты откатывать назад не нужно, потому что класс помнит, куда они установлены. И это позволяет меньше дёргать драйвер. В DX может и попроще с этими стейтами, но уверен, что там этот подход тоже будет намного удобнее.
А вот снаружи этих 5 файлов уже нормальные небольшие классы текстур, буферов, мешей и кучи всего другого, которые внутри себя дёргают методы AGraphics и никак вообще не зависят от GAPI. Пользователю не нужно работать с этим огромным классом, он работает только с удобными ООП классами, отдельными для каждой сущности.

Мизраэль
> хвастаться тем, что засунул кучу кода в пяток файлов это как
> минимум странно. Ты хотел показать, что для перехода на другое API придётся
> править всего 5 файлов (в отличие от 57 у меня)
Я о том, что вся эта куча кода отвечает только за абстракцию от GAPI и ни за что больше. Я их строго разграничил. И не надо править эти файлы, а надо написать полностью новые 3 файла (загрузка расширений в DX не нужна), чтобы автоматически получить движок, поддерживающий сразу два GAPI. Никакая часть кода, специфичного для GL, не понадобится в DX.
Только с различиями в языках шейдеров понадобится разобраться, и это придётся делать уже вне этого класса.


> К тому же обычно в компаниях в код-стайле написано ограничение на длину файла кода.
А какое, например, у вас ограничение? Просто интересно для общего развития. Если бы такое ограничение было у меня, я бы просто разбил файл реализации этого класса на несколько, но класс остался бы одним. Может быть даже я и сам так сделаю, если класс ещё сильнее разрастётся, и станет неудобно с ним работать. Или я таким образом нарушаю правило "один класс - один файл"?

#48
17:18, 19 янв. 2016

gammaker
> Нельзя просто взять и поделить эту огромную машину состояний на части
Состояния как минимум можно сгруппировать и сделать разные стейт-машины для групп.
gammaker
> И не надо править эти файлы, а надо написать полностью новые 3 файла
Наследование в С++ не пробовал? :) Сделал бы абстрактный класс тех же текстур и пару реализаций OGL и D3D.

gammaker
> А какое, например, у вас ограничение? Просто интересно для общего развития.
Когда геймдевом занимался, то было проще 1 класс - 1 файл (на самом деле 2 конечно .h и .cpp). Плюс всякие ограничения и рекомендации, что должно быть в заголовочном, что в файле с кодом. + ещё есть файл с интерфейсом обычно, если класс торчит наружу (а наружу может торчать только интерфейс).
Сейчас я в интерпрайзе, там обычный S.O.L.I.D. на разработку + свой код-стайл на оформление кода.

#49
17:22, 19 янв. 2016

gammaker
> А какое, например, у вас ограничение?
Там есть ограничение 1) по длине строки кода, чтобы нормально помещалась на экране рабочего монитора в студии с открытыми панелями SolutionExplorer. 2) ограничение на длину функции: 1 экран, т.е. нужно иметь возможность видеть всю функцию целиком. 3) из S.O.L.I.D. есть ограничение на то, какие функции могут быть в классе, соответственно примерно определяется их максимальное количество. Именно на длину файла тоже вроде есть ограничение, но я его не помню.  Скорее всего что-то около "менее 1000 строк". Обычно сильно меньше (100-200).

#50
17:24, 19 янв. 2016

gammaker
> Если бы такое ограничение было у меня, я бы просто разбил файл реализации этого
> класса на несколько, но класс остался бы одним
Это скорее всего не прокатит, т.к. нарушается "Single responsibility principle". У тебя получается god-класс.

#51
18:06, 19 янв. 2016

Мизраэль
> Наследование в С++ не пробовал? :) Сделал бы абстрактный класс тех же текстур и
> пару реализаций OGL и D3D.
И зачем плодить абстрактные классы, тем более, когда у меня уже есть нормальный класс текстур, независимый от API? Либо будет несколько классов текстур, что может вызвать путаницу, либо придётся избавляться от моего класса текстур, но тогда будет дублирование функционала.
Это во-первых. А во вторых, куда я вынесу хранение текущего стейта текстур? Текстуре он не принадлежит, значит надо будет всё равно дёргать какой-то центральный объект. И кто вообще будет биндить текстуры? Сама текстура не должна себя биндить, потому что в GL 4.x например появилась функция, которая может разом забиндить много текстур, и она должна работать быстрее.

И то же самое с шейдерами. Даже чтобы поменять uniform, надо для этого забиндить шейдер. Перед отрисовкой надо проверять, забинден ли именно тот шейдер, который надо, а если не тот, то надо биндить другой.

Мизраэль
> там обычный S.O.L.I.D. на разработку
Даже не знаю, что это такое, надо почитать.

Мизраэль
> 1) по длине строки кода, чтобы нормально помещалась на экране рабочего монитора
> в студии с открытыми панелями SolutionExplorer.
У меня часто прототипы функций не помещаются, когда там много параметров типа const ПространствоИмён::ДлинноеИмяКласса&. Но у меня ноут и я шрифт сделал больше, чем по умолчанию. Может у вас на мониторе поместилось бы.

Мизраэль
> Именно на длину файла тоже вроде есть ограничение, но я его не помню.  Скорее
> всего что-то около "менее 1000 строк". Обычно сильно меньше (100-200).
Ну у меня всего три файла, которые больше 1000 строк. Точнее два и один скоро перерастёт - у него 990 строк. Один из файлов - это парсер моего декларативного языка уже превысил 2000 строк. Он как-то незаметно резко разросся и я его собираюсь переделать и отрефакторить. Второй - GraphicsGL.cpp занимает 2280 строк и я пожалуй поделю его на 3-4 части. Но это всё равно будет один класс. Третий, который 990, пусть пока растёт, потому что он на части не делится без костылей типа #include посреди файла, а все его аналоги в сторонних библиотеках, которые я знаю, реализованы тоже в одном файле и превышают 10000 строк кода.


Мизраэль
> Это скорее всего не прокатит, т.к. нарушается "Single responsibility
> principle". У тебя получается god-класс.
Это понятие reponsibility слишком размытое. Всё зависит от рассматриваемого уровня детализации. Я могу сказать, что его responsibility - абстракция от API и тогда вроде бы всё как бы норм.

#52
18:38, 19 янв. 2016

gammaker
> потому что в GL 4.x например появилась функция, которая может разом забиндить
> много текстур, и она должна работать быстрее.

Тесты в студию

#53
21:02, 19 янв. 2016

innuendo
> Тесты в студию
Нет тестов и лень делать. Слова "она должна работать быстрее" я писал по логике, что надо меньше драйвер дёргать. Если бы был подтверждённый результат, я бы не писал слово "должна".

#54
22:32, 19 янв. 2016

slava_mib
> > http://ru.directx.wikia.com/wiki/DirectX_11_шаг_за_шагом
> > http://gameinstitute.ru/uroki-directx-11/
> Вот такую хрень я бы точно читать не советовал. Если надо откуда-то
> скопипастить код - то норм. А вот если надо разобраться (т.е. при условии, что
> изначально ты не знаешь этого всего) - это, конечно, знатный шлак. Хотя про
> ДХ11 вообще крайне мало не шлака среди туторов почему-то, в отличие от того же
> ДХ9, для которого было много толковых док.
Можешь предложить что-то лучше на русском языке? Это хоть что-то для тех у кого с английским туго. Я с этих туториалов начинал разбираться. Потом уже стал смотреть на английском языке. Нередко полезно про одно и тоже на разных ресурсах прочитать, чтобы кое какое представление сложилось. За подробностями назначения функции или структуры обычно в MSDN хожу.

Чем больше читаю этих туториалов, тем чаще приходит мысль, что двиг придется в третий раз серьезно перепиливать :(
#55
22:40, 19 янв. 2016

gammaker
> Если бы был подтверждённый результат, я бы не писал слово "должна".

Заслушаем любителя оптимизаций ? :)

#56
23:15, 19 янв. 2016

innuendo
> Заслушаем любителя оптимизаций ? :)
Это ты про кого? Если про меня, то у меня есть другие более перспективные места для оптимизаций, которые я не успел сделать. Я ещё даже на UBO не перешёл, а судя по всему, установка uniform'ов по одному сажает FPS в 2 раза на AMD у знакомого. У него на AMD Radeon 290X FPS ниже, чем у меня на Intel. У меня на интеле и NVidia видимо это не так много жрёт CPU, и поэтому упирается в GPU.

#57
23:20, 19 янв. 2016

gammaker
> Это ты про кого?

Нет же

> а судя по всему, установка uniform'ов по одному сажает FPS в 2 раза на AMD у
> знакомого

Ты читаешь последние темы ?

#58
23:44, 19 янв. 2016

innuendo
> Ты читаешь последние темы ?
Ну вроде был у вас с Eugene спор про установку uniform в GL и DX, если ты про это. Но там не совсем про производительность вроде было.

Страницы: 1 2 3 4
ПрограммированиеФорумГрафика

Тема в архиве.