Я шукаю деяке розуміння невеликої проблеми з перекладом одиниць у сітці.
Оновлення та вирішення
Я вирішив власне питання. Детальніше дивіться нижче. Все в цій частині допису виявилося правильним. Якщо що-небудь, це може послужити мініатюрним підручником / прикладом / допомогою для наступної людини.
Налаштування
- FBO, VAO, VBO
- Вікно 512x448
- 64х64 сітка
gl_Position = projection * world * position;
projection
визначаєтьсяortho(-w/2.0f, w/2.0f, -h/2.0f, h/2.0f);
Це функція ортогональної проекції підручника.world
визначається фіксованим положенням камери при (0, 0)position
визначається положенням спрайта.
Проблема
На скріншоті нижче (масштабування 1: 1) інтервал між сітками становить 64х64, і я малюю пристрій у (64, 64), однак блок малює приблизно в 10 пікс в неправильному положенні. Я спробував рівномірні розміри вікон, щоб запобігти будь-яке спотворення розміру пікселів, але тепер я трохи втратив належним чином, забезпечуючи проекцію 1: 1 на світову одиницю проекції. Так чи інакше, ось декілька швидких зображень, які допоможуть у вирішенні проблеми.
Я вирішив супер-нав’язати купу спрайтів на те, що, як вважає двигун, 64-х зміщення.
Коли це здалося поза місцем, я пішов і зробив базовий корпус на 1 одиницю. Який, здавалося, вибудовувався так, як очікувалося. Жовтий показує різницю руху в 1px.
Що я хочу
В ідеалі 64-одиничні переміщення в будь-якому напрямку вивели б наступні (накладені одиниці)
Вершини
Здавалося б, вершини, що надходять у вершину шейдера, є правильними. Наприклад, по відношенню до першого зображення дані виглядають так у VBO:
x y x y
----------------------------
tl | 0.0 24.0 64.0 24.0
bl | 0.0 0.0 -> 64.0 0.0
tr | 16.0 0.0 80.0 0.0
br | 16.0 24.0 80.0 24.0
Для повноти тут представлений фактичний масив, відповідний вищевказаним рухам:
x y z w r g b a s t
-------------------------------------------------------------
tl | 0.0 23.0 0.0 1.0 0.0 0.0 0.0 1.0 0.14210527 0.62650603
bl | 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0 0.14210527 0.76506025
tr | 16.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0 0.2263158 0.76506025
br | 16.0 23.0 0.0 1.0 0.0 0.0 0.0 1.0 0.2263158 0.62650603
-------------------------------------------------------------
-------------------------------------------------------------
tl | 64.0 24.0 0.0 1.0 0.0 0.0 0.0 1.0 0.0 0.21084337
bl | 64.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0 0.0 0.3554217
tr | 80.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0 0.08421053 0.3554217
br | 80.0 24.0 0.0 1.0 0.0 0.0 0.0 1.0 0.08421053 0.21084337
// side bar: I know that I have unnecessary data with having a z-axis.
// The engine flips between perspective and orthogonal and I
// haven't selectively started pruning data.
Матриця проекції
Матриця проекцій для вікна 512x448 виглядає так:
0.00390625 0.0 0.0 0.0
0.0 0.004464286 0.0 0.0
0.0 0.0 -1.0 0.0
0.0 0.0 0.0 1.0
і побудована за допомогою підручника ортогональної функції проекції:
ortho(-w/2.0f, w/2.0f, -h/2.0f, h/2.0f);
// explicitly: ortho(-512/2.0f, 512/2.0f, -448/2.0f, 448.0f
ortho(float left, float right, float bottom, float top)
{
projection.setIdentity();
projection.m00 = 2.0f / (right - left);
projection.m11 = 2.0f / (top - bottom);
projection.m22 = -1;
projection.m30 = -(right + left) / (right - left);
projection.m31 = -(top + bottom) / (top - bottom);
projection.m32 = 0;
}
Матриця світогляду
Положення камери - це лише матриця перекладу, яка в цьому випадку я просто компенсую на -w / 2 та -h / 2 до нуля відносно центру.
1.0 0.0 0.0 -256.0
0.0 1.0 0.0 -224.0
0.0 0.0 1.0 0.0
0.0 0.0 0.0 1.0
Рішення, які я намагався
player.moveRight()
перемістив би 1-одиницю із співвідношенням сторін, врахованим у рівняння. Отже:gridWidth = 64 / 1.14f
. Рух не вкладався в сітку.Вимушено вікно 512x512 з ортогональною проекцією, що відповідає.
Спробував різні магічні числа і спробував встановити співвідношення між ними.
З урахуванням сказаного, все, що мені залишається вірити, - це те, що я змінюю свою реальну прогноз. Отже, я шукаю будь-яку думку про підтримку проекції 1: 1 на світову одиницю.