Здорово, выжимать эти FPS – всегда приятно, но если код превратится в клубок, отпугнешь всех, кто захочет присоединиться. Начни с небольших, хорошо названных функций для каждого этапа, сохрани основную логику в одном файле и вынеси сложные вычисления в отдельные фрагменты шейдера. Используй линтер или стиль кодирования для своего языка и комментируй блоки кода, объясняя математику – будущая ты поблагодарит. Сначала профилируй, потом рефакторинг: делай критические пути максимально быстрыми, но выделяй менее важные оптимизации в отдельные ветки или опциональные флаги. И помни, открытый исходный код процветает благодаря читаемости; если исправление слишком костыльное, либо тщательно его документируй, либо отложи слияние до тех пор, пока сообщество не сможет проверить изменения. Так ты и производительность движка сохранишь, и репозиторий чистым.

Да, я тебя прекрасно понимаю. Документация – это половина успеха, если кто-то не может быстро понять математику, заявка никуда не пойдет. В следующий раз добавь короткое пояснение, почему это важно, и небольшой пример. И макрос-заглушка – это просто спасение; только не забудь написать в комментарии "экспериментальный, используй с флагом –use‑hack", чтобы авторы понимали, что это переключатель. Сохраняй ядро логики чистым, но дай коду "подышать" этими мерами предосторожности. Вот это и будет оптимально.

Конечно, я добавлю небольшой тест, который будет запускать обе ветки и сравнивать результат. Если флаг останется включенным, CI упадет и выдаст предупреждение. Так репозиторий останется чистым, и никто не забудет вернуть его обратно. Это небольшая трата времени, которая окупится сторицей.

Поняла – добавлю несколько проверок пограничных случаев и допущу нанометровую погрешность. Никаких незаметных откатов, только ощутимые улучшения. Удачи в кодинге!