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

[Beermonza]

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

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

За Целерон на текущий момент я тебе точно сказать не смогу, поскольку слишком много компов на квадратный метр, я его на середине проекта продал за символическую цену. Далее тестировал на Pentium 4 3GHz и на ноутбуке. С тех пор буфера стали 1200х800, объекты укрупнились, расчетов стало больше. По памяти помню, с буферами 1024х768 с деревьями в 3 раза мельче и без анимации, без второго слоя почвы, без внешнего слоя индексов, без интерфейса, тогда с тормозов и загрузки 100% дошел до отсутствия тормозов и загрузки 100%, затем до 87%, затем 70% с копейками, 68%, и где-то так осталось только в результате оптимизации кода и за счет перехода на тип PChar. Постоянно поднимал планку качества, и загрузка колебалась на уровне 52-68%. Там с диспетчером задач не расставался, на уровне паранойи уже и погони за цифрами. Далее Целерон ушел в хорошие руки я сел за Пень 4. На нем практиковал ассемблерные вставки и MMX тоже испробовал на нем. Загрузка 28-45% (эмуляция двух ядер) в нормальном режиме, ...на ноутбуке 7-18% (два ядра).

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

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

Вот может и вариант увидеть работу MMX на "старичке". Подумаю на счет этого. Одно знаю точно, вся информация по MMX изученная, в основном на момент 1997-2001 гг. У тебя какого года "старичок"?

[Tronix]

Могу протестировать на следующих олдскул-писи:
1) iP 233Mhz MMX/64 RAM/S3 Trio64V+ 4Mb/Windows 98
2) Celeron 433Mhz/128 RAM/Geforce 2 MX440 64Mb/Windows XP SP3

Но что-то мне подсказывает, что та же самая демка, двигающая по экрану 20 битмапок туда сюда, на OpenGL будет заметно быстрее, чем на канвасе (GDI).

[Ulex]

Вот у Tronix_а вторая машина - очень хороший вариант для тестов.

У меня года где-то 1998-2001 выпуска:
-мамка Abit BE 6-2.
-Частота FSB - 96 MGz
-Частота CPU ~1250 MGz (Celeron-Tualatin)
-Память PC100 SDRAM 256Мб
-Порт AGP 2X
-Видео GeForce FX 5200 (сколько памяти не помню - то ли 128, то ли 64)

[Tronix]

Ах да, забыл еще, для совсем экстремальных тестов есть еще такое:
80486 DX2 66Mhz/32 RAM/Tradent 9000C 512Kb ISA/Windows 95

Но это как сами понимаете без MMX, да и 1024x768 не потянет. Там вроде 800x600x8bit (256 цветов).

[Beermonza]

Tronix, хе-хе, "дед сто лет" не понадобится, а вот "старичок" вполне подопытен.

Во вложении тест программа, интуитивно разберетесь с управлением. Память выделяется командами GetMem и чистится FreeMem после уничтожения формы, т.е. мусора не оставляет. Данные теста желательно выписать в виде списка, примерно такого:

Процессор: Intel Core 2 Duo 1,8GHz/800MHz
Память: DDRII 2048 Mb
Видеокарта: Intel Graphics Media Accelerator X3100
Операционная система: Windows Vista HP

10 объектов, 20 мс - 4-6% CPU
253 объекта, 20 мс - 7-18% CPU

Если тормозит и с 1-м объектом, только с деревьями, понижайте интервал таймера. У меня постоянно стоит 31 мс, этого достаточно для анимации. Нащупайте приемлемые варианты, без тормозов хотя бы для 100-тни объектов, и сколько должен быть интервал таймера, чтобы загрузка была в районе 50% для "старичков".

[Ulex]

Я не понял, как связан параметр "интервал" и интервал рисовальщика?
Почему интервал стоит 20 мс, а FPS получается 32, должно же быть 50?

Вот такая зависимость странная:
10мс - 64 FPS (а надо 100)
20мс - 32 FPS (а надо 50)
30мс - 32 FPS (то что надо)
40мс - 22 FPS (а надо 25)
50мс - 16 FPS (а надо 20)

[Tronix]

Интервал - это интервал таймера. Отрисовка происходит в процедуре таймера. Увы, но 64 FPS - это максимум, что можно выжать если рисовать через таймер с интервалом 1 (минимальным). Больше хоть ты тресни, но не получится, потому как таймер быстрее не обновляется. У меня тоже с интервалом 1 - 64 fps дает.

Это как-бы не правильное тестирование. Делать нужно не через таймер, а через отдельный поток, вот тогда мы сможем увидеть реальную максимальную fps.

UPD: В потоке можно в конце поставить Sleep(1), чтобы поток не грузил сразу процессор на 100%. Даже с этой задержкой в конце, поток будет выдавать около 300-400 fps, заместо 64 при таймере. Это разумеется на моем компе. У вас может быть совсем по другому, например будет 1000 fps, если комп какой-нить последний интеловский.

[Ulex]

Больше хоть ты тресни, но не получится, потому как таймер быстрее не обновляется. У меня тоже с интервалом 1 - 64 fps дает.

А почему при больших значениях интервала, FPS всё равно отстаёт от правильного?

Делать нужно не через таймер, а через отдельный поток, вот тогда мы сможем увидеть реальную максимальную fps.

А зачем максимальную. Я просто хочу увидеть нормальную (управляемую таймером) FPS и оценить загрузку CPU.

[Tronix]

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

А почему при больших значениях интервала, FPS всё равно отстаёт от правильного?

А что такое "правильный" fps? Откуда вы взяли цифру 100 и почему она "правильная"?

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

А зачем максимальную. Я просто хочу увидеть нормальную (управляемую таймером) FPS и оценить загрузку CPU.

А что такое "нормальное" fps? Вот для крестиков-ноликов, скажем, я считаю нормальным и достаточным значения 0.5 - 1 fps. Для гонок/шутера - от 60 fps и так далее.

Все дело в том, что завязывать на таймер рендер и непосредственно этим же таймером регулировать этот рендер - не правильно. В этом случае на мощьных ПК мы достигнем предела в 64 fps и тут казалось бы все ок. Но ситуация резко меняется, когда мы имеем дело с маломощьным ПК, который не успевает за интервал в 1 мс (на самом деле около ~55 мс) просчитать всю логику и рендер и вывести все это на экран. Поэтому происходит резкий спад: во-первых самого FPS, а во-вторых всей логики в целом, потому как она завязана на этоми проклятом таймере.

Поэтому выход только один - рендер и логику уносить в отдельный поток (а лучше два - один для непосредственно рендера, другой для логики), который будет молотить так быстро, на сколько позволяет процессор, а не упираться в интервалы. При этом можно использовать таймер для одной единственной цели - синхронизировать FPS до минимально нужного игре. Ну например если у вас очень быстрый проц и без задержек у вас рендер идет с 5000 fps, то таймер позволит ограничить скажем до 60 fps. Не больше не меньше. А в случае медленного процессора когда он без задержек и таймеров выдает скажем всего 40 fps (а если в таймере - то все 20), то точно также происходит синхронизация с той лишь разницей что ограничивать ничего не нужно. Предоставляем потоку все ресурсы которые смогли выжать.

[Ulex]

А что такое "правильный" fps? Откуда вы взяли цифру 100 и почему она "правильная"?

Ну как откуда, если рисовальщик работает с периодом 20 мс и успевает за это время нарисовать всю сцену (производительности хватает), то за одну секунду сцена будет нарисована 50 раз. Т.е. FPS должен быть равен 50. А если он меньше, значит процессор не успевает. Это как раз и будет говорить о тормозах. Но не для данного теста. Тут я пока не понял как работает таймер. Тут похоже какой-то свой таймер для рисования есть. Тогда не понятно интервал чего я задаю в конечном итоге?

А что такое "нормальное" fps?

Нормальное - значит соответствующее установленному мной периоду.

Все дело в том, что завязывать на таймер рендер и непосредственно этим же таймером регулировать этот рендер - не правильно. В этом случае на мощьных ПК мы достигнем предела в 64 fps и тут казалось бы все ок. Но ситуация резко меняется, когда мы имеем дело с маломощьным ПК, который не успевает за интервал в 1 мс (на самом деле около ~55 мс) просчитать всю логику и рендер и вывести все это на экран.

А если не успеет, то я это сразу увижу, потому что заявленный мной период таймера будет не соответствовать получившемуся FPS, это и будет означать что для данной частоты обновления тест не пройден.

Кстати, Tronix, пробовал на Целероне запускать?
А то у меня вот чего вышло: