Прямая запись в изображение на экране монитора.

Как напрямую изменять пиксели на мониторе максимально быстро.
Допустим нужна программа, которая при запуске, не создавая окна, рисует квадрат,
просто напрямую в видео-память, прямо на рабочем столе.
Не используя OpenGl,DirectX,GDI... .

Хочу сделать игру где много эффектов, и быстрее будет работать с пикселями как с массивом.
Вроде такого(В данном случае сделать какой-то пиксель красным, другой синим, третий зелёным):

Код (Text):

1. mov dword [graphics+256], dword ff000000h
2. mov dword [graphics+260], dword 00ff0000h
3. mov dword [graphics+264], dword 0000ff00h

 

спроэцируй себе в АП видеобуфер..
поидее этого можно достичь посылкой IOCTL_VIDEO_SHARE_VIDEO_MEMORY видео-драйверу

 

Вопрос, сколько времени спроецированное изображение проживет в видеобуфере, пока не будет затерто видеодрайвером, обновляющим изображение рабочего стола и ничего не знающего о "незаконном вторжении" ???

 

Лично я выдвигаю гипотизу о том что прямой доступ медленее чем через OpenGl,DirectX,GDI при умелом использовании.
dess
Можно получить обновленную облость и перерисовать ее. Как не помню но думаю это не составит труда сделать.

 

хочешь прямого вывода в видео память, а алгоритмы для рисования, скажем, ну хотябы полилинии в массиве байтов у тя есть? Это не проще чем через opengl или directx, ну и тем более gdi

 

Zhelezka
1. кури интерфейсы директ X 2-7 они как раз предоставляют простой и удобный способ прямого доступа к видеопамяти.
2. рисовать прямо на экране без окна элементарно можно и через GDI .
3. если очень хочется рисовать самому (при дзенном подходе обогнать по скорости рисования GDI/GDI+ действительно элементарно), то для этого проще всего рисовать в BitMap и копировать его в экран. Исчезнет мерцание и далеко не всегда правильно делать векторную перерисовку при обновлении экрана, иногда достаточно просто перескопировать буфер. (или тоже самое через поверхности в DX7)
4. отказываясь от средств DX и OGL ты отказываешся от аппаратного ускорения и потому не факт, что выиграешь в скорости

max7C4

дак освоение этих алгоритмов (медитация + гугл в помощь) и есть самая интересная часть в таких задачах а когда ещё и видишь, что даже не очень хорошо оптимизированный вариант кода всё равно быстрее GDI - приятно )
Массив байтов с палитрой в наше время неактуален рисовать лучше всего в массиве dword, а при необходимости поддержки совместимости с 256 цветным (и т.п.) режимами имхо всё равно лучше рисовать через dword, а при копировании в экран преобразовывать.

 

Zhelezka

DirectDraw тебе в помощь (прямой доступ к поверхностям + аппаратное ускорение).

 

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

 

dess, а что с ним должно случицо? это проекция.. то, что меняется по физ адресу видеопамяти, меняется и у тебя по соотв виртуальному адресу и наоборот. дабы убрать проекцию надо послать IOCTL_VIDEO_UNSHARE_VIDEO_MEMORY.
а вообще, как сказали выше, прямой доступ не лучшая идея.

 

Freeman

Что такое АП буфер?
Можно поподробнее?

Pavia и Y_Mur

Я думаю апаратное ускорение не сможет того чего я хочу ь, я хочу некторые эффекты, которые думаю аппаратно быстро не сделать.

max7C4

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

Y_Mur

Простой и удобный, скорее всего не подойдёт.
Обычно с простыми и удобными много не сделаешь, или делать будут лишнее, ну и конечно скорость.

Хотелось-бы услышать такие варианты:
1:Работает в разнах ОС, и максимально быстрая работа с массивом пиклелей(растровым изображением).
2:Работает в разнах ОС, прямой доступ, без посредников.
3:Максимально быстрая работа с массивом пиклелей(растровым изображением)

 

Zhelezka

В этом вопросе лучше не думать, да гадать, а почитать что умеют современные видеоускорители вообще и твой в частности

Там простой и удобный прямой доступ к видеопамяти как к массиву, так что скорость отрисовки уже целиком определяется твоим алгоритмом
+ возможность рисовать в буфере, который расположен в невидимой видеопамяти но его можно мнговенно сделать видимым без копирования.
Ещё есть аппаратная поддержка копирования памяти из видео в видео и из обычной в видео, что тоже существенно ускоряет отображение нарисованного невидимого буфера на экран, но эта поддержка используется и GDI при копировании битмапов, так что накладные расходы от варианта рисовать в битмап и копировать через GDI относительно невелики.

Прямой доступ к видеопамяти в винде это как раз DX 2-7 (их интерфейсы полностью доступны в старших версиях) или DirectDraw в DX>7, но имхо DX7 удобнее в применении и лучше дружит со старыми машинами (если это конечно актуально). После получения этого доступа уже никаких посредников нет, есть только удобные сервисы для переключения\копирования поверхностей и т.п. полезности. А в разных ОС работа с массивом есно одинакова, отличаются только способы его размещения в видеопамяти или копирования туда.

массив он и есть массив даже если он в видеопамяти тут уже только твой алгоритм отрисовки скорость задаёт.

max7C4

В большинстве случаев да, но иногда во что-то полезное и вырастает в любом случае это шаг к дзену

 

АП = адресное пространство. буфер = многа байтов

эт в гугл. примеров реализации у меня нет, так как тема мне не особо интересна

 

Freeman

http://wasm.ru/forum/viewtopic.php?pid=201485#p201485

 

исчо один довод в пользу того, что прямой доступ к видеобуферу - ненужное усложнение проги, в которой можно без этого обойтись

 

[offtop]
Это мне всё напоминает что-то вроде - "хочу, сам не знаю чего" или "стой там иди сюда".
ТС желаю хорошо учиться, и всяческих успехов.

 

Zhelezka
Все шины рассчитаны на пакетную передачу данных. А это значит что обращение к видео памяти будет медленее нежели чем работа с оперативной памятью. А вот копировать я считаю лучше через BitBlt не жели ручками.

Если ваша видео карта поддерживает шейдоры, то на них быстрее всего. Даже самый современный проц Nehalem держит 10-15 FPS. И то неясно что-там за спец эффекты.
Лично моя видеокарта не поддерживает шейдоры. Только комбини регистрс, а на них далеко не уедишь.

 

Если рисовать самому в bitmape то не BitBlt, а StretchDIBits. Если не нужно преобразовывать глубину цвета, то скорость такая же как в BitBlt (аппаратное ускорение есть). Если глубина цвета буфера и экрана отличается то скорость конечно падает, зато не нужно думать над алгоритмом преобразования

 

Y_Mur
тут я согласен, но не все это осилят
Zhelezka
А Вы уверены что потяните написание этих алгоритмов с нужной точностью и возможностями. рисование попиксельной линии это одно дело, а вот написать какой-нибудь antialising - это честно говоря не тривиальная задачка, после чего может очень сильно отпасть желание писать дальше. к тому же если вам на Си не хватало скорости, то и на ассемблере не хватит. Си достаточно хорошо оптимизирует внешние вызовы и доступ к памяти (другими словами, учесть все особенности архитектуры, которые учитывает компилятор, на ассемблере в ручную - это очень долго)! беритесь уж тогда писать сразу игру без системы вообще. вот там-то действительно вся скорость Ваша и на масдай не пожалуешься.

 

max7C4
Все Hi level компиляторы включая С++, не важно оптимизируют FPU код, да и в целочисленных алгоритмах можно кое-что на асме оптимизировать. Имхо как раз библиотеки графических функций лучше всего делать на асме, ибо кросплатформенность тут не критична - буфер памяти он везде буфер, а процессор семейства x86 настолько распространён, что вполне заслуживает привязанной к нему графической библиотеки ) А в скорости (которая в графике очень желательна) можно хорошо выиграть. Даже если ТС не создаст свою игру этот опыт даром не пропадёт и когда нибудь пригодится, если и не по прямому назначению, то как ступень в поисках просветления в дзене )

 

max7C4
Си ничего не оптимизирует. Оптимизирует компилтор и программист. Переписав алгоритм можно выиграть в 1-8 раз, а то и больше. А переписывание на ассемблер даст еще 2-4 раза. Сравнил оптимизацию визуал студию с Делфи. Разница чувствуется, но до человека далеко.