Как что?
Удобней, чем SkyDrive.
С пикасой не сравнивал, но Яндекс недавно свою программу сделали, которая сейчас в beta-стадии. Не пробовал.
Когда мне нужно загрузить 100500 картинок, пользуюсь плагином для ФФ, для 1-20 картинок — стандартным флеш загрузчиком.
Для отдельных картинок (чтобы не пользоваться другими картинкохостингами) сделал себе загрузчик через апи и повесил на GAE.
В Windows есть втроенный планировщик либо можно поставить nncron.
Для копирования файлов достаточно склепать маленький bat-ник и заставить планировщик тягать его по таймеру.
Насчет обратного обновления. Это означает копирование из папки дропбокса или синхронизациб между компьютерами?
Если первое, возможно, это тоже решается с помощью батника. Или же сценарием на более продвинутом языке. Виндовсь вроде нативно умеет выполнять .vbs.
Зависит от системы. Линк на папку не поможет. Даже жесткая ссылка на файл в WinXP не сработает.
Как с этим в никсах и Vista/Win7 — не знаю.
В любом случае можно настроить планировщик на копирование этих самых сохранений в соответствующую папку. При этом, что радует, сохраняются все ревизии файлов.
Хостинг простейший, но не самый долговечный. Имхо, лучше html+js+css выкладывать на народ.ру, если предполагается, что странички будут жить больше пары недель.
Я отличаю классы от объектов, я просто неверно выразился, за что прошу извинить. Уточняю: таймер только один, других копий нет и не предусмотрено. насчет статических переменных и функций — спасибо, приму к сведению, я пока не до конца вник во все тонкости с++, и пользовался лишь простейшими классами да виртуальными методами.
Все равно не понял. Попробую объяснить не понятно, что подразумевается под тем, что функция QueryPerformanceCounter загружает процессор. Если имеется в виду, что бесконечный цикл, нагружает процессор на 100 процентов, то причем тут QueryPerformanceCounter? Если же то, что на вызов QueryPerformanceCounter затрачивается много времени, то причем тут Sleep?
В мейнлупе если останутся только обработчики сообщений — будет нормальная нагрузка на процессор. Если же туда добавить тяжелых функций типа QueryPerformanceCounter — загрузка будет 100%, слип будет давать возможность другим процессам пользоваться процессорным временем. Насчет того, что будет, если убрать только таймер, оставив все остальное в цикле, ничего не могу сказать, не пробовал, и пока что нет возможности попробовать (нахожусь вдали от компилятора), но разницы это не сделает — таймер нужен, и только он уже грузит на 100% (ибо с таймера начинал движок писать и эта проблема как раз и возникла).
в таком случае я вообще не вижу смысла в этом классе, т.к. тебе достаточно синхронизировать кадры, а все остальное будет базироваться на константе дельта t. Вся эта морока, с измерением разницы и т.д. и т.п.
Мы не до конца поняли друг друга: я имел в виду, что отрезки времени дискретны, но имеют разную длину, т.е. событие «через 0.5 секунды» выполняется не через 0.5 секунды (непрерывное время), а через 0.5+х секунд, где х зависит от величины последнего временного отрезка. Например, если временные отрезки будут следующие: 0.1, 0.2, 0.3, то событие выполнится только через 0.6 секунд. Проще говоря, дельта t не константа.
От автора:
Я считаю, что в классы нужно упаковывать как объекты, которых будет заведомо несколько, так и объект, который будет точно уникален. Насчет апи-вызовов — точность таймера требует жертв.
* что означает вот эта фраза: «сильно загружают процессор, имеет смысл ограничить чатоту кадров, выполняя Sleep»?
В конце каждого кадра выполнять функцию Sleep(x), таким образом частота кадров никогда не превысит 1000/x.
* «использования в игровом движке (а это значит, что помимо отмерения отрезков времени нам необходимо обеспечить работу событий, возникающих через заданное время)» как из одного следует другое?
К примеру таймер для профайлинга по идее должен только замерять время выполнения конкретного участка кода. В то время как в играх всегда будут события, которые должны возникнуть через некоторое время (будь то конец уровня, или снятие наложенного проклятия с игрока, к примеру).
* «Самым логичным решением» почему? Нужно рассмотреть другие варианты, например: GetTickCount(), clock(), описать все плюсы и минусы.
Поначитался геймдева да мсдн, везде для точного таймера рекомендовали именно эти функции
* странно использование плавающей арифметики, чем обусловлен такой выбор? Почему не целочисленная арифметика?
Физика игры (даже простейшие движения по прямой) базируется на реальных физических законах скорость+ускорение во времени, поэтому числа с плавающей запятой больше подходят, как «более физические», т.е. мы можем описывать скорость в пикс./сек. исходя из того, что 1.0 = 1 секунда, и не используя более точное, но слишком абстрактное для данных условий число тиков
* «обратите внимание: время здесь не замеряется» почему?
Дабы можно было вызвать эту функцию несколько раз, на каждом из которых результат был бы одинаков (если замерять каждый раз время, то оно, разумеется, будет течь между вызовами, и нарушится общая картина событий по таймеру). В моем движке время течет дискретно, на каждом тике все события, связанные со временем обновляются сразу и результат отображается на экран. Т.к. Время обновления таймера взято очень маленькое, визуально это смотрится как непрерывность.
теперь по поводу стрельбы:
Насчет этого могу сказать лишь то, что доступно много и разных способов реализации, а у меня это сделано через менеджер событий из-за мой попытки отделить события по таймеру от всего остального, дабы классы оружия, менеджера оружий и игрока не хранили лишнюю информацию насчет времени и не обновляли ее (у меня только 2 раза используется взятие времени — для обновления физики, и для обновления событий). В будущем возможно пересмотрю позицию.
Ответ:
1. спасибо, попробую учесть в будущих правках.
2. мне нет особого смысла брать мультиплатформенностью, движок узкопрофильный все же, к тому же пишу я его скорее для «чего-нибудь написать», нежели для особой пригодности его (впрочем, если так выйдет, буду рад). И еще, стараюсь отделить по возможности мух от котлет и по идее обеспечение кроссплатформенности не должно стать проблемой в будущем, т.к. сейчас я сосредоточен в основном на механизмах работы игровой логики, а все остальное, что было реализовано — инструмент для тестирования этой самой логики.
Нет, я пока добрался только до GAE, о портировании еще не задумывался. Да и если буду портировать, разве что только на Tcl, других языков не знаю совсем. :(
Удобней, чем SkyDrive.
С пикасой не сравнивал, но Яндекс недавно свою программу сделали, которая сейчас в beta-стадии. Не пробовал.
Когда мне нужно загрузить 100500 картинок, пользуюсь плагином для ФФ, для 1-20 картинок — стандартным флеш загрузчиком.
Для отдельных картинок (чтобы не пользоваться другими картинкохостингами) сделал себе загрузчик через апи и повесил на GAE.
Для копирования файлов достаточно склепать маленький bat-ник и заставить планировщик тягать его по таймеру.
Насчет обратного обновления. Это означает копирование из папки дропбокса или синхронизациб между компьютерами?
Если первое, возможно, это тоже решается с помощью батника. Или же сценарием на более продвинутом языке. Виндовсь вроде нативно умеет выполнять .vbs.
Как с этим в никсах и Vista/Win7 — не знаю.
В любом случае можно настроить планировщик на копирование этих самых сохранений в соответствующую папку. При этом, что радует, сохраняются все ревизии файлов.
Я отличаю классы от объектов, я просто неверно выразился, за что прошу извинить. Уточняю: таймер только один, других копий нет и не предусмотрено. насчет статических переменных и функций — спасибо, приму к сведению, я пока не до конца вник во все тонкости с++, и пользовался лишь простейшими классами да виртуальными методами.
В мейнлупе если останутся только обработчики сообщений — будет нормальная нагрузка на процессор. Если же туда добавить тяжелых функций типа QueryPerformanceCounter — загрузка будет 100%, слип будет давать возможность другим процессам пользоваться процессорным временем. Насчет того, что будет, если убрать только таймер, оставив все остальное в цикле, ничего не могу сказать, не пробовал, и пока что нет возможности попробовать (нахожусь вдали от компилятора), но разницы это не сделает — таймер нужен, и только он уже грузит на 100% (ибо с таймера начинал движок писать и эта проблема как раз и возникла).
Мы не до конца поняли друг друга: я имел в виду, что отрезки времени дискретны, но имеют разную длину, т.е. событие «через 0.5 секунды» выполняется не через 0.5 секунды (непрерывное время), а через 0.5+х секунд, где х зависит от величины последнего временного отрезка. Например, если временные отрезки будут следующие: 0.1, 0.2, 0.3, то событие выполнится только через 0.6 секунд. Проще говоря, дельта t не константа.
Я считаю, что в классы нужно упаковывать как объекты, которых будет заведомо несколько, так и объект, который будет точно уникален. Насчет апи-вызовов — точность таймера требует жертв.
В конце каждого кадра выполнять функцию Sleep(x), таким образом частота кадров никогда не превысит 1000/x.
К примеру таймер для профайлинга по идее должен только замерять время выполнения конкретного участка кода. В то время как в играх всегда будут события, которые должны возникнуть через некоторое время (будь то конец уровня, или снятие наложенного проклятия с игрока, к примеру).
Поначитался геймдева да мсдн, везде для точного таймера рекомендовали именно эти функции
Физика игры (даже простейшие движения по прямой) базируется на реальных физических законах скорость+ускорение во времени, поэтому числа с плавающей запятой больше подходят, как «более физические», т.е. мы можем описывать скорость в пикс./сек. исходя из того, что 1.0 = 1 секунда, и не используя более точное, но слишком абстрактное для данных условий число тиков
Дабы можно было вызвать эту функцию несколько раз, на каждом из которых результат был бы одинаков (если замерять каждый раз время, то оно, разумеется, будет течь между вызовами, и нарушится общая картина событий по таймеру). В моем движке время течет дискретно, на каждом тике все события, связанные со временем обновляются сразу и результат отображается на экран. Т.к. Время обновления таймера взято очень маленькое, визуально это смотрится как непрерывность.
Насчет этого могу сказать лишь то, что доступно много и разных способов реализации, а у меня это сделано через менеджер событий из-за мой попытки отделить события по таймеру от всего остального, дабы классы оружия, менеджера оружий и игрока не хранили лишнюю информацию насчет времени и не обновляли ее (у меня только 2 раза используется взятие времени — для обновления физики, и для обновления событий). В будущем возможно пересмотрю позицию.
Попробуйте скомпилить оригинальный, нераскрашенный код (по ссылкам http://s-c.me/5234/s и http://s-c.me/5232/s). Если заработает, тогда сменю раскрашивалку.
От автора: «компилилось под msvs2008sp1 redist».
1. спасибо, попробую учесть в будущих правках.
2. мне нет особого смысла брать мультиплатформенностью, движок узкопрофильный все же, к тому же пишу я его скорее для «чего-нибудь написать», нежели для особой пригодности его (впрочем, если так выйдет, буду рад). И еще, стараюсь отделить по возможности мух от котлет и по идее обеспечение кроссплатформенности не должно стать проблемой в будущем, т.к. сейчас я сосредоточен в основном на механизмах работы игровой логики, а все остальное, что было реализовано — инструмент для тестирования этой самой логики.
Спасибо!