Правила, действующие в этом форуме и всех его подфорумах:
1) Запрещена реклама в любых её проявлениях (сразу бан без предупреждения)! 2) Мат тоже не приветствуется на форуме, но иногда можно выразить свои чувства ( лучше заменяйте матные слова точками, пробелами, другими буквами)! 3) Категорически запрещается унижать, посылать, издеваться над участниками форума! Мы здесь все - одна большая и дружная семья! Поэтому за нарушение этого правила автоматически будем банить! 4) Разрешены ссылки на информацию, которые относятся к тому или иному разделу форума! 5) Ссылки не в тему будут удаляться и пользователь получит предупреждение или будет забанен! 6) Пользователям разрешено задавать любые вопросы относящиеся к теме, а мы все дружно ответим на эти вопросы. А также отвечать на вопросы и высказывать своё мнение. 7) Повторные темы, которые будут создаваться, будут удалены! Создавайте темы, удостоверившись, что такой темы нет на форуме! 8) Запрещён флуд во всех его проявлениях, сообщения не по теме, сообщения состоящие из одного или нескольких смайликов без текста, сообщения типа - Вах!, Рулез!, Круто! и т.п. Пользуйтесь пожалуйста кнопкой [EDIT], не плодите бессодержательные сообщения. 9) Использование смайликов разрешается не более 3-х подряд!
Всё, текстуры походу найдены! Предварительная инфа: представляют собой набор cel-картинок размером 32х32, запихнутых в контейнер CARY. В настоящий момент нет просмотрщика\конвертера из CARY в CEL, но сам формат на первый взгляд несложен. Вот одна из картинок, распакованных руками в HEX-редакторе.
Выше полностью распакованный один из файлов ARY, содержащий эти три картинки. Угадайте что это и откуда? Я сам не понимаю)) Также любопытно почему эти три кадра упакованы в один файл CARY, что это значит?..
Последний раз редактировалось aliast 02 июн 2013, 12:35, всего редактировалось 2 раз(а).
1) В некоторых CARY-файлах имелась секция PDAT, но почему-то не во всех... сначала было подумал что там может быть что угодно, не только картинки, но видимо это не так 2) Поиск строк внутри KTшного launchMe, там я нашёл строку ошибки, мол, файл не имеет заголовка "CARY (CelArray)". CelArray! Изучил функцию, в которой встречается эта ошибка. Там просто смещения считывались всякие. Дальше начал смотреть на имеющиеся cel-картинки, почитал в 3DO SDK про флаги, флаги устанавливали, в частности, для каждого файла наличие секции PLUT. Она обычно имеет размер 4Ch (считая заголовок), а одно из смещений в CARY (то что это смещение я уже понял, но не мог понять на что оно указывает) как раз и имело размер 40h (+ 4 байта заголовок, +4 байта размер заголовка, итого 48h, не хватиало ещё 4 байт). Сделал догадку что первое смещение указывает на секцию PDAT. Открыл HEX-редактор, создал заголовки CCB, PDAT, PLUT, оформил всё как положено, открыл в 3doresexplorer.. сначала был набор точек. Это потому что я PLUT не сразу правильно нашёл. Потом вдруг всё получилось)) Распаковал руками пару файлов, и вот уже нашлись розовые стены из лабиринта! А те текстуры выше хрен поймешь откуда(( 3) Ну и помимо всего прочего на том новом сайте 3до юкоз тоже высказали догадку про графический формат файла.
Благодарю за развернутый ответ! А по какому принципу делать заголовки CCB, PDAT, PLUT и где? Неплохо было бы, если бы ты оформил это дело как пошаговый мануал. Думаю, тут найдется народ, который хочет пощупать это руками.
_______________________________________ There are 10 types of people in the world: those who understand binary, and those who don't.
А по какому принципу делать заголовки CCB, PDAT, PLUT и где? Неплохо было бы, если бы ты оформил это дело как пошаговый мануал.
Немного путано получилось, может ещё одно видео снять?
Файлы ARY
Массив из нескольких CEL-картинок с текстурами с порезанными заголовками CCB, PDAT, PLUT. Этот формат скорее всего изучен полностью. typedef struct ARY { string CARY; //сигнатура файла CelARraY int32 start_offset; //смещение к началу первой секции CCB int32 file_size; //размер файла ARY минус 4 байта int32 zero1; //нули int32 offset1; //смещение к началу первой секции CCB int32 offset2 //смещение к началу второй секции CCB ... int32 zero2; //нули - обозначают конец таблицы оффсетов };
Далее идёт секция CCB первой картинки, но заголовок CCB обрезан, нужно восстановить его самим написав вначале: 43 43 42 20 00 00 00 50 00 00 00 00 Здесь 43 43 42 20 = "CCB " 00 00 00 50 = неизменный размер секции в 80 байт (0x50) 00 00 00 00 = нули Далее идут 68 байт (0x44) из файла ARY, начиная со смещения offset1 до offset2 (должно быть offset2 - offset1 = 0x44) Секция CCB имеет следующий вид (для дальнейшей распаковки нам понадобятся offset_PDAT и offset_PLUT): typedef struct CCB { string CCB ; //сигнатура секции "CCB " (с пробелом в конце) int32 CCB_size; //размер секции, всегда равен 0x50 int32 zero1; //нули int32 flags; //спец. флаги (за подробностями читаем 3DO SDK, а пока просто копируем данные из ARY) int32 zero2; //нули int32 offset_PDAT //смещение к секции PDAT применительно к файлу ARY int32 offset_PLUT //смещение к секции PLUT применительно к файлу ARY ... //дальше лень расписывать, просто копируем данные }; Сразу после секции CCB идёт секция PDAT, заголовок тоже обычно обрезан. Восстанавливается дописыванием байт: 50 44 41 54 размер_секции_PDAT Здесь 50 44 41 54 = "PDAT" размер_секции_PDAT = размер секции PDAT = смещение_к_следующей_секции_PDAT - смещение_к_предыдущей_секции_PDAT Далее копируем данные из ARY, начиная со смещения offset_PDAT и до смещения offset_PDAT из заголовка CCB следующего файла. Ну и по аналогии восстанавливаем секцию PLUT, дописав вначале секции: 50 4C 55 54 00 00 00 4C 00 00 00 20 Здесь 50 4C 55 54 = "PLUT" 00 00 00 4C = размер секции PLUT, всегда 0x4C 00 00 00 20 = неизвестный байт 0x20. Скорее всего он всегда равен 0x20 во всех картинках Копируем данные из ARY, начиная со смещения offset_PLUT и до смещения offset_PLUT из заголовка CCB следующего файла. Всё - первая картинка распакована. Переходим ко второй.
Тестовая версия распаковщика ARY в CEL. Некоторые файлы выходят битые, это потому что у них размер нестандартный - разбираюсь как с ними быть. http://rusfolder.com/40331224 Тестировал на 58.ary - берёзки из стартовой зоны распаковались на ура :) PS: нежданчик! Из файла 64.ary достались те же самые текустурки что и в 58.ary, но с разрешением 128х128 против
13chuck13 писал(а):
Это блошиный цирк с ярмарки!
32х32 Вот вам для сравнения: и 32x32 128x128 Интересно, нафига нужные мелкашки?! Видимо превьюшки, но для чего?
Нашёл в Artmoney MaxYLook и MinYLook - ограничители угла просмотра: вниз 150, вверх 6. Вроде бы значения 200 и 1 должны помочь, или ещё поэкспериментируй как лучше. http://yadi.sk/d/NawV6LgP5Nz1L
Ура вид стал опускаться полностью в низ а значит остается принскринить куски и тупо объединять их ,спасибо. Теперь работы будет гораздо меньше. Один вопрос DEADMAN517 ты еще работаешь над портом или как?
_______________________________________ Знание – главный инструмент управления. (Билл Гейтс)
По поводу распаковки текстур эта тема подходит лучше, чем тема про выбор движка для портирования :) В общем, похоже я был прав. В игре очень много похожих друг на друга текстур, отличающихся либо по цвету, либо дополнительными трещинами, лианами, орнаментом - текстура стены та же, но добавили лианы. В ARY-файлах текстуры стены хранятся отдельно от накладываемых элементов (трещины, лианы). А вот должны они распаковываться отдельно или с наложением непонятно. Возможно наложением занимается сам движок игры? Я не могу сообразить как их при распаковке надожить :( Пробовал пихать их в один заголовок PDAT, на выходе голая стена без наложения. Пробовал удалять байты 00BF - картинка вообще портится, т.е. не надо удалять. Создавал несколько секций PDAT в одном файле, опять не то... Но то что байты 00BF отделяют основную текстуру от дополнительной это факт!
Получается вручную. А автоматизировать хз как. Кроме того недавно понял что 00BF это вовсе не байты разделения текстур, а скорее что-то вроде чёрного фона. Так что не вариант по ним файлы делить. Нужно по другому... составить список всех смещений к секциям PDAT, сортировать их по увеличению и уже по ним определять где кончается одна текстура и начинается другая. Эти смещения в файле идут вразброс, скорее всего согласно схеме наложения. Часто повторяются (видимо когда одна текстура разных оттенков). В общем, каша полная. Вручную распаковать проще, но задолбаешься. Автоматизировать не получится пока досконально не разберешься.
Тестовая версия распаковщика ARY в CEL. Некоторые файлы выходят битые, это потому что у них размер нестандартный - разбираюсь как с ними быть. http://rusfolder.com/40331224 Тестировал на 58.ary - берёзки из стартовой зоны распаковались на ура :) PS: нежданчик! Из файла 64.ary достались те же самые текустурки что и в 58.ary, но с разрешением 128х128 против
13chuck13 писал(а):
Это блошиный цирк с ярмарки!
32х32 Вот вам для сравнения: и 32x32 128x128 Интересно, нафига нужные мелкашки?! Видимо превьюшки, но для чего?
Приветствую! Ссылка уже битая. По алгоритму выше написал программулину, которая выдергивает CEL'ы из ARY. Сравниваю структуру получившегося CEL'а с эталонным вариантом, который был выдернут с ZStream и успешно конвертируется в BMP - все четко на первый взгляд. Однако при конвертации моего CEL'а в BMP получается мишура. При этом всем по рандомным картинкам даже что-то более-менее осязаемое виднеется, но все равно не то - искажены цвета и отсутствуют рандомные области. Буду признателен, если подскажешь, как с тобой связаться можно (WhatsApp, Telegram, E-mail - без разницы). Хотелось бы данную тему обсудить. Заранее премного благодарю.
PS: Кстати в своем варианте я все-таки собираю массив структур со смещениями CCB, PDAT, PLUT и сортирую их по возрастанию смещения PDAT, и далее распаковываю. Даже размен последней PDAT секции удалось вычислить, полностью разобрав размеры остальных элементов внутри ARY и вычитая их из общего размера ARY с ARY заголовка.
Распарсил весь ZStream, получилось 3183 CEL'а. Просмотрел каждый. 50% маленьких картинок (от 10х6 до 32х32) - корректно отображаются в 3DOResExplorer 0.0.8. Что касается картинок размером более указанных ранее - ни одной целой, все битые, но в некоторых видны частично осмысленные очертания стен и дверей с искаженной цветовой палитрой. Ощущение, будто они пожаты... Несколькими постами выше aliast писал, что удалось руками распаковать текстуру розовых стен начального лабиринта. На примере этой текстуры хотелось бы например на видео увидеть, как это делается руками и каким ПО конвертится получившийся CEL.
Вот мой распаковщик: https://drive.google.com/file/d/0B0oL7g ... -TjQvTCpjg Я его писал в апреле 2014 года, так что разумеется мало что помню. Попробовал навскидку распаковать парочку ARY-файло. Вроде бы распаковывается, потом 3DOResExplorer v. 0.0.7 преобразую их в BMP. Будет ли это работать для всех ARY файлов смотреть надо. А можно пример битых текстур? Берёзы 128x256 тоже нормально преобразовались в BMP.
Вот мой распаковщик: https://drive.google.com/file/d/0B0oL7g ... -TjQvTCpjg Я его писал в апреле 2014 года, так что разумеется мало что помню. Попробовал навскидку распаковать парочку ARY-файло. Вроде бы распаковывается, потом 3DOResExplorer v. 0.0.7 преобразую их в BMP. Будет ли это работать для всех ARY файлов смотреть надо. А можно пример битых текстур? Берёзы 128x256 тоже нормально преобразовались в BMP.
UPD: HEX редактором открыл ZStream, взял первый попавшийся CARY, убрал его в отдельный файл, скормил твоей програмке, получил горсть битых CEL'ов. Есть возможность скинуть успешный вариант распаковки CEL'а? Если при этом укажешь смещение или порядковый номер CARY + смещение или порядковый номер CEL'а - ваще будет замечательно. Хочу твой успешный результат сравнить со своим неуспешным и понять, что у меня все-таки не так в алгоритме или банально в данных.
И еще странный вопрос: вот тот CEL, который я распаковал твоей программой, нормально у тебя в ResExplorer'е отображается, или тоже мусор? Спрашиваю, потому что с армового мака сижу и предполагаю, что ResExplorer может подглючивать при трансляции Win11 ARM -> x86 (неочень логичная теория, конечно, потому что скорее всего тогда все картинки не показывались бы поголовно, а не частично, но хотелось бы такую вероятность тоже отмести).
UPD: Сравнил "Первый CEL, который получился с помощью твоей програмки" с первым CEL'ом, который родила моя програмка сишная. Результат - CEL'ы одинаковые! За исключением PDAT и PLUT оффсетов конечно. Я после того, как увидел, что картинка получается битая, сделал принудительное зануление PDAT и PLUT смещений в CCB заголовке, поскольку ранее они указывали на размещение относительно ARY, а теперь, по логике, когда CEL одиночный, эти оффсеты в теории не нужны. Но это никак не помогло. Текущий итог: первый CEL из первого ARY у нас с тобой выходит идентичным по сути. Может у меня кривой образ 3DO KT...вариант с кривой адресацией на винде отметаю, т.к. на виртуалке с MacOS 9 и плагином CEL'ьным к Photoshop 4, CEL получившийся также выглядит кривым.
UPD: На виртуальной машине c Windows 7 Pro x86 (qemu-system-x86_64) симптомы те же, так что дело не в архитектуре машины и не в ПО. SHA1 контрольная сумма имеющегося у меня ZStream файла - 7b344debde0794228037a327a6b345f1d5cb5f03.
У меня тоже картинка битая. А откуда взялся этот test.ary? Он похоже сам по себе содержит битые данные.. Эти хидеры JOIN, JVRT тут явно лишние. По смещению 0x1F90 Стоп! Нельзя же просто взять кусок данных из Stream-файла и распаковать его вручную! Там какой-то хитрый алгоритм распаковки. А так конечно файл битый выходит. Вот эта прога должны стрим распаковывать: http://3do.ucoz.ru/load/prilozhenija/so ... /11-1-0-49
У меня тоже картинка битая. А откуда взялся этот test.ary? Он похоже сам по себе содержит битые данные.. Эти хидеры JOIN, JVRT тут явно лишние. По смещению 0x1F90 Стоп! Нельзя же просто взять кусок данных из Stream-файла и распаковать его вручную! Там какой-то хитрый алгоритм распаковки. А так конечно файл битый выходит. Вот эта прога должны стрим распаковывать: http://3do.ucoz.ru/load/prilozhenija/so ... /11-1-0-49
Я так и знал, что упускаю что-то очень важное. И ведь неспроста ZStream оно зовется, а не Stream, где Z как бы намекает на Zip или какое-то другое сжатие. Сейчас буду пробовать.
UPD: Получилось распаковать один ARY моей утилитой. Магия, не иначе, все картинки корректные. Значит все-таки дело было в сжатии самого ZStream! Попробую все распаковать и выяснить процент битых картинок.
Добавлено спустя 1 час 44 минуты 38 секунд: Все получилось! aliast еще раз спасибо! В качестве благодарности и вклада в форум, выкладываю исходники своего поделия. Мое поделие написано на Си и использует маппинг файлов в память в качестве основного способа чтения и записи данных. Написано под стандарт c89, это значит, что оно скомпилится любым, даже самым старым и паршивым Сишным компилятором под Linux, Windows (MinGW например), macOS, FreeBSD и пр.. Оно не умеет выдергивать CEL'ы из нескольких переданных ARY, но умеет дергать CEL'ы из всех ARY, которые соединены в один файл. Исходя из всего вышеописанного прилагаю свою инструкцию для чайников и инструменты:
2.2) Запускаем OperaFSReader, выбираем образ из п1 (Disc Image, кнопка "...") 2.3) Заходим в директорию Stream 2.4) Нажимаем кнопку "extract all files from current directory" 2.5) В появившемся окне выбираем путь, куда хотим сохранить файл ZStream размером 644 Мб, жмем "Сохранить" (Save) и ждем окончания распаковки
3.2) Запускаем 3DO Res Unpacker, жмем кнопку "Открыть" (Open) 3.3) В появившемся окне выбираем распакованный в п2 файл ZStream, жмем "Open" (Открыть), далее жмем "ОК", если появилось предупреждение. Дожидаемся окончания анализа, жмем "ОК" в появившемся окошке итогов 3.4) Жмем "Извлечь всё" (Extract all), выбираем директорию, в которую хотим сохранить ресурсы игры, жмем "ОК". Дожидаемся окончания извлечения. В конце возможно будут выскакивать предупреждения, на все жмем "ОК", их порядка 20-ти
4) В терминале MinGW/Линуксовом терминале/Маковском терминале, соединяем все ARY файлы в один:
В результате должно получиться порядка 3590 CEL файлов 5.4) Опционально: среди распакованных картинок, есть очень много дубляжей. Их можно вычистить скриптом cleanup, который находится в архиве с исходником main.c
6.2) Запускаем 3DOResExplorer, справа-сверху в открывшемся окошке переходим в директорию, в которой располагаются CEL файлы, полученные в п5 6.3) В верхнем меню приложения выбираем Command -> Convert Current Dir. Дожидаемся окончания конвертации 6.4) Видим примерно 1284 картинки формата BMP. Далее вам остается лишь придумать, для чего их использовать :)
Заранее извиняюсь, если далее озвученная тема уже была на данном форуме. Вопрос касается видео призраков. Есть какой-то способ их раскодировать? Полностью лабиринты уже построил в GZDoom и осталось лишь эти видео влепить.
Сейчас этот форум просматривают: Yandex [Bot] и гости: 5
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вот вам для сравнения:
