Вот на таком эпическом названии остановился мой выбор). В основном такая идея была продиктована большой схожестью названий и возможностей элементов библиотеки с технологией Windows Presentation Foundation. Это как бы должно с первых шагов подвести пользователя к мысли что все просто и знакомо в обращении. В библиотеке есть еще места которые можно в перспективе рефакторить для еще большей схожести, но всему свое время. У меня ушло очень много времени на создание сайта на сильверлайте. Именно сильверлайт я выбрал по причине отсутствия необходимости учить для меня что то новое, т.к. я ни когда не работал в области web и это мой первый сайт.
Пересекая очередной финиш, хочу выразить огромную благодарность за помощь, советы и творческие обсуждения своим друзьям:
- Сергей Лутай - блог - твиттер
- Сергей Звездин - блог
- Ильшат Хабибуллин
Спасибо ребят).
Сам сайт продукта http://generalpf.ru
четверг, 10 февраля 2011 г.
Comments for Vic Gundotra message:"#feb11 Two turkeys do not make an Eagle"
Забавный мужик этот Vic Gundotra. Он является вице-президентом по разработкам в Google. В своем блоге он оставил такое сообщение "#feb11 Two turkeys do not make an Eagle", что по нашему звучит как "11 февраля Из двух индеек не получится Орла". Мало кто сомневается, что речь идет о возможном альянсе Microsoft и Nokia.
Заерзали значит, это хорошо). На уровне вице-президента публичные цирки происходят.
"Кроме мяса, индейки дают много ценного пуха и пера" [Домашняя индейка], а орел?))).
У одной индейки богатый опыт в области мобильных решений, правда ОС не сахар, видимо софт не их занятие. У другой большой потенциал с софтом и возможностями. Есть повод для переживаний).
Заерзали значит, это хорошо). На уровне вице-президента публичные цирки происходят.
"Кроме мяса, индейки дают много ценного пуха и пера" [Домашняя индейка], а орел?))).
У одной индейки богатый опыт в области мобильных решений, правда ОС не сахар, видимо софт не их занятие. У другой большой потенциал с софтом и возможностями. Есть повод для переживаний).
пятница, 14 января 2011 г.
XNA, GarbageCollector, SynchronizeWithVerticalRetrace, IsFixedTimeStep – используйте правила и будет вам счастье …
И так по порядку. Что значат эти термины:
SynchronizeWithVerticalRetrace – public properties GraphicsDeviceManager. Gets or sets a value that indicates whether to sync to the vertical trace (vsync) when presenting the back buffer (MSDN). Эта штука синхронизирует переключение back buffers с частотой обновления экрана монитора. Зная, как технически происходит обновление изображения на мониторе, можно сказать, что включение данного параметра нужно для предотвращения разрезания изображения при смене кадров.
IsFixedTimeStep - public properties Microsoft.Xna.Framework.Game. Gets or sets a value indicating whether to use fixed time steps (MSDN). Параметр, отвечающий за включение или отключение режима, который отвечает за ограничение частоты вызовов метода Update.
GarbageCollector – системный сборщик мусора. Конкретно нас будет интересовать класс System.GC .
Как работают SynchronizeWithVerticalRetrace и IsFixedTimeStep. Есть четыре сочетания данных флагов:
1. SynchronizeWithVerticalRetrace = false и IsFixedTimeStep = false
В этом случае графические буферы меняются по мере их рисования, не дожидаясь синхроимпульса, синхронно вызывается метод Update.
Особенности: обычно в приложении не требуется вызывать метод Update с максимально возможной частотой. При SynchronizeWithVerticalRetrace = false мы имеем возможность измерять значение fps превышающее частоту обновления монитора. Активно пользуюсь при отладке приложения.
2. SynchronizeWithVerticalRetrace = false и IsFixedTimeStep = true
В этом случае мы можем дополнительно контролировать частоту вызова методов Update и Draw и устанавливать фиксированный интервал через свойство TargetElapsedTime.
Особенности: сомнительное удовольствие применять данный подход повсеместно. Он подходит, для каких либо исключительных случаев, в которых его применение полностью обоснованно. Не пользуюсь.
3. SynchronizeWithVerticalRetrace = true и IsFixedTimeStep = false
Тут все просто, обновляем, рендерим, ждем синхронизации, меняем back buffers и по новой.
Особенности: невозможно измерить значение fps выше частоты обновления монитора. Пользуюсь.
4. SynchronizeWithVerticalRetrace = true и IsFixedTimeStep = true
Интересный случай. Если время синхронизации меньше IsFixedTimeStep, то ждем следующей синхронизации и только после этого выполняется Update и Draw. Если же время синхронизации больше IsFixedTimeStep, то по факту выполнения синхронизации не медленно выполняется Update и Draw. Эдакий хромающий ослик без одной ноги).
Особенности: теряюсь в догадках где это можно применить, точно не мой профиль). В некоторых случаях при значениях TargetElapsedTime/ vsyncTime = 1.5f (примерно) можно на глаз заметить не равномерное обновления экрана. Не пользуюсь.
Уже теплее. И так, о главном). Если вы написали приложение|игру используя XNA, применили из вышеописанных приемов 1й или 3й и в вашем приложении наблюдаются периодические задержки, а вы к тому же нечайно вспомнили «слова которые нельзя произносить» - Garbage Collector ))). Главное не паникуйте, при этом не обязательно писать в различных форумах Ваше мнение о .net и XNA, крутости и преимуществах C++. Все это от нервов, нервы от не знания, не знание от лени, лень от глупости, но это лечится.
Как пользуется Garbage Collector’ом рядовой «пользователь» Visual Studio? Да ни как. Он полагается на настройки по умолчанию для Garbage Collector’а. Настройки по умолчанию рассчитаны на так называемые бизнес приложения, для динамичной работы с DirectX нужно доработать.
По умолчанию Garbage Collector выполняет освобождение памяти в любом случае не синхронно с работой Update. Мертвый груз копится и освобождается в непредсказуемый, для логики вашего приложения, момент. Самый простой выход – это делать в начале очередного Update:
System.GC.Collect(1);
Где 1 это номер поколения, значение подобрано экспериментально.
С другой стороны может быть не целесообразно перегибать палку и выполнять сборку мусора 60 раз в секунду при включенной синхронизации (если у монитора такая рабочая частота обновления экрана) или более 60 раз при выключенной синхронизации.
По этому можно сделать так:
Возможно не везде будет полезным применение потока, это просто мой случай.
GarbageCollector gc = new GarbageCollector(20);
т.е. при частоте монитора 60 Гц - 3 раза в секунду.
SynchronizeWithVerticalRetrace – public properties GraphicsDeviceManager. Gets or sets a value that indicates whether to sync to the vertical trace (vsync) when presenting the back buffer (MSDN). Эта штука синхронизирует переключение back buffers с частотой обновления экрана монитора. Зная, как технически происходит обновление изображения на мониторе, можно сказать, что включение данного параметра нужно для предотвращения разрезания изображения при смене кадров.
IsFixedTimeStep - public properties Microsoft.Xna.Framework.Game. Gets or sets a value indicating whether to use fixed time steps (MSDN). Параметр, отвечающий за включение или отключение режима, который отвечает за ограничение частоты вызовов метода Update.
GarbageCollector – системный сборщик мусора. Конкретно нас будет интересовать класс System.GC .
Как работают SynchronizeWithVerticalRetrace и IsFixedTimeStep. Есть четыре сочетания данных флагов:
1. SynchronizeWithVerticalRetrace = false и IsFixedTimeStep = false
В этом случае графические буферы меняются по мере их рисования, не дожидаясь синхроимпульса, синхронно вызывается метод Update.
Особенности: обычно в приложении не требуется вызывать метод Update с максимально возможной частотой. При SynchronizeWithVerticalRetrace = false мы имеем возможность измерять значение fps превышающее частоту обновления монитора. Активно пользуюсь при отладке приложения.
2. SynchronizeWithVerticalRetrace = false и IsFixedTimeStep = true
В этом случае мы можем дополнительно контролировать частоту вызова методов Update и Draw и устанавливать фиксированный интервал через свойство TargetElapsedTime.
Особенности: сомнительное удовольствие применять данный подход повсеместно. Он подходит, для каких либо исключительных случаев, в которых его применение полностью обоснованно. Не пользуюсь.
3. SynchronizeWithVerticalRetrace = true и IsFixedTimeStep = false
Тут все просто, обновляем, рендерим, ждем синхронизации, меняем back buffers и по новой.
Особенности: невозможно измерить значение fps выше частоты обновления монитора. Пользуюсь.
4. SynchronizeWithVerticalRetrace = true и IsFixedTimeStep = true
Интересный случай. Если время синхронизации меньше IsFixedTimeStep, то ждем следующей синхронизации и только после этого выполняется Update и Draw. Если же время синхронизации больше IsFixedTimeStep, то по факту выполнения синхронизации не медленно выполняется Update и Draw. Эдакий хромающий ослик без одной ноги).
Особенности: теряюсь в догадках где это можно применить, точно не мой профиль). В некоторых случаях при значениях TargetElapsedTime/ vsyncTime = 1.5f (примерно) можно на глаз заметить не равномерное обновления экрана. Не пользуюсь.
Уже теплее. И так, о главном). Если вы написали приложение|игру используя XNA, применили из вышеописанных приемов 1й или 3й и в вашем приложении наблюдаются периодические задержки, а вы к тому же нечайно вспомнили «слова которые нельзя произносить» - Garbage Collector ))). Главное не паникуйте, при этом не обязательно писать в различных форумах Ваше мнение о .net и XNA, крутости и преимуществах C++. Все это от нервов, нервы от не знания, не знание от лени, лень от глупости, но это лечится.
Как пользуется Garbage Collector’ом рядовой «пользователь» Visual Studio? Да ни как. Он полагается на настройки по умолчанию для Garbage Collector’а. Настройки по умолчанию рассчитаны на так называемые бизнес приложения, для динамичной работы с DirectX нужно доработать.
По умолчанию Garbage Collector выполняет освобождение памяти в любом случае не синхронно с работой Update. Мертвый груз копится и освобождается в непредсказуемый, для логики вашего приложения, момент. Самый простой выход – это делать в начале очередного Update:
System.GC.Collect(1);
Где 1 это номер поколения, значение подобрано экспериментально.
С другой стороны может быть не целесообразно перегибать палку и выполнять сборку мусора 60 раз в секунду при включенной синхронизации (если у монитора такая рабочая частота обновления экрана) или более 60 раз при выключенной синхронизации.
По этому можно сделать так:
using System; using System.ComponentModel; using Microsoft.Xna.Framework; namespace GeneralPresentationFoundation.gSystem.gGarbageCollector { public class GarbageCollector { private BackgroundWorker bw = new BackgroundWorker(); private int stepNumber = 0; private int sleepStep = 1; public int SleepStep { get { return sleepStep; } set { sleepStep = value; } } public GarbageCollector() { Init(); } public GarbageCollector(int sleepStep) { this.sleepStep = sleepStep; Init(); } private void Init() { bw.DoWork += new DoWorkEventHandler(bw_DoWork); } public void Update() { if(!bw.IsBusy) { stepNumber++; if(stepNumber == sleepStep) { stepNumber = 0; bw.RunWorkerAsync(); } } } private void bw_DoWork(Object sender, EventArgs e) { GC.Collect(1); } } }
Возможно не везде будет полезным применение потока, это просто мой случай.
GarbageCollector gc = new GarbageCollector(20);
т.е. при частоте монитора 60 Гц - 3 раза в секунду.
среда, 1 декабря 2010 г.
RSDN совместно с MSDN сообщают о новом конкурсе статей по технологиям Microsoft
RSDN совместно с MSDN сообщают о новом конкурсе статей по технологиям Microsoft, посвященных одной из двух тем:
- Возможности операционной системы Windows 7
- .NET
На конкурс принимаются русскоязычные технические статьи, присланные на адрес submit@rsdn.ru в период с 12 октября по 31 января 2011 года.
Первые три места получают:
1 Notebok Acer "Aspire 3820TG-5464G50iks"
2 Коммуникатор HTC "HD2 T8585"
3 XBox 360
Участники, написавшие интересные статьи, но не попавшие в первую тройку, получат специальные призы от жюри:
4 Microsoft "Wireless Laser Desktop 7000"
5 Microsoft "Natural Ergonomic Keyboard 4000"
6 Microsoft "Wireless Arc Mouse" ZJA-00010
Подробности тут
- Возможности операционной системы Windows 7
- .NET
На конкурс принимаются русскоязычные технические статьи, присланные на адрес submit@rsdn.ru в период с 12 октября по 31 января 2011 года.
Первые три места получают:
1 Notebok Acer "Aspire 3820TG-5464G50iks"
2 Коммуникатор HTC "HD2 T8585"
3 XBox 360
Участники, написавшие интересные статьи, но не попавшие в первую тройку, получат специальные призы от жюри:
4 Microsoft "Wireless Laser Desktop 7000"
5 Microsoft "Natural Ergonomic Keyboard 4000"
6 Microsoft "Wireless Arc Mouse" ZJA-00010
Подробности тут
четверг, 14 октября 2010 г.
GPF - "WPF" for XNA
GPF - на таком рабочем названии библиотеки я остановился.
Сегодня закончил модуль 3d форм - это такой штука, обеспечивающая
функционал добавления в сцену объектов на плоские грани которых можно проецировать формы и оперировать ими указателем мыши.
Пока не стал возиться с наложением форм на не плоские поверхности по
причине того, что это нарушит совместимость с Windows Phone 7 экземпляром библиотеки.
Вот такое видео:
Показал Expander, DataGrid, Table.
Со стилями элементов опять не поиграл. Оставил на потом)
Сегодня закончил модуль 3d форм - это такой штука, обеспечивающая
функционал добавления в сцену объектов на плоские грани которых можно проецировать формы и оперировать ими указателем мыши.
Пока не стал возиться с наложением форм на не плоские поверхности по
причине того, что это нарушит совместимость с Windows Phone 7 экземпляром библиотеки.
Вот такое видео:
Показал Expander, DataGrid, Table.
Со стилями элементов опять не поиграл. Оставил на потом)
суббота, 9 октября 2010 г.
XNA. gEngine. Forms (GUI)
Вот и созрел я до первого показа своего интерфейса для приложений реализованных на базе XNA. Как говорится лучше один раз увидеть …, так не буду Вас задерживать:
Рекомендую смотреть в HD режиме.
Данное видео не показывает всех элементов и возможностей. Опубликовал по многочисленным заявкам. За продолжением следите в следующих сериях.
Идея архитектуры, данного интерфейса, базируется на архитектуре предложенной в WPF. Но ядро и элементы написаны с нуля и оптимизированы под 3d. Так же данная библиотека работает и на Windows Phone 7.
Список уже реализованных элементов выглядит следующим образом:
- Button
- Canvas
- CheckBox
- CheckElement
- ConsoleOutput
- DataGrid
- Expander
- Image
- ListSelector
- Menu
- ProgressBar
- ScrollBar
- ScrollDiagram2d
- ScrollView
- Slider
- StackPanel
- Switch
- TabControl
- Table
- TextBlock
- TextBox
В этот список попали не характерные для WPF элементы, что было продиктовано первоочередной необходимостью реализации отображения функционала 3d движка.
В представленном видео все элементы и формы выводятся с простым базовым стилем. Под базовым стилем подразумевается (если есть) прямоугольная рамка и (если есть) прямоугольник фона. Стиль любого элемента достаточно просто меняется наследованием от него нового нового класса. Я пока не стал перегружать рабочую версию интерфейса надуманным стилем и растровой графикой, бесполезная трата времени на то что в последствии не пригодится.
Рекомендую смотреть в HD режиме.
Данное видео не показывает всех элементов и возможностей. Опубликовал по многочисленным заявкам. За продолжением следите в следующих сериях.
Идея архитектуры, данного интерфейса, базируется на архитектуре предложенной в WPF. Но ядро и элементы написаны с нуля и оптимизированы под 3d. Так же данная библиотека работает и на Windows Phone 7.
Список уже реализованных элементов выглядит следующим образом:
- Button
- Canvas
- CheckBox
- CheckElement
- ConsoleOutput
- DataGrid
- Expander
- Image
- ListSelector
- Menu
- ProgressBar
- ScrollBar
- ScrollDiagram2d
- ScrollView
- Slider
- StackPanel
- Switch
- TabControl
- Table
- TextBlock
- TextBox
В этот список попали не характерные для WPF элементы, что было продиктовано первоочередной необходимостью реализации отображения функционала 3d движка.
В представленном видео все элементы и формы выводятся с простым базовым стилем. Под базовым стилем подразумевается (если есть) прямоугольная рамка и (если есть) прямоугольник фона. Стиль любого элемента достаточно просто меняется наследованием от него нового нового класса. Я пока не стал перегружать рабочую версию интерфейса надуманным стилем и растровой графикой, бесполезная трата времени на то что в последствии не пригодится.
четверг, 7 октября 2010 г.
Фрагмент истории xnadev.ru
Своим рассказом хочу развеять некоторые предрассудки, заблуждения и прояснить ситуацию.
Как то зашел разговор о том, что с различных ресурсов, пользователей задающих вопросы по XNA, перенаправляют на наш сайт xnadev.ru. Пользователи приходят не (!) регистрируясь осматриваются, чаще всего делаю вывод о том что форум мертв и уходят. Т.е. не задерживаются.
На самом же деле форум не мертв. Собралась достаточно дружная компания, костяк из админов, MVP, активных грамотных пользователей, плюс немного интересных и эксцентричных персонажей, добавляющих в наше общение позитив, и прочие читатели. Каждый занимается своим делом, временами рассказываем, показываем наработки. Ежедневно отвечаем на вопросы (я это делаю по вечерам). Общаемся в меру свободного времени и настроения.
Но до недавнего времени доступ к самым активным веткам форума был закрыт (!) для не зарегистрированных пользователей. Без злого умысла, данное обстоятельство было продиктовано техническими ограничениями тарифа хостинга сайта (нагрузки, трафик и т.д.), а так как админы платили кровные из своего кармана, то пояса пришлось затянуть по туже. Сейчас мы сменили хостинг, переехали на 1gb.ru. Еще раз спасибо за содействие Евгению Марченкову (Microsoft). Возможности расширились и мы изменили права доступа для всех пользователей (и соответственно поисковых систем). Вот такая вот наша сказка).
Милости просим.
Подписаться на:
Сообщения (Atom)