User Tag List

Показано с 1 по 10 из 66

Тема: ZX DevStudio

Древовидный режим

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #19

    Регистрация
    30.01.2006
    Сообщений
    1,921
    Спасибо Благодарностей отдано 
    73
    Спасибо Благодарностей получено 
    119
    Поблагодарили
    80 сообщений
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Titus Посмотреть сообщение
    Понятно, что все синхронизируется по аудио, то чего ему не быть плавным. Никуда не убежит и не отстанет. Лишь задержка будет из-за длины буфера. Кстати, какая задержка у тебя?

    Вот в том-то и проблема, когда синхронизируешься по одному, сложно (хотя и можно, порой, дикими извращениями) добиться синхронизации другого. Видео, когда синхришься по звуку, и звука, когда синхришься по видео.
    Ну со звуком в 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 чтото происходит (ресайз и тп).
    Последний раз редактировалось ZXMAK; 10.05.2014 в 06:54.
    ZXMAK2 - Виртуальная Машина ZX Spectrum https://github.com/zxmak/ZXMAK2 (старая ссылка http://zxmak2.codeplex.com)
    ZXMAK.NET - спектрум на C# http://sourceforge.net/projects/zxmak-dotnet

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •