X-Ray Oxygen 1.7f «X-Ray Oxygen» - это OpenSource проект по рефакторингу движка X-Ray, представляющий собой платформу для разработки игр или же модификаций. Проект не имеет мультиплеера, так же он неподдерживает 32 битные системы. Кроме рефакторинга, у нас есть расширенный скриптовый функционал для создания более гибкой скриптовой логики, так же различные улучшения в оружейной части, включая поддержку новых звуков и анимаций, если таковые имеются. Особую роль для нас играет графическая составляющая, какой же прок от движка в 2018 годе без хорошей графики :)? Помимо этого, мы стараемся задействовать как можно больше функционала вашего процессора, из-за чего мы стараемся использовать различные наборы инструкций, таких, как SSE 4.1. Так же основную роль в наше время играет многопоточность, о которой мы стараемся не забывать.
К нам в проект требуются: C# программисты, C++/CLI разработчики, HLSL программисты, не помешали бы OpenGL/Vulkan разработчики, которых в ST-Community практически нет, а жаль... Если вы желаете помочь проекту, свяжитесь со мной или же воспользуйтесь системой Issues/PR на GitHub.
• Полностью рабочий x64 • Переделанная Mixed конфигурация (для разработчиков) • Удалёно много ненужного кода, в том числе стороннего API и мультиплеерного. • Многоядерная обработка потоков • Многопоточность • Новая звуковая система: OpenAL Soft + EFX • C# Скриптинг (Spectre Script Engine) • XML Blend шейдеров
[WARNING!] Для работы данного проекта требуется C++ Redistributable for VS 2019 x64. [WARNING!] Нет статического освещения. Бугага! [WARNING!] Нет поддержки WinXP/Win7
Так же открыты донаты: Сбербанк Visa: 4276 3801 5027 9896
Сообщение отредактировал FX - Пятница, 14.02.2020, 09:51
ты считаешь, что без 64 бит в сталкера играть нельзя?
Я считаю что, если хочется, или никак иначе, то конечно можно. Можно даже вышеупомянутую оптимизацию произвести. Вот только писать "Ребят, Х86, ну позя-я-я..." однозначно не стоит, а стоит при первой возможности перейти на X64, а X86 оставить под другие задачи, которых найти можно не мало. Потому что развитие, оно не заключается в упрощении - уменьшении полигонов, кол-ва пикселей и всяческих обрезаниях и "оптимизированиях".
sinaps, ты видимо очень прав, если считаешь оптимизацию упрощением всего. Оптимизация и упрощение - разные вещи.
Давай рассмотрим это на примере оптимизации в проекте RoH. Там склеили большую локацию, и она просто целиком грузилась в память, как и в оригинале. Жрало это - дохрена. Тогда ребята заморочились и сделали динамическую подзагрузку коллизии. И жрать стало меньше. А можно было бы и не оптимизировать, просто купить несколько десяков гигов рамы и всё было бы зашибись и так.
Modera, я очень хорошо понимаю, что такое необоснованное потреблением ресурсов. Частенько приходится переделывать DXT3 и DXT5 в DXT1 там где α-канал ну не нужен никак и выкидывать куски геометрии из внутренностей моделей, которые всё равно никто и никогда, кроме как в 3D-редакторе не увидит.
Конечно. Если что-то не развивается, то оно деградирует и помирает. Ведь x64 движок предоставляет больше доступных ресурсов чем x86. А уж как их осваивать, как ими распоряжаться, что конкретно на этой основе раализовывать - дело для будущих модостроителей и модов. В этом на мой взгляд и заключается развитие - в появлении новых возможностей.
Первым делом стоит отметить, что начинается интеграция Qt в графические окна. Началось всё с написания аналога xrPlay.
Так же, мы сделали лаунчер более удобным для использования. Он сохраняет пользовательские настройки. Из-за этого пришлось переделать инициализацию xrCore. Заодно и переделал принцип инициализации shared_str. Теперь они существуют с момента запуска движка и вплоть до его закрытия.
Опять уделили внимание оптимизации сборки. Поубирали лишнее из xrCore и xrEngine. Так же слили xrCPU_Pipe с xrCore. Теперь ttapi можно вызвать из любого проекта.
Исправили практически все ошибки в сборке Max_Export2016. В целом, осталось заставить его работать, но пока руки не доходят.
В общем, для игрока в этом месяце толком ничего интересного нет.
Ну и так: экспериментально ускорили загрузку самого движка, путём выноса загрузки .thm в два асинхронных потока. Вроде работает, но пока в релиза не будет. Надо ещё погонять, чтоб как с OMP не было.