думаю прикрутить запись видео в MP4, в отладочном варианте уже работает :)
Пишет в реальном времени очень даже неплохо и проц не особо жрет :)
Вид для печати
думаю прикрутить запись видео в MP4, в отладочном варианте уже работает :)
Пишет в реальном времени очень даже неплохо и проц не особо жрет :)
Можно сделать как в анрыле, через ffmpeg, чтобы с кодеками не геморроиться.Цитата:
Сообщение от ZXMAK
Заметил, что при синхронизации от звука можно таскать окно с эмулем или заниматься иной активной деятельностью и эмуль не тормозит, а при синхронизации от видео или таймера - при таскании окна или иной активности в винде - сразу тормозит и заикается звук.
при синхронизации по VBlank, ScanLine используется как таймер с частотой FPS * DisplayMode.Height для прогнозирования времени которое осталось до VBlank. Когда время вычислено, если его достаточно, то делается Thread.Sleep :)Цитата:
Сообщение от Titus
Кроме того момент VBlank засекается по системному таймеру и если на следующем ожидании кадра окажется что прошло время равное или большее чем frequency / FPS, то обновляется время последнего VBlank и производится немедленный возврат, чтобы попытаться успеть.
Идея с прогнозированием времени для Thread.Sleep подсмотрена в unreal :smile: Только в unreal для прогнозирования используется ненадежный RDTSC. А у меня системный таймер.
Может возникнуть проблема, если DirectX говорит одну частоту FPS, а на самом деле другая. Или если реальный FPS сильно отличается от той, которую дает DirectX. Тогда время неточно прогнозироваться будет. Думаю можно сделать адаптивный алгоритм для коррекции реального fps путем замера реального времени между VBlank.
Кстати интересный вопрос - можно как-то узнать количество ScanLines для текущего режима? Я сейчас тупо беру Height дисплея, что естественно не очень правильно, т.к. реальное число ScanLines больше Height, т.е. частота ScanLines вычисляется меньше реальной.
---------- Post added at 14:55 ---------- Previous post was at 14:45 ----------
я именно на ffmpeg и сделал, с помощью AForge.Video :smile: прикручивание заняло минут 15-20, включая загрузку библиотек :biggrin:Цитата:
Сообщение от Eltaron
Проблемное место с видео - как писать видео, если меняется разрешение экрана. На лету разрешение видеофайла не поменяешь. Думаю в таких случаях можно начинать писать следующий файл после каждой смены разрешения, например test.mp4, test.1.mp4, test.2.mp4, test.3.mp4 и т.д. Или просто прекращать запись.
Только дискретность Thread.Sleep не лучше 1мс, так ведь?Цитата:
Сообщение от ZXMAK
хм, интересная особенность, можно будет поисследовать почему так происходит. Если с VBlank можно списать на то что Highest приоритет ставится, то для синхры по времени приоритет не меняется и таскание не должно сильно влиять на поток который с UI не связан.Цитата:
Сообщение от Titus
Посмотрю чуть позже, как я это делаю в EmuStudio - отпишусь.Цитата:
Сообщение от ZXMAK
с дискретностью вопрос интересный, я вообще считал что Sleep минимум через 10 мс управление возвращает, на деле оказалось что и через 1 мс возвращает. Но это возможно от версии Windows зависит.Цитата:
Сообщение от Titus
Я тоже читал, что в XP (или даже 98) дискретность 10мс, поэтому принудительно в эмуле ставил дискретность самую маленькую 1мс. И на всех виндах от XP до 7 это прокатывало, она была действительно 1мс.Цитата:
Сообщение от ZXMAK
И все же, если дискретность 1мс, не топорно ли засыпать на время с такой грубой дискретностью? Ибо можно промахнуться от начала VBlank на порядка 10%.
там запас 5 мс вычитается, оставшиеся 5 мс эмуль опрашивает VBlank и крутит Thread.SpinLock. Если частоту процессора правильно вычислить, то можно попробовать остаток времени в Thread.SpinWait отдавать, но это не очень надежно, т.к. частота может гулять плюс минус лапоть на всяких Turbo Boost и т.п. новомодных технологияхЦитата:
Сообщение от Titus