заикается из редко еле заметно, ещё раз посмотрю, попробую более детально описать

GEN13
Глянь еще на счет читаемости/четкости текста, плиз.

К идее ролика (арт, звук) претензий нет, всё классно.
Технически - заикается звук и видео (периодически, редко, но есть); ползущий текст очень сильно размазан. Некрасиво. Читабелен, но некрасиво.

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

Добавлено спустя 2 минуты 48 секунд:
Вот этот же ролик, но не конвертированный для 3DO.
https://yadi.sk/i/um4bsB95eE2Jf

да, заикается когда начинает подыматься текст предысории, и также местами заикается пока идёт вся предыстория, на счёт текста подтверждаю смазан не чёткий, сказывается сильное жатие ролика

Не знаю, я не умею работать с видео.

Да не! Работать не надо. Может, сюжет какой подскажешь.

Можешь пример исправленного файла выложить для сравнения?

Да, было бы неплохо, я поковырял и ни фига не получилось.

Выделил на картинке что изменилось. Размер картинки в чёрной рамочке подбирал наугад. Всё остальное вычисляется.
https://yadi.sk/d/rHyJAVGreGgHp

aliast
Спасибо!

Добавлено спустя 2 часа 27 минут 24 секунды:
Обнаружил функции GetShapeWidth и GetShapeHeight в файлах библиотеки burger. Видимо, поэтому в Rezfile нет габаритов текстур. Они просто вычисляются библиотекой.

Ну кстати да, я эти функции видел, но не разобрался как они работают. Сейчас проверил на D0133 - всё прекрасно совпадает.
Если посмотреть на скриншот выше, то перед черной рамочкой с шириной и высотой идут два числа: PRE0 = 40 00 05 C3 и PRE1 = 05 00 10 37
GetShapeWidth() возвращает нам (PRE1 AND 0x7FF) + 1 = (0x05001037 AND 0x7FF) + 1 = 0x38
GetShapeHeight() возвращает нам (((PRE0 >> 6) AND 0x3FF) + 1) = (((0x400005C3 >> 6) AND 0x3FF) + 1) = (((0x1000017 AND 0x3FF) + 1) = 0x18
Имеем то что в чёрной рамочке: 00000038 00000018.
На других картинках пока не проверял.

aliast, большое тебе спасибо за объяснения!

P.s. до сих пор не понимаю мотивов разработчика так извращаться ради пары байт данных, когда свободного места на компакт-диске осталось 70%. Старой закалки что-ли, когда всё оптимизировать пытались на компах ради 640 кб дурацкой верхней памяти, которой вечно не хватало и 640 даже не было ни разу, ну 600 это предел мечтаний, если выпилить всё, даже нужное.

aliast
А как ты понял, что PRE0 и PRE1 это именно числа перед рамкой? И почему именно такой длины?

Versus, длина параметров в заголовке CCB везде 4 байта.

см. описание струтктуры typedef struct MyCCB в threedo.c. В наших файлах-огрызках именно такой формат.
uint32 ccb_PRE0;
uint32 ccb_PRE1;
uint32 и есть 4 байта.
А в полноценном CEL-файле формат описан в SDK в файле form3do.h в структуре typedef struct CCC

Насколько я понимаю приставке плевать на все эти заголовки. Заголовки описаны в SDK, а приставка читает только эти данные, что мы имеем в думе. Может быть это оптимизация, может быть у программистов (Ребекки) не было sdk под рукой, может какие другие причины были... а с учётом всех этих нестыковок с одинаковыми функциями в burger и SDK и матами Ребекки в адрес работы sdk со строками скорее второе - sdk у неё был, но она его сильно перелопатила и выдала Burger.

Проверил на полноэкранной картинке D0130 - тоже получается 320*200 (000000С8 000000140). Там pre0 = 40 00 31 C4, pre1 = 3A 00 11 3F

Действительно, извращение. Вводить 2 переменные, из которых потом будут вычисляться размеры текстуры. Объем памяти такой же, если не бОльший (учитывая дополнительные функции GetShapeWidth и GetShapeHeight).

Добавлено спустя 9 минут 9 секунд:
Еще вопрос созрел. Если все текстуры (думаю, и спрайты) находятся в REZFILE в таком "обрезанном" виде, то как они туда попали такими обрезанными? Их нужно редактировать перед запихиванием туда или это "обрезание" делает утилита makerez?

Попробовал накидать прогу для автоматизации процесса восстановления CEL. Получилось фигово, всего 3 файла правильно обрабатываются 132 (131 по StreamReader'у), 133, 135. Надо что-то поправить, не знаю найду ли время.
Кидаю с исходниками на Delphi CodeGear 2007.

p.s. файлы можно пачкой заправлять в прогу, выделяем список и погнали.

Author
Спасибо!!!

Первая ошибка что сразу бросилась в глаза - размер заголовка CCB прыгает и, кажется, приравнивается к смещению к секции PDAT. Это неправильно, размер CCB ВСЕГДА 0x50. Я Delphi плохо знаю, но попробую исправить, поискать другие ошибки.
Вроде поправил: https://yadi.sk/d/gh5XUaPYeHomJ
D0130 распаковался правильно, остальные пока не тестил.

aliast
Спасибо! Потестил:

130 - работает.
131 - файл не создается.
132 - работает.
133 - работает.
134 - файл не создается.
135 - файл не создается.
136 - работает.
137 - файл не создается.
138 - файл не создается.
139 - файл не создается.
140 - файл не работает.
141 - файл не создается.
142 - файл не создается.

Да, это ошибка. Когда начал писать прогу ещё не вник в твой алгоритм и так и осталось. Спасибо!

тут точно новый исходник? по-моему так же работает. Кстати, у некоторых файлов в начале какие-то неизвестные данные, но если их отрезать, то будет нужный заголовок для формирования CEL. Тебе что-то известно об этом?...заметил, что первые 4 байта это смещение как раз к началу заголовка недоделанного CEL'a...хмм. может удастся автоматизировать. Опять же, зачем так было делать или это у меня неправильно дёрнуты файлы из REZFILE'a стрим ридером?...хм в 134 файле (133 в ридере) целых 12 смещений к началу заголовка...вот так дела :) Анимашка что-ли?

Я сделал, что размер всегда CCB 0x50. Стало больше открывать, но ничего нового я не увидел. Текстура игрового окна под разные размеры стала открываться и картинка с черепами.

Там цифры, минус и знак процента. Как раз получается 12. Похожая ситуация с 131 файлом. Там шрифт.

Нет! Видимо я не сохранил исходник, только exe.

Добавлено спустя 11 минут 57 секунд:

В 141 и 142 много кратинок, а в 140 НЕТ секции PLUT, т.к. смещение к ней равно нулю. В этом файле только PDAT.

aliast
А эти "много картинок" как зашиты? Как анимация или как большое полотно?

А шут его знает. А как ты себе представляешь шрифт как анимацию?) Нет, скорее всего игра берёт нужную буковку как номер файла со шрифтом + номер символа-картинки. Но и анимация в игре тоже есть... Думаю игра сама по номеру файла определяет его тип, визуально врядли есть разница.

Увидев библиотеку burger, уже ничему не удивлюсь. Ну, например, файл: такой-то, номер кадра: такой-то.

Вроде бы пофиксил: https://yadi.sk/d/Bjr7s5N0eJqp2

Осталось добавить распаковку массива картинок.

aliast
Спасибо, пощупаем!

aliast, отлично, отсутствие раздела PLUT не было учтено, картинка открывается :)