H@NON, вот у тебя в этом коде используется стабилизатор из стандартных templat'ов в Blitz3D\IDE. Так вот я его тоже использую, его принцип таков: Указывается постоянный UPS, и далее если из-за фпс, упс падает, то не рендерить данный цикл, пока упс не отстабилизируется до заданного. Походу мы все говорим практически ободном.
В чём выигрывает такая система, чем то как делал stone_evil или jimon умножая скорость логических действий, на опр коэфицент стабилизации, тем что есть такие операции которые Только выводят, например Glow или DoF, там есть CopyRect и RenderWorld которые задуйствованы Больше 1 раза, при этом если упс падает, мы не делаем эти действия и не выводим картинку, тем самым производительность вырастет по сравнению с DeltaTime.
|
Именно этот конфликт и решается с помощью синхронизации. Ессно, применять ёё, как и всё остальное, нужно с умом. ФПС выше астрономических величин- 60? 70? 100? - можно и залочить, чтоб не прыгал, а ФПС ниже 20- лочить отключением синхронизации необходимо- ибо тормоза и рывки хуже плавного замедления.
|
ИМХО: нужно заранее думать над игрой, во первых минимальные требования, во вторых, если я на своём 700 дюроне с 4к жирафом и 512 озу, буду пытаться играть в дуум3 то что со мной поделаешь, ну не удастся и всё, а играть на скоросте в 10 раз меньше нормальной с 10фпс, это не игра.
Вот мне нравиться Source Engine, там тот же SiN Episodes идёт на моём (бывшем, ы обновил железо!) компе, и может идти с более крутыми настройками на крутых машинах, при этом местами игра просто идёт гладенько, но местами и тормозит.
Я считаю что Самое важное это стабильность логики, а не изображения. И от сюда мы имеем, что если у нас оптимальная графика, то не придётся ограничивать игрока фпсом, а если у него машина слабая, то он будет уверен, что этот вот монстр, будет бежать это время, и игрок успеет сделать финт который требует затрат времени, где на разных машинах оно будет одно и тоже.