LINUX.ORG.RU

Какие игры под linux умеют динамическое разрешение? ^.^

 , , , ,


0

1

И так столкнулся с тем что у меня начал местами проседать fps из за parallax occlusion (вот пример https://youtu.be/FUYzaYnRJWY?t=254, модель плоская, но создаётся ощущение трёхмерного объёма ) так как уменьшать семплирование в шейдере уже некуда 6 проходов и так уже всего лишь. Начал думать, если менять разрешение поменьше то всё ок, но при разном основном размере окна уменьшать размер вьюпорта который потом скалить до размера окна нужно по разному. Просто снизить разрешение не вариант так как это проседания местами, а не всегда. Наткнулся на статью https://software.intel.com/ru-ru/articles/dynamic-resolution-rendering-article стало интересно, нашёл одно видео https://www.youtube.com/watch?v=pMQppLv-z1o&feature=emb_logo , по быстрому на коленке реализовал динамическое разрешение, вот так выглядит https://youtu.be/rWm3GYq3Nds (оно там не отрегулировано поэтому скачет, намеренно задано 60 слоёв паралакса для вызывания лагов) Ну так вот,проблему оно решает если проседание 10 кадров то можно смело уменьшать разрешение пикселей на 100 а то и 200 если сцена динамическая проседание будет только в 1 кадре один раз, а чуть меньшее разрешение не так бросается в глаза чем лаги, после того как в сцена может снова рисовать нормальное количество кадров то разрешение возвращается обратно, хочется посмотреть как выглядит оно в реальных играх, что бы сравнивая допиливать своё.

Игра может быть закрытая, желательно бесплатная. Мне просто визуально посмотреть как оно используется в реальности. Как оно внутри работает я по картинке пойму. Я сейчас делаю в лоб, а при детальном рассмотрении кадров игр порой видно не очевидное. Например можно разбить кадр на квадраты и рендерить последовательно их выявлять какой квад экрана вызывает проседание и менять разрешение только этого квада. Ну и тому подобное.

Я всё та подробно расписал что бы из бежать вопросов «Зачем, чвоитатакое?» и утверждений «Эта нинужна! оптимизируй причину, а не лечи следствия!»

Де взять такую игруху? =) ^.^ (Видосы с ютуба не то если что, он портит шум)

★★★★★

Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

Mandelbulber. Не совсем игрушка, но судя по всему оно умеет делать то, что ты хочешь.

SZT ★★★★★
()

О, кстати, POE такое умеет из всего что я знаю. Но там и проблема из-за этого есть, когда в движке что-то лагает, оно не понимает что по факту может рисовать нормально, т.к. нихрена в игре не происходит, а текстурки как раз просели до маленьких, так не всегда назад откатываются и если в динамике это нормально выглядит когда у тебя месиво из снарядов и мобов на экране, то когда ты на месте стоишь и вообще ничего нет, то это шляпа. Лечится только перезапуском игры.

PS

Уменьшай разрешение текстур в 2 раза, есть алгоритмы по быстрому и красивому уменьшению текстур или увеличению именно в кратные 2-ум разы.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine

Тебе алгоритм нужен или проприетарщина?

Мне картинка нужна реальной игры где это применяется, кадры в большом разрешении где можно рассмотреть детали и всё, просто что-бы увидеть с каким шагом меняется разрешение, по всему ли экрану, с какими таймингами и условиями разрешение востанавливается.

Это не алгоритмы, а просто мелочи жизни так сказать. Как сделать то что я хочу я знаю и уже сделал. Но порой глядя на результат других видно свои промахи и недоработки, не додумки.

Причём тут проприетарщина? Нет разницы, нужно видеть процесс работы и результат. В большинстве случаем мне не нужен код что-бы понять как и что работает.

Это как ты делаешь автомобиль в гараже, рядом проехала машина и у неё есть дворники, ты такой, ха! И сам делаешь себе дворники не смотря как они устроены и работают у проехавшей машины. Я вот про это

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Поставь POE на винду и посмотри. Можно в wine накатить. Оно бесплатно. Только поиграть придётся долго, чтобы собрать лагучий билд, ну или железо тупенькое взять. Меняется по всему экрану, кроме бэкграунда. Восстанавливается по таймеру похоже, но это плохое условие, т.к. если пролаг в этот момент из-за подгрузки текстурок, то оно вообще только перезапуском лечится.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 3)
Ответ на: комментарий от peregrine

Уменьшай разрешение текстур в 2 раза, есть алгоритмы по быстрому и красивому уменьшению текстур или увеличению именно в кратные 2-ум разы.

Текстуры можно не трогать, я пересобираю FBO цели рендера и вьюпорт уменьшаю, первое освобождает лютую кучу памяти (порой она виновата) второе отсекает кучу текселей растеризатора по итогу framerate падает без видимого на глаз мыла. Можно не трогать fbo но тогда надо вносить нюансы в шейдера, но я так не хочу. Пусть пересоздание буферов даже относительно долгое дело. На уменьшенном вьюпорте можно смело LOD_BIAS текстур уменьшать, соотвецтвено будет уже mipmap выборка и тут как раз освобождённая от FBO память (он стал меньше, ну подключённые целевые текстуры понятное дело) занимается mipmap уровнями текстур. Пока что я вот так думаю. Самый минимальный вариант вообще наипростейший рендерим с вьюпортомvec2_size - resolution_offset во временные буферы, затем итоговую ldr текстуру рендерим на экран с вьюпортом vec2_size + resolution_offset всё, оно уже работает, offset же мы вычисляем в зависимости от того какой у нас fps при 60 например он 0, упало до 58 нам надо два кадра, а лучше три запаса, задаём offset в 50 следующий кадр уже с меньшим разрешением (но хрен ты заметишь ) а кадры пришли назад.

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от peregrine

Не, ну можно и ими. Передать в итоговый шейдер offset, нормализовать его и UV кадра на него поделить. Одна строчка. Но, нафиг она мне нужна =), если viewport мне всё равно надо каждый кадр устанавливать и дешевле будет просто его менять, а не добавлять что-то в шейдера. Но! Если разрешение придётся опускать прям на дно, то надо его будет зернить и тому подобное дабы скрыть падение разрешения. Но если лагает так что при 1920x1080 основном разрешении проседает до 10 кадров и что-бы вытянуть на 60 надо будет в 800x600 утанавливать то как мне кажется пущай лучше лагает )))) А то от таких скачков разрешения проблеваться можно. 200 пикселей по краям и норм. Дальше жопа. Ну, ща игр и софта советованного накачаю буду скрины делать и рассматривать, как у взрослых дядек оно выглядит =)

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Я про то, что есть смысл иногда 2 версии текстурок держать предварительно сделанных, если динамически они не рисуются и уже загруженные в память.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

А, ну да. Но такое я пока у себя ещё не реализовал. По сути да надо LODы и моделей иметь и текстур по хорошему. Но не знаю сейчас возьмусь опять в допиливании движка застряну =) А надо игру делать, это уже потом. Сейчас же надо как то по бырому оптимизировать отдельные моменты вот таким пусть и грубым, но быстрым способом. А там увидим

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от peregrine

Всё равно спасибо за советы, порой даже явные вещи мимо мыслей вжух. А потом локти кусай сиди

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Мипмапы уже есть, можно просто LOD оффсет для них крутить наверное.

В случае parallax map, mipmap не спасёт. Ну, спасёт, но такое себе, надо тотально и комплексно. Прям ща замерил 512 (это у меня лимит) проходов parallax LOD_BIAS = 2 выдаёт 12 fps понижаю LOD_BIAS = -8 (самый нижний уровень выборки 1 цвет по сути) 13 fps, короче фигня. Лоды текстуры хороши когда большие пространства + не яркое освещение, там да более низкие уровни выборки дают порой over 200% прироста кадров. А в случае тяжёлых операций надо уменьшать количество обрабатываемых данных. К примеру я (будет такое) буду кратковременно спавнить кучу партиклов котрые взрывом будут разлетаться. В момент когда они кучей мелькают на экране (там блендинг и всё такое) 100% будет кратковременный, но сильный просад кадров, и вот тут из за того что на экране и так каша можно сэкономить на пикселях и временно на момент бабаха вселенского в лицо игроку снизить разрешение, лагов меньше, плавности бабаха больше, бабах кончился разрешение вернулось назад. Все довольны. Конечно это в зависимости от ситуации может быть сильно заметно, но. Либо лаги, либо хаки. К сожалению каждая отдельная оптимизация чаще всего применима только к определённым случаям. ((( Золотой пульки нет. Тут разрешение подкрутить в динамике там LOD подправить, тут тени поубавить, там то тут это тут сё. Эх ((

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от mittorn

Не, ну по динамике хочешь их понижать, понижай. Только не удивляйся, где FPS потом, если ты именно его и пытаешься оптимизировать.

peregrine ★★★★★
()
Ответ на: комментарий от mittorn

Влияет, значительно. Но, как правило, в реальных игорях больше производительности жрут шейдеры, а разрешение и LOD текстурок специально занижены.

anonymous
()
Ответ на: комментарий от anonymous

Влияет количество вызовов пиксельного шейдера больше. А большие текстуры на маленьком разрешении всё равно залодятся

mittorn ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.