Ну, во-первых, всё ещё не ясно, что уберут, а что нет. К тому же позже могут вернуть в любой момент, да и в целом никто не заставляет использовать 4-ку, ведь 3-ка никуда не денется и может развиваться отдельно.
Во-вторых, 4-ка всё-таки больше про vulkan, который не является панацеей, потому как многое железо просто его не потянет. Вот как моя карточка, допустим. Поэтому мне особо незачем менять 3-ку на 4-ку, если я хочу уровень графики gles3, а его там не окажется.
Спасибо.
Оно не случайно Вангеров напоминает :) тут в целом собраны некоторые их основные механики.
У меня, кстати, Radeon HD8670m, AMD A10, 4Мб оперативки. Gles3 с тенями в fullscreen более менее сносно работает в Windows 8.1 (видеоролики записываю на машине помощнее, чтобы чуть большее разрешение и запись не съедала fps). Альтернативной ОС стоит Manjaro KDE Plasma, там с тенями уже похуже на свободном дайвере работает (проприетарные пока не пробовал ставить, dual graphics — это в принципе проблемная штука, но, допустим, Godot и разные версии Blender'а с текущим драйвером уже юзабельны в Manjaro), но с выключенными тенями в целом нормально. До недавней переустановки системы тут была комбинация Windows 7 и Deepin. В Win 7 работало примерно так же, как на 8.1, а вот Deepin был тормознее чем Manjaro.
Добавил сборки под linux и win32 на gles2 рендере. Какие-то шейдеры отвалились, но более менее подправил частицы и некоторые материалы.
Как-то так выглядит gles2 версия:
По всей видимости не тянет gles3-рендер. Но у Godot есть ещё gles2, просто там как минимум отвалятся частицы при конвертировании и нужно будет их переделать. Попробую тогда собрать вариант на gles2.
Ну тут стандартная сборка Godot для windows. Просто не уточнял как собираются для 32. Видимо, там нужно просто галочку Binary Format — 64 Bits снять. Если так, то получается могу собрать для 32.
Скорее уж смартфоны в перспективе сожмутся до габаритов волшебной палочки, которая умеет в более продвинутое альтернативное управление, хотя бы голосом, и нечто вроде голограмм.
А гибкие дисплеи в рамках современных технологий — это не серьёзно. Просто у этого есть продающий вау-эффект, поэтому покупатели найдутся. Я уже видел желающих, которые ничего даже слышать не хотят против — дай им, и всё, как дети.
Были вот складные телефоны, например. Я с такого прямо начинал — подарили. Когда взял позже обычный, то не понял, зачем складные вобще были нужны — в обычном всё было куда оптимальнее.
Или вот сейчас, когда диагональ смартфонов проскочила какой-то разумный уровень и начинает расти куда-то не туда. Притом сразу у всех производителей, почти не оставляя вариантов. Вот чем их 5 и 5.5 не устраивали? Как по мне — самый комфортный диапазон, мне больше не нужно. Как и не нужны никакие складные или гибкие.
Вот потребитель хочет новаций ради новаций, хочет 7 дюймов и сгибать в трёх местах — пусть, только это какой-то излишний жир, давайте называть вещи своими именами. Не все прорывы одинаково полезны. Не все из них влекут за собой действительно глобальные качественные изменения.
Просто в различных примерах, да и в исходниках, любят писать наглядным образом, везде используя $… Но есть вот такие нюансы, малозаметные пока подобных обращений в коде немного и они не начинают массово скапливаться в цикле.
Подобные способы взятия узлов ($AnimatedSprite, $Timer и прочие $...) стоит кэшировать, например: onready var this_sprite = $AnimatedSprite
onready var for_timer = $Timer
чтобы обращаться к ним так: this_sprite.play(«show») вместо $AnimatedSprite.play(«show»)
Становится менее наглядно, но следует помнить, что каждый такой $… аналогичен вызову get_node() и при использовании в цикле потери времени на это могут стать заметными. Попутно от подобного кэширования дополнительная польза на будущее, если целевой узел вдруг сместится в иерархии, то не надо будет править пути к нему по всему коду.
А так, вне циклов, обращения через $… более оправданы, в том плане, что так проще/нагляднее и потери могут быть почти неощутимы.
Просто есть разные подходы — показывать только уже исключительно законченную вещь либо показывать итерации. У этого всего есть свои определённые плюсы/минусы. К тому же, допустим, прототипы на то и прототипы, что не все из них имеет смысл развивать в нечто большее.
Есть ещё такая вещь как Voxel Tools (кастомная сборка движка на основе версии 3.2.2): https://github.com/Zylann/godot_voxel
Там реализован вывод бесконечных, как-бы «воксельных» ландшафтов. По факту это технология marching cubes, перепаивающая полигональную сетку.
Я собирал вот такой прототипчик с паучком, работая в этой «воксельной» сборке (правда видео захвачено на не особо мощном железе, к тому же тени тут отключены):
Ёмко.
Кстати, соглашусь с важной ролью ограничений, благодаря которым появляются специфические геймплеи или способы реализации чего-то внутри игры, организации пространств и так далее. Собственно, в статье и описаны различные подходы к устройству прототипа, которые выросли в процессе разработки из специфики того или иного движка. Да и в целом сама полигональная графика и её пайплайны тоже выросли из ограничений, потому как считать реалтайм 3д через «честные» воксели — драматически непроизводительно. Или вот такой особый «переходный» поджанр, как 3d игры с фиксированной камерой и пререндеренными задниками. Да даже в эпоху 2д тоже хватало своих «нечестных» трюков и ухищрений, чтобы обходить ограничения и добиваться адекватной производительности.
Тоже в качестве C# движка рассматриваю Stride как один из интересных вариантов. Потому как в Unity на шарпе замечательно всё писалось и хотелось бы чего-то подобного. Вот почему и взялся за Unigine, в котором эта возможность тоже есть, хотя пока в основном описано невизуальное использование скриптового языка. Но опыт Unity туда хорошо переносится. В Godot, напротив, выбрал всё-таки внутренний GDScript, потому как из нескольких скриптовых языков в движке я лучше возьму тот, который лучше проработан и интегрирован. Тем более отличия от шарпа не такие большие, чтобы это было какой-то прям проблемой — пишешь себе логику и пишешь.
Как мне кажется, повышению интереса к движку способствуют разрабатываемые на нём проекты, в том числе силами самих разработчиков движка. Может даже чисто демонстрационные. Чтобы наглядно показать пайплайны, инструментарий. Опять же — лишние инфоповоды, вроде новостей из дневников разработки, но не касаемо самого движка, а каких-то прототипов на его основе.
Лучше всего даже каких-то супер-простых, от которых новоприходящим разработчикам проще моддить свои проекты. Даже в том же Unity не сразу к этому пришли — относительно недавно (хотя на сайт к ним давно не заглядывал) на сайте появились официальные мини-проекты с разбором отдельных элементов, вроде простой гонки, шутера и так далее.
Я просто вспоминаю, как начал делать игры на том же Flash именно после того как нашёл где-то на Kongregate пошаговое руководство по написанию простой леталки. В итоге около десятка игр на эту платформу написал. Хотя, конечно, сам интерес к разработке на Flash изначально появился не от наличия туториала, а по иным причинам, но без существования этой точки старта я в то время, наверное, продолжал бы использовать Blitz3d или ушёл в какие-то другие среды разработки.
В случае со входом в Blitz3d тоже попалась некоторая обучалка возможностям и примеры сборки чего-то простого. А на Unity можно было относительно просто вкатиться благодаря сторонним мини-прототипам в асстет-сторе, пока не было расписанных пошаговых официальных.
Просто когда у движка на официальном канале последнее видео годовой давности, а прочие аж 7-летней, то это как-то не очень способствует популяризации. Тем более, что какие-то новые версии они выкатывали не 7 лет назад и как раз есть повод поснимать каких-то новых видео/туториалов и всякого подобного.
Во-вторых, 4-ка всё-таки больше про vulkan, который не является панацеей, потому как многое железо просто его не потянет. Вот как моя карточка, допустим. Поэтому мне особо незачем менять 3-ку на 4-ку, если я хочу уровень графики gles3, а его там не окажется.
Оно не случайно Вангеров напоминает :) тут в целом собраны некоторые их основные механики.
У меня, кстати, Radeon HD8670m, AMD A10, 4Мб оперативки. Gles3 с тенями в fullscreen более менее сносно работает в Windows 8.1 (видеоролики записываю на машине помощнее, чтобы чуть большее разрешение и запись не съедала fps). Альтернативной ОС стоит Manjaro KDE Plasma, там с тенями уже похуже на свободном дайвере работает (проприетарные пока не пробовал ставить, dual graphics — это в принципе проблемная штука, но, допустим, Godot и разные версии Blender'а с текущим драйвером уже юзабельны в Manjaro), но с выключенными тенями в целом нормально. До недавней переустановки системы тут была комбинация Windows 7 и Deepin. В Win 7 работало примерно так же, как на 8.1, а вот Deepin был тормознее чем Manjaro.
Как-то так выглядит gles2 версия:
А гибкие дисплеи в рамках современных технологий — это не серьёзно. Просто у этого есть продающий вау-эффект, поэтому покупатели найдутся. Я уже видел желающих, которые ничего даже слышать не хотят против — дай им, и всё, как дети.
Были вот складные телефоны, например. Я с такого прямо начинал — подарили. Когда взял позже обычный, то не понял, зачем складные вобще были нужны — в обычном всё было куда оптимальнее.
Или вот сейчас, когда диагональ смартфонов проскочила какой-то разумный уровень и начинает расти куда-то не туда. Притом сразу у всех производителей, почти не оставляя вариантов. Вот чем их 5 и 5.5 не устраивали? Как по мне — самый комфортный диапазон, мне больше не нужно. Как и не нужны никакие складные или гибкие.
Вот потребитель хочет новаций ради новаций, хочет 7 дюймов и сгибать в трёх местах — пусть, только это какой-то излишний жир, давайте называть вещи своими именами. Не все прорывы одинаково полезны. Не все из них влекут за собой действительно глобальные качественные изменения.
onready var this_sprite = $AnimatedSprite
onready var for_timer = $Timer
чтобы обращаться к ним так:
this_sprite.play(«show») вместо $AnimatedSprite.play(«show»)
Становится менее наглядно, но следует помнить, что каждый такой $… аналогичен вызову get_node() и при использовании в цикле потери времени на это могут стать заметными. Попутно от подобного кэширования дополнительная польза на будущее, если целевой узел вдруг сместится в иерархии, то не надо будет править пути к нему по всему коду.
А так, вне циклов, обращения через $… более оправданы, в том плане, что так проще/нагляднее и потери могут быть почти неощутимы.
https://github.com/Zylann/godot_voxel
Там реализован вывод бесконечных, как-бы «воксельных» ландшафтов. По факту это технология marching cubes, перепаивающая полигональную сетку.
Я собирал вот такой прототипчик с паучком, работая в этой «воксельной» сборке (правда видео захвачено на не особо мощном железе, к тому же тени тут отключены):
Кстати, соглашусь с важной ролью ограничений, благодаря которым появляются специфические геймплеи или способы реализации чего-то внутри игры, организации пространств и так далее. Собственно, в статье и описаны различные подходы к устройству прототипа, которые выросли в процессе разработки из специфики того или иного движка. Да и в целом сама полигональная графика и её пайплайны тоже выросли из ограничений, потому как считать реалтайм 3д через «честные» воксели — драматически непроизводительно. Или вот такой особый «переходный» поджанр, как 3d игры с фиксированной камерой и пререндеренными задниками. Да даже в эпоху 2д тоже хватало своих «нечестных» трюков и ухищрений, чтобы обходить ограничения и добиваться адекватной производительности.
Тоже в качестве C# движка рассматриваю Stride как один из интересных вариантов. Потому как в Unity на шарпе замечательно всё писалось и хотелось бы чего-то подобного. Вот почему и взялся за Unigine, в котором эта возможность тоже есть, хотя пока в основном описано невизуальное использование скриптового языка. Но опыт Unity туда хорошо переносится. В Godot, напротив, выбрал всё-таки внутренний GDScript, потому как из нескольких скриптовых языков в движке я лучше возьму тот, который лучше проработан и интегрирован. Тем более отличия от шарпа не такие большие, чтобы это было какой-то прям проблемой — пишешь себе логику и пишешь.
Лучше всего даже каких-то супер-простых, от которых новоприходящим разработчикам проще моддить свои проекты. Даже в том же Unity не сразу к этому пришли — относительно недавно (хотя на сайт к ним давно не заглядывал) на сайте появились официальные мини-проекты с разбором отдельных элементов, вроде простой гонки, шутера и так далее.
Я просто вспоминаю, как начал делать игры на том же Flash именно после того как нашёл где-то на Kongregate пошаговое руководство по написанию простой леталки. В итоге около десятка игр на эту платформу написал. Хотя, конечно, сам интерес к разработке на Flash изначально появился не от наличия туториала, а по иным причинам, но без существования этой точки старта я в то время, наверное, продолжал бы использовать Blitz3d или ушёл в какие-то другие среды разработки.
В случае со входом в Blitz3d тоже попалась некоторая обучалка возможностям и примеры сборки чего-то простого. А на Unity можно было относительно просто вкатиться благодаря сторонним мини-прототипам в асстет-сторе, пока не было расписанных пошаговых официальных.