A-tit indd

Паттерны программирования игр
— Паттерны оптимизации
359
void ParticleSystem::activateParticle(int index)
{
// 3 6!
assert(index >= numActive_);
// 6 6 
// $6, .
Particle temp = particles_[numActive_];
particles_[numActive_] = particles_[index];
particles_[index] = temp;
numActive_++;
}
Для деактивации частицы требуется обратный про-
цесс:
void ParticleSystem::deactivateParticle(int index)
{
// 3 6!
assert(index < numActive_);
numActive_--;
// 6 6 
// $6,
// .
Particle temp = particles_[numActive_];
particles_[numActive_] = particles_[index];
particles_[index] = temp;
}
У очень многих разработчиков (включая меня) выра-
боталась аллергия на перемещение чего-то в памяти. Пе-
ретаскивание набора байтов 
ощущается
намного слож-
нее, чем простое переназначение указателей. Но если 
прибавить сложность 
переходов
по указателям, то ока-
зывается, что интуиция нас подводит. В некоторых слу-
чаях намного дешевле действительно перемещать дан-
ные в памяти, так как кэш останется заполненным.
Есть еще небольшое приятное последствие хранения 
частиц 
отсортированными
по состоянию активности —
нам вовсе не нужно хранить логическую переменную. 
Ее можно заменить позицией в массиве и счетчиком 
то прогнозирование бу-
дет неверным.
Когда случается 
ошибка, процессору 
приходится прерывать 
выполнение инструк-
ций, к которым он уже 
приступил (
очищать 
конвейер
), и начинать 
сначала. Степень влия-
ния на производитель-
ность зависит от кон-
кретного железа, 
но многие программи-
сты все же пытаются из-
бегать контроля потоков 
в особо важных частях 
кода.
Это небольшое напоми-
нание о необходимости 
документирования
, когда 
вы принимаете такие 
решения.

---