pixik: Я когда прочитал ваш самый первый вопрос, сразу предположил, что надо на проблему посмотреть на один уровень абстракции выше, ибо техническое решение это частный случай бизнес-решения :)
rsoinvi: По своей природе, люди неодинаковые и не равны. Поэтому автоматизация и роботы - это всего лишь инструмент, чтобы снова одним доминировать над другими. Чтобы мы не изобрели, этими изобретениями кто-то будет пользоваться чтобы управлять другими.
Технологический процесс не косвенно, а совершенно прямо влияет на размеры, энергетические затраты в таком устройстве и следовательно тепловыделению, и следовательно можно повышать частоту.
pixik: Основная проблема, что все, что вы пишете, кажется немного костылем на костыле, потому что вы не описали глобальный смысл этого.
У вас связь между двумя точками организована по модему, и нет возможности связать эти две точки, а инфу нужно гнать? Или у вас странное устройство, которое может только получать данные по ком-порту, а эти данные нужно гнать дальше?
Ну то есть, пока вы не опишите самый верхний уровень возникновения проблемы, советы будут очень "нишевыми", и очень вряд ли кто-то подскажет больше, чем вы уже знаете, разве что он сталкивался именно с такой же проблемой как у вас.
А зачем писать данные в файл?
Почему нельзя писать данные в разные файлы, и передавать по модему уже завершенные? При этом их можно сжать, а если очень надо, объединить с той стороны.
Что это за данные и почему нельзя передавать данные не файлом а другим способом, который больше подходит под передачу фрагментами?
Серожа none: частота работы шины упирается не в это, а в технологический процесс изготовления чипов.
Иначе почему в 90е годы скорость света упиралась в 5-12 мегагерц а сейчас в 4-6 гигагерц?
andrewjabber: mamkaololosha:
Процессоры улучшаются, ускоряются, новые инструкции. Появляются новые возможности - GPU, многопоточность, на порядки вырос объем доступной для анализа памяти.
Кто-бы мог себе представить рабочий кодек x264 в 90-м году на 8086 ?
Коллизии хешей также представляют проблемы, ибо биг-дата, размеры хеш-массивов все больше и больше.
Уже который год хотят архиватор, который юзает GPU (хотя это практически вряд ли имеет смысл), но мало ли.
Филипп Поликаренков: ну так тем более, вы не видите смысла в программировании и в практическом применении ваших знаний на практике. И как только встречается рутинное, неудобное для мозга действие, вы забрасываете. Значит просто не ваше.
Saboteur
@saboteur_kiev Куратор тега Разработка игр
Сервер будет отрабатывать действия по степени их реальной длительности. Если у сервера указано, что переход из комнаты в комнату длится два тика, значит следующий переход он будет выполнять через два тика.
При этом вполне можно добавить команду "стоп", при получении которой сервер сразу очищает весь буфер команд игрока, и ставит статус "стоп".
Очередной "тик" сервера, когда он пробегает по всем действиям игрокам, сервер увидит статус стоп и прервет текущий action игрока согласно очередности.
Что находится по вашей ссылке четко не ясно, но там не совсем то. Там вообще чуть ли не браузерка комнатная. В этом случае все делается иначе.
Пошаговая стратегия, в которой каждый игрок отправляет свои действия. Сервер может просчитывать какие-то действия сразу автоматом (например бои в порядке очереди), а например сами постройки и сбор ресурсов не считает в принципе. Для этого используется схема таймстампов и расчет по последнему обновлению.
Пример такой:
я захожу в казармы и заказываю постройку 1000 лучников. Каждый лучник строится 0.5 секунды. В момент заказа, на сервер отправлена команда 1000 лучников. Сервер получает ее, проверяет ресурсы, и записывает время начала выполнения.
Клиент со стороны игрока может сам по себе рисовать новых юнитов, согласно своим рассчетам, периодически отправляя запросы на обновление информации к серверу.
В момент такого запроса, сервер сравнивает прошлое время с текущим, высчитывает сколько должно было быть построено юнитов, и добавляет их.
Таким образом, расчеты делаются не каждые полсекунды для каждого игрока, а гораздо реже.
Если игрок выйдет из игры - расчет вообще будет выполнен при следующем логине. Либо если другой игрок зайдет в эту комнату (то есть не важно кто вызвал апдейт, главное что расчет информации будет идти строго по запросу). Так снижается нагрузка на сервер от регулярных расчетов всего и всея, но тут не требуется идеальная синхронность.
Взять популярные игры вконтактиках, с онлайном до 100к игроков, там даже начало боев часто определяется "примерно в пределах от 1 сек до 1 мин".
То есть не существует идеальной синхронизации для многих игроков.
Та же линейка, в момент осады (то есть пиковое время, когда в зоне видимости 2-4 тысячи человек), начинала жутко тормозить, а передавались исключительно клики мышкой, ибо в линейке нет такого, как движения стрелочкой, только клик "бежать по координатам x,y", кастануть в игрока ID xx скиллом yy
