[dmp]

1) Фреймворки в инсталлер _НЕ_ включаются. Вы просто не можете ни юридически, ни физически включить фреймворк в инсталляцию, которая делает сама студия. Установите себе вижуал студию 2010 для начала.
2) Почитайте коменты к статье, которую вы прислали. Во-первых, там не дабл, а один буфер Во-вторых, то обычный говнокод (ну блин, вставить в онпаинт вызов свого визуализатора, и не вызывать base - нафиг однозначно).
Что такое двойной буфер, и почему он спасает от "дергания" - я на пальцах объясню. Это считайте асинхронная визуализация (в коде на кодепроджект она синхронаня кстати) Значит, есть у вас буфер, который  растеризируется с периодом, скажем, - одна милисекунда. Если поставить бОльшую задержку - будет бОльшее мерцание (на 100 милисекундах - это будут рывки). А нам нужно плавное движение. Если мы будем рисовать прямо в этом буфере, который непосредственно растеризуется - нам может не хватить быстродействия, и изображение может мерцать. Поэтому, мы все время, с максимально малым периодом растеризируем первый буфер, а делаем визуализацию, с полной предварительной очисткой в так называемом втором. По окончании растеризации второго буфера подается команда, и данные второго буфера просто через memcpy пишутся в первый за фемтосекунды
и где же там в том говнокоде двойной буфер, работающий по этому принципу?

[dmp]

XNA - это бывший Managed DirectX - объектная обёртка над функциями Direct3D и DirectSound (XACT), построенная на платформе .NET

[nikyer]

Фреймворки в инсталлер _НЕ_ включаются. Вы просто не можете ни юридически, ни физически включить фреймворк в инсталляцию, которая делает сама студия. Установите себе вижуал студию 2010 для начала.

Да включаются они туда без проблем. Шаблон проекта инсталлятора, который идёт вместе со студией - далеко не единственный и уж точно не лучший способ создания инсталляционного пакета
А по поводу юридических проблем было бы неплохо, если бы вы подтвердили ваши слова выдержкой из лицензионного соглашения.
Вообще я вам уже предложил решение проблемы, но вы упорно ищете причины, почему этого сделать нельзя

Что такое двойной буфер, и почему он спасает от "дергания" - я на пальцах объясню.

OMG, объясните это лучше разработчикам фреймворка, которые создавали свойство Control.DoubleBuffered

XNA - это бывший Managed DirectX - объектная обёртка над функциями Direct3D и DirectSound (XACT), построенная на платформе .NET

Thanks, cap!

[doom]

2) Почитайте коменты к статье, которую вы прислали. Во-первых, там не дабл, а один буфер Во-вторых, то обычный говнокод (ну блин, вставить в онпаинт вызов свого визуализатора, и не вызывать base - нафиг однозначно).

Плохо вы статью читали. Там описываются и встроенные в фрэймверк механизмы двойного буфера и самописные. Если в комментах кто-то чего-то не понял - это его проблемы.
Собственно, двойной буфер мы использовали еще на Паскале в 10-м классе. Было бы странно, если бы его не было в современных языках, не находите?

[dmp]

было бы неплохо, если бы вы подтвердили ваши слова выдержкой из лицензионного соглашения

Давайте только не будете пытаться пиписками меряться, ок?
Нате пожалуйста:
http://www.gotdotnet.ru/blogs/msdn/6366/
Редистрибуция .NET Framework
Чтобы распространять Dotnetfx.exe со своим приложением, вам потребуется правильно лицензированная копия Microsoft .NET Framework SDK. Кроме того, вам нужно будет подтвердить свое согласие с тем, что любое использование или распространение Dotnetfx.exe с вашим лицензированным продуктом (Licensed Product), как он определен в лицензионном соглашении конечного пользователя Microsoft .NET Framework SDK ("EULA"), осуществляется согласно правилам EULA. Если у вас нет правильно лицензированной копии Microsoft .NET Framework SDK или вы не согласны с условиями EULA, вы не имеете права распространять Dotnetfx.exe и можете применять его согласно правилам лицензионного соглашения конечного пользователя, содержащимся в Dotnetredist.exe.

SDK ставится с Вижуал Студией. У вас вижуал студия лицензионная, или кастрированная express edition? Лично у меня - не express edition. А также, гарантируете ли вы, что пользователь инсталлирует через инсталлятор инсталлятор фреймворка под правами админа (см. ниже - для ClickOnce это неважно)

Вообще я вам уже предложил решение проблемы

Спасибо, но проблемы никакой нет, поскольку это - ClickOnce инсталляция, то есть инсталлятор _САМ_ поставит нужные библиотеки, если в системе они отсутствуют. Нужно только не отключать инет во время инсталлирования. Исключение - затык на XP, где нужно руками поставить xna framework redistributable.
Если же даже и включить в инсталляцию отдельный распространяемый фреймворк.
Вот вам ссылка в тему о ClickOnce: http://www.sql.ru/Forum/actualthread.aspx?bid=34&tid=661072&hl=

Ну и насчет статьи: как я говорил, решение с двойным буфером - это асинхронное рисование. Вы можете сказать, в каком потоке будет вызываться OnPaint - в потоке компонента, т.е. синхронно, или в отдельном, мысль понятна? Свойство DoubleBuffered то немного не то Я лично не могу. И никто не может, потому что это определяет CLR, в каком потоке будет "жить" визуальный компонент - в потоке родителя, или в отдельном. Потому что он реализует интерфейс IInvokable (как то так называется - можете по метаданным посмотреть).  Свойство надо его читать InvokeRequired. Может да, а может нет. А городить свой отдельный new Thread, чтоб отрисовать контрол для игры - это гемор в плане расходования ресурсов (это каждого "жука" из игры загнать в отдельный поток  При этом еще городить блокировки, а где-то провтыкать - может случиться дедлок, потому что они взаимодействуют по модели игры). Оно можно хоть на асме писать под вин, только есть уже специализированные движки, которые по ClickOnce ставятся - зачем велосипед изобретать?

[doom]

Ну и насчет статьи: как я говорил, решение с двойным буфером - это асинхронное рисование. Вы можете сказать, в каком потоке будет вызываться OnPaint - в потоке компонента, т.е. синхронно, или в отдельном, мысль понятна?

Уууу.... Остапа понесло. А какая разница? Причем здесь потоки? Потоки конкретно к буферу и морганию не имеют никакого отношения. Вы можете использовать потоки, а можете и не использовать. В самом простейшем случае, без потоков, фрэймворк сам управляет процессом. Ваше дело рисовать в методе OnPaint, а фреймворк сам потом выведет в передний буфер, по окончании отрисовки в заднем.
Что такое асинхронное рисование в вашем понимании. Оно параллельно чему?

[dmp]

Хотел ответить на твой вопрос - но то уже неважно что причем. Дум, а ты проверял производительность выполнения методов GDI+, и производительность отрисовки? Метрики не хочешь снять?
Вот я просто знаю, что на стандартном фреймворке ты игру не напишешь, чтобы ею гордиться, потому что он не предназначен для Realtime обработки, это просто - надстройка над языком SQL 
Но я не поленился, и скачал исходник. Вот раскрой его хотя-бы 800х600, как у меня игровое окно. Ты увидишь невооруженным глазом очень хреновую отрисовку. Потому что:
1) Рисование на плоскости, скажем, тупо ОДНОГО закрашеного эллипса без вообще ничего - 15 милисекунд.
2) Тупо отрендерить в твой даблбуфер - 4 милисекунды.
Метрики снимаются через экземпляр StopWatch, и выводятся в окошко Output.

Не получится у тебя нормальной анимации на втором. и даже на третьем. и на четвертом. только на XNA. Потому что не будем говорить, что это - просто обвертка под НАТИВНЫМ оптимизированным чисто под графику и аудио. У меня задержки - сотые милисекунд. И есть с чем синхронизироваться (передается аргумент, содержащий последний таймспан после вызова, и все игровое время). И два метода, вызываемые самой средой асинхронно: один - чисто для отрисовки именно в игровом двойном буфере, второй - чисто для расчета данных, используемых для отрисовки.

В итотоге - на обычном фреймворке у тебя будет анимация типа туц...туц...туц..., ну может туцтуцтуц, а на XNA - оооооооооооопа - типа того.
Тот проджект, который ты упомянул - максимум для рисования кастомных кнопочек и фенечек в UI
Вот, покури - полдня, и ты прозреешь: http://rbwhitaker.wikidot.com/xna-tutorials

[dmp]

Еще пару слов в защиту XNA: вот, допустим, заказчик захотел, чтобы мы добавили бомбу. И она взорвалась. И баги, которые попали в фронт взрыва - загорелись. Чтобы не городить тонны дополнительной графики (дополнительно нужно нарисовать минимум 48 горящих жуков - в разных направлениях) - нам нужно написать шэйдер: это - обработчик текстуры, которая потом будет наложена вместо нее. И имплементить алгоритм Glow. На GDI+ вы это не сделаете однозначно (1 сек. на метрику шейдера естественно не катит). Прийдется создавать новый тип файла в Студии под XNA И левым мизинцем правой ноги обрабатываете пикселы. А если захотите создать трехмерную игру - как это сделать без DirectX / OpenGL (она же XNA) я лично не знаю, а на практике - просто создаете в том же 3DS MAXe трехмерную модель, конвертите в FBX и сохраняете. Далее, включаете ее в проект, загружаете, создаете обзор - и все. И практически без программирования.

[dmp]

А вообще - спасибо за сцылко Я и не знал о классах двойного буфера во фреймворке

[dmp]

Кстати, кто пошутил насчет трояна? Вот, игра уже пошла под брендом 2DGames: http://2dgames.ru/ вот ее обзор в самом верху