программирование демок без dx/ogl

здарова всем!

-------------

кто-нибудь может поделиться хорошими линками на доки по демомэйкингу для чайников на асме под винду БЕЗ применения сторонних библиотек ака опенжл, директикс и др? или этого хотеть ненормально?

типа, как в старом досе - только порты и работа с ними. и никаких библиотечных надстроек. применяя термин, основательно прижившийся на всем васме, хочется научиться работать с графикой на асме 'ДЗЕННО' 8-0.

в общем, хочется научиться писать НАСТОЯЩИЕ демки, а не юзанью библиотечных функций с той лишь разницей, что юзать их на асме, а не на Си++.

буду рад конструктивным мнениям, комментариям, етк.

 

varnie >

DX - это не стороняя библа, а часть ОС. IMHO вполне дзенно использовать IDirectDrawSurface::Lock() и потом рисовать без библиотечных ф-ций.

 

varnie

хочется научиться писать НАСТОЯЩИЕ демки, а не юзанью библиотечных функций

=)) а ты получишь аппаратное ускорение?

 

поскольку интересует програмирование под виндос, исправлю неточности из FAQ по первой ссылке выше:



>

Можно: IDirectDraw::GetScanLine()

хотя есть небольшая вероятность, что вернёт DDERR_UNSUPPORTED :-(



>

метод сейчас не пригодный (и возможно неточный из-за возможной интерференции частот таймера и развёртки)

Для этого существует IDirectDraw::WaitForVerticalBlank()



>

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

Это в теории. На практике мои тесты показывают, что даже movntq в видеопамять даёт скорость в 2-3 раза меньше чем в обычную память (на GF2 и R8500)





jekyll >

использование библиотечных ф-ций этого не гарантирует

не везде оно есть :-/

 

varnie, ищи Hornet Archive (на scene.org), и страницу hetero (SAC/Razor1911) - там много полезных сорсов и доков

 

всем спасибо за ответы, буду разбираться...

 

S_T_A_S_

использование библиотечных ф-ций этого не гарантирует

Да, но дает надежду на это, и интерфейс программирования видяхи.



Лично я не видел ни одной работы под ДОС, которая использует мощь видяхи хотя бы на 80%.

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

 

varnie

хочется научиться писать НАСТОЯЩИЕ демки



Слушай, не написал не одной работы а уже делишь демки на настоящие и ненастоящие. Крутые работы бывают и в хардварных демках и в софтварных. А так же и дерьмо есть и там и там. Напиши для начала хоть что-нибудь. Может лишние вопросы отпадут. Вот тебе мое конструктивное мнение.

 

jekyll



Ну не все же хотят шейдеры, может цель создание чего-то oldschool, как здесь

К тому же, IMHO лет через 5 шейдеры вымрут, как когда-то это сделали Adlib/OPL, а затем и GUS с SB AWE





_DEN_ >

Дык человек хочет научится, а ты сразу наехал ))

 

S_T_A_S_

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

Ну вот мне интересно, что за идиотское мнение по поводу того что графика на платформе это "уже не то"? Я не понимаю, из-за этого OpenGL математика что-ли поменялась?



varnie

Это похоже на то как 8-ми классник рассуждает, кто в постеле лучше, блондинки или брюнетки. Возьми учебник по геометрии, напиши на MoveToEx - LineTo перспективное проецирование. Потом растеризация и закраска. Для начала. Думаю уже тут переосмыслишь свое деление на нормальные и ненормальные демки.

 

_DEN_ >

Ну вот, как я люблю флейм :О)

Конечно же вымрут, я напрягая память, вспоминаю те времена, когда мой свежеприобретённый AWE64 ввергал в чёрную зависть обладателей всяких там ESS1868 =) А что сейчас? любой AC97 кодек запросто справляется с синтезом, несильно при этом загружая проц.

А если напрячь ещё сильнее, то вспоминаю, как я припаял AY8912 к спектруму - какой это был прогресс по сравнению с бипером =)



Видеоускорители первого этапа уже почти вымерли (это те, где нет шэйдеров - аналог FM синтезаторов)

Теперь 2й этап - шэйдеры (это аналог всяких там "сопроцессоров" вроде GUS)

Но и они вымрут, когда производительность процев ещё чуток поднимется.

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



Весовая категория немного не та: nVidia не сможет тягаться с монстрами вроде Intel когда те запустят новую маркетинговую компанию "вместо видеокарты за 800$ приобретите 2 проца Pentium6, вы получите отличную графику за меньшие деньги, к тому же и word 2008 не будет тормозить"

Ведь всё идёт к тому, что GPU становится всё больше похож на CPU, а теперь внимание вопрос: "на кой мне 2 CPU, если один из них работает только в играх?"



Да вспомни Amiga, по сравнению с которой графика на писюке была полным отстоем, но кто победил?



>

У меня как у чайника вопрос, а как сделать туже плазму средствами OGL?

 

Это полный ЧЕС ! Да ЖПУ (гы гы, по русски звучит прикольно) - это тот же самый ЦПУ но заточенный под графику ! Зачем ЦПУ знать как рисуеться примитивы ? Шейдеры отомрут тока когда пойдет пик аппаратных рейтрейсеров (но это вовсе не маркетинговый ход, сейчас тех. базы нема для этого... хотя вот если ДСП впарить туда), и полигоны остануться не у дел... И вообще, ты хоть в курсе что такое шейдеры ? По ходу нет... А ЖПУ и ЦПУ отличаються ровно настолько насколько IA32 и DSP

 

S_T_A_S_

Во многом согласен с tylerdurden. Процессоры, ориентированные на конкретные задачи всегда будут круче универсальных.

1. Шейдеры.

2. Сетка + игра текстурных координат.

3. Сетка + 3D текстура.

4. Сетка + Cubemap.



Далее, учитывая логические пиксельные операции, трафарет, альфа-тест и альфа-бленд, поинт-спрайты и ... Вобщем способы ограничены лишь фантазией программера.

 

tylerdurden >

Ну вот видишь, ты сам согласен, что RT лучше, теперь представь что все инвестиции тратятся не на развитие технологий 8ми летней давности, а именно в этом направлении. тех база появится в 5 секунд





_DEN_ >

Да и пусть будут круче.



=========================================================

3 сокровища.



К учителю Япутре как то подошел купец Рбрбр и, желая испытать его, спросил: "Учитель скажи, какое из трех сокровищ самое ценное: мудрость, кротость или усидчивость?"

"Мудозвон ты, дундозвон! Главное - башли!!" - рассмеялся Учитель, обнял купца Рбрбра и попросил у него денег в долг.

=========================================================



Welcome to real world, _DEN_.



Никто, никогда не будет тратить 500$ на вещь, которая в 2 раза лучше делает что-то, чем худьший аналог, но за 2$ ("для понта" в расчёт не берём)



Ты не согласен? Ну где сейчас все эти "звуковые процессоры", которые, кстати, когда-то имели производительности на уровне CPU или выше. Вопрос только во времениб GPU так же умрут.



>

э-э-э, а если нет шейдеров, "купите новую видяху" ?

что, сейчас суперпозиция синусов уже не катит? Ах да, я забыл, GPU синусы как-то не очень хорошо считает :-(



>

IMHO ты перепутал фантазию и возможности аппаратного ускорителя, которые строго говоря ограничены некоторым множеством операций.

 

S_T_A_S_

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

Стасик, если ты так трепетно относишся к прадедовским методам 2D/3D графики, давай я тебе напишу твою любимую 2D-плазму на OpenGL, которая будет летать на самом мохнатом Savage 3D?



А по поводу RTRT... Честного RTRT...

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

 

Вот и плазма



Установить

#define SCREEN_X 800.0

#define SCREEN_Y 600.0

по вкусу



У меня проц загружен на 80-90%, но это именно CPU. GPU вобще не напрягается. Главный цикл никто не мешает переписать на асме так чтобы и CPU не напрягался Играйся с коэффициентиками и радуйся oldschool-ностальгии.



Да, самое главное За "полосковатость" прошу всецело винить вендоров, которые оптимизируют алгоритм Фонга нечеловеческими способами (с потерей качества)

1197523630__Plasma.cpp

 

А вот и быстрая плазма

Только она сначала долго думает, потому что все сначала просчитывает. Из-за этого в мозгах весит 16 метров И дергается каждые 10 секунд Но если правильно подобрать (читай посчитать) период - все будет гладко, так что и CPU и GPU теперь работают зевая в полусне



Если

#define GRID_X 32

#define GRID_Y 32



заменить на

#define GRID_X 64

#define GRID_Y 64



то подождать придется в 4 раза дольше, и весить мы будем 50 метров, зато картинка будет идеальной. Еще цвета надо было бы конечно на байтовое представление поменять, это снизило бы затраты оперативы в 4 раза, но уже лень Через полтора часа ехать в универ - допсу закрывать (а я тут плазмами балуюсь )

1264154786__plasma_fast.cpp

 

Хе-хе, вот я тормоз )

Плазма тормозит в debug-конфигурации. В Release со всеми оптимизациями (VC++ 2003) все летает, цветет и пахнет. Даже после увеличения разрядности сетки. Так что теперь еще и "полосоватость" пропала Да еще и float на unsigned char докучи поменял, так что по шине теперь в 4 раза меньше данных гоняется



Стас, специально для тебя, можно сказать в подарочной упаковке

_1758731795__plasma_fast_small_nice.cpp

 

_DEN_



Спасибо тебе за кучу сорцов, не стОило тратить время

Я про плазму к примеру сказал.



Но раз она есть, вот некоторые соображения:

1. Отсутствует синхра по кадровой развёртки, из-за этого ужасные горизонтальные репанья :-(

2. Как на счёт просчитывать синусы для каждой точки?

3. По моим замерам, на посторение одного кадра уходит около 50000 микросекунд! (AXP2000+ R8500) Это ОЧЕНЬ много. (тест в аттаче)



___________________________________________



Теперь обрати внимание как идёт спор:

1. я привожу некоторые аргументы (например, параллели со звуковухами), в пользу того, что ускорители через несколько лет вымрут. Ты же аргументов никаких не приводишь, только лишь "шейдеры rulez" и "CPU suxxx"

2. я отстаиваю свою позицию (конечно, не факт, что она верная, я могу очень запросто ошибаться)

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

Ы?

Рекомендую ознакимиться со статьёй Джоэля "Огонь и движение", это приоткроет для тебы завесу над загадочным миром M&M, что значит Might&Magic.. тфу, management&marketing.

_723487982__plasma_fast_small_nice.cpp