Комментарии 17
Напомнило, как в студенчестве (начало 90х) делал прогу на Си с кучей матана, которая рисовала нечто, напоминающее сосновую ветку с игрушкой (а-ля новогод). И все это крутилось под стандартной борландовской egavga.bgi, работало не сказать что сильно быстро (математик из меня так себе).
Потащил ее на местечковый конкурс (уж дюже был горд собою, что сумел в матан). Но на конкурсе были два ботана, которые притащили две крутейших проги, целиком на ассемблере, которые рисовали какую-то симпатичную геометрию о 256 цветах и даже с некоторым подобием антиалиасинга.
Короче, в список призеров я не попал :)
Потащил ее на местечковый конкурс (уж дюже был горд собою, что сумел в матан). Но на конкурсе были два ботана, которые притащили две крутейших проги, целиком на ассемблере, которые рисовали какую-то симпатичную геометрию о 256 цветах и даже с некоторым подобием антиалиасинга.
Короче, в список призеров я не попал :)
DirectX? Вы серьезно?
API используемый на одной единственной платформе в 2018 году? Хмм…
API используемый на одной единственной платформе в 2018 году? Хмм…
Я написал о том API, с которым у меня получилось добиться наибольшей производительности. OpenGL и Vulkan в моей реализации показали фреймрейт на 30% хуже, из чего я сделал вывод, что с ними у меня не получилось разобраться на достаточном уровне.
К тому же, подробные «пошаговые» статьи про другие API мне также не удалось найти, возможно, их написание ещё имеет смысл (а возможно, плохо искал)
К тому же, подробные «пошаговые» статьи про другие API мне также не удалось найти, возможно, их написание ещё имеет смысл (а возможно, плохо искал)
OpenGL и Vulkan в моей реализации показали фреймрейт на 30% хуже, из чего я сделал вывод, что с ними у меня не получилось разобраться на достаточном уровне.
Ещё бы, когда API пилится столько лет под одну и ту же платформу, фирмой разработчиком этой платформы. Было бы странно ожидать другой результат.
К тому же, подробные «пошаговые» статьи про другие API мне также не удалось найти
Первая же ссылка в гугле Learn OpenGL
Первая же ссылка в гугле Learn OpenGL
Я неправильно выразился. Имел ввиду именно статьи, аналогичные этой, где подробно описывается простое применение вычислительного шейдера.
К тому же LearnOpenGL описывает OpenGL 3.3, а вычислительные шейдеры официально добавлены в спецификацию в OpenGL 4.3
DirectX? Вы серьезно?
API используемый на одной единственной платформе в 2018 году? Хмм…
А что не так? Использовать API под наиболее распространённую платформу вполне нормальное решение. Особенно если учесть что DX намного удобнее GL или Vulkan (имхо конечно, но на протяжении 9 лет что я работаю с графикой я по прежнему отдаю предпочтение DX)
Использовать API под наиболее распространённую платформу вполне нормальное решение
Мобильные устройства учитываете? Какой там API? Какова доля мобильных устройств в сравнении и десктопом? Каков оборот на рынке мобильного геймдева?
Возьмем рынок игровых консолей. Да Xbox One использует directx. А PS4 и Nd swith — не используют.
Какой смысл использовать для новых проектов API, имеющий хождение только на десктопах и одной, не самой популярной консоли? При этом совершенно не портируемый ни под что другое? В эпоху когда кроссплатформенность это маст хэв для нормального проекта. Я не вижу логики
Мобильные устройства учитываете?
Нет естественно, речь была только про десктоп.
Возьмем рынок игровых консолей. Да Xbox One использует directx. А PS4 и Nd swith — не используют.
Каждая из консолей использует своё GAPI (PS4 и ND не используют OGL) так что какая разница, DX хотя бы 2 платформы покрывает.
В эпоху когда кроссплатформенность это маст хэв для нормального проекта.
С чего вы взяли что это мастхэв? Большинство ААА игр выпускаются, только под винду (да на другие ос они не заглядывают) и консоли. А мобильные игры и игры под пс в любом случае имеют сильно разные подходи к использованию GAPI так что в большинстве случаев без разницы какое GAPI используешь все равно придётся всё переписать.
Так что нету на данный момент поистине кросплатформенного GAPI, поэтому я буду выбирать то что удобнее.
К тому же OGL больше не развивается, расширения не угадаешь где работают нормально а где бажат безбожно. Альтернатива конечно вулкан, но он ещё более геморный по сравнению с DX. Писать на OGL в сравнении с DX это всё равно что писать на С вместо С# при том что C# в данном случае быстрее. Да кросплатформенно но очень неудобно.
Я может невнимательно смотрел, но это не C++.
__uuidof(...)Вас это смутило?
вы к тому, что это больше на чистый С похоже?
А то что в DirectX почти всё это классы и вызовы методов вас не смутил?
А вы давно на «C++» пишете?
Советую не учится плохим вещам из MSDN (например, тот же NULL) и вообще не использовать препроцессор для создания констант.
Советую не учится плохим вещам из MSDN (например, тот же NULL) и вообще не использовать препроцессор для создания констант.
В данном случае невозможно выразить NUMTHREADS через константу, т.к. [numthreads(...)] принимает только литералы. Чтобы эта константа была определена в одном месте (а используется она в шейдере и в вызывающем коде), использовал #define — очень редкая ситуация, в которой можно попытаться оправдать макрос. PARTICLE_COUNT задефайнен для единообразия.
На счет NULL или nullptr здесь не уверен, вероятно, Вы правы.
Оценку своего опыта в плюсах давать не рискну, т.к. этот опыт делится на олимпиадные задачи, мелкие проекты по типу приведенного в статье и заброшенные незавершенные проекты (в основном попытки создания игр). Если же интересует именно время — примерно с 2013.
Вот настоящий, современный С++17.
ps: Надо было сразу на vulkan делать что бы как-то усложнить задачу.
ps: Надо было сразу на vulkan делать что бы как-то усложнить задачу.
Увы, мое решение на Vulkan показывает низкую производительность (наверняка найдется множество ошибок, которые к этому приводят), и также не отличается красотой кода. Впрочем, последнее исправить проще
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Написание системы попарно взаимодействующих частиц на C++ с использованием DirectX 11