Вершинный выполняется один раз на каждую вершину, пиксельный - один раз на каждый пиксель. В вершинном можно подменить координату вершины, а в пискельном - цвет и прозрачность пискеля. Это если вкратце.
Координаты UV передаются из вершинного шейдера в пиксельный через переменную типа varying, которая осуществляет интерполяцию UV-координат для всех пикселей. То есть в вершинном шейдере в неё идёт значение UV для каждой вершины, а в пиксельном из неё берётся уже растянутое равномерно по полигону (наподобие градиента) значение UV.
В шейдере можно работать в любом пространстве координат, хоть в мировом, хоть в локальном, хоть в экранном. Для перевода между ними используются соответствующие матрицы.
Но с UV там есть нюанс, что если не знаешь соотношение сторон спрайта, то не сможешь перейти в другие координаты, поэтому это соотношение надо передавать самому (или не его, а сами координаты уже посчитанные). Не помню, с чем это точно связано, так как шейдеры последний раз открывал давно... (то же самое про глубину, касался только слегка и уже забыл, как работать с буфером глубины в шейдерах).
А мне в целом понятно что в этом шейдере из сабжа куда вставлять. Непонятно что в качестве displace текстур использовать.
Собсно там тебе тело функции main описано. Ну uv нужно либо вручную посчитать либо взять из входных шейдра (в GMS это texCcoords) Потом то что написано 1) Взять пиксель с текстуры смещения 2) Посчитать само смещение 3) И с нужной текстуры брать этот пиксель с учётом посчитанного смещения 4) Крутить текстуру смещения для динамики. Это можно в рассчёте uv добавлять таймер к координатам
Во втором блоке сказано что можно юзать две текстуры смещения. По сути сделать п1 и п2 из предыдущего блока для новой текстуры и по приведённой формуле посчитать итогове смещение
В тертьем блоке говорится что можно добавить ещё одну маску, которая будет влиять на степень смещения пикселей, например чтобы на дереве в каких-то местах листья сильнее шевелились чем в других. И снова приводится блок кода как это сделать.
В четвёртом блоке говорится как сделать Pixel-perfect и снова строчки кода как этого добиться.
Вроде всё понятно если немного в контексте шейдеров. Т.е. понимаешь как он работает и чё делают основные функции.
Тут нет никакого ассмемблера. По крайей мере GLSL (а он почти везде используется и в юнити скорее всего) - это СИ-подобный язык. Синтаксис, функции и макросы - всё как в Си.
Смысл шейдера - обработать пиксель. Ты знаешь его цвет в виде четвёрки значений RGB+alpha и его координаты в текстуре. Ты можешь передавать в шейдер другие значения - числа, массивы и даже текстуры и как-то их вплетать в рассчёты. Таким образом, в шейдере ты пересчитываешь цвет пикселя, который обрабатываешь и возвращаешь его.
Например, у тебя есть две текстуры, которые ты хочешь как-то смешать. В шейдер у тебя попадает текущая текстура и по ней происхорит обработка. Ты можешь взять цвет текущего пикселя с этой текстуры, ты можешь взять цвет пикселя с другой текстуры по тем же самым координатам. В любом случае, у тебя будут значения RGBA, которые ты можешь смешать. Например, ты можешь взять среднее значением между ними или как-то отфильтровать, получая тем самым эффекты наложения подобоно эффектам в фотошопе. А ещё ты можешь взять цвет соседнего пикселя в текстуре и использовать его - тем самым сделав что-то типа смещения (как я понял шейдер в сабже как-то так и работает). Тут важно понимать что у тебя текстура попиксельно обрабатывается и то что ты пишешь в шейдере - это то что обработает и выплюнет цвет одного конкретного пикселя, но у тебя при этом есть контекст о других пикселях в текстуры, и ты можешь использовать его чтоюы достичь крутых эффектов.
А набор функций в шейдерах довольно примитимный. Вот для GLSL, например: http://www.shaderific.com/glsl-functions
Это все возможные функции, ага =) Простые математчиеские функции типа минимума, максимума, косинуса, синуса, ну и немного векторных функций. Во многом просто чтобы работать с цветом и координатами как с векторами, а не писать на каждую компоненту свою строчку кода. Кстати, тут нет функции рандома, например, так что в примерах довольно много обвеса делается для его имитации. Или для обсчёта ячеек Вороного (очень популярный алгоритм)
Все формулы по шейдерам - это пересчёты координат и цвета, и тут, да - сложно понять концепцию. Дело не столько в математике, сколько в вычислениях и алгоритмах. Всё это приходит только с опытом, т.е. прочитав пару книжек - хер что ты напишешь.
Вывод - если хочешь писать шейдеры сам, то нужно засесть за это всёрьез и достаточно надолго, тренируясь, начав с очень простых примеров и постоянно экспериментируя. Мне очень сильно помогает Shadertoy в этом плане.
Почему ты избегаешь изучения вопроса? По своему опыту скажу, что намного проще разобраться в чем-то и спокойно делать, чем пытаться срезать углы и просто использовать готовое решение без понимания. Хотя кажется, что наоборот.
Посмотри, к примеру - https://thebookofshaders.com/
Кроме Туториалов там в архиве есть ещё и Демо. Так что мало не будет. Другое дело что там местами код не самый адекватный, но я не могу одновременно писать реальные проекты и заниматься просветительской деятельностью. Будут проблемы - спрашивай.
Я для этого использую структуры данных. ds_list ds_map ds_queue Это основные Бывает ещё ds_grid для карты, например. Но в них только простые типы данных хранятся - числа, строки. Но каждая их этих структур при создании имеет свой ID, который цифра и который можно использовать в другой структуре. Так можно создать список словарей. В своём последнем опыте для сущностей как ты говоришь я сделал скрипты, которые создавали ds_map с нужными полями, а потом делал из них списки, массивы и т.д. Примерно так:
А потом ходишь по списку когда нужно. Но в данном случае я бы немного по-другому инвентарь делал, чтобы не было повторов. Смысл был - показать как со структурами работать.
Это типа как объекты в JS, только без функуций. Можно как с JSON работать, но там всё хитровыебано, несомтря на наличие функционала для этого.
(Объект o_box нужно создать в списке ресурсов предварительно)
for(i=0; i<15; i++){
box[i]=instance_create(x,y, o_box)// координаты задаются сразу при создании
box[i].name="name"+string(i)// будет name1, name2, ...}
В процессе игры можешь обращаться к любому из них типа box[3].любая_переменная = 123.
Это пример с массивом, можно заводить их в списке:
box_list=ds_list_create()repeat(15)ds_list_add(box_list,instance_create(x, y, box))
Или в словаре, или в сетке, но это зависит от того, что ты проектируешь. Для двухмерного инвентаря лучше использовать ds_grid, для одномерного - ds_list, для просто перечисления всего подряд по ключевым словам (слотам, см. основная экипировка как в Diablo) - ds_map.
Написал такую систему в 2011. Там внутри всё понятно, а если нажать F1 в самом EXE, то ещё и справка по формату скрипта диалогов будет. Правда, на английском, так как планировалось это задействовать в проекте с иностранцами, а то и в маркетплейс продать, но как-то влом было заниматься что тем, что другим, что вообще игру делать. Так и лежит 9 лет в столе, ждёт своего часа, когда я портирую с ГМ8.1 на Студию 1 и потом на Студию 2.
подумаю как сделать специальный системный уровень, чтоб там было всё сразу включая героя, только не придумал как сделать так чтобы системный уровень создавался, если он ещё не был создан
С таким свойством перед методом, этот метод будет запускаться каждый раз, как ты запускаешь игру в редакторе. В методе ты можешь загружать основную сцену со всеми контроллерами и игроком. Так очень просто тестить отдельные уровни - вместо того чтобы сначала загружать сцену-менеджер, а потом уровень (для чего придется либо править каждый раз код, либо менять переменные в редакторе), ты можешь использовать это свойство и проверять, загружена ли сцена-менеджер. Если нет - загружать ее, а потом уже, как обычно, соединять менеджер с загруженной сценой. Для этого поможет объект, который должен существовать в каждом уровне, и ты этот объект ищешь после завершения загрузки сцены и привязываешь его к менеджеру.
Звучит сложновато, но в коде на самом деле просто все. Это позволяет отвязать друг от друга многие элементы и править их по отдельности.
попробуй Space Rogue. Только чтобы не испортить впечатление - не гриндь в ней, иначе откроешь практически весь контент за один заход. Возможность исследования мира это наверно ее главный косяк. и Depth-of-Extinction похожа слегка
Можно попробовать sugarcoat, там синтаксис максимально приближен к Pico-8/Tic-80. Это просто надстройка над love2d, castle, как я понимаю, скачивать не нужно (но это тоже штука забавная).
... и когда через некоторое время, доведя до ума какой-то старый проект, начинали на той же странице новый, оставляя ссылки и медиа-материалы на свою первую игру (в качестве рекламы) и начиная пилить новости уже по второй. Патроны просто по большей части продолжали саппортить следующий проект и всё у ребят было хорошо.
Вершинный выполняется один раз на каждую вершину, пиксельный - один раз на каждый пиксель. В вершинном можно подменить координату вершины, а в пискельном - цвет и прозрачность пискеля. Это если вкратце.
Координаты UV передаются из вершинного шейдера в пиксельный через переменную типа varying, которая осуществляет интерполяцию UV-координат для всех пикселей. То есть в вершинном шейдере в неё идёт значение UV для каждой вершины, а в пиксельном из неё берётся уже растянутое равномерно по полигону (наподобие градиента) значение UV.
В шейдере можно работать в любом пространстве координат, хоть в мировом, хоть в локальном, хоть в экранном. Для перевода между ними используются соответствующие матрицы.
Но с UV там есть нюанс, что если не знаешь соотношение сторон спрайта, то не сможешь перейти в другие координаты, поэтому это соотношение надо передавать самому (или не его, а сами координаты уже посчитанные). Не помню, с чем это точно связано, так как шейдеры последний раз открывал давно... (то же самое про глубину, касался только слегка и уже забыл, как работать с буфером глубины в шейдерах).
А мне в целом понятно что в этом шейдере из сабжа куда вставлять. Непонятно что в качестве displace текстур использовать.
Собсно там тебе тело функции main описано. Ну uv нужно либо вручную посчитать либо взять из входных шейдра (в GMS это texCcoords)
Потом то что написано
1) Взять пиксель с текстуры смещения
2) Посчитать само смещение
3) И с нужной текстуры брать этот пиксель с учётом посчитанного смещения
4) Крутить текстуру смещения для динамики. Это можно в рассчёте uv добавлять таймер к координатам
Во втором блоке сказано что можно юзать две текстуры смещения. По сути сделать п1 и п2 из предыдущего блока для новой текстуры и по приведённой формуле посчитать итогове смещение
В тертьем блоке говорится что можно добавить ещё одну маску, которая будет влиять на степень смещения пикселей, например чтобы на дереве в каких-то местах листья сильнее шевелились чем в других. И снова приводится блок кода как это сделать.
В четвёртом блоке говорится как сделать Pixel-perfect и снова строчки кода как этого добиться.
Вроде всё понятно если немного в контексте шейдеров. Т.е. понимаешь как он работает и чё делают основные функции.
http://www.unity3d.ru/distribution/viewtopic.php?f=35&t=24905
Я же писал стать про шейдеры недавно =)
Тут нет никакого ассмемблера. По крайей мере GLSL (а он почти везде используется и в юнити скорее всего) - это СИ-подобный язык. Синтаксис, функции и макросы - всё как в Си.
Смысл шейдера - обработать пиксель. Ты знаешь его цвет в виде четвёрки значений RGB+alpha и его координаты в текстуре. Ты можешь передавать в шейдер другие значения - числа, массивы и даже текстуры и как-то их вплетать в рассчёты. Таким образом, в шейдере ты пересчитываешь цвет пикселя, который обрабатываешь и возвращаешь его.
Например, у тебя есть две текстуры, которые ты хочешь как-то смешать. В шейдер у тебя попадает текущая текстура и по ней происхорит обработка. Ты можешь взять цвет текущего пикселя с этой текстуры, ты можешь взять цвет пикселя с другой текстуры по тем же самым координатам. В любом случае, у тебя будут значения RGBA, которые ты можешь смешать. Например, ты можешь взять среднее значением между ними или как-то отфильтровать, получая тем самым эффекты наложения подобоно эффектам в фотошопе. А ещё ты можешь взять цвет соседнего пикселя в текстуре и использовать его - тем самым сделав что-то типа смещения (как я понял шейдер в сабже как-то так и работает). Тут важно понимать что у тебя текстура попиксельно обрабатывается и то что ты пишешь в шейдере - это то что обработает и выплюнет цвет одного конкретного пикселя, но у тебя при этом есть контекст о других пикселях в текстуры, и ты можешь использовать его чтоюы достичь крутых эффектов.
А набор функций в шейдерах довольно примитимный. Вот для GLSL, например:
http://www.shaderific.com/glsl-functions
Это все возможные функции, ага =) Простые математчиеские функции типа минимума, максимума, косинуса, синуса, ну и немного векторных функций. Во многом просто чтобы работать с цветом и координатами как с векторами, а не писать на каждую компоненту свою строчку кода. Кстати, тут нет функции рандома, например, так что в примерах довольно много обвеса делается для его имитации. Или для обсчёта ячеек Вороного (очень популярный алгоритм)
Все формулы по шейдерам - это пересчёты координат и цвета, и тут, да - сложно понять концепцию. Дело не столько в математике, сколько в вычислениях и алгоритмах. Всё это приходит только с опытом, т.е. прочитав пару книжек - хер что ты напишешь.
Вывод - если хочешь писать шейдеры сам, то нужно засесть за это всёрьез и достаточно надолго, тренируясь, начав с очень простых примеров и постоянно экспериментируя. Мне очень сильно помогает Shadertoy в этом плане.
Почему ты избегаешь изучения вопроса? По своему опыту скажу, что намного проще разобраться в чем-то и спокойно делать, чем пытаться срезать углы и просто использовать готовое решение без понимания. Хотя кажется, что наоборот.
Посмотри, к примеру - https://thebookofshaders.com/
https://help.yoyogames.com/hc/en-us/articles/217571368
Я помню что сам когда-то их там качал. Вот ссылка сейчас прямая с той страницы:
http://store.yoyogames.com/downloads/gm-studio/StudioAllDemosTutorials.zip
Кроме Туториалов там в архиве есть ещё и Демо. Так что мало не будет. Другое дело что там местами код не самый адекватный, но я не могу одновременно писать реальные проекты и заниматься просветительской деятельностью. Будут проблемы - спрашивай.
https://www.dropbox.com/s/fc3p9qfcx2m56jy/Alexsample.gm81?dl=0 - оно?
Я для этого использую структуры данных.
ds_list
ds_map
ds_queue
Это основные
Бывает ещё ds_grid для карты, например.
Но в них только простые типы данных хранятся - числа, строки. Но каждая их этих структур при создании имеет свой ID, который цифра и который можно использовать в другой структуре. Так можно создать список словарей.
В своём последнем опыте для сущностей как ты говоришь я сделал скрипты, которые создавали ds_map с нужными полями, а потом делал из них списки, массивы и т.д. Примерно так:
А потом ты такой
А потом ходишь по списку когда нужно. Но в данном случае я бы немного по-другому инвентарь делал, чтобы не было повторов. Смысл был - показать как со структурами работать.
Это типа как объекты в JS, только без функуций. Можно как с JSON работать, но там всё хитровыебано, несомтря на наличие функционала для этого.
Есть массив через [], и список ds_list. Почитай доки.
https://docs2.yoyogames.com/
Разделы:
Scripting -> GML Overview -> Arrays
Scripting -> GML Reference -> Data structures -> DS Lists
В Game Maker:
(Объект o_box нужно создать в списке ресурсов предварительно)
В процессе игры можешь обращаться к любому из них типа box[3].любая_переменная = 123.
Это пример с массивом, можно заводить их в списке:
Или в словаре, или в сетке, но это зависит от того, что ты проектируешь. Для двухмерного инвентаря лучше использовать ds_grid, для одномерного - ds_list, для просто перечисления всего подряд по ключевым словам (слотам, см. основная экипировка как в Diablo) - ds_map.
Поставь ColorMania, и сможешь со всего экрана брать цвета пикселей, хоть в хекс, хоть в чём ещё
https://htmlcolorcodes.com
С другой стороны:
https://www.dotpdn.com/downloads/pdn.html
Справа Free Download Now.
https://www.dropbox.com/s/fh5h82fatwswzt9/Dialogue4-1.1.zip?dl=0
Написал такую систему в 2011. Там внутри всё понятно, а если нажать F1 в самом EXE, то ещё и справка по формату скрипта диалогов будет. Правда, на английском, так как планировалось это задействовать в проекте с иностранцами, а то и в маркетплейс продать, но как-то влом было заниматься что тем, что другим, что вообще игру делать. Так и лежит 9 лет в столе, ждёт своего часа, когда я портирую с ГМ8.1 на Студию 1 и потом на Студию 2.
Да, словарь хорош:
Можно использовать такое свойство перед методом:
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
С таким свойством перед методом, этот метод будет запускаться каждый раз, как ты запускаешь игру в редакторе. В методе ты можешь загружать основную сцену со всеми контроллерами и игроком. Так очень просто тестить отдельные уровни - вместо того чтобы сначала загружать сцену-менеджер, а потом уровень (для чего придется либо править каждый раз код, либо менять переменные в редакторе), ты можешь использовать это свойство и проверять, загружена ли сцена-менеджер. Если нет - загружать ее, а потом уже, как обычно, соединять менеджер с загруженной сценой. Для этого поможет объект, который должен существовать в каждом уровне, и ты этот объект ищешь после завершения загрузки сцены и привязываешь его к менеджеру.
Звучит сложновато, но в коде на самом деле просто все. Это позволяет отвязать друг от друга многие элементы и править их по отдельности.
http://www.vst4free.com/free_vst.php?plugin=VST_Speek&id=1863
Встшка есть вот такая нормальная
попробуй Space Rogue. Только чтобы не испортить впечатление - не гриндь в ней, иначе откроешь практически весь контент за один заход. Возможность исследования мира это наверно ее главный косяк.
и Depth-of-Extinction похожа слегка
Уно Моралес хорошо чудовищ и психов рисует.
Можно попробовать sugarcoat, там синтаксис максимально приближен к Pico-8/Tic-80. Это просто надстройка над love2d, castle, как я понимаю, скачивать не нужно (но это тоже штука забавная).
Обычно делаю так
love.graphics.setDefaultFilter("nearest", "nearest")
Вот эта строка не канает:
потому что image - локальная переменная в функции love.load
Есть static. Создаешь статичный публичный класс и указываешь там свои публичные переменные.
где тебе надо обратиться к глобальной переменной
Может что-то неправильно написал, но кажется так (давно классы на C# не писал).
http://www.eyezmaze.com/grow/rpg/
Есть очень много примеров, когда люди регистрировались именно под соусом разработки конкретной игры:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
... и когда через некоторое время, доведя до ума какой-то старый проект, начинали на той же странице новый, оставляя ссылки и медиа-материалы на свою первую игру (в качестве рекламы) и начиная пилить новости уже по второй.
Патроны просто по большей части продолжали саппортить следующий проект и всё у ребят было хорошо.
Knytt Underground, там можно превращаться в весьма прыгучий мяч.
Да и кому нужен гугол, если тут есть поиск.