Тысяча вариантов 3-в-ряд с разными скинами?

н

Самые разные.

Он говорил, что в основном его просили делать клонов.

Ну это очевидно, на заказ же.

И курсовые делал на Юнити.

Он говорит, что в Юнити всё предустановлено, что довольно удобно при билде под андроид. Говорил, что там игру со своей физикой почти невозможно сделать, ведь она там работает через анус, то бишь бросанием лучей даже тогда, когда это не требуется.

Говорил, что весит очень много(ну это уже проверено мною).

Ууу, в современности, когда SSD стоят пучок за пятачок, объём перестаёт играть какую-то роль. Плюс, если ты собрался серьёзно девелопить — изволь выложить 50-100к рубликов на машинку. Если собрался девелопить в ВР — 150-200к. Объём занимаемого пространства вообще не играет роли.

Ну и в Юнити 2д хреновое, там это как 3д, но камера ограничена. Это, конечно, можно использовать для своей выгоды, но это скорее исключение.

Ужас

На самом деле в ловке та же фигня. 2д в ловке — это 3д, но с ограничениями.

Мало того, абсолютно везде где есть OpenGL/DirectX — та же фигня.

А Vulkan?

Единственное где ты можешь пользоваться "истинным 2d" — это при копировании текстур в другие текстуры. Считай что рисовать в ловке через ImageData:MapPixel() ))

А Vulkan?

А ты как думаешь? ))

Ты разрушил мой мирок, Снус. ;_;

Кароч, открою одну Маленькую Страшную Тайну: видеокарте глубоко пофигу что обрабатывать: 2д-вершины или 3д или даже 25д. Главное чтобы они преобразовались в двухмерную проекцию, и были данные (вершины с тремя или двумя компонентами, матрицы трансформаций 3х3 или 4х4 и т.д.).

3d - тоже 2d.

Только с извращениями и ещё кучей всего...

:<

Фигня в том, Тони, что ты даже не очень представляешь о чём рассуждаешь, поэтому твой мирок очень сильно отличается от действительности (хотя кто я такой чтобы рассуждать о действительности).

А так — да, в юнити просто по умолчанию все вершины всех объектов трёхкомпонентные. И в 2д это даёт некоторые преимущества (например, сортировка по z-оси, которую в той же ловке нужно или ручками сортировать или через z-буфер).

Я вот Годо рою. Вообще хз, какая там оптимизация, но ходят слухи, что нормальная.

Опять скачешь по технологиям, не изучив их суть )) Карочи, вот тебе цикл статеек для домашнего чтения: https://habr.com/ru/post/310790/ Берёшь такой и читаешь. И усваиваешь. Можешь попрактиковать. Все движки в мире (включая лов2д и годот и юнити) работают примерно по этим принципам. Так что открывай содержание и читай.

Да по чесноку тебе говорю, что не скакаю... Я уже преисполнился пониманием моих целей и требований))))

ООП изучаю.

Ты кое что забыл: базовые знания технологий.

Но как оно поможет мне при создании игры не на голом OpenGL / других граф. библиотек ?

Отлично поможет понять, как работают движки и что там происходит под капотом. И немножко поменьше просадок производительности. И стимул изучать функции самого движка, на тему "а как тут реализована та или иная фигня, и куда её можно приспособить в моей СуперИгре".

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

И как это можно сделать? Я не буду высказывать свои глупые предположения, просто расскажи, пожалуйста

Объединение нескольких шейдеров в одну шейдерную программу, запись в свойства вершин инстансов спрайтов дополнительных параметров с набором требуемых шейдеров для этой вершины (каким квадом обрезать текстурный атлас для данного спрайта для анимации, какие шейдеры использовать и с какими параметрами), и собственно инстанцирование. Это на OpenGL. А в конкретных движках надо смотреть, реализовано ли там такое, или можно ли такое впихнуть ))

Вот ты видел примеры хардварного 3д на TIC80? Вот если ты изучишь базу, сможешь стать достаточно образованным для того чтобы делать так же ))

И как это можно сделать? Я не буду высказывать свои глупые предположения, просто расскажи, пожалуйста

О, кстати, дурацкий вопрос. Вот у тебя есть какой-нибудь движок. Каким образом производится черчение на экране обыкновенной прямой линии? love.graphics.line(), например. Примерный алгоритм действий.

Ну даже не знаю, есть много различных способов. Это надо ещё подумать, какой из них самый оптимизированный...

Ну вот есть примерно три распространённых способа. С видеокартой и без видеокарты (хардвар и софтвар), и одна модификация для обоих.

Ну даже не знаю, есть много различных способов. Это надо ещё подумать, какой из них самый оптимизированный...

Карочи, прямые пиксельные линии — это алгоритм Брезенхэма. Придуман, о боже мой, в 1962 году. С видеокартой, на видяху подаётся вектор и матрица трансформации (смещение/поворот), и она вызывает шейдер (обычно, выбор цвета) для каждого пикселя на линии по алгоритму Брезенхэма. С софтваром, берутся две точки, между ними по алгоритму Брезенхэма же закрашиваются пиксели в текстуре-массиве выбранным цветом. И да, до сих пор не придумали ничего лучше, хотя модификации алгоритма есть, вроде алгоритма Ву, рисующего сглаженную линию.

Угадай, какой тут из алгоритмов какой.

А теперь дуй на википедию читать. Потом прочитаешь про алгоритмы заливки треугольников.

Можно любую фигуру залить заливкой соседних пикселей, которые ещё не закрашены ни в какой цвет

Но это медленно

Да, классическая рекурсивная заливка, крайне дурацкая и так же легко реализуемая.

Но это не про треугольники.

Там интыгралы?

Нет

Почему ты вообще про них вспомнил, мистер?

Да так

Блен, с каждым твоим уточняющим вопросом, складывается впечатление что у тебя в голове прям полная каша.

Я просто якоря закидываю.

Это не моё представление.

Ты тупизмом занимаешься. Засунь якоря куда поглубже и не доставай больше никогда.

У меня его нет))

Ладно, сам буду разбираться.

Если это такой способ сбора данных, то я просто представить не могу, какую информацию ты можешь собрать такими якорями. Запомнить, что "заливка треугольников это интегралы" или "заливка треугольников это не интегралы"? Что вообще тебе может дать такая инфомация?

Блен, с каждым твоим уточняющим вопросом, складывается впечатление что у тебя в голове прям полная каша.

У меня его нет))

И давай уже тогда перебирай сразу всё: "Заливка треугольников это теория чисел?" "Заливка треугольников это математическая статистика?" "Заливка треугольников это конечный автомат?" "Заливка треугольников это моя мама?" "Заливка треугольников это чай с молоком?" Перебирай прям вообще всё. Соберёшь восхитительную, и главное, объёмную базу бесполезных данных, в твоей голове будет прям полная каша, которую ты же старательно собрал.

Ктото учится программировать игры на основе голосов в голове?

😈

Ну вот не иначе.

И давай уже тогда перебирай сразу всё: "Заливка треугольников это теория чисел?" "Заливка треугольников это математическая статистика?" "Заливка треугольников это конечный автомат?" "Заливка треугольников это моя мама?" "Заливка треугольников это чай с молоком?" Перебирай прям вообще всё. Соберёшь восхитительную, и главное, объёмную базу бесполезных данных, в твоей голове будет прям полная каша, которую ты же старательно собрал.

Ну, не совсем. Если правильно тегировать свои знания, то потом можно по тэгам искать и восстанавливать информацию :-)

Условно говоря, «игровой цикл – конечный автомат»

И уже понятно куда копать если забыл вообще всё

Там интыгралы?

А ты знаешь что такое интеграл в геометрическом смысле?

Знаю.

Условно говоря, «игровой цикл – конечный автомат»

Тут есть смысл подбирать что-то по теме, а не случайные умные слова вставлять.

Знаю.

Не ты

Тут есть смысл подбирать что-то по теме, а не случайные умные слова вставлять.

Ну, это да

Ну, это да

А как мы узнаём тему? Правильно, читаем материалы. Ну ты понел.

Вопрос качества этих голосов в голове. Если голоса в голове на основе rnd — ничего путного не напрограммируешь, увы.

Вот у меня коллеги тоже страдают от моих голосов в голове. Особенно учитывая что архитектуру последнего проекта я рисовал😂

Defold опенсорснули. https://defold.com/2020/05/19/Defold-is-now-open-source/

Хотя, не совсем опенсорснули: https://defold.com/license/ Есть пункт, запрещающий продавать оригинальную и изменённую версию движка.

Ребят, я уже совсем голову сломал об эти регулярки. Подскажите, как это делается: есть фраза, разделённая дефисом. Как вычленить часть фразы до или после дефиса? Дефисов может быть более одного, но требуется ориентироваться только первый.

Пробовал так: ^.*( - ) не работает

("asd-qwe"):match("(.-)%-")

Или даже local a, b = ("asd-qwe"):match("(.-)%-(.*)") В a придёт часть до дефиса, в b — после. Если дефисов несколько — в a придёт часть до первого дефиса, в b — вообще всё остальное, включая остальные дефисы, соответственно, для полной обработки можно продолжать использовать эту регулярку над b.

Пробовал так: ^.*( - ) не работает

"-" — служебный символ, для указания символа дефиса его надо экранировать в %-. В скобках у тебя, помимо дефиса есть пробелы. Они будут считаться, то есть "( - )" — это "наименьшая последовательность пробелов + ещё один пробел". Сами скобки указывают на захват определённой группы символов. Группы заставляют регулярку игнорировать всё, кроме захватываемой группы (самих групп может быть несколько). Если попробовать экранировать дефис в "( %- )" — оно будет пытаться искать "пробел + дефис + пробел", и захватывать его, игнорируя всё остальное, это тебе вообще не нужно.

Или даже local a, b = ("asd-qwe"):match("(.-)%-(.*)") В a придёт часть до дефиса, в b — после. Если дефисов несколько — в a придёт часть до первого дефиса, в b — вообще всё остальное, включая остальные дефисы, соответственно, для полной обработки можно продолжать использовать эту регулярку над b.

Спасибо большое! Но у меня не получается вставить переменную. Вот в такой контекст: ... local pattern = { --[[ description, field type, pattern, alt pattern, ... ]] {"test1", ft_string, "%[(.+)%]", }, ... local a, b = ("asd-qwe"):match("(.-)%-(.*)"), {"test2", ft_string, "${a}", }, ... что я делаю неправильно?