Потянет ли офисная видеокарта GZDoom без просадки fps ниже 60 с 3d моделями и текстурами высокого разрешения?
Мое мнение - если хочешь 60 фпс без просадок на офисном железе, то тебе надо:
1) Russian Doom
2) PrBoom
3) GZDoom, но без графономодов (а также без тяжелых геймплейных модов/маппаков а-ля serpent resurrection, где из-за обилия 3д полов и прочих таких вещей, очень падает фпс)
GZDoom с графономодами лагает (ну или как минимум делает периодические просадки фпс) даже на НЕофисном железе (тем не менее, мой опыт показал, что в гздуме с графономодами средний фпс выше, чем в думсдее с графономодами, и играть комфортнее)
Одна из проблем, которую ты встретишь в гздуме с графономодами, это прекеш, и из-за частой подгрузки текстур во время игры, фпс будет просаживаться (а бороться с такими вещами геморно, особенно когда не хватает видеопамяти). Чтобы фпс был максимальным в гздуме с графономодами, тебе придется очень постараться с оптимизацией твоего графономода. А также у тебя встанет вопрос версии порта, ибо я слышал много хейта в сторону последних версий в плане их производительности, а те версии, которые преподносятся как максимально быстрые, они уже очень древние, и многие графонофичи (а также полезные для их оптимизации вещи, например зскрипт) не потянут
Если тебе интересно, какой фпс (и какие просадки) показывают мои графономоды для дума, еретика и хексена на гздуме (уточню, что для дума я 3д модели пока не юзаю, так как руки не дошли, но зато для дума юзаются нейросетевые хайрез спрайты и 2k текстуры, для которых у меня не хватает видеопамяти, что иногда создает просадки) на моем железе:
помни, что параллельно с гздумом часть ресурсов расходуется на запись видео в 2 потока, один на стрим, второй на запись
то вот ссылка на записи всех моих стримов по гздуму: https://www.youtube.com/playlist?list=PL5QwAqOy7WACcs00yF5j64ujBbJXlShsl&disable_polymer=true (чем ниже ролик в плейлисте, тем актуальнее версия гздума и моих графономодов. Версию порта я всегда пишу справа снизу в заглушке стрима. Ролики по Strife и Serpent Resurrection игнорируй, они не имеют отношения к тяжелым графономодам (но серпент лагает сам по себе, по другим причинам) )
STALKEROZ_ - map mapname - меняет карту, как если бы запускалась игра с 0 (прим. map e1m2, map map30)
- changemap mapname - меняет карту с интермиссией, сохраняя весь инвентарь и переменные в библиотеках ACS/ZScript (прим. changemap e1m2, changemap map30)
- есть ещё changemap2 , но не помню что там. То ли пистолстарт, то ли ещё что-то. Упс. Похоже наврал с этим.
Возможно ли в этом порту через настройки или какую то программу убрать искры от файерболов? Привык просто играть без них. Меньше искр, дыма - лучше видимость врага!
И вообще сделал ли кто-нибудь мануал на русском по многочисленным настройкам порта? Порт то очень популярен! Настроек и правда слишком много и неясно порой что улучшается или ухудшается ими....
Возможно ли в этом порту через настройки или какую то программу убрать искры от файерболов? Привык просто играть без них. Меньше искр, дыма - лучше видимость врага!
Да. В настройках есть выбор. Display options/Rocket trails - off
Недавно выяснил, что тяжелые графономоды (при условии использования HQ4x или XBRZ4x фильтра) в актуальной версии 4.4.2 гздума (а также последних девбилдах на текущий момент) будут съедать в 9 раз больше памяти (в пике), чем в версии 4.3.3, что с большой долей вероятности добавит вам неиграбельные лаги.
Вот короткая видео демонстрация, как гздум лагает на последнем девбилде (в версии 4.4.2 он лагает точно так же) на железе "16 GB RAM, 2 TB SSD" (тобишь файл подкачки у меня на ссд, и если оперативки не хватает, то недостающие данные пишутся/читаются с ссд): https://forum.zdoom.org/viewtopic.php?f=2&t=69768&p=1164429#p1164377 (справа в роликах выведен taskmanager, где можно динамически смотреть использование памяти гздумом)
По той же ссылке можете глянуть и второй ролик, как гздум версии 4.3.3 не лагает на том же моде, конфиге и сценарии использования
Здесь есть те, кто шарит в исходниках гздума, чтобы объяснить, почему вот эти https://github.com/coelckers/gzdoom/commit/8505c7ee7da1fa5ac8452903f4b32f9797c9c32c изменения привели к 9-кратному приросту использования памяти? Это баг, или так и задумано? Если так и задумано, то есть ли шанс, что смена рендера с opengl на вулкан (имею в виду будущие допиленные его реализации в гздуме) уменьшит используемую память?
Например там есть такой коментарий:
Still not solved: Material layers need explicit control, not only for scaling but also for filtering.
Значит ли это, что после решения проблемы "Material layers need explicit control also for filtering", использование оперативки опять вернется к тому, что было в 4.3.3?
З.Ы. В 4.4.2 обнаружены утечки памяти https://forum.zdoom.org/viewtopic.php?f=7&t=69055 (которые пофикшены в последнем девбилде), так что если используете 4.4.2, возможно имеет смысл откатиться назад на 4.3.3 или использовать последний девбилд (я так понял, это не связано с проблемой, которую я описал выше, так как ролик записывался на актуальном девбилде)
При компиляции скриптов библиотеки из блокнот-файла столкнулся с забавным глюком.
У меня в блокнот-файле стояла кодировка UTF-8. После компиляции в игре перестали распознаваться русские буквы (хотя переменные, отвечающие за язык я прописал корректно - и при смене языка на англ. все тексты правильно отображались).
Посмотрел на кодировку в старом файле блокнота, с которым не было раньше проблем - а там, оказывается, стоит ANSI.
В итоге пришлось тупо скопировать текст из файла с UTF-8 в файл с ANSI, скомпилировать его, после чего в игре русский язык заработал, как и положено.
Это, интересно, такой прикол? что acc компилятор не понимает русские буквы в UTF-8?
И как быть, если под рукой не окажется готового файла ANSI, куда можно все скопировать?
Асс компилятор понимает всё правильно. Просто очевидно что если твой шрифт сделан под ANSI, то работать под UTF он не будет (для этого нужно продублировать все русские символы в 0x400+ интервале)
Или в консоли тоже не выводится текст написанный в юникоде?
Просто очевидно что если твой шрифт сделан под ANSI, то работать под UTF он не будет
Не понял, причем тут шрифт вообще. Файл шрифта .fon2 лежит в пк3 отдельно, а речь шла о тексте, который записан в скрипте библиотеки.
Например, кусок скрипта:
sethudsize(1024,768,0);
SetFont("SmallRfo");
if (Abilities == 0)
{
if (GetUserCVar(0,"P_Language") == 0) {hudmessage(s:"You don't have enough abilities to increase your attributes.";HUDMSG_plain,10025,CR_red,184.1,200.1,0);}
if (GetUserCVar(0,"P_Language") == 1) {hudmessage(s:"У вас недостаточно возможностей для повышения характеристик.";HUDMSG_plain,10025,CR_red,184.1,200.1,0);}
delay(1); terminate;
}
при компиляции из txt-файла с UTF-8 в игре русские надписи не пишутся (остается пустое место), а англ. пишутся. При компиляции из txt-файла с ANSI в игре пишутся надписи на обоих языках.
В шрифте номер буквы при юникоде и при ANSI разный.
Например буква A = 0xC0 при ANSI и 0x410 при юникоде.
При попытке отрендерить юникод гздум переключается на режим юникода (тот самый который сделали для китайских иероглифов) и пытается в твоём шрифте найти символ 0x410, например. А у тебя он под ANSI и их максимум 256...
Хз как ещё понятнее объяснить)
Поэтому я и спрашиваю: В КОНСОЛИ отображаются юникодовские надписи? Консольный шрифт всегда одинаковый.
ZZYZX Теперь понятно. Значит файл шрифта fon2 сгенерирован для ASCI, а скрипты скомпилировались от юникода, в итоге возникает несоответствие символов, когда скрипт пытается обратиться к шрифту.
В консоли тексты из скриптов не пишутся, потому проверить нельзя. В консоли пишется только про подбираемые вещи и т.п. стандартные сообщения декорэйта, а там везде англ. язык. И да, декорэйтные текстовики у меня в кодировке UTF-8, но в случае латинских букв проблем с кодировкой не возникает.
Shadowman Я имел в виду чисто для теста вывести в консоль что-нибудь через такой ацс с юникодом. И глянуть что будет.
Либо иероглифы, либо пустые буквы, либо нормальный русский. Если иероглифы или пустые то это баг ACC/GZDoom. Если в консоли будет нормальный русский, то проблема именно в том что я сказал.
Ты же понимаешь что я сам не тестировал и поэтому 100% уверенности нет, только достаточно вероятная идея)
Правила 
Поиск
