ZXMAK2 - Виртуальная машина ZX Spectrum

[ZXMAK]

думаю прикрутить запись видео в MP4, в отладочном варианте уже работает
Пишет в реальном времени очень даже неплохо и проц не особо жрет

[Eltaron]

думаю прикрутить запись видео в MP4, в отладочном варианте уже работает
Пишет в реальном времени очень даже неплохо и проц не особо жрет

Можно сделать как в анрыле, через ffmpeg, чтобы с кодеками не геморроиться.

[Titus]

Заметил, что при синхронизации от звука можно таскать окно с эмулем или заниматься иной активной деятельностью и эмуль не тормозит, а при синхронизации от видео или таймера - при таскании окна или иной активности в винде - сразу тормозит и заикается звук.

[ZXMAK]

Поделись методикой)

при синхронизации по VBlank, ScanLine используется как таймер с частотой FPS * DisplayMode.Height для прогнозирования времени которое осталось до VBlank. Когда время вычислено, если его достаточно, то делается Thread.Sleep
Кроме того момент VBlank засекается по системному таймеру и если на следующем ожидании кадра окажется что прошло время равное или большее чем frequency / FPS, то обновляется время последнего VBlank и производится немедленный возврат, чтобы попытаться успеть.

Идея с прогнозированием времени для Thread.Sleep подсмотрена в unreal Только в 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, чтобы с кодеками не геморроиться.

я именно на ffmpeg и сделал, с помощью AForge.Video прикручивание заняло минут 15-20, включая загрузку библиотек

Проблемное место с видео - как писать видео, если меняется разрешение экрана. На лету разрешение видеофайла не поменяешь. Думаю в таких случаях можно начинать писать следующий файл после каждой смены разрешения, например test.mp4, test.1.mp4, test.2.mp4, test.3.mp4 и т.д. Или просто прекращать запись.

[Titus]

при синхронизации по VBlank, ScanLine используется как таймер с частотой FPS * DisplayMode.Height для прогнозирования времени которое осталось до VBlank. Когда время вычислено, если его достаточно, то делается Thread.Sleep

Только дискретность Thread.Sleep не лучше 1мс, так ведь?

[ZXMAK]

Заметил, что при синхронизации от звука можно таскать окно с эмулем или заниматься иной активной деятельностью и эмуль не тормозит, а при синхронизации от видео или таймера - при таскании окна или иной активности в винде - сразу тормозит и заикается звук.

хм, интересная особенность, можно будет поисследовать почему так происходит. Если с VBlank можно списать на то что Highest приоритет ставится, то для синхры по времени приоритет не меняется и таскание не должно сильно влиять на поток который с UI не связан.

[Titus]

Кстати интересный вопрос - можно как-то узнать количество ScanLines для текущего режима? Я сейчас тупо беру Height дисплея, что естественно не очень правильно, т.к. реальное число ScanLines больше Height, т.е. частота ScanLines вычисляется меньше реальной.

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

[ZXMAK]

Только дискретность Thread.Sleep не лучше 1мс, так ведь?

с дискретностью вопрос интересный, я вообще считал что Sleep минимум через 10 мс управление возвращает, на деле оказалось что и через 1 мс возвращает. Но это возможно от версии Windows зависит.

[Titus]

с дискретностью вопрос интересный, я вообще считал что Sleep минимум через 10 мс управление возвращает, на деле оказалось что и через 1 мс возвращает. Но это возможно от версии Windows зависит.

Я тоже читал, что в XP (или даже 98) дискретность 10мс, поэтому принудительно в эмуле ставил дискретность самую маленькую 1мс. И на всех виндах от XP до 7 это прокатывало, она была действительно 1мс.

И все же, если дискретность 1мс, не топорно ли засыпать на время с такой грубой дискретностью? Ибо можно промахнуться от начала VBlank на порядка 10%.

[ZXMAK]

Я тоже читал, что в XP (или даже 98) дискретность 10мс, поэтому принудительно в эмуле ставил дискретность самую маленькую 1мс. И на всех виндах от XP до 7 это прокатывало, она была действительно 1мс.

И все же, если дискретность 1мс, не топорно ли засыпать на время с такой грубой дискретностью? Ибо можно промахнуться от начала VBlank на порядка 10%.

там запас 5 мс вычитается, оставшиеся 5 мс эмуль опрашивает VBlank и крутит Thread.SpinLock. Если частоту процессора правильно вычислить, то можно попробовать остаток времени в Thread.SpinWait отдавать, но это не очень надежно, т.к. частота может гулять плюс минус лапоть на всяких Turbo Boost и т.п. новомодных технологиях