С чего начать программирование графики на ассемблере?

у меня на нетбуке на GMA950 (intel GM945) получилось в линейную память писать не из под винды - из PM.
Все не так уж сложно как кажется сначала - но это конечно с документацией.

 

Treant

Но прямая запись в видеопамять -- это мелочь, по большому счёту, ведь всю работу выполняет ЦП, а ГП стоит без дела. Задействовать же всю мощь ГП куда сложней.

 

Мы работаем над этим (с)

 

Treant

Верной дорогой идёте, товарищи (с)

 

а должон пдп. но это очень очень старая мысль. давно не повторял попыток. счас все по-другому.

 

> Ну а полноценная поддержка ГП? Со всеми наворотами ДХ10-11?
ну я не говорил, что там всё хорошо
просто теоретически это возможно.

 

Какой смысл в Windows напрямую писать пиксели в видео память? Причём ещё ладно в видео-память, а в окошки? Если кодите под ОС, то смиритесь с тем что, вам всё придётся делать через её API. Таким образом вы и своё время не потеряете в пустую и программа будет переносима с компьютера на компьютер. Если хочется разобраться в программировании видео-карты - загрузитесь в DOS и напишите программу переходящюю в PM или Unreal Mode (чтобы вся физическая память была доступна) и уже работающюю с видео-картой. И учтите, что в винде вам будут мешать все кому не лень - и оконная подсистема перерисует окошко когда не надо, и видео-драйвер будет претендовать на доступ к видео-памяти. Вот что что, а прямую работу с видео-памятью программировать в винде смысла нет. Если вы конечно же не драйвер пишите для этой самой видюхи.

 

Давайте поставим вопрос немного иным способом. Есть монитор? Есть. Есть компьютер? Есть. И шнур, который их соединяет… По этому шнуру идут сигналы от компьютера до монитора. И если эти самые сигналы перехватить, то можно разобраться каким образом они устроены и потом генерировать эти сигналы вручную. То есть речь идёт о прямой работе с монитором, путем посылки ему сигналов. А уж каким образом их туда послать и как это лучше сделать – надо подумать. Мысль в целом ясна? Прямая работа без посредников. Остаются ещё некоторые нерешенные тонкости, но о них позже.

 

assemblerist
Я так понимаю, в один порт пишем сигнал который меняется во времени? Вы хотите взять на себя работу железа по синхронизaции? Это конечно прикольно, но без аппаратной поддержки это будет криво и трудно. Нужно будет получать много обратной информации от монитора, причём очень аппаратно специфичной.

 

assemblerist
640х480х60=18 432 000 Гц Для вашего монитора нужна частота 20МГц минимум. А вот чтобы современное разрешение выводить. 400МГц

Есть документация.

Booster

Что за бред. Не нужно получать обратно информацию. Хотя кое какие данные с монитора считываются они задокументирована раз во вторых не обязательны.

 

Pavia

Только вроде напрямую управлять видеовыходами никакой возможности нет (поскольку это на практике нафиг не нужно, всем должен заниматься графконтроллер). Или есть?

 

Pavia

Согласен, бред. Но тема сама по себе бред. ^)

 

SII

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

 

Если у тебя нет ОС, то ради бога. Если у тебя есть Windows, освой ДиректХ - там в конце-концов все можно свести к записи пикселей. Не совсем в видеопамять - но куда-то, что системой будет перекинуто в видеопамять. То есть - а) инициализация всего что надо, б) работа с пикселями в) отображение на экране. Вообще не понимаю смысла треда. Ну скажите мне ЗАЧЕМ в Windows выводить графику напрямую? Самому? Это даже если и возможно, по уровню гемороя сравнимо с написанием своей ОС. Графика всегда была самым "лакомым кусочком", верно. Я сам начинал исключительно с графики. И вот если речь о реальном режиме, портах видеоадаптера, и выводе точек - тут уже все непросто, при больших разрешениях, выше чем 320*240. А уж далее... Возьми МенуэтОС - режим устанавливается через SVGA, система потом максимум выводит точки (ок, пишет байты в видеопамять), используя svga-совместимость, и никаких функций аппаратного ускорения. "Круче" без детального мануала от производителя видеокарт сделать невозможно. А производители делиться не спешат.
И в том же OpenGL не исключается работа с памятью - рендери в память, потом изголяйся над ней как хочешь, потом отражай на экран. Перефразирую вопрос, чтоб абсурд был очевиден:
"У меня есть танк. Он ездит, стреляет и вполне в приличном состоянии. Как из старых велосипедов сделать почти танк, не используя частей от танка, чтоб по проходимости, броне и огневой мощи... Ну вы поняли." Вот если бы у тебя НЕ БЫЛО танка, вопрос имел бы смысл - как на велосипед прикрутить что-то, чтоб он хоть как-то напоминал танк )

 

> Есть монитор? Есть. Есть компьютер? Есть. И шнур, который их соединяет…
в этой схеме не хватает видеокарты.
или ты хочешь свою железку спаять?

 

Прямая работа с монитором на мой взгляд наиболее эффективна. Предположим нужно вывести один пиксель на экран, соответственно используешь функцию SetPixel(), но беда в том, что она тормозная. Тогда… что вы делаете? Берёте и перехватываете сигнал SetPixel’а и генерируете его уже напрямую без всяких нагромождений. Видеокарта, конечно же, нужна. Как без неё. Но об этом потом. Пока что нужно научиться перехватывать сигнал, предназначенный монитору и заносить, скажем, в память, чтобы далее сгенерировать его повторно, но уже напрямую без “одна функция вызывает другую функцию”. Короче говоря, речь идёт о работе с конечными потоками, потоками сигналов, если уж на то пошло.

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

 

В общем, бред-с.

 

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

влиять на это нет необходимости - была и остается вероятность повредить оборудование

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

основная проблема - быстро пересчитать значения этого массива - для сего придуманы всякие графические процессоры

 

Это уже интересно. Каким образом можно получить прямой доступ и контроль над видеопамятью с учетом встроенных возможностей графических процессоров? Мне бы не помешал собственный графический пакет на подобие DirectX или OpenGL со своими специфическими функциями. Брать готовые графические инструменты и приспособлять их под свои нужды не считаю в достаточной мере обоснованным, поскольку это отчасти неудобно и ведёт за собой частичную потерю производительности.

 

Если это GDI, то таки да, используем SetPixel. Но если нам надо быстрее (а GDI в целом не шибко быстрый) - то пишем все то же на OpenGL-DirectX, и получаем (внимание!) максимальную скорость. Сравни чисто на уровне скорости раскрытия окон KDE, оболочки от MacOS и винду - винда быстрее. Это все потому, что ... производители карт уже написали под нее самые удачные драйвера. А если до игрушек доходить, не будет у тебя никогда, хоть на трижды ассемблере, не используя АПИ, производительности выше, чем под директХ.