Софтверный 2.5D движок для PSP
|
Какие люди!:shok::drinks::good:
|
:) Да вот, вспомнил про PSP и перенёс движок. А то он у меня и для Windows и для QNX, и для MS-DOS есть, а для PSP-нет. :) Придумать бы, как его ускорить - впрочем, можно разрядность цвета понизить. И ещё при перемещениях очень хорошо видны смазывания цветов. Интересно, неужели экран такой инерционный? Вроде бы в играх я такого не замечал (хотя в DOOM вроде бы я такое уже видел).
|
Ilsor,
многие тяжёлые игры работают в 16 битах (мало VRAM). Что меня очень печалит, когда я смотрю на чёрный цвет. И экран действительно достаточно инерционный (Pong). |
Это забавно, но я сегодня был на Юноне (это в СПб). Много лет я там бывал, но вот именно сегодня попались и Спектрум в красивом оформлении за 1500 и PSP Street.за 1000. А первой я увидел PSP и её и купил из интереса. Будет у меня две PSP. :) А спектрум уже не купил - мне на вокзал нужно было встречать и лишний груз ни к чему. А жаль. Вот такой облом. :) А раньше ничего такого не попадалось много лет. :) Ну, кроме МК-85. :)
Жаль, прошивка только виртуальная бывает к ней... :( И экран ооооочень инерционный. :( Но работает. Будет запасной. А вот в официальных играх шлейфов-то почти и нет. Надо подумать, откуда они берутся при прямой отрисовке без ускорителя. |
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
|
|
ErikPshat,
у меня в архивах тоже всё есть. Нужно только тему поправить. |
Цитата:
|
Цитата:
Правда, я не уверен, что в PSP ещё хоть кто-то играет. :) |
Цитата:
|
А, точно. Не заметил. :)
Понял, откуда шлейф. Вот из-за этой функции: sceDisplaySetFrameBuf((void*)VideoBuffer,512,PSP_DISPLAY_PIXEL_FORMAT_8888,0); Последний параметр у меня 1 был - синхронизация: PSP_DISPLAY_SETBUF_IMMEDIATE Buffer change effective immediately. - это 0 PSP_DISPLAY_SETBUF_NEXTFRAME Buffer change effective next frame. - это 1 Честно говоря, я не заметил, что там такие значения и заданы через enum. Подумал, что либо есть, либо нет синхронизации. Вот как полезно бывает читать документацию. :) Но в архиве я не заменил на PSP_DISPLAY_SETBUF_IMMEDIATE - там остался 0. У себя-то я уже исправил на PSP_DISPLAY_SETBUF_IMMEDIATE вместо нуля, но не перезалил. :) Он и синхронизирует. :) Я ещё кое-что изменил в движке - в физической части. Сейчас FPS стабильный при движении. Но, правда, только 20-30 FPS выдаёт в полноэкранном режиме 480x272. Но на 320x240 около 30-40. Архив в первом сообщении перезалит. :) |
Попытался задействовать графический ускоритель PSP для вывода картинки движка. Занятно. Едва координаты точки треугольника оказываются за спиной (координата Z больше либо равна нулю), как ускоритель просто выбрасывает весь выводимый треугольник! Это что ещё за шутки такие? Никогда тот же OpenGL так не делал - это задача ускорителя перенести точки на переднюю плоскость отсечения. И он это делает даже на PSP когда координата Z отрицательна! Открыл исходники Quake 1 для PSP. Вижу там целый модуль clipping.h - не знаю, из оригинального он Quake или нет, но похоже он как раз и занимается отрезанием частей полигонов, находящихся за спиной. Я правильно понимаю, что GU не умеет работать с положительными Z координатами точек?
И ещё я нифига не понял, что это такое: sceGumUpdateMatrix(); - я наивно полагал, что матрица задействуется сразу же после её задания. И оно так и было, пока я не начал менять матрицы каждый кадр в цикле (менял плоскость отсечения). Что за бред? С текстурами такая же фигня - без sceKernelDcacheWritebackAll(); на текстурах артефакты - полоски и точки. Что за странный GU у PSP? Ему постоянно нужно сбрасывать кэш при смене текстур и просить пересчитать матрицы? Зачем же всё это нужно? |
Сделал отсечение по Z. А вот и не помогло. У GU проблема вовсе не в Z. У него какая-то проблема с проецированием - если точки куда-то попадают про проецировании, то они выбрасываются вместе с выводимым полигоном. Но вот какое это условие - я не знаю. Можно, правда, из матрицы проецирования найти все ограничивающие вид плоскости и отсечь по ним. Тогда, наверное, заработает.
|
Вложений: 1
Всё, заработало. Разобрался с тем, что делают в Quake-1. Фишка вот какая - GU нужно чтобы вершины после проекции попадали в видимое окно. Иными словами, нужно отсечь вершины полигонов по плоскостям, ограничивающим вид игрока слева, справа, снизу и сверху. А передняя плоскость отсечётся автоматом. :)
Как это сделать? Считать три матрицы - GU_PROJECTION, GU_MODEL, GU_VIEW. Перемножить их и получить итоговую матрицу преобразования координат. Из этой матрицы можно вытащить все нужные ограничивающие вид плоскости (4 компоненты полученного вектора задают плоскость с уравнением ax+by+cz+w=0). (a,b,c) - вектор нормали, а w=a*x0+b*y0+c*z0 - характеризует некую точку (x0,y0,z0) плоскости. Сами координаты точки нам не нужны - достаточно знать w. Вычисляется это всё так: Функции для перевода вектора в нормализованное представление (x,y,z,w) и умножения матрицы на матрицу: Код:
//---------------------------------------------------------------------------------------------------- Код:
//получаем матрицу проецирования А дальше надо просто найти пересечения сторон полигона с плоскостями и посчитать новые точки, а старые (которые вне плоскостей) выкинуть. Это делается так: Код:
//---------------------------------------------------------------------------------------------------- Код:
//#pragma pack(1) Код:
//задаём геометрию Код:
//выполняем отсечение Движок под GU тоже заработал. Только нифига ускорения не вышло - тормоза одни. Причём, при отключённом текстурировании скорость резко возрастает. Может, нужно как-то текстуру в видеопамять перебросить. Вот сама демонстрационная программа (не забудьте скопировать текстуру в каталог с eboot.pbp): |
Кстати, если текстуры поместить в видеопамяти (которая получается по sceGeEdramGetAddr()), то скорость текстурирования резко возрастает. Вот только на все текстуры памяти не хватает. :) Придётся в видеопамяти кэшировать только те текстуры, которые в данный момент используются при выводе графики.
|
Вот ссылка на движок под GU с форматом цвета 565 - 16 бит. Этому движку нужны файлы из движка выше - текстуры и карта. Кстати, в той карте есть ошибочно нарисованный сегмент (он наложился поверх другого) в месте, где водопады. Из-за этого там будут глюки с текстурой - будет видно наложение.
|
Текущее время: 02:05. Часовой пояс GMT +3. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc. Перевод: zCarot
PSPx Forum - Сообщество фанатов игровых консолей.