Я бы так не делал.
Первое — я бы использовал умные указатели.
Второе — делал бы методы с говорящими именами. player->SitInCar( car ); К тому же в этом случае легко реализовать дополнительную логику.
Разные преложения по разному загружают процессор и видео. И игры не исключение. Где-то все упирается в процессор, где-то в видеокарту. Зависит от конкретных видео и проца, а так же от настроек игры. Ну и от самой игры, конечно же.
Если и графику переложить на процессор, то ресурсов на физику, логику, звук и тд останется меньше и, как результат, получим еще менее качественные игры.
По поводу обмена значений двух переменных без использования третей. В оригинале значения были целыми, а весь смысл был в не использовании дополнительной памяти. А кто знает, что в реальности делает a, b = b, a?
И вообще через третью переменную быстрее: docs.python.org/release/2.3.3/tut/node12.html 10.10
Хотелось бы добавить о причинах рассинхронизации. Кроме упомянутых в статье случаев с ошибками округлений чисел с плавающей точкой ( лечится ), и ошибкой не инициализированной переменной ( борются, повышая культуру программирования ), есть еще одна неприятная причина рассинхронизации. Когда симуляция начинает зависеть ( часто очень не явно ) от пользовательского слоя. Простейший случай — в симуляции взяли позицию не у мирового объекта ( который участвует в симуляции ), а у клиентского.
Потому что дорого! Пусть в текущий момент проходит 100тыс игр в SC2. Где взять 100тыс серверов? Ну хорошо, пусть один сервер держит 5игр ( там же симуляция ). 20тыс серверов — это огромные и очень дорогие мощности.
Хорошая статья!
С рассинхронизациями действительно сложно бороться, однако вполне возможно. Для этого должен быть механизм записи реплеев. А также контрольную сумму нужно уметь считать по-объектно. Да, при реальной игре этого не надо ( тормозит ), но для починки бага — самое оно.
По поводу борьбы с рассинхронизацией у конечного пользователя. Можно в систему p2p ввести сервер, который будет хранить корректное состояние мира ( которое подтвердили все клиенты ). Пусть оно будет не часто обновляться, однако в случае рассинхрона, можно откатить всех клиентов на него и продолжить игру.
Где-то близко проблема reconnect'а. Она также решается заливанием на клиента полного состояния мира и запуска симуляции. Тут конечно зависит от размера мира. Но думаю даже пару мегабайт можно себе позволить передать. Можно без сервера, каждый клиент передает свою часть мира…
С задержкой можно бороться так. Клиент кликает, юниты идут сразу, но на клиенте, локально. Потом они уже «подстраиваются» под симуляцию. Что-то типа асинхронного движения. Вполне работает :)
У меня есть вопрос по Python, который давно меня мучает. У меня есть проект на Python. Возникает необходимость поменять входные параметры некоторой функции. Как определить все места, где она вызывается?
Как я понял ваш совет, он аналогичен просто глобальным функциям MYNEW(...), MYDELETE(...). Но у меня нет возможности поменять все new/delete в проекте на них. Плюс надо чтобы сторонние библиотеки, stl и тд использовали наши переопределенные new/delete
Для поиска утечек можно использовать внешние программы: DevPartner Studio, Intel Parallel Inspector. К сожалению ни одна из них не смогла корректно посчитать утечки в C#,C++/CLI, C++ среде.
Можно использовать _CrtSetDbgFlag(), но не удобно с ним работать + проблемы со статическими глобальными переменными.
Visual Leak Detector — не пробывал, надо попробывать.
Еще мы используем nedmalloc, и для этого нам нужны свои глобальные new/delete.
Первое — я бы использовал умные указатели.
Второе — делал бы методы с говорящими именами. player->SitInCar( car ); К тому же в этом случае легко реализовать дополнительную логику.
Если и графику переложить на процессор, то ресурсов на физику, логику, звук и тд останется меньше и, как результат, получим еще менее качественные игры.
И вообще через третью переменную быстрее: docs.python.org/release/2.3.3/tut/node12.html 10.10
С рассинхронизациями действительно сложно бороться, однако вполне возможно. Для этого должен быть механизм записи реплеев. А также контрольную сумму нужно уметь считать по-объектно. Да, при реальной игре этого не надо ( тормозит ), но для починки бага — самое оно.
По поводу борьбы с рассинхронизацией у конечного пользователя. Можно в систему p2p ввести сервер, который будет хранить корректное состояние мира ( которое подтвердили все клиенты ). Пусть оно будет не часто обновляться, однако в случае рассинхрона, можно откатить всех клиентов на него и продолжить игру.
Где-то близко проблема reconnect'а. Она также решается заливанием на клиента полного состояния мира и запуска симуляции. Тут конечно зависит от размера мира. Но думаю даже пару мегабайт можно себе позволить передать. Можно без сервера, каждый клиент передает свою часть мира…
С задержкой можно бороться так. Клиент кликает, юниты идут сразу, но на клиенте, локально. Потом они уже «подстраиваются» под симуляцию. Что-то типа асинхронного движения. Вполне работает :)
V003. Unrecognized error found на куче файлов на строчке #include «stdafx.h»
Пока анализ продолжается, по оценке он займет 3-4часа.
Можно использовать _CrtSetDbgFlag(), но не удобно с ним работать + проблемы со статическими глобальными переменными.
Visual Leak Detector — не пробывал, надо попробывать.
Еще мы используем nedmalloc, и для этого нам нужны свои глобальные new/delete.