hash_map и unordered_map по сути одно и то же. Только в первом случае явно говорится, что сортируются данные по хэшу, а во втором случае говорят, что данные быстро находятся, не уточняя, почему именно. А по сути тот же хэш для сортировки. Не вдавался в подробности, может просто переименовали в наиболее популярный термин.
В файле std_lib_facilities.h есть строчка "#define unordered_map hash_map". Т.е. там unordred_map насильно заменяется на hash_map, который признан устаревшим и удаляемым в скором времени. Надо это строчку закомментить. И в инклюдах заменить hash_map, на unordered_map.
hash_map нужно заменить на unordered_map. Только в одном файле поправить.
У них ещё и qt статически собран. Переделал на сборку с динамическим, чтобы более новый qt использовать, так теперь с библиотекой preprocessor.lib проблемы и не могу догадаться, что это за вообще библиотека... Придётся тоже статически qt пересобрать...
Нормально соберётся только в VC2012, при компоновке с qt пишет, что 1700 версия нужна. И не факт, что соберётся.(
norlin: Ааа, тогда не правильно понял. Тогда с гауссом вы неплохо придумали. Но, если ресурс восстанавливается медленно, то всё равно придётся хранить 100500 коэффициентов для каждого изменившегося участка. Т.е. какая разница, хранить значение в конкретной области или коэффициент для формулы?
norlin: У вас же не "шахматное" представление мира. И ресурсы лежат не в каждой клетке. Допустим, у вас в игре будет миллион игроков. В среднем на игрока будет по 10 "мест" с ресурсами (понятно, что разные игроки могут припереться на одну и ту же территорию и друг у друга ресурсы приворовывать, поэтому и пишем, что в среднем). Получается всего лишь 10 миллионов узлов. Я специально сказал про триангуляцию узлов, чтобы не было связи каждый узел с каждым узлом, а была лишь узел - с несколькими ближайшими. Допустим, каждый узел будет связан с десятком соседних (тут всё зависит от алгоритма триангуляции, но соседей будет от двух до пары десятков максимум). Т.е. нужно хранить 10 миллионов узлов и 100 миллионов рёбер. Даже при корявой реализации вряд ли больше гигабайта займёт - считай даром.
Kris125: Это окно в режиме timeline, оно для видео. Справа кнопка меню, в ней пункт convert to frame animation. После этого будет пункт про зацикливание.
Артем: > extern EthernetClient client;
Это не создание экземпляра класса! Это указание компоновщику, что где-то в другом месте лежит экземпляр класса с этим именем.
Вижу, что табличка не совсем корректна. remove head для vector имеет сложность O(n).
Опять же, есть разница между формальным определением и реализацией. Например, std::deque в плане использования не сильно отличается от std::vector, если пользоваться итераторами или индексами. А вот указателями уже нельзя в deque пользоваться. std::queue вообще реализован в виде фасада над std::deque, поэтому у них все показатели должны быть одинаковы (в пределах свойств интерфейса класса). Но это не к вам претензия, а к составителю таблички.)
В книжках сравнений нет, потому что многое зависит от реализации. Стандарт описывает только интерфейс, а реализовать можно по разному и сложность операций может отличаться. Например Find имеет сложность O(log n) только для отсортированного массива, причём с тем же предикатом, с которым осуществляется поиск.
Егор Марчук: Да, в С надо слово enum перед типом добавлять, чтобы создать переменную.
A, B, C это не переменные, а именованные значения. А variable_1 - переменная, инициализированная значением A. Т.е. вместо абстрактных цифр, можно использовать конкретные имена. Для понятности чтения. В бинарном коде это будут просто целые числа, будто ты написал variable_2 = 1.
Роман Сохарев: В зависимости от применения, разрезать треугольник на три других может не быть нужным. Вместо этого один и тот же треугольник можно внести в две партиции. Опять же, в зависимости от вариантов использования, оверхед от дублирования треугольников может быть гораздо меньше времени дробления треугольников. Сколько-нибудь сложную геометрию в принципе невозможно разрезать пополам, не разрезая(дублируя) треугольников.
Роман Сохарев: Коллизии будут всегда на любой более-менее не квадратной геометрии. С этим приходится жить и это не страшно.
Если есть какие-то особенности в топологии, то можно привязываться к ним, чтобы оптимизировать разбиение. В принципе, плоскости могут даже не быть ортогональными и выровненными по глобальным осям, но это уже сложнее равномерно разбить.
Если нет никаких "особенностей", то можно резать ровно пополам и быть уверенным, что всё делаете правильно.
Николай: Да. Ещё можно построить BSP дерево или "матрицу" для всего уровня, чтобы разграничить все объекты по областям и проверять пересечения не между всеми объектами, а только между теми, которые находятся в одной области.
Подозреваю, что Unity или box2d делают это по умолчанию.
Кстати, даже если по честному считать пересечения полигональных мешей, то сперва лучше проверять пересечение сфер или габаритных контейнеров.
