Demul, эмулятор Dreamcast, Naomi etc.

[CaH4e3]

Вся необходимая информация находится под спойлером ниже:

• Официальный сайт эмулятора
• Официальный русскоязычный форум
• Скачать Demul
• Багтрекер для сообщений об ошибках
• Часто задаваемые вопросы (FAQ)

• Для работы эмулятора требуются: MSVC 2010 Redist x86 а также последний DirectX
• Биосы консоли SEGA Dreamcast в формате эмулятора можно скачать здесь или там

Инструкция Demul в картинках + biospack
Шейдерные фильтры для режима OpenGL можно скачать здесь

[CaH4e3]

Если забор плоский и нормали у него повернуты внутрь ринга, то он может отсекаться не положением камеры, а либо проверкой направления нормали, либо по ориентации треугольников (расположения вершин по часовой либо против часовой).

Это достаточно тривиально. Этот забор по Z в далеких минусах, отрицательные Z режутся (должны) плоскостью видовой проекции. Куллинг по фейсам полигонов включен и работает (должен). Тем не менее эта геометрия все равно появляется на экране. Возможно это глюки программной трансформации (у нее нет отсечения), но перенос этой работы целиком на гпу тоже связан с определенными проблемами.

Добавлено позже:
Камера, кстати - это понятие чисто виртуальное. В рендерах нет такого понятия - куда поставить камеру. Ее положение определяется исключительно трансформацией/поворотом/переносом всей геометрии сцены относительно нулевой точки, соответственно, куда будет перенесена нулевая точка, там будет и камера. Игра с параметрами на гпу невозможна, по причине того, что все делается софтварно - умножение на матрицы трансформации, переносы и прочее. Куллинг и отсечение делает уже потом сам гпу, но уже по экранным координатам, посчитанным в программе, как это делает гпу дрима и рендер эмулятора. Так что это все не так просто, как ты думаешь. Все, что ты говоришь уже давно испробовано.

[DreamZzz]

Ну если программно и камера все-же в нулях, то тупо как-то так:
if (v1->z < 0 && v2->z < 0 && v3->z < 0)
   return нафиг

Все, что ты говоришь уже давно испробовано.

Хтож его знает...

[CaH4e3]

Гага... А теперь внимание, вопрос на понимание: стрип треугольников, половина вершин в положительном полупространстве, половина вершин в отрицательном полупространстве, как минимум один треугольник стрипа - пересекает плоскость отсечения. Как тогда будет выглядеть твой алгоритм?

[DreamZzz]

Гага... А теперь внимание, вопрос на понимание: стрип треугольников, половина вершин в положительном полупространстве, половина вершин в отрицательном полупространстве, как минимум один треугольник стрипа - пересекает плоскость отсечения. Как тогда будет выглядеть твой алгоритм?

Вопрос некорректный. Видимо, ты хотел спросить как будет выглядеть картинка в данном случае при проверке выложенной выше? Точно так-же как если бы оно попало в область znear/zfar при указании перспективы не софтварными методами. За исключением того, что отрезало бы треугольник целиком.

Вообще все же логично. Если камера в нулях, а забор по z меньше нуля (по твоим словам), то он рисоваться не должен. Если рисуется - проблема в обрезании по znear/zfar (если это вообще используется), либо просто такой проверки нет вообще.

[Wind]

Вообщем софтварные алгоритмы отсечения плоскостями известны, но применить их не представляеться возможным, очень много геометрии, даже не представляешь насколько много, вероятено придеться что-то вроде вертексного кеша воротить, в даном конретном случае такое возможно осуществить, для того чтобы посылать только изменившиеся вертексы. На реальной системе все вертексы храняться в T&L чипе и меняються матрицы и много реже сами вертексы, но в случае эмуляции каждый кадр вся сцена пересылаеться заново, в vf4 кое-как 50 - 60 фпсок натягиваеть в мульти-трейдинге, т.е. целое ядро проца едва-едва справляеться с декодированием всей геометрии. Плюс сам програмный код игры использует много довольно тяжелых инструкций, с null рендером скорость едва 80-90 фпсок достигает.

[DreamZzz]

Да, проблема понятна. Теоретически надо каждый кадр заполнять вершинный буфер, а учитывая нагрузку цпу эмуляцией, расчетов получается много. Одно только не понятно, зачем вы столько софтварных расчетов используете, проц и так нагружен. Я так понял, z-buffer тоже не используется? Вы на софте преобразовываете 3d на плоскость, создав как бы смежный конвеер, чтобы не сильно менять остальной код эмулятора?

[Wind]

Да не, мы софтварно только матрицы и считаем (причем пробывали и на шейдерах разницы в плане скорости не было никакой) на проце считаем с надеждой на то что можно будет таки как-то отсечь уже пересчитаные координаты, при желании можно и на шейдеры вернуть, но скорость в даном случае уже 10, тут бы правильную картинку получить хотя бы по проекциям, но пока увы не выходит.
А наоми2 разрабатывался под железо наоми1 т.е. натягиваеться она легко на код эмулятора, просто несколько областей памяти новых, ну и дма новое, которое тока пока мы и раскурить смогли, оно не сложное но думаю пока мы не раскажем остальные не скоро додумаються как оно работает

[CaH4e3]

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

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

[DreamZzz]

правильную картинку получить хотя бы по проекциям

Если вам придется fov на софте курить, вы укуритесь Вам очень желательно использовать как минимум D3DXMatrixPerspectiveFov (или gluPerspective) и z-buffer. Тогда (если камера все-же в нулях, а очень похоже что так и есть) вам останется подобрать fovy и aspect, чтобы получить правильную проекцию.

это приведет к сглючиванию всего объекта

Ну да, но вы сами усложнили себе задачу, не используя аппаратную проекцию.

Только не подумайте, что я вас пытаюсь учить или что-то в это роде. У меня просто коварные планы поиграть в VF4   

[Wind]

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

[DreamZzz]

т.е. матрицы пересчитывают вертексы в оконые координаты вот и все

Ну не могут они без угла обзора пересчитыватсья, ну никак. Иначе получится то, что у вас и получилось. Курить матрицу проекции все равно надо, хоть на софте, хоть на гпу, хоть на чем.

[Wind]

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

[DreamZzz]

Ну рядом с прокционо матрицей лежат два флоат числа одно кажись 10 другое 1000

Похоже на плоскости отсечения по z. Первое znear, второе zfar.

Я это к тому что если угол есть то он должен где-то и как-то передаваться я думаю

Попробуй для начала статический, в пределах от 30 до 90 градусов. Обычно fov в играх делается константой и меняется очень редко (может меняться если используется снайперский прицел или всякие эффекты).

[Wind]

Похоже на плоскости отсечения по z. Первое znear, второе zfar.

согласен, но не уверен

Попробуй для начала статический, в пределах от 30 до 90 градусов. Обычно fov в играх делается константой и меняется очень редко (может меняться если используется снайперский прицел или всякие эффекты).

Ну мог бы попробывать если бы знал как домножить на него

[DreamZzz]

Ну мог бы попробывать если бы знал как домножить на него

Ну у тебя же есть видовая матрица (та, где позицию камеры задаешь). Тебе надо эту видовую матрицу перемножить с матрицей проекции. Матрицу проекции проще всего не вычислять самому, а получить через функции DX или GL.

В DX это делается так:
D3DXMATRIX matProj;
D3DXMatrixPerspectiveFovLH(&matProj, fovy, aspect, znear, zfar); // fovy в радианах

В GL функция Perspective не возвращает матрицу, а напрямую задает ее. В этом случае можно сначала задать ее, а потом получить с помощью GetProjectionMatrix.

[Wind]

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

[CaH4e3]

Там нет проекционной матрицы в ее полном виде, как для того же frustrum в ogl, потому что нет такого количества параметров. Ширина и высота окна в видовой плоскости берется как размер стандартного экрана всегда. Максимум, что там может передаваться - расстояние от экранной плоскости (ноль по Z) до координаты точки наблюдателя в плоскости (-расстояние по Z). Для простейшего случая камеры в координатах (0, 0, -dist) не надо матриц, надо простейшую пропорцию, собственно что сейчас и работает. И она не всегда дает положительные результаты, потому что скорее всего должен быть еще как минимум один параметр (0, yc, -dist) для вычисления проекции, про который как раз пока ничего не известно и который чутка усложнит функцию перспективного преобразования, хотя все равно матрицы тут тоже не обязательны.

[DreamZzz]

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

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

Там нет проекционной матрицы в ее полном виде

Если есть координаты в 3d, надо их как-то проецировать на 2d. Сейчас у вас идет простое параллельное проецирование, результат не радует. Значит проецирование не параллельное. Значит нужна матрица проекции.

[Wind]

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

[DreamZzz]

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

[Wind]

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

[DreamZzz]

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

gluPerspective пробовал?

[Wind]

нет, ибо это уже не гуд глу функции не гуд, они вообещем-то и не нужны не кому

[DreamZzz]

нет, ибо это уже не гуд глу функции не гуд, они вообещем-то и не нужны не кому

Я даже растерялся, что на это ответить. Либо ты сразу отмел мою версию, что дело в перспективе, либо хз. Ладно бы ты попробовал, показал результат и сказал, что так-то и так-то, дело не в перспективе, потому-то и потому-то. В OpenGL единственный аналог D3DXMatrixPerspectiveFovLH это gluPerspective. А glFrustum это тот еще анахронизм и мазохизм. Ну, дело хозяйское.

Вот тут глянь, аналог gluPerspective через glFrustum.
http://www.gamedev.net/community/forums/topic.asp?topic_id=180495

[Wind]

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

Добавлено позже:
Попробывал поиграться таки с gluPerspective, вообщем результат отрицательный, даже скриншота не вышло сделать вразумительного, увы все что можно пока сделать так это уменьшать x,y в зависимости от удалености z. Но результат так себе на оригинал не шибко похоже

[DreamZzz]

Можно как-то получить доступ к исходникам и покурить это дело? Если это дело раскуривается в плагине, достаточно исходников плагина.

[Wind]

Заходи на irc.newnet.net / #demul, обсудим

[Paragon]

А можно где взять список поддерживаемых игр наоми?

[CaH4e3]

Можно где
http://forum.emu-russia.net/viewtopic.php?p=6767#p6767

[Paragon]

Вроде тоже самое что на нуле! А эмуляция наоми 2 возможна или это шутка?