Простая работа с AY

[Eltaron]

аштоэта? поясните темному..

Пруф того, что между 48-м васиком zx128 и 48-м васиком +3 больше килобайта разницы.

---------- Post added at 12:12 ---------- Previous post was at 12:05 ----------

Сравнивал барсик-48 потому, что его хотя бы визуально по F3 в коммандере можно узнать. А basic-128 перекопан вообще весь - ничего общего, 16118 байт различаются.

[denpopov]

все же я не вижу связи бейсика с упомянутым Амстрадом, ну да ладно..

[daniel]

да ну?

ну да!

[denpopov]

ну да!

вот и поговорили

[ZXMAK]

все же я не вижу связи бейсика с упомянутым Амстрадом, ну да ладно..

48-й бейсик:

[denpopov]

ZXMAK, такая картинка привычнее:

[Splinter]

Книга Мир звуков спектрума очень помогает.

[Alex Rider]

Вполне достаточно? Ты не шутишь? В каких же играх встречается озвучка оператором PLAY?

Для игр на ЯВУ достаточно. Озвучки бейсик-игр оператором Play нет по одной простой причине - игра приобретает AY-звук (не шедеврального качества, надо сказать), но при этом теряет совместимость с 48к. А озвучки на блокирующем BEEP с еще менее шедевральными возможностями - сколько угодно.

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

Критичен. Потому что ЯВУ. Он итак компилится в менее эффективный код, чем код, написанный на ассемблере руками, так еще и либы с собой тянет. Так недолго и всю памяти скушать еще до того, как кончатся идеи для релиза.

По-моему Олег ставил несколько иную задачу, чем просто организовать звук с минимальным кодом.

Олег просил способ позвать как-то Play из машкода даже если нет ПЗУ-128. Я почитал код Play'а, и теперь уверенно могу присоединиться к тем, кто отговаривает Олега его использовать. Для начала, оно сильно "любит" фишки 48 BASIC - workspace и калькулятор, например. А еще оно поддерживает мертворожденный MIDI, что совсем не надо в либе для ЯВУ. И, да, в нем есть баги.

[Barmaley_m]

Для игр на ЯВУ достаточно.

Очень спорное и ничем не обоснованное утверждение.

Озвучки бейсик-игр оператором Play нет по одной простой причине - игра приобретает AY-звук (не шедеврального качества, надо сказать), но при этом теряет совместимость с 48к.

Причина возможная, но не единственно возможная. Ты же не залезешь в голову всем, кто думал реализовать озвучку игр или чего-то другого оператором PLAY, но отказался от этой идеи?

Критичен. Потому что ЯВУ.

И что? Даже на бейсике можно встретить программы с AY-музыкой (на прерываниях или через PAUSE 1), использующие ассемблерные плееры.

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

Он итак компилится в менее эффективный код, чем код, написанный на ассемблере руками, так еще и либы с собой тянет.

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

[Alex Rider]

Очень спорное и ничем не обоснованное утверждение.

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

Причина возможная, но не единственно возможная.

Ok, я бы во-превых и в-единственных не стал озвучивать игру на BASIC'е оператором PLAY потому что она перестанет идти на машинах, на которых нет 128к. Может быть, есть и еще причины. Моего уровня кодинга хватит чтобы озвучить игру и ассемблерными вставками, но я не уверен, что все игрописатели на бейсике могут это сделать, а альтернатива PLAY в этом случая - либо BEEP, либо всякие глючные мегабейсики, резко отжирающие память своим рантаймом.

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

Согласен с одним комментарием. Сначала надо сделать самое востребованное, а потом смотреть фидбэк и добавлять всякие опции.

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

Да. Но все зависит от универсальности этой либы. Если сделать максимально функционально, разработчик ради экономии памяти может плюнуть на либу и использовать BEEP или писать выод звука на ассемблере сам. Вариант с использованием команды PLAY из ПЗУ заведомо экономнее по памяти, но, как выяснилось, сильно геморройный. Опять же, плееры AY-музыки есть быстрые и длинные, есть медленные и короткие. Какой лучше включить в либу? Все? Хотя, нормальны трек, ЕМНИП, все равно существенно длиннее плеера, так что при его тспользовании уже сэкономить не получится (кстати, строки PLAY'а сильно короче компилированных музык).