September 9th, 2007

nyaload

(no subject)

Прочитав это задумался: А как же лет через десять-пятнадцать будут запускать-эмулировать старые игры, если практически невозможно воспроизвести точное поведение видекарты? Которая не смотря на то, что очень старая, но обладает огромной сложностью (+ драйвера к ней). Сейчас я могу так или иначе запустить любимую DOS-игрушку в эмуляторе DOS/WmWare, могу запустить старенький Warcraft 2 которому нужен только VESA, старенький StarCraft которому нужен только ddraw. А что будет, если я захочу запустить через десять лет StarCraft 2, который на шейдерах, что на несколько порядков сложней блиттинга в ddraw? Кто будет заниматься эмуляцией тонкостей багов?


Возникают всякие странные мысли вроде D3D9 поверх OpenGL в софтварной Mesa GL :) или D3D9 поверх D3D 10 поверх D3D 15 поверх ... со всё возрастающей вероятностью багов (ведь шейдеры надо перекомпилировать с одного языка на другой, это непросто, есть тонкости с точностью вычислений и границами диапазонов).
nyaload

Повышение точности Sleep в Windows

Sleep можно сделать точней. В данном случае timeBeginPeriod(1) довёл его точность с +- 10% при паузе на 100 мс до +- 10% при паузе на 10 мс. Осторожно, это недокументированное поведение timeBeginPeriod, и оно глобальное на все программы в винде (то есть, другое приложение может его нам испортить). Так же после timeBeginPeriod() начинает точней работать timeGetTime и GetTickCount(). Работает ли под Вистой - не проверял. Есть ли там такая же проблема с глобальным состоянием timeBeginPeriod - не знаю. Ох и устроили же разработчики Windows/процессоров кучу тайного знания по тому, как измерять небольшие кусочки времени в играх или как сделать что бы не грузить процессор на 100% при FPS, когда мы нарочно его ограничиваем числом 60-100.

Кстати, timeGetTime(после повышения точности) - это одно из средств избежать глюков QueryPerformanceCounter на многоядерных AMD-процессорах на непатченной специально винде.


Collapse )