Снова вспоминается программирование игр и мой опыт создания ЗБ-мира под DOS. Чтобы рассчитать текущее положение игрока, видимую область, стены, каркас стен, которые должны быть прорисованы, да еще и наложить на них текстуры, необходимо совершить множество математических расчетов. Когда я попытался сделать это в реальном времени, то получились большие задержки. Оптимизация математики была бесполезна и не привела бы ни к чему хорошему.

Расчет сцены зависел от разрешения экрана. Тогда для игр разрешение 320x200 считалось вполне приемлемым, особенно для жанра 3D Action. Итак, для расчета сцены запускался цикл из 320 шагов (разрешение по горизонтали), а на каждом этапе просчитывалась соответствующая вертикальная линия, видимые области на этой линии и т. д. Надо понимать, что каждая вертикальная линия расположена под каким-либо углом. Для упрощения расчетов я использовал небольшой угол обзора. Для расчета градусов, линий и других элементов применялся метод трассировки лучей, который требует геометрических расчетов с функциями косинусов, синусов, тангенсов и т. д. Выполнение одних только этих функций отнимает немало процессорного времени.

В то время у меня был Pentium 100, а для него геометрические расчеты были слишком сложны. Оптимизировать их нельзя, потому что без них никуда не денешься. Тогда я воспользовался Интернетом и начал искать какую-нибудь информацию. В те времена Всемирная сеть только начала распространяться в России, поэтому на русском языке ничего найти не удалось, но на английском мне на глаза попался один интересный документ. В нем предлагалось произвести сложные расчеты и округлить полученные результаты еще на этапе загрузки программы (уровня).

Проанализировав код, я нашел те участки, которые можно было вынести на этап старта программы. Получалось, что основные расчеты делались заранее формировалась таблица выходных значений, а во время просчета сцены из таблицы бралось самое близкое значение. Конечно же, рассчитанные значения для 0-360 градусов займут в памяти много места, поэтому был выбран определенный шаг.

Таким образом, скорость была повышена за счет снижения качества графики Хорошо, что это была графика и в ней расчеты с округлением допустимы. При работе с деньгами округление может обойтись штрафами и даже лишением работы.

Не думайте, что в офисных программах округление не используется из-за высокой точности расчетов. Однажды я писал программу сбора информации с производственного оборудования, и она должна была строить график изменений. Опять же, для его построения можно использовать, и я использовал приблизительные расчеты и заранее рассчитанные значения Когда пользователь выбирал определенный период, и не было необходимости в отображении данных в реальном времени, то график формировался четко. Так как человеческий глаз не может замечать изменения в один пиксел на движущемся графике, погрешность между реальными расчетами и приближенными не была заметна. Об этом знал только я, но, конечно же, никому не сказал.

Именно при работе с графикой и звуком чаще всего необходимы высокие скорости. Если звук в офисных приложениях используется редко, а если и используется, но не требует высокой производительности, то графика нужна часто и желательно, чтобы она выводилась в реальном времени.

Представляете, что графики биржевых котировок прорисовываются с большой задержкой. Большинство брокеров и маклеров просто обанкротились бы.

2.7. Процедуры и функции || Оглавление || 2.9. Лишние прорисовки экрана


Delphi в шутку и всерьез: что умеют хакеры



Новости за месяц

  • Декабрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31