61 = ПРЯМОЙ ДОСТУП К ГРАФИКЕ

Wed Aug 10, 2005 6:37 am

Кто работал напрямую с видео памятью? ПЛЗ покажите в какой программе реализованна эта ф-я. а то в огоньках и в других граф. приложениях всё это делается с 7ой ф-ей.

Wed Aug 10, 2005 1:06 pm

ДА, а заодно как :
-скопировать часть изображения (например часть формы) в буфер
-как сделать вывод в буфер (например написать текст в буфере а не наэкране)?

Меня интересует реализация скроллинга изображения в выделенной области в частности!

Wed Aug 10, 2005 10:01 pm

DoomEd Archangel
Есть функция 61, но я с ней не разбирался.

FreGL
1) Расписывай подробней, а то нихрена непонятно.
2) Ты про это уже спрашивал, и тебе сказали, что штатных средств в системе для этого нет. Могу предложить метод, реализации, раз ты сам не ничего не можешь придумать. Ты должен иметь файл со шрифтами, в принципе шрифт в МеОС это набор двухцветных спрайтов, которые выводятся методом наложения через AND или OR, час уже точно не помню. Так вот накладываешь по кускам спрайты букв в нужное место буфера, поверх изображения и потом выводишь буфер на экран. Ничего особо сложного в процедуре нет.
3) Скроллинг изображения в буфере делается тоже просто. Размер буфера должен быть больше размера выводимого окошка. А ты просто изменяешь координаты этого самого окошка в буфере при передаче вывода на экран. И все. Телемаркет!

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

Thu Aug 11, 2005 11:05 am

т.к. видимо никто ещё не касался этой темы, был сделан научный тык в ф-ю 61.
Для не сведующих в этом деле (как я) вот пример.

Code: Select all

include 'macros.inc'
;application start

; for 800x600x32

; 1st byte is blue
; 2nd byte is green
; 3rd byte is red

; example:
; mov [gs:offset],0x00
; [offset] is an offset from the beginning of the screen
; for 800x600x32 the maximal offset (right low corner of the screen)
; is <1 920 000> = 800(pix)*600(pix)*4(bytes)


meos_app_start

code

        mov [offset],0 ;320400
        mov esi,[offset]
        jmp aaa111
graphics_test:
        inc esi
        aaa111:
        mov dword [gs:esi],0x00  ;blue

        inc esi
        mov dword [gs:esi],0x00  ;green

        inc esi
        mov dword [gs:esi],0xff   ;red

        inc esi
                ;other

        cmp esi, 1920000;1860000 ;[offset], 1860000
        jb graphics_test

        mov eax,61
        int 0x40


        mov eax,5  ;delay
        mov ebx,400   ;4 sec
        int 0x40

        mov eax,61
        int 0x40


mov eax,-1
int 0x40


still:
mov eax,10
int 0x40
cmp eax,2
je key
jmp still

key:
mov eax,2
int 0x40
jmp still

offset dd 0
;;;;;;;;;;;;;;;;;;
;;;;;;;DATA;;;;;;;
;;;;;;;;;;;;;;;;;;
data
;;;;;;;;;;;;;;;;;;
;;;;;;UDATA;;;;;;;
;;;;;;;;;;;;;;;;;;
udata
;application end
meos_app_end

кто разбирается в этом -
почему возможно записывать только побайтно? зачем нужен 4-ый байт в 32х битном цвете? почему цвета располагаются не по установленному порядку?

Thu Aug 11, 2005 1:11 pm

и ещё
не совсем понял что выдала мне ф-я 61 при ebx=1 при разрешении 1024х768х32
вобщем в переменных было:
scr_x = 2097920
scr_y = 50332672

Thu Aug 11, 2005 3:09 pm

хех .. есть же 14 ф-я...
я почти победил эту 61-ю... завтра если получится попробую вывести изображение...
вообще весч прикольная, одно достаёт - каждый байт записывать отдельно.. двордами удобнее было бы, и быстрее..
кстати, если выводить рисунок напрямую в память, это будет быстрее чем вывод через putimage??? учитывая что надо будет побайтно брать цвет и прописывать в память...

Fri Aug 12, 2005 10:12 am

Надо учитывать, что система может работать не только с разным разрешением экрана, но и с разным количеством бит на пиксел (32, 24; [крутые режимы] 8 и 4; [с моим драйвером] 16 и 15). Ты же не хочешь заставлять пользователя устанавливать нужный тебе видеорежим? К тому же, нужный режим может быть недоступен пользователю (не поддерживается). Не думаю, что вручную писать в видеопамять будет быстрее. В моём драйвере используется оптимизация под каждый битовый режим.
Удачи.

Fri Aug 12, 2005 12:07 pm

mike.dld
да, я знаю на счёт битовых режимов. я пока проверяю только на 32х битном цвете.
на счёт скорости - есть ли возможность ускорить запись\чтение? а с драйвером?
ведь надо что нибудь придумать на счёт "мерцания" при прокрутке, быстром наборе, и тд ..???

картинка выводится, и даже с прозрачным фоном (я с видео памятью до этого никогда не работал, так что для меня это щас так дико

.. теперь надо поработать над шрифтами... кстати тут понадобится сильная оптимизация, потому что построчный вывод шрифтов в буфер будет занимать много расчётов, а потом ещё и из буфера выводить!..
FreGL есть какие нить задумки на счёт этого???

опять не пойму - при чтении из видеопамяти, начальным (нулевым) смещением почему-то считается левый верхний угол окна, запустившего графическое приложение(то есть если запускаете из sysxtree, и сохраняете данные из видеопамяти, начиная с 0-го смещения, а затем выводите это изображение куда-нить на экран, то выводится окно sysxtree, при том в очень интересном виде... тоже самое и с запуском из тинипада).

и ещё - допустив небольшую ошибку в программке весь экран сделал в оттенках серого (как в ХР

) правда панель сразу перерисовалась, но всё равно было прикольно!!! надо будет доработать END

Fri Aug 12, 2005 3:08 pm

Идей много, а знаний мало

Fri Aug 12, 2005 4:09 pm

FreGL
знаний много не бывает

пусть в меня кинут помидорами те, кто считает что он знает всё! (слышны хлопки помидоров о лицо DoomEd'a)
вобщем я пока буду пробовать сделать что нить с этой функцией. если будут какие наработки - пиши.

Sat Aug 13, 2005 4:42 pm

Работа со шрифтами - дело полезное, но сложное. Во-первых нужно разработать формат растрового шрифта. Во-вторых нужно перевести стандартные шрифты (с помощью программы в windows, например, отображающей, а потом обратно считывающей символы) в этот формат. В-третих нужно договориться об алгоритме поиска подходящего шрифта, когда запрошеного шрифта нет и о месте хранения шрифтов. А сам вывод шрифта после всего этого покажется несущественной мелочью.
(Дальше пункта 1 еще никто не доходил.)
На счет глюков чтения из видеопамяти. Такого не должно быть. Напиши программу, которая записывает и тут же читает из видеопамяти (по нулевому адресу), и в случае не совпадения выдает сообщение на доску отладки. Если глюк в ней подтвердиться, то она станет неплохим тестом, когда кто-нибудь будет этот глюк исправлять.

Sat Aug 13, 2005 7:09 pm

halyavin
кстати, я пробовал написать подобную программу под Меос, но у меня тогда получилось только выводить шрифт на экран.. можно было бы её доработать. а на счёт разработки растрового шрифта - можно было бы просто записывать в файле шрифта номера закрашиваемых точек, если ты меня поймёшь

такой шрифт действительно быстрее бы обрабатывался, но стоит ли оно того? ведь растровые шрифты в ОС с интегрированным в ядро ГУИ проживут не долго... ладно, я могу трепаться бесконечно! а надо что то делать...

кста, програмку я напишу и проверю, а то я сам не уверен в присутствии этого глюка (скорее у меня в проге чем в ядре)...

Sat Aug 13, 2005 9:49 pm

ведь растровые шрифты в ОС с интегрированным в ядро ГУИ проживут не долго

Мне кажется, что перед использованием любого шрифта он растеризуется. Просто более интеллектуальные форматы позволяют хранить в небольшом объеме кучу вариантов шрифта, а в памяти, соотвественно, хранятся растеризованными только нужные варианты. Кто-нибудь разбирается в GDI настолько, чтобы подтвердить/опровергнуть это утверждение? (а то мне самому интересно)

Sun Aug 14, 2005 2:48 pm

halyavin
запись/чтение видеопамяти производится правильно (по крайней мере на ядре колибри 4).
это в той программке были глюки - я учитывал 4ый байт, но не перепрыгивал через него...

кстати, для чего он всё таки нужен???

ещё нашёл свою ошибку - я думал что запись производится не напрямую в видеопамять, а в некий буфер. а при вызове ф-ии 61 буфера меняютяс местами... оказалось что всё не так, и запись производится напрямую в память и 61ю ф-ю можно не вызывать...
НО! приходится использовать свой буфер, что ЗНАЧИТЕЛЬНО замедляет работу...
Представьте что надо почти 3,5 мега побайтно сначала просчитывать и записывать в ВП.

Sat Aug 20, 2005 6:03 pm

а можно ли добавить использование z-buffer'a ??? и насколько это сложно?
Майк, если есть ссылки на инфу о графике, в частности о битности (а то надо делать и для других режимов тоже) плз скинь

это я DoomEd.

61 = ПРЯМОЙ ДОСТУП К ГРАФИКЕ

Who is online