Функции рисования 2d графики (библиотеки vectors и buf2d)

Discussing libraries simplifying applications development
  • Исходники vectors.obj есть на SVN? Актуальны они или нет, может уже перекочевали в buf2d?
    Из хаоса в космос
  • Leency wrote:Исходники vectors.obj есть на SVN? Актуальны они или нет, может уже перекочевали в buf2d?
    Исходников vectors.obj на SVN нет. Часть кода из vectors.obj перешла в buf2d.obj.
    Актуальны они или нет вопрос сложный, потому что в них есть возможность вывода масштабируемых полигонов, чего нет в buf2d. Перекидывать эти функции в buf2d я не стал по той причине что хотел упростить формат для хранения полигонов.
    Думаю что название этой темы можно поменять на Функции для рисования 2d графики (библиотеки vectors и buf2d) , только я как простой пользователь не могу менять название тем.
  • На самом деле можешь, хоть это и не совсем очевидная функция, - для этого нужно отредактировать заголовок первого сообщения в теме.
    Из хаоса в космос
  • Теперь функции дизеринга добавлены в buf2d, поэтому напишу здесь.
    Я здесь viewtopic.php?f=32&t=2187&p=44785#p44810 писал, что иногда "тот фильтр вылетает".
    Spoiler:Возьмём, например, dither_4.
    Вызов происходит из buf_filter_dither:

    Code: Select all

    proc buf_filter_dither, buffer:dword, algor:dword
    ; ...............................................
    ;edi - pointer to 24bit bitmap
    ;edx - x size
    ;esi - y size
    lea   edx,[edx+edx*2]
    imul  esi,edx
    ; ...............................................
    call dither_4
    Цикл ниже будет выполняться столько раз, сколько байтов содержится в bitmap.

    Code: Select all

    dither_4:                       ; Atkinson algorithm
    newp_4:                         ; Dithering cycle
    ; ...............................................
     .next:
        inc   edi
        dec   esi
        jnz   newp_4
    
    В некоторый момент произойдёт обращение к памяти за пределами буфера bitmap:

    Code: Select all

      .ok:
        mov   [edi+3],al             ; putpixel
     
        movzx eax,byte[edi+edx]      ; pixel (x;y+1)
    ; ..........................................
      .ok1:
        mov   [edi+edx],al           ; putpixel
     
        movzx eax,byte[edi+6]        ; pixel (x+2;y)
    ; ..........................................
      .ok2:
        mov   [edi+6],al             ; putpixel
     
        movzx eax,byte[edi+edx-3]    ; pixel (x-1;y+1)
    ; ..........................................
      .ok3:
        mov   [edi+edx-3],al         ; putpixel
     
        movzx eax,byte[edi+edx+3]    ; pixel (x+1;y+1)
    ; ..........................................
      .ok4:
        mov   [edi+edx+3],al         ; putpixel
     
     
        movzx eax,byte[edi+edx+edx]    ; pixel (x;y+2)
    ; ..........................................
      .ok5:
        mov   [edi+edx+edx],al         ; putpixel
  • Хм, похоже на правду - как-то не сталкивался с падениями, потому не задумывался, как доберусь - поковыряюсь.
  • Как-то не могу придумать годного решения проблемы обращения к памяти за пределами буфера, кроме как вручную резервировать после буфера область, равную 2 строкам изображения. Может у кого лучше идеи есть?
  • Heavyiron
    А из-за чего возникает обращение за пределы буфера ?
  • Serge, обработка изображения идет попиксельно, а погрешность распределяется на соседние пиксели, расположенные в том числе и в нижних строках. В начале изображения и до предпредпоследней строки - все ок, но дальше алгоритм начинает писать в область за пределами последних пикселей. 0CodErr 2 постами выше привел пример в коде. Мутить проверку не находится ли пиксель в последних строках не хочется - думаю, это заметно замедлит код.
  • Лучше всего выделить дополнительные строки.
  • Serge wrote:Лучше всего выделить дополнительные строки.
    Для заранее неизвестного размера изображения придётся делать это динамически, что также может замедлить код.
    Есть ещё такой вариант: применять фильтр не ко всему изображению, то есть начинать не с точки (0; 0), а с точки (1; 1) и заканчивать точкой (Width-2; Height-2), а не точкой (Width-1; Height-1). Мы не так много потеряем в качестве из-за каких-то двух строк.
  • 0CodErr, в качестве будет незаметно, но изображение уже не будет 8-ми цветным, если какие-то пиксели не обработаны. Разве что цвета округлять, а ошибку не распределять для последних строк. Но тут опять впадаю в ступор по реализации этого дела
  • Для заранее неизвестного размера изображения придётся делать это динамически, что также может замедлить код.
    В смысле заранее неизвестного ? Там буфер фиксированного размера и если картинка больше, то всё, облом ?
  • Serge, там передаются в качестве параметров размеры и указатель на изображение(источник и он же приёмник). Не получится просто так «прилепить» туда дополнительный кусок памяти.
  • 0CodErr wrote:Есть ещё такой вариант: применять фильтр не ко всему изображению, то есть начинать не с точки (0; 0), а с точки (1; 1) и заканчивать точкой (Width-2; Height-2), а не точкой (Width-1; Height-1). Мы не так много потеряем в качестве из-за каких-то двух строк.
    Думаю можно на время работы функции поменять размер изображения (саму память для изображения не менять), а после окончания работы вернуть прежние размеры изображению.
    0CodErr wrote:Не получится просто так «прилепить» туда дополнительный кусок памяти.
    Функция buf2d_resize меняет размер изображения, также добавляя или убирая память выделенную под изображение.
  • Who is online

    Users browsing this forum: No registered users and 6 guests