
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.97.9.174] |
![]() |
|
Сообщ.
#1
,
|
|
|
(Как всё это заставить работать ??? )
Подскожите Pleazz как инициализировать графический режим 640x480x8 в Protected mode с использованием LFB. (А то в Real медленно получается) И если можно укожите пару адресков с аписанием. |
Сообщ.
#2
,
|
|
|
Не занимайся ерундой!
![]() ![]() |
Сообщ.
#3
,
|
|
|
Fallex
Спасибо за совет, но ты вобше работал с VESA. VESA позваляет работать с бальшими разрешениями и количеством цветов. А меня интересует 640x480x16. В Real mode есть только одно (два но второе не используют) окно $A000 разметом 64к и это значит, что весь видео буфер нужно грузить по кускам 640*480*2/65536=9.375 (на одну страницу надо 10 кусков). Из за этих кусков резко усложняются все процедуры вывода графики на экран и по таму нужно инфо по LFB (Long frame bufer (если не ошибаюсь)). Все линейно по таму и скорость больше понемаеш? |
Сообщ.
#4
,
|
|
|
Информации по LFB более чем достаточно, например, имеется официальное описание стандарта VESA/VBE 3 Core Functions, которое можно скачать с www.vesa.org. Тем не менее, имей в виду, что LFB-приложения не работают под операционными системами Windows NT (NT 3/4, 2000, XP), а это довольно сильное ограничение... :-( Таким образом, использование VESA 1.2 (т.е. работа с банками видео памяти) остается единственным надежным методом программирования SVGA графики в приложениях MS-DOS.
|
Сообщ.
#5
,
|
|
|
Используй TMT-Pascal !!! Очень удобная работа с графикой !!!
|
Сообщ.
#6
,
|
|
|
vb
Если LFB под win 2000 не палит то вазможно ли добится приемлимых скоростей используя банки видео памяти? (скажем закрашивать экран 50 раз на секунду в режиме 640x480x16 на 333 Celeron) |
Сообщ.
#7
,
|
|
|
7in
Я бы с удовольствием изучил бы TMT но у меня есть только кампилятор (без редактоа), что давольно не удобно. |
![]() |
Сообщ.
#8
,
|
|
Интересно, куда ж он, редактор, у тебя делся-то???
Он обзывается idew32.exe ![]() Скачивай новую версию 3.90! |
Сообщ.
#9
,
|
|
|
Цитата Chibis, 27.04.02, 00:33:38 vb Если LFB под win 2000 не палит то вазможно ли добится приемлимых скоростей используя банки видео памяти? (скажем закрашивать экран 50 раз на секунду в режиме 640x480x16 на 333 Celeron) Это зависит от оптимизации твоего кода и от производительности видеокарты (критическим фактором является пропускная способность VRAM). Думаю, что прокачать 234.5 Mb в секунду ("...закрашивать экран 50 раз на секунду в режиме 640x480x16...") сможет практически любая видеокарта, т.к. даже простенькая Riva Vanta LT имеет пропускную способность памяти 800 Мб/с. |
Сообщ.
#10
,
|
|
|
2: Chibis
Я немного ошибся в своем предыдущем письме. В действительности, для выполнения твоей задачи нужно прокачать не 234.5 Мб/с, а всего-навсего 29.3 Мб/с (=640*480*2*50). Такая пропускная способность не является проблемой даже для очень древних карточек. |
Сообщ.
#11
,
|
|
|
Правильно люди говорят!
![]() ТМТ паскаль - и проблема решена( ну почти : ![]() Так чо поищи лучше инфу по модулю GRAPH в ТМТ |
Сообщ.
#12
,
|
|
|
Ладно уговорили. Уже качаю TMT.
|
Сообщ.
#13
,
|
|
|
vb
Незнаю но я лично дабился скорости не больше 40 кадров. Использовал Pascal 7.0 с Asm. Перебрасывал по 4 байта используя db 66h. Все тормоза как я понел из за переключения банков. |
Сообщ.
#14
,
|
|
|
TMT С РЕДАКТОРОМ, ПРИБАМБАСАМИ, ПРИМЕРАМИ V3.90 И ГЛАВНОЕ НА ХАЛЯВУ :D
Уже слюньки потекли. ![]() |
Сообщ.
#15
,
|
|
|
Цитата Chibis, 27.04.02, 22:39:51 vb Незнаю но я лично дабился скорости не больше 40 кадров. Использовал Pascal 7.0 с Asm. Перебрасывал по 4 байта используя db 66h. Все тормоза как я понел из за переключения банков. Использование 32-битных команд в 16-битном режиме (db 66h) выполняется не особо быстро. Все-таки в native 32-bit protected mode это дело работает гораздо шустрее. Конечно, процедура переключения банков тоже требует достаточно много времени. Тем не менее, она не должна _так_сильно_ тормозить процесс... Ты не мог бы привести полный код своей процедуры закраски экрана? |
Сообщ.
#16
,
|
|
|
По поводу переключения банков: лучше переключать их, делая FAR CALL, а не через INT 10h. Шустрее будет....
|
Сообщ.
#17
,
|
|
|
Особенно медленно прерывания (в т.ч. и INT 10h) работают в 32-битных приложениях защищенного режима, т.к. thunking (переключение режима 32bit->16bit->32bit) очень сильно тормозит приложение. Таким образом, прямой вызов 32-битной процедуры переключения банков, которая доступна в VESA 2.0 и выше (функция 0Ah - Return VBE Protected Mode Interface), действительно очень ускоряет работу с графикой в banked SVGA режимах.
|
Сообщ.
#18
,
|
|
|
7in
Первый пример VESA который я в дальнейшем разобрал как раз использавал этот FAR CALL. (см. ниже) |
Сообщ.
#19
,
|
|
|
vb
По поводу примера: Далее приведён почти рабочий пример программы с использованием моей процедуры закраски экрана (VFAP) в Real mode. Следует отметить что она ращитана на работу с разными разрешениями и колличеством цветов, так же предусмотрен просчёт для переключения видео страниц. Но т.к. тут всё фиксировано то все числа подставлены в ручную. Надеюсь что я подставил верные параметры для работы проги но если она не заработает то прошу меня проинформировать). На моём 333 Cel эта процедура даёт около 47 кадров за секунду. Может есть замечания, предложения по оптимизации, или критика то пишите. ![]() ![]() Var wAddPixel:Word; {Заполняется процедурой переключения видео страниц} wAddChunk:Word; {-//-//-} wEndChunk:Word; {-//-//-} wEndPixel:Word; {-//-//-} BytesPerPixel:Byte;{Заполняется при инициализации} pWindowingFunction:Pointer;{-//-//-} wDeltaChunk:Word;{-//-//-} wWriteSegment:Word;{-//-//-} wReadWriteChunk:Word;{Нужно для хранения активного банка. Позволяет избавляться от лишнего переключения банка. Активно используется процедурой прорисовки точки.} Buf:Array[0..63]of LongInt; Function VESAModeSupport(GrMode:Word):Boolean; {Нужна для получения информации} Assembler; Asm mov ax,Seg(Buf) mov es,ax mov di,Offset(Buf) mov ax,$4F01 mov cx,GrMode int $10 End; Procedure VFAP(wColor:word);{Вот так она у меня выглядит} Assembler; Asm mov ax,wAddPixel mov bl,BytesPerPixel xor bh,bh mul bx add dx,wAddChunk mov di,ax mov bx,0 pusha; cli; call pWindowingFunction; sti; popa mov cx,wDeltaChunk add cx,wEndChunk mov ax,wWriteSegment mov es,ax mov ax,wColor db 66h shl ax,16 add ax,wColor {Далее сама закраска} @1: db 66h;stosw cmp di,1 jnc @1 inc dx pusha; cli; call pWindowingFunction; sti; popa sub cx,1 jnz @1 @2: db 66h stosw cmp di,wEndPixel jnz @2 mov dx,wReadWriteChunk pusha; cli; call pWindowingFunction; sti; popa End; Begin VesaModeSupport($101); {Нужна для получения адреса процедуры переключения строниц} pWindowingFunction:=Pointer(Buf[3]);{Сам адрес} wWriteSegment:=$A000; {По умолчанию} BytesPerPixel:=2; wDeltaChunk:=640*480 div $8000; wEndPixel:=24576; Asm mov ax,$4f02;mov bx,$111; int 10h; end; {Грубоя инициализация режима 640x480x16 на самом деле всё делается не так} VFAP($ffff);{Обычно я закрашиваю чёрным цветом} ReadLn; Asm mov ax,3; int 10h; End; End. |
Сообщ.
#20
,
|
|
|
А для чего ты вызываешь pWindowingFunction в конце процедуры (непосредственно перед “End;”)? IMHO кроме дополнительного торможения программы, это ничего не дает... Кроме того, “rep stosd” будет выполняться быстрее, чем последовательность “@2: stosd; cmp di, wEndPixel; jnz @2”. Еще, вместо pusha/popa можно сохранять только те регистры, которые используются в твоей процедуре (es, ax, di, cx и dx) – так быстрее. Ну и разумеется, если переписать все это дело под 32-bit protected mode, то можно будет избавиться от префикса 66h, что даст дополнительный прирост производительности.
|
Сообщ.
#21
,
|
|
|
vb
Спасибо за советы, учту. Было бы интересно посмотреть твои 32-ух битные разработки(если они у тебя есть), может скинеш что нибудь? |
Сообщ.
#22
,
|
|
|
Честно говоря, мне и скинуть то нечего... Давать тебе обобщенные процедуры нет смысла, т.к. они все равно будут достаточно медленными. Писать что-то конкретное для твоего примера тоже не интересно, т.к. ты это прекрасно сделаешь и без меня. Если же надо дать пару-тройку советов по оптимизации конкретного примера - всегда пожалуйста!
|
Сообщ.
#23
,
|
|
|
Не врубаюсь, зачем нужна 2-ух байтная переменная wWindowGranulity?
(5-ий байт буффера передавймый при вызове VESAModeSupport (AX=4F01)) |