forum.boolean.name - смена разрешения

Собственно ты сам же себе противоречишь, нет? :)
В том то и дело, что лучше закладывать это все в проекте сразу,
все его возможные функции. Ну вот например если какая-то вешь мне потребуется пару раз, то проще ее расписать как обычно. А если часто и в разных местах - то надо постараться свернуть ее в универсальную функцию и отделить. Конечно все учесть всеравно не получится и многое нужно будет переписать, но это гораздо легче когда изначально все держишь в голове и стараешься писать с учетом этих будущих особенностей.
Относительно важности смены разрешений:
да в своем проекте она у меня запланирована на финальный этап, но
я знаю как именно я собираюсь ее реализовать.
если поделиться опытом коммерческой разработки в студии, чем сейчас кстати и занимаюсь, то тут положение не такое замечательное как при собственной разработке:
так как мне пришлось писать основу механики на блице, потом перегонять код пока он сильно не разросся в пурбейсик (в принципе простое действо но нужно привыкнуть - некоторые функции не перенесены, так как есть сходные пурбейсиковские - например функция и процедура, типы и структуры, и так далее).
после этого пришлось подключать разные вещи для инсталятора, привязывать уже наработанный контент, прикреплять наработки по ГУИ.
после чего я смог получить инсталирующее приложение демонстрирующее только один уровень с механикой.
потом начался процесс добавления меню и еще одного экрана,
через инклюд. позже пришлось все это переписать в единую программу,
тут же требование переключения разрешений - написал, плюс конфиг-файл.
тут как бы не я ставлю условия - а мне дают задачу - нужно то-то и то-то, и не потом, а СЕЙЧАС. так что тут помогает только самоорганизация процесса, потому что постоянно прыгаешь с одного на другое (конечно планирование у нас не идеальное - например замер и тест фпс я бы производил в самом начале процесса - , но я думаю
это не такое уж редкое явление).
тем более заказчиков ведь особо не волнует процент готовности игры, они уже хотят ее посмотреть. и чтобы все основное работало. а основным они считают не то что думает программист - переключается разрешение, уже хорошо, курсоры анимированы - замечательно.
Так что в моем случае это неизбежный гемор, особенно если учесть что
половину вещей пришлось писать и придумывать впервые. Конечно опыт в собственном проекте (даже не одном, просто остальные в очереди на производство, для начала выбран более проработанный (Аватары - тем более что их механика переписывалась раз пять - пришлось выкидывать куски хорошего реалтайм кода, переписывать на походовость, потом упрощать для понимания и лучшего управления, а потом вообще появилась совершенно другая механика. отсюда кстати вывод - нужно иметь концепцию, а к ней подбирать механику. и не пытаться развивать механику противоречащую концепции)) очень помог. Там да - можно переносить все маловажное с точки зрения основного процесса на потом, в коммерческом проекте так скорее всего не получится, если только процесс программирования не контролируется.