Там 3 игры бесплатно что ли? Или закавыка какая-то?

И, значит, заплатив условные 3 копейки, получаешь GameMaker: Studio Pro. А почему она не стимовская? Я смотрю, эта программа есть в Стим.

Потому-что убрали из продажи, устарела она. Сейчас уже вторая версия, но в бандле ее нет.

Ну, я смотрю, Кситилон и прочие постоянно в GameMaker: Studio 1 в Стим торчат.
Видимо, 2-я еще не созрела для бандлов. Дорогая она. Потому и дорогая, что очень полезная.

А теперь есть и depth и слой, и без обоих никак!

На самом деле, depth теперь вообще не нужен. Его оставили исключительно для совместимости с проектами, сделанными на ГМС1 -- на практике же он в ГМС2 жутко забагован и категорически не рекомендуется к использованию. Теперь вместо старого доброго "depth = -y" в двумерных изометрических игрушках народ клепает системы для отрисовки спрайтов каждого объекта в порядке, зависимом от координаты y, типа такой.

Теперь представьте, что один объект описывает отображение нескольких изображений в разных местах на разной глубине. На ГМС это сделать нормально невозможно, нужны феерические костыли.

А слои это что-то конфликтующее с depth? Или же можно на одном слое использовать глубину нормально, как раньше? Лол

И зачем ds_grid ? Можно же "приоритетом" автоматически сортировать - я так в Пистоне и делал для полупрозрачных объектов.

Или ещё можно вспомнить, что на самом деле ГМС1\2 это 3Д и просто делать что-то вроде z = -y, но только не уходить дальше плоскостей отсечения.

Это что за покемон?

[deleted]

?

Ну я могу сказать за свой опыт лишь на бэте - у меня depth работал, насколько я помню. Нормально работал. Но там конечно 2,5 объекта были - стены и игрок.

Видео не смотрел, но я понял, что ds_grid это к нему. Вот тут сказались бы твои "некогданенужно" в плане технологий и оптимизаций \якубович\ Тот, кто читал\писал\пытался делать свой движок знают, что вообще более эффективно собирать всю отрисовку в один проход. Т.е. считай список вывода, но в ГМС2(надеюсь) остался ds_priority, который автоматом бы сортировал по какому-то параметру - по Y например.

Да зачем мне вообще z, я хотел бы просто в ПЛАТФОРМЕРЕ правильно depth всем задавать

Кто-то просто не уверует в 3Д! Твой 2Д платформер на самом деле 3Д платформер! ШОК! Только ось Z - направление взгляда, а проекция ортогональная. Поэтому в теории любую 2Д игру на ГМС можно перелопатить в 3Д.

Но я понял о твоих негодованиях относительно instance_create. Вообще, depth\layer это полезно. Но я так и так уже написал обёртку для себя - spawn(object), spawn(x,y,object), так что добавить в теории какую-то глубину\слой нет никаких проблем.

Ну я могу сказать за свой опыт лишь на бэте - у меня depth работал, насколько я помню. Нормально работал. Но там конечно 2,5 объекта были - стены и игрок.

Глубина и слои начинали конфликтовать при переходах между комнатами. Тогда появлялась ерунда с "Layer system integrity compromised", объекты внезапно показывались с неправильной глубиной, а через пару переходов проект и вовсе намертво вис. Кто знает, может, сейчас это уже поправили. Как бы то ни было, раньше документация предостерегала от использования depth и гласила, что глубина была оставлена чисто для совместимости — однако сейчас, как я вижу, её использование очень даже допускается:

You would normally not need to use this variable as you should be setting instances to be added to discreet layers, which in turn are set to a specific depth, but it may be that you want to change the depth of an instance using this value, in which case a "temporary layer" will be created specifically for the instance at the given depth.

Так что есть вероятность, что проблема уже решена.

1. Кситилон всегда прав
2. 2. Если Кситилон неправ, то смотри п.1.

:yak:

Глубина и слои начинали конфликтовать при переходах между комнатами.

А вот это неожиданно. И ведьма странно. У себя там у меня всего 1 комната и была, так что теперь понятно почему я не наткнулся на эту проблему.

Но с чем я согласен, относительно ворчания Кситилона - лучше подождать какое-то время. Там багов поправят, какие-то добавят, где сделают заплатку и будет нормально. А там и на хамбл бандл будет за 1 бакс pro версия. (или нет)

Это как костыль звучит какой-то.

При этом на промо-ролике ГМС2 я видел авто-тайлинг. А где если не в jrpg, или игры с подобным видом он нужен? И вот, в таком виде обычно же и делали depth = -y. 100500 временных слоев как бы странная штука. Но фиг знает.

Смущает еще то, что ГМС1 сразу же выпилили при появлении ГМС2.

Впрочем, в бандле я уже одну ГМС1 купил подарком и отправил другу, у которого ее не было - все работает.

А вообще, для чего нужны слои? Ну кроме удобства в редакторе? Вот когда я делал уровни для Взертоса - в редакторе действительно не хватало слоёв, а для игр-то где это использовать? В Юнити можно рейкасты делать только по определённому слою, например (если я правильно помню), но для 2д игр то зачем? Неужели тоже раскидывать коллайдеры\статичные_твёрдые_тела по слоям? Мне кажется, что глубина всё равно должна работать в рамках хотя бы одного слоя. Глубина это должна быть просто ось Z, ну или в крайнем случае это сортировка уже средствами ГМС такая.

Будь у меня слои, Drillknight отрисовывать было бы куда легче - можно было бы забубенить задний слой и передний. Учитывая, что террейн отрисовывается одним экземпляром одного объекта приходится довольствоваться одним только задним в угоду производительности (в отрисовке каждый шаг приходится перебирать большой массив что и как отрисовать, чтобы сделать передний пришлось бы процедуру делать дважды каждый шаг). А так за один проход я бы рисовал и на заднем, и на переднем.

А что мешает использовать в качестве "слоёв" сурфейсы, в которые производится отрисовка в одном объекте, после чего сурфейсы рисуются отдельно (в другом объекте или в этом же в Draw End или Draw GUI) в необходимой последовательности? Конечно, это увеличит нагрузку (потому что теперь кроме собственно объектов придется рисовать и сурфейсы), но тут уже наука бессильна - ты либо рисуешь сразу на экран, либо в отдельную текстуру, которую потом в любом случае надо рисовать на экран.

Сурфейсы активно используются, но есть в них один нюанс - переключения между сурфами отъедают время, справка настоятельно рекомендует не злоупотреблять. А теперь представьте какая будет нагрузка, если каждый шаг раз этак 500-1000 переключаться с одного сурфа на другой. fps упадет до 2-3 кадров в сек.

если каждый шаг раз этак 500-1000 переключаться с одного сурфа на другой. fps упадет до 2-3 кадров в сек.

Справка немножко преувеличивает (хотя, полагаю, что 1000 смен таргетового сурфейса опустит фпс дл 2-3 кадров, там и не написано), потому что:

При 1200 сменах между двумя сурфейсами размером 2048х2048 игра всё еще выдает ~60 фпс. При том, что моя видеокарта это жифорс 610м (а это одна из самых лоу-эндовых видеокарт, которые можно иметь, и всё еще чувствовать себя хоть немного человеком), а 2048х2048 - совершенно дикий размер для пиксель-арта, и на самом деле требуемый размер сурфейса намного меньше.

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

Уже ничтожных 60 fps. И это без обсчета логики игры и отрисовки. В итоге будем иметь 2-3. Сурфы слоям фиговая замена. Впрочем, останусь все равно на ГМС. Он на directX9 работает.

4600 смен при текстурах размером 768х384, что есть более адекватное разрешение для пиксель-арта, которое я обычно использую. Естественно, у кого-то разрешение экрана побольше, но у таких людей, предположительно, и видеокарта помощнее.

В любом случае, хозяин-барин.

Дело не в хозяин-барин. Вы меряете на пустышке. А в игре просто до хрена всяких расчетов происходит. И ресурсоемкие решения для динамичной игры не подходят. Для примера - создайте какой-нибудь бешеный цикл, который будет у вас выводить 60fps. А потом к этому подключите эту смену сурфейсов - сами увидите насколько упадет.

А зачем делать 100500 переключений сёрфейса вообще? В смысле, почему нельзя установить сёрф один раз и потом N раз отрисовать туда все необходимые объекты?

Идет перебор ячеек сеток. В каждой ячейке объект заднего плана, среднего и мог быть переднего. Для понимания о чем речь - https://youtu.be/BqCN3LCTcYs
Дважды перебирать - падает fps, так как ячейки сетки еще анализировать надо (я пробовал)

Лол, я понимаю, что два ресурсоемких процесса, оставляющих 60 фпс в игре, при сложении дадут намного меньше 60 фпс, спасибо за информацию.

Но я показал, что 60 фпс это результат 4600 свапов (что, на минуточку, в 4.6 раза больше, чем заявленное требуемое количество), поэтому, как нетрудно догадаться, 500-1000 свапов - это намного больше фпс и намного больше остаточной производительности, которой (предположительно) за глаза хватит для игровых вычислений (учитывая то, что отрисовка, наряду с физикой, это в принципе один самых ресурсоемких моментов в игре). Не говоря уже о том, что, можно кэшировать результат отрисовок (за какими-нибудь анимированными исключениями), и перерисовывать только те части бэка, которые изменились (что значительно уменьшит количество и отрисовок, и смен таргетового сурфейса). Насколько такой производительности хватает на самом деле для вашей игры, я понятия не имею. Я не знаю размер отрисовываемой области, я не знаю текущий средний фпс. Если он сейчас и так уже ровно 60, то, конечно, 500-1000 лишних смен всё убьют. Но, в любом случае, сами по себе 1000 смен между не очень большими сурфейсами - это не так уж и страшно, и для игры, которая не использует сложнейший нейросетевой АИ, попиксельную физику или какие-нибудь еще убийственные для производительности вещи, вполне подойдут.

Посмотрел видео от игры. Не совсем понял проблему заднего\переднего плана и земли. Можно подробнее? В смысле проект же на ГМС1? Там есть depth. Или тут про что-то другое, чего я не понял?

Отличная новость!!

Надо брать, а то фиг его теперь найдешь (

Ага, что-то GMS2 мне не очень.