Помогите новичку

Applications development, KoOS API questions
  • Эмуляторы обычно поддерживают 640*480, 800*600, 1024*768. Другие режимы как повезет.
    Есть альтернативное решение. я не так давно сделал функцию и программу - Ограничение размеров отображаемой части экрана
    Так что можно задать любые произвольные (в разумных пределах) размеры, которые меньше текущего видеорежима.
    В последних ночных сборках нужно только поправить AUTORUN.DAT, убрав # и указав нужные размеры для:

    Code: Select all

    #/RD/1/CROPFLAT "XS800 YS480"      1    # set limits of screen
  • 0CodErr
    Подобная прога очень пригодилась бы до выпуска дистра, искренне желаю удачи. ещё бы самые простые эффекты, типа сепия, оттенки серого и т.д.
    Из хаоса в космос
  • В qemu с драйвером vmware можно кучу разных разрешений выбрать. Если все фильтры однообразные - почему бы не сделать из них классическую библиотеку Колибри? После этого программа, которая хочет использовать фильтры, сможет просто взять листинг директории, и для всех obj-файлов нужных плагинов получить таблицы экспорта и работать как положено :)
  • 0CodErr wrote:Насколько я понял, libimg может декодировать bmp, jpg, png, gif, ico, pcx, tiff, wbmp, pnm, xcf.
    Ещё tga и z80 (хотя последний для меня самого загадка).
    0CodErr wrote:Проверить возможность декодирования можно с помощью "img_is_img".
    Уже не нужно. Сразу вызываешь img.decode, и она, если может, декодирует и возвращает указатель на структуру Image (см. libimg.inc) или ноль. Глянь в пример по ссылке из моего предыдущего поста:

    Code: Select all

            invoke  img.decode, [img_data], [img_data_len], 0
            or      eax, eax
            jz      exit
            mov     [image], eax
    Т.е. первый вызов libimg -- это сразу img.decode.
    img.is вызывается из img.decode и руками это делать не нужно.
    0CodErr wrote:"img_decode" возвращает указатель на структуру Image, из которой можно узнать размеры изображения.
    Да. Не забудь освободить память от загруженного и уже декодированного файла.
    0CodErr wrote:"img_to_rgb" преобразует исходное изображение в массив RGB.
    Да. to_rgb сама выделяет память под выходное изображение, to_rgb2 принимает указатель на уже выделенную память вторым аргументом _out.
    0CodErr wrote:То есть, сначала нужно прочитать файл в буфер.
    Нужно.
    0CodErr wrote:Проверить поддерживается ли такой формат файла.
    Не нужно.
    0CodErr wrote:После этого декодировать и преобразовать в RGB.
    Теперь преобразованное изображение можно вывести на экран.
    Правильно. Обрати внимание, что для вывода используется функция img.draw, а не функция ядра.
    0CodErr wrote:"img_encode" пока ничего не кодирует. То есть, сохранять изображение придётся самому.
    Пока так.
    0CodErr wrote:"img_draw" только выводит изображение. А планируется ли добавить функцию(-ии) масштабирования?
    Я не планирую добавлять функции масштабирования в libimg. С другой стороны, есть scale.obj. С ней я совсем не знаком; думаю, автор отпишется, в каком она состоянии и как с ней работать.
    0CodErr wrote:Я начал делать программу с расчётом на то, чтобы в дальнейшем фильтры загружались из файлов.
    Но как сделать это лучше - я пока не знаю. Возможно, стоит сделать библиотеку фильтров.
    Библиотека будет, на мой взгляд, лучшим вариантом. Для этого, правда, нужно сделать код более универсальным. Например, научить его работать с разными форматами данных (имею в виду 8bpp/16bpp/24bpp/32bpp).

    Библиотека -- это не сложно. Для начала вынеси функции фильтров в отдельный .asm файл, чтобы логически их отделить от кода самой программы. По сути, эти функции ничего не должны знать об остальной программе, их работа должна полностью определяться входными параметрами. Если для разных фильтров количество параметров разное, передавай указатель на структуру с этими параметрами.

    Кстати, для интерфейса у нас есть печеньки box_lib. Там, вроде, даже документация есть. А уж примеров на svn просто куча.

    Я тебя тут загрузил :roll:
    Делай последовательно что задумал -- и всё получится.
    Тому, кто что-то делает, тут охотно помогают.
  • Dunkaist, спасибо за замечательный ответ. Так и хочется добавить его в избранное и плюсануть в карму. Побольше бы таких постов на форуме, как твой, и поменьше бы таких, как мой. Тебе бы документацию писать.

    0CodErr, можно экспортировать изображение в формат bmp или pnm, а затем конвертировать в jpg или png с помощью конверторов, которые я перенес в Колибри. В идеале, конечно, хотелось бы заняться img_encode в libimg, но я, увы, такую ответственность на себя взять не могу. Я еще шрифты не доделал, за что мне ужасно стыдно.
  • А за браузер и Qemu? :wink:
  • SoUrcerer, мне бы экзамены сдавать).

    По поводу img.encode напишу в теме libimg. Документация в процессе, но ещё не на подходе.
  • За qemu уже менее стыдно, потому что linux запустить в Колибри можно.
    За браузер тоже менее стыдно, потому что активно интересующиеся с широким инет-каналом могут опробовать идею просмотра инета через прокси, а менее активно интересующиеся могут лазить по инету через веб-браузер на lua. Хотя он ничем не лучше HTMLv.
  • dunkaist wrote:Ещё tga и z80 (хотя последний для меня самого загадка).
    Последний правильнее было бы назвать scr - от слова screen. Это файл, представляющий слепок видеопамяти компьютера ZX Spectrum (1 и 2). Изображения в таком формате практически не встречаются, за исключением сайтов соответствующей тематики (например, 1). История появления формата в Колибри - программы e80 и ScrV.
  • Mario wrote:Есть альтернативное решение. я не так давно сделал функцию и программу - Ограничение размеров отображаемой части экрана
    Но ведь это не изменит реальное разрешение?
    Leency wrote: ... ещё бы самые простые эффекты, типа сепия, оттенки серого и т.д.
    Да, это можно добавить. Оттенки серого - так вообще просто.
    SoUrcerer wrote: ... почему бы не сделать из них классическую библиотеку Колибри? После этого программа, которая хочет использовать фильтры, сможет просто взять листинг директории, и для всех obj-файлов нужных плагинов получить таблицы экспорта и работать как положено
    Была похожая идея. Только один obj-файл, содержащий версию библиотеки и сами фильтры. Тогда количество фильтров в библиотеке — это количество структур в таблице экспорта минус один. Или даже без версии.
    Но как быть с тем, что для некоторых фильтров существует куча алгоритмов реализации? У них у всех есть свои плюсы и минусы, поэтому желательно иметь возможность их одновременного использования(без замены библиотеки, например).

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

    Вариант с несколькими файлами подойдёт в случае, если кроме фильтров будут ещё какие-либо дополнительные компоненты программы. Тогда директория с плагинами могла бы содержать "filters.obj", "ещё что-то.obj", ... и т.д. Количество плагинов — это число всех файлов в этой директории.

    Я тоже считаю, что лучше делать именно классическую библиотеку Колибри, потому что с такими библиотеками работать(и разрабатывать их) уже более-менее привычно.
    dunkaist wrote: Библиотека будет, на мой взгляд, лучшим вариантом. Для этого, правда, нужно сделать код более универсальным. Например, научить его работать с разными форматами данных (имею в виду 8bpp/16bpp/24bpp/32bpp).
    Но ведь libimg может всё это перевести в RGB? А фильтры будут работать уже с этим RGB.

    dunkaist, спасибо за содержательный ответ!
  • 0CodErr wrote:
    Mario wrote:Есть альтернативное решение. я не так давно сделал функцию и программу - Ограничение размеров отображаемой части экрана
    Но ведь это не изменит реальное разрешение?
    Зато позволит проверить корректность работы программы при разных разрешениях. Впрочем дело хозяйское - я предложил один из вариантов.
  • 0CodErr, насчёт переменного количества параметров. Как я писал выше, можно передавать только указатель на структуру параметров, а длина и содержание этой структуры уже будет зависеть от конкретного фильтра. В первый dword структуры можно записывать её длину, чтобы не было путаницы.
    0CodErr wrote:Да, это можно добавить. Оттенки серого - так вообще просто.
    Там ведь тоже куб RGB на отрезок grayscale разными способами отобразить можно. Взять тот же гимповский colors/desaturate. Было бы желание, а работа найдётся).
    0CodErr wrote:Но ведь libimg может всё это перевести в RGB? А фильтры будут работать уже с этим RGB.
    Можно, конечно, но ведь не рационально делать преобразование 8bpp->24bpp, потом применять фильтр к трём каналам и делать обратное преобразование. Можно ведь в таком случае обойтись применением фильтра к единственному исходному каналу.
  • Spoiler:FFFFFFUUUUUUUUUUUUUUUUUUUUUUU
    Написал код на асме, руководствуясь интернетами, но из-за того что асмов много и руки у мя неочень он не работает. Почему?

    Code: Select all

    	mcall 48, 4 ;get skin width
    	sub eax, 7; отнимаем 7
    	div eax, 2 ;делим на 2
    	mov [skin_h], eax ;перемещаем значение в переменную
    	
    	outcount dword [scoreb],300,skin_h,cl_Blue,5*65536
    
    	skin_h dd 25
    
    Что он должен делать: он должен выводить строку текста посередине заголовка окна.
    Из хаоса в космос
  • Проблема в div, эта команда имеет сложную структуру.
    При вызове div eax, 2 ты делишь edx:eax на 2 и записываешь результат в eax, если я не ошибаюсь. Следовательно, если у тебя edx не равен 0, ты получишь число куда большее, чем ожидал.
  • Who is online

    Users browsing this forum: No registered users and 29 guests