Поднимать старый код на новых компиляторах это жопа полная, особенно в Сях, где что угодно и как угодно пишется. В MovieToStream в итоге надо всю работу с файлами переписывать. Не ясно, что было в их QuickTime библиотеке, но есть Create (создать файл) и FSOpen (открыть файл), их почему-то в библиотеке qtmlclient.dll нет (пробовал скачать новую и ту, что ты мне дал, из них импортировать файл *.lib) и получается надо на обычные вызовы переделывать. Пока финиш.
Добавлено спустя 56 минут 9 секунд: EXTERN_API( OSErr ) Create( ConstStr255Param fileName, short vRefNum, OSType creator, OSType fileType);
/* * Create() * * Availability: * Non-Carbon CFM: in InterfaceLib 7.1 and later * CarbonLib: not available * Mac OS X: not available */
в файле Files.h ... как они это компилировали, если нужна какая-то InterfaceLib 7.1 да ещё и под непонятно что за CFM. Если бы ещё знать, что именно сделает этот Create.
Вот его вызов Create(filmFileName,0,'CYBD','FILM'); тип файла FILM, создатель CYBD...ничего не понятно.
Versus, я на _fsopen заменил. А инклуды типа stdio,stdlib ты откуда использовал? Ну и главный вопрос, что создаёт Create. Ясно, что файл, но записывает он туда что-нибудь или нет. Зачем передавать FILM, CYBD? Может там заголовок какой-то должен сформироваться.
Убрал пока Create, подсунул qtmlclient.dll экзешнику. Прога зависла на проверке, установлен ли QuickTime вызывав if ( ( status = Gestalt( gestaltQuickTime, &result ) ) != noErr )
Author Вечером посмотрю. Также выложу исходники своего makerez, который получился из старых Ребекки. Посмотришь, что именно я там поменял. Менял немного, и, кстати, там тоже нужно было выборочно свопить или нет отдельные данные. Помню, что удивлялся, почему наоборот прога действует.
Добавлено спустя 10 минут 59 секунд:
Author писал(а):
А инклуды типа stdio,stdlib ты откуда использовал?
Виндовские. Оттуда, кстати и fopen.
Добавлено спустя 5 часов 3 минуты 33 секунды: Author Исходники makerez выложил в теме про Doom.
Где ты это нашел? Че-то я потерялся... Не знаю, важно или нет, но файл qtmlclient.dll нашелся в установленном QuickTime C:\Program Files\QuickTime\QTSystem.
Народ, а кто замечал такую хрень? 1. Достаешь cel прогой 3DOResExplorer004a.exe; 2. Сохраняешь как BMP. - Потом если эту BMP сжимаешь обратно в cel без изменений, то cel получается куда большего размера, чем оригинальная. А если еще что-то дорисовываешь/перерисовываешь - вообще пипец, потом обратно не засунешь, если половину картинки не убрать. Короче, больше получается, чем была, раза в 1,5! 3. Самое интересное. Если в первый раз сжатую cel, но размером больше, чем нужно, пусть даже не измененную, а просто сковерченную в BMP, а потом обратно - взять и открыть в 3DOResExplorer004a и снова конвертнуть в BMP, а потом снова в cel - она становится уже годного размера. То есть, после двойной конвертации: Оригинальная cel => BMP = cel => BMP = итоговая cel. Тогда размер уже удобоваримый. И если по ходу двойной конвертации открывать HEX-редактором получающиеся cel, то видно, что с каждым разом, данные уже плотнее сидят. При этом, при многократной ковертации, в cel ничего не теряется. Я на каждом этапе, BMP фотошопом с пипеткой проверял.
Я вот, мучился с cel-ками Uncoced 16, имеющими пикселы всего 4-х цветов. Сама картинка ничего не меняется, все пикселы на месте и их цвета те же, а с каждой переконвертаций и повторными пересжатиями - cel весит всё меньше и данные внутри пакуются всё плотнее.
Думаю, что это смотря чем пересохранять. Если утилитами cdoty, то вряд ли это хороший способ. Я сконверченную cel пересохранял маковским фотошопом. В зависимости от выставленных параметров меняется и размер итоговой cel.
Маковским фотошопом пользуюсь, конечно, в том и дело.
Добавлено спустя 1 минуту 51 секунду: Утилита cdoty слишком "вонючая" - ей BMP нужен определенной палитры, плюс она может жать BMP в cel, только если ширина картинки BMP (cel) - чётная , и т.п. Говно - утилита, в общем.
- Потом если эту BMP сжимаешь обратно в cel без изменений, то cel получается куда большего размера, чем оригинальная. А если еще что-то дорисовываешь/перерисовываешь - вообще пипец, потом обратно не засунешь, если половину картинки не убрать. Короче, больше получается, чем была, раза в 1,5!
Вне зависимости от выбранных параметров сохранения?
aspyd писал(а):
То есть, после двойной конвертации: Оригинальная cel => BMP = cel => BMP = итоговая cel. Тогда размер уже удобоваримый.
Осмелюсь предположить, что это как при сохранении в jpg. Если много раз пересохранять одно и то же, то размер будет постепенно сокращаться.
Вне зависимости от выбранных параметров сохранения?
Я же говорю - достаем cel из игры. Она пожата в Uncoded 16 с Pack Cel Data. Всё. Чтобы игра её приняла обратно - надо жать её так же. Никакие там параметры крутить нельзя. Ковертишь ее в BMP прогой 3DOResExplorer, затем, ничего не трогая и не перерисовывая, конвертишь эту BMP обратно в cel. Из-под фотошопа под MAC, 3DO Cel Writer-ом. Выбрав Uncoded 16 и Pack Cel Data, иначе игра её не сожрет.
В итоге получается cel, но почему-то бОльшего размера, которую не запихнешь обратно в игру.
Потом эту "непригодную" cel снова открываешь 3DOResExplorer, снова в BMP, потом опять => в cel, из фотошопа, 3DO Cel Writer-ом, Uncoded 16, Pack Cel Data, то есть, точно так же. Теперь размер становится меньше, и она уже куда ближе к оригинальной. Может обратно в игру даже и влезть (а может, всё равно, не влезть).
А вот если в третий раз так же переконвертировать - уже не прокатывает, итоговая cel больше не уменьшается.
Versus писал(а):
Осмелюсь предположить, что это как при сохранении в jpg. Если много раз пересохранять одно и то же, то размер будет постепенно сокращаться.
А между тем кто-то продолжает клепать хоумбрюшки для 3DO. Во тут кто-то недо Tetris склепал (2015 год). "Недо" потому что падают одни только Z-ки (глюк эмулятора?) От этого же автора есть некий эмулятор NES для 3DO с сырцами! Надо бы поизучать :)
Появился вопрос - как позицию по осям координат для текстурки перевести в пикселы? Например, в заголовке вижу позицию по оси X = 1E. Сколько это пикселов нужно отсчитать, чтобы прикинуть её позицию на экране и откуда считать пикселы?
Вне зависимости от выбранных параметров сохранения?
Я же говорю - достаем cel из игры. Она пожата в Uncoded 16 с Pack Cel Data. Всё. Чтобы игра её приняла обратно - надо жать её так же. Никакие там параметры крутить нельзя. Ковертишь ее в BMP прогой 3DOResExplorer, затем, ничего не трогая и не перерисовывая, конвертишь эту BMP обратно в cel. Из-под фотошопа под MAC, 3DO Cel Writer-ом. Выбрав Uncoded 16 и Pack Cel Data, иначе игра её не сожрет.
В итоге получается cel, но почему-то бОльшего размера, которую не запихнешь обратно в игру.
Потом эту "непригодную" cel снова открываешь 3DOResExplorer, снова в BMP, потом опять => в cel, из фотошопа, 3DO Cel Writer-ом, Uncoded 16, Pack Cel Data, то есть, точно так же. Теперь размер становится меньше, и она уже куда ближе к оригинальной. Может обратно в игру даже и влезть (а может, всё равно, не влезть).
А вот если в третий раз так же переконвертировать - уже не прокатывает, итоговая cel больше не уменьшается.
Versus писал(а):
Осмелюсь предположить, что это как при сохранении в jpg. Если много раз пересохранять одно и то же, то размер будет постепенно сокращаться.
Не знаю. Потому и спрашиваю.
Кстати если все делать с помощью маковского фотошопа и установленных в нем 3до расширений,то в принципе файлы получались правильного формата и размера, а вот при использовании программ 3DOResExplorer расширение файла менялось((( также вроде в фотошопе можно было создавать файлы формата photocd, но к сожалению добиться полноценного результата проигрывания на приставке не удалось(((
Всем доброго времени суток. Я разработчик, в данный момент занимаюсь портами старых игр. (Если интересно - текущая платформа с основой stm32 мк). Если очень интересно - вот линк на то что у меня есть : https://github.com/cornway?tab=repositories По сути : Я хочу проделать то же с легендарной игрой - killing time. И мне нужна ваша помощь. Любая мелочь, я не спешу. Заранее всех благодарю. Пс : Я понимаю что мне потребуется емулировать хардвар, - на этот случай будет достаточно ресурсов. Пс2 : Я согласен даже на декомпиляцию.
Может я вконец отупел.... никак не могу понять, почему расчёт количества страниц видеопамяти для хранения битмапа рассчитывается именно по такой формуле: ScreenPageCount = (width*2*height+GrafBase->gf_VRAMPageSize-1)/GrafBase->gf_VRAMPageSize; Умножение на 2 - это 16-битный цвет каждой точки. Но для чего здесь добавляется размер одной страницы - 1? Upd: разобрался.. предположим, нам нужно выделить память под маленький кусочек битмапа,размером 100*100. Он займёт 100*100*2=200 байт. Размер одной страницы VRAM = 2048 байт. Получается, что при округлении до целого числа получится что под 200 байт нужно 0 страниц памяти вот поэтому и добавляется размер одной страницы памяти, чтобы получился не ноль, а 1. А минус один делаем, чтобы в случае выделения 2048 байт ровно у нас не получилось две страницы VRAM, а 1,99, т.е. 1 страница. PS: и правда отупел.. в который раз убеждаюсь - когда что-то непонято, начни объяснять это другому человеку, и тут же разберёшься PSS: это я тут сижу исходники Дума ковыряю (и не только Дума). Давненько я 3DO не занимался...
