В мире видеоигр эмуляторы стали настоящей находкой для поклонников классических проектов. PPSSPP — один из самых популярных эмуляторов для PlayStation Portable (PSP), который позволяет нам вновь окунуться в атмосферу любимых игр, но уже на современных устройствах. Однако чтобы играть без сбоев и лагов, нужно убедиться, что код эмулятора хорошо написан.
Итак, теперь у нас есть первая приблизительная оценка видимости листьев из порталов, хранящаяся в массиве mightsee каждого портала. Вычислять, что именно видно через последовательность порталов, сложно, поэтому мы вместо этих вычислений используем «консервативную» оценку. Она ни за что не скроет лист, который должен оставаться видимым.
«Это просто задача отсечения»
Свет внезапно выключается. Вы сидите в огромном конференц-зале. Кто-то включает проектор. На экране сам Майкл Абраш! Похоже, это знаменитый доклад Quake Postmortem с GDC 1997.
Он говорит о порталах.
Мы берём плоскости отсечения, ограничивающие максимальный объём видимого, и отсекаем их по всё более дальним порталам, пока они не пропадут.
Градиентное текстурирование — это методика оптимизации 3D-текстурирования, в первую очередь предназначенная для мобильных видеоигр. В ней используются текстурные карты низкого разрешения и градиентные цвета, позволяющие снизить ресурсную нагрузку на игровые без ущерба качеству графики. Благодаря применению градиентов в низкополигональных 3D-моделях симулируются такие эффекты, как освещение, тени и глубина, позволяя избавиться от необходимости в текстурах высокого разрешения, потребляющих больше ресурсов.
Эта методика обеспечивает эффективный баланс между производительностью и визуальным качеством, оптимизирует время загрузки и улучшает игровой процесс. Кроме того, она позволяет гибко менять цветовые палитры и может адаптироваться под разные 3D-модели, снижая размеры файлов и оптимизируя использование памяти.
C и C++ не имеют встроенной сборки мусора, поэтому разработчик сам решает, как и когда выделять и освобождать память. Мы, конечно, можем покивать в сторону STL, сокрытия аллокаций в контейнерах, но от этого они никуда не денутся. Просто если раньше приходилось думать про выделенный кусок памяти, понимать, как он скажется на времени фрейма, помнить, что его надо удалить (а может, не надо и стоит оставить на следующий фрейм), то теперь всё заворачивается в сахарные контейнеры и разработку в стиле STL-blin-vse-sterpit. STL-то может и стерпит, и даже как-то будет ворочаться, однако не стоит полагаться исключительно на системный аллокатор, бездумно вызывая new или malloc для каждого запроса памяти. Вы ведь понимаете, что std::vector посреди цикла или горячей функции — это плохая идея?
Кроме того, такая практика приводит к ожидаемым проблемам с производительностью даже в обычных приложениях, чего уж говорить про высоконагруженные системы или игры, которые претендуют на что-то быстрее 20 фреймов в секунду.
Пытаться оптимизировать код, который использует системные аллокаторы, — всё равно что сгребать листья в кучу ветреным днём: куча, конечно, сгребается, но постоянно приходится махать грабельками, чтобы она оставалась на одном месте. Даже если выделения памяти происходят последовательно, друг за другом, вот прям без всяких перерывов, нет гарантии, что эти участки будут расположены хотя бы близко друг к другу. В результате при обработке таких данных процессору приходится прыгать по разным участкам памяти, теряя такты просто на поиск данных вместо того, чтобы работать с ними.
Я отнюдь не призываю вас встать на путь ручного управления памятью, ибо он будет усеян ловушками, граблями и чреват утечками. Но разработчик в итоге оказывается перед выбором: либо довериться системному аллокатору и столкнуться с проблемами вроде размазанного перфа, когда вроде и код написан правильно, модно и молодежно, но отчего-то работает небыстро, либо взять всё в свои руки, создавая собственные механизмы выделения и освобождения ресурсов.
Ребята из HFT, Database, Automotive и Embedded-систем наверняка могут рассказать немало интересных историй про оптимизацию new/delete. Давайте я расскажу немного про разные аллокаторы в играх?
Должен признать, у меня есть некая особая любовь к классическому DOOM. Несмотря на то, что игре уже 31 год, в нее все еще весело играть самому (хотя и выходит у меня так себе) или просто смотреть на то, как другие в нее играют (вот в этом я показываю себя лучше); и поскольку исходный код игры открыт, ей можно наслаждаться на любой современной платформе — ПК, смартфон, камера, осциллоскоп — да и вообще на любой вещи, которая придет вам в голову. В результате чего, благодаря ряду обстоятельств, я оказался меинтейнером нескольких связанных с DOOM пакетов в Fedora Linux.
Итак, за несколько месяцев до нового релиза, проект Fedora Linux осуществляет массовую сборку всех пакетов. Это имеет несколько преимуществ — позволяет убедиться в совместимости ABI, обновить статически линкуемые зависимости, использовать новые оптимизации компилятора и так далее. Как бы то ни было, с приближением релиза Fedora Linux 42 в середине апреля, пришло время для массовой пересборки, и как часто бывает, не все пакеты выжили. Одним из пакетов, которые не удалось собрать оказался chocolate-doom.
Мы не удивим наших читателей тем фактом, что на сегодняшний день сфера видеоигр является наиболее динамично развивающейся и перспективной в индустрии развлечений. Гейминг-экспансия приобрела поистине планетарные масштабы благодаря смещению акцента с монопользовательской версии на многопользовательскую, чему способствовало развитие сервисов прямых трансляций, потоковых и кроссплатформенных игр с возможностью онлайн-общения, превратив тем самым игры в полноценные сообщества по интересам и платформы для общения и заработка пользователей со всего мира. По прогнозам аналитиков выручка на игровом рынке в 2025 году достигнет $522,5 млрд, а число игроков — более 3,3 млрд.
Итак, мне удалось дойти до этого момента, и эмулятор начинает писать в неправильную область PPU, что конечно же портит всё выполнение.
Приветствую тебя. Ты, наверное, уже задался вопросом, какой нездоровый на голову человек будет влезать в такие долги при нынешней экономической ситуации в стране, да и в мире в целом. На что он вообще надеется, делая визуальную новеллу, да ещё в пиксель-арте и в советском сеттинге по детским страшилкам? Он что, совсем больной? В целом вопросы справедливы и, возможно, даже диагноз верный. Но давайте взглянем чуточку назад и найдём причинно-следственные связи для столь отчаянного, на первый взгляд, поступка.
Из новостей: разработчики MiSide про 1% с продаж игры, SDL 3, продажи Balatro превысили 5 миллионов копий, экспериментальная поддержка C# в Defold, динамическая разрушаемость с помощью Havok Physics.
Из интересностей: почему на создание Judas Кена Левина ушло 10 лет, как создаются бойцы Super Smash Bros, загадка дыры.
- Чем чревато брать float или double в качестве типа данных для хранения позиций объектов?
- Как это может повлиять на наличие багов в игре и ошибки синхронизации сетевой игры или реплеев?
Об этом вы узнаете в этом гайде с наглядными гифками и пруфом на C++
У меня за плечами несколько лет работы в IT, но в сферах, связанных с геймдевом, я никогда не работал. Но это не помешало мне поучаствовать в Tech Jam от Facepunch для ещё не вышедшей s&box. О том, как это было (и обо всех провалах в процессе), я и решил написать.
В этом проекте я хотел ответить на вопрос: возможно ли написать игру на Java для Sega Mega Drive/Genesis. Не хочу раскрывать спойлеры, но ответом будет «да».
Несколько лет назад я повстречал проект Java Grinder, который позволяет писать код для различных ретро процессоров на Java, в том числе для Sega Mega Drive. По сути, он интерпретирует байт-код из файлов .class, полученных после компиляции, в код на Ассемблере 68K. Если файлу класса нужны другие файлы классов, то они тоже считываются и обрабатываются. Все вызовы методов API записываются в выходном коде, либо как встроенный ассемблерный код, либо как вызовы предварительно написанных функций, выполняющих свою задачу.
Вы когда-нибудь хотели узнать, как работала предварительно вычисленная видимость в Quake? Я хотел, поэтому написал программу vis.py, воссоздающую этот алгоритм на Python. В этой статье представлена вся информация, необходимая для понимания vis, — инструмента, применявшегося в Quake, Half-Life и играх на Source Engine.
В процессе разработки Quake возникла проблема перерисовки (overdraw), то есть многократной записи одного и того же пикселя во время рендеринга кадра. Видимым остаётся лишь последний цвет, а все предыдущие записи оказываются лишней тратой ресурсов. Это плохо, если в вашей игре используется программный рендеринг, и так выжимающий последние соки из компьютера середины 90-х годов.
Как снизить объём перерисовки? Давайте начнём с высокоуровневого обзора возможных решений.
Я оптимизировал Trellis для работы на обычных ПК. Это мощный AI-инструмент для генерации 3D моделей из изображений, и хочу поделиться тем, как удалось снизить требования к видеопамяти с 16GB до 8GB, сохранив качество генерации.
Создание документации — самая скучная часть в разработке игр. Так думают многие разработчики, а некоторые из них уверены, что «документация устаревает раньше, чем она написана». Отчасти они правы. В современной разработке игр жестким многостраничным документам нет места. Но это вовсе не значит, что документация бесполезна. Геймдизайн документ (диздок, GDD) как стандарт документации для создания игр эволюционировал вместе с индустрией.
Я никогда не посещал «Игромир» и другие подобные выставки, так как всегда считал, что там слишком многолюдно, а половина стендов представляют игры с донатной моделью или проекты, которые уже успели набить оскомину благодаря рекламе. Однако, начав посещать различные мероприятия, я понял, что на игровых выставках можно найти действительно интересные проекты.
Именно поэтому я решил заглянуть на одно из самых знаковых событий последнего времени — выставку «РЭД Экспо». Вместе с «Игропромом» эти выставки действительно дают хоть какой‑то толчок для инди‑разработчиков и небольших студий. На «Игропром» я, к сожалению, попасть не смог, а по «РЭД Экспо» у меня будет отдельный материал.
Сегодня же я хочу поговорить об одной интересной игре — «Спарта 2035». Этот проект, как и «Сатурн», «Передний край» а также несколько других игр, показывает, что деньги от Института Развития Интернета могут быть направлены на создание действительно качественных и интересных проектов, а не только на спорные примеры вроде «Смуты».
Этот материал разделён на две части. Первую часть — обзор бесплатной демо‑версии игры «Спарта 2035» — вы можете найти в предыдущих постах. А перед вами вторая часть — интервью с техническим директором «Липсар Студио» Сергеем Шапошниковым. Приятного чтения!
В студии Arkane в Лионе на входе в офис есть стена с разными вещами, которые присылают фанаты. Одно время там висела большая борда с цитатами великих разработчиков игр, к сожалению, тогда не подумал её сфотографировать. Это была не просто декорация, часто там стояли люди, даже читавшие её не один раз. Где-то в середине разработки Deathloop этот источник вдохновения, который встречал каждого входящего, убрали на склад. Впрочем там поменяли большинство экспонатов. Среди цитат можно было найти слова Джона Кармака, говорящего о важности технологии, или слова Сида Мейера о том, что игра — это серия выборов, мысли главного "Марио" Шигэру Миямото о том, что плохая игра останется плохой навсегда. Эти цитаты напоминали людям, что они не просто создают игры, а продолжают традиции, заложенные легендами индустрии. Слова мастеров оставались в памяти, напоминая, что каждое решение — от механики до дизайна уровней — должно быть осмысленным и значимым. Цитат было немного, точно не считал, но около тридцати, подумал может кому будут интересны высказывания мэтров. Все на память не помню, пришлось спрашивать у гугла.
Спойлер для всех очарованных обложкой: эта книга больше про Nintendo, чем про игру. Хорошая новость: это качественная история о Nintendo и подробности о Марио в ней тоже будут.
