Матрицы и сгенерированный мозаичный мир, как сгенерировать ребра?

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

Я хочу сгенерировать края моего мозаичного мира. У меня есть основные 8 ребер. У меня есть массив целых чисел, которые представляют мои плитки. 0 — вода, 1 — трава. Я хотел бы добавить свои края, переход между водой и травой. Мои края от 10 до 17.

int edges[3][3] =
{
    {10, 11, 12},
    {13,  0, 14},
    {15, 16, 17}
};

Первое, что я думаю, это то, что это напоминает матрицы. Я знаю, что у меня есть объект матрицы 3 на 3 с моей графической библиотекой. Существуют ли какие-либо стандартные операции с матрицами или масками для умного применения моих краев к моим плиткам?

Существует ли стандартная формула для слияния ребер? Например, если правый нижний угол перекрывается с плиткой травы, возможно, я бы просто не стал менять ее значение, однако, если правая нижняя часть перекрывается с верхней левой, я хочу изменить эту плитку на траву (0). Индивидуальных сценариев гораздо больше, и проблема становится сложной.

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

Это также напоминает мне о сглаживании, интересно, есть ли соответствующая формула в этой области.

В идеале решение должно быть оптимальным. Например, у меня была бы какая-то маска, подобная приведенной выше, и, добавляя ее к каждому тайлу травы в массиве, я бы затем получал уникальные значения для углов и сторон, чтобы я мог преобразовать их в изображения краев.


c++ game-engine tile procedural-generation
person user3345413    schedule 30.04.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Сначала различайте логику и визуализацию. Наверное, имеет смысл иметь массив, где каждая ячейка — это либо трава, либо вода для игровой логики (назовем его a). Из этого вы создаете второй массив для хранения того, как отображается эта ячейка, и учитывайте края (давайте назовем его v).

Чтобы вычислить v из a, вы можете посмотреть на проблему следующим образом: для каждой ячейки v_ij в v вы хотите вычислить, как ее отобразить в зависимости от a_ij и значений из соседних ячеек.

Пример:

Это значения в a:

0 0 0
1 0 0
1 1 1

Как бы вы визуализировали ячейку посередине?

Без учета симметрии у вас фактически есть 2^8=256 разных случаев.

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

Вы можете получить индекс в этой таблице поиска, пройдя через 8 ячеек, таким образом получив 8 раз 0 или 1, и установив это как биты целого числа без знака.

В приведенном выше примере вы, например, получите 000 100 111 = 39, то есть 39-ю запись в вашем поиске.

person Danvil    schedule 30.04.2014
comment
Вы делали это раньше! лол, мне очень нравится ваше решение, большое спасибо, я предполагаю, что нет стандартной матричной операции для сдвига битов в int? Собираюсь просто использовать массивы и никаких матриц, я предполагаю, что не будет никакой аппаратной оптимизации для хранения этих 3 на 3 в матрице. - person user3345413; 30.04.2014