Board.KolibriOS.org

Leency wrote:col_bg = DSDWORD[skin.image+24];

Это ты указатель на пиксели получил. А теперь сделай col_bg[0].

Нет, указатель это skin.image+24, а DSDWORD[skin.image+24] - это "данные по адресу".

А чем DSWORD отличается от DSDWORD?

Структура, грубо говоря, такая: Т.е. по адресу skin.image+4 лежит ширина изображения, а по адресу skin.image+24 лежит адрес, по которому лежат пиксели. Пиксели находятся не в самой структуре Image, они отдельно. В skin.image есть только указатель на ту область, и он находится в skin.image со смещением 24.

skin.image+24 -- это указатель на указатель

Ох шайтан. Спасибо, дома попробую.

Обнаружил в libimg несколько неприятных мелочей (не думаю, что их можно назвать багами).

1) Некоторые функции (scale, к примеру) вообще не сохраняют значения никаких регистров. Для ассемблера это нестрашно, а вот для ЯВУ проблема.

2) В документации к функции to_rgb говорится следующее: Но на самом деле функция возвращает буфер в несколько другом виде. В начало буфера сохраняются ширина и высота изображения (каждое 4 байта) и только после них начинается массив с rgb значениями. Документацию стоит подправить.

3) Функция scale масштабирует изображения даже тогда, когда масштабирование не требуется, так как в параметрах переданы исходные значения ширины и высоты. По крайней мере такое поведение наблюдается при использовании LIBIMG_SCALE_STRETCH и LIBIMG_INTER_BILINEAR, другие варианты я не тестировал.

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

4) Еще неплохо было бы указать в документации, что функция scale работает не со всеми форматами изображений, а только Image.bpp24 / Image.bpp32 / Image.bpp8g.

Подтверждаю, там много не доделанного.

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

anyone has used libimg with high-level lenguge like visual c++? I not found any example about how use it. Maybe dont work with hll. I try to use it with oberon-07, and when call to decode image my program crash with general memory protection fault.

ddarias
I use with C--, it should work with any language.

http://websvn.kolibrios.org/filedetails ... bimg_lib.h
and more here http://websvn.kolibrios.org/listing.php ... 6dfa56425a

The need has risen to draw images with the correct transparency.
Is it planned to make a function "img.to_argb" and/or a function to draw an image into a 24bpp or 32bpp canvas?

img.to_argb will be implemented as img.convert with proper flags.

Transparency requires significantly more work.
Currently libimg uses f65 to output images which doesn't support neither alpha nor canvas.
Experimental f73 is said in docs to support transparency, but actually it doesn't.

If you have ideas for transparency API to satisfy your busyness need, they are very helpful.

What I mean with canvas is an off-screen buffer.
Currently, I'm using img.decode, then img.to_rgb and then I manually blit it to the correct place in the offscreen buffer.
This all works great as long as there no transparency involved, because I cannot know what 24bit value represents the magic transparent color.
(As used in transparent GIF's for example).

Look at the buf2d library for the offscreen buffer with transparency support.

Ray wrote:Look at the buf2d library for the offscreen buffer with transparency support.

The problem is not in the offscreen buffer routine, I'm missing information about the image.

hidnplayr wrote:

Ray wrote:Look at the buf2d library for the offscreen buffer with transparency support.

The problem is not in the offscreen buffer routine, I'm missing information about the image.

That makes sense.

Сегодня впервые в эмуляторе колибри был создан *.png файл размером 72*72 пикселя!
Для кодирования использована zlib.obj, которую я планирую объединить с системной archiver.obj.
Код пока что экспериментальный, создаются файлы размером не более 16 Кб (это связано с тем что кодирование в deflate должно делаться в цикле порциями не больше 16 Кб, а я для простоты кода в один вызов сделал).
Потому ни на svn ни на форум давать его наверное не буду.
Если удастся довести до рабочего состояния то можно будет включить его в libimg.