вот сочинил


Присоединённый файл ( Кол-во скачиваний: 67 )
 ddraw_asm.rtf

Цитата

после окончания наших художественных работ «бэкбуфер» нада разлочить comcall DDSBack,UnlockSurface,0

Почему ? Я выделил память (кому она нужна-то ?), спокойно в ней рисую. Как настало время вывести, я включил ее тама в какую-то очередь - дал знать там кому-то, что хочу вывести.

Цитата

тоесть для рисования к примеру белой точки в левом верхнем углу достаточно сделать mov [edi],0xffffffffh с учетом выставленой 32 битной глибины цвета

Так что, в винде рисование сводится к примерно режиму 13h (256 цветов 320x200) - просто каждая ячейка содержит номер цвета ?

Кстати, а как же вывод самой винды ? Неужели тоже целым банком ? Скажем, винда отрисовывает мышь по новой только если она попадает на изменяемую область экрана.

Цитата

Почему ? Я выделил память (кому она нужна-то ?), спокойно в ней рисую. Как настало время вывести, я включил ее тама в какую-то очередь - дал знать там кому-то, что хочу вывести.

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

Цитата

Так что, в винде рисование сводится к примерно режиму 13h (256 цветов 320x200) - просто каждая ячейка содержит номер цвета ? Кстати, а как же вывод самой винды ? Неужели тоже целым банком ? Скажем, винда отрисовывает мышь по новой только если она попадает на изменяемую область экрана.

тут не в винде дело
просто видео память так организована что в режиме 32 бита к примеру
получаем RGB+1 байт нафик не нужный ( ну под альфу можно ипользовать)
и 255,255,255 будет соответственно точка белого цвета
а в 13 режиме 1 байт на точку с выбором цвета из палитры
ну а так как мы рисуем напрямую в память то оно так и будет
кстати если при режиме 32 бита сделать окно 8 бит
то оно будет емулится кабы (не могет карта сделать 2 куска памяти разнобитными)
а вот на Амиге могет , там могу разные разрешения и глубины цветов в тотже самый момент на
экране рисовать, но эт к теме не относится

в дебри винды я не лазил но думаю что она как положено рисует себе в lfb и не мучается
на 95 винде можно перед ее загрузкой посадить в память резидент
который в первом банке к примеру рисует ченить ну или в lfb
и при загрузке винды все это видно будет
сам проверял
на остальных думаю также, проверять лень , резидентов они прибивают
можно драйвер нарисовать пусть ченить рисует в банк

кстати мыш в большинстве случаев хардварно картой рисоватся может,если карта поддерживает, ну они почти все поддерживают

Это сообщение отредактировал(а) oleg1973 - 11.4.2004, 18:39

Слишком много умных слов, не че не понял =)

Отлично написано.
Мне очень понравилось - просто, понятно и доступно.
Не сочтите за наглость, но небольшие пожелания как юзера данного эпоса:
1) хотелось бы в конце документа иметь приложение (в смысле приложение к тексту, а не программа-приложение) ко всему написанному - готовый текст программки, с к-м можно сделать "копировать-вставить", нажать Compile, Run, полюбоваться, а потом уж начинать прорабатывать самостоятельно - понимать, разбирать и набирать. А то так и запутаться можно.. ;)
2) в документе упоминаются различные DDraw-константы, нельзя ли заодно и упоминать, какие еще возможны варианты (допустим, если я не хочу полноэкранный режим?..)
3) дальше хочу. А будет ли продолжение? Эт первый документ по ddraw, к-й я ПОЛНОСТЬЮ понял и хочется развиваться в этом направлении.. Очень интересуют такие вопросы как вывод картинки (фоном или просто в опред. месте), вывод графических примитивов (линия, прямоугольник и т.д) - не верится, что там все по пикселам сделано () ну и т.д. и т.п.

Как я уже говорил, все вышесказанное не более чем фантазии на тему "а чего бы еще хотелось". Искренне надеюсь, мною не написано ничего обидного и протиозаконного.

придется дописать вторую серию

Да, написано неплохо. Полезно.

Цитата

Да, написано неплохо. Полезно.

Лучше и не скажешь!
Короче, ожидаем..

Мужики!
Я тут впервые, так что не топчите сразу ногами
Пишу на Билдере, возникла нужда двигать картинки по экрану, нашел в экзамплах DDraw, вроде годится, но вот беда - никакой доки по DDraw нету, а по экзамплам не все ясно. Куда сходить, чтоб забрать хелп по нему для начинающего? Или в идеале может кто его зазипованного скинет мне на мыло: [email protected]

а причем тут ассемблер?

Одно но есть, от которого нужно избавится.
Я предполагаю, что при ображщении процессора к видеопамяти видеокарты запись в видеопамять будет происходить только во времена 

1) Обратного хода луча по кадру
2) Обратного хода луча по строке

Можно как-нибудь отключить это ограничение ?

Оно существует потому, что пишут вроде чтобы на экране не появлялся снежок.
Но никакого снега я никогда не замечал, даже если данные записывались и все время.

Дело заключается в том, что  до этого я использовал для вывода растровых прямоугольных изображений АПИ-функцию SetDIBitsToDevice, и она давала скорость при полноэкранном выводе массива до 120 кадров в секунду. А только что попробовал с помощью Direct Draw выводить - и всего 40 кадров в секунду. Это привело меня в недоумение сначала. Потом я предположил, что если луч в данный момент времени рисует линию на экране - то компьютер ожидает обратного хода луча и только когда будет обратный ход луча по строке или по кадру - начинается запись в видеопамять.

Функция SetDIBitsToDevice давала большую производительность, наверное потому, что вывод изображения происходил и в течении прямого и обратных ходов луча. 
НО СНЕГА НЕ БЫЛО НА ЭКРАНЕ !

Может уважаемый Олег подскажет, как отключить запрет записи в видеопамять в течении прямого хода луча ?

Сей "продвинутый" метод расчистки снега помнится применялся на CGA видекартах, но стех пор много снега упало и растаяло. Теперь записываемые данные буферизируются аппаратно и прозрачно для программ  (кажется это уже в EGA появилось )

Собственно в тексте же есть:

Но это мерцание не снег, а когда полэкрана одна картинка, а полэкрана другая, поэтому и рекомендуется дождаться обратного хода по экрану, а не по строке.
Ихмо заметно это только если эти части экрана сильно отличаются, т.е. при быстром движении рисуемого объекта.

Это сообщение отредактировал(а) mur - 22.9.2006, 21:23

ГА-ГА-ГА     

Я наверно заблуждался в своих рассуждениях. И теперь понял почему !
Функция SetDIBitsToDevice давала большую производительность, наверное потому, что вывод изображения происходил в оперативную память, а в видеопамять он происходил в фоновом режиме. И реализация этого фонового режима мне неизвестна,    то ли ее реализует сам видеодрайвер ?

Некоторые факты подтверждают мое предположение. Когда я разгонял тактовую частоту шины FSB - пропорционально увеличивалась и тактовая частота шины памяти, но тактовая частота шины AGP ведь не должна зависеть от FSB и частота передачи данных в видеокарту не увеличится от этого, видеокарта не станет быстрее потреблять данные; так вот при разогнанной частоте FSB функция SetDIBitsToDevice работала быстрее во столько же раз, во сколько была увеличена частота FSB (1,2 раза).
А скорость записи с помощью DirectDraw не изменилась.

И вообще во время непрерывной записи в течении 3 минут в видеопамять на частоте FSB 120 МГц (вместо номинальной 100 МГц) произошел сбой...

Это сообщение отредактировал(а) sgi1981 - 23.9.2006, 09:05

Дошли руки потестить SetDIBitsToDevice (до этого всегда юзал StretchDIBits)
Выводы: 
1. Обе функции не синхронизированы с обратным ходом по кадру (это хорошо видно при горизонтальном движении вертикальной полосы на всю высоту экрана)
2. Время копирования у SetDIBitsToDevice и StretchDIBits практически одинаково и составляет: 
   ~17 тактов на пиксел на PII с преобразованием цвета из 32 битного BitMap в 16 битный экран
   ~6 тактов на пиксел на PM при 32 битном экране и BitMapе 
   ~3 такта на пиксел на другом PM с такой же тактовой    значит видеоускорители используются  
При желании их можно засинхронизировать с помощью DirectDraw функций WaitForVerticalBlank или GetScanLine

Еще разобрался с флагом DDLOCK_WAIT в IDirectDrawSurface::Lock. Он оказывается означает ждать освобождения поверхности если она занята другим потоком   (в IDirectDrawSurface7 и выше вместо него используется обратный флаг DDLOCK_DONOTWAIT, а отсутствие DDLOCK_WAIT ничего не значит  ) соответственно к кадровой синхронизации это никакого отношения не имеет. Т.е. получается, что в DirectDraw тоже нужно использовать WaitForVerticalBlank или GetScanLine (это пока не тестировал).


Это сообщение отредактировал(а) mur - 25.10.2006, 21:12