122
> Просьба потестировать и сообщить о тормозах, багах, и всяком таком.
Что-то не то с управлением. Ось Y мыши работает в мировом пространстве, а нужно в локальном.
Mikle
> Ось Y мыши
Как я понимаю, это гимбал лок. Как его исправить глобально мне пока неясно.
Локально он тут особой роли не играет, летишь то все равно только вперед.
122
> Локально он тут особой роли не играет, летишь то все равно только вперед.
Ну... я сразу повернул, нужно же исследовать.
122
> Как его исправить глобально мне пока неясно.
Матрицы, самое простое.
Mikle
У меня поворот вершин идет по обычной формуле поворота точки в плоскости.
Типа вот такого, псевдокод.
x_new=x_center + (sinXY*x_lever) - ( cosXY*y_lever); y_new=y_center + ( cosXY*x_lever) + ( sinXY*y_lever);
Соответственно, последовательно поворачивают вершину во всех трех плоскостях. Так работает сейчас. Однако, чтобы исправить гимбал лок, мне требуется до этого повернуть углы так, чтобы они оказались в локальной системе камеры. В общем на сейчас не справился с этим.
Как всегда инвертмаус приходится добавлять самому.
0000BD97: D6 F2 0000BD9E: 74 54
122
Сергей, то что у тебя описано это как раз те формулы, которые используются при умножении вектора позиции вершины на матрицу поворота. Плюсую совету от Mikle по поводу использования матриц. Если освоишь их, то откроешь для себя новые чудесные возможности однородных преобразований и более наглядный код, который превратится из множества строчек с тригонометрическими функциями во что то простое типа V_nex = Center + V * Rotation в одну строчку. А внутри этой арифметики уже будут работать синусы и косинусы скрытые от твоих глаз уровнем абстракции.
21 год жду игру про автобус и кукурузу!
Vitorio
> Плюсую совету от Mikle по поводу использования матриц.
Однородность конечно красиво, но она требует жертв: в несколько раз больше действий получается. Внешне всё выглядит как одной действие, а по-факту там дохрена всяких умножений производится.
Хотя, для ускорения и упрощения разработки советую.
Графика - кул, напомнило игры с первой PS.
Болиды порой полностью перекрывают вид, может, делать их полупрозрачными при приближении к камере? Или полностью скрывать.
При столкновениях часто автобус разворачивает так сильно, что сложно вернуться на трассу, или за первым столкновением следует сразу пачка дополнительных, слишком реалистично)
122
Не планируешь ли дальше использовать воксели, рейтрейсинг? Тоже интересная тема
Epsilon
> Однородность конечно красиво, но она требует жертв: в несколько раз больше
> действий получается. Внешне всё выглядит как одной действие, а по-факту там
> дохрена всяких умножений производится.
Зависит от кривизны рук.
Если ты пишешь
v1 = M1*M2*v2
то да, в несколько раз больше действий. Фикс очевиден, не?
Правда я знаю чела, которого так достало выискивать места "очевидного фикса", что он вообще забанил M*v, а вместо сделал v*M
Kott
> Не планируешь ли дальше использовать воксели, рейтрейсинг? Тоже интересная тема
После создания даже этой небольшой игры выявились неудобства, их и стану решать. Попробую сделать движок удобнее.
Вообще в далеком будущем хотелось бы конечно всяких рейтрейсингов, физики. Но это наверное сложно.
entryway
> Как всегда инвертмаус приходится добавлять самому.
Вот ты упорный. :) Я когда игру делал и так и так играл. И с инвертированной, и с такой мышкой, 10-20 минут было на перепривыкание. Так-то понятно, что в большой игре надо будет инверт осей давать.
Слушай, а ты Идой дизасмиш? Скажи, мне просто любопытно, принципы алгоритма моей растеризации ты можешь так понять? Насколько она вообще дает наглядный результат?
Vitorio
> Если освоишь их, то откроешь для себя новые чудесные возможности однородных
> преобразований и более наглядный код
Понятно. Но сколько раз пытался освоить их, только мозги расплавил. :)
Kott
> Болиды порой полностью перекрывают вид, может, делать их полупрозрачными при
> приближении к камере?
С полупрозрачностью сейчас не оч. Из-коробки ее нет кроме стекол, и даже если добавлю, это будет дополнительный проход по экрану, долго.
А кто-то знает, как вообще делали полупрозрачность в софтрендерах типа Квейка2? Ну ведь получается овердро, тормоза.
122
> Понятно. Но сколько раз пытался освоить их, только мозги расплавил. :)
Короче на хитрожопые матрицы 4х4 забей пока.
для поворота достаточно матрицы 3х3.
Матрица 3х3 состоит из трёх векторов.
Первый - это во что надо перевести (1,0,0)
Второй - это во что надо перевести (0,1,0)
Третий - это во что надо перевести (0,0,1)
Любой вектор это линейная комбинация координатных векторов. Значит надо составить такую же линейную комбинацию из составляющих матрицы.
Для переноса заведи отдельно вектор.
Короче матрица 3х3 + вектор задаёт любое аффинное преобразование пространства.
Про расплавление мозгов и матрицы ты зря короче. Я ж ещё про кватернионы написать хотел, но решил, что не стоит. Потому что в них уже как раз действительно надо врубаться, конкретно так. При этом толк от них - лишь более быстрая композиция поворотов и экономия памяти.
122
> А кто-то знает, как вообще делали полупрозрачность в софтрендерах типа Квейка2?
Ну я могу идеек кинуть. Только скажи, какие у тебя градации есть на полупрозрачность? Если три градации (0,1/2,1), то идейку кину. Помню, зефирчик, увидев мою формулу, потом ещё пару лет кукарекал разорванным задом что-то типа "да ты только битики двигать умеешь".
Плохо помню Ку2, но вот в Хексене2 была лишь одна градация: 1/2. Для неё формула вообще тупая.
122
> Слушай, а ты Идой дизасмиш? Скажи, мне просто любопытно, принципы алгоритма
> моей растеризации ты можешь так понять? Насколько она вообще дает наглядный
> результат?
Вряд ли. Это Barabus у нас любитель принципы разбирать с дизасма. Идой, да. Поискал по коду cmp *, 200h (wm_mousemove), посмотрел куда сохраняется yPos, нашел где оно считывается, ну и где-то там в окрестностях поменял
sub esi, edx; mov [bla-bla], esi
на
sub edx, esi; mov [bla-bla], edx
В ку2 софтваре прозрачность через извращения с палитрами
http://fabiensanglard.net/quake2/quake2_software_renderer.php
Тема в архиве.
Тема закрыта.