Сам ставил. Чистая лицензия, установлены только рабочие лицензионные программы. Выяснять, почему не работает - не буду.
Добавлено спустя 4 часа 56 минут 50 секунд:
aliast писал(а):
т.е. число текстур = 74, номер первой 2, число flat-поверхностей 43, первая флат-поверхность в файле с номером 76 (итого D002-D075 это текстуры, D076-D118 это флат-поверхности) дальше вроде бы ширина-высота и 00000000. А про сами текстуры я уже писал - у них нет заголовков секций PDAT, PLUT и плюс у них нет PRE0 и PRE1 по которым определяется размер, размер берётся из D001
Нашел, где ты писал про первый файл. Ну, капееец... Наворочено-то...
Написал программулину, которая бы делала первый файл в REZFILE. Шапка + блоки ширина/высота/нули текстур. Как-то с ним не совсем чисто. Сверху - оригинал из REZFILE. Снизу - мой файл. Начало файла:
Середина файла:
Конец файла:
Как видно, мой файл получается больше. Обрабатываю и текстуры и флаты. Может, нужно только текстуры? Но тогда как понимать параметр 4С в шапке? И откуда такие разночтения в середине файла? aliast, проверь, пожалуйста.
Нашел, почему не совпадают 3 байта, которые "подряд". Мой косяк, я читал из исходного файла текстуры по 1 байту на ширину/высоту, а нужно читать 2 байта. 3 текстуры (небо) имеют размер в ширину 256 (0x100) и в один байт этот параметр не помещается. Это нужно фиксить. В шапке номер, с которого начинаются flats, тоже поправлю. Остается неизвестным 1 отличающийся байт. Это параметр 10-ой по счету текстуры, т.е. rCRATINY. Ее размеры - 128х64. Таким образом запись должна быть
Добавлено спустя 1 час 19 минут 4 секунды: Все правильно. В исходниках текстур - это большая текстура 128х64, а в файле doom.wad - маленькая 16х64. Уф... Примем тот факт, что в первый файл включать flats не нужно. Итак, осталась механика и прога будет готова. Мы стали еще на шаг ближе к добавлению своих текстур. Чтобы полностью закрыть этот вопрос, нужна прога, которая режет и PRE0, PRE1 у текстур. aliast, поможешь?
Добавлено спустя 40 минут 26 секунд: aliast, можешь выложить исходники своей проги конвертера WAD? Нашел только твою прогу с 3-мя лумпами. Не хочется наступать на те же грабли, попытаюсь допилить последний лумп на основе твоей проги.
На счёт флага rezfixed: он стоит на файлах: первый файл в резе, файл цифр, последние 3 лумпа каждого уровня. Первый файл содержит размеры всех текстур стен загруженного уровня. Пол/потолок не участвует, потому что размер всех текстур 64х64. Он нужен всегда при загруженной игре, потому что неизвестно, какая текстура за поворотом и нужно быстро определить её размер. На файл с цифрами в коде даже стоит комментарий: needed always. Он как загружается в память, так там и остаётся. Вот уже видим схожие детали. Могу предположить, что для трёх лумпов тоже нужен особый приоритет.
У каждого спрайта в D0396-D408 есть несколько состояний (враг бежит, стоит, атакует). Все они описаны в файле Info.c {Spr(rSPR_IMP,20),-1,0,0}, // S_TROO_XDIE8 где 20 - номер спрайта. Максимальный номер для импа (D0396) = 25 что соответствует 26 спрайтам. Открываем D0396 и видим в начале 8 смещений с префиксом 40 00, 18 смещений без префикса (ведущие напрямую к 18 ПОСЛЕДНИМ картинкам). Итого 8+18 = 26. Совпадает? Да только дальше в файле идут 5 добавочных смещений, которые нужно добавлять к первым 8 смещениям с префиксом 40 00, потом идут ещё несколько чередующихся смещений с префикcом 80 и без префикса, итого 58 картинок :( Тут надо распаковать один файл и глянуть что там за 32 "лишних" спрайта. Скорее всего это спрайты с разных ракурсов для вращения. Префикс 40 00 насколько я вкурил показывает что спрайт может вращаться, а 80 00 что спрайт может быть flip (?) т.е. /* Reverse horizontal */ Я не понял что это значит. If your character needs to walk on the ceiling, let's use the FLIP command for that Нужно распаковать один и думать дальше.
Если префикс 80 00 действительно показывает, что спрайт может быть отображен по горизонтали, то с этим как раз понятно. Например, когда враг идет на игрока, то он может смотреть "чуть влево" и "чуть вправо". При этом, как я понимаю, кадр спрайта используется один, только он зеркалится.
Добавлено спустя 10 часов 37 минут 3 секунды: Я вот тут подумал: а что если в 10 лумпе не делать одинаковое смещение на строку 0х0000 0хFFFF, а так их и распердолить по всему файлу. Пускай и будут одинаковые строки также, как и в PC версии. То есть, мы просто делаем из 2-х байт 4, делаем им своп и все. Движок должен читать это корректно. Другой вопрос, что (возможно) памяти израсходуется чуть больше, но это уже другая история. Все-таки, мне кажется, что в памяти все равно будет храниться длинная портянка. Когда грузится лумп BLOCKMAP, мы ходим по оффсетам и читаем строки, на которые они указывают. Все равно наша одинаковая строка будет находиться в памяти по разным смещениям. Это только в файле она находится в одном месте, а в памяти, все равно, будет размножена. Думаю, что допилить этот конвертер можно будет потом. Пока попытаюсь сделать, как сейчас написал. Может, и выйдет чего.
Добавлено спустя 10 минут 44 секунды: PS. Прога для первого файла в REZFILE (rTEXTURE1) закончена.
Versus, скинул ссылку: https://yadi.sk/d/iItcCn94nWxSi на треки Doom Playstation: Official Soundtrack - 20th Anniversary Extended Edition, там 1 из треков может идеально подойти к заставке 3DO версии, в принципе треки те-же что и в PS1 версии, но с более богатым звучанием и стерео эффектом, это оф. издание
, обязательно будет в начале списка blocklists или может встретиться позже?
Так она же даже на первой карте встречается и в начале и позже... а может ли быть такое, что в начале её не будет, а потом появится? - понятия не имею.
aliast Слушай, а может так получиться, что в PC-шном лумпе будет дополнительная blocklist? Я это обнаружил, когда сгененировал файл без одинаковых строк 00 00 00 00 FF FF FF FF. По ссылке архив с двумя файлами: PC 10 лумп и 3DO 10 лумп (из REZFILE). В PC файле по смещению 0x9B00 есть строка 00 00 19 01 FF FF, которой по смещению 0xE900 в 3DO-шном файле нет. И далее тоже есть разночтения, пока не проверял все. https://yadi.sk/d/pDUBuRYfnekgv
Добавлено спустя 2 часа 15 минут 45 секунд: Или мы должны рассматривать дубликаты ВСЕХ строк, а не только 00 00 00 00 FF FF FF FF?
aliast Пока копался в коде, нашел у тебя пару незначительных косяков. В лумпе 2 и 8(7?) вместо нулей пишется СС. Поменял тип buf1 с char на int и все прошло. Кстати, а ты не перепутал случайно местами лумпы 7 и 8? Просто у тебя создаваемый файл lump8 соответствует лумпу 7 из REZFILE и наоборот. Мой лумп blockmap с убранными дубликатами пока только одной строки 00 00 00 00 FF FF FF FF работает, с косяками. Какие-то стены проходные насквозь, какие-то работают корректно. Блин, придется все-таки убирать все дубликаты. Ну, уже круто, уровень запускается. А с перепутанными лумпами и/или теми небольшими ошибками вешал игру.
Добавлено спустя 5 минут 59 секунд: А, и еще увеличил
char linecounts[10000]; short linedef[10000]; short linelength[10000]; int offsets[10000];
в CreateBlockmapLump. Без этого последние 2 лумпа не создавались (пытался сконвертировать недавнюю Ромеровскую карту). PS. CreateBlockmapLump у меня свой, поэтому тут правил только для того, чтобы прога не вешалась.
Добавлено спустя 11 часов 48 минут 30 секунд: Вот первый опыт запуска новой карты на 3DO.
Кстати говоря то что мы делаем очень похоже на алгоритм работы архиватора. Они тоже ищут одинаковые цепочки и заменяют их некой ссылкой. Осталось только найти исходники какого-либо архиватора и выдрать этот кусок кода. Проблема в том, что современные архиваторы вряд ли работают так просто :(
aliast Вроде, у меня получается что-то внятное. Долго вылавливал свой косяк, по которому не учитывались нулевые значения в теле строки. То есть, в PC есть одна цепочка: 00 00 00 00 01 00 02 00 03 00 04 00 30 00 FF FF В ней после начала 00 00 есть еще нулевое значение 00 00. Выловил, наполовину сделал общий алгоритм.
Хмм... Странно, а в 3DO-шном лумпе это нулевое значение как раз-таки транклюкировано. И еще есть пара отличий. Радует лишь то, что на текущий момент сделал определение оригиналов и дублей строк. Теперь нужно выборочно писать в выходной файл оригиналы, по пути меняя смещения. Та еще задачка...
Передвигаюсь черепашьим темпом. Записал оригиналы смещений на свои места. А вот с одинаковыми смещениями пока затык. Отработка первых дубликатов работает корректно до строки 172. Эта строка является первым повторением другой строки-дубля. И в этом месте смещения считаются неправильно. Ошибка на подобных смещениях набегает к концу файла. Итого, пока имеем 46 разночтений (по первой тестовой карте).
Бляяяяяяя! Я его победил! Ну и задачка была... В коде хаос и бардак, но по-другому быть не может. Это моя первая с нуля написанная прога на С. Кому интересно, могу выложить этот ужасный код. Делал как отдельную прогу. Сейчас попытаюсь прогу aliast-а и свою соединить и причесать немного код. Нужно удалить временные файлы после работы, сделать запрос имени файла для удобства и сделать прочие мелочи. Но главное сделано! Налить всем по чарке!
