Запись идет не на диск, а в буфер (от того одним из параметров события и является buffer_id). А знаешь, что можно делать с буфером? Верно, передавать по сети (или копировать частями в другие буферы).
Даже, если бы шла запись на диск, никто бы не мешал выходящий файл постепенно считывать и пересылать.

After that you can do what you want with the custom buffer - you could play it using the dedicated buffer audio functions, you could process it and send it over the network, you could save it to disk...

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

Добрый день, подскажите можно ли реализовать в игре общение, между игроками, по микрофону?

задержки какие? передачи пакетов или движения перса в игре управляемого по сети другим игроком?

как часто отправлять данные и в каком формате?

Здравствуйте, форумчане. Мне нужна ваша помощь. Что необходимо для создания подобной игры (http://cars.play.tegos.ru/)? Я имею ввиду такие пункты (помимо головы и прямых рук) :
1. Какой движок лучше всего подходит? (языки готов выучить, но желательно лучше без них)
2. Движки для офф-лайн игр не подходят, т.к. игра должна лежать именно на сервере.

По этим языкам есть вопросы:
1. Какой проще всего изучать?
2. Какой из них безопаснее всего? (в плане хранения данных пользователя. Про протокол HTTPS слышал, но он дорогущий)

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

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

А теперь, вопрос на засыпку: какой движок оптимален для таких задач? Смотрел Phaser, Uranium и понял, что без знания их языка не обойтись. Я многого хочу, но нет ли движка, на подобии Game Maker, дабы не химичить самому со всеми этими операторами? Только опять же, с возможностью загрузки на сервер.

Столкнулся с такой проблемой при создании игры. Сегодня PHP выше версии 5.6 уже не использует такую функцию как mysql_connect. Он то её использует, но при каждом использовании он выдаёт уведомление о том, что ваш mysql устарел и вам желательно использовать Mysqli. Но проблема в том, что сменить mysql на mysqli на хостинге я не могу, на Денвере то еще можно. Как можно разрешить такую проблему? Не говоря уже о банальной регистрации, будет выскакивать уведомление, а что говорить о дальнейшей игре, там ведь кругом связь с БД.

Заранее спасибо)

мобильный вид у меня в игре.
надо как видно на картинке, одну фигуру с разрешением х,у (Ios) и рандомные удары.
все слепить в одно целое

Как окно CUA не знает, что будет в нем нарисовано программой.

Дык, мы на момент создания "панелек" знаем только, разрешение экрана, что панелек будет две (и, возможно, они будут снабжены парой кнопок "перелистывания"). Что на них будет нарисовано, мы не знаем, это выясниться только при загрузке на панельку содержимого выбранной страницы.

Т.е. страница "слушает" только саму себя. Более того, прослушать соседнюю физически невозможно, т.к. событие случившееся "там" полностью уничтожает информационный объект "здесь".

Никоим образом. Это свойства экрана, на котором программа вынуждена жить.

На момент создания "шаблонизатора" число и размер объектов неизвестны - это свойства загружаемой информации.

Совершенно избыточно (за исключением отлова системного сигнала Resize). Зачем слушать, если листание производится явными действиями пользователя?

Эти "некоторые панели" и "какие-то объекты", очевидно, должны удовлетворять некоторым требованиям. Независимо от того, "сколько на экране кнопочек". Какими?

maker-rus, у Вас как-то все две крайности: либо теория, либо рисуем нужные кнопочки. Есть и промежуточный слой: программно-независимая концепция кнопочек. Например тот же CUA...

Если Вам проще в терминах шаблонизатора, то примерно так.
Допустим есть идеальный двухстраничный шаблонизатор и, тоже допустим, есть компьютерная программа (любая), которую можно заставить "быть сервером". Никакой связи между ними нет - допустим, их писали два разных человека, ничего не зная о целях и задачах друг друга.
Интересует:
1) Во-первых, хватит ли двух страниц для интерфейса любой разумно организованной программы?
2) Во-вторых, если на первый вопрос ответ положительный, то как организовать автоматическое приведение ввода/вывода любой программы в двухстраничный вид?
3) В-третьих, какими свойствами должен обладать язык обмена информацией между страницами? Достаточно ли одной-единственной операции "вызови вторую страницу с параметрами ..."?
4) В четвертых, если выкинуть наш шаблонизатор и оставить только два этих языка (приведения и обмена), то смогут ли они быть настолько полными, чтобы определить автоматическое создание любого другого шаблонизатора "хоть вертикального, хоть горизонтального, хоть совмещенного"?

Как бы изначально это и не устраивает, ни "индивидуальность", ни "как будет удобнее", что на практике означает "заведомо неудобно". Других проблем в теме почти нет (кроме двух: как в случае заранее неизвестного количества информации ее резать? и как в одних и тех же терминах описать "процесс" для разных сред - html, Tk, Win?).

Реализовать любое "деление" - проблем нет, важно понять, "как делить". Как убрать эту самую "индивидуальность"?

Усложнить себе жизнь: "Тут надо две страницы и мы идем рожать шаблонизатор",- очень просто.

А, вот, можно ли ее упростить: "А, так тут две страницы, значит и думать не над чем!"? (Как мы до этого говорили: "Так это стандартный CUA с его рамкой и менюшками!". Или как Раскин говорил: "Все есть доска объявлений!".

maker-rus, боюсь, все это не по теме. Вы, как и коллега Snake174 утверждаете, что обладая некоторой эрудицией, можно решить частную задачу. Это хорошо. Но в теме поднимается вопрос "общего решения". Т.е. какими свойствами, например, должны обладать "шаблонизаторы" (дались они Вам!), чтобы обеспечить "двустраничную синронизацию"? Кроме, конечно, "они должны обеспечивать двустраничную синронизацию". Насколько они должны быть "информационно замкнуты"? Возможно ли создание единого "интерфейсного элемента", или "синхронизация" должна включать в себя несколько "интерфейсных каналов"? Наконец, тупо, что удобнее: "обрезание по размеру", "масштабирование" или "прокрутка"? Можно ли их совмещать?

P.S. Короче, кто-нибудь задавался мыслью, что две страницы были бы удобнее, чем набор "супер навороченных адаптивно верстаемых всплывающих-выпадающих фигулек"? Чего для сиюминутной реализации этого не хватало?
Добавлено (15 мая 2015, 12:00)
---------------------------------------------
Кстати, обсуждение оказалось не совсем бесполезным.
Я понял, что информация, представляемая на страницах должна быть организована иерархически, что позволит обойтись без прокрутки:
1) обрезание "по окну" можно реализовать с точностью до "узла дерева"
2) масштабирование - свертывание/разворачивание "поддеревьев"

Tymonr, ничего сверх сложного, сам хотел сделать подобную для игры в GURPS по интернету.
Но есть пара НО если собираться с друзьями и играть это очень весело, круто и запоминаемо, если же играть с посторонними то получится такая ситуация (Игрок1: я тебя убиль, Игрок2: нет это я тебя убиль!) Проще говоря maker-rus, будет ли контроль? Кто будет ограничивать действия и выступать в роли рассказчика(ГМа) человек/машина/страус/игроки?

Понятно, что свобода не будет безграничной или что не будет никакого контроля, все это будет и это понятно, что бы не появлялись игроки: убиватор3000 или нагибатор2001, с супер-мега способностями, которые они себе придумают. Подразумевается, что будет совет(модераторы), который и будет следить за правилами игры.

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

Идея бесполезна. Это я говорю вам как игрок в подобные игры на протяжении 9 лет.
1) Во первых никто не станет играть. Только если друзья. Т.к найти людей, желающих играть в ролевых чатах попросту нет. Раньше их было много, сейчас их всё меньше и как правило они тусят на форумах. Тебе понадобится лет 5, чтобы в игре ежедневно играло хотя бы человек 10.
2) Чтобы люди играли в ролевом мире, его надо прописать ОТ и ДО, что займет в свою очередь очень много времени, а что самое интересное, едва ли труды будут вознаграждены. Знаю по своему опыту.
3) Такие чат-игры существуют уже давно. Со своими законами и правилами. И что ты думаешь?) Они все пустеют и витают в облаках и до них никому не хочется тянуться. И только некоторые из них пытаются поддерживать онлайн, при этом отдают 50% реального дня. Готов ты уделять ежедневно проекту по 12 часов и это после того, как всё сделаешь и всё распишешь?)

maker-rus, и...?! Все давно известно и пройдено... Так почему не пересчитать на пальцах "основные моменты"? Как эти Ваши "замечательные фичи" и прочие "шаблонизаторы" обеспечивают "адаптивную верстку"? И нафига нам последняя?

Например, в примере выше (второй рисунок - "Лунолет") параметры нажатой ссылки в левом фрейме честно передавались как параметры вызова CGI-калькулятора в правом. Откуда, в общем-то и родилась идея свести обмен между страницами к некоторому виду "синхронизации".

но не нечто полезное для измышления новых интерфейсов.

maker-rus, половину из того, что он хочет даже на этих конструкторах не сделать в два клика.
А к той же Unity, к примеру, есть куча китов.
(Конечно, к конструкторам есть ещё больше таких китов и уроков по ним, но суть в том, что такое можно сделать на очень многих инструментах)