Я уже привел этот аргумент. Да и вообще, есть ли смысл что-то рассуждать о компании, когда для того, чтобы писать нативные приложения для их собственной ОС приходится юзать сторонние библиотеки (Qt).
> Так что вы либо не в теме, либо из тех, кто любит ругать компанию не аргументированно.
Я бы не стал переходить на личности. Я же не говорю, что Вы человек, которого за зарплату посадили пиарить микрософт, а значит любая аргументация и споры с таким человеком в принципе бессмысленны.
Это какие такие принципы? Можно конкретики? Что за принципы я должен изучать именно из технологий микрософта, которые гарантированно откинутся, а не где-то еще (в принципе уже сейчас UWP не производит вид живой).
Я только слегка этой темы касался, поэтому могу фигню сморозить. Но я так понимаю — сперва исходник делится на лексемы, а потом токенизация на основе этого (хотя часто лекса и токен одно и тоже). Т.е. просматривается строка посимвольно: видим символ '=' или пробел, значит предыдущая лексема кончилась (так как проблел или = не может быть частью имени переменной), и начинаем собирать символы следующей лексемы. github.com/1vanK/RecursiveDescentParser
Microsoft порождает новые технологии с гигантской скоростью и с такой же скоростью эти технологии умирают, а время, потраченное на их изучение некто не вернет. Связываться с очередным «шедевром инженерной мысли» от микрософта будет только безумец.
Мне надо внутри функции комментировать линии и возле некоторых поставить имя картинки. И на выходе получить исходник с комментариями и картинками в каком-то формате (html, markdown без разницы), чтобы все это можно было нормально читать. Я так понял, \code и \endcode требуют скопировать всю функцию в комментарий, что дико неудобно.
> но вы уверены, что Doxygen подходящий инструмент для решения вашей задачи?
мне любой инструмент подойдет, который поможет, но doxygen имеет всякие полезные фичи, так что при прочих равных я бы предпочел его
Я бы хотел пояснить сложный код картинками. Пробую для этой цели doxygen. Нашел как вставить картинку, нашел как вставить исходник в документацию (INLINE_SOURCES). Но в документации получается, что в начале все комментарии и картинки, а потом исходник с вырезанными комментарии. Возможно ли сделать так, чтобы комментарии и картинки были расположены между строк исходника?
roughness, albedo в PBR это такая же карта, как карта нормалей. Никому в голову не придет искать какое-то другое слово, чтобы заменить «карта нормалей». Ваша претензия напоминает человека, который прочитал статью по математике: «у вас тут в статье корни и интегралы какие-то, неужели нельзя было нормальным языком написать, вместо того, чтобы я лез в справочник и узнавал, что это такое». Я бы такому человеку просто посоветовал бы не читать статьи по математике.
> Заметьте, что я всего лишь преобразовал порядок двух строк кода — см. вышеупомянутую статью Ханну.
Я построил графики от фпс и если переставить строки, то проблема инвертируется. То есть при низком фпс скорость будет возрастать быстрее, чем надо. И только если точно следовать методу Ханну (два раза по половинке) то все нормально.
Кстати текстура со всеми мип уровнями занимает больше памяти, чем текстура без мип уровней всего на треть, так что все эти «уникальные» текстуры дума никаких проблем не вызывали бы при обычном подходе. Просто они не могли сделать игру без своей технологии, которая является главной его фишкой.
Ну про освещение и PBR конечно не в тему. Но вот как раз ради уникальности — таки да. Смысл в том, чтобы уместить в видеопамяти только нужные mip уровни тысяч текстур вместо того, чтобы размещать в видеопамяти сотню текстур, но со всеми mip уровнями.
Но вот беда, что все эти теоретически разные текстуры как раз выглядят одинаково. Никто не оплатит художнику 10 лет труда, чтобы он рисовал везде разные решетки и травинки. Он просто натянет одну и туже текстуру то, там то тут. В итоге выглядит так же, но с дополнительными косяками.
И если уж авторы технологии не смогли сделать нормально, а больше никто эту технологию и не использует, то проблема возможно в самой технологии (ну не так просто быстро постоянно пересылать данные в видеопамять, вместо того, чтобы сразу загрузить все необходимое).
Возможно Вы что-то другое имеете в виду? Потому что LOD не генерируются на лету, а все заранее сгенерированные mip-уровни хранятся в dds-текстуре (обычно)
Мегатекстура — это когда смотришь налево — загружаются текстуры, смотришь направо — загружаются текстуры, и неоправданно гигантский размер ресурсов игры.
Мб задумка и хорошая — типа уникальный вид каждого уголка мира, но это экономически невыгодно и в итоге все равно все сводится к натянутым везде одинаковым текстурам + дополнительные артефакты.
Я уже привел этот аргумент. Да и вообще, есть ли смысл что-то рассуждать о компании, когда для того, чтобы писать нативные приложения для их собственной ОС приходится юзать сторонние библиотеки (Qt).
Я бы не стал переходить на личности. Я же не говорю, что Вы человек, которого за зарплату посадили пиарить микрософт, а значит любая аргументация и споры с таким человеком в принципе бессмысленны.
Это какие такие принципы? Можно конкретики? Что за принципы я должен изучать именно из технологий микрософта, которые гарантированно откинутся, а не где-то еще (в принципе уже сейчас UWP не производит вид живой).
github.com/1vanK/RecursiveDescentParser
А вообще перерывами читаю книгу linux-doc.ru/programming/assembler/book/compilers.pdf. Кажется достойной.
> но вы уверены, что Doxygen подходящий инструмент для решения вашей задачи?
мне любой инструмент подойдет, который поможет, но doxygen имеет всякие полезные фичи, так что при прочих равных я бы предпочел его
> Docco
Эта штука для javascript? Просто мне для c++
Я построил графики от фпс и если переставить строки, то проблема инвертируется. То есть при низком фпс скорость будет возрастать быстрее, чем надо. И только если точно следовать методу Ханну (два раза по половинке) то все нормально.
Ну про освещение и PBR конечно не в тему. Но вот как раз ради уникальности — таки да. Смысл в том, чтобы уместить в видеопамяти только нужные mip уровни тысяч текстур вместо того, чтобы размещать в видеопамяти сотню текстур, но со всеми mip уровнями.
Но вот беда, что все эти теоретически разные текстуры как раз выглядят одинаково. Никто не оплатит художнику 10 лет труда, чтобы он рисовал везде разные решетки и травинки. Он просто натянет одну и туже текстуру то, там то тут. В итоге выглядит так же, но с дополнительными косяками.
И если уж авторы технологии не смогли сделать нормально, а больше никто эту технологию и не использует, то проблема возможно в самой технологии (ну не так просто быстро постоянно пересылать данные в видеопамять, вместо того, чтобы сразу загрузить все необходимое).
Возможно Вы что-то другое имеете в виду? Потому что LOD не генерируются на лету, а все заранее сгенерированные mip-уровни хранятся в dds-текстуре (обычно)
Разделяющая ось всегда одномерная (т.е. линия), даже для 3D, поэтому проецировать надо на линию, а не на плоскость en.wikipedia.org/wiki/Hyperplane_separation_theorem#Use_in_collision_detection
www.youtube.com/watch?v=YeX-20DAA0I
Мб задумка и хорошая — типа уникальный вид каждого уголка мира, но это экономически невыгодно и в итоге все равно все сводится к натянутым везде одинаковым текстурам + дополнительные артефакты.