Посмотрите новые switch в java, они на голову выше стандартных с break и {}. Получается компактно и удобно, работает в связке return switch...
switch это тот же map, но в байткоде, а не Map/dict, то есть будет работать быстрее и шанс ошибиться ниже, так как компилятор обязывает проверять все значения из enum, все отнаследованные типы.
.kkrigger, насколько я помню, так и не дошёл до релизной версии, а всё ради минимизации .exe, из-за чего игра гвоздями прибита к win api, и, скорее всего к какой-то конкретной версии винды, так как на win 11 запускается в режиме совместимости с некоторыми багами.
Портируемость - нулевая. Расширяемость - околонулевая. Популярность - вечная в сообществе минимизаторов. Ценность для игрока - мизерная.
Достаточно глянуть на текстуры: 1024х1024 в формате ETC2_RGB займёт 0.5 МБ, плюс простейший MIP = 0.68МБ, условно 0.7 МБ. Brotli / z сожмет до 0.2-0.5 (а зависимости от данных).
В одном материале: цвет, нормаль, металличность, шероховатость. Последние две - одноканальные, их можно сжать до RG, B оставить пустым. Итого 3 текстуры на 1 материал = 2.1 (1.2 сжатый) МБ.
100 материалов - 120МБ только на текстуры. Если текстуры не 1к, а 2к, то размер больше в 4 раза (480 мб).
Ещё меши, но они занимают 30-40% от размера текстур.
Анимации - зависит от игры. Может получиться сравнимо с текстурами, а может раз в 5 меньше.
Музыка занимает много, сравнимо с текстурами, возможно больше.
В блендере разделены: меш, арматура, анимация. В арматуре у костей есть имена, у анимаций - тоже, поэтому переносить анимации между разными скелетами возможно (вроде менять веса у меша для разных арматур тоже).
В 2021 году писал свой экспортер из блендера. Вспоминая размер контекста, который надо хранить в голове, нейронки вряд ли справятся (либо затратите х5 времени на объяснения и проверки, чем написали бы сами).
Дело не столько в объёме, сколько в понимании устройства блендера, так как получить нормали модно несколькими способами, но в первом они будут правильные, а во втором - (0; 0; 0;).
В итоге - да навайбкодить простой экспортер можно, а доводить до product-ready придётся вручную.
А оно обязано? У каждого DE, у каждого дистрибутива свое сообщество, которое сосредоточено на своем объекте интересов.
Потому и существуют сотни форков, а до ума (установил и работаешь) доведено ноль.
А то можно договориться до того, что не нужны и одновременно мак и винда. Нужно сосредоточиться на чем-то одном. А если чтт не нравитмя, то "оно вам не нужно" или "жрите, что дают".
Винду и мак делают корпорации, цель которых - извлекать прибыль, а для этого нужно удерживать пользователей, в том числе предоставляя ему удобство работы за ПК.
У сообщества линукса такой задачи нет - это группа по интересам, где никто никому ничего не должен.
Ага, щаззз, до конца. Постоянно какие-то проблемы, да еще за свои же деньги. Я уж лучше поимею проблемы, но бесплатно, тем более, что пока нерешаемого не встречал.
Не припоминаю проблем в винде в ходе использования, но допускаю что они были/есть у других пользователей.
Что делает виндузятник, если на тачпаде ноута скорость скрола слишком высокая? Лезет в настройки и двигает ползунок скорости скрола.
Что делает линуксоид в той же ситуации? Правильно, ищет репо на гите (https://gitlab.com/cczp/act-2/libinput-touchpad-scroll-fix), который компилится в библиотеку и на лету делит скорость скрола, делая её нормальной, а не турбореактивной.
Да, подумать тут приходится, но как-то удобнее на винде всё-таки...
Возможно этот "фикс" ломает навигацию в блендере с тачпада (камера одновременно приближается и крутится). Совершенно точно из-за него жесты в тг и перелистывание страниц в главном меню становятся тугими.
В винде работают жесты в браузере - в линуксе их либо надо настраивать, либо их нет. В винде скрол инерционный везде, в линуксе - где-то работает, где-то нет, где-то быстрее, где-то медленнее. В винде нормальный офис, в линуксе - танцы с бубном.
Из плюсов линукса - apt install, но то же самое позволяет сделать WSL, но с удобством винды как основной ОС. Я хочу работать, а не чинить и настраивать систему и всё равно смириться с тем, что всё брошено на 90%.
Почему сообщество не сконцентрирует силы на одном дистрибутиве, на одном (окей, второе для слабых пк) оконном окружении? Зачем распылять силы на gnome, kde, xfce, lxde, unity, cinnamon, mate и сотню других недоделок? Зачем debain, ununtu, kubuntu, lubuntu, xubuntu, mint, popos, elementaryos, fedora и прочие? Создание ОС и оконного окружения не должно становиться целью, ОС и оконное окружение должно быть инструментом.
В винде и эппле 1 система и 1 оконное окружение. Зато доделано до конца, а в линуксе - зоопарк "бери, допиливай сам".
Прокси сервер переносим из системы в систему, скорее всего сделан так, что позволяет закрыть несколько ресурсов (доменов) в одной системе, а скрипт из папки привязан к архитектуре и языку одной конкретной системы.
В маленьких проектах лучше скрипт в папке, в проектах побольше - прокси сервер.
У компиляторов и VM процесс перевода "код -> асм" детерминирован, исчерпывающе протестирован, описан в документации, а в случае ошибок указывает вплоть до символа где опечатка, или RuntimeException.
Что же будет в случае, если интерпретатор заменит AI? Миллиард цифр и вперёд, отлаживай. Поведение "примерное", результат "в целом нормальный", а какие-то граничные случаи приведут к сбоям, уязвимостям.
Работать оно будет, конечно, но скорее всего для пет проектов и прототипов, а более-менее серьёзные системы будут писаться на обычных ЯП, а не AI-first.
ИМХО, Смотря с какой java сравнивать. Последняя LTS 21 очень даже хороша с var, виртуальными потоками, pattern matching'ом, записями, try with resources и другими полезными нововведениями.
Крупняк пока переходит с 8 явы, но новые проекты можно начинать на 21 версии и получить все плюшки, либо начинает на kotlin.
На юнити или скретче можно "программировать" игры с помощью чат-гпт, и весь процесс будет казаться магией (в которой не особо хочется разбираться, так как она отдана на аутсорс нейросетке). Польза от такого программирования сомнительная, хотя простая игра может получиться, замотивировав идти дальше. Скилл программирования при подходе "напиши задачу или скопируй ошибку нейросетке" не растёт, и в результате получится очередной гпт-программист, не способный перевернуть строку.
Второй способ - начинать с CS, с машинного уровня. В геймдеве с этим скорее всего придётся столкнуться, когда речь зайдёт об оптимизации или минимальной защите игры от взлома. Но такой подход долгий и за 2-3 года может пропасть желание "изучать IT, чтобы делать игры", а игры не будет. Зато может появиться стремление к чему-то другому: бэк, фронт, мобайл, дизайн, десктоп, тестирование, аналитика и так далее.
Вопрос поиска баланса при запросе "хочу научиться делать игры" для меня остаётся открытым, уж слишком много надо для этого изучить, чтобы сделать что-то сложнее (а в большинстве случаев это именно так) гиперказуалок.
Мой список того, что нужно изучить, чтобы начать геймдевить на c++ / java / js: 0. Структурное программирование, операторы, типы данных.
Многофайловая структура программы
Main loop
Загрузка/выгрузка ресурсов (текстуры, звуки, модели, анимации)
Пайплайн рендера, opengl или vulkan
Шейдеры
Матрицы, кватернионы, линейная алгебра
Текстуры, форматы текстур
Форматы данных вершин, нормали, тангенты, кости, веса костей
Multi render target, framebuffer, отложенный рендер
Возможно ли это уместить в 2 года обучения? - скорее нет, может ли это отбить желание делать игры? - скорее да. Зато, если пройти весь путь, то "хочу делать игры" будет осмысленным решением и скорее всего всё получится, так как не будет нпоняток и магии.
Ужели в 2024 170 кб или 1.3 мб так иного для 3d рендера и игрового движка? Нет смысла уменьшать размер js, если модели, текстуры, звуки будут весить 10+ мб.
Поставляется со своей UI либой
Это плюс - не нужно шаманить дебаг меню, а модно взять готовое
Не поддерживает реактивность
Ленивая загрузка ресурсов 3д сцены не тривиальная тема, так что в любом случае придётся загружать вручную. В каких-то случаях, окэй, принимаю как минус THREE.js
Шейдеры пишутся в строковых литерах, а не в отдельных файлах
На мой взгляд это плюс, так как можно сделать shaders.json и грузить все разом, а не делать 10 запросов на сервер за каждым файлом.
Копипаст кода через препроцессор а-ля С++ замедляет компиляцию
Шейдеры в любом случае будут компилиться, если вы не кладёте их в кэш, а чтобы положить - нужно их скомпилить хотя бы раз.
Нет автоматической группировки инстансов с одинаковым шейпом
Думаю, это действительно лучше делать ручками, так как инстансинг в принципе возможен только если одинаковый шейдер и одинаковые текстуры (окей, можно взять textureArray, но он не везде может быть и минимальный гарантированный размер - 256 слоёв одинаковых по формату и размеру текстур).
Рендеринг либо треугольниками, либо всё руками на шейдерах
Как бы да, все GPU рендерят либо треугольники, либо линии.
А теперь по плюсам THREE js:
Есть куча стандартных материалов
Есть скелетная и морфовая анимация, блендинг, инверсная кинематика
Поддержка множества форматов 3д моделей, ибо gltf не панацея
Подробная документация
Множество статей, вопросов и ответов, решений проблем новичков
Рендер текста
С Вавилоном вы получаете полноценный движок игры, и нужно делать только игру, а не возиться с рендером, загрузкой/выгрузкой ресурсов и так далее.
Чем не угодил THREE.js, в котором и функционал шире, и поддержка устройств лучше, и примеров больше? Или, например, движок babylon, в котором и 3д графика, и физика?
Постарайтесь ответить без гонора ("Вакансия, разумеется, для интеллектуального меньшинства. Вам она, к сожалению, не подойдёт."), и сарказма ("У нас не только разработчиков нет, но и документации: https://mol.hyoo.ru/#!section=docs"), а по пунктам: у THREE.js / babylon нет, а у $mol есть, или в THREE js / babylon это не настраивается, а у $mol - настраивается, и так далее.
Вы можете настроить в гитхабе Actions так, что при пуше автоматически собирается новая версия вашей утилиты и кладётся в releases. Это ж круто. Можете сделать репу публичной и давать утилиту знакомым, им не нужно будет собирать из исходников.
С версионированием (и гитлабом/хабом) плюсов больше чем с дропбоксом. Я бы на вашем месте сделал выбор в пользу гитхаба, а не ждал пока облака прикрутят фичу игнорирования файлов.
Просмотр и редактирование структуры БД (не через консоль, которая безусловно есть, а через GUI), автодополнение SQL в коде на java / go / node. Подключение к локальным БД и по SSH, удобный редактор таблиц, сразу с поиском по каждой колонке, пагинацией, нормальным копи-пастом, позволяющим как скопировать записи из других таблиц, открытых в IDE, так и из csv файла.
Самое необходимое из этого - подсветка sql в коде проекта, с остальным кое-как справляется либо консоль, либо отдельные клиенты бд.
Из моей практики, потребление оперативки средами jet brains до 4 гб (с запасом). Я считаю это разумной платой за функционал, который предоставляет IDE.
Посмотрите новые switch в java, они на голову выше стандартных с break и {}. Получается компактно и удобно, работает в связке return switch...
switch это тот же map, но в байткоде, а не Map/dict, то есть будет работать быстрее и шанс ошибиться ниже, так как компилятор обязывает проверять все значения из enum, все отнаследованные типы.
.kkrigger, насколько я помню, так и не дошёл до релизной версии, а всё ради минимизации .exe, из-за чего игра гвоздями прибита к win api, и, скорее всего к какой-то конкретной версии винды, так как на win 11 запускается в режиме совместимости с некоторыми багами.
Портируемость - нулевая.
Расширяемость - околонулевая.
Популярность - вечная в сообществе минимизаторов.
Ценность для игрока - мизерная.
Достаточно глянуть на текстуры:
1024х1024 в формате ETC2_RGB займёт 0.5 МБ, плюс простейший MIP = 0.68МБ, условно 0.7 МБ. Brotli / z сожмет до 0.2-0.5 (а зависимости от данных).
В одном материале: цвет, нормаль, металличность, шероховатость. Последние две - одноканальные, их можно сжать до RG, B оставить пустым.
Итого 3 текстуры на 1 материал = 2.1 (1.2 сжатый) МБ.
100 материалов - 120МБ только на текстуры.
Если текстуры не 1к, а 2к, то размер больше в 4 раза (480 мб).
Ещё меши, но они занимают 30-40% от размера текстур.
Анимации - зависит от игры. Может получиться сравнимо с текстурами, а может раз в 5 меньше.
Музыка занимает много, сравнимо с текстурами, возможно больше.
В блендере разделены: меш, арматура, анимация.
В арматуре у костей есть имена, у анимаций - тоже, поэтому переносить анимации между разными скелетами возможно (вроде менять веса у меша для разных арматур тоже).
В 2021 году писал свой экспортер из блендера. Вспоминая размер контекста, который надо хранить в голове, нейронки вряд ли справятся (либо затратите х5 времени на объяснения и проверки, чем написали бы сами).
Дело не столько в объёме, сколько в понимании устройства блендера, так как получить нормали модно несколькими способами, но в первом они будут правильные, а во втором - (0; 0; 0;).
В итоге - да навайбкодить простой экспортер можно, а доводить до product-ready придётся вручную.
Потому и существуют сотни форков, а до ума (установил и работаешь) доведено ноль.
Винду и мак делают корпорации, цель которых - извлекать прибыль, а для этого нужно удерживать пользователей, в том числе предоставляя ему удобство работы за ПК.
У сообщества линукса такой задачи нет - это группа по интересам, где никто никому ничего не должен.
Не припоминаю проблем в винде в ходе использования, но допускаю что они были/есть у других пользователей.
Что делает виндузятник, если на тачпаде ноута скорость скрола слишком высокая? Лезет в настройки и двигает ползунок скорости скрола.
Что делает линуксоид в той же ситуации? Правильно, ищет репо на гите (https://gitlab.com/cczp/act-2/libinput-touchpad-scroll-fix), который компилится в библиотеку и на лету делит скорость скрола, делая её нормальной, а не турбореактивной.
Да, подумать тут приходится, но как-то удобнее на винде всё-таки...
Возможно этот "фикс" ломает навигацию в блендере с тачпада (камера одновременно приближается и крутится). Совершенно точно из-за него жесты в тг и перелистывание страниц в главном меню становятся тугими.
В винде работают жесты в браузере - в линуксе их либо надо настраивать, либо их нет.
В винде скрол инерционный везде, в линуксе - где-то работает, где-то нет, где-то быстрее, где-то медленнее.
В винде нормальный офис, в линуксе - танцы с бубном.
Из плюсов линукса - apt install, но то же самое позволяет сделать WSL, но с удобством винды как основной ОС.
Я хочу работать, а не чинить и настраивать систему и всё равно смириться с тем, что всё брошено на 90%.
Почему сообщество не сконцентрирует силы на одном дистрибутиве, на одном (окей, второе для слабых пк) оконном окружении?
Зачем распылять силы на gnome, kde, xfce, lxde, unity, cinnamon, mate и сотню других недоделок?
Зачем debain, ununtu, kubuntu, lubuntu, xubuntu, mint, popos, elementaryos, fedora и прочие?
Создание ОС и оконного окружения не должно становиться целью, ОС и оконное окружение должно быть инструментом.
В винде и эппле 1 система и 1 оконное окружение. Зато доделано до конца, а в линуксе - зоопарк "бери, допиливай сам".
P.S. речь о линуксе на десктопе / ноуте.
Прокси сервер переносим из системы в систему, скорее всего сделан так, что позволяет закрыть несколько ресурсов (доменов) в одной системе, а скрипт из папки привязан к архитектуре и языку одной конкретной системы.
В маленьких проектах лучше скрипт в папке, в проектах побольше - прокси сервер.
У компиляторов и VM процесс перевода "код -> асм" детерминирован, исчерпывающе протестирован, описан в документации, а в случае ошибок указывает вплоть до символа где опечатка, или RuntimeException.
Что же будет в случае, если интерпретатор заменит AI? Миллиард цифр и вперёд, отлаживай. Поведение "примерное", результат "в целом нормальный", а какие-то граничные случаи приведут к сбоям, уязвимостям.
Работать оно будет, конечно, но скорее всего для пет проектов и прототипов, а более-менее серьёзные системы будут писаться на обычных ЯП, а не AI-first.
Этой байке Сократа о "последнем поколении" 2 тысячи лет.
ИМХО, Смотря с какой java сравнивать. Последняя LTS 21 очень даже хороша с var, виртуальными потоками, pattern matching'ом, записями, try with resources и другими полезными нововведениями.
Крупняк пока переходит с 8 явы, но новые проекты можно начинать на 21 версии и получить все плюшки, либо начинает на kotlin.
Отличная идея, учитывая что через JS можно запросить FullScreen и рисовать на нём что угодно, например синий экран смерти или что-то подобное :)))
О, спасибо. Обновлю QR и код, как будет время.
Смотря какие игры и как программировать.
На юнити или скретче можно "программировать" игры с помощью чат-гпт, и весь процесс будет казаться магией (в которой не особо хочется разбираться, так как она отдана на аутсорс нейросетке). Польза от такого программирования сомнительная, хотя простая игра может получиться, замотивировав идти дальше.
Скилл программирования при подходе "напиши задачу или скопируй ошибку нейросетке" не растёт, и в результате получится очередной гпт-программист, не способный перевернуть строку.
Второй способ - начинать с CS, с машинного уровня. В геймдеве с этим скорее всего придётся столкнуться, когда речь зайдёт об оптимизации или минимальной защите игры от взлома. Но такой подход долгий и за 2-3 года может пропасть желание "изучать IT, чтобы делать игры", а игры не будет. Зато может появиться стремление к чему-то другому: бэк, фронт, мобайл, дизайн, десктоп, тестирование, аналитика и так далее.
Вопрос поиска баланса при запросе "хочу научиться делать игры" для меня остаётся открытым, уж слишком много надо для этого изучить, чтобы сделать что-то сложнее (а в большинстве случаев это именно так) гиперказуалок.
Мой список того, что нужно изучить, чтобы начать геймдевить на c++ / java / js:
0. Структурное программирование, операторы, типы данных.
Многофайловая структура программы
Main loop
Загрузка/выгрузка ресурсов (текстуры, звуки, модели, анимации)
Пайплайн рендера, opengl или vulkan
Шейдеры
Матрицы, кватернионы, линейная алгебра
Текстуры, форматы текстур
Форматы данных вершин, нормали, тангенты, кости, веса костей
Multi render target, framebuffer, отложенный рендер
Анимации (кости, кватернионы, матрицы, интерполяции)
Сеть - сокеты / http / websocket
Бэк, если есть сеть. Стек не важен, главное не пхп.
Многопоточность, синхронизация
Физика - какой-либо движок, aimo.js, bullet
Аудио
GUI, рендер элементов управления, рендер текста, статические и динамические шрифты
3д моделирование, текстурирование, риггинг, анимации
Список можно продолжать.
Возможно ли это уместить в 2 года обучения? - скорее нет, может ли это отбить желание делать игры? - скорее да. Зато, если пройти весь путь, то "хочу делать игры" будет осмысленным решением и скорее всего всё получится, так как не будет нпоняток и магии.
Таков путь. В начале чувственно изучаешь мир, потом агрегируешь до эмпирических правил, потом принимаешь как теорию.
В данном случае чувственные измерения не дали ответа, и поиск продолжился в области математики.
Ужели в 2024 170 кб или 1.3 мб так иного для 3d рендера и игрового движка? Нет смысла уменьшать размер js, если модели, текстуры, звуки будут весить 10+ мб.
Это плюс - не нужно шаманить дебаг меню, а модно взять готовое
Ленивая загрузка ресурсов 3д сцены не тривиальная тема, так что в любом случае придётся загружать вручную. В каких-то случаях, окэй, принимаю как минус THREE.js
На мой взгляд это плюс, так как можно сделать shaders.json и грузить все разом, а не делать 10 запросов на сервер за каждым файлом.
Шейдеры в любом случае будут компилиться, если вы не кладёте их в кэш, а чтобы положить - нужно их скомпилить хотя бы раз.
Зато есть стандартные материалы, например https://threejs.org/docs/#api/en/materials/MeshStandardMaterial
Думаю, это действительно лучше делать ручками, так как инстансинг в принципе возможен только если одинаковый шейдер и одинаковые текстуры (окей, можно взять textureArray, но он не везде может быть и минимальный гарантированный размер - 256 слоёв одинаковых по формату и размеру текстур).
Как бы да, все GPU рендерят либо треугольники, либо линии.
А теперь по плюсам THREE js:
Есть куча стандартных материалов
Есть скелетная и морфовая анимация, блендинг, инверсная кинематика
Поддержка множества форматов 3д моделей, ибо gltf не панацея
Подробная документация
Множество статей, вопросов и ответов, решений проблем новичков
Рендер текста
С Вавилоном вы получаете полноценный движок игры, и нужно делать только игру, а не возиться с рендером, загрузкой/выгрузкой ресурсов и так далее.
Чем не угодил THREE.js, в котором и функционал шире, и поддержка устройств лучше, и примеров больше? Или, например, движок babylon, в котором и 3д графика, и физика?
Постарайтесь ответить без гонора ("Вакансия, разумеется, для интеллектуального меньшинства. Вам она, к сожалению, не подойдёт."), и сарказма ("У нас не только разработчиков нет, но и документации: https://mol.hyoo.ru/#!section=docs"), а по пунктам: у THREE.js / babylon нет, а у $mol есть, или в THREE js / babylon это не настраивается, а у $mol - настраивается, и так далее.
А ещё "привет, вонь", что делает необходимым не только бокс, но и вентиляцию.
GitLab CE, GitHub - ваш выбор. Версионирование, коммиты, Actions / CI/CD.
Вы можете настроить в гитхабе Actions так, что при пуше автоматически собирается новая версия вашей утилиты и кладётся в releases. Это ж круто. Можете сделать репу публичной и давать утилиту знакомым, им не нужно будет собирать из исходников.
С версионированием (и гитлабом/хабом) плюсов больше чем с дропбоксом. Я бы на вашем месте сделал выбор в пользу гитхаба, а не ждал пока облака прикрутят фичу игнорирования файлов.
Просмотр и редактирование структуры БД (не через консоль, которая безусловно есть, а через GUI), автодополнение SQL в коде на java / go / node. Подключение к локальным БД и по SSH, удобный редактор таблиц, сразу с поиском по каждой колонке, пагинацией, нормальным копи-пастом, позволяющим как скопировать записи из других таблиц, открытых в IDE, так и из csv файла.
Самое необходимое из этого - подсветка sql в коде проекта, с остальным кое-как справляется либо консоль, либо отдельные клиенты бд.
Ежели у вас 4 гб оперативки, то все верно.
Из моей практики, потребление оперативки средами jet brains до 4 гб (с запасом). Я считаю это разумной платой за функционал, который предоставляет IDE.