Важная информация

User Tag List

Страница 1 из 2 12 ПоследняяПоследняя
Показано с 1 по 10 из 17

Тема: Идея для авторов игр и дем (AY-плеер)

  1. #1
    Master
    Регистрация
    08.05.2007
    Адрес
    Dnepropetrovsk
    Сообщений
    880
    Благодарностей: 470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию Идея для авторов игр и дем (AY-плеер)

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

    С данной проблемой обычно боролись путем оптимизации плеера музыки, попытками сделать нагрузку от плеера на процессор более равномерной. Уже в плеере PT2 авторы отрабатывают новую ноту на каждый канал не одновременно, а в трех разных фреймах, сохраняя промежуточные результаты. Эти и другие подобные меры хоть и улучшают ситуацию, но все равно не могут обеспечить полностью равномерной нагрузки на процессор. Кроме того, указанные меры часто приводят к повышению общей нагрузки на процессор из-за усложнения плеера, хранения и пересылки промежуточных величин и т.д.

    Предлагаю вашему вниманию способ, который, практически не увеличивая среднюю нагрузку на процессор; с минимальными затратами памяти, позволяет решить описанную проблему. Способ универсальный, его можно применить к любому существующему плееру, т.е. разрабатывать новый плеер не требуется.

    Идея в том, чтобы организовать очередь из AY-таблиц. Обычно в каждом плеере есть одна таблица, куда плеер складывает значения для последующего вывода в регистры AY. А мы организуем несколько таких таблиц. Например, штук 5. До начала анимации вызываем плеер 5 раз - в результате в очереди будут подготовлены значения для вывода в AY на 5 кадров вперед.

    Теперь рассмотрим типичную структуру игрового движка. По прерыванию движок первым делом выводит в AY содержимое AY-таблицы, которое стоит первым в очереди. Это занимает немного времени, и нагрузка на процессор одинакова каждый кадр. Вывод в AY в первую очередь по прерыванию необходим для того, чтобы содержимое регистров AY обновлялось равномерно во времени, а не в зависимости от нагрузки на графический движок.

    После обновления регистров AY работает графический движок, который синхронизирован с видео-разверткой. Как правило, нагрузка на процессор от графического движка неравномерна. В идеале она близка к 100% (чтобы возможности процессора полностью использовались для пользы), однако на практике так бывает редко, и нагрузка может колебаться в районе от 60 до 100%.

    После отработки графического движка обычно вызывается плеер музыки. При этом, при традиционном подходе, если отработка графики + музыки не уложилась в кадр до следующего прерывания, то происходит потеря кадра, срыв. Однако в нашем случае происходит следующее. Плеер музыки выполняется с разрешенными прерываниями. Поэтому прерывание останавливает исполнение плеера. Процедура обработки прерывания первым делом, как описано выше, выводит в AY содержимое очередной таблицы. В описываемой ситуации плеер не успел подготовить новые значения (так как его выполнение было прервано). Однако у нас же очередь, в которой ждут готовыми целых 5 таблиц AY! Поэтому процедура обработки прерывания спокойно выводит в AY содержимое следующей таблицы из очереди. После этого она отрабатывает графику. А после отработки графики происходит возврат из прерывания, и прерванный код плеера продолжает работу. Длина очереди AY-таблиц в 5 штук обеспечивает то, что даже при одновременном неблагоприятном стечении обстоятельств (высокая нагрузка на процессор от графики за несколько кадров подряд), не будет нарушена ни плавность анимации, ни воспроизведение музыки. При необходимости длину очереди можно увеличить, благо это не затратно по памяти.

    А когда нагрузка на процессор от графического движка уменьшится, то произойдет вызов музыкального плеера сразу несколько раз подряд, что обеспечит восполнение сократившейся очереди воспроизведения. Очередь воспроизведения лучше всего организовывать в виде циклического буфера, аналогично буферу клавиатуры. Пример реализации кода с разрешенными прерываниями (длина очереди - 8):

    QUEUE_FULL:
    HALT
    MAINLOOP:
    LD A,(BUF_WR_POS) ;указатель конца очереди (куда добавляются элементы)
    LD C,A
    INC A
    AND 7
    LD B,A
    LD A,(BUF_RD_POS); указатель начала очереди (откуда извлекаются элементы)
    CP B
    JR Z,QUEUE_FULL; очередь заполнена - ждать освобождения, что произойдет в процедуре обработки прерывания
    ; в очереди есть место - вызвать плеер
    PUSH BC
    CALL MUSIC_PLAY
    POP BC
    ; увеличить указатель записи в очередь
    LD A,B ; B - указатель конца очереди после увеличения на 1
    LD (BUF_WR_POS),A
    JR MAINLOOP

    В процедуре обработки прерывания вызывать музыкальный плеер не нужно. Нужно только извлекать очередной элемент из очереди и выводить в AY содержимое таблицы, а также вызывать графический движок:
    ISR:
    PUSH AF
    PUSH BC
    LD A,(BUF_WR_POS)
    LD C,A
    LD A,(BUF_RD_POS)
    CP C
    JR Z,QUEUE_EMPTY; Очередь пуста - пропустить очередной вывод в AY
    ; А - место в очереди, откуда следует осуществить AY-вывод
    PUSH AF
    CALL AY_TRANSFER ; Вывести в регистры AY первый элемент очереди
    POP AF
    INC A
    AND 7
    LD (BUF_RD_POS),A
    QUEUE_EMPTY:
    CALL GRAPHICS_ENGINE
    POP BC
    POP AF
    EI
    RET

  2. Этот пользователь поблагодарил Barmaley_m за это полезное сообщение:
    Urguk (24.10.2017)

  3. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  4. #2
    Guru
    Регистрация
    08.10.2005
    Адрес
    Москва
    Сообщений
    9,937
    Благодарностей: 3436
    Mentioned
    2 Post(s)
    Tagged
    1 Thread(s)

    По умолчанию

    Дело в том, что флуктуации нагрузки на процессор в хорошо оптимизированных AY-плейерах очень малы. Эффект был бы заметнее, если б плейер кушал десятки тысяч тактов с неравномерностью нагрузки до нескольких тысяч тактов. А современные плейеры занимают по 1-2 тысяче тактов, и при этом весьма стабильны. Т.е. идея хорошая, но мало-применимая, имхо.

  5. #3
    Master
    Регистрация
    08.05.2007
    Адрес
    Dnepropetrovsk
    Сообщений
    880
    Благодарностей: 470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Titus Посмотреть сообщение
    А современные плейеры занимают по 1-2 тысяче тактов, и при этом весьма стабильны. Т.е. идея хорошая, но мало-применимая, имхо.
    Даже если плеер нагружает процессор равномерно - то его процедуру надо вызывать 1 раз в кадр - не больше, но и не меньше. А мой подход позволяет иногда (в самых напряженных кадрах) отказаться от вызова плеера и использовать все процессорное время только на графику, при этом без ущерба для музыки. Вот в чем принципиальное преимущество!

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

  6. #4
    Vitamin C++ Аватар для Vitamin
    Регистрация
    14.01.2005
    Адрес
    Таганрог, Россия
    Сообщений
    4,031
    Благодарностей: 1426
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Имхо, идея имеет право на жизнь. Плюс опыт разработки многопоточной программы (классическая схема писатель-очередь-читатель) с использованием примитивов синхронизации.

  7. Этот пользователь поблагодарил Vitamin за это полезное сообщение:
    Barmaley_m (22.07.2014)

  8. #5
    Master
    Регистрация
    08.05.2007
    Адрес
    Dnepropetrovsk
    Сообщений
    880
    Благодарностей: 470
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vitamin Посмотреть сообщение
    Плюс опыт разработки многопоточной программы (классическая схема писатель-очередь-читатель) с использованием примитивов синхронизации.
    Я просто не хотел усложнять описание привлечением этих страшных терминов - все понятно и без них. Однако да, так и есть. Мой способ есть реализация вытесняющей многозадачности. Программа работает в 2 потока, один имеет высокий приоритет (графика и вывод очереди в AY), второй поток имеет низкий приоритет (плеер). Примитивы синхронизации не используются, но используется очередь в виде циклического буфера - это один из немногих известных примитивов для безопасного обмена данными между потоками, не требующий блокировок (типа запрещения прерываний, Spinlock и т.д.). Так что да, теоретическое обоснование у нас не отстает

  9. #6
    Guru Аватар для newart
    Регистрация
    19.01.2005
    Адрес
    Санкт-Петербург
    Сообщений
    10,947
    Благодарностей: 1520
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Titus Посмотреть сообщение
    А современные плейеры занимают по 1-2 тысяче тактов
    Современные это какие?

    Плеер Vortex Tracker'a заточен под размер, и кушает 2-5к тактов.

  10. #7
    Guru
    Регистрация
    08.10.2005
    Адрес
    Москва
    Сообщений
    9,937
    Благодарностей: 3436
    Mentioned
    2 Post(s)
    Tagged
    1 Thread(s)

    По умолчанию

    Цитата Сообщение от newart Посмотреть сообщение
    Современные это какие?

    Плеер Vortex Tracker'a заточен под размер, и кушает 2-5к тактов.
    Я их не пользую, не могу сказать. Но даже я писал в 95 году плейер для ST в 3000 тактов. А после меня писали и того меньше.

  11. #8
    Guru
    Регистрация
    25.01.2005
    Адрес
    Miass, Chelyabinsk region
    Сообщений
    4,082
    Благодарностей: 918
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    забыли, кажется, что некоторые плееры вовсю используют стек и нельзя их прерывать прерыванием...

  12. #9
    Guru Аватар для jerri
    Регистрация
    01.03.2005
    Адрес
    Samara
    Сообщений
    3,363
    Благодарностей: 704
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Barmaley_m, Хорошая годная идея

    Давай сорцы плеера и игралки

    ---------- Post added at 12:35 ---------- Previous post was at 12:23 ----------

    Цитата Сообщение от psb Посмотреть сообщение
    забыли, кажется, что некоторые плееры вовсю используют стек и нельзя их прерывать прерыванием...
    Значит надо переписывать плеер, раз он такой неудачный
    С уважением,
    Jerri / Red Triangle.
    [02.05.2014] не забудь этот день. Чубайс должен умереть. Dixi.
    [l'Abbey des morts TSEvo EV...5%] kiwi кошелек +79178162712

  13. #10
    Veteran Аватар для Destr
    Регистрация
    26.03.2008
    Адрес
    Питкяранта
    Сообщений
    1,426
    Благодарностей: 643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от jerri Посмотреть сообщение
    Значит надо переписывать плеер, раз он такой неудачный
    И переписать так, чтоб он был пусть и побольше размером, но чтоб всегда и везде одно и тоже количество тактов занимал. Хоть тресни планета, но кол-во тактов плеера = const.

Страница 1 из 2 12 ПоследняяПоследняя

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

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

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

Похожие темы

  1. MP3 плеер, как магнитофон для ZX?
    от Addison в разделе Unsorted
    Ответов: 12
    Последнее: 27.09.2007, 18:19
  2. Ответов: 1
    Последнее: 13.09.2006, 17:14
  3. AY плеер
    от newart в разделе Unsorted
    Ответов: 19
    Последнее: 19.07.2006, 22:03
  4. Ищу авторов KooLeGGz: группу HorrorSoft
    от TomCaT в разделе Люди
    Ответов: 4
    Последнее: 03.03.2006, 16:18
  5. PT3 плеер, модификация
    от Corpsegrinder в разделе Программирование
    Ответов: 5
    Последнее: 17.02.2005, 18:09

Метки этой темы

Ваши права

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