Emu80 v.4

Цитата:

---

Сообщение от Titus

Core I3-6300 3.8GHz. Видюха встроена в проц.

---

Вполне достаточно :)

Цитата:

---

Сообщение от Titus

Звуковуха Audigy 2. Старовата, но хороший звук дает, поэтому я ее держу.

---

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

Цитата:

---

Сообщение от Titus

Предположу, что всякие кросплатформенные прослойки между WinAPI и эмулятором типа QT могут вносить свои глюки или тормоза.

---

Это да, еще и руки бывают связаны ограничениями используемой прослойки. Чего, например, стоит хотя бы ограничение Qt на возможность отрисовки только из основного потока или возможность выводить звук под windows только посредством wavout. Хотя все решаемо, конечно. Надеюсь, со временем руки дойдут довести до ума...

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

Цитата:

---

Сообщение от marinovsoft

грузит его на 100%

---

Бывает такое на картах NVidia, всегда загрузка около 100%. Попробуй запустить с параметром:

Код:

---

Emu80qt.exe -angle

---

Загрузка уменьшится?

Цитата:

---

Сообщение от Pyk

выводить звук под windows только посредством wavout.

---

Тогда ничего удивительного, я думаю)

Как синхронизируется звук и видео?

Как ожидается начало кадра vblank?

Код:

---

Emu80qt.exe -angle

---

Загрузка упала до 6%.

Цитата:

---

Сообщение от Titus

Как синхронизируется звук и видео?

---

Вопрос очень объемный, но если в 2 словах, то сейчас синхронизация происходит за счет звука, а не видео (что было бы логичнее). Если интересует что-то более конкретное - поясню. Я бы спросил, как у тебя сделано, но боюсь, что в моих реалиях этот вариант будет неприемлем ;(

Цитата:

---

Сообщение от Titus

Как ожидается начало кадра vblank?

---

Установкой соответствующего флага в Qt, отвечающего за ожидание vsync при отрисовке. Особых вариантов Qt не оставляет... Отсюда и 100% загрузка процессора, обсуждаемая чуть выше - это происходит где-то в недрах Qt или даже скорее видеодрайвера, как раз во время ожидания vsync...

Надо будет еще вернуться к этому вопросу и попробовать переработать синхронизацию, сохранив кроссплатформенность. Можно попробовать задействовать еще SDL специально для вывода звука. Я вообще удивлен, что в текущем варианте удалось добиться удовлетворительных результатов с использованием исключительно возможностей Qt с его жесткими ограничениями...

Приветствую!
При необходимости, если таковая будет, могу тестовую версию с Qt и Корветом затестить в сборке для MacOS.

Цитата:

---

Сообщение от Pyk

Вопрос очень объемный, но если в 2 словах, то сейчас синхронизация происходит за счет звука, а не видео (что было бы логичнее). Если интересует что-то более конкретное - поясню. Я бы спросил, как у тебя сделано, но боюсь, что в моих реалиях этот вариант будет неприемлем ;(

---

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

Titus, ну да, примерно так. Причем с этим мало что можно сделать, так как есть жесткое ограничение: рисовать в Qt можно только из GUI-потока. Так что даже если сделать собственно эмуляцию в отдельном потоке, в случае ресайза это не поможет :( Хотя, уже Qt6 вышел, можно посмотреть, не изменилось ли там что-то в этом плане, а также не появилось ли что-то полезное для синхронизации и звука. Но что-то я пессимистически настроен по этому поводу, уже сколько лет никаких важных изменений...

Цитата:

---

Сообщение от Pyk

Хотя, уже Qt6 вышел, можно посмотреть, не изменилось ли там что-то в этом плане, а также не появилось ли что-то полезное для синхронизации и звука. Но что-то я пессимистически настроен по этому поводу, уже сколько лет никаких важных изменений...

---

А какой смысл тогда писать под QT? Не лучше ли перейти на чистый WinAPI или типа того?

Titus, мультиплатформенность. Сейчас все, что нужно для запуска на другой ОС - перекомпиляция.
А поддерживать несколько версий GUI под разные API слишком сложно...

Посмотрим, простор для оптимизации всегда есть, не все так плохо. Вот и сейчас посмотрел внимательнее документацию - оказывается и в Qt можно рисовать не в GUI-потоке, если использовать вызовы OpenGL вместо встроенных средств Qt. :) Просто я после первой реализации уже почти 4 года не возвращался к этому вопросу, увлекся поддержкой новых компов, надо будет заняться в этом году...

Цитата:

---

Сообщение от Pyk

Titus, мультиплатформенность. Сейчас все, что нужно для запуска на другой ОС - перекомпиляция.
А поддерживать несколько версий GUI под разные API слишком сложно...

---

А нужно ли это? Сколько у нас этих платформ? UNIX'ы, но на них WinE есть, под которым вполне хорошо работает.
На маке тоже можно запускать PC-шные приложения.

А на мобильных и планшетах все равно нужен другой интерфейс, чем на PC.