ревизия 2815 добавлена еще одна воксельная функция и 2 примера. Внешний вид примеров под спойлером.
Функции рисования 2d графики (библиотеки vectors и buf2d)
-
ревизия 2759 добавлены функции для рисования воксельных объектов (создаваемых в воксельном редакторе)
ревизия 2815 добавлена еще одна воксельная функция и 2 примера. Внешний вид примеров под спойлером.
Исходники vectors.obj есть на SVN? Актуальны они или нет, может уже перекочевали в buf2d?
Из хаоса в космос
Исходников vectors.obj на SVN нет. Часть кода из vectors.obj перешла в buf2d.obj.Leency wrote:Исходники vectors.obj есть на SVN? Актуальны они или нет, может уже перекочевали в buf2d?
Актуальны они или нет вопрос сложный, потому что в них есть возможность вывода масштабируемых полигонов, чего нет в buf2d. Перекидывать эти функции в buf2d я не стал по той причине что хотел упростить формат для хранения полигонов.
Думаю что название этой темы можно поменять на Функции для рисования 2d графики (библиотеки vectors и buf2d) , только я как простой пользователь не могу менять название тем.
На самом деле можешь, хоть это и не совсем очевидная функция, - для этого нужно отредактировать заголовок первого сообщения в теме.
Из хаоса в космос
Теперь функции дизеринга добавлены в buf2d, поэтому напишу здесь.
Я здесь viewtopic.php?f=32&t=2187&p=44785#p44810 писал, что иногда "тот фильтр вылетает".
Вызов происходит из buf_filter_dither:
Цикл ниже будет выполняться столько раз, сколько байтов содержится в bitmap.
В некоторый момент произойдёт обращение к памяти за пределами буфера bitmap:
Я здесь 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
Code: Select all
dither_4: ; Atkinson algorithm
newp_4: ; Dithering cycle
; ...............................................
.next:
inc edi
dec esi
jnz newp_4
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). Мы не так много потеряем в качестве из-за каких-то двух строк.
Функция buf2d_resize меняет размер изображения, также добавляя или убирая память выделенную под изображение.0CodErr wrote:Не получится просто так «прилепить» туда дополнительный кусок памяти.
Who is online
Users browsing this forum: No registered users and 7 guests