Вектор-06Ц: Средства разработки

[svofski]

Держи: http://pastebin.com/AATFjnWV

Еще дополнительно, на вкус, в Settings specific - User:

{
	"extensions":
	[
		"inc",
		"asm"
	],


   "font_face": "Glass TTY VT220",
   "font_size": 18,
   "translateTabsToSpaces": true
}

[Advertiser]

[PPC]

Удивительные бывают открытия. Порылся у себя в закромах, и нашёл исходники ISA Sprite Editor, т.е. вот это: http://sensi.org/~svo/scalar/ware/661/
Причём, они даже компилятся и линкуются в готовую прогу, правда в КОИ-7 из-за того, что так работает m80, сбрасывая у всех data declarations старший бит. Похоже, что m80 мы захакали когда-то, и он у нас работал в КОИ-8, но как мы его захакали сейчас уже и не вспомнить. Тогда каждый день что-то правили то в Суперкалке, то в Вордстаре. В любом случае, выкладываю исходники. Я только файл для сборки make.sub приделал. Ещё из интересного нашёл переделку моей 2dsci.mac (см. выше), но c для принтера D100. У Серёги, получается был такой принтер. Глядишь, так я нарою и исходники нашего БИОСа. Где-то они были.

[PPC]

Две программки, прямо со сковородки. Обе с исходниками.

1. IDC.COM - Image Data Converter

Конвертирует Windows или OS/2 bitmap размером от 1x1 до 256x256 пикселов в формат несжатой Векторовской видеопамяти. Входной .BMP файл должен иметь 4 бита на пиксел без RLE компрессии. Выходной файл всегда будет иметь размер 32K и может быть просмотрен утилитами 2DSCI.COM, GRAB.COM (см. пост выше) или SHIM.COM (см.ниже в этом посте). Изображение меньшего размера всегда выводится в левом нижнем углу. Утилита GRAB использует такой-же формат, поэтому возможно выдирать куски из полученного изображения и создавать спрайты в многочисленных форматах, которые GRAB поддерживает.

Во время конвертации, IDC.COМ также производит текстовый файл с исходным именем .BMP файла и расширением .PAL, содержащий палитру, конвертированную из 24-битового цветового пространства в Векторовскую 8-битовую палитру. Файл содержит палитру в виде кода на ассемблере вида:
DB xx
...
DB yy
и может быть немедленно использован для ассемблирования. Комментарии в файле содержат исходные цвета в .BMP картинке и рассчитанное значение яркости. Поддерживается десятичный (по умолчанию) и шестнадцатиричный (опция IDC -h1) форматы вывода палитры. Алгоритм нахождения ближайшего цвета пока довольно примитивный, поэтому возможны повторения цветов, что может быть исправлено дальнейшим редактированием .pal файла.
По умолчанию, IDC производит "зеркальное" копирование плоскостей из BMP, так, что цвет 0 соответствует плоскости 0xE000, а цвет 8 - плоскости 0x8000. Зеркальное копирование можно отменить опцией
IDC -f0
Опция IDC -vX, где X=0,1,2 задаёт объём выдаваемой информации об исходном изображении и диагностики во время конвертирования.
Процесс конвертирования достаточно долгий, и требует большого количества обращений к диску, так что лучше используйте квазидиск.
Исходники для компилятора Supersoft C прилагаются.

2. ShIm.COM - Show Image
Позволяет посмотреть картинку, сгенерённую утилитой IDC в цветах из файла палитры в 16-цветном режиме. Не портит содержимое квазидиска.
Единственное условие, цвета в файле палитры должны быть в десятичной системе счисления.
Файл палитры может содержать и больше строчек с цветами, ShIm будет использовать только первые 16. Выход из просмотра - клавиша BackSpace.
Исходники для m80 прилагаются.

[ivagor]

О, я тоже нечто отдаленно похожее делал. Там слегка устаревшая версия (вроде уровни не соотвествуют текущим версиям эмуляторов, еще какая-нибудь мелочь).

[PPC]

О, я тоже нечто отдаленно похожее делал. Там слегка устаревшая версия (вроде уровни не соотвествуют текущим версиям эмуляторов, еще какая-нибудь мелочь).

А я даже немножко пользовал SPRView.
Вот, собсно, результат прогона BMP через IDC на VV, затем-screenshot и в JPG. Не все цвета совпали, но вроде на оригинал-похоже.

[PPC]

Главная проблема сейчас - найти более разумный алгорим подгонки цветов. На картинке выше пара-тройка цветов совпала, потому, как алгоритм сейчас донельзя примитивный (ниже - кусок функции GenPal() из IDCLib.c)

		/* BGR(8,8,8) to BGR(2,3,3) */
				
		b = rgb->rgbBlue  / 64;
		g = rgb->rgbGreen / 32;
		r = rgb->rgbRed   / 32;
		l = (rgb->rgbBlue + rgb->rgbGreen + rgb->rgbRed) / 3;
		
		
		color[i] = (b << 6) + (g << 3) + r;

[ivagor]

Сначала я тоже так делал, потом стал по евклидовой метрике искать ближайшие цвета к векторовским, вроде так все же лучше и правильнее. Причем "векторовские цвета" желательно задавать конфигом, чтобы можно было без перекомпиляции изменить. А то в VV одни цвета, в emu - другие, мне кажутся правильными третьи, да и у каждого векториста свое собственное мнение, какой д.б. палитра.
В утилите Романа кстати много вариантов, но задания палитры, к которой подгоняем, нет. Хотя у него там есть другие "регуляторы".

[PPC]

Погляжу, на Евклида, спасибо. В принципе, так как конвертилка у меня генерит отдельный файл с палитрой, где в комментариях стоят исходные цвета, можно написать какой-нибудь постпроцессор "уточнения палитры с опциями" перед тем как просматривать изображение.
Можно конечно и ручками, в обычном текстовом редакторе палитру править, "разводя" сдублированные цвета. Всё-же, это средство разработки, побочный эффект моей основной задачи, поделка, зробленная "на коленке" за 3 дня. В общем, покумекаю, но не очень много.

[ivagor]

Сейчас посмотрел, у меня в последней версии (1.79) так:
На основании уровней из конфига формируем полную векторовскую палитру (256 цветов) с 8 битами на компоненту. Потом перебираю каждый цвет палитры картинки и ищу ближайший цвет в векторовской картинке по метрике
(r1-r2)*(r1-r2)+(g1-g2)*(g1-g2)+(b1-b2)*(b1-b2)
Может это тоже не лучший вариант, но он мне понравился больше, чем просто отбрасывание бит (которое, фактически, является частным случаем)

[PPC]

А кстати вопрос. При всех разных исходных цветах, возможны-ли совпадения конечных цветов по такой метрике или исключены?