Скорость рисования и остальная скорость

[Beermonza]

Ulex, хе-хе, ну, грешить на игру и делать выводы, что она недостойна внимания только из-за повышенных системных требований, в сравнении с имеющейся машиной, это как минимум глупо ...ну согласись. Я купил NFS III при Pentium'е 100 зная, что у меня будет машина по-мощнее, через каких-то там полгода. Это один момент, связанный с системными требованиями к игре, которая экономно расходует ресурсы, и немощность машины пользователя - обстоятельство из ряда вон выходящее. Второй момент с 2D, которая по определению не требовательна к ресурсам видео-карты. Любая 2D игра работает на машинах прошлого века без затруднений, того объема видео-буфера хватает для хранения спрайтов на игровой кадр и его изменение, дальнейшие загрузки оперативно производятся из оперативной памяти (ОЗУ). Значит, дело в кривых руках разработчика, как максимум, и как минимум недостаточная оптимизация кода, по большей части в работе с графическими данными.

[Ulex]

Так я почти про это и говорю. Очень странны такие повышенные требования. На этом компьютере идут без тормозов CS1.6, Квака 3, а какая-то плоская свистопределка (это я про свою программу) грузит его под 100. Может быть конечно дело в моих кривых руках, но обычный BitBlt области 800*580 по таймеру 20 мс грузит процессор на 33%.

Второй момент с 2D, которая по определению не требовательна к ресурсам видео-карты. Любая 2D игра работает на машинах прошлого века без затруднений, того объема видео-буфера хватает для хранения спрайтов на игровой кадр и его изменение, дальнейшие загрузки оперативно производятся из оперативной памяти (ОЗУ).

А вот этого немного не понял, если речь пошла про видеобуферы и про ресурсы видео-карты, то тогда мы говорим не про GDI. И тогда безусловно этот компьютер потянет любую 2D игру.

Но тогда повторюсь:

Сможете причаститься к прямому выводу графики (через HDC и пр.) - забудете о тормозах отрисовки.

Это заблуждение. Забудете о тормозах на мощных процессорах с памятью не ниже DDR SDRAM.

[Beermonza]

Сообщение от Ulex

А вот этого немного не понял, если речь пошла про видеобуферы и про ресурсы видео-карты, то тогда мы говорим не про GDI. И тогда безусловно этот компьютер потянет любую 2D игру.

Любой вывод графических данных требует наличия хоть какого-нибудь графического адаптера. Того объема видео-буфера (видео-памяти с содержанием страниц и разверток, области хранения графических данных) достаточно для 2D. Не совсем старые видео-карты уже имеют аппаратные средства ускорения обработки и вывода графических данных. Если мы говорим о компах прошлого века, годов с 95-х начиная, то аппаратные возможности у них уже имелись (и OpenGL и DirectX).
BitBlt тоже требует контекст устройства, в которое будут отправлены данные. Вот только применять вывод этим методом нужно в самый последний момент, когда кадр уже готов. Собирать кадр нужно в ОЗУ быстрыми методами, используя указатели и копируя сразу участки данных из буферов текстур в буфер подложки.
Ошибка может крыться в излишней цикличности, или выполнением одного и того же кода, который можно вынести за цикл перебора пикселей, оставив только переменную, которая является решением этого повторяющегося кода. В общем, глубокой оптимизации подлежит все и вся, касающееся графики. И с самыми быстрыми методами можно загнать комп, как говорится в силовой электронике - в насыщение.

[Ulex]

Не совсем старые видео-карты уже имеют аппаратные средства ускорения обработки и вывода графических данных. Если мы говорим о компах прошлого века, годов с 95-х начиная, то аппаратные возможности у них уже имелись (и OpenGL и DirectX).

Имелись, только достучаться до них средствами GDI наверное не получится. Вот у вас получится средствами GDI создать текстуру именно в видеопамяти? У меня - нет.

Собирать кадр нужно в ОЗУ быстрыми методами, используя указатели и копируя сразу участки данных из буферов текстур в буфер подложки.

Так я вам про это и твержу. Вы априори считаете, что ОЗУ - это скорость. Это не так. Это стало так с появлением памяти DDR (DDR SDRAM производительней обычной SDRAM минимум в 2 раза). Я же привёл пример - обычный BitBlt (я вообще ничего с DIB секцией не делаю, ничего в неё не копирую). Просто в таймере на 20 мс тупо выводится DIB секция чуть более чем в половину экрана по площади. И это безобразие загружает систему на треть. Если я сделаю секцию размером 1024*768 (типа Full Screen), то надо полагать загрузка будет 66%. О какой скорости тут можно говорить? При этом видеокарта совершенно не загружена. А видеокарта FX 5200 - как бы грешно её не загрузить, у неё на борту памяти чуть меньше чем во всей системе, да и память тактуется на 400 Мгц, а системнаю на 100. Вот только средствами GDI этого не сделать.

[.pixel]

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

[Beermonza]

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

Давай начнем с того, что...

первое: 2D не грузит систему как это делает 3D;
второе: GDI - библиотека ОС, и ее содержимое для вывода графических данных не требует аппаратной поддержки видео-карты, важен сам факт наличия адаптера, куда можно переслать данные, хранящиеся в ОЗУ. Слабым звеном будет пересылка данных из ОЗУ в видеопамять. Поэтому функция GDI BitBlt вызывается один раз в самом конце, когда изображение готово.
третье: начиная с Celeron 300А (я разогнал до 450) в процессорах Intel поддерживается технология MMX, что это такое, читайте на страницах Интернета, ...вкратце, это возможность использовать специальные регистры емкостью по 8 байт, т.е. обрабатывать пакованную графическую информацию по 8 байт за такт.
четвертое: видео-память предназначена для хранения часто используемых данных, которые применяются при аппаратной обработке и методах преобразования и вывода графики. GDI не использует аппаратные средства, все графические данные хранятся в ОЗУ, в ней обрабатываются и в финале передаются в видеопамять на отображение.
пятое: любая старая видео-карта, и не совсем старая, не позволит хранить достаточное число не маленьких спрайтов отличного качества. Например, только одна подложка 1200х800х24bit весит 2,7М, а таких буфера 2, один - сборная подложка, другойу - буфер кадра. Одно анимированное дерево 450х500х24bit весит 7,8М, кроме того альфаканал занимает столько же, только для того, чтобы MMX брал пакованные данные параллельно по 8 байт сразу, это в 6 раз быстрее самых быструх методов манипулирования графическими данными. Вот у меня графических данных для построения финального кадра набирается под 100М, с учетом подготовки на каждую локацию банка встречающихся текстур, с учетом 4-х слоев вывода, с 30 fps, и все это берет от 7 до 18 % моего Core 2 Duo 1,8GHz ноутбука, у которого видеокарта не нагружена никак. Я пробовал делать тоже самое на DirectDraw, на котором работало большинство отличных 2D игр, но мой метод быстрее почти в 10 раз, ...я даже написал самую быструю процедуру загрузки текстур в surface. Делал проект даже на OpenGL но получил максимум 28% загрузки, притом, что изображение заметно размазывалось работало без тормозов, но грузило процессор, ...вернулся к своему методу, он пока самый приемлемый.

На заметку, ...старые игры грузят современные системы под 100% по диспетчеру, но при этом тормозов не наблюдается.

[Ulex]

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

Вы меня либо не слышите, либо не хотите слышать. Я не говорил, что невозможно создать быстрый код без аппаратных средств видео карты. Я просто категорически повторяюсь - скорость вашего кода на GDI со всеми MMX очень сильно зависит от аппаратуры, даже больше, чем скорость кода на DDraw. Вот только аппаратура другая - память и системная шина. А исторически так получилось, что память и шина видеокарты были быстрее, чем системные (DDR память впервые начали применять на видеокартах).
Т.е. вы целеноправленно ограничили свою аудиторию счастливыми обладателями четвёртых пеньков и аналогичных машин (кстати, не знаю как там с PC133, может на ней лучше чуток будет). А как вы будете на коробке системные требования писать (мин тр. - память DDR2). Как пользователь будет ориентироваться, покупать ему эту игру, или ему ещё и компьютер надо к ней новый купить. Большинство пользователей знать не знают какая там у них память в системе стоит.
Представьте себе удивление такого "игрока". Ну как же, у него "летают" всякие 3D игрушки, а по сути плоская игра кое как шевелится. Примерно такое было моё удивление, когда я запустил эту свою поделку на Celeron-e. Ну как же на P4-2D(3GHz) эта мухорайка грузила проц максимум на 6%, а на Celeron-e просто застрелилась. EPIC FAIL

Ну и по порядку:

2D не грузит систему как это делает 3D;

2D на GDI будет грузить эти конфигурации гораздо сильнее чем 3D на DX.

GDI - библиотека ОС, и ее содержимое для вывода графических данных не требует аппаратной поддержки видео-карты, важен сам факт наличия адаптера, куда можно переслать данные, хранящиеся в ОЗУ

Не требует аппаратной поддержки видео-карты, но требует быструю память и широкую шину.

начиная с Celeron 300А (я разогнал до 450) в процессорах Intel поддерживается технология MMX, что это такое, читайте на страницах Интернета, ...вкратце, это возможность использовать специальные регистры емкостью по 8 байт, т.е. обрабатывать пакованную графическую информацию по 8 байт за такт.

опять таки скорость MMX операций зависит от процессора, памяти и шины. И, кстати, регистры MMX - это регистры FPU со всеми вытекающими.

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

Это является плюсом, когда память быстрая. И минусом, когда она медленная.

Кстати, давно хотел спросить. Раз вы используте MMX регистры для копирования bitmap_ов, ширину картинки как то приходится нормализовать. Т.е. если за одну операцию я к примеру формирую две точки (пусть у меня глубина 32-бита), значит ширина картинки должна быть кратна 2? Или необязательно?

[Beermonza]

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

Сообщение от Ulex

Это заблуждение. Забудете о тормозах на мощных процессорах с памятью не ниже DDR SDRAM.

ZotaC программирует в Delphi, изучает OpenGL, если опять посмотреть на старые компы, видеокарта у них никакая, я уже описал пример того объема памяти что понадобится для хорошей 2D, только не для 640х480 и не для 800х600, на дворе 21 век, как уже сказали выше и ЖК широкоформатные мониторы. Что остается? ...организовывать постоянную динамическую связь "ОЗУ <-> видеопамять"? ...оно будет тормозить жутко, эффективнее будет выполнять пересылку готовых кадров. Заметь, мы современные компы не трогаем пока, все об "старичках".

Смотрим на средства, предлагаемые ОС. Из среды Delphi можно достучаться до них через Canvas, ...тормозно да? ...да, 100% загрузка, или в лучшем случае 80% (ограничение на 30 fps для 2D, 1024х768х24bit). Смотрим дальше, ...создание динамических массивов, обращение к ним по указателям, двойной цикл на отрисовку изображения из источника в приемник. Это быстрее "канвы", на слабой Целке 450 работает быстрее на десяток процентов. Что-то не шибко радует. Что делать? ...смотрим команды Delphi, находим CopyMemory, применяем, радуемся, что еще 10-15% скинуто.

После нескольких дней и увеличения нагрузки в виде дополнительного качества и большего числа объектов начинаем придираться и к этому расходу ресурсов. Копаем модули среды, находим, что CopyMemory ссылается на Copy, эта на Move, а последняя на код на ассемблере. Выдираем кусок на asm'е и кидаем в проект. Офигеваем от производительности и падения нагрузки на CPU, в режиме переброса подложки в буфер кадра.

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

Вроде все, ...но, хочется добить. Смотрим алгоритмы обработки объектов, замечаем кучу статики в выводе графики в буфер кадра, ...думаем как бы уменьшить вычислительную нагрузку. Видим в цикле по-Х вычисление, которое можно вынести за цикл, а вместо него ставим переменную с рассчитанным значением, ...радуемся падению нагрузки. Мыкаемся со всем кодом, то и дело находя "узкие места", оптимизируем, ...на неделю все устраивает, занимаемся геймплеем.

Постепенно добавляется интерфейс, еще больше объектов, больше эффектов, снова "шило" не дает покоя, нужно что-то делать. Начинаем рыть код. В формулах смешивания компонент цвета пикселей замечаем деления на кратные 8-ми числа, заменяем сдвигами, ...снова радуемся падению нагрузки. На время все устраивает. Затем переходим на тип динамического массива PChar, сами выделяем и сами освобождаем память, используем арифметику адресации указателей, ...снова видим падение нагрузки. Вспоминаем что было раньше, какое было качество и сколько объектов и как все тормозило, если в теперешний код засунуть те начальные требования и качество, комп будет сидеть на 20% загрузки, ...но нет! ...нужно качество и 1024х768х24bit. Режим монитора конечно 32, но битмапы используем RGB + отдельно альфа-канал 8-bit, зачем? ...картинку альфа-канала обработать эффектами быстрее, чем когда она "зашита" в битмап (пустые п
иксели заполнены с PNG).

[Beermonza]

...продолжение

Казалось бы вот все, быстрее не будет. Появляется мысль заменить циклы перебора пикселей на asm-вставки, ...копаем Интернет, кругом все намекают "рехнулся дядя, есть же OGL, DX", раз спрашиваю, значит нужно. Находим помощников на этом форуме и копаем, копаем, копаем. Наконец получается "быстрейший" код на asm'е, меняем все циклы на него, ...офигеваем, но не на столько, чтобы совсем )) ...натыкаемся на описание чудесного "MMX", понимаем, что это может решить все проблемы. Опять не без помощи этого форума создаем самый быстрый код отрисовки в буфер кадра. Делим изображение на две одинаковые по размеру обрасти, в первой храним RGB, а во второй AAA, т.е. полный альфа-канал, которым можно задать не только прозрачность пиксела, но и степень прозрачности отдельных его компонент, ...зачем? ...чтобы еще кроме того брать сразу по 8 байт изображения параллельно, не нагружая адресацией и вычленением альфы из полного изображения. Вот тут вроде и все, ...а возможно еще и нет, ...но то что получается рвет в клочья DirectDraw и не уступает OpenGL. Для того же "старичка" видео-карта остается не нагруженной, но работает очень хорошо, и не грузит систему как это делает Age Of Empires.

Вернемся к тебе, Ulex, ...верно утверждать, что два компа по разному обрабатывают данные от скорости шин памяти, и неверно - совершенно забывать, что один и тот же комп с ММХ работает в разы быстрее (с теми же данными) чем с обычными регистрами. То, о чем говорит Alex Cones, действительно самое эффективное решение для пользователя старой машины, как бы то ни было у него нет выбора, а у нас есть. Вот мой ноутбук и тот целерон Age Of Empires нещадно грузила на 100% CPU, с чего бы? ...OpenGL же вроде? ...или неверное понимание приоритетности? ...фиг знает. А моя программка до 18% в обычном режиме и до 30% в перегруженном состоянии, когда на экране 255 персонажей, ботов со своими характерами, каждый делает свои дела, и кроме того на одном ноуте еще и сервер, который все считает, ...я пока доволен.

Сообщение от Ulex

Кстати, давно хотел спросить. Раз вы используте MMX регистры для копирования bitmap_ов, ширину картинки как то приходится нормализовать. Т.е. если за одну операцию я к примеру формирую две точки (пусть у меня глубина 32-бита), значит ширина картинки должна быть кратна 2? Или необязательно?

Давай "на ты", чтобы на равных, уже не первый раз общаемся. Да конечно, нужно выдерживать кратность, но только 8-и, стараюсь делать текстуры кратные 8-и, если умножить ширину текстуры на битность (на 3). Если это не реально, то при загрузке выполняется алгоритм, который добавляет недостающие байты в строку пикселей, это может выглядеть странно без альфа-канала, остатки компонент рассыпаются по краям, зажигая крайние пиксели неестественными яркими цветами, но альфа-канал это все скрывает, записывая в себя нули.

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

Удачи!

[Ulex]

Хорошо, убедил (почти). Значит это у меня руки чем-то попахивают.

Два момента только осталось.
Момент первый - вопрос:
-Какая в твёрдом остатке получилась загрузка Целерона (18 и 30 - это я так понял на Core 2 Duo)?

Момент второй - просьба (приогромная):
-Тест хочу. Там делов на пять минут (ну ладно, на 10). Просто картинка разрешением 1024*768, по которой вправо-влево ползает десяток другой картинок (одинаковых, неанимированных). Всё это рендерится по таймеру 20 мс. Очень хочу увидеть это чудо своими глазами. Ну пожалуйста.. Ну пожалуйста..пожалуйста. Ну а чего, жалко чтоли.

Вот мой ноутбук и тот целерон Age Of Empires нещадно грузила на 100% CPU, с чего бы? ...OpenGL же вроде? ...или неверное понимание приоритетности? ...фиг знает.

Кстати, да. Была такая мода. Даже в книжках по DX очень часто писали, дескать рендер должен выполняться всегда, когда программа не делает ничего другого. Даже примеры приводили специально извращённых циклов обработки сообщений, с выходом по idle. Ну зато у таких программ FPS получается забубенный (у меня до 3000 дело доходило по старой памяти). Хотя опять таки VSYNC мог всю эту производительность обломать.