Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Но [в 1990 году] никто не смог сделать то же самое на IBM PC».
Новые графические карты были известны как карты Enhanced Graphics Adapter (EGA). У них было больше встроенной видеопамяти, что у карт Color Graphics Adapter (CGA)
В 1990-м на родине Кармака «новыми графическими картами» уже были SVGA. Да и (поправьте меня, если ошибаюсь) отрисовка тайлов со скроллом на видеокартах РС уже давно была изобретена. Тем более что тот же EGA имел многостраничный режим отображения, и позволял легко строить изображение в скрытой области видеопамяти, а потом просто активировать его для вывода на экран.
В 1990-м на родине Кармака «новыми графическими картами» уже были SVGA.Что только ухудшило ситуацию: шины ISA и на EGA-графику еле-еле хватало, а уж SVGA до 1992 года (и появления VBus) можно было только «слайд-шоу» изображать. Недаром ещё много лет после этого (примерно так до 1995-1997) большинство диничных игр выпускались под режим 320x200x8bpp (или нестандартный 320x240x8bpp).
Да и (поправьте меня, если ошибаюсь) отрисовка тайлов со скроллом на видеокартах РС уже давно была изобретена.Она, вообще-то, ещё в документации на C64 описана. Инновация в Commander Keenе была относительно небольшой, но результат был фантастический: сочетание тайлов-со-скроллом в стиле C64 с двойной буфферизацией, в результате чего персонажи перстали мерзко мерцать.
Тем более что тот же EGA имел многостраничный режим отображения, и позволял легко строить изображение в скрытой области видеопамяти, а потом просто активировать его для вывода на экран.Это сейчас это «легко», а в те времена без возможности легко найти подробную документацию (имевшаяся официальная не описывала необходимые регистры, а неоффициальная, как несложно догадаться, появилась намного позже)…
Почитайте про Adaptive Tile Refresh — офиально предоставляемых возможностей EGA для этого было совершенно недостаточно.
VGA это Video Graphics Array, а не Adapter
Эх, ностальгия. Помню как я примерно в это-же время придумывал алгоритм быстрой отрисовки плоскостей, что-бы потом написать свою игру. И что самое интересное — придумал. :) На движке для Quake писал дополнения. Сделал крюк с провисающей динамической веревкой, а не уродливые варианты с прямой, которые тогда были распространены. Эх, молодость… :)
Сейчас ведь тоже есть возможность делать нечто подобное — для себя.
Например, опубликовать на Хабре пост с какой-нибудь хитрой задачкой, которую сам уже решил (в стиле кентерберийских головоломок). И смотреть на решения других людей. В следующем посте показать своё решение. И т.п. Думаю, было бы весьма интересно.
P.S. Возможно, такие посты уже были. Но, в любом случае, это могло бы быть доброй интеллектуальной традицией.
Например, опубликовать на Хабре пост с какой-нибудь хитрой задачкой, которую сам уже решил (в стиле кентерберийских головоломок). И смотреть на решения других людей. В следующем посте показать своё решение. И т.п. Думаю, было бы весьма интересно.
P.S. Возможно, такие посты уже были. Но, в любом случае, это могло бы быть доброй интеллектуальной традицией.
Это позволило испускать лучи от игрока только в одной горизонтальной 2D-плоскости [посередине] и масштабировать видимую высоту стены согласно её удалённости от игрока вместо определения каждой отдельной точки стены.… Движок Кармака стал невероятно быстрым
У меня есть давнее подозрение, что заполнение экрана по столбцам вместо строк тоже тогда дало значимый прирост скорости. Похоже было, что построчное заполнение конфликтовало с DMA видеоадаптера и в результате медленнее работало.
Демонстрация возможностей пентиумов на примере вольфа? Какое извращение!
Ну, автор статьи, несмотря на 2002-й год оригинала (10 лет после выхода Wolf3D), допускает столько технических неточностей, что у меня глаза болят.
«10 цветов», «300х200», перепутанные скриншоты (т.е. он в те игры в принципе не играл).
«10 цветов», «300х200», перепутанные скриншоты (т.е. он в те игры в принципе не играл).
А в чём неточности? 16 цветов текста + 8 цветов фона для большинства — это «с десяток цветов» и есть. Разрешение CGA — это действительно 320x200 (а не 320x240, как бы вам этого ни хотелось...) и так далее.
Скриншоты — это да… хотя не факт, что их автор статьи подбирал: во многих журналах «картинки к статье» добавляет другой человек.
Скриншоты — это да… хотя не факт, что их автор статьи подбирал: во многих журналах «картинки к статье» добавляет другой человек.
В статье есть цитата «обычно 300 на 200 пикселей». Непонятно с чего вы взяли, что Wano987 хочет ..x240.
Они построили 3D мир и успокоились на этом. Но ведь можно и разрушать — хотелось бы ещё почитать про разрушаемость того же Battlefield 3-4 и нарезки предметов на части-ломтики мечом в Metal Gear Revengeance.
Это совершенно другое. Разрушаемость — это скорее хранение объектов. А Кармак спец по быстрой прорисовке и визуализации.
Разрушаемость — это не быстрая прорисовка быстро возникшей кучи объектов?
Нет, это возможность хранить в памяти трехмерную карту мира с возможностью ее на ходу менять.
Смотри как было раньше: есть уровень, в нем есть прописанные структуры. И есть отдельные списки или массивы объектов — npc, mobs, items, которые отдельно прорисовываются.
А теперь — весь мир объекты, нет ничего статичного. Каждое место может быть разрушено уникальным способом, и нужно быстро придумать как это сделать, ибо простая стена, может быть описана очень кратко в памяти. А частично разрушенная стена — резко увеличивается в размерах. Плюс сколько проблем может из-за этого быть, поскольку предусмотреть нужно все — как все должно проваливаться, если можно разрушить пол — как и кто проваливается туда.
Опять же, передвижение mob-ов — если при обычных условиях, у тебя могли быть заранее просчитанные вейпоинты, чтобы мобы (особенно квестовые) не «застревали в текстурах», то после частичного нарушения нужно все просчитывать на самом деле, без всякой подстраховки, что на порядок более сложная задача, и я не уверен что решенная.
Смотри как было раньше: есть уровень, в нем есть прописанные структуры. И есть отдельные списки или массивы объектов — npc, mobs, items, которые отдельно прорисовываются.
А теперь — весь мир объекты, нет ничего статичного. Каждое место может быть разрушено уникальным способом, и нужно быстро придумать как это сделать, ибо простая стена, может быть описана очень кратко в памяти. А частично разрушенная стена — резко увеличивается в размерах. Плюс сколько проблем может из-за этого быть, поскольку предусмотреть нужно все — как все должно проваливаться, если можно разрушить пол — как и кто проваливается туда.
Опять же, передвижение mob-ов — если при обычных условиях, у тебя могли быть заранее просчитанные вейпоинты, чтобы мобы (особенно квестовые) не «застревали в текстурах», то после частичного нарушения нужно все просчитывать на самом деле, без всякой подстраховки, что на порядок более сложная задача, и я не уверен что решенная.
простая стена, может быть описана очень кратко в памяти. А частично разрушенная стена — резко увеличивается в размерах.И в полигонах, и внутренние текстуры. Резко возрастает количество объектов для отрисовки.
В том же MGR я таки углядел хитрость — некоторые кусочки медленно исчезают в куче, некоторые становятся единым целым как квантовое сцепление — воздействие передаётся и на вторую, в два раза меньше просчёта физики.
saboteur_kiev
perfect_genius
Кстати да, сложная это тема, может потому и непопулярная. Стоит вспомнить хотя бы опыт Red Faction. С тех пор разрушения только «оптимизировали», упростив до предварительно просчитанных нескольких кусков, но даже сегодня можно увидеть, как девелоперы страдают: скажем, можно понаблюдать эволюцию системы разрушений в долгострое Star Citizen, сейчас там крылья истребителя могут разваливаться на несколько частей хотя бы, в зависимости от точки приложения огня и независимо от других субчастей, а год-два назад вообще было всего 4-5 частей на весь истребитель и это выглядело, как будто модельку связали веревочками, а потом их одновременно разрезали. Кармака на них нет… :)
perfect_genius
Кстати да, сложная это тема, может потому и непопулярная. Стоит вспомнить хотя бы опыт Red Faction. С тех пор разрушения только «оптимизировали», упростив до предварительно просчитанных нескольких кусков, но даже сегодня можно увидеть, как девелоперы страдают: скажем, можно понаблюдать эволюцию системы разрушений в долгострое Star Citizen, сейчас там крылья истребителя могут разваливаться на несколько частей хотя бы, в зависимости от точки приложения огня и независимо от других субчастей, а год-два назад вообще было всего 4-5 частей на весь истребитель и это выглядело, как будто модельку связали веревочками, а потом их одновременно разрезали. Кармака на них нет… :)
И кроме этого, изначальный 3д мир в игре оптимизируется по числу полигонов и объёму текстур не под максмальную загрузку мощностей уже на «статике», а с учётом возможных разрушений, число дроблений у которых, конечно же ограничивается (чтобы не получать резкие проседания на целевой конфигурации ПК). Другими словами, на 100% мощности должна загружать лишь сцена в которой «разрушено всё, что можно». Ну а далее, для целей повышения детализации у ещё не разрушенных объектов уже и начинают применяться техники экономии потребления ресурсов типа «исчезание» сломанных кусочков (через динамический параметр «время жизни» объекта). При таком подходе уже не возникает понятий «резко возрастает число» (и «что с этим дальше делать?»), т.к. ты чётко представляешь и контролируешь максимальную размерность игрового мира и его требований к ресурсам.
Первый Quake был с феноменальной атмосферой! По мрачности мало кто мог составить конкуренцию.
О, да. Для меня таковым атмосферным конкурентом является, пожалуй, только первый Blood) Собственно, раз в пару-тройку лет я перепрохожу Quake, Quake 2, Blood. Забавно, что Кен Сильверман тоже был отличным программистом и создал довольно интересный движок, и Кармак отзывался о Сильвермане весьма лестно advsys.net/ken/carmken.htm
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Магия разработки видеоигр id Software