PaintCAD Mobile - журнал разработки

[blackstrip]

Продолжаем разборки с j2me окошком Video3GP

Андроидовское окошко Video3GP2 создано, работает, успешно оттестировано на многих андроидах (см. предыдущий пост). А вот в яве мы только подвинули две нижние строчки (размер кадра в пикселях и имя файла будущего снимка) чтобы они не улезали за панель софт-клавиш.

Попробуем его починим как-нибудь. Или улучшим. Или посмотрим почему оно так плохо себя ведет в эмуляторе.

Отладка на эмуляторе Siemens SL75

Сдвигаем видеовывод

Будем показывать в заголовке окна ошибки пока что.

Получаем размер видео как обычно:

Код: Выделить всё

sw=vc.getSourceWidth();
sh=vc.getSourceHeight();

Левый верхний угол показа видео сдвинем чтоб не залезал на заголовок окна:

Код: Выделить всё

vc.setDisplayLocation(3 виртуальных пикселя,3 виртуальных пикселя + высота заголовка + 1 виртуальный пиксель);

Ширину вывода тоже пропорционально сожмем если ширина видео не равна нулю

Код: Выделить всё

if (sw!=0) vc.setDisplaySize(ширина экрана - 6 виртуальных пикселей,(ширина экрана - 6 виртуальных пикселей)*sh/sw);

Видео запоказывалось со сдвигом вниз, но не сжимается по ширине (может сименс не умеет сжимать его):



Ну это уже лучше, хотя бы заголовок окошка видно будет.

Почему не фоткает снимки

Сначала попробуем брать снимок без указания параметров:

Код: Выделить всё

byte[] b = vc.getSnapshot(null);

При снимке смотрим что за исключение возникает:



Слишком длинный текст, ничего не понятно) Выведем его в текстовое поле:



Пишет "Такая кодировка не поддерживается"

Пишут, что можно запросить все поддерживаемые кодировки через System.getProperty("video.snapshot.encodings") - но на сименс-эмуляторе оттуда возвращается пустая строка...

Попробуем снимем кадр с другой кодировкой наугад:

Код: Выделить всё

byte[] b = vc.getSnapshot("encoding=jpeg");

Опять кодировка не поддерживается)

Код: Выделить всё

byte[] b = vc.getSnapshot("encoding=png");

И опять кодировка не поддерживается))

Есть еще вариант bmp! Попробуем его:

Код: Выделить всё

byte[] b = vc.getSnapshot("encoding=bmp");

Тоже не поддерживается. В общем, эмулятор никаких кодировок не поддерживает =) и не снимает никаких снимков с видео.

Но вообще в коде было зашито что запрашиваем всегда vc.getSnapshot("encoding=jpeg"), но сименс, видимо, плевал на этот параметр и сохранялись всегда png файлы, поэтому у файлов выставлялось png расширение, а остальным телефонам назначалось jpg расширение для снимков (они-то, видимо, слушались параметра "encoding=jpeg").

Вообще надо сделать как в андроид-окошке на выбор PNG и JPG - и запрашивать, в зависимости от выбранного формата, "encoding=jpeg" или "encoding=png", и ловить ошибку если такой формат телефоном не поддерживается, выводя куда-нибудь что снять кадр не удалось.

Отладка на Nokia 7900

Проверим снимок с видео на реальной нокии Nokia 7900. Поставим сразу "encoding=jpeg" и попробуем снять снимок. Видим другую ошибку:





Пишет, что только съемка через capture://image поддерживает снимки. НО capture://image - это же работа с камерой. А для файлов нужно file://путь/файл.mp4. Получается на нокии 7900 кадры из видео снять и сохранить в файлы не получится.

Зато можно увидеть на первом из этих нокиевских скринов что нокия полноценно слушается кода установки размера видеовывода:

Код: Выделить всё

if (sw!=0) vc.setDisplaySize(ширина экрана - 6 виртуальных пикселей,(ширина экрана - 6 виртуальных пикселей)*sh/sw);

и сжимает видеопоток так, что и слева от него и справа остается по три виртуальных пикселя.

Отладка на Nokia N90

На ней 3GP файл вообще не открывается. И попытка снимка выдает ошибку "0". Ну раз видео не открылось, то и снимать нечего.



Отладка на эмуляторе Siemens EL71

Открываем видео:



Иногда эмулятор говорит что не может ничего снять... и извиняется =)





Вероятно тут видео кончилось или сбой какой-то.

А иногда, как обычно, пишет что не поддерживает кодировку:



В общем, на нем тоже ничего не снять)

Переделываем интерфейс в подобный андроидовскому окошку Video3GP2

В любом случае, на реальных сименсах снимались снимки в файлы, да и на других моделях съемка кадров может и работать на каком-нибудь формате файла (jpg, png, bmp). Поэтому переделаем окно под более удобный вид для этих телефонов.

Нужно:
- сделать по кнопке "0" выбор формата (encoding) из известных "jpeg", "png", "bmp" и формат по умолчанию "???" (когда вместо формата передаем в getSnapshot параметр null и телефон должен сам выбрать формат и выдать снимок в этом формате, расширение файла в этом случае назначим ".pic", но даже если внутри будет записан PNG или JPG - по "Открыть ???" он должен загрузиться в паинткад). С выбором формата менять и расширение файла
- контролировать сбой загрузки видео и выводить сообщение что его не удалось загрузить
- контролировать сбой съемки кадра и выводить сообщение что кадр не удалось снять (тогда пользователь попробует сменить формат по "0" и снять кадр в другом формате)
- выводить слева внизу размер видео по ширине/высоте
- выводить справа внизу номер кадра + расширение без приписки имени видео
- сделать отчет номера кадра с 1, а не с 0
- сделать более хитрый подбор ширины/высоты видеопотока для vc.setDisplaySize (как в андроидовском окошке), учитывающий и ширину, и высоту экрана и доступное на экране место, чтоб видео не залезало на нижнюю строку с информацией и панель с подписями софт-клавиш

Сделаем окно Video3GP для j2me такое же по интерфейсу как окно Video3GP2 для андроида.

У j2me плеера есть функции получения текущей временной позиции просмотра в микросекундах p.getMediaTime(), длительности видео в микросекундах p.getDuration(). Также есть функции отрисовки видеопотока в нужном месте экрана и с нужным размером (чтоб сделать масштабирование по кнопке "*" на весь экран).

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

Если телефон не знает текущую позицию просмотра, то он возвращает TIME_UNKNOWN равное -1 в ответ на вызов getMediaTime(). Если он не знает текущую длительность видео, то он тоже возвращает TIME_UNKNOWN равное -1 в ответ на getDuration().

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

Обработаем неизвестную длительность как невозможность по клику на слайдере на экране, и отображение на нем длительности как "??? с". А если неизвестна и текущая временная позиция плеера, вообще будем писать на слайдере "??? с" без всякой черты, разделяющей текущую позицию и длительность.

И перемотка должна вроде бы работать по p.setMediaTime(timemks), но может не поддерживаться телефоном и тогда ничего не перемотаешь.

Вот что получилось

Nokia N90

Nokia N90 не хочет открывать ни один из видео файлов (3gp мелкий или побольше, mp4 большой):



Nokia 7900

Окошко с подсказками по кнопкам теперь такое же как в андроиде. По кнопке 0 переключается JPG, PNG, а дальше еще BMP и ??? (формат по умолчанию, выбираемый самим телефоном, сохраняет кадры в PIC-файлы, а внутри на самом деле или PNG, или JPG, смотря что конкретный телефон считает форматом по умолчанию). В подсказке не будем расписывать все 4 формата, т.к. BMP это вообще редкость (огромные по объему кадры в памяти, но пишут что такое бывает на каких-то телефонах), а ??? это только если JPG и PNG снимать не хочет, то можно попробовать попросить снять формат "по умолчанию", переключившись по "0" на него.



Эта нокия идеально выполняет сдвиг и масштабирование растра видеопотока на экране, но не может сообщить сколько длительность видео, поэтому на слайдере отображается "текущая позиция / ??? с", а слайдер всегда заполнен полностью (т.к. не может нарисовать сколько из длительности уже проиграно и в каком месте видео по времени мы находимся относительно всего видео).

Без масштабирования по звездочке - растр видеопотока посередине свободной области окна:



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



Но т.к. она, как показывалось выше, снимает только кадры с потока с камеры capture://image (и говорит об этом в исключении, которое возникает при попытке снять кадр), то паинткад видит что произошла ошибка и пишет об этом бледно-красным текстом "Ошибка съемки" на 3 секунды на переключателе режима сверху окна и при первой ближайшей перерисовке окна сообщение исчезнет само (например, если идет проигрывание видео по #, и окно часто перерисовывается, отображая слайдер с текущим положением проигрывания во времени). Если попереключать переключатель режима по ДжойВправо-ДжойВлево, то текст ошибки пропадет сразу при переключении, не дожидаясь трех секунд. А если произведение выключено - ошибка будет висеть до любой первой перерисовки:



Если переключить переключатель во второй режим - то включится съемка в файл (прямо как в аналогичном окошке андроида Video3GP2):



Но снимать кадры в файлы от переключения режима Нокия, конечно, не станет. Она снимает только кадры с видеопотока камеры, а из файла с видео - снимать не хочет.

Эмулятор Siemens SL75

Окно с подсказками по клавишам теперь новое как и на нокии. Короткие строчки сверху, а длинные снизу, чтоб не залезли на значок на узких экрана с большими буквами шрифта.



Само окно при запуске проигрывания теперь пытается перерисовываться (каждые 300 мс), и на сименсе почему-то закрашивает плеер =) На нокии он всегда рисовался поверх того, что рисовалось на экране мидлетом в яве.



С другой стороны - это даже хорошо. Не будем закрашивать фоном окна весь экран. А четырьмя прямоугольниками нарисуем фон сверху над видеопотоком, фон снизу под видеопотоком, фон слева от видеопотока и фон справа от видеопотока. А саму область видео закрашивать не будем. Пусть там будет нечто, что по идее должно полностью закраситься видеопотоком. На нокии проблем не будет. На сименсе - это позволит видеопотоку там отрисовываться когда он захочет и никто не будет его закрашивать фоном окна. И если он будет кривого размера (не такого, какого попросил паинткад) и в кривой позиции (не в той, в которой попросил паинткад), но закраска фоном обрежет куски видеопотока, торчащие за рассчитанную область видеопотока.

С первого проигрывания в эмуляторе видеопоток не хочет рисоваться - остается желтое (цвет системного фона окошек) поле:



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



Повторное проигрывание - появляется видео, проигрываемое с нуля, уже без мусора:



Ни один формат (JPG, PNG, BMP, ???), выбранный по кнопке "0", не дает ничего снять, прямо как на нокии 7900 =) Ну это все эмуль виноват, вообще физический настоящий сименс снимать кадры-то умеет:



Кстати, что-то этот эмулятор сименса плохо реагирует на включение проигрывания/паузы, много раз понажимаешь - плеер высыпает какое-нибудь исключение в лог и окно виснет, а то и паинткад, а то и весь эмуль. Да и без виртуальной клавиатуры (на которой подсказки-значки на кнопках) мало какой человек вспомнит с того окошка с подсказкой по кнопкам, которое показывается перед этим окном съемки кадров, что включить проигрывание можно по нажатию "#".

Поэтому сделаем в явовской версии Video3GP небольшое отличие от андроидовского Video3GP2 - при открытии видео и попадании в окошко съемки кадров сразу будет запускаться проигрывание как раньше. Остается, по идее, только нажать джойстик (а на это подсказка внизу окна показывается со словом "Снимок") и снять кадр, затащив его в паинткад.

А уже тем, кто запомнил управление, будет можно переключиться на съемку в файл, остановить/продолжить показ видео и т.д.

Эмулятор Benq-Siemens EL71

Окошко с подсказками по клавишам выглядит нормально:



А вот с видео этот эмулятор уже ничего не слушается, в отличие от SL75. Показывает видео со сдвигом, по горизонтали равным запрошенному, а по вертикали - ниже примерно на 1 строку текста. И вообще не хочет обрезать видео, показывает целиком, поверх окошка. Оно вылезает из бледно-фиолетового прямоугольника, в пределах которого должно рисоваться:



Все 4 формата снимать не хочет (JPG, PNG, BMP, ???):



MP4 размером 640x480 открывает и даже пытается ужать под требуемую область, но у него не выходит) Видимо, сжимает в какое-то стандартное количество раз, например, в 2 раза:



Ну ладно, как-то работает на эмуляторе Benq-Siemens EL71. Кадры не снимает во всех форматах из MP4 тоже =) На реальном бы устройстве посмотреть вместо эмулятора. Но для этого надо сначала сократить требования паинткада по памяти каким-то образом.

Теперь модуль Video3GP работает и на андроиде, и на яве с новыми возможностями. Андроидовская версия проверена. Явовская - проверена временем, код сохранения кадров не изменялся. Если найти такой java-телефон, который снимает кадры - то этот модуль будет снимать кадры из видео и класть в PNG/JPG/BMP/PIC-файлы в папку где лежит видео

Масштабируем следующее окно

Дальше идет модуль VideoBMP и еще один похожий модуль VideoGIF:



Ревизия окон VideoBMP и VideoGIF

Рассмотрим VideoBMP, а править будем сразу оба, т.к. они похожи.

Это окно VideoBMP используется при массовой конвертации BMP-файлов в GIF-файлы (чтобы потом собрать из них GIF-анимацию, например). Работает эта функция так:

1) в главном меню выбрать "0"-"Обработка"-"BMPs->GIFs". Появится указание что делать дальше - указать папку с готовыми 1.bmp, 2.bmp, 3.bmp и так далее:



2) после выбора в файловом менеджере одного из нумерованных файлов 1.bmp, 2.bmp... появляется окно VideoBMP. Из-за особенностей построения экономного кода оно пошагово отрисовывается, но андроид ляпает пару перерисовок при старте окна - и окно отрисовывается, стирается, а потом поверх окна (которое уже стерто) рисуется только список найденных BMP-файлов. Вообще это было сделано чтоб по движению по списку рисовать только список, а окно больше не рисовать. Но в андроиде это выглядит после двойной перерисовки и пропадания окна вот так:



Убеждаемся что их ровно столько, сколько надо. И жмем правый софт чтобы продолжить. Ну или левый чтобы отменить все это.

3) дальше вызывается открытие каждого BMP и сохранение в соответствующий GIF. В заголовке окна с прогрессом сохранения пишется какой из скольких файлов обрабатывается. Интересно что с полосой прогресса - 100%, но полоска в отрицательную сторону нарисована:



4) ну и в конце радостное окно об успешном завершении конвертации:



И если BMP-файлы не с именами 1.bmp, 2.bmp - то этот модуль их еще и переименовывает в 1.bmp, 2.bmp)

Починим процедуру отрисовки окна VideoBMP чтобы оно отрисовывалось полностью. И посмотрим что там с полосой прогресса при такой пачечной обработке BMP-файлов.

Вставили процедуру перерисовки окошка всегда для андроид-устройств. И еще в процедурах отрисовки полос прогресса теперь контролируем чтоб не было текущее значение меньше нуля (тогда рисуем как при нуле) или больше максимума (тогда рисуем как максимум).

Модуль VideoGIF - для сборки анимированных GIF-файлов. Оно похож по строению на VideoBMP, сразу и в нем тоже исправим перерисовку.

Еще в обоих модулях поправим расчет высоты списка так, чтобы снизу до полосы с подписями софт-клавиш гарантированно был выпуклый край окна (2 виртуальных пикселя) + зазор до списка размером 1 виртуальный пиксель.

А еще в окне Explorer тоже подправим зазор списка, чтобы внизу до края экрана был гарантированно был выпуклый край окна (2 виртуальных пикселя) + зазор до списка размером 1 виртуальный пиксель

Получилось в VideoBMP:



Получилось в VideoGIF:

[blackstrip]

В ходе простых тестов было обнаружено что функция BMPs->GIFs (VideoBMP модуль) на андроиде должна по очереди открывать BMP и сохранять их как GIF. Но если положить 256-цветные BMP, то она что-то открывает, видимо, неудачно, и сохраняет просто текущий рисунок в 1.gif, 2.gif, 3.gif.

Если положить 24-битные BMP, то происходит то же самое)

Посмотрим почему это происходит и починим ее.

Попутная починка удаления файлов

После очередного текста захотелось удалить получающиеся GIF-файлы для чистоты эксперимента (чтоб новые создавались с нуля, а не поверх старых) - но в андроиде показывается форма с надписью "Удалить 1.gif?" и все. Типа такого:



Должен быть вызов меню, но как его вызвать если у устройства нет кнопки "Меню")

Вызов меню был сделан в паинткаде на формах только для текстовых полей (например, при вводе имени файла) - в паинткаде если долго держать палец на текстовом поле в андроиде, то вылезает меню. Переделаем окно "Удалить" из формы в полноэкранное текстовое поле. Получилось:

1) Выбираем файл, жмем на вирт.клавиатуре кнопку "..." и в меню выбираем "Удалить":



И вот она полноэкранная текстовая форма, в которой написано "Удалить имя_файла ?". Если в ней долго пальцем жать в текстовое поле - то вылезет желанное меню, и в нем можно выбрать "Убить" чтобы удалить файл:



На некоторых телефонах типа Redmi Turbo 3 при удерживании пальца вылезает не только меню, но еще и меню правки текста (выделить/вырезать/копировать/вставить и т.д.), но оно не мешает, жмем кнопку "Убить" и файл удаляется:



При запуске в яве - оставим окошко без текстового поля:



Теперь в файловом менеджере под андроидом файлы можно удалять.

Починка пачечной конвертации BMP в GIF

Проверка на сименсе в яве показала что конвертация BMP в GIF прекрасно работает, все проблемы в андроиде.

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

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

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

Еще один мини-баг BMPs->GIFs

Был выявлен на сименсе 132х176 точек, где все рисуется по умолчанию в масштабе х1.

После обработки в паинткаде оставался открытым последний BMP кадр. Но при масштабе x1 не было перерисовки рисунка и рисунок был белый как будто (а при больших масштабах рисунок рисовался поточечно и этого не было заметно). Теперь это исправлено и последний открытый кадр после обработки BMPs->GIFs полноценно виден и в масштабе x1 тоже.

Теперь конвертация из пачки BMP в пачку GIF работает отлично и под андроидом. Можно долго рисовать какую-нибудь картинку, сохраняя историю рисования в 1.bmp, 2.bmp, 3.bmp, 4.bmp и т.д. А потом конвертировать их все в GIF-файлы и собрать Work-In-Progress GIF-анимацию, чтобы посмотреть как шло рисование от пустого листа до финального рисунка. На последний кадр с финальной картинкой можно поставить задержку подольше чтобы можно было рассмотреть что получилось в конце. Типа этой из галереи паинткада (правда, эта на PaintCAD 4Windows была нарисована, курсором-жуком, который катается как машина по рисунку, вырисовывая дуги нужного скругления в зависимости от выбранных параметров):



Мелкие исправления

Центрируем текст и значок в окне выбора режима SelectMode

Выбиралось что больше - значок (вот эта цифра "8") или текст ("256 цветов, GIF, анимация") - и это расстояние запоминалось чтоб ниже рисовать следующие элементы (переключатель режима), а потом и значок, и текст рисовались от верхней границы области:





Теперь текст центрируется по вертикали в области:





"Шрифт окон" - увеличиваем высоту

Когда включали настройку "Шрифт окон", то вместо телефонного шрифта в интерфейсе использовался растровый, встроенный в паинткад шрифт. Но у него, оказывается, символы имеют такие изображения, что есть те, которые в самом верхнем ряду пикселей нарисованы (это еще нормально), а всякие свисающие буквы типа p, g достают до самого нижнего пикселя изображения символа.



В итоге, в окнах строчки были слишком скученно нарисованы, в подписях к софт-клавишам вообще нижняя часть символа проваливалась в темную выпуклую область окошка и была почти не видна:



Добавим одну строчку пустых пикселей в конец всех букв. Теперь символы будут не 12 пикселей высотой, а 13. Все-таки между строчками должен быть какой-то зазор.



Теперь строчки рисуются пошире, а буквы касаются выпуклой области окошка, но не проваливаются в нее.

Было и стало в стартовом окне:





Было и стало в меню:





И на большом экране стало:





Чиним кривые треугольники

В интерфейсе есть треугольные стрелки у "переключателя" по бокам:



И в палитре в "спектральном подборе":



Толстая линия окантовки у них должна быть с постоянной толщиной с виртуальный пиксель (хотя бы в сечении по вертикали, т.к. она продолжает такую же горизонтальную синюю линию центрального элемента переключателя), но она явно меняется. Потому что при отрисовке она набирается из тонких линий, у которых начало плавно съезжает в пределах 1 виртуального пикселя по вертикали, а конец - в пределах такого же виртуального пикселя по горизонтали (на остром углу стрелки). Чтобы получилась толщина ровно 1 виртуальный пиксель по высоте - на остром углу съезжать подальше чем 1 виртуальный пиксель.

Получаем новые стрелки переключателя (на разных экранах, где виртуальный пиксель это 1 реальный, 2 реальных и 9 реальных):







И новые стрелки в спектральном подборе палитры (на разных экранах, где виртуальный пиксель это 1 реальный, 2 реальных и 9 реальных):

[blackstrip]

Еще мелкие доработки

Отображение времени в меню

На скриншоте про "шрифт окон" в предыдущем посте в главном меню внизу рисуется время вместо подсказки что "0" вызывает справку по пункту (0-?):



В меню, где справки нет, всегда отображается время. А в меню, где справка есть, при первой перерисовке - время, а при последующих уже "0-?". Но в андроиде в microemu при переключении окна срабатывает сразу две перерисовки и время никогда не видно.

Починим это) Теперь во всех меню и в андроиде при первом отображении рисуется время (пока в списке курсор не передвинешь или не переключишь подменю ДжоемВлево/ДжоемВправо):



Файловый менеджер - исправляем создание папок, удаление и переименование файлов/папок в неподходящих местах

В списке дисков папку не создать. И не удалить диск. И не переименовать. Поэтому поставим проверки и если это вызвано через меню, то паинткад ничего делать не будет.

Аналогично в пустой папке с одним пунктом "Пусто ;P" этот пункт не переименовать и не удалить (будет краш). Тоже поставим проверки и заблокируем это дело чтобы ничего не происходило, и краш тоже. Но папку создать в пустой папке можно.

Зависание в J2ME Loader и проверки на сони-эриксон

Проверка на запуск под сони-эриксоном в нескольких окошках заставляла их перерисовываться полностью если паинткад запущен на телефоне этой марки. Были какие-то проблемы с сонериком, помню. С отрисовкой.

Но в j2me loader (андроидовский запускатель j2me JAR-файлов) теперь окошко инструментов, например, вообще как будто виснет. И с клавиатуры, и с тачскрина не хочет выбирать инструменты. Но зато может выбрать текущий выбранный по правому софту или выйти из окошка по левому. И там как раз проверка на сонерик и полная перерисовка окна с картинками всегда. Убираем проверку - перестало виснуть.



Чудеса, ну ладно, уберем из всего паинткада (штук 5 в разных окнах) проверки на сонерик.

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

Исправляем размер списка файлов в пустой папке

В файловом менеджере в папке с файлами рисуются значки и имена файлов. Из-за этого пункты в списке большие по высоте:



А в пустой папке рисуется список с пунктом "Пусто" и его высота уже без значка, просто со строчку текста:



Из-за этого высота списка и высота выделенного пункта меняются:



Поправим это - сделаем чтоб в файловом менеджере высота пункта в списке с "Пусто" была такой же, как в списке со значками:



Теперь при переходе в пустую папку и выходе из нее обратно в папку с файлами - высота списка и высота пунктов в нем не будут прыгать.

Исправляем горизонтальный размер списка

Оба списка - со значками и без - почему-то справа на 1 реальный пиксель короче чем заголовок окна. На большом экране с большими виртуальными пикселями этот сдвиг на 1 реальный пиксель незаметен. А вот на мелких экрана виден.

Сделаем оба списка длиннее на этот пиксель. Получилось:





Масштабируем два следующих окна

Дальше идет модуль ViewBMX, а за ним View SBMX:



Эти окна - проигрыватели 4-кадровых BMX-анимаций.

Как работает ViewBMX

Чтобы увидеть его и использовать - надо:

1) нарисовать или открыть в 8-битном чернобелом режиме BMX-анимацию:



2) нажать ДжойВправо и в меню команд выбрать "Плеер BMX"



3) появится окно ViewBMX. Кнопками "*" и "#" переключать кадры и смотреть анимацию. Вон она в центре экрана:



Как работает ViewSBMX

А чтобы его увидеть и использовать - надо:

1) нарисовать в 8-битном чернобелом режиме BMX-анимацию на рисунке 32х32 пикселя. Для удобства можно нажать "ДжойВлево" - "Разбить" чтобы анимация делилась не на 4 вертикальных части-кадра, а крестом на 4 кадра по 16х16 пикселей. Кадры будут располагаться как:
1 3
2 4

2) можно и открыть обычную анимацию 16х64 пикселя, сразу превратив ее в 32х32:







3) тогда (при ч/б картинке 32х32 пикселя) кнопка "ДжойВлево" в главном окне не обменивает цвета ПЦ и ЗЦ местами, а открывает меню для управления такими картинками. Выбираем там "Плеер 16х64":



4) и открывается окно ViewSBMX:



У него, почему-то, панель софт-клавиш уже с закраской (а у ViewBMX прозрачная).

А так - эти два окна ViewBMX и ViewSBMX отличаются только текстом в заголовке окна и способом извлечения кадров с картинки: ViewBMX представляет картинку как 4 вертикальных кадра, ViewSBMX представляет картинку как 4 кадра 16х16 пикселей, размещенные в квадратном рисунке 32х32 пикселя.

Объединим их в одно окно. До этого уже был сделан видеоплеер для вытаскивания кадров из 3GP/MP4 видео. Примотаем его к окну ViewBMX, изменив функции для работы с 4-кадровыми анимациями.

Получается вот такое окно:



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

По кнопке "#" как в плеере 3GP/MP4 можно запустить проигрывание. По кнопке джойстика можно выбрать одну из 3 скоростей проигрывания: 0.5x (один кадр за две секунды), 1x (кадр в секунду), 2x (кадр в полсекунды) в порядке возрастания. Это же можно сделать по кнопке "ДжойВверх". А по кнопке "ДжойВниз" выбирать скорость в порядке убывания. Текущая скорость показывается в середине панели софт-клавиш.

По кнопке "*", тоже как в плеере 3GP/MP4, можно включить масштабирование кадров анимации чтобы лучше их разглядеть. Здесь масштабирование будет "кратное" - размер рассчитывается как "увеличивать/уменьшать в 2 раза пока не упремся в границы разрешенной для показа области", тогда все увеличенные пиксели будут гарантированно ровные, одинаковые:



По кнопке "0" можно переключить полосу времени на обычную (чтобы прикинуть сколько по времени проигрывается анимация в 4 кадра при разных скоростях):



Если при черно-белом рисунке 32х32 пикселя по кнопке "ДжойВлево" вызывается меню "16х64" и там можно выбрать "Плеер 16х64" для проигрывания нарисованной BMX-анимации, то при других размерах рисунка в ч/б BMP/BMX режимах просто обмениваются цвета ПЦ и ЗЦ. Хотя переключать черный и белый цвет можно и по левому софту (в ч/б режиме по левому софту вместо показа палитры просто ПЦ переключается с черного на белый или с белого на черный). Для удобства сделаем вызов BMX плеера в главном окне рисования по кнопке "ДжойВлево" в любом черно-белом режиме (BMP и BMX).

В самом окне BMX плеера ViewBMX кнопками "ДжойВлево" и "ДжойВправо" будем переключать по 1 кадру назад/вперед, аналогично нажатию "4" и "6" на клавиатуре или зеленых стрелок слева/справа от полосы времени.

Теперь решим что делать с остальными кнопками в наборе 1-9:



Оставим почти все подсказки на виртуальной клавиатуре такие же как в плеере 3GP/MP4.

Кнопками "4" и "6" будем переключать по 1 кадру - и на этих кнопках нарисовано по одной стрелке.

Кнопками "1" и "3" будем переключать по 2 кадра сразу - и на этих кнопках нарисовано по две стрелки. Так можно сравнить первый с третьим кадром или второй с четвертым, не показывая другие кадры.

Ну тогда кнопками "7" и "9" будем переключать по три кадра - и на этих кнопках нарисовано по три стрелки, хотя перемотка на 3 кадра вперед - это то же самое что на 1 кадр назад, ну да ладно) И этими кнопками можно сравнить, например, первый кадр с последним.

Кнопки "2" (перемотка в начало) и "8" (перемотка в конец) оставим как есть. Пусть перематывают просмотр на первый и на последний кадр анимации.

Кнопку "5" (перемотка в середину) в этом окне уберем, т.к. перемещаться в середину 4-кадровой анимации никому не нужно. Пусть лучше кнопка "5" делает то же, что и кнопка джойстика - переключает скорость проигрывания по возрастанию c 0.5x до 2x. Тогда подсказка на ней будет - значок умножения. Получилась вот такая виртуальная клавиатура для окна ViewBMX:



Правый софт в окне ViewBMX назовем "В GIF"/"To GIF". BMX-анимации мало кто может сегодня смотреть) а вот GIF - это совсем другое дело. Работать правый софт будет только в 8-битном режиме, а в 24-битном будет серый и неактивный. Плеер по правому софту будет спрашивать путь и имя, рубить рисунок на 4 кадра и сохранять их во временные GIF-файлы кадров (в папку где анимация будет потом сохранена), потом собирать из них бесконечно зацикленную GIF-анимацию с задержками на кадрах, соответствующими текущей выбранной скорости в окне плеера, а потом удалять временные GIF-файлы кадров. И тогда можно будет любой старый BMX превратить в анимированный 4-кадровый GIF. А чтоб такой GIF из бывшего BMX было видно на экранах высоких разрешений - просто перед открытием плеера функцией "Размер растра" пропорционально увеличить загруженный BMX в нужное количество раз.

Сборка BMX-кадров в GIF теперь в "Плеере BMX" работает так:

1) в 8-битном режиме открываем BMX анимацию:



2) открываем плеер BMX в меню команд по "ДжойВправо" или просто жмем в главном окне "ДжойВлево" (в ч/б режиме это вызовет BMX-плеер, а в цветном - обмен цветов пц/зц):



3) в плеере выбираем нужную скорость, посмотрим как проигрывается по "#" и жмем "Правый софт" с подписью "В GIF":



4) показывается сообщение что надо выбрать папку, в которую будут складываться GIF-кадры (да и анимация в ней тоже будет сохранена):



5) в открывшемся окне файлового менеджера заходим, например, в новую пустую папку:



Жмем кнопку "Меню" или кнопку "..." под андроидом на виртуальной клавиатуре. В появившемся меню внизу экрана выбираем "В этой папке":



6) вводим название будущего файла с анимацией:



7) в стандартном окошке сборке GIF-анимации смотрим что задержки установились правильно. Но можно установить и любые свои (для каждого кадра отдельно или для всех кадров сразу):



8) после удачной сборки анимации читаем об этом сообщение:



9) теперь в бывшей пустой папке лежат и кадры анимации в GIF-файлах, и сама анимация:



Стирать кадры не будем, т.к. мало ли кому нужно будет их еще отредактировать и собрать другую анимацию или с другой скоростью.

Из сименсовского faceball.bmx получаются вот такие гиф-анимации:

1) в обычном разрешении со скоростью 1х (один кадр в секунду):



2) увеличен "Размером растра" в 10 раз, со скоростью 2х (два кадра в секунду):



Пункт "Плеер BMX" доступен в 8-битном режиме даже при цветном рисунке. И GIFы собираются со всей палитрой рисунка (без упора на чернобелые изображения). Можно сделать цветной BMX =)

1) Открываем в 8-битном режиме faceball.bmx:



2) рисуем поверх первого кадра какой-нибудь фон. Травку с небом:



3) жмем "ДжойВправо" - "Копия", это раскопирует первый кадр на все остальные:



4) получается в каждом кадре по фону:



5) отдельно зарисуем этот faceball цветами:



6) и вставим его "Спецвставкой" с прозрачным белым фоном поверх травки с небом:



7) по "ДжойВправо" - "Плеер BMX" смотрим как оно прыгает в цвете:



8) превращаем в плеере в GIF - получается цветной анимированный faceball:



9) еще можно отступить от квадратных размеров и от четких скоростей, выбираемых плеером из ряда "0.5 кадра в секунду, 1 кадр в секунду или 2 кадра в секунду". Натянем рисунок размером растра до неквадратных пропорций:



10) Посмотрим на него в плеере:



11) При сборке GIF укажем задержку для всех кадров, например, 750 мс (1.33333 кадра в секунду):



12) И получаем расплющенный гиф:



Проверим окно ViewBMX еще и на сименсе на мелком экране:



Слово "Кадр: X" справа внизу слишком прижато к правому краю. А прямоугольники, обозначающие кадры, прижались к правой стрелке. Исправим это и получаем:

1) открываем наш раскрашенный BMX, увеличиваем его "Размером растра" в два раза:



2) открываем плеер - теперь все ровно рисуется:



3) посмотрим по кнопке "0" переключение на полосу времени - тоже все ок:



Теперь окно BMX-плеера:
- масштабировано на большие разрешения экрана,
- расширено до обычного функционала других плееров (из съемки кадров из 3GP/MP4-видео под андроидом/явой),
- может проигрывать черно-белую BMX анимацию на разных скоростях и даже экспортировать ее в GIF-анимацию,
- также может в 8-битном режиме и цветные 4-кадровые BMX-анимации превращать в анимированные GIF-файлы.

[blackstrip]

И еще мелкие доработки.

Правим срезание текста в заголовке окна

В этом окошке из предыдущего поста в заголовке слишком длинный путь и он срезается справа. Но срезается слишком рано.



Отступим ровно 5 виртуальных пикселей справа (2 на выпуклую границу окна, 1 на зазор, 1 на синюю окантовку заголовка и еще 1 на зазор внутри заголовка окна). Получаем во всех окнах паинткада срез текста справа вот такой:



Рисование BMX-анимаций: показ меток, разделяющих кадры, в любом режиме и при любом типе рисунка

Под черно-белые анимации в 8-битном режиме сделан специальный "Тип рисунка" - BMX. В этом режиме на рисунке показываются разделяющие 4 кадра метки.

А если рисовать цветную BMX-анимацию, как в прошлом посте, то ни в 8-битном режиме, ни в 24-битном режиме никаких меток на рисунке видно не будет.

По логике надо бы в 8-битный режим добавить четвертый тип рисунка - цветной BMX. Но хотелось бы рисовать BMX анимации и в 24-битном режиме, там вообще один-единственный тип рисунка - это 16-миллионоцветный рисунок.

Тогда лучше сделаем настройку принудительного показа меток BMX-анимации в любом режиме и при любом типе рисунка. Поместим ее в меню настроек. Вот она:



Она сохраняется при выходе и загружается при следующем запуске паинткада. При ее выборе появляется стандартное окно сообщения с вопросом о переключении состояния этой настройки (с "выключено" на "включено" или наоборот):



И если она включена - то и на цветном рисунке, и в 8-битном, и в 24-битном режимах метки теперь видны:



А если выключена - то, как раньше, разделяющие кадры метки показываются только на черно-белом BMX рисунке в 8-битном режиме.

Рисование полноцветных BMX-анимаций в 24-битном режиме: копирование первого кадра на остальные функцией "Копия" и проигрывание анимации в BMX плеере

Раньше BMX-анимация считалась в паинткаде черно-белой и только для 8-битного режима. Раз уж теперь и в цвете она может быть, и даже в 24-битном режиме хотелось бы BMX рисовать, то разблокируем "серые" для 24-битного режима пункты "Копия" и "Плеер BMX" в меню команд (меню по "ДжойВправо" в главном окне рисования).



Допишем функцию "Копия" чтобы работала и в 24-битном режиме. Пусть и в 24-битном режиме можно будет раскопировать первый кадр BMX-анимации на остальные.

И теперь можно будет посмотреть в 24-битном режиме свою полноцветную анимацию в BMX-плеере. Но превращение в GIF в 24-битном режиме не будет работать (т.к. нет ни палитры, ни рисунка в индексированных цветах), эту функцию плеера на правом софте для 24-битного режима сделаем серой:



Можно сначала нарисовать полноцветную BMX анимацию в 24-битном режиме, полюбоваться на нее в BMX плеере, сохранить в файл. А потом уже, если нужен анимированный гиф из нее:
- перезапустить паинткад в 8-битном режиме,
- открыть ее из файла, подобрав нормальную палитру (UNI или "Гипер" в "Джой вправо" - "Подбор цвета" в главном окне, для UNI-палитры с Обычным приближением к цветам или зернистым Точным в "ДжойВправо" - "Адаптация" в главном окне),
- и уже скукоженный до 256 цветов рисунок BMX анимации посмотреть и так целиком, и в BMX плеере, и если все ок - сохранять в GIF через BMX плеер

Меняем название функции "Копия"

Она копирует первый кадр BMX-анимации во второй, третий и четвертый, чтобы сначала нарисовать фон в одном кадре, копировать его в остальные три, а потом уже дорисовывать меняющиеся в каждом кадре анимированные элементы. В английском варианте интерфейса она называется Frame-Copy - типа "раскопирование кадра на остальные". А в русском, почему-то, просто "Копия".

Переименуем ее хотя бы в "Копия кадра". Получаем в меню команд:



Английскую тоже переименуем. Из "Frame-Copy" превратим ее в "Frame copy":



Исправляем две иконки в мидлете

Как заметил один человек в телеграме, в манифесте JAR-архива есть два пункта с разными иконками:

Код: Выделить всё

MIDlet-Icon: /ikonka.png
MIDlet-1: PaintCAD, /iconka.png, paintcad.PaintCAD

Первый, видимо, для значка всего JAR-архива. А второй для первого и единственного мидлета в JAR (можно напихать много мидлетов в один JAR, тогда телефон при запуске будет спрашивать какой нужно запустить).

Один и тот же файл по содержимому, но с разным названием. В итоге обе иконки JBuilder добавлял в JAR-архив.

Поменяем их на одинаковую. Размер JAR файла уменьшился на размер одной иконки - около 1 килобайта.

Делаем индикатор для копии BMX кадра

Раньше BMX были маленькие (в одну смс влезала ровно одна 4-кадровая с каждым кадром 16х16 пикселей) и "Копия кадра" работала мгновенно.

Но если делать гигантский BMX и попросить паинткад раскопировать первый кадр на остальные функцией "Копия кадра", то весь экран станет черным пока не докопируется до конца и будет так висеть несколько секунд. Вынесем обработку "Копии кадра" в отдельный поток и будем оттуда дергать отрисовку индикатора прогресса. Теперь вместо черного экрана будет вот такое окно:



Проверяем высоту рисунка перед проведением Копии кадра

До этого "Копия кадра" работала на любых рисунках. Грубо рубила его на 4 части и из первой части забирала пиксели, запихивая их во вторую, третью и четвертую. И при некратной 4 пикселям высоте рисунка часть бралась чуть меньше четверти (т.к. четверть была дробная, например, 22 с половиной пикселя), и после копирования оставались пустые строки пикселей между кадрами.

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



Расширяем возможности Копии кадра

Покажем перед применением "Копии кадра" еще один вопрос с двумя вариантами ответа.

Если был рисунок, например, вот такой, размером 16х16 пикселей:



Паинткад теперь после вызова "Копии кадра" покажет окно с вопросом "Откуда брать исходный кадр":



Если выбрать "1/4 сверху" - то это как раньше, четвертую часть изображения копируем вниз. Получается скопированная четырежды верхняя четверть изображения высотой 4 пикселя:



Но можно выбрать и второй вариант:



Тогда весь рисунок считается первым кадром. Паинткад увеличит рисунок в 4 раза по высоте и раскопирует туда исходный кадр 16х16 пикселей (чтобы легче было превратить рисунок в 4-кадровую анимацию, дорисовав/изменив потом в каждом кадре что-то анимированное):



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



Метки кадров в главном окне при высоте BMX рисунка, не делящейся на 4 кадра

Плеер BMX при рисунке, не делящемся на 4 по высоте, ругается и не показывает анимацию. Это правильно.

Копия кадра тоже ругается сообщением и не хочет работать. Это тоже правильно.

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

Сейчас при рисунке, например, 14х14 пикселей метки смело рисуются, отделяя кадры разного размера:



Сделаем так, что метки-линии на рисунке рисоваться в этом случае не будут. А метки-точки на окантовке окрасятся вместо черного в неяркий красный:



Исправляем автовыбор базового диска по умолчанию для файлового менеджера в моторолах

Когда-то давно, когда еще в паинткаде не было настройки кодов клавиш, коды клавиш выбирались по модели телефона, а модель телефона по косвенным признакам (наличие определенных классов в API, наличие определенного текста в строчке платформы, отдаваемой телефоном и т.п.). И вот у моторол было аж 2 набора клавиш - старые моторолы управлялись, выдавая мидлету одни коды клавиш, а поновей моторолы - уже другие коды. И когда было ясно что моторолы бывают двух видов - то вместо единственной распознаваемой паинткадом модели "-=Motorola=-" было введено две модели в стартовом окошке выбора языка -=OLD Motorola=- (включается вручную в этом окошке по кнопке 7) и -=NEW Motorola=- (включается вручную кнопкой 2).

А процедура автовыбора базового для файлового менеджера при первом запуске паинткада (без настроек) по умолчанию пыталась выбрать диск b/ для обычной Motorola (которой вообще в паинткаде нет, вместо нее только OLD Motorola и NEW Motorola теперь). Поэтому моторолы оставались без базового диска. А при выходе вообще диск сбрасывался на первый попавшийся сименсовский a:, и при следующих запусках файловый менеджер всегда пытался влезть на a:, которого на моторолах, конечно, нет.

Теперь это поправлено. Для всех моторол выбирается базовый диск b/, ну и в "0" - "Настройки" - "Базовый диск" можно выбрать другой базовый диск, файловый менеджер сразу перескочит на него. А если потом еще выйти из паинткада по "0" - "Файл" - "Выход из проги", то ручной выбор базового диска сохранится, и при следующем запуске паинткада файловый менеджер сразу полезет на выбранный вручную базовый диск, а не на автовыбираемый для моторол b/.

[blackstrip]

Следующий модуль Wizard:



Окошко у него - мастер выбора начального действия при запуске паинткада (Создать, Открыть и т.д.). Без него пришлось бы в главном окне лезть в меню и вызывать разные пункты в разных подменю. А он сводит все эти пункты в одну линейку действий. Список действий для 8-битного и 24-битного режима отличается. А в режиме "Обработчик" мастер не показывается совсем.

Масштабируем окно Wizard

Сейчас окно выглядит так на мелком экране сименса. Стрелки и значок сдвинуты на 5 пикселей вверх от центра по вертикали. И с отступом в эти 5 пикселей расположен текст под значком:



И так на большом:



Так как по вертикали элемента всего два - то оставим зазор между значком и текстом 5 пикселей, превратив их в 5 виртуальных пикселей. Стрелки от краев окна тоже оттащим на 5 виртуальных пикселей вместо реальных. Получаем картинку с пропорциями и отступами примерно как на мелком экране сименса:



Вот и все масштабирование для окна стартового мастера Wizard.

Последний масштабируемый модуль - ZoomBrowser

Следующий модуль ZoomBrowser - и он последний модуль в очереди на масштабирование!



Это окошко показывается при вызове "ДжойВправо" - "Лупа" в главном окне рисования.

Масштабируем окошко ZoomBrowser

Окно на мелком экране сименса:



И на большом:



На обоих экранах стрелки, почему-то, лежат вплотную к панели подписей софт-клавиш. Отодвинем их вверх на пару виртуальных пикселей. И текст с текущим масштабом xN тоже.

Зато предпросмотр масштабированных пикселей (шахматная клетка посередине экрана) уже отодвинут на 3 виртуальных пикселя от левой и правой частей окна, т.к. мы сделали это раньше когда масштабировали предыдущие модули.

Еще можно доработать окно. Тут пустует клавиша джойстика. Подпишем ее словом "Экран" и будем по ней масштабировать рисунок так чтобы не было полос прокрутки (весь рисунок был на экране).

Еще не используются кнопки "ДжойВверх" и "ДжойВниз". Сделаем на них изменение масштаба в виртуальных пикселях. "ДжойВниз" уменьшает масштаб на 1 виртуальный пиксель (останавливается когда масштаб будет 1 виртуальный пиксель), "ДжойВверх" увеличивает масштаб на 1 виртуальный пиксель (останавливается когда масштаб будет максимальным количеством виртуальных пикселей, умещающихся в макс.масштаб х100).

А еще по "Звездочке" сделаем установку масштаба в минимальное количество виртуальных пикселей (т.е. 1 виртуальный пиксель), а по "Решетке" в максимальное количество виртуальных пикселей, умещающихся в х100.

Масштабы с х1 по х9 давно устанавливаются если нажимать кнопки "1"-"9".

Незанятую до сих пор кнопку "0" тогда сделаем устанавливающей масштаб х10.

Кстати, коды клавиш "0" - "9" обычно в яве соответствуют диапазону 48 - 57 ("0" это 48, "1" это 49, ..., "9" это 57). И в нескольких местах кода разных модулей это использовалось для быстрого определения нажатой клавиши. Но теперь в паинткаде есть настройка клавиш, и клавиши "0" - "9" могут и не иметь таких кодов, увеличивающихся подряд на единицу с 48 и выше. Поэтому поправим модули, где высчитывалась нажатая цифра по формуле (keyCode-48). Это модули BlurForce (одиночный слайдер), New File (указание размера по ширине и высоте), RGBForce (три слайдера для каналов R, G, B).

Теперь эти три модуля поправлены и даже если коды кнопок "0" - "9" перепутаны местами (например, пользователь специально назначил их так в настройке клавиш) или назначены на рандомные кнопки QWERTY-клавиатуры вразнобой с любыми кодами, все равно эти три модуля должны правильно понимать нажатые клавиши и выставлять положения слайдеров и принимать значения введенных ширины/высоты.

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



И когда масштаб не кратный виртуальному пикселю - то строчка масштаба в вирт.пикселях пропадает, а обычный масштаб центрируется в середине бывших двух строк:



Теперь можно устанавливать масштаб в виртуальных пикселях:
"*" - минимальный масштаб в виртуальных пикселях,
"#" - максимальный масштаб в виртуальных пикселях,
"ДжойВверх" - увеличить масштаб в виртуальных пикселях,
"ДжойВниз" - уменьшить масштаб в виртуальных пикселях.

И еще можно кнопкой "Джойстик" сразу автоматически выбрать масштаб чтобы подогнать текущий рисунок под экран, выводить его без полос прокрутки. Причем для каждого режима (Обычный, Расширенный, Полноэкранный, переключаемых в главном окне рисования по двойной "*" или по "ДжойВправо" - "Широкий экран") масштаб разный, т.к. выбирается исходя их доступного места на экране.

Проверим автомасштабирование рисунка на экран без прокрутки по нажатию на "Джойстик" в окне "Лупа" на неквадратной картинке. Например, загрузим лого сименс клуба, оно прямоугольное:



Жмем "ДжойВправо" - "Лупа" - "Экран" (кнопка джойстика) и масштаб устанавливается в х4 как самый крупный для отображения рисунка целиком на экране без прокрутки. Паинткад считает требуемый масштаб по обеим осям и выбирает такой масштаб чтобы и по горизонтали, и по вертикали изображение влезло в область рисования в главном окне в текущем режиме отображения (Обычный, Расширенный, Полноэкранный):



Попробуем поставим масштаб х5 - прокрутка появляется. Действительно, здесь х4 самый крупный для отображения всего рисунка без прокрутки:



Проверим еще окошко ZoomBrowser на j2me эмуляторе телефона Benq-Siemens EL71:

Окно "Лупа" с отображением масштаба в виртуальных пикселях:



Подбор масштаба для рисунка 32х32 чтобы отобразить его максимально увеличенным, но без прокрутки:



Все работает.

[blackstrip]

И еще мелкие правки

Альтернативный вариант выбора автомасштаба картинки

Сейчас будет много текста)

1. Виртуальные пиксели

Как уже писалось, виртуальные пиксели позволяют сэмулировать на смартфоне с гигантским разрешением типа 1000х2000 пикселей экран какого-то старого телефона с разрешением типа 128х128 точек или 132х176.

Для этого паинткад считает что шрифт, которым устройство пишет на экране, как будто, как в старом телефоне-сименсе вроде CX75. Тогда его высота, допустим, около 12 пикселей (в старом телефоне - реальных, а в телефоне с большим разрешением - виртуальных). Если поделить высоту шрифта андроида в пикселях на 12 - и получится размер виртуального пикселя.

На экранах высокого разрешения и высота шрифта в андроиде большая, например, 100 пикселей. Она выбирается так чтобы умещалось порядка 10 строк на экране по его меньшему значению из "ширины" и "высоты".

И тогда для высоты шрифта в 100 реальных пикселей размер виртуального пикселя будет 100/12 = 8,3333... = 8 реальных пикселей.

Если все строчки разложить на экране по смещениям в виртуальных пикселях - то они лягут точно там же, где ложились в старом телефоне на мелком разрешении.

И вот такое окошко на Xiaomi Redmi Turbo 3:



при виртуальном пикселе 9х9 реальных, на самом деле, для паинткада является примерно вот таким - каждая клетка "виртуальный пиксель":



И здесь этих клеток - всего-то 135х125. Такое разрешение для паинткада как будто бы имеет экран)

2. Что дальше

И вот, если ближе к делу, после расчета размера виртуального пикселя хорошо бы иметь возможность вообще любую графику в паинткаде сделать с пикселями не меньше этого виртуального пикселя. Ну чтоб визуально казалось что ты взял в руки старый телефон, и на экране самый маленький пиксель - виртуальный, меньше него ничего нет =) это как раньше на свежекупленном телефоне вглядывались в ЖК-экран, оценивая размеры пикселей

Но, во-первых, шрифты в андроиде векторные и у них будут элементы меньше виртуального пикселя всегда. Всякие там уголки, острия, скругления.

А, во-вторых, должна быть в паинткаде возможность выставить масштаб в 1 реальный пиксель чтобы смотреть картинку на экране с гигантским разрешением. Чтобы, например, при рисовании обоев для рабочего стола увидеть нарисованное в реальных пикселях в масштабе 1:1 на весь экран и оценить что ты нарисовал и что еще надо поправить.

3. Значит должны быть сразу оба варианта

Первый вариант - возможность смотреть на картинку и править ее в масштабе 1:1 с ооочень мелкими на глаз пикселями

Второй вариант - возможность смотреть на картинку и править ее, отрисованную в пикселях, кратных виртуальному пикселю. Чтобы почувствовать телефон с разрешением 135х125 пикселей из пункта 1.

Поэтому в окне "Лупа" теперь сразу оба этих варианта:
- обычное управление масштабом картинки ("ДжойВлево", "ДжойВправо"),
- установка масштаба в виртуальных пикселях:
а) по "ДжойВверх" / "ДжойВниз" выбирать масштабы, только кратные виртуальному пикселю.

Если виртуальный пиксель, к примеру, 4х4 реальных, то по "ДжойВверх" / "ДжойВниз" будет самый мелкий масштаб "х4", он же "ВП х1" (т.е. 4х4 реальных, они же - 1 виртуальный пиксель). Следующий (по "ДжойВверх") будет "х8", он же "ВП х2". Потом "х12", он же "ВП х3" и так далее,

б) по "*" и "#" можно выбрать минимальный и максимальный масштабы в ВП.

Т.к. в данный момент в окне "Лупа" максимальный масштаб х100, то все масштабы, кратные виртуальному пикселю, будут выбираться в диапазоне х1 - х100. А это для виртуального пикселя размером 4х4: х4 (ВП х1), х8 (ВП х2), х12 (ВП х3), х16 (ВП х4), ..., х92 (ВП х23), х96 (ВП х24), х100 (ВП х25). Поэтому минимальный масштаб будет х4 (ВП х1) по кнопке "*". А максимальный масштаб будет х100 (ВП х25) по кнопке "#".

Кстати, на старте паинткада масштаб картинки выставляется в 1 виртуальный пиксель. Поэтому в заголовке окна рисования сразу виден размер виртуального пикселя на телефоне - он равен масштабу, показываемому после надписи PaintCAD и номера версии:



4. Чего не хватает

В окне "Лупа" было добавлено масштабирование картинки на весь экран. Но оно масштабирует картинку, выбирая среди всех масштабов от х1 до х100.

Этой функции вполне хватит при обычном рисовании.

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

5. Функция "Попробуй сделать такой масштаб чтоб рисунок влезал в экран и показывался целиком без прокрутки. Но не показывай мне пикселей никаких других размеров кроме кратных размеру виртуального пикселя"

Разместим эту функцию в окне ZoomBrowser на свободной до сих пор кнопке "Снять трубку" ("Answer call").

Если в результате расчета получается масштаб меньше чем виртуальный пиксель - то пусть ставит масштаб равный виртуальному пикселю, даже если при этом не удалось сжать рисунок до размеров меньше экрана и прокрутка не пропала.

Получаем на устройстве Xiaomi Redmi Turbo 3 с виртуальным пикселем 9х9:

1) Была маленькая картинка 16х16 пикселей:



2) Окно "Лупа" по запросу "Экран" устанавливает масштаб х50 и показывает картинку на всю область картинки в главном окне:



3) Окно "Лупа" по запросу по кнопке "Снять трубку" устанавливает масштаб х45, кратный виртуальному пикселю 9х9:



В каждом пикселе картинки ровно 5 виртуальных пикселей 9х9:



Как будто на старом телефоне с малым разрешением экрана включили в паинткаде масштаб х5.

А с лого сименс-клуба из прошлого поста так:

1) Была достаточно крупная картинка - логотип "сименс-клуба" размером 252х120 пикселей:



2) Окно "Лупа" по запросу "Экран" устанавливает масштаб х4 и показывает картинку на всю область картинки в главном окне без прокрутки:



3) Окно "Лупа" по запросу по кнопке "Снять трубку" пытается найти масштаб кратный виртуальному пикселю х9 и чтобы картинка влезла в экран без прокрутки. Это ей не удается и она ставит самый ближайший минимальный возможный масштаб. Т.к. пикселей меньше виртуального 9х9 у нее быть не может - то она ставит масштаб х9. Прокрутка осталась. Зато пиксели не меньше виртуального и кратны ему как на старом телефоне:



Информация о виртуальном разрешении

Есть в паинткаде пункт в меню "Справка" - "Объем памяти":



Он показывает в простом сообщении объем свободной памяти и объем всей памяти:



Расширим его до пункта "Инфо о системе", где покажем все, включая информацию о памяти, информацию о разрешении и т.д.

Итак, первый экран "Система" получился такой:

Под андроидом там версия Android, версия API и информация о платформе:



В яве там MIDP, CLDC и информация о платформе:



Второй экран "Экран" - информация о доступной для вывода экране, и о его части, выделенной под окошки (GUI)? если полэкрана закрывает виртуальная клавиатура, то эта область меньше всего экрана.

Выводится цветность и размер экрана, сколько цветов и сколько уровней прозрачности (альфа-канала). В подразделе GUI показывается размер части экрана под окошки в пикселях и, если виртуальный пиксель больше чем один реальный пиксель, то размер GUI в виртуальных пикселях:



В яве тоже самое:



Третий экран "Память" - показывает в реальном времени весь хип явы, его занятую и доступную части. Раз в секунду обновляется. Можно еще нажать "Очистка" кнопкой джойстика или по ДжойВверх и вызвать garbage collector, удаляющий ненужные объекты в памяти и чистящий ее:



В яве аналогичный экран:



И последний, четвертый экран "Файлы" показывает какую файловую систему использует паинткад (JSR-75 или Siemens FS). Показывает список всех дисков. И для JSR-75 после каждого диска показывает отдельной строчкой пустое место на диске и другой отдельной строчкой весь объем диска. Старается показать размер в мегабайтах, но если возвращаемое явой/андроидом число больше 1000, то показывает в гигабайтах:



В яве такой же. Если дисков много, как в этой нокии (есть C:, E:, Память тлф:, Карта памяти:, вторые два полностью эквивалентны первым двум), то про каждый такая информация о свободном и полном месте:



На некоторых телефонах возвращаются странные числа пустого места и полного объема. Но паинткад их какими получил, такими и отображает =)

[blackstrip]

Правки и новые функции

Исправляем кривой расчет пустого места на дисках и полного объема дисков

Пришлось за последнее время так много написать плееров, где миллисекунды это секунды поделить на тысячу.

И вот пишем теперь мегабайты, гигабайты. Они, конечно, отличаются уже не в 1000, а в 1024 раза =) А сейчас вписаны именно 1000. Исправим это на 1024, а то паинткад показывает на дисках на 4 экране "Файлы" окошка "Инфо о системе" одни числа свободного места и полного объема, а файловые менеджеры в андроиде - чуть другие.

Проверим новое окошко Sysinfo (Инфо о системе) на разных андроидах и посмотрим его 4 экрана там выглядят

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

1 - Android 2.3.6 - Samsung Galaxy Ace

Тут, оказывается, андроид 2.3.6, а не 2.3.3 =)









Вот теперь, после правки делителя с 1000 на 1024 размер показывает на диске примерно то же, что Total Commander:



2 - Android 4.2.2 - RugGear RG310

А тут - андроид 4.2.2, а не 4.2.









3 - Android (Mocor) 4.4.4 - Joy's S15









4 - Android 5.0.1 - Asus ZenFone 2









5 - Android 7.0 - Fly FS522 Cirrus 14









6 - Android 9 - Soyes XS13









7 - Android 11 - Xiaomi Redmi Note 8 Pro









8 - Android 12 - Xiaomi Duoqin F22 Pro



На этом экране перенос мог бы пройти по символу подчеркивания, но он не был добавлен в список символов для переноса. Добавим его, получаем:



Остальные экраны:







9 - Android 16 - Xiaomi Redmi Turbo 3 (Poco F6)

Пока снимал скриншоты - на Redmi Turbo 3 пришло обновление андроида. Теперь это не 15 андроид, а 16.

Был до обновления первый экран информации о системе:



А после обновления стал:



Шрифт в заголовке окна стал какой-то худой. Сравним толстый и худой - отличаются теперь у Redmi Turbo 3 в 16 андроиде очень слабо:



Остальные экраны остались такими же:



На этом экране можно сравнить букву "н" из заголовка (она жирная, обратим ее чтобы стала черной) и из текста в окне (она обычная, нежирная) - различия жирного и нежирного шрифта теперь, в этом новом андроиде 16 (или в этом оформлении от xiaomi), почти минимальны:



У этой "н" в жирном варианте ширина символа остается точно такой же, как у нежирной, а вот линии внутри самой буквы слегка утолщаются)





10 - Java2ME - Nokia N90









11 - Java2ME - Nokia 7900 Prism









12 - Java2ME - МТС (Alcatel) 665

Этот телефон еще не участвовал в тестах. А он хороший - целых 6 мегабайт оперативной памяти в яве. Паинткад легко запускается и куча памяти остается незанятой)

Он с wi-fi подключением к интернету, и с qwerty-клавиатурой:



Его информация о системе:









13 - Java2ME - Эмулятор Siemens SL75









Эмулятор сообщает что диск у него мегабайт 15 где-то, а свободно 2 гигабайта)

14 - Java2ME - Эмулятор Benq-Siemens EL71









Этот эмулятор тоже врет о свободном месте, как и SL75.

В общем, все тестовые телефоны показывают окно Sysinfo с информацией о системе без сбоев и вылетов.

Делаем иные палитры

У PaintCAD Mobile одна палитра - это 256-цветная универсальная (или UNI) палитра. Она видна и в 8-битном режиме по умолчанию, и в 24-битном режиме.

А вот у PaintCAD 4Windows их много в окошке создания нового файла:



Перетащим все эти палитры в PaintCAD Mobile.

Когда у рисунка необычная палитра - тогда в 8-битном режиме к такому рисунку нельзя будет применять эффекты, но можно будет рисовать в этих специфичных для разных платформ цветах. А потом уже перевести рисунок в обычную или точную (зернистую) UNI-палитру и применить все что захочется.

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

Дорабатываем окно палитры (Palete) под разные палитры

Раньше в 24-битном режиме в окне палитры в режиме сетки цветов была только UNI-палитра. Теперь сделаем ее тоже изменяющейся.

А в 8-битном режиме она и так изменяющаяся. Так что почти ничего менять здесь не придется, просто класть в ячейки другие цвета.

Итак, открываем палитру:



По кнопке "0" в сетке палитры теперь вызывается смена палитры на другую:



Заголовок окна меняется на переключатель палитр с названием палитры, подписи софт-клавиш появляются без фона (как будто всё в подвешенном, несохраненном состоянии) и эти подписи совсем другие:
- "Назад" возвращает пользователя назад, не меняя палитру,
- "Выбор" - выставляет выбранную палитру в ячейки,
- "Внедрить" - эта фича из PaintCAD 4Windows, не только выставляет цвета в ячейки, но и весь текущий рисунок (и буфер, если он есть) перерисовывает в новых цветах, подбирая их из новой палитры взамен старых.

Переключателем выбираем по "ДжойВлево"/"ДжойВправо" палитру - и она сразу рисуется в ячейках. Но при этом можно, посмотрев разные палитры" нажать "Назад" (левый софт) и все вернется как было. Ну или выбрать "Текущая палитра" и нажать "Выбор" (по кнопке джойстика или по "ДжойВверх", или по "5") - тоже палитра не изменится.

Из PaintCAD 4Windows заберем другие палитры и составим из них список, из которого можно будет выбирать палитру:
- Текущая - это палитра, которая сейчас (если передумали менять) - на скрине выше текущая была UNI, так что она и рисуется,

- Пустая - палитра с 256 черными цветами, чтобы потом самому формировать цвета в ячейках:



- CGA 4 - четыре цвета из старых видеокарт:



- CGA 16 - 16 цветов из этих же видеокарт поновей:



- CGA NTSC 16 - 16 цветов при NTSC сигнале:



- C64 16 - 16 цветов из 8-битного домашнего компьютера Commodore 64:



- DOS VGA 16 - 16 цветов из досовского экранного режима (чтоб рисовать как в кубейсике при режиме SCREEN 12):



- ZX Spectrum 16 - 16 цветов из другого домашнего компьютера ZX Spectrum:



- DOS VGA 256 - это тоже в досе была смешная палитра по умолчанию в 256-цветных режимах (типа SCREEN 13 в кубейсике):



- UNI 256 - универсальная стандартная палитра, которая всегда была у новых рисунков в 8-битном режиме, чтобы все "вернуть взад" к привычной палитре если захочется):



- UNI 128 - укороченный вариант UNI-палитры, 128 цветов:



- UNI 64 - еще более короткий, 64 цвета:



- UNI 32 - еще вдвое меньшая, 32 цвета:



- UNI 16 - 16-цветная UNI, сколько тут синих и зеленых оттенков по сравнению с досовской или спектрумовской 16-цветной:



- UNI 8 - самая короткая, 8-цветная UNI:



Относительно стартового положения переключателя палитры "Текущая": "Джой Вправо" идет по палитрам экзотическим с разных систем и потом по UNI палитрам 256, 128, 64, 32, 16, 8 цветов.

А если сразу хочется перейти на UNI-палитру с текущей - то "Джой Влево" начнет переключать их в обратную сторону: Текущая, UNI 8, 16, 32, 64, 128, 256, и потом экзотические с разных систем.

Внедрение палитры в рисунок по правому софту

Если с функцией "Выбор" все ясно - копируем палитру в текущую и все. Ну в 8-битном перерисовываем рисунок и буфер по новой палитре.

То с "Внедрить" по правому софту все сложнее.

В PaintCAD 4Windows внедрение палитры работает только в 24-битном режиме. А потом уже рисунок, если хочется, можно перевести его в 256 цветов.

Его варианты там:
- выбрать цвет такой же точно с рисунка как в палитре или, если в палитре таких цветов нет, поставить на его место первый цвет из палитры ("нулевой" если считать их в диапазоне 0..255)
- подобрать из палитры один цвет, ближайший к исходному с рисунка
- подобрать смесь из двух, трех или четырех ближайших цветов, да еще и абсолютно (относительно нуля, т.е. черного цвета) или относительно исходного цвета



Оставим для PaintCAD Mobile единственный вариант внедрения палитры - по ближайшему цвету.

Проверка внедрения палитры в рисунок для некоторых из палитр

Оригинальная фотка эспандера в мелком разрешении 85 х 85 пикселей (чтобы посмотреть что делается с пикселями):



DOS VGA 16 цветов:



UNI-палитра 8 цветов:



UNI-палитра 64 цвета:



CGA-палитра 4 цвета:



Commodore 64 палитра 16 цветов:



DOS VGA 256 цветов:



Теперь в окне палитры в режиме сетки цветов можно по кнопке "0":

- выбрать одну из стандартных палитр и поставить ее вместо текущей, чтобы рисовать картинки в ее цветах. Тогда текущий рисунок перерисуется в соответствии с измененными цветами в ячейках палитры. А в 8-битном режиме еще и в буфер, т.к. у них обоих одна палитра, и если она меняется, то меняться должны оба - и рисунок, и буфер,

- внедрить палитру в рисунок. Тогда палитра сменится на новую, плюс к точкам рисунка (а в 8-битном режиме - и буфера тоже) будут подобраны цвета из новой палитры,

- внедрением в рисунок универальных палитр меньших размеров чем старая большая 256-цветная теперь можно сократить количество цветов на рисунке (но при этом оставить его более-менее полноцветным), чтобы, например, сохранить рисунок в небольшой GIF-файл или превратить картинку в малоцветную для какой-нибудь системы, отображающей малое количество цветов,

- а выбором палитр от ретро-систем типа MS-DOS или компьютеров ZX Spectrum или Commodore 64 - можно просто рисовать в их стандартных цветах, прикидывать и эскизно создавать графику для них

[blackstrip]

Расширяем работу с палитрами

Сохранение палитры в файл

Добавим в меню сохранения пункт сохранения палитры в файл PAL:



При его нажатии вылезает окно для ввода пути и имени файла как с другими файлами. Выбираем "Обзор", выбираем папку куда будем сохранять и жмем "В этой папке":



Дописываем имя файла и жмем "Ок":



Сохраняется файл длиной 768 байт - это 256 цветов по 3 байта (байт R, байт G, байт B).

Для теста сохранили палитру Commodore 64. В PaintCAD 4Windows такие же файлы палитры, проверим что там сохранилось. Откроем окно палитры в PaintCAD 4Windows - там пустые ячейки:



Жмем справа кнопку "Загрузить (Ctrl+O)" и загружаем наш файл pal, сохраненный в PaintCAD Mobile. Видим нашу сохраненную палитру:



Все работает. Теперь можно сохранить палитру в PAL-файл.

Загрузка палитры из файла

При загрузке надо загрузить палитру и дать возможность просто поставить ее в сетку либо поставить в сетку и внедрить в рисунок. Прямо как с выбираемыми стандартными палитрами по кнопке "0" в окошке палитры и описанными в предыдущем посте.

Добавляем в список форматов для открытия новый пункт "PAL", активный в обоих режимах (8-битном и 24-битном):



Вызываем его и указываем наш, сохраненный ранее, файл PAL с палитрой Commodore 64:



После загрузки сразу появляется окно палитры с диалогом смены палитры. По умолчанию включается пункт "Из файла", в нем видна загруженная палитра. Ее можно просто установить в сетку или установить + внедрить на рисунок:



Если захочется сравнить загруженную палитру с текущей - то кнопками "ДжойВлево" / "ДжойВправо" можно попереключать текущую палитру и палитру из файла, посмотреть что у той и у другой в ячейках цветов:



Теперь можно и загружать палитры из ранее сохраненных PAL-файлов и устанавливать их в палитру либо устанавливать и сразу внедрять на рисунок, как со стандартными ретро-палитрами.

Значок PAL файла в файловом менеджере

Для PAL файлов не было установлено никакого значка:



Поставим ему значок как у BMP файлов, на нем как раз нарисована какая-то палитра типа UNI:



Предпросмотр PAL файла в файловом менеджере

По кнопке "1" паинткад пытается загрузить PAL файл как картинку средствами телефона, это у него не выходит и он показывает большой красный крест:



Альтернативный предпросмотр сделан только для PCF-файлов - они открываются не средствами телефона, а паинткадом и показывается предпросмотр шрифта.

Сделаем еще один альтернативный предпросмотр - для PAL файлов. Пусть создается в памяти мелкий рисунок 16х16 пикселей, в который как в окно палитры укладываются пиксели цветов из PAL файла слева-направо сверху-вниз.

Получаем на этом телефоне по кнопке "1" показ картинки палитры 16х16 пикселей, окантованной рамкой толщиной с виртуальный пиксель (9 реальных пикселей):



Включаем по "*" масштабирование - и видим на экране крупную такую картинку палитры:



Теперь можно рассмотреть палитру из PAL файла перед загрузкой.

Проверка внедрения нестандартной палитры на рисунок из файла

1) Берем какую-нибудь картинку:



2) Открываем заранее заготовленный файл с нестандартной палитрой. Эта, например, сделана в 8-битном режиме из пустой палитры. Первый цвет - черный, а потом еще 4 - это RGB (50,0,0), (100,0,0), (150,0,0), (200,0,0) - красный с плавно повышающейся яркостью. После создания она была сохранена в PAL-файл.

Открываем его и видим палитру:



3) Жмем "Внедрить" и фото перерисовывается в красно-черных тонах:



Вот теперь можно сделать картинки с пикселями в любой палитре. Например, сделать набор графики для какой-нибудь малоцветной системы или для игры с определенной малоцветной палитрой.

[blackstrip]

Правки ошибок и новые функции:

Долгое удерживание клавиш Вверх/Вниз в окне файлового менеджера при предпросмотре

Если наложить в папку несколько PAL-файлов палитр и включить в файловом менеджере предпросмотр по "1" и масштабирование на весь экран по "*", то мелкая картинка палитры 16х16 долго будет масштабироваться в какую-нибудь 1000х1000 пикселей (полсекунды, например, а то и целую секунду). И когда нажимаешь ДжойВниз на виртуальной клавиатуре и держишь, то таймер повторения начинает отсчет и ломится при каждом срабатывании вызвать нажатие клавиши. При уже идущей перерисовке (или расчете масштабированной картинки) он должен не вызывать следующее нажатие клавиши, а он вызывал, т.к. не везде были проставлены флажки идущей перерисовки. И по одному нажатию показывался предпросмотр одной масштабированной палитры, потом еще одной, потом еще, хоть уже давно все клавиши отпущены)

Теперь, вроде бы, флажки идущей перерисовки поставлены в файловом менеджере везде. И одно нажатие ДжойВниз/Вверх или 2/8 теперь переключает строго один пункт в списке файлов и показывает только одну следующую картинку, даже если ее долго масштабировать. А долгое удерживание - ждет пока отмасштабируется картинка, и только потом показывает ее и переходит к следующей. Как только клавиша отпускается - больше никаких картинок помимо последней не рисуется и не переключается.

Пункт "Выбор" в окне палитры при вставке/внедрении слишком длинный

На правом софте слово "Внедрить". Это уже 8 букв. Еще и с отступом от края экрана.

На центральной клавише (джойстик) еще слово "Выбор" - это еще 2 с половиной буквы справа от центра. Итого в правой половине экрана 10 с половиной букв с отступом от края. Как будто 21 буква с двумя отступами на всю ширину экрана.

Большинство телефонов с узким экраном вмещали от силы букв 20. И правда - на узком экране сименса "Выбор" перекрывает "Внедрить":



Заменим "Выбор" на "Ок" - это почти тоже самое, но уже по ширине. Теперь надписи не перекрываются, хотя и то, кажется, близко расположены:



Новая функция - Внедрение гигантской палитры

В палитре всего 256 цветов. А хорошо бы иметь функцию, которая бы целиком цветовую гамму одного полноцветного рисунка переносила на второй.

Например, грузим в буфер опорную картинку, в ней какие-нибудь цвета типа старой желтой фотки (а ля сепия).

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

Назовем эту функцию "Цвета из буфера" / "Colors from CB" и положим ее в меню "Доп.эффекты".

Получилось вот такое:

1) Загружаем в буфер картинку, которая будет нашей гигантской палитрой. Эта фотка 300х300 пикселей - 90000 цветов если все пиксели разного цвета, или меньше цветов если есть одинаковые:



2) А на рисунок грузим картинку, в которую будем внедрять эту палитру. Эта фотка еще больше: 765х765 пикселей, т.е. 585225 пикселей в ней:



Вызываем в меню "Доп.эффекты" новую функцию "Цвета из буфера":



Функция для каждого из 585225 пикселей картинки пытается подобрать самый похожий на пиксель цвет из буфера (сканируя там все 300х300 = 90000 пикселей друг за другом). В итоге, чтобы провести подбор для всей фотки 765х765 пикселей - нужно будет проделать 585225 * 90000 = 52 670 250 000 сравнений. Это, конечно, не быстро)

Индикатор прогресса показывает 5-7 минут на Redmi Turbo 3 (наверху показывается какая строка пикселей из скольких всего строк картинки сейчас обрабатывается):



А если обе картинки взять 765х765, то выходит вообще полчаса, а то и 40 минут.

Поэтому именно для этого, иногда длительного, эффекта пришлось сделать на левом софте кнопку "Прервать/Break". Если ее нажать, то обработка прекратится.

Если дождаться до конца - видим вот такую картинку, желтый и красный поблекли, и теперь раскрашены в какие-то цвета из поверхности стола на фоне эспандера:



А если прервать посередине (на 25%, например), то часть картинки будет уже обработанная и блеклая, а часть еще в сочных цветах, туда обработка не успела дойти:



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

А если нажать ДжойВверх (Отменить), то картинка придет в первоначальное состояние до применения эффекта.

В 256-цветном режиме эффект тоже работает, но там легче и быстрее - он собирает с картинки-палитры все используемые цвета (их там от 1 до 256, не больше). А потом уже в поисках ближайшего цвета сканирует не рисунок-палитру в буфере, а просто используемые цвета в палитре, это гораздо быстрее.

Теперь можно "внедрить" в любой рисунок гигантскую палитру-рисунок, загрузив/положив ее в буфер и вызвав функцию "Эффекты" (кнопка "*") - "Доп.эффекты" - "Цвета из буфера". Только при больших картинках-палитрах в буфере это будет слишком долго считаться, но можно нажать "Прервать", потом ДжойВверх (Отменить), потом подкрутить картинку-палитру в буфере (например, уменьшить раза в 2 по ширине/высоте "Размером растра") и снова вызвать эффект "Цвета из буфера".

Например, если внедрить картинку-палитру шириной 256 пикселей и высотой 1 пиксель с градиентом от синего до ярко-зеленого из буфера в эту же фотку с желтой и красной консолями, то получится:



Что делать с PAL-файлами при открытии через "Открыть ???"

Уже сделали что в файловом менеджере PAL файлы в предпросмотре по кнопке "1" видны как картинки 16х16 пикселей. Сделаем чтобы и при открытии через "Открыть ???" открывалась такая картинка 16х16 пикселей со всеми цветами палитры. В 24-битном режиме цвета точно будут перенесены на рисунок. А в 8-битном будут приведены к UNI-палитре (если выбран "Подбор цвета" - "UNI-палитра") или собраны в 256-цветную палитру по порядку расположения (если выбран "Подбор цвета" - "Гипер-палитра").

Получилось:

1) Залезаем в "Открыть ???", ставим курсор на наш файл:



2) В предпросмотре по "1" палитра видна как картинка 16х16:



3) Жмем на файл, вводится путь и имя файла:



4) Жмем Ок и у нас на рисунок загрузилась палитра-картинка 16х16 с ее цветами:

[blackstrip]

Исправления:

Длительные процессы в новых андроидах

В старых андроидах при длительном подвисании программы выводилось системное окошко про то, что программа зависла. И была кнопка "Подождать".

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

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

Будем исправлять эти подвисания и выводить обработки из основного потока в дополнительные.

Подвисание окна правки цвета EditColor в 8-битном режиме

Когда в 8-битном режиме жмем в окне палитры в режиме сетки цветов левый софт с надписью "Правка" - то правим выделенный в сетке цвет в RGB-режиме. Это происходит в отдельном окне EditColor.

И если по результатам правки цвет ПЦ или цвет ЗЦ изменились, то весь рисунок перерисовывается новыми цветами (точнее старыми, но один из них изменился и стал новым). А если был еще и буфер заполнен чем-нибудь (скопированным рисунком, например) - то и он перерисовывается. Нужно вынести эти перерисовки в отдельный поток и отобразить на экране что идет процесс перерисовки рисунка и перерисовки буфера вместо обычного подвисания на оба этих действия.

Получилось в 8-битном режиме после правки цвета и нажатия правого софта:

Сначала перерисовывается рисунок, в это время окно не слушается клавиш, просто висит на экране, вместо подписей софт-клавиш надпись "В рисунок..." (запись изменений):



А потом, если был буфер, то появляется другая надпись "В буфер...":



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

Подвисание окна палитры Palete в 8-битном режиме

Аналогичная перерисовка произойдет если в 8-битном режиме в окне палитры по кнопке "0" перейти в режим смены палитры (или загрузить палитру из PAL-файла) и применить эту измененную палитру без внедрения (софт-клавишная подпись "Ок" посередине, нажимается джойстиком или кнопкой ДжойВверх, или кнопкой 5).

Сделаем чтобы при полной перерисовке рисунка из-за измененного цвета - отображались эти же индикаторы поверх окна.

Для перерисовки рисунка:



Для перерисовки буфера:



Подвисание главного окна при возврате из разных эффектов в 8-битном режиме

Есть в главном окне слабое место - некоторые эффекты/обработки, после того как они что-то поменяли на 8-битном рисунке, могут попросить главное окно "перерисовать полностью текущий рисунок по цветам палитры". И оно это делает прямо во время первой отрисовки окна на экране. Возвращаемся из эффекта/обработки в главное окно - и в андроиде все подвисает, черный экран, ждем секунду-две (если рисунок большой), потом появляется окно рисования. А если будет картинка 5000х5000, например, то новые андроиды вообще аварийно закроют паинткад, т.к. он слишком долго подвис на черном экране и не отвечает на внешние раздражители.

Исключаем из главного окошка вообще этот флажок с просьбой полной перерисовки рисунка по цветам палитры:

1) уберем все просьбы в главному окну о полной перерисовке рисунка по цветам палитры, вызывать будем перерисовку внутри эффектов/обработок под конец их применения, чтобы это все делалось в отдельном потоке (и паинткад не выглядел подвисшим для андроида), и плюс добавим индикаторы "В рисунок..." и/или "В буфер...",

2) и сотрем сам флажок и обработку "перерисовка рисунка во время отрисовки окошка на экране".

Эффект "UNI-палитра" - убираем подвисание при возврате в главное окно:

В этом эффекте полностью меняется палитра на UNI-палитру. Поэтому надо перерисовать с новыми цветами все - и рисунок, и, если есть, буфер обмена.

Утащим все эти перерисовки рисунка и буфера в код эффекта и отобразим на окошке текстом "В рисунок..." и "В буфер..." со 100% полосой прогресса, там это все идет в отдельном потоке и андроид не испугается что все зависло. А потом уже вернемся в главное окно, и там уже никаких подвисаний не будет, оно мгновенно будет в работоспособном состоянии.

Получилось в конце применения эффекта еще два шага:





По модулю открытия файлов (BMP, GIF, WBMP, ???) везде меняем отрисовку обновления рисунка и буфера для 8-битного режима. Теперь в конце открытия файлов появляется шаг "В рисунок..." или "В буфер...":



Чиним сохранение в GIF

В процессе тестов показа дополнительных шагов "В рисунок..."/"В буфер..." стало ясно что сохранение в обычный GIF почему-то не сохраняет GIFы, а начинает собирать анимацию)

Оказывается, вероятно, когда масштабировали и дорабатывали модуль ViewBMX до сборки анимированных 4-кадровых GIF из BMX, то сломалось сохранение и в GIF случайно. Теперь это исправлено. В GIF сохраняется как раньше =)

Подвисание в главном окне после перехода из окна выбора типа рисунка SelectType

Это окно при создании нового файла создает рисунок выбранного типа и для 8-битного режима перерисовывало его в главном окне. Переносим эту обработку внутрь окна SelectType в отдельный поток.

Еще это окно используется в 8-битном режиме при переключении Типа рисунка в меню "0" - "Настройки" - "Тип рисунка". Если переключили с цветного на ч/б рисунок или анимацию - оно превращает текущий рисунок в чернобелый. Если был буфер - оно тоже превращает его в чернобелый.

Назовем этот этап очернобеливания плюс установку палитры и начальных параметров как "Подготовка...".

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

Теперь окно делает сначала "Подготовку..." - параметры + очернобеливание если перешли с цвета на ч/б.
Потом оно перерисовывает рисунок как раньше, покажем это как внесение изменений "В рисунок...".
Потом, после правки ошибки, перерисовывает и буфер, покажем это как внесение изменений "В буфер...".

Получилось:







Подвисание главного окна рисования при отмене последнего действия по ДжойВверх

Когда идет отмена последнего действия - то она тоже подвисает в 8-битном режиме. Внутри нее обмен местами буферов отмены и картинки, и обмен палитры картинки с палитрой отмены, это идет быстро. А вот для 8-битного режима потом вызывается полная перерисовка рисунка - вытащим всю эту отмену целиком в отдельный поток, в нем покажем окошко с прогрессом, но прогресс сразу выставим на 100% и не будем рисовать от 0 до 100% в динамике (чтоб быстрее отмена шла, это часто используемая команда). Зато как окно с прогрессом пропало и появилось окно рисования - можно рисовать дальше (удобно если рисуешь очень большой рисунок, и отмена последнего действия с перерисовкой рисунка идет секунду, а то и несколько секунд).

Интересно, что палитра в процессе отмены последнего действия меняется на предыдущее состояние как и рисунок. Но буфер не перерисовывается) Это ошибка. Исправим это: сравним палитру рисунка и палитру буфера отмены. И если они разные - то значит при отмене последнего действия палитра изменится и тогда обязательно буфер обмена нужно перерисовать. А если одинаковые - то палитра не изменится и тогда перерисовывать буфер отмены не будем.

В 24-битном режиме никакие картинки и буферы не перерисовываются, поэтому там окошко с шагами "отмены последнего действия" показывать не будем. Там как раньше - нажали отмену и сразу рисунок поменялся на предыдущее состояние.

Получилось в 8-битном режиме при вызове отмены последнего действия по ДжойВверх в главном окне: