Почему автор считает что случайная генерация карт в шутерах это технически не сложно? На мой взгляд генерация карты в которую будет приятно и интересно играть довольно сложная задача. Есть весьма реальные риски что качество некоторых генерируемых карт будет отвратительным.
P.S. В том же CS Source была случайность в виде закрытых дверей/проходов, но популярности это особо не дало.
Sketch дешевле чем Photoshop, основная задача быстро и красиво делать наборы макетов, которые после нескольких итераций будут утверждены. Условно говоря заказчику понравился надцатый вариант, и только после этого можно верстать, разбивать на компоненты и т.д. Переделывать макет в дизайн проге, которая векторный и растровый редактор проще и быстрее, чем менять вёрстку.
Даже так — менять вёрстку и компоненты потом настолько накладно, что это нормально выкинуть несколько вариантов макета в корзину, но точно убедиться, что от заказчика потом правок больше не будет (ха-ха).
Кстати на этапе дизайна все может и закончиться, до вёрстки дело не дойдет.
В вашей непрерывной последовательной последовательности перевода пропущен абзац с числами 30 и 500 000 000 на который осталась ссылка. А там, между прочим, на оригинального автора снизошло озарение, что идентификатор и дата связаны. Поэтому можно использовать бинарный поиск, который далее в статье и расписывается.
Признаю что RTSR тут выглядит чётче, но насколько он стабилен? Например если сместить изображение от сетки на пиксель вправо/влево или вверх вниз. Артефактов нет?
Может просто неудачно подобрано, но местами выглядит хуже, чем стандартный фильтр Ланцоша. И вообще идея универсального увеличителя на мой взгляд обречена на провал, так как в низком разрешении дерево, обои, одежда или даже часть лица персонажа выглядят похоже, а при увеличении обладают абсолютно разными деталями. Соответственно сначала нужно корректно классифицировать объект, затем уже на основании выборки объектов заданного типа воссоздавать детали. А это довольно сложная задача.
По заголовку думал что статья про HTML Canvas чтобы нарисовать горизонтальную или вертикальную линию толщиной в один пиксель. С целочисленными координатами антиалиасинг делает блеклые линии толщиной в два пикселя. И это правильно и логично, если подумать :)
Я думаю что поскольку ребро получается в результате пересечения двух плоскостей, то две нормали к поверхностям как дополнительные атрибуты вершины позволят вычислить нужный цвет линии. Но это уже вершинный шейдер — раньше его не было.
Раньше похожий эффект делали с помощью прорисовки линиями поверх треугольников с помощью glPolygonOffset без дополнительного буфера и постобработки. Интересно было бы сравнить.
Думаю эта "фича" относится скорее к линтеру с автоисправлением, а вот в компиляторе ее быть не должно, так как это не стандартное поведение, которое создаст проблему при смене компилятора.
Поскольку это юбилейное издание, возможно стоит взять за основу оригинальную обложку 1975 года, ведь книга прошла проверку временем, а обложки переводов на русский по моему все были разношёрстные и не связанные.
Почему вы считаете разработку нового языка программирования великой стройкой коммунизма?
Есть генераторы лексических и синтаксических анализаторов, прицепить к LLVM и новый язык готов :)
Какую современную проблему решит или научные знания даст создание нового языка?
Спасибо автору за статью.
Напомнила студенческие годы.
В библиотеке OpenGL для Windows лет этак 20 назад была функция wglUseFontOutlines. Когда-то даже игрался с ней году в 2003м. Исходный код может быть есть в Wine, тесселятор там из GLU.
Тогда по логике дефферед начинается с форварда и без него существовать не может. Просто сейчас начальный форвард стал проще, а тяжёлые шейдера отрабатывают после него. Дефферед же по сути надстройка поверх форварда?
Можно как-то детальнее пояснить про форвард? В моем понимании преобразование координат и растеризация никак по-другому и не работает, как можно без него заполнять буфера?
Он гарантирует точность при фиксированном числе операций без использования LUT, и 12 бит точности не такие уж и накладные для 32х битного процессора на мой взгляд.
Почему автор считает что случайная генерация карт в шутерах это технически не сложно? На мой взгляд генерация карты в которую будет приятно и интересно играть довольно сложная задача. Есть весьма реальные риски что качество некоторых генерируемых карт будет отвратительным.
P.S. В том же CS Source была случайность в виде закрытых дверей/проходов, но популярности это особо не дало.
Sketch дешевле чем Photoshop, основная задача быстро и красиво делать наборы макетов, которые после нескольких итераций будут утверждены. Условно говоря заказчику понравился надцатый вариант, и только после этого можно верстать, разбивать на компоненты и т.д. Переделывать макет в дизайн проге, которая векторный и растровый редактор проще и быстрее, чем менять вёрстку.
Даже так — менять вёрстку и компоненты потом настолько накладно, что это нормально выкинуть несколько вариантов макета в корзину, но точно убедиться, что от заказчика потом правок больше не будет (ха-ха).
Кстати на этапе дизайна все может и закончиться, до вёрстки дело не дойдет.
В вашей непрерывной последовательной последовательности перевода пропущен абзац с числами 30 и 500 000 000 на который осталась ссылка. А там, между прочим, на оригинального автора снизошло озарение, что идентификатор и дата связаны. Поэтому можно использовать бинарный поиск, который далее в статье и расписывается.
Признаю что RTSR тут выглядит чётче, но насколько он стабилен? Например если сместить изображение от сетки на пиксель вправо/влево или вверх вниз. Артефактов нет?
Может просто неудачно подобрано, но местами выглядит хуже, чем стандартный фильтр Ланцоша. И вообще идея универсального увеличителя на мой взгляд обречена на провал, так как в низком разрешении дерево, обои, одежда или даже часть лица персонажа выглядят похоже, а при увеличении обладают абсолютно разными деталями. Соответственно сначала нужно корректно классифицировать объект, затем уже на основании выборки объектов заданного типа воссоздавать детали. А это довольно сложная задача.
Почему приведенная реализация Rank1 имеет логарифмическую сложность? На вид линейная, явный же цикл.
По заголовку думал что статья про HTML Canvas чтобы нарисовать горизонтальную или вертикальную линию толщиной в один пиксель. С целочисленными координатами антиалиасинг делает блеклые линии толщиной в два пикселя. И это правильно и логично, если подумать :)
Я думаю что поскольку ребро получается в результате пересечения двух плоскостей, то две нормали к поверхностям как дополнительные атрибуты вершины позволят вычислить нужный цвет линии. Но это уже вершинный шейдер — раньше его не было.
Раньше похожий эффект делали с помощью прорисовки линиями поверх треугольников с помощью glPolygonOffset без дополнительного буфера и постобработки. Интересно было бы сравнить.
https://www.shadertoy.com/view/XstGRf
Думаю эта "фича" относится скорее к линтеру с автоисправлением, а вот в компиляторе ее быть не должно, так как это не стандартное поведение, которое создаст проблему при смене компилятора.
Поскольку это юбилейное издание, возможно стоит взять за основу оригинальную обложку 1975 года, ведь книга прошла проверку временем, а обложки переводов на русский по моему все были разношёрстные и не связанные.
Пример с концентрическими кругами и анимацией вполне можно попробовать реализовать на одном лишь CSS вообще без JavaScript.
Почему вы считаете разработку нового языка программирования великой стройкой коммунизма?
Есть генераторы лексических и синтаксических анализаторов, прицепить к LLVM и новый язык готов :)
Какую современную проблему решит или научные знания даст создание нового языка?
Спасибо автору за статью.
Напомнила студенческие годы.
В библиотеке OpenGL для Windows лет этак 20 назад была функция wglUseFontOutlines. Когда-то даже игрался с ней году в 2003м. Исходный код может быть есть в Wine, тесселятор там из GLU.
Тогда по логике дефферед начинается с форварда и без него существовать не может. Просто сейчас начальный форвард стал проще, а тяжёлые шейдера отрабатывают после него. Дефферед же по сути надстройка поверх форварда?
Можно как-то детальнее пояснить про форвард? В моем понимании преобразование координат и растеризация никак по-другому и не работает, как можно без него заполнять буфера?
Он гарантирует точность при фиксированном числе операций без использования LUT, и 12 бит точности не такие уж и накладные для 32х битного процессора на мой взгляд.
А вы пробовали вычислять квадратный корень через разложение в ряд Тейлора ?
Можно подробнее про массивы переменной длины в С, VLA что ли?
В C++ есть std::vector, да.