Xpeccy

[SAM style]

https://forum.qt.io/topic/53152/solv...opengl-scene/5 тут вроде пример рабочий есть для qt5

Я так уже пробовал. Одно отличие - у меня QGLWidget, а не QOpenGLWidget (какая между ними разница - я не понял). beginNativePainting/endNativePainting ничего не исправляют.
QPainter::drawText я не использую - для сообщений у меня отдельный битмап-шрифт и отдельная процедурина вывода, тоже картинками.
Сразу было ясно, что конфликт где-то в совокупности gl-вызовов и существования QPainter-а
Сравнивая то-где-глючит и то-где-не-глючит, я нашёл только одно отличие - фпс эмулируемой машины. Поток эмулирования за раз отэмулирувает где-то 20мс (для 50Гц), но при 60Гц на эмулируемой машине в этот период может быть готово сразу 2 кадра, и соответственно 2 раза выдаётся сигнал "кадр готов". Возможно, он и засирает всё.

[Dexus]

SAM style, а переход в ожидание следующего фрейма в конце эмулирования у тебя чтоли нет? Ну чтобы "кадр готов" не складировались, и чтобы второй кадр даже не начинал вычисляться, пока предыдущий не пошел на отображение. Тогда и лаг на 2 фрейма тоже понятен, это типа как render ahead получается, т.е. заранее все наэмулировал а стейты клавиш только потом доходят...

[SAM style]

SAM style, а переход в ожидание следующего фрейма в конце эмулирования у тебя чтоли нет? Ну чтобы "кадр готов" не складировались, и чтобы второй кадр даже не начинал вычисляться, пока предыдущий не пошел на отображение. Тогда и лаг на 2 фрейма тоже понятен, это типа как render ahead получается, т.е. заранее все наэмулировал а стейты клавиш только потом доходят...

У меня отрезок эмулирования - не кадр, а заполненный звуковой буфер. Срань вполне может излечиться, если обрезать длину буфера (пока нет возможности проверить), хотя SDL довольно капризный в этом плане - то любую длину принимает при открытии устройства, то хочет степени двойки... Собственно, каллбэк SDL-а по звуку и даёт сигнал к очередной порции эмуляции.
Сигнал "кадр готов" выдаёт поток эмуляции, а принимает его уже основной поток - в котором весь UI, в т.ч и вывод картинки на экран

[Dexus]

У меня отрезок эмулирования - не кадр, а заполненный звуковой буфер.
...
Сигнал "кадр готов" выдаёт поток эмуляции, а принимает его уже основной поток - в котором весь UI, в т.ч и вывод картинки на экран

Хмм... Понятно.

Срань вполне может излечиться, если обрезать длину буфера

Я думаю не стоит прибивать гвоздями размер буфера, и увязывать с длиной кадра. Все как-то без этого обходятся...
Каким образом кстати длина буфера может на это повлиять, он генерируется, не вытесняя рисовку экрана...

Буфер я так понимаю короче кадра?
В любом случае в ходе заполнения буфера (всякие и биперы) поток эмуляции заполняет и картинку (ход луча и все такое). И когда встречается blank - дает сигнал на вывод графики. Тут все логично.
Но есть вопрос: сигнал этот сразу же обрабатывается, или же в очереди складируется?
Потому что должен сразу же. Если не сразу, то есть смысл пересмотреть это место. Ведь в таком случае реально возможна ситуация, когда в очереди накопится ДВА сигнала на перерисовку (а такого быть вообще не должно - если чтото не успевает - фрейм должен скипаться).

принимает его уже основной поток - в котором весь UI, в т.ч и вывод картинки на экран

У тебя есть возможность мониторить длину и содержание этой очереди? Ну хотя бы на предмет именно сигнала на перерисовку. И просто дампить в лог случаи, когда в основном цикле (в котором рисование и происходит) оказывается более одного? И вообще не помешало бы замерять тайминги между выводами, у меня есть подозрения, что время там скачет от 5ти до 40ка мс.

А вообще, каким образом может оказаться два сигнала на вывод? Ладно, думаю не нужно тут голову ломать, прежде чем это вообще подтвердится. Может там все дело в чем-то другом.

[SAM style]

У тебя есть возможность мониторить длину и содержание этой очереди

Это всё внутри QApplication::exec() - там Qt запускает свой main-loop, принимает сигналы от всех и выполняет связанные с ними слоты, если они есть. Всё в одном потоке, поэтому очередь присутствует, но мне недосягаема. В принципе, я могу сделать свой обработчик всех событий для основного окна и пробовать отсеивать там лишние вызовы...

Я думаю не стоит прибивать гвоздями размер буфера, и увязывать с длиной кадра. Все как-то без этого обходятся...

Это вначале было прибито, потому что всё работало в 50фпс, и заполнение буфера звука плюс-минус совпадало с заполнением картинки. А так SoundFreq / CompFPS должно давать правильное значение, но переоткрывать звуковое устройство каждый раз при смене фпс-ов... Дойду до домашнего компа - попробую.

[Dexus]

поэтому очередь присутствует, но мне недосягаема

Печально.
Может все таки можно использовать какой-нибудь QSignalSpy?

Это вначале было прибито, потому что всё работало в 50фпс, и заполнение буфера звука плюс-минус совпадало с заполнением картинки.

Блин ну не должно быть так, чтобы длину буфера к длительности кадров постоянно подгонять. Если аудио является основны якорем, и событие вывода графики генерируется из звукового рендера, то вообще не важно какая длина буфера, важны временнЫе отметки, а их уже можно о и с 50фпс и с 60фпс и с 59 генерировать (samplerate делить на эти самые привязанные к кадрам чанки).

[Advertiser]

[SAM style]

Блин ну не должно быть так, чтобы длину буфера к длительности кадров постоянно подгонять. Если аудио является основны якорем, и событие вывода графики генерируется из звукового рендера, то вообще не важно какая длина буфера, важны временнЫе отметки, а их уже можно о и с 50фпс и с 60фпс и с 59 генерировать (samplerate делить на эти самые привязанные к кадрам чанки).

Звук оказался не при чём. Делал буфер на 10 буферов/сек, и на 100 буферов/сек - всё одно. Косвенно отследил забиваемость очереди Qt (printf на сигнал по кадру, printf на слот, который к нему привязан) - сколько сигналов выпущено, столько раз и слот срабатывает. Бывает, что идёт 2 сигнала подряд, но за этим следует 2 вызова слота подряд. Очередь не забивается. Возможно, 2 перерисовки подряд как-то дурно влияют на GL...

- - - Добавлено - - -

Решилось Точно не знаю, почему так, но... До этого для перерисовки окна я делал setUpdatesEnabled(true); repaint(); setUpdatesEnabled(false); - обновления окна разрешены только здесь, чтобы система не перерисовывала его когда ей захочется.
С GL были огромные подозрения, что активный QPainter вызывает рекурсию. Поэтому я сделал прямой вызов paintEvent(nullptr) вместо предыдущей связки. Окно перерисовывается, но все другие обновления окна теперь запрещены всегда. И шо бы вы таки думали? Его теперь не колбасит - GameBoy стабильно держит свои 60фпс, NES в NTSC тоже...
Чудесато...
Чудесато то, что теперь оно накапливает задержку, но медлено...
Чудесато... без двойной буферизации не накапливает, но индикаторы иногда подмигивают

[Dexus]

SAM style, накапливает задержку, это то что звук начинает от видео запаздывать? А как же сигнал на вывод фрейма из потока эмуляции?

- - - Добавлено - - -

По логике задержка конечно может накапливаться, но только в пределах одного фрейма, если vsync установлен. Бегущие строчки 50hz на мониторах в 60hz неизменно подергиваться, но делать это они должны по однообразному шаблону. С задержками между кадрами в 1,1,2,1,1, 1,1,2,1,1 кадров. 60fps по идее никуда дрейфовать не должен.

[SAM style]

накапливает задержку, это то что звук начинает от видео запаздывать?

Нет, реакция Qt на события (таймеры, нажатия клавиш итп) начинает запаздывать. Картинка и звук в порядке.
Вобщем, пока что вылечил отключением двойной буферизации. Может, ещё потом поэкспериментирую - отключу автоматический swapBuffers, и буду его руками менять.
Исходники впилены на гитхаб. Для cmake появилось -DUSEOPENGL=0 или 1 в зависимости от желания. Если есть возможность собрать - можно погонять.
У nes заметил ещё одну вещь - если во время работы вызвать опции и нажать ок, то сбиваются все тайлы. Но это уже совсем другая история...

[Dexus]

SAM style, а какой-либо вариант vsync случайно не включен? Двойная буферизация с vsync’ом всегда дают небольшой лаг. Тройная буферизация менее лагучая. https://zen.yandex.ru/media/mywebpc....11b700af1e7f39

По «запаздыванию». Оно прям на глаз ощутимым становится? Типа там по 5, 10 фреймов, или даже на пол секунды?

Зы: в прошлый раз так и не получилось научиться собирать.. может еще раз попытаться.