61 = ПРЯМОЙ ДОСТУП К ГРАФИКЕ
-
Кто работал напрямую с видео памятью? ПЛЗ покажите в какой программе реализованна эта ф-я. а то в огоньках и в других граф. приложениях всё это делается с 7ой ф-ей.
ДА, а заодно как :
-скопировать часть изображения (например часть формы) в буфер
-как сделать вывод в буфер (например написать текст в буфере а не наэкране)?
Меня интересует реализация скроллинга изображения в выделенной области в частности!
-скопировать часть изображения (например часть формы) в буфер
-как сделать вывод в буфер (например написать текст в буфере а не наэкране)?
Меня интересует реализация скроллинга изображения в выделенной области в частности!
DoomEd Archangel
Есть функция 61, но я с ней не разбирался.
FreGL
1) Расписывай подробней, а то нихрена непонятно.
2) Ты про это уже спрашивал, и тебе сказали, что штатных средств в системе для этого нет. Могу предложить метод, реализации, раз ты сам не ничего не можешь придумать. Ты должен иметь файл со шрифтами, в принципе шрифт в МеОС это набор двухцветных спрайтов, которые выводятся методом наложения через AND или OR, час уже точно не помню. Так вот накладываешь по кускам спрайты букв в нужное место буфера, поверх изображения и потом выводишь буфер на экран. Ничего особо сложного в процедуре нет.
3) Скроллинг изображения в буфере делается тоже просто. Размер буфера должен быть больше размера выводимого окошка. А ты просто изменяешь координаты этого самого окошка в буфере при передаче вывода на экран. И все. Телемаркет!
Блин для меня написание приложений это как ерунда после ковыряния ядра. Подолбались бы вы с ядром вам бы приложения показались фигней. Действительно я теперь вижу окно приложения не как приложение и даже не как набор элементов управления. Я вижу просто куски кодов связанных между собой. Поневоле матрица вспоминается.
Есть функция 61, но я с ней не разбирался.
FreGL
1) Расписывай подробней, а то нихрена непонятно.
2) Ты про это уже спрашивал, и тебе сказали, что штатных средств в системе для этого нет. Могу предложить метод, реализации, раз ты сам не ничего не можешь придумать. Ты должен иметь файл со шрифтами, в принципе шрифт в МеОС это набор двухцветных спрайтов, которые выводятся методом наложения через AND или OR, час уже точно не помню. Так вот накладываешь по кускам спрайты букв в нужное место буфера, поверх изображения и потом выводишь буфер на экран. Ничего особо сложного в процедуре нет.
3) Скроллинг изображения в буфере делается тоже просто. Размер буфера должен быть больше размера выводимого окошка. А ты просто изменяешь координаты этого самого окошка в буфере при передаче вывода на экран. И все. Телемаркет!
Блин для меня написание приложений это как ерунда после ковыряния ядра. Подолбались бы вы с ядром вам бы приложения показались фигней. Действительно я теперь вижу окно приложения не как приложение и даже не как набор элементов управления. Я вижу просто куски кодов связанных между собой. Поневоле матрица вспоминается.
т.к. видимо никто ещё не касался этой темы, был сделан научный тык в ф-ю 61.
Для не сведующих в этом деле (как я) вот пример.
кто разбирается в этом -
почему возможно записывать только побайтно? зачем нужен 4-ый байт в 32х битном цвете? почему цвета располагаются не по установленному порядку?
Для не сведующих в этом деле (как я) вот пример.
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х битном цвете? почему цвета располагаются не по установленному порядку?
и ещё
не совсем понял что выдала мне ф-я 61 при ebx=1 при разрешении 1024х768х32
вобщем в переменных было:
scr_x = 2097920
scr_y = 50332672
не совсем понял что выдала мне ф-я 61 при ebx=1 при разрешении 1024х768х32
вобщем в переменных было:
scr_x = 2097920
scr_y = 50332672
хех .. есть же 14 ф-я...
я почти победил эту 61-ю... завтра если получится попробую вывести изображение...
вообще весч прикольная, одно достаёт - каждый байт записывать отдельно.. двордами удобнее было бы, и быстрее..
кстати, если выводить рисунок напрямую в память, это будет быстрее чем вывод через putimage??? учитывая что надо будет побайтно брать цвет и прописывать в память...
я почти победил эту 61-ю... завтра если получится попробую вывести изображение...
вообще весч прикольная, одно достаёт - каждый байт записывать отдельно.. двордами удобнее было бы, и быстрее..
кстати, если выводить рисунок напрямую в память, это будет быстрее чем вывод через putimage??? учитывая что надо будет побайтно брать цвет и прописывать в память...
Надо учитывать, что система может работать не только с разным разрешением экрана, но и с разным количеством бит на пиксел (32, 24; [крутые режимы] 8 и 4; [с моим драйвером] 16 и 15). Ты же не хочешь заставлять пользователя устанавливать нужный тебе видеорежим? К тому же, нужный режим может быть недоступен пользователю (не поддерживается). Не думаю, что вручную писать в видеопамять будет быстрее. В моём драйвере используется оптимизация под каждый битовый режим.
Удачи.
Удачи.
mike.dld
да, я знаю на счёт битовых режимов. я пока проверяю только на 32х битном цвете.
на счёт скорости - есть ли возможность ускорить запись\чтение? а с драйвером?
ведь надо что нибудь придумать на счёт "мерцания" при прокрутке, быстром наборе, и тд ..???
картинка выводится, и даже с прозрачным фоном (я с видео памятью до этого никогда не работал, так что для меня это щас так дико .. теперь надо поработать над шрифтами... кстати тут понадобится сильная оптимизация, потому что построчный вывод шрифтов в буфер будет занимать много расчётов, а потом ещё и из буфера выводить!..
FreGL есть какие нить задумки на счёт этого???
опять не пойму - при чтении из видеопамяти, начальным (нулевым) смещением почему-то считается левый верхний угол окна, запустившего графическое приложение(то есть если запускаете из sysxtree, и сохраняете данные из видеопамяти, начиная с 0-го смещения, а затем выводите это изображение куда-нить на экран, то выводится окно sysxtree, при том в очень интересном виде... тоже самое и с запуском из тинипада).
и ещё - допустив небольшую ошибку в программке весь экран сделал в оттенках серого (как в ХР ) правда панель сразу перерисовалась, но всё равно было прикольно!!! надо будет доработать END
да, я знаю на счёт битовых режимов. я пока проверяю только на 32х битном цвете.
на счёт скорости - есть ли возможность ускорить запись\чтение? а с драйвером?
ведь надо что нибудь придумать на счёт "мерцания" при прокрутке, быстром наборе, и тд ..???
картинка выводится, и даже с прозрачным фоном (я с видео памятью до этого никогда не работал, так что для меня это щас так дико .. теперь надо поработать над шрифтами... кстати тут понадобится сильная оптимизация, потому что построчный вывод шрифтов в буфер будет занимать много расчётов, а потом ещё и из буфера выводить!..
FreGL есть какие нить задумки на счёт этого???
опять не пойму - при чтении из видеопамяти, начальным (нулевым) смещением почему-то считается левый верхний угол окна, запустившего графическое приложение(то есть если запускаете из sysxtree, и сохраняете данные из видеопамяти, начиная с 0-го смещения, а затем выводите это изображение куда-нить на экран, то выводится окно sysxtree, при том в очень интересном виде... тоже самое и с запуском из тинипада).
и ещё - допустив небольшую ошибку в программке весь экран сделал в оттенках серого (как в ХР ) правда панель сразу перерисовалась, но всё равно было прикольно!!! надо будет доработать END
Идей много, а знаний мало
FreGL
знаний много не бывает пусть в меня кинут помидорами те, кто считает что он знает всё! (слышны хлопки помидоров о лицо DoomEd'a)
вобщем я пока буду пробовать сделать что нить с этой функцией. если будут какие наработки - пиши.
знаний много не бывает пусть в меня кинут помидорами те, кто считает что он знает всё! (слышны хлопки помидоров о лицо DoomEd'a)
вобщем я пока буду пробовать сделать что нить с этой функцией. если будут какие наработки - пиши.
Работа со шрифтами - дело полезное, но сложное. Во-первых нужно разработать формат растрового шрифта. Во-вторых нужно перевести стандартные шрифты (с помощью программы в windows, например, отображающей, а потом обратно считывающей символы) в этот формат. В-третих нужно договориться об алгоритме поиска подходящего шрифта, когда запрошеного шрифта нет и о месте хранения шрифтов. А сам вывод шрифта после всего этого покажется несущественной мелочью.
(Дальше пункта 1 еще никто не доходил.)
На счет глюков чтения из видеопамяти. Такого не должно быть. Напиши программу, которая записывает и тут же читает из видеопамяти (по нулевому адресу), и в случае не совпадения выдает сообщение на доску отладки. Если глюк в ней подтвердиться, то она станет неплохим тестом, когда кто-нибудь будет этот глюк исправлять.
(Дальше пункта 1 еще никто не доходил.)
На счет глюков чтения из видеопамяти. Такого не должно быть. Напиши программу, которая записывает и тут же читает из видеопамяти (по нулевому адресу), и в случае не совпадения выдает сообщение на доску отладки. Если глюк в ней подтвердиться, то она станет неплохим тестом, когда кто-нибудь будет этот глюк исправлять.
halyavin
кстати, я пробовал написать подобную программу под Меос, но у меня тогда получилось только выводить шрифт на экран.. можно было бы её доработать. а на счёт разработки растрового шрифта - можно было бы просто записывать в файле шрифта номера закрашиваемых точек, если ты меня поймёшь такой шрифт действительно быстрее бы обрабатывался, но стоит ли оно того? ведь растровые шрифты в ОС с интегрированным в ядро ГУИ проживут не долго... ладно, я могу трепаться бесконечно! а надо что то делать...
кста, програмку я напишу и проверю, а то я сам не уверен в присутствии этого глюка (скорее у меня в проге чем в ядре)...
кстати, я пробовал написать подобную программу под Меос, но у меня тогда получилось только выводить шрифт на экран.. можно было бы её доработать. а на счёт разработки растрового шрифта - можно было бы просто записывать в файле шрифта номера закрашиваемых точек, если ты меня поймёшь такой шрифт действительно быстрее бы обрабатывался, но стоит ли оно того? ведь растровые шрифты в ОС с интегрированным в ядро ГУИ проживут не долго... ладно, я могу трепаться бесконечно! а надо что то делать...
кста, програмку я напишу и проверю, а то я сам не уверен в присутствии этого глюка (скорее у меня в проге чем в ядре)...
Мне кажется, что перед использованием любого шрифта он растеризуется. Просто более интеллектуальные форматы позволяют хранить в небольшом объеме кучу вариантов шрифта, а в памяти, соотвественно, хранятся растеризованными только нужные варианты. Кто-нибудь разбирается в GDI настолько, чтобы подтвердить/опровергнуть это утверждение? (а то мне самому интересно)ведь растровые шрифты в ОС с интегрированным в ядро ГУИ проживут не долго
halyavin
запись/чтение видеопамяти производится правильно (по крайней мере на ядре колибри 4).
это в той программке были глюки - я учитывал 4ый байт, но не перепрыгивал через него...
кстати, для чего он всё таки нужен???
ещё нашёл свою ошибку - я думал что запись производится не напрямую в видеопамять, а в некий буфер. а при вызове ф-ии 61 буфера меняютяс местами... оказалось что всё не так, и запись производится напрямую в память и 61ю ф-ю можно не вызывать...
НО! приходится использовать свой буфер, что ЗНАЧИТЕЛЬНО замедляет работу...
Представьте что надо почти 3,5 мега побайтно сначала просчитывать и записывать в ВП.
запись/чтение видеопамяти производится правильно (по крайней мере на ядре колибри 4).
это в той программке были глюки - я учитывал 4ый байт, но не перепрыгивал через него...
кстати, для чего он всё таки нужен???
ещё нашёл свою ошибку - я думал что запись производится не напрямую в видеопамять, а в некий буфер. а при вызове ф-ии 61 буфера меняютяс местами... оказалось что всё не так, и запись производится напрямую в память и 61ю ф-ю можно не вызывать...
НО! приходится использовать свой буфер, что ЗНАЧИТЕЛЬНО замедляет работу...
Представьте что надо почти 3,5 мега побайтно сначала просчитывать и записывать в ВП.
а можно ли добавить использование z-buffer'a ??? и насколько это сложно?
Майк, если есть ссылки на инфу о графике, в частности о битности (а то надо делать и для других режимов тоже) плз скинь
это я DoomEd.
Майк, если есть ссылки на инфу о графике, в частности о битности (а то надо делать и для других режимов тоже) плз скинь
это я DoomEd.
Who is online
Users browsing this forum: No registered users and 9 guests