Я написал прогу для прочтения файлов dib - bmp, но некоторые картинки она рисует путём, а некоторые криво. В прямом смысле криво. Достаточно
кое - где поменять <(arg) на <=(arg) и те картинки которые криво рисовались начинают ещё кривее рисоваться, а те что нормально рисовались начинают рисоваться криво, но слегка. Если поменять < на <(arg-1) то тот же эффект, только в другую сторону. Т.е. кривые картинки никак прямо рисоваться не хотят. Или криво влево или криво вправо, а посередине никак

А вот ещё одно. В windows цветовые коды другие, нежели в dos'е и чтобы не зависеть от кодировок нужно цвета из палитры рисуемого bmp читать, а там эти хреновы цвета даны как интенсивности трёх составляющих - красного, синего и зелёного. А мне эти три составляющие нах не надо, мне результирующий цвет нужен, т.е. как - то надо эти три компоненты смешать, а вот как? Я думаю это делается на битовом уровне, поэтому придётся писать внешнюю asm - процедуру, вот и послал
этот вопрос в asm'овскую тему?

P.S. Заранее благодарю за любой ответ. Raven.

Что-то типа

Код

;Cl = 255 * 255 * R + 255 * G + B xor EAX, EAX mov AL, R shl EAX, 8 mov AL, G shl EAX, 8 mov AL, B ;Здесь в EAX - то что нужно. Вроде будет работать...

Или лучше:

Код

;Cl = 255 * 255 * R + 255 * G + B xor EAX, EAX mov AH, R mov AL, G shl EAX, 8 mov AL, B ;Здесь в EAX - то что нужно. Вроде будет работать...

Это сообщение отредактировал(а) acp - 8.6.2003, 19:15

Дык забыл сказать, цветов то 256 а в твоей формуле по ходу их никак 2^24 получается.

А разве это не стандартная формула? В винде цвет так по моему хранится. Только ещё один первый байт там есть... Всего - 4.
А если тебе надо меньше, то наверное придётся проводить выборку по всем этим цветам, что бы получить 256. Я не помню, как формируются эти 256 цветов...

Дело в том, что в bmp каждая строка дополняется битами до длины 32 бита. Если их не учитывать, изображение будет съезжать в бок. Скорее всего, те картинки, которые рисовались правильно, имели ширину строки, кратную 4 байта.

Цитата

Я думаю это делается на битовом уровне, поэтому придётся писать внешнюю asm - процедуру, вот и послал этот вопрос в asm'овскую тему?

ассемблер - не единственный язык, имеющий возможность оперировать с битами

Цитата

Дык забыл сказать, цветов то 256 а в твоей формуле по ходу их никак 2^24 получается

есть 24-разрадные bmp, где каждый пиксел задается 3 байтами, а есть bmp меньшей разрядности. Вот в них в начале файла пишется палитра. Каждый цвет в палитре - 24 разряда (или 32 - не помню). В палитре - не более 256 цветов.

Цитата(acp @ 8.6.2003, 22:15)

А если тебе надо меньше, то наверное придётся проводить выборку по всем этим цветам, что бы получить 256. Я не помню, как формируются эти 256 цветов...

А как её провести - то, эту выборку?
К тому же там палитра циклическая

Цитата(maxim1000 @ 9.6.2003, 06:55)

Дело в том, что в bmp каждая строка дополняется битами до длины 32 бита. Если их не учитывать, изображение будет съезжать в бок. Скорее всего, те картинки, которые рисовались правильно, имели ширину строки, кратную 4 байта.

Спасибо.

Для DOS (BMP 2,16,256 color):
Для каждой составляющей RGB палитры нужно проделать
операцию:
(для Pascal)
R := 63*R div 255
G := 63*G div 255
B := 63*B div 255
а потом вызвать процедуру setRGBpalette(i,R,G,B)
i - результирующий цвет.
(для Asma)
аналогичная процедура:
setRGBpalette proc near
mov ah,10h
mov al,10h
mov bx,i
mov ch,r
mov cl,g
mov dh,b
int 10h
ret
setRGBpalette endp

или лучше даже через macro (для старого MASMa under DOS)

setRGBpalette macro i,r,g,b
mov ah,10h
mov al,10h
mov bx,i
mov ch,r
mov cl,g
mov dh,b
int 10h
endm

БААААААААААААААААЛЬШОЕ спасибо!!!!!! А то я целый месяц хернёй страдал

Так это тебе помогло или нет?

а не учли что bmp еще и с RLE компрессией бывают?
я знаю ето
если 256 цветов то
768 байт палитра (3 байта на цвет) 6 бит в отличие от виндосовских 8 бит
тоесть будет 63 градации
если картинка 16 24 или 32 бита
то палитры как таковой нет
цвет точки определяется непосредственно 2 байтами если 16 бит
3 если 24-32 бита