⭐ Вечный C1 x1 сервер (ОБСУЖДЕНИЕ) ❤️

В целом смотрю игра напрягает именно последнее ядро (или поток) в целом можно раздать приоритеты и покрутить всякое и игра еще бодрее себя чувствовать будет,но при желании это ядро можно оверклокнуть ну или как минимум не урезать у него турбобуст по частотам!

А вообще на месте разрабов,яб поэксперементировал с возможностью замены древнего рендера d3d8 e c1 на современный вулкан,впринципе прикрутить его не сложно и не долго,да и тестить не особо гиммор!
 
вот с 720п до 4к скейл...фоткал с тв (4к50 дюймов)! Но фотку жутко ужимать пришлось,ибо ограничения на размер файлов стоят тут.
Дополнительно vrr (gsync) подкрутил еще...в целом картинка очень годная,но как по мне и 2к с таким раскладом хватает за глаза(да и у винды свои косяки от 4к имеются,например проблемы с кешированием ярлыков даже),...с шарпом прям оч неплохо! У кого амд железки,там в дровах очень годный шарп докрутить еще можно,хотя и в скейлере он очень годный.
ну и как видишь интерфейс адекватный по размеру!
но у настолько урезанной фотки,не увидишь конечно особо качество от скейла )
Непонял это Ц1 обычный стандартный клиент? Все говорят что невозможно читать текст размер слишком мизерный если поставить больше фулл хд

Можеш на чистом обычном Ц1 клиенте поставить разные расширения от 2к и 3к и 4к и сделать скрины? Именно Ц1. Покажи как оно выглядит

Если ты найдёш как это вылечить подскажи разрабам пусть добавят в клиент потому что 99% игроков играют с современыми мониками
 
Непонял это Ц1 обычный стандартный клиент? Все говорят что невозможно читать текст размер слишком мизерный если поставить больше фулл хд

Можеш на чистом обычном Ц1 клиенте поставить разные расширения от 2к и 3к и 4к и сделать скрины? Именно Ц1. Покажи как оно выглядит

Если ты найдёш как это вылечить подскажи разрабам пусть добавят в клиент потому что 99% игроков играют с современыми мониками
это с реборна и их клиентом якобы ц4...но результат на ц1 тот-же будет...
 
это с реборна и их клиентом якобы ц4...но результат на ц1 тот-же будет...
Какраз нет, говорят что если поставить большое разрешение то не будет ничего читаться нужен микроскоп
и это не лечится

Скачай проверь пофикси пожалуйста цены не будет тебе
 
Какраз нет, говорят что если поставить большое разрешение то не будет ничего читаться нужен микроскоп
и это не лечится

Скачай проверь пофикси пожалуйста цены не будет тебе
так со всем клиентами л2 ) эта болячка видимо навеки с л2! вот этот клиент с родным 4к и его мизерным интерфейсом )))
 

Attachments

  • 222.jpg
    222.jpg
    1 MB · Views: 76
вот с 720п до 4к скейл...фоткал с тв (4к50 дюймов)! Но фотку жутко ужимать пришлось,ибо ограничения на размер файлов стоят тут.
Дополнительно vrr (gsync) подкрутил еще...в целом картинка очень годная,но как по мне и 2к с таким раскладом хватает за глаза(да и у винды свои косяки от 4к имеются,например проблемы с кешированием ярлыков даже),...с шарпом прям оч неплохо! У кого амд железки,там в дровах очень годный шарп докрутить еще можно,хотя и в скейлере он очень годный.
ну и как видишь интерфейс адекватный по размеру!
но у настолько урезанной фотки,не увидишь конечно особо качество от скейла )
каким образом ты такой скейл сделал? какие минусы у этого способа?
 
У клиентов С1-Интерлюд - пиксельное строение интерфейса, а это значит как нарисовано в текстуре - так и будет, и никак вы этого не измените. Можно лишь растянуть "пиксель" чтобы всё стало шире и больше, но будет размытое изображение.
@Groboman Можно по подробнее про ядра и их ап вулканом? Что то на нереальном.
 
так со всем клиентами л2 ) эта болячка видимо навеки с л2! вот этот клиент с родным 4к и его мизерным интерфейсом )))
Ну тут явно клиент выше ИЛ. Вон настройки какие
 
Можно лишь растянуть "пиксель" чтобы всё стало шире и больше, но будет размытое изображение.
Можно использовать мудреный апскейлер типа AMD FSR.

 
У клиентов С1-Интерлюд - пиксельное строение интерфейса, а это значит как нарисовано в текстуре - так и будет, и никак вы этого не измените. Можно лишь растянуть "пиксель" чтобы всё стало шире и больше, но будет размытое изображение.
@Groboman Можно по подробнее про ядра и их ап вулканом? Что то на нереальном.

Верно выше указали,этим скейлером (как и бесплатным аналогом https://github.com/Blinue/Magpie) можно прикручивать метод скейлера ФСР1 к играм (и не только),запускать в оконном режиме 720п к примеру (меньше базовое значение разрешения---меньше потребуется ресурсов на скейл),скейл будет идти на разрешение раб стола (к примеру хоть до 4к),внутри ПО можно выбрать тип скейлера (тут желательно ls1 или fsr)...и этим методом можно скейлить игру,не убивая интерфейс,при этом получив профит по картинке еще! дополнительно можно прикрутить и еще разные фичи,как к примеру gsync (ибо по дефолту порой оконки не работают с ними и пойдут бесячие разрывы кадров)
По этому пофег какой клиент,ибо алгоритм используется извне!
Да это не натив,но скейл все-равно дает оч годный результат,при этом кушая куда меньше ресурсов,чем нативное разрешение.
Как правило рисков ипользования этих фич в онлайн проектах нет...но на свой страх и риск )

Далее по процессам...тут все просто,https://bitsum.com/ берем тулзу,и вешаем максимально высокий приоритет l2.exe,ибо 1 ядро (поток) игра использует и тут желательно использовать его на максимум...в тулзе можно проверить,какое именно ядро-поток игра на вашей железке использует,и потом можно всячески разгонять это самое ядро (при этом игнорируя остальные) в итоге тут имеем меньше статтеров в игре при различных движухах,ну и в целом более адекватный performance.

По вулкану...тут все просто ,берем https://github.com/doitsujin/dxvk/releases/tag/v2.5.3
который изначально пилился для линукс систем и адаптации протонов и direct x с их open gl,под более современный Vulkan c его кешем (По-сути аналог современного DX12) но их вполне успешно можно прикручивать и к играм в винде ))
но тут как раз...могут в играх с онлайн фичами дать бан! Ибо идет подброска dll файлов,которые будут работать с драйверами GPU и их имплементированными библиотеками вулкана (просто тут надо последние версии дров amd-nvidia)...

Конкретно со случаем С1,дефолт рендер там d3d8 от directx8,и эти старые библиотеки со старыми версиями open gl,неохотно нагружают современные системы,из-за этого всякие GTA4 по дефолту к примеру будут работать так се и на современных железках,зачастую плохо работая с нагрузкой на ЦПУ и ГПУ современных железок!

В итоге берем dll файлы x32 (сомневаюсь,что л2 времен С1 писалась для х64 систем),d3d8.dll и dxgi.dll и кидаем в папку с экзешником игры,и запускаем экзешник как обычно!

При запуске,эти библиотеки будут взаимодействовать с библиотеками вулкана драйверов,перехватывая приоритет у directx(поэтому за этот метод и идут баны как и от различных античитов у игр)
Проверяем оверлей чтоб было указано,что используется уже рендер Vulkan....ииии тестим!

Разницу по использованию железки можно в том-же lasso по цпу смотреть.
Зачастую профит больше всего как раз и имеем от старых игр на dx8-9,более современные уже куда оптимизированнее!
1ый запуск может идти со статтерами (это норм) ибо идет кеширование...бегаем....чекаем....пишем в кеш шейдеры (банально даже бегая по локе к примеру) это автоматом,выходим и заходим еще раз...далее уже куда плавнее все будет!
опять-же тут от случая к случаю,но порой можно очень здоровский прирост получить по производительности.
тем более вулкан умеет хорошо закидывать нагрузку на мультипоток,и хорошо работает с многоядерностью!
Просто банально кидаете эти файлы к экзешнику и гоняем! попутно сравнивая разницу по перформансу...до и после.

Ну и конечно нужно чтоб работал файл подкачки системы (некоторые до-сих пор его вырубают уууххх садо-мазо прям),особенно это актуально будет для хд клиента у кого маловасто ОЗУ!
 
Last edited:
getSmile
МИКРОЩЕПОТКА ИНСАЙДОВ ВЕЧНОГО С1
getSmile





Причёски, цвет волос и тип лица за донат:

POFIGUS:

Это ‼️ новые причёски, которые будут только за донат.

Так же будет добавлена ‼️возможность за донат купить цвет волос (в стандартном клиенте цвета всего два).

Цвета волос будут немного изменены, чтобы не выбиваться из стиля Ц1, у нас всё до мелочей продумывается сразу.


View attachment 11196

View attachment 11197

Не будет новых только у Светлой Эльфийки, так как там все волосы длинные и там причёски все движущиеся, но у неё и так типов причёсок хватает.

Я сделал 1 причёску не с длинными волосами светлым и она будет только в комплекте с шапкой идти:


View attachment 11198

View attachment 11199View attachment 11200

View attachment 11201

Так же планирую добавить ‼️третий тип лица всем персонажам, так же за донат:

View attachment 11202

View attachment 11203

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




Штраф за несоответствие типа вещей:

View attachment 11194




Пассивка на щит:

View attachment 11195




НОВЫЕ СЕТЫ:

Brigandine Set:

View attachment 11187


Composite Set:

View attachment 11189


Chain Mail Set:

View attachment 11190



Full Plate Set:

View attachment 11191



Half Plate Set:

View attachment 11192



Drake Leather Set:

View attachment 11207


Bronze Breastplate Set:

View attachment 11193
Вроде на 1й взгляд кое где кривоватое описание + поработать бы с пунктуацией, на счёт пассивок на щит не будет ли это сказываться на наборе Агро у танков?по поводу статов пока мнение не сложить
 
Хмм а вообще по клиенту Ацкого,немножко непонятка есть...он говорил,что его текстуры потребуют около 8гб озу,но обычно при апе текстур и мешей,повышается нагрузка на VRAM у ГПУ,а не на ОЗУ...хотя хрен знает как там УЕ2 двигло работает с ГПУ...
 
Он говорил, что его текстуры потребуют около 8гб озу, но обычно при апе текстур повышается нагрузка на VRAM у ГПУ, а не на ОЗУ...
Не знаю как дела у dx8, но например OpenGL имеет странную по нынешним меркам особенность - любит хранить дубликаты буферов в RAM...

Вулкан умеет хорошо закидывать нагрузку на мультипоток,и хорошо работает с многоядерностью!
Для меня странно звучит идея о том, что при использовании интерпретатора из одного API в другой может как-то увеличиться производительность. С технической точки зрения на ум пока что пришло только нечто, что я описал для OpenGL. У меня такое ощущение, что информации из приходящих в подмененную библиотеку вызовов не должно хватать для какого-то сильного распараллеливания, если изначально приложение было однопоточное. Только если dxvk сразу отдает запросы отрисовки на обработку в другой поток, а при попытке воспользоваться результатом заставляет приложение (которое на этот момент рассчитывает, что все готово после прошлого вызова) ждать окончания работы.

Есть что почитать на эту тему без необходимости лезть в исходники или переписки разработчиков dxvk?
 
Верно выше указали,этим скейлером (как и бесплатным аналогом https://github.com/Blinue/Magpie) можно прикручивать метод скейлера ФСР1 к играм (и не только),запускать в оконном режиме 720п к примеру (меньше базовое значение разрешения---меньше потребуется ресурсов на скейл),скейл будет идти на разрешение раб стола (к примеру хоть до 4к),внутри ПО можно выбрать тип скейлера (тут желательно ls1 или fsr)...и этим методом можно скейлить игру,не убивая интерфейс,при этом получив профит по картинке еще! дополнительно можно прикрутить и еще разные фичи,как к примеру gsync (ибо по дефолту порой оконки не работают с ними и пойдут бесячие разрывы кадров)
По этому пофег какой клиент,ибо алгоритм используется извне!
Да это не натив,но скейл все-равно дает оч годный результат,при этом кушая куда меньше ресурсов,чем нативное разрешение.
Как правило рисков ипользования этих фич в онлайн проектах нет...но на свой страх и риск )

Далее по процессам...тут все просто,https://bitsum.com/ берем тулзу,и вешаем максимально высокий приоритет l2.exe,ибо 1 ядро (поток) игра использует и тут желательно использовать его на максимум...в тулзе можно проверить,какое именно ядро-поток игра на вашей железке использует,и потом можно всячески разгонять это самое ядро (при этом игнорируя остальные) в итоге тут имеем меньше статтеров в игре при различных движухах,ну и в целом более адекватный performance.

По вулкану...тут все просто ,берем https://github.com/doitsujin/dxvk/releases/tag/v2.5.3
который изначально пилился для линукс систем и адаптации протонов и direct x с их open gl,под более современный Vulkan c его кешем (По-сути аналог современного DX12) но их вполне успешно можно прикручивать и к играм в винде ))
но тут как раз...могут в играх с онлайн фичами дать бан! Ибо идет подброска dll файлов,которые будут работать с драйверами GPU и их имплементированными библиотеками вулкана (просто тут надо последние версии дров amd-nvidia)...

Конкретно со случаем С1,дефолт рендер там d3d8 от directx8,и эти старые библиотеки со старыми версиями open gl,неохотно нагружают современные системы,из-за этого всякие GTA4 по дефолту к примеру будут работать так се и на современных железках,зачастую плохо работая с нагрузкой на ЦПУ и ГПУ современных железок!

В итоге берем dll файлы x32 (сомневаюсь,что л2 времен С1 писалась для х64 систем),d3d8.dll и dxgi.dll и кидаем в папку с экзешником игры,и запускаем экзешник как обычно!

При запуске,эти библиотеки будут взаимодействовать с библиотеками вулкана драйверов,перехватывая приоритет у directx(поэтому за этот метод и идут баны как и от различных античитов у игр)
Проверяем оверлей чтоб было указано,что используется уже рендер Vulkan....ииии тестим!

Разницу по использованию железки можно в том-же lasso по цпу смотреть.
Зачастую профит больше всего как раз и имеем от старых игр на dx8-9,более современные уже куда оптимизированнее!
1ый запуск может идти со статтерами (это норм) ибо идет кеширование...бегаем....чекаем....пишем в кеш шейдеры (банально даже бегая по локе к примеру) это автоматом,выходим и заходим еще раз...далее уже куда плавнее все будет!
опять-же тут от случая к случаю,но порой можно очень здоровский прирост получить по производительности.
тем более вулкан умеет хорошо закидывать нагрузку на мультипоток,и хорошо работает с многоядерностью!
Просто банально кидаете эти файлы к экзешнику и гоняем! попутно сравнивая разницу по перформансу...до и после.

Ну и конечно нужно чтоб работал файл подкачки системы (некоторые до-сих пор его вырубают уууххх садо-мазо прям),особенно это актуально будет для хд клиента у кого маловасто ОЗУ!
Это один из полезнейших постов со всего форума. Администрация, не пройдите мимо!
 
Не знаю как дела у dx8, но например OpenGL имеет странную по нынешним меркам особенность - любит хранить дубликаты буферов в RAM...


Для меня странно звучит идея о том, что при использовании интерпретатора из одного API в другой может как-то увеличиться производительность. С технической точки зрения на ум пока что пришло только нечто, что я описал для OpenGL. У меня такое ощущение, что информации из приходящих в подмененную библиотеку вызовов не должно хватать для какого-то сильного распараллеливания, если изначально приложение было однопоточное. Только если dxvk сразу отдает запросы отрисовки на обработку в другой поток, а при попытке воспользоваться результатом заставляет приложение (которое на этот момент рассчитывает, что все готово после прошлого вызова) ждать окончания работы.

Есть что почитать на эту тему без необходимости лезть в исходники или переписки разработчиков dxvk?

Возможно у OpenGL тех времен (не забываем,что версий там было множество,как и их правок) были "ограничители" на чрезмерную нагрузку VRAM,ибо тогда ускорители стоили очень дорого,да и обьем памяти был мал! Возможно да,в около 2001+ года нагрузка железа шла уже распыляясь на ЦПУ--ОЗУ-ВРАМ...до этого в около 96года,когда не было еще толком GPU и ранних Voodoo,тогда вообще нагрузка рендеров и прорисовок у игр лежала в большинстве своем на ЦПУ и лишь возможно и RAM(тогда и обьем в 16мб озу нормой был,где большей части нужно было самой ОС) в наше время нагрузки по железу конечно по другому идут с нынешними движками и инструментарием!
В целом восхищают насколько филигранно в те года умудрялись в "оптимизон" на столь слабом железе тех времен(как и консолей),а какие чудеса творили на машинках уровня IBM486 мммм...где каждый мегагерц был на счету и использовался на максимум возможностей!
Но в ввиду 2001+ и УЕ2,вполне себе уже должны адекватно использовать возможности GPU,поэтому возможно основная нагрузка HD клиента с апнутым визуалом все-же больше именно на ГПУ ляжет (не без участия ОЗУ и ЦПУ конечно-же),ну как минимум надеюсь шо так )) ибо Ядро ЦПУ и так будет занят л2 процессом )

Насчет возможностей вулкана не сомневайся,штука отменная...как и современный ДХ12(в целом они во многом схожи),Валвы уже хотели нанять себе разраба dxvk,ведь они усиленно продвигают их Линукс систему(например на их-же Деке),и очень грамотно используют Вулкан в своих Протонах,благодаря чему игры и работают на линуксах...но вулкан в той-же мере отлично себя показывает и на винде конечно-же )
НО поскольку протоны работают с использованием внешних библиотек и прочих нюансах,естественно игры с онлайн защитой и подобное (типа античита)не работают там! Поэтому разрабам серва нужно изначально добавлять эти библиотеки в клиент,ну и прописать их в своей защите...
Данная подменная библиотека,скорее по приоритету перенаправляет (с некой обработкой) на библиотеки и рендер вулкана в драйвере ГПУ,в обход directx древнего с его старой версией opengl.

В целом тут как с ремонтом машины например...когда машину ремонтируют,слесари же не ограничивают себя инструментом в виде молотка и лопаты(ну а вдруг)) а используют для достижения поставленной цели и результата по мере необходимости много разных инструментов и ухищрений!
Тут также,для достижения годного оптимизона,не стоит прям зацикливаться исключительно на правках старого исходного кода(особенно когда и возможностей тут нет особо) и тратить на это уйму ресурсов,когда можно воспользоваться другими инструментами...пусть даже и извне!
как минимум на месте разрабов харбора я-бы попробовал и сделал-бы замеры этой самой производительности при использовании современного рендера на движке УЕ2,вполне может оказаться вполне действенным инструментом...а возможно и перенаправит нагрузку с ядра на ГПУ (тут вулкан тоже хорош),ведь ядро и так будет занято л2 процессом,и желательно максимально его разгрузить!
Опять-же это если стоит цель,достичь (или хотя бы попытаться) максимального перформанса....ведь порой у разрабов и нет этой цели,будем честны ))

Вообще можно и еще даже апнуть оптимизон у л2,есть методы.Но тут юзерам конечно допиливать самолично на машинках придется,желающих на это будет не много!
С миру по нитки(тут чутка--там чутка),и в итоге вполне себе можно выжать неплохо со старого двигла,даже в реалиях многопоточных цпу.
 
Впринципе думаю вполне возможно с лаунчера харбора на уровне клиента даже заранее подготовленный профиль process lasso подогнать где уже будут выставлены нужные приоритеты и параметры по l2.exe,и автоматически при запуске л2 будет запускаться lasso с нужным конфигом...думаю с помощью батника на уровне клиента это вполне себе реализуемо,тем самым автоматизируя этот процесс!
А судя по различным веткам форумов еще бородатых годов этим инструментом пользовались немалое кол-во людей гоняющих л2,с его однопотоком...
Тем более,что вулкан,что lasso это freeware контент,поэтому проблем с авторскими правами и не будет тут (да есть Про версия платная у лассо,но хватит и freeware варика)
 
Last edited:
Возможно у OpenGL тех времен (не забываем,что версий там было множество,как и их правок) были "ограничители" на чрезмерную нагрузку VRAM.
Почти, это и правда сделано из-за малого количества VRAM, но по чуть иным причинам. Представь, что у тебя 16мб VRAM, а все текстуры и модели для отрисовки сцены весят условно 20мб. Из-за ограничений API эту ситуацию разработчик ПО никак обойти не мог, поэтому драйверы начали хранить все 20мб в RAM, закидывать все 16мб что помещается в VRAM, рисовать что поместилось, переписывать оставшиеся 4мб и рисовать оставшееся.
В современных графических API есть буферы разного вида, что позволяет разработчику самому контролировать распределение памяти между RAM/VRAM.

Насчет возможностей вулкана не сомневайся,штука отменная...как и современный ДХ12
В современных графических API я не сомневаюсь, но сомневаюсь что игра написанная по "старым правилам" заиграет новыми красками, если будет переведена на "новый язык" в автоматическом формате. В принципе вижу как могут уйти некоторые статтеры, но среднее количество кадров наверное не вырастет.

Данная подменная библиотека,скорее по приоритету перенаправляет (с некой обработкой) на библиотеки и рендер вулкана в драйвере ГПУ,в обход directx древнего с его старой версией opengl.
Почти верно, но есть неправильные или лишние слова.
Никакого приоритета для перенаправления нет, перенаправляется все. Скорее всего при запуске создается некий супер общий пайплайн Vulkan рендера, и все дальнейшие вызовы к d3d8 "переводятся" и пробрасываются дальше по этому пайплайну в Vulkan.
DirectX и OpenGL никак с технической точки зрения не связаны, это два не связанных между собой графических API, которые говорят с видеокартой на более понятном ей языке.

Я бы сказал так:
Данная подменная библиотека переводит все DirectX запросы в запросы Vulkan и вызывает их используя библиотеки и рендер вулкана в драйвере ГПУ полностью игнорируя directx.
 
Back
Top