Недавно я занимался несколько необычным для себя занятием - оптимизировал чужой код. Дело в том, что у одного товарища с фгд имелась почти готовая игра и адские тормоза к ней в придачу. Код для игры писал какой-то очень умный программист с обширными фундаментальными знаниями, навыками ООП, использования паттернов и всякого такого. Код - просто загляденье: всякое там наследование, конфиги в отдельном файле, менеджеры и алгоритмы, которые должны уменьшать нагрузку на процессор. Должны...
На деле, в коде вскрылись велосипеды (привет Найтмарецу с самописным классом поворота), которые вводили Flash в ступор. Вполне верные с теоретической точки зрения оптимизационные алгоритмы, как выяснилось, сильно проигрывают готовым решениям Флеша. Например, каждый кадр считать расстояния между объектами и включать самописную проверку на столкновения тогда, когда эти расстояния становятся достаточно малыми - это теоретически верное решение. Но куда быстрее просто каждый кадр вызывать обычный hitTest.
По-хорошему, всю архитектуру следовало бы написать с нуля, ибо иррациональное неприятие "настоящих программистов" использования Flash IDE в данном случае повлекло за собой написание ресурсоёмкого менеджера анимаций и менеджера глубины... Но будущий хит (я серьёзно) итак уже пилится около полугода, поэтому существующий код был по-возможности переделан - например, я добавил новую систему столкновений и иначе стал просчитывать урон.
А вообще, ради чего я это пишу? Во-первых, вы можете обращаться ко мне по вопросам оптимизации флешек) Во-вторых, этот случай в очередной раз показал мне, что "настоящие программисты" зачастую нифига не стоят, если они ограничены исключительно своими убер-знаниями.
На деле, в коде вскрылись велосипеды (привет Найтмарецу с самописным классом поворота), которые вводили Flash в ступор. Вполне верные с теоретической точки зрения оптимизационные алгоритмы, как выяснилось, сильно проигрывают готовым решениям Флеша. Например, каждый кадр считать расстояния между объектами и включать самописную проверку на столкновения тогда, когда эти расстояния становятся достаточно малыми - это теоретически верное решение. Но куда быстрее просто каждый кадр вызывать обычный hitTest.
По-хорошему, всю архитектуру следовало бы написать с нуля, ибо иррациональное неприятие "настоящих программистов" использования Flash IDE в данном случае повлекло за собой написание ресурсоёмкого менеджера анимаций и менеджера глубины... Но будущий хит (я серьёзно) итак уже пилится около полугода, поэтому существующий код был по-возможности переделан - например, я добавил новую систему столкновений и иначе стал просчитывать урон.
А вообще, ради чего я это пишу? Во-первых, вы можете обращаться ко мне по вопросам оптимизации флешек) Во-вторых, этот случай в очередной раз показал мне, что "настоящие программисты" зачастую нифига не стоят, если они ограничены исключительно своими убер-знаниями.
