Ну со звуком в zxmak2 проблем нет ни при синхронизации по звуку, ни по видео. Проблема только в том, что при синхронизации по видео, точное отслеживание начала развертки требует большой нагрузки на процессор, т.к. в windows нет ивентов по vblank, поэтому приходится в цикле следить за scanline.
Задержка в zxmak2 зависит от системы, как только приходит ивент, так заливается новый фрейм. Если ивенты система бросает с задержкой, то добавится эта задержка. В среднем минимальная задержка должна быть на уровне около 1 фрейма, т.е. порядка 0.02 сек, но т.к. эмулятор всегда следит чтобы в буффер не был пустым, то реальная задержка будет ближе к максимальной - по числу буфферов, т.е. не более 8 фреймов = 0.16 сек. Т.к. эмуляция фрейма не мгновенная, а требует какогото времени, плюс задержки на переключение задач а они в windows очень существенны), то на деле задержка должна составлять 6-7 фреймов или 0.12 сек.
ZXMAK2 при синхронизации по звуку ориентируется исключительно на ивенты системы, оставляя на ее совести неравномерность генерации этих ивентов. Т.е. если система бросает ивенты пачками, то и фреймы будут заливаться пачками. Это естественно сделает скроллы менее плавными, т.к. фреймы будут эмулироваться не достаточно плавно, но раз системе так нужно для нормального воспроизведения звука, то с этим ничего не поделаешь. При синхронизации по видео таких эффектов не будет, т.к. vblank происходит равномерно, заодно и привязка к развертке получается, поэтому скролы в этом случае получаются плавными (если не считать влияние пропуска кадров для ресэмплинга, но это на плавности малозаметно, а больше влияет на визуальное восприятие цветов в мультиколорах).
Тут следует отметить что рендер на экране в zxmak2 осуществляется асинхронно от эмуляции, поэтому задержки UI влияют только на обновление окна, но не на саму эмуляцию (включая и запись в звуковой буфер). За счет этого удалось добиться высокой скорости реакции UI, при полном отсутствии влияния на поток эмуляции. Поэтому эмулятор так шустро реагирует на ресайз окна, не останавливается при перетаскивании и т.п. Добиться такого было непростоИзображение вначале заносится в текстуру из потока эмуляции и инвалидируется окно. А UI уже по запросу системы на WM_PAINT рендерит тектуру в окно. WM_PAINT система синхронизирует с vblank, поэтому изображение на дисплей попадат синхронно с разверткой. Независимо от источника синхронизации фреймов.
У меня была идея сделать синхронизацию от по WM_PAINT, но это оказалось не очень хорошей идеей, т.к. в UI windows это сообщение приходит с задержкой, например если с UI чтото происходит (ресайз и тп).



Изображение вначале заносится в текстуру из потока эмуляции и инвалидируется окно. А UI уже по запросу системы на WM_PAINT рендерит тектуру в окно. WM_PAINT система синхронизирует с vblank, поэтому изображение на дисплей попадат синхронно с разверткой. Независимо от источника синхронизации фреймов.
Ответить с цитированием