Perfect Particle 2

[SaiLight]

И, подведя итог моих сегодняшних новостей, хотелось бы рассказать о новом способе вывода графики, который будет использован в Perfect Particle 2. Если в первой версии программы эффекты рисовались при помощи 'GL_QUADS' (каждая частица в отдельности), то теперь я хотел бы использовать для этого метод под названием 'буферные объекты' (VBO), знаний о котором, впрочем, на данный момент еще недостаточно. Оттого, я не буду описывать здесь данную технологию и все ее преимущества. Надеюсь лишь, что смотрю в правильном направлении, и это именно то, что мне нужно.

Напоследок, задаю планку для последующих тестов Perfect Particle 2 эффектом, созданном вчера в первой версии программы. Насколько удастся его превзойти - увидим лишь после выпуска первой рабочей версии нового редактора.

http://vimeo.com/72736404

P.S. Информацию о процессе разработки, по каким-то причинам не вошедшую в данную тему (если таковая найдется) можно посмотреть в группе, посвященной Perfect Particle 2 в Контакте, которая, также, в скором времени будет обновляться.

[SaiLight]

И вновь я поприветствую всех, читающих данную тему и следящих за ее обновлениями, не извиняясь за их долгое отсутствие, что было обговорено еще в самом первом сообщении темы. Но сегодня я пришел с хорошими новостями, подтверждающими, что данная тема не заброшена, и мое долгое отсутствие в ней было вызвано не ленью или забывчивостью, но лишь чрезвычайной загруженностью этим и другими проектами.

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

И вот прошло пять месяцев, я сижу здесь и пишу это сообщение, вспоминая тот день, чтобы знать, что время не было потрачено зря. Время, отведенное на ответвление от основной темы моей работы, на получение огромного количества дополнительного опыта, на такой же огромный риск и опасность 'не успеть', взявшись за то, чего ранее никогда не делал. Но теперь, после пяти месяцев сомнений и неудач, верю, что риск был оправдан.

Что же было сделано? Для одного - простая работа на пару месяцев, для меня же - огромное количество опыта, новых знаний и столько же положительных эмоций, полученных от самого творческого процесса. Итак, все это время я занимался разработкой графических компонентов для своей системы. Дело в том, что мне не хотелось, чтобы внешний вид программы зависел от оформления, установленного на конкретном компьютере, поэтому я уже давно приглядывался к компонентам, реализующим в Delphi возможность подключения к проекту собственных тем оформления. Но, по множеству разных причин, все они вызвали у меня разочарование, что и послужило поводом для создания собственных компонентов.

Сама по себе эта идея, конечно, казалась выигрышной, хотя бы в плане опыта, - до этого я ни разу не создавал собственных компонентов для Delphi, но со временем стал все острее ощущать необходимость в этом. Другой вопрос, вставший тогда передо мной - успею ли я справиться со своей основной задачей к моменту сдачи дипломной работы?

Итак, всего в процессе работы было написано 12 графических компонентов и 2 дополнительных, вспомогательных класса, на одном из которых и были основаны все вышеупомянутые компоненты - TGradientBitmap. Я использовал знания, полученные мною в прошлом году при расчете градиентов, создав с их помощью данный класс, имеющий возможность рисовать на себе градиент по неограниченному количеству опорных точек, передаваемых в него в виде строки. В дополнение к этому, градиент может быть - как вертикальным, так и горизонтальным.

Сегодня я поделюсь в этой теме показательной программой, демонстрирующей некоторые (основные) из подготовленных мною компонентов, а также новый стиль оформления и логотип Perfect Particle 2.

InterfaceTest.rar

[phomm]

Разделяю Вашу эмоциональность, сам безмерно радуюсь реализации своих проектов, когда они живут и красиво работают.
В проекте всё понравилось по дизайну, кроме чекбокса, невыразительно когда он отмечен и даже непонятно, отмечен ли вообще.
По работе:
Немного непонятно, скролбар только вертикальный ? было бы неплохо если одни компоненты влияли на другие, например, чтобы при отметке чекбокса скролбар менял ориентацию. Ещё у скролбара нет стандартной функциональности клика в пустое место полоски, при котором он производит "прыжок" ползунка.
Хотелось бы ещё видеть состояния not enabled для контролов, и предусматривались ли они вообще, плюс какие работы с фокусом и кнопками клавиатуры были ? Листбокс и скролбар по идее должны переключаться стрелками при наличии фокуса ввода. Каковы возможности настройки внешнего вида контролов ? Предусматривается ли Стайл-провайдер компонент, хранящий единые настройки, как бы скин ?
Ну и вложение контролов - можно ли на панель ставить контролы и другие панели с контролами, вплоть до рекурсии

Плюс один из моих давних извечных вопросов к любым гуи-системам - как реализован хиттест ? По попаданию мышки в прямоугольник контрола ?

Я сам писал гуи-движок, но не на компонентах, а просто графическими элементами, с нуля, кнопки, надписи, списки, диалоги, был ещё один проект вне первого, там реализовывал эдиты и специфичные вещи, возможно когда-то сяду доводить до ума, там всё на GDI + Graphics сделано по сути. Да и сейчас в третьем проекте создаю контролы по необходимости, но там совсем другая история - 3д-спрайты.

[SaiLight]

phomm, спасибо за оценку и полезную критику, для меня это очень важно. Насчет дизайна CheckBox'а - это в любой момент можно изменить, главное, что теперь я об этом знаю.

Вообще, компоненты создавались по принципу 'необходимого минимума', но чтобы реализован этот минимум был максимально качественно. Оттого, например, ScrollBox пока может быть только вертикальным - мне в Perfect Particle 2 пока нужен только такой, и от катастрофической нехватки времени я пока не реализовывал его поворот. Также, насчет функциональности, хочу отметить, что некоторые моменты были упущены мною, а некоторые, наоборот, детально проработаны. Возможно, сам я никогда не пользовался клавиатурой для прокрутки ScrollBar'а, потому и не знал, что это вообще должно быть предусмотрено (виноват, исправлюсь). Но, что касается SpinEdit'а, например, его функциональность, в сравнении со стандартным, была довольно сильно расширена. Тут и прокрутка значений при помощи мышки, и быстрая прокрутка при нажатой клавише CTRL, и единое событие 'onDoAction', возникающее не при вводе каждого нового символа, а при подтверджении своего ввода нажатием на Enter, при потере фокуса или при вставке значения...

Следует отметить, что данные компоненты пока написаны лишь 'для себя' - и для узкого круга людей, знающих об их недостатках и умеющих мирить с ними свою программу. И, все же, с основными недостатками, затрудняющими работу с компонентами, я стараюсь бороться, что, впрочем, пока не делает данные компоненты идеальными и не дает им право выходить в свет для борьбы с такими системами как Skin Engine или Theme Engine. Просто для конкретных моих задач они сейчас удобнее и красивее, а когда потребуется что-то большее, я добавлю и это.

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

Насчет возможностей настройки внешнего вида:

• Поддерживается линейный градиент, построенный по 'неограниченному' количеству опорных точек, находящихся на любом желаемом расстоянии друг от друга. Просто указывается позиция точки и ее цвет. Используя уже одну эту (основную) возможность, можно создавать как обычные градиентные кнопки, так и модные сегодня 'стеклянные' - на что хватит воображения.
• Для кнопок и панелей можно устанавливать градиенты, относящиеся к разным состояниям, таким как 'Обычное', 'Наведение', 'Нажатие' и 'Неактивное'. Для поля ввода Edit присутствует отдельный градиент для компонента под фокусом.
• Есть возможность менять стиль градиента - 'Вертикальный' или 'Горизонтальный'.
• Поддерживается рамка вокруг компонента с настраиваемыми толщиной и цветом. Также, рамка при получении компонентом фокуса может принимать другой цвет.
• Существует возможность детальной настройки и всех вложенных компонентов. К примеру, есть возможность задания текста на кнопках ScrollBar'а или цвета Scroller'а (кнопки прокрутки), что дает много дополнительных возможностей при создании собственного дизайна.

Вообще, используя данные возможности с умом, можно создавать необычные и довольно красивые интерфейсы для своих программ. Важно воображение, а не количество возможностей.

Все компоненты были созданы на основе класса 'TCustomControl', действия при нажатии на них мышкой или при использовании клавиатуры производятся посредством перехвата сообщений, посылаемых операционной системой.

Неактивное состояние для компонентов предусмотрено было, но в показательную программу я его отображение вносить уже не будут, так же, как не внес и остальные компоненты - все это можно будет увидеть в дальнейшем при выкладывании скриншотов и демо-версий Perfect Particle 2. Для списка такое состояние пока не было реализовано - все потому, что он создавался мною намного раньше, еще в прошлом году, не как компонент, а как отдельный класс, и теперь, с несерьезными изменениями, был внесен в список графических компонентов, а вот неактивное состояние добавлено пока не было. Прикрепляю к этому сообщению скриншот показательной программы с отключенными компонентами.

[RegedroN]

Хренасе проект!) Серьезная программа)

[SaiLight]

RegedroN, спасибо за оценку проекта, это очень важно для меня.

Недавно была завершена работа над интерфейсом программы. Она была завершена еще неделю назад, но из-за большой загруженности другими проектами я все никак не мог обновить данную тему. На самом деле, разработка интерфейса в моем понимании не ограничивается созданием форм и размещением на них компонентов. Это, прежде всего, и создание связей между компонентами, обеспечивающих взаимодействие компонентов друг с другом. Во избежание последующих трудностей и путаницы, связанной с обработкой вполне обычных событий, таких, как, например, onClick кнопки или onChange списка, я разделил общую задачу на несколько подзадач, обозначив некоторые этапы в своей дальнейшей работе над программой.

Данный подход применялся мною и в работе над прошлой версией Perfect Particle - пользуясь своим полным осознанием задачи, каждой ее детали, я имею возможность разделить общую задачу на подзадачи: сначала отдельно разрабатывать интерфейс, писать код, связанный с ним, и лишь потом переходить к работе над самой системой частиц. Думаю, этот подход имеет право на жизнь.

Скриншоты получившегося интерфейса представлены ниже. Программу пока выкладывать смысла не вижу.

Для меня был удивителен тот факт, что не всякий, даже программист, увидевший скриншоты моей программы, может правильно их оценить и сделать соответствующие выводы. Поэтому, считаю нужным разъяснить здесь некоторые моменты, во избежание всякого рода непониманий. Думаю, стоит сделать небольшую заметку о роде моей деятельности - я занимаюсь не только программированием, но и уже довольно долгое время воспитываю в себе некоторые навыки в сфере работы с компьютерной графикой, а именно, рисование, работа в Photoshop и 3D-моделирование. Но так как я вынужден развиваться в нескольких направлениях, а времени мне отпущено не больше, чем остальным, многое сделать я просто не успеваю, хотя и понимаю необходимость в этом. Оттого, размышляя над данной проблемой, я пришел к выводу о необходимости комбинирования нескольких действий в одном - и одно действие приносило бы пользу в решении сразу нескольких задач.

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

[SaiLight]

И вот я снова пишу в этой теме, подводя итог очередному этапу своей работы над системой частиц Perfect Particle 2. Работа сложна не только своей масштабностью, но и категорическим отсутствием необходимого для ее выполнения времени и столь же необходимых сил. Впрочем, несмотря на это, могу похвастаться точностью исполнения плана, продуманного еще перед началом всех работ и, хотя периодически я сталкиваюсь с довольно сложными проблемами, предсказать которые по каким-то причинам не сумел, думаю, завершить работу я, все же, успею. В любом случае, начался последний месяц перед отчетом, а если он, все же, окажется предпоследним, то к моменту его завершения у меня в руках окажется готовая работа и немного свободного времени.

Сегодня мне хотелось бы поговорить о том, чего я сумел достичь и к чему планирую устремиться за оставшийся месяц своей работы.

Прежде всего, необходимо отметить некоторые отличия новой системы от старой и коснуться в этом вопросе, я бы хотел структуры классов, так именно их разработкой я и занимался все последнее время. И первое, что хотелось бы отметить в структуре, - это введение понятия 'Событие', отвечающего за осуществление правильного взаимодействия между объектами классов. Теперь частица взаимодействует с эмиттером, создавшим ее посредством событий 'onBirth' и 'onDeath' (рождение и смерть), и если ранее в подсчете количества живых частиц могли возникнуть некоторые проблемы, связанные с утечкой некоторых частиц из поля зрения эмиттера после их смерти, то теперь, благодаря вышеназванным событиям, этого легко удалось избежать. До тех пор, пока... Впрочем, об этом чуть позже.

Я размышлял о непрестанном копировании одних и тех же данных при создании всякой частицы. Когда в Perfect Particle создается частица, она заносится в массив, после чего каждому из ее полей присваиваются определенные значения. И если в первой части программы это еще было приемлемо, то сегодня дело обстоит совершенно по-иному. В Perfect Particle 2 мы видим намного более обширный список параметров, - судя не столько по их количеству, сколько по месту, занимаемому ими в памяти. И правда, с переводом системы на графики у нас появилась необходимость хранить их настройки в строках, где, разделенные пробелами, записывались по порядку все точки, установленные пользователем на очередной график. И вот проблемы многократного копирования одних и тех же строк мне хотелось бы избежать.

Для этого я создал некую структуру, содержащую в себе информацию об очередном графике:

TPropertiesBlock = Record
  Curve: Array of TRPoint;//Массив с точками графика
  Value: Integer;//Значение (если задаем фиксированное значение)
  Deviation: Integer;//Отклонение
end;

И две специальных функции: одну - для перевода строки в массив точек и другую - для обратного перевода. Таким образом, мне удалось 'упаковать' огромное количество однотипных данных в эту запись, сделав, тем самым, структуру своего кода более понятной. И когда передо мной встал вопрос об избежании копирования этой структуры (и иных настроек) в каждую новую частицу системы, я сказал: 'Использую шаблон', и в моей программе появился шаблон.

Вообще, шаблон, - простая структура, запись, хранящая в себе набор параметров, необходимых частице для обработки своих свойств. Таким образом, с момента введения понятия 'Шаблон', я получил возможность избежать лишних временных затрат на создание каждой частицы (ведь многократное копирование длинных строк занимает довольно много времени), а также, ограничил передаваемые в новую частицу данные одним лишь указателем на созданный внутри эмиттера шаблон. Отныне каждая частица хранит в себе лишь необходимые (в основном, для рисования) данные и кучу временных параметров - локальных переменных в функции обновления. Так частица стала легче.

И, окрыленный подобным успехом, я тут же поспешил создать шаблон для эмиттера. Параметров в нем меньше, но идея та же - возможность обращаться по ссылке к глобальным свойствам системы, ничего не зная о существовании самой системы.

[SaiLight]

Вообще, мне очень хотелось бы поблагодарить своего друга (SpectreZ) за неоценимую помощь, оказанную мне в процессе работы. Сам он трудится параллельно со мной над другой темой - 'Организация пользовательского интерфейса в программах, использующих OpenGL'. И, поскольку обе наших работы объединяет наличие 'OpenGL' в названии, некоторые технологии, используемые им в своей работе, пригодились и мне, и были незамедлительно мне предоставлены. В частности, - модуль для загрузки изображений в память с возможностью загрузки png-изображений, модуль для загрузки шрифтов и их вывода (использующий метод загрузки, созданный им же) и замечательный модуль для работы с RTTI в своем классе. Собственно говоря, само понятие RTTI я узнал именно от него.

Итак, подведя итог всего сказанного в предыдущем абзаце, могу выделить несколько полезных улучшений, введенных в Perfect Particle 2 благодаря наличию модуля для работы с RTTI. Так как отныне я мог обращаться ко всем необходимым мне свойствам класса как к массиву, сам процесс сохранения и загрузки настроек эмиттера теперь сводился к простому перебору заранее заданного набора свойств циклом. Подобным же образом удалось организовать и функцию копирования значений между эмиттерами, также, необходимую мне в дальнейшем. Единственное, что пришлось сделать для этого, - создать пару дополнительных классов. Дело в том, что RTTI не дает возможности работать со свойствами-записями, а именно записями и являлись 90% моих свойств (TPropertiesBlock). Поразмыслив над этим, я решил не лениться и переписать эту структуру в класс, что, разумеется, оказалось правильным шагом, ведь это, ко всему прочему, давало и дополнительные удобства, делая структуру программы более читаемой.

К примеру, мне больше не нужны были отдельные функции для перевода строки в массив точек и обратно - вместо этого я создал в своем новом классе свойство 'Curve: String', для чтения и записи которого назначил соответствующие функции. Помимо прочего набора удобств, класс TPropertiesBlock обладал возможностью сохранения своих немногочисленных данных в файл, загрузки их из файла и копирования данных из другого класса. Подобными же функциями обладал и TImagesList - второй дополнительный класс, работающий со списком изображений эмиттера.

[SaiLight]

Возможно, впервые за эти годы я серьезно задумался об оптимизации. Моя цель - не просто написать хорошую систему частиц и сделать для нее редактор, - кроме того, необходимо еще, чтобы система работала быстро и могла в реальном времени выводить на экран довольно красивые эффекты. Я стал искать слабые места в своем коде - где я мог бы подправить его, чтобы облегчить и без того непростую жизнь своего компьютера. И первой проблемой, бросившейся мне в глаза, была проблема несоответствия типов. В самом деле, когда разговор заходит о таком огромном количестве свойств и о необходимости взаимодействия этих свойств друг с другом, мы время от времени неизбежно сталкиваемся с необходимостью конвертировать значения одних свойств в типы, пригодные для записи в другие. Наиболее частой проблемой было несоответствие 'Integer - Real', ведь, в разных местах программы было удобнее использовать тот или иной тип, но в местах их пересечения приходилось приводить значения к общему типу.

Примером тому может служить свойство TColor (оно же Integer) при вычислении градиента частицы. Так как сам градиент по своей структуре очень похож на график, я объединил его с графиками и стал работать с ним при помощи класса TPropertiesBlock, о котором уже писал чуть выше. Но результат, возвращаемый функцией этого класса, отвечающей за подсчет значения свойства в соответствии со временем жизни объекта (по графику) имел тип Real, и после его получения мне приходилось вызывать функцию 'Round' для округления и записи его в TColor. И таких мест было довольно много. Одним из наиболее страшных в моих глазах было частое округление нецелочисленных значений, и я, где только мог, старался этого избегать, борясь чуть ли не за каждую строку.

Но, как выяснилось позже, это не было основной проблемой, подлежащей решению и оптимизации. И в своих поисках той самой, единственной, я продвинулся еще на шаг вперед, а именно, к использованию класса TList. Дело в том, что способ организации хранения частиц в моей программе шел еще с самой первой ее версии (кажется, написанной года два назад) - частицы просто хранились в динамическом массиве. Каждый раз при добавлении новых частиц мы пробегали по всему массиву (в том же цикле, что и обновление частиц) и искали те из них, что были помечены как мертвые. Ведь мертвые объекты не удалялись, они лишь помечались значением False соответствующего свойства и оставались лежать в массиве до своего чудесного воскрешения. И я искал такие частицы и, находя, воскрешал их. Если же на текущем кадре был пройден весь массив, а необходимого количества созданных частиц за этот шаг мы еще не достигли, в массив добавлялись новые элементы, и он, соответственно, рос.

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

Здесь я решил использовать TList - новый для меня класс. Я не поленился переписать огромное количество кода для того, чтобы перевести массив частиц на TList и не пожалел. Несмотря на то, что теперь каждая мертвая частица удалялась из памяти, а каждая новая, соответственно, в ней создавалась, мне удалось значительно повысить скорость работы программы, а также, существенно снизить ее размер в оперативной памяти. Подозреваю, что первое вытекало из второго, ведь, теперь размер массива был равен количеству живых частиц в системе, а значит, лишних шагов в цикле мне делать не приходилось. В любом случае, программа стала работать немного быстрее, и я был рад этому.

[SaiLight]

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

И в этот раз я отказался от класса 'Частица'. Я вновь перевел всю структуру на динамический массив, но организовал работу с ним совершенно по-новому. Прежде всего, из-за отказа от класса 'Частица', в моей программе появилась соответствующая запись (Record) 'Частица', со всеми ее свойствами, а функции создания и обновления были перенесены непосредственно в класс 'Эмиттер'. Теперь массив, хоть и являлся, по-прежнему, динамическим, не нуждался в неудобствах, связанных с вызовами конструктора и деструктора для каждой частицы, и я мог в любой момент добавлять и удалять любое необходимое количество его элементов. К примеру, для добавления нескольких частиц в конец массива, я добавлял их, сразу все, одной командой 'SetLength', и лишь потом вызывал соответствующую функцию 'CreateParticle'. Также, размер массива постоянно фиксировался, и ненужная его часть, при необходимости обрезалась на каждом кадре. От шаблона, также, из-за ненадобности, пришлось отказаться, ведь теперь частицы хранились непосредственно в эмиттере, который уж точно имел доступ ко всем своим свойствам.

Сам по себе подобный переход не сильно разгрузил систему, но в сумме с еще несколькими усовершенствованиями, позволил значительно снизить нагрузку на процессор.

Итак, после всех этих усовершенствований, я вижу лишь одну проблему, на решение которой у меня пока не было достаточно свободного времени, но она гнетет меня, и я знаю, что настанет время, когда я возьмусь за ее решение. Проблема эта связана с выводом графики при помощи OpenGL'овских функций 'glBegin/glEnd'. Причем, она настолько тормозит систему при выводе, что если 6000 частиц грузят процессор на 35-45%, то при отключении функции рисования нагрузка снижается до 6-11%. В любом случае, в скором времени данная проблема подлежит разрешению.