Спасибо за тесты.
Выкладываю третий вариант ,там получилось ,что блок более 32к в файл не сохраняется ,поэтому выскакивала ошибка ,уже разбил на части,вроде все нормально,пробуйте.
Хелп с обновлениями выложу на одной из страничек после тестирования ,думаю страна будет знать своих героев

Здравствуйте!
Протестил Вашу программу в режиме конвертации BMP и GIF (176х132) в ASM и BIN
форматы 16 и 8 бит.
Мне кажется при сохранении в ASM (16 бит) лучше все-же будет сохранить форму
массива как и для 8 бит, так можно использовать одну подпрограмму для чтения
(вместо ".dw 0xE71D" оставить ".db 0xE7, 0x1D" ) к тому-же отправка всеравно идет
по одному байту, а не по два...

Еще было-бы намного удобнее если картинка 176х132 открывалась на всю область просмотра,
ведь в конвертер в основном будут загружаться уже отформатированные по размеру изображения.
Еще рамку выделения изображения нужно-бы не отпускать за границы просмотра...

Конечно все это мелочи, Ваш проект и так супер!
И очень даже в тему!

и опять присоединяюсь к Andrew_KMR.
протестил в конверторе к С 16 бит. Усе ОК!
от меня предложение -
в шапке
//Screen Bin 128x88 16 bit (5:6:5)
добавить еще имя исходного файла - для информативности.
при закрытии массива
....,0xEF5B,
} добавить символ ";" , знаю про это и сам сегодня два раза наступил
ну конечно жду конвертор в монохром.
Не знаю на сколько востребованно, но все же: отображать позицию левой верхней точки области просмотра.

Насколько в курсе то что .dw 0xE71D ,что .db 0xE7, 0x1D одно и тоже ,тоесть в памяти оно располагается также и команде SPM ее все равно побайтно выгребать,хотя можно сделать и так ,в принципе без проблем.

Вот это я даже незнаю ,даже если удастся что то придумать со свойствами масштабирования обьекта Picture ,я не знаю как на это отреагирует API функция ,по факту она сканирует точку (размерность Pixel) прямо с экрана ,короче посмотрим ,может удастся что то придумать.


Согласен ,будет полезно ,сделаем всех четырех
Остальное подправим.
В пнедельник-вторник постараюсь выложить.

Протестировал последний вариант конвертера в 8 битах...
в асм файле в последней строке .db и все... можно ее туда и не ставить.
Вопрос по цветопередаче: Переводя картинку в 256 цветов любым редактором получаем 8 бит цвет - выглядит неплохо. Перегоняем конвертером- границы цветоперехода очень резкие - похоже как на 16 цветную картинку
и про рамку еще (может уже исправлено)гружу картинку - ткнул мышью - рамка в той точке куда ткнул 8 на 8... выбираю 132 на 176 и рамки не видно, но при выводе на дисплейчик вижу что у меня кусочек изображения с того места где я ткнул мышкой а не с 0... а остальное поле пустое, а рамка не рисовалась...

Ну лень мне было определять конец данных и сносить .db в последней строке

Винда выводит на монитор с цветом в 24бита ,в редакторе преобразование идет по другому ,каждому 24битному цвету присваивается номер до 256 ,тоесть количество цветов в картинке 256 ,но цвета то другой разрядности
В моем конвертере берется 3 старших бита для R,G и 2 старших для B из 8R:8G:8B ,возможно у вас есть более удачный способ - давайте обсудим.

Нужно следовать тому порядку работы с прогой ,про который я уже писал.
Потом я естественно я постараюсь поубирать коллизии, возникающие при произвольном использовании кнопок и шаловливых ручек .

Шаловливые ручки пользователей иногда находят такие баги, что сам бы никогда и не подумал (проверено на моей работе )
Вопрос: кто и где берет шрифты для своих програм на S65 ?
хотелось бы найти фиксированный шрифт размером 16х16 или 14х16 с кирилицей... ибо у меня прибор будет стоять в машине и надо шрифт покрупнее, чтобы не напрягаясь видеть показания....
или 8х8 выводить задваивая каждый пиксель чтобы получить 16х16...

Здравствуйте! Как у Вас обстоят дела с конвертером? Готов к новым тестам!

А на счет 256 цветов думаю может Вам заложить алгоритм, по которому я делал палитру!?
А именно: 3 бита могут иметь значение максимум 0х07, округляем входное 24-х битное значение цвета до числа кратного 36, получаем минимум 36 и максимум 252 - это и есть от 0х00 до 0х07 для трех бит...
Синий цвет так-же, только минимальное значение 84, а максимум то-же 252 (ну и конечно еще плюс нулевое значение).

У меня цвета вполне достойно на экране выглядят!


Сообщение отредактировал Andrew_KMR - Dec 19 2007, 14:55

Пока не готов ,застрял я с єтой монохромкой, незнаю что делать с картинками ширина которых не кратна 8 ,"хвосты" остаются

Насчет алгоритма - это тоже самое ,что и у меня ,только у вас арифметически.
Допустим есть цвет R = хххххххх ,получаем
00000000=0
00100000=32
01000000=64
01100000=96 и т.д. ,тоесть имеем кратность 32

Похоже 8бит и в Африке 8бит ,годится для шрифтов и мультяшных картинок.
Можно как вариант попробовать в редакторе сжать по вертикали в два раза ,а потом сконвертировать в 132х88х16б ,а строку прорисовывать дважды ,получиться по обьему кода как 8бит ,но цветов 16бит ,правда вот какая получится зернистость

2 Cyber_RAT
В редакторе шрифты FicsedSys и System имеют фиксированую длину ,там же и размер подберете.

Вроде домучал ,нужно проверить монохромку на ширине ,там где на 8 не делится ,типа 66,132

Могу выложить свою версия программу для конвертирования шрифтов, только не знаю, где надо поставить галочку в Builder C, чтоб не надо было библиотек при переносе на другую тачку.
Шрифты грузяться из картинки, задаются размеры, визуально контроллируется размер одного символа, и потом преобразуется под исходник. Коменнтарии и прочие разделители (0x для Си) задаются пользователем. Если нада, заатачу сюда....

выложите плззз... а то изобретаем велосипед каждый сам себе
Я тут подсел на шрифты psf консольные линуксовые (они фиксированного размера и есть неплохой выбор) gbdfed - редактор для них (linux естественно).

Протестил вчера последнюю версию вашей програмки.Работает великолепно, хоть пенёк 4 и задумывается. А так в целом цветопередача отличная! Спасибо, хорошая програмка.

протестировал монохромку на 64 *64

получаем неправильное преобразование
//Screen Bin 64x64 mono
{
0x7F,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 1
0xBF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 2
0xDF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 3
0xEF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 4
0xF7,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 5
0xFB,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 6
0xFD,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 7
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 1 - 8
0xFF,0x7F,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // 2 - 1

в строке 1 - 8 первый байт должен быть 0xFE.
ну и явно видно отсутствие вертикальной полосы (видимо одна и та же причина).
и еще раз обращаюсь с настойчивой просьбой (пожеланием)
- в комментарий к массиву вставить название исходного ВМР.
думаю, что вы переусложнили задачу по монохрому с точки зрения генерации
не кратной байту строки, я собственно это и не проверял.
по нажатию на "помощь" - куда то вылетает в поисках сайта?
при отображении координат окна - нижняя и правая координата должны быть на 1 меньше
(при 64*64 = 0,0,63,63)
а в целом очень здорово!

Сообщение отредактировал Шурила - Dec 23 2007, 05:27

Здравствуйте!
В этой версии Вашей программы после конвертации видна красная рамка
по координатам +Х и +Y. И при конверте в ASM 16 бит так и осталась .dw
И у меня почему-то возникли проблеммы с разрешением 176х132, команду
переворота экрана выводил, но картинка собирается в кучу, может я что
не так делаю...