Картинки для Вектора

[aGGreSSor]

Вообще-то странно, что BMP не работает. Я им переносил все картинки из фотошопа в Карандаш для Вектора когда Роботов делал. Просто исходный BMP должен быть палеттизированный 4BPP или 8BPP на худой конец. Но если 8бит то BMP будет ещё одну конверсию цветового пространства делать и можно "потерять" пикселы.

Даже не рассчитывал, спасибо за ответ и утилиты. Думаю их надо занести в БАЗИС. Проверил, они работают, но есть моменты по конвертации в целом. Да, я использую только палеттизированные 4BPP.

Попробуйте перенести BMP.com и все его оверлеи на квазидиск и сгенерить оттуда. Возможно, микроДОС шалит с оверлеями.

Попробую. Кстати, это интересно. Ведь InitApplication выключает, а RestoreBIOS включает квази-диск в PPCLib. Нашёл исходник scrpack.mac, он тоже рубит квазидиск перед началом работы (заставить его корректно работать на моих бинарниках не удалось, видимо что-то недопонял). Но да, BMP-DEMO в пакете BMP активно использует квази-диск. Нет опыта эксплуатации квази-диска, надо будет поразбираться.

Размер SCR - да, может превысить 32K. Там не очень эффективный упаковщик. Но для картинок спрайтов я использовал именно его.

Печаль. На моих картинках результат всегда превышает 32K и такие картинки потом ни одна программа: ViewSCR, Карандаш, Pencil и плагин DaScrViewWLX к TotalCommander показать не может. RECOMP если расположить картинку ниже 8000H тоже не распаковывает. Вообще всё зависит от характера данных. Если на картинке преобладают простые примитивы, много залитых областей на которых ничего не нарисовано или фон и что-то нарисовано в центре, то проблем не возникает. Результирующий файл будет в пределах 8К, т.е. размера одной плоскости. Такие SCR и SPR прекрасно распаковываются соотв. процедурами. Но если есть много дизеринга, высокая детализация, конвертация цветной фотографии, наконец, то мы вылезаем за эти пределы и DSPR может распаковать картинку в SPR не более 19К, причём её надо грузить с адреса 4000-5800H. Была надежда, что со SCR это не так, можно загрузить его с 8000H и распаковать через call RECOMP, но - увы, судя по всему.

Ни в коем случае не жалуюсь, просто излагаю кейс. Тут смешно что-то ожидать спустя 32 года, надо просто погружаться и писать конверторы для PC не имеющие ограничений. Возможно, попросить DEC добавить выгрузку в SCR в DaDither (поскольку он уже погружен). Последовательность такая:

bmp image.bmp -ok
cp image.bin image2.bin
bin2scr image2.bin
viewscr image.scr
viewscr image2.scr
dir

На выходе два файла: image.scr размером 31232 байта из bmp и image2.scr размером 128 байт из bin2scr. Оба непригодны для использования.
Показываю как это выглядит в эмуляторе:

Так что это просто констатация фактов. Пока буду использовать SPR, т.к. дальше возиться с конвертацией нет времени. Потом, при появлении/написании внешнего конвертора и (возможно) своих процедур распаковки, можно будет починить возврат в ДОС, в том что будет скорей всего зарелижено. Было бы супер найти код для загрузки с диска бинарного файла без вызова МикроДОС и где-то я даже видел бут который по описанию такое умеет, но это надо опять же затратить время на то, чтобы его найти и расковырять. Такое себе.

Хотя, если подумать, то можно просто разбить на два COM-файла, где первый показывает картинку, загружает второй и передаёт ему управление. Как в DRAW сделано, и в Хоббите у PPC. Отсюда ноги этого решения и растут, похоже. Короче, это вам не LOAD "" CODE 16384 в Sinclair BASIC писать..

[Advertiser]

[svofski]

DaDither 1.108 имеет опцию сохранения в SPR/PALS если выбран режим PCHG1. Но почему-то без PCHG1 в SPR нельзя.

А, не! Можно, только надо чтобы был Native dimension 256x256 -- видимо это ограничение SPR.