- Aroch
- Постоялец
Aroch
1) Не представляю, как оно может дёргаться, если точная дельта компенсирует длительность каждого кадра и устанавливает соответствующий коэффициент движения за прошедший кадр...
2) Как воспроизведение звука зависит от дельты, если буферизированный звук запускается на воспроизведение и играет уже сам, а в поточном только обновляются буферы?
Видимо подход к реализации движка у нас диаметрально противоположный, на то он и есть свой движок, иначе бы проще было взять для своих проектов уже готовый.
Daniil Petrov
> Как воспроизведение звука зависит от дельты, если буферизированный звук
> запускается на воспроизведение и играет уже сам, а в поточном только
> обновляются буферы?
когда куча мелких буферов (отдельных звуков) и заранее не предсказать какой из них в какой момент будет задействован.
> Не представляю, как оно может дёргаться, если точная дельта компенсирует
> длительность каждого кадра и устанавливает соответствующий коэффициент движения
> за прошедший кадр...
а ты не представляй, реализуй да посмотри, оба способа делаются за пару минут.
Aroch
Ладно, возникнет необходимость, реализую
Ghost2
> И что по твоему при этом происходит, если поток выполняется на другом ядре?
Сваливает на нужное ведро, на котором в прошлый раз проводил измерения. Можно как воркэраунд, мол если модель процессора или версия винды ниже указанной, то пишем пользователю рекомендуемые действия(застрелиться, чтоб не мучиться) и что его комп дно и сваливаемся в воркэраунд, чтоб игра не глючила. По скорости просадок почти не будет
*Lain*
> Сваливает на нужное ведро, на котором в прошлый раз проводил измерения
Ну то есть уходит в режим ядра и вызывает решедулинг на некое ядро, которое тоже может быть занято.
Не кажется, что уже попахивает?
Ghost2
> Не кажется, что уже попахивает?
Не важно что говорят злые языки, главное что работает и работает хорошо. У тебя решедулинг все время работает. А тут он лишней раз будет вызываться не особо чаще раза в секунду. Короче обычно можно пренебречь. Короче нефиг расслаблять булки тем, кто не осилил купить новый комп. Идиоты должны страдать ящитаю
Daniil Petrov
> virtual ~Timer(void) {}
Зачем тут void?
Daniil Petrov
> return float((double)FrameLength / 1000000.0f)
Каст int64 к double, потом автокаст float к double и снова явный каст к float. Зачем?
Это первое, что бросилось в глаза. Логику не смотрел, т.к. такой стиль форматирования для меня нечитабелен.
andreyu
Исправил!
Чем <chrono> предпочтительнее <time.h> ?
Daniil Petrov
> Исправил!
> return float((double)FrameLength / 1000000.0);
Да как-то не очень исправилось :)
Я бы сделал так:
return FrameLength / 1000000.0f;
bykabak
<хромо> более крестовый. Тайм.н имеет рандомные характеристики реализации. А хромой частично их специфицирует
*Lain*,
<хромо> более крестовый. Тайм.н имеет рандомные характеристики реализации.
А можно на простом русском языке ?
крестовый - ? ( С++ )
рандомные характеристики реализации - ?
В чём будут неточности или проблемы, если использовать Time.h ? Я понимаю, что написано на C и old School. Но чем чревато ?
andreyu
Исправил :) просто я в таких тонкостях ещё не спец!
Daniil Petrov
> Исправил :) просто я в таких тонкостях ещё не спец!
Теперь пришло время заменить __int64 на int64_t, а так же вспомнить про c++11 и using вместо монструозного std::chrono::high_resolution_clock и Ко.
long long уже в С++11
using только в *.cpp, в заголовках всегда полные имена
andreyu
> Теперь пришло время заменить __int64 на int64_t,
А чем они отличаются?
andreyu
> а так же вспомнить про c++11 и using вместо монструозного std::chrono::high_resolution_clock и Ко.
А как именно его использовать?
Тема в архиве.