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

[ZXMAK]

А, а то у меня от всех этих разговоров о графах показалось, что DirectShow. Сразу попытался вспомнить, где там счас кодеки берут

хотел закомитить, но когда начал код причесывать и делать общий интерфейс для разных рекордеров, всплыли недостатки текущих интерфейсов - разнообразие указателей, картинки в виде int*, звук в виде byte* и uint*. Пока отложил - нужно интерфейсы подрефакторить.

Может кто подскажет простой и быстрый алгоритм для хорошего ресамплинга. Нужно чтобы на 60 Гц дисплеях скролы плавные были. Сейчас просто считается сколько фреймов пропустить, в итоге на 60 Гц слишком неравномерно обновление кадров получается

Суть в чем - есть импульсы с частотой источника (частота дисплея, например 60 Гц) и есть импульсы с целевой частотой (частота TV, 50 Гц). Нужна функция которая будет показывать какой импульс источника пропускать, а какой нет, чтобы на выходе получилась целевая частота, но в сетке частоты источника, при этом чтобы импульсы были распределены равномерно.

---------- Post added at 20:23 ---------- Previous post was at 20:06 ----------

Теперь я понял) Ты ждешь события. Что за событие?
Разве события могут приходить чаще, чем раз в квант (1мс?). Когда я экспериментировал с событиями от звукового буфера, они приходили именно так, с дискретностью в квант. А иной раз задерживались и приходили скопом по несколько штук даже.

речь не об уведомлениях, а о событии vblank, наличие которого определяется соответствующим вызовом в драйвер видеокарты

[Titus]

речь не об уведомлениях, а о событии vblank, наличие которого определяется соответствующим вызовом в драйвер видеокарты

Значит ты засыпаешь на столько-то миллисекунд, чтобы проснуться перед временем в которое должен прийти VBlank, затем проснувшись (а VBlank уже рядом) вызываешь странный цикл из NOP'в неопределенной длительности, а после этого цикла начинаешь проверять не наступил ли VBlank? Словом, я опять не понял необходимости в этом цикле NOP'ов)

[ZXMAK]

Значит ты засыпаешь на столько-то миллисекунд, чтобы проснуться перед временем в которое должен прийти VBlank, затем проснувшись (а VBlank уже рядом) вызываешь странный цикл из NOP'в неопределенной длительности, а после этого цикла начинаешь проверять не наступил ли VBlank? Словом, я опять не понял необходимости в этом цикле NOP'ов)

Титус, ну чего ты к этому прицепился? Это не цикл nop'ов, а цикл специальных инструкций, которые разгружают процессор. В отличие от nop, который несмотря на ничего не делание, блоки процессора таки загружает.
Что тут странного? Цикл простой - проверили vblank, если его нету, то даем немного тактов процессору, нам несколько тактов погоды не делают, зато у процессора появляется возможность прокачать кэши, обновить оптимизатор или отключить ненужные блоки чтобы снизить потребления тока. Это в любом случае лучше чем тупо цикл крутить или nop'ы выполнять. так в чем вопрос?

---------- Post added at 20:53 ---------- Previous post was at 20:47 ----------

чтото я с ресемплингом запутался. Сделал интерполяцию - результат тот-же, что и сейчас. Ну разве что диапазон частот больше поддерживается. Однако на 60 Гц скролл получается дерганый, т.к. все сводится к тому чтобы пропускать каждый 6-й кадр, вот на этом кадре и видно неравномерность.
Получается что из 60 Гц плавные 50 Гц никак не выжмешь? Или есть какие-то методики для обмана зрения?

[Titus]

Титус, ну чего ты к этому прицепился?
Что тут странного? Цикл простой - проверили vblank, если его нету, то даем немного тактов процессору, нам несколько тактов погоды не делают, зато у процессора появляется возможность прокачать кэши, обновить оптимизатор или отключить ненужные блоки чтобы снизить потребления тока. Это в любом случае лучше чем тупо цикл крутить или nop'ы выполнять. так в чем вопрос?

Вот в этом и был вопрос) Теперь ты ответил)
Я не цепляюсь, а стараюсь понять суть ибо тоже занимаюсь сходными проблемами.

Кстати, как ты решаешь проблему рассинхронизации звука и видео, когда синхронизация идет по видео? Или и в этом случае ты за опору берешь аудиобуфер?

---------- Post added at 21:58 ---------- Previous post was at 21:53 ----------

чтото я с ресемплингом запутался. Сделал интерполяцию - результат тот-же, что и сейчас. Ну разве что диапазон частот больше поддерживается. Однако на 60 Гц скролл получается дерганый, т.к. все сводится к тому чтобы пропускать каждый 6-й кадр, вот на этом кадре и видно неравномерность.
Получается что из 60 Гц плавные 50 Гц никак не выжмешь? Или есть какие-то методики для обмана зрения?

Попробуй использовать методику смешения двух соседних кадров с прозрачностью каждого пропорциональной расстоянию реального 60Гц кадра от двух прогнозируемых 50Гцовых. Например:

50----------60---50--------60--------50----60------------50

т.е. в первом случае твой 60гц кадр это смесь на 1/4 от предыдущего 50гц и 3/4 последующего.
второй твой 60гц кадр это смесь 1/2 предыдущего 50гц и последующего, и третий это 3/4 предыдущего и 1/4 последующего.
Коэффициенты взяты грубо для наглядности.

[ZXMAK]

Вот в этом и был вопрос) Теперь ты ответил)
Я не цепляюсь, а стараюсь понять суть ибо тоже занимаюсь сходными проблемами.

Кстати, как ты решаешь проблему рассинхронизации звука и видео, когда синхронизация идет по видео? Или и в этом случае ты за опору берешь аудиобуфер?

просто решаю - если ошибка накопится до размеров одного кадра, до просто будет пропущен кадр у того устройства которое является слейвом. Т.е. если синхра от звука, то будет пропущен один кадр видео. Если синхра от видео, то 1 кадр звука. Если синхра от времени, то кому как повезет.
Учитывая что ошибка маленькая, да и фреймы очень маленькие (1/50 секунды), то такие коллизии не критичны, например потери одного фрейма за несколько минут никто не заметит Вот если это будет происходить часто, то это будет заметно

---------- Post added at 21:16 ---------- Previous post was at 21:04 ----------

Попробуй использовать методику смешения двух соседних кадров с прозрачностью каждого пропорциональной расстоянию реального 60Гц кадра от двух прогнозируемых 50Гцовых. Например:

50----------60---50--------60--------50----60------------50

т.е. в первом случае твой 60гц кадр это смесь на 1/4 от предыдущего 50гц и 3/4 последующего.
второй твой 60гц кадр это смесь 1/2 предыдущего 50гц и последующего, и третий это 3/4 предыдущего и 1/4 последующего.
Коэффициенты взяты грубо для наглядности.

вот какраз такого хотел избежать, но похоже только такой вариант и остается

[Titus]

просто решаю - если ошибка накопится до размеров одного кадра, до просто будет пропущен кадр у того устройства которое является слейвом. Т.е. если синхра от звука, то будет пропущен один кадр видео. Если синхра от видео, то 1 кадр звука. Если синхра от времени, то кому как повезет.

Блин, это не айс) Кадр от звука - это вплоть до щелчка, а кадр от видео это дернулся скролл.

[ZXMAK]

Блин, это не айс) Кадр от звука - это вплоть до щелчка, а кадр от видео это дернулся скролл.

А какие есть варианты? Адаптивный рескейл аудио и видео в реальном времени?

---------- Post added at 01:11 ---------- Previous post was at 01:04 ----------

Last Ninja Remix 2 на Скорпе с ПрофПЗУ после входа в монитор по NMI и выхода кажет черный экран. Потому что включена вторая экранная область. Сдается мне, проблема в чтении 1ffd и 7ffd. Или в ПрофПЗУ Игра 48-я, но при сохранении образа памяти ПрофПЗУ пишутся 256 Кб. Unreal ведет себя так же. По мотивам этой темы.

48к снапшоты пишутся только если включена и залочена стандартная 48к раскладка памяти, в скорпе нельзя навсегда залочить, поэтому пишется полный снепшот.

[Titus]

А какие есть варианты? Адаптивный рескейл аудио и видео в реальном времени?

Да, я так и делаю. Когда тактирование идет от VBlank.
Только это, как оказалось прокатывает лишь на моей звуковухе (т.к. у ней есть нотификация о ТОЧНОЙ позиции в звуковом буфере на текущий момент), и я могу адаптивно подстраиваться.
Когда же стал тестить на других звуковухах, чаще всего интегрированных типа AC97, то выяснилось, что у них данные о текущей позиции в буфере предоставляются с точностью в +-километр (сотни байт). А начиная с Висты (у меня-то XP), системно вообще не предусмотрено получать значения позиции в аудиобуфере точнее, чем с дискретностью... то ли 400 позиций, то ли скокько-то там. В общем, не одна сотня. Это все было обсуждено ТУТ, но потом за неимением точных методов /временно/ заглохло.

[ZXMAK]

Да, я так и делаю. Когда тактирование идет от VBlank.
Только это, как оказалось прокатывает лишь на моей звуковухе (т.к. у ней есть нотификация о ТОЧНОЙ позиции в звуковом буфере на текущий момент), и я могу адаптивно подстраиваться.
Когда же стал тестить на других звуковухах, чаще всего интегрированных типа AC97, то выяснилось, что у них данные о текущей позиции в буфере предоставляются с точностью в +-километр (сотни байт). А начиная с Висты (у меня-то XP), системно вообще не предусмотрено получать значения позиции в аудиобуфере точнее, чем с дискретностью... то ли 400 позиций, то ли скокько-то там. В общем, не одна сотня. Это все было обсуждено ТУТ, но потом за неимением точных методов /временно/ заглохло.

на мой взгляд тут ошибкой было ориентироваться на замеры времени кадров - под windows это не корректно. Точный замер сделать не получится - аппаратура для этого не предназначена. а коррекция в процессе работы невозможна, т.к. для этого прийдется останавливать эмуляцию чтобы произвести еще один замер. Если учесть то, что частоты процессора, видеокарты и звуковухи могут меняться в процессе работы, то без повторных замеров тут не обойтись

[Titus]

на мой взгляд тут ошибкой было ориентироваться на замеры времени кадров - под windows это не корректно. Точный замер сделать не получится - аппаратура для этого не предназначена. а коррекция в процессе работы невозможна, т.к. для этого прийдется останавливать эмуляцию чтобы произвести еще один замер. Если учесть то, что частоты процессора, видеокарты и звуковухи могут меняться в процессе работы, то без повторных замеров тут не обойтись

На моей звуковухе это работало ИДЕАЛЬНО.
Так что пока открытый вопрос, как это адаптировать (и можно ли) под более грубую нотацию других звуковух и Win7 систем.

Частота процессора тут вообще не при чем.

А уж если пользователь меняет частоту видюхи во время эмуляции, то или не надо этого делать, или пересчитывать.

А частоту звуковухи... Как она может поменяться?