Не то, что классы, а даже интерфейсы)
Но все же под C++ подразумевают многие не С с добавкой ООП.
Вообще предлагаю не начинать дискуссию на эту тему. Все таки, статья посвящена написанию вычислительного шейдера и автор был намерен сосредоточиться на этом вопросе.
А вы давно на «C++» пишете?
Советую не учится плохим вещам из MSDN (например, тот же NULL) и вообще не использовать препроцессор для создания констант.
Пример все же был бы лучше, если отсортированные данные не только бы записывались в файл.
Выводим: lower_bound по нижней границе возраста по всему диапазону данных и lower_bound по верхней границе возраста и в диапазоне от результата первого поиска и до конца исходного диапазона.
Преимуществом того, что данные отсортированы, стоит воспользоваться)
Более того, у вас уже есть comparator (хотя для lower_bound понадобится иной)
Меня это также озадачило во время прочтения статьи.
Сейчас даже накладно делать пули физ. объектами, ибо тогда необходимо повышать частоту обновления физики, либо иметь CCD (continuous collision detection), которое также очень накладное и сложное в реализации. А во время DOOM так тем-более было не выгодно, да и симуляция физики еще в зачатке была.
Можете почитать новости этой индустрии с 2010-ого года)
Если вкратце, AMD были очень возмущены в свое время действиями Nvidia и еще давным давно в Bullet добавлялась поддержка OpenCL за счет AMD.
Это даже еще 2009-ый был: nvworld.ru/news/new-449
Тут об этом также можно почитать: ru.m.wikipedia.org/wiki/PhysX
У Havok была очень странная поддержка GPU, при условии, что под физику эффектов (конкретно эффектов, а не геймплейной физики) отдавался второй графический процессор, который должен был вообще быть в устройстве.
От себя добавлю, что он также вне конкуренции.
Havok — проприетарный, имеет более низкую производительность, не имеет поддержки физики твёрдых тел на GPU и не имеет поддержки частиц из коробки (хотя и в PhysX частицы объявлены устаревшими, вместе с одеждой и разрушениями), но при этом, конечно, гораздо читабельнее PhysX и Bullet.
Bullet — открытый, популярный, но опять-таки не столь оптимизирован, как PhysX и не такой удобный в использовании, как PhysX и Havok (чисто моё мнение). При том, что ключевой разработчик Bullet работал в своё время над Havok.
ODE, React3D и прочие трёхмерные движки уже можно и не учитывать.
Насчёт Unity: открытая часть, как по мне, самая бесполезная из всего движка.
Насчёт PhysX: я сомневаюсь что кто-либо вообще тронется как-то работать над движком. Исходный код движка большую ценность несёт для тех, кто занимается конкретно real-time физикой. Для этого и режима read-only достаточно.
PhysX во многих местах через чур хрупкий. Человек, который не обладает достаточными знаниями о данной системе будет долго и нудно разбираться в местном фен-шуе.
Но все же под C++ подразумевают многие не С с добавкой ООП.
Вообще предлагаю не начинать дискуссию на эту тему. Все таки, статья посвящена написанию вычислительного шейдера и автор был намерен сосредоточиться на этом вопросе.
Советую не учится плохим вещам из MSDN (например, тот же NULL) и вообще не использовать препроцессор для создания констант.
Спасибо)
Выводим: lower_bound по нижней границе возраста по всему диапазону данных и lower_bound по верхней границе возраста и в диапазоне от результата первого поиска и до конца исходного диапазона.
Преимуществом того, что данные отсортированы, стоит воспользоваться)
Более того, у вас уже есть comparator (хотя для lower_bound понадобится иной)
Сейчас даже накладно делать пули физ. объектами, ибо тогда необходимо повышать частоту обновления физики, либо иметь CCD (continuous collision detection), которое также очень накладное и сложное в реализации. А во время DOOM так тем-более было не выгодно, да и симуляция физики еще в зачатке была.
Тут я с вами солидарен) Об этом же выше писал.
Можно более подробно?)
Если вкратце, AMD были очень возмущены в свое время действиями Nvidia и еще давным давно в Bullet добавлялась поддержка OpenCL за счет AMD.
Это даже еще 2009-ый был: nvworld.ru/news/new-449
Тут об этом также можно почитать: ru.m.wikipedia.org/wiki/PhysX
У Havok была очень странная поддержка GPU, при условии, что под физику эффектов (конкретно эффектов, а не геймплейной физики) отдавался второй графический процессор, который должен был вообще быть в устройстве.
От себя добавлю, что он также вне конкуренции.
Havok — проприетарный, имеет более низкую производительность, не имеет поддержки физики твёрдых тел на GPU и не имеет поддержки частиц из коробки (хотя и в PhysX частицы объявлены устаревшими, вместе с одеждой и разрушениями), но при этом, конечно, гораздо читабельнее PhysX и Bullet.
Bullet — открытый, популярный, но опять-таки не столь оптимизирован, как PhysX и не такой удобный в использовании, как PhysX и Havok (чисто моё мнение). При том, что ключевой разработчик Bullet работал в своё время над Havok.
ODE, React3D и прочие трёхмерные движки уже можно и не учитывать.
Ну а насчет коммерческой стороны вопроса — здесь я с вами согласен.
Насчёт PhysX: я сомневаюсь что кто-либо вообще тронется как-то работать над движком. Исходный код движка большую ценность несёт для тех, кто занимается конкретно real-time физикой. Для этого и режима read-only достаточно.
PhysX во многих местах через чур хрупкий. Человек, который не обладает достаточными знаниями о данной системе будет долго и нудно разбираться в местном фен-шуе.
Я год как занимаюсь физ. движком.
По производительности он уже шустрее Box2D.
P.S. не сразу понял, что вы веткой промахнулись…
Чистый рэйкастинг. С большим количеством геометрии(> 2000) работает отлично