Как написать программу в codeblocks

CodeBlocks — среда программирования на языке C/C++

Code::Blocks — это бесплатная кроссплатформенная среда разработки на языке C/C++. На данный момент это лучшая бесплатная среда разработки на языке Си.

Code::Blocks разрабатывается для Windows, Linux и Mac OS X.

В среде Windows скачать эту среду удобнее всего в составе сборки Си-экспресс, в которой уже есть все необходимые библиотеки для начала работы. Сборка не требует установки и работает по принципу: «Распаковал и работай».

Поддерживаемые компиляторы

Code::Blocks поддерживает следующие компиляторы:

GNU GCC (incl. G77) (Linux)
MinGW GCC (incl. G77) (Win32)
MSP430 GCC (Win32)
TriCore and PowerPC GCC (Win32, Linux)
Apple GCC (Xcode) (Mac OS X)
Microsoft Visual C++ Toolkit 2003 (Win32)
Microsoft Visual C++ 2005 (Win32)
Borland’s C++ Compiler 5.5 (Win32)
DigitalMars C/C++ (Win32)
OpenWatcom (Win32)
Intel C++ compiler (Win32)
Small Device C Compiler (SDCC)
Digital Mars D
GDC D Compiler
LLVM D Compiler

Готовые шаблоны

CodeBlocks имеет готовые шаблоны проектов, которые позволяют быстро создать минимальное приложение.

Редактор кода

Редактор кода обладает всеми возможностями для комфортной работы программиста:

Выделение синтаксиса (можно настроить под себя)
Интерфейс с вкладками
Автозавершение кода
Браузер классов
Умный отступ
Обмен одним кликом между файлами .h и .c / .cpp
Пользовательские сочетания клавиш
Внешние настраиваемые «Инструменты»
Управление списком дел с разными пользователями

Количество настроек редактора просто огромно:

Кроме общих настроек также настраивается:

Сворачивание кода
Поля и курсор
Подсветка синтаксиса (отдельно по типам файлов)
Код по умолчанию для создаваемых файлов (можно вставить автоподпись)
Сокращения (при вводе сокращения оно автоматически разворачивается в код)
Форматирование кода
Способ сохранения и возврата к строчкам кода
Автодополнение кода
Настройка статистики кода
Генерация документирования кода
и многое другое

Плагины

Возможности редактора могут быть расширены с помощью плагинов. Например:

HEX-редактор
Диаграммы Насси Шнейдермана
Экспорт исходного кода в другие форматы
Макросы нажатия клавиш
Горячие клавиши для меню
Инкрементный поиск
Переменные среды
и многие другие

Отладчик

В качестве отладчика по умолчанию CodeBlocks использует GDB — самый популярный отладчик для языка Си, который был разработан еще Ричардом Столменом.

Отладчик позволяет установить точки останова и затем пошагово выполнять код с одновременным мониторингом переменных и массивов. Также вы можете отслеживать стеки вызываемых функций.

Итоги

Количество возможностей и настроек среды CodeBlocks позволяют превратить эту среду в отличный инструмент Си-программиста.

Источник статьи: http://progtips.ru/instrumenty-programmista/codeblocks.html

Разработка простой игры в Code::blocks с использованием Direct3D 9

Введение

Итак, в свободное от работы время решил я изучить популярный графический API. Прочитав несколько книг и разобрав кучу примеров и туториалов (в том числе из DirectX SDK), я осознал, что настал тот самый момент, когда стоит попробовать свои силы самостоятельно. Основная проблема была в том, что большинство существующих примеров просто демонстрируют ту или иную возможность API и реализованы процедурно чуть ли не в одном cpp-файле, да еще и с использованием обертки DXUT, и не дают представления о том, какую структуру должно иметь конечное приложение, какие классы нужно спроектировать и как это все должно друг с другом взаимодействовать, чтобы все было красиво, читабельно и эффективно работало. Данный недостаток касается и книг по Direct3D: например, для многих новичков не является очевидным тот факт, что состояния рендера (render states) не всегда нужно обновлять при отрисовке каждого кадра, а также, что большинство тяжеловесных операций (типа заполнения вершинного буфера) следует выполнить всего один раз при инициализации приложения (либо при загрузке игрового уровня).

Первым делом мне необходимо было определиться с самой идеей игры. На ум сразу пришла старая игра из 1992 года под MS-DOS, которая, я думаю, многим знакома. Это логическая игра Lines компании Gamos.

Что ж, вызов принят. Вот что мы имеем:

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

Теперь посмотрим с точки зрения приложения Direct3D:

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

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

Начало разработки

До сих пор я не упоминал, какие инструменты использовались. Во-первых, необходим DirectX software development kit (SDK), всегда доступный для свободного скачивания на сайте Microsoft: DirectX SDK. Если вы собираетесь использовать версию Direct3D 9, как я, то после установки необходимо через главное меню открыть DirectX Control Panel и на вкладке Direct3D 9 выбрать, какая версия библиотек будет использоваться при сборке — retail либо debug (это влияет на то, будет ли Direct3D сообщать отладчику о результатах своей деятельности):

Почему Direct3D 9-й версии? Потому что это последняя версия, где все еще есть fixed function pipeline, то есть фиксированный графический конвейер, включающий в себя, например, функции расчета освещения, обработки вершин, смешивания и так далее. Начиная с 10-й версии, разработчикам предлагается самостоятельно реализовывать эти функции в шейдерах, что является неоспоримым преимуществом, но, на мой взгляд, сложновато для восприятия при первых опытах с Direct3D.

Почему Code::blocks? Наверное, глупо было использовать кросс-платформенную IDE для разработки приложения, использующего некросс-платформенный API. Просто Code::blocks занимает в несколько раз меньше места, чем Visual Studio, что оказалось очень актуальным для моего дачного ПК.

Старт разработки с Direct3D оказался очень прост. В Code::blocks я создал пустой проект (empty project), затем в build options нужно было сделать две вещи:

1) На вкладке search directories и подвкладке compiler добавить путь к директории include DirectX SDK — например, так:

После этого в исходном коде приложения нужно будет включить заголовочные файлы Direct3D:

Структура приложения

Здесь я допустил первую ошибку: начал размышлять над тем, какой шаблон проектирования выбрать. Пришел к выводу, что лучше всего подходит MVC (model-view-controller): моделью будет класс игры (game), включающий всю логику — вычисление путей перемещения, появление шаров, разбор взрывных комбинаций; представлением будет класс движка (engine), отвечающий за отрисовку и взаимодействие с Direct3D; контроллером будет собственно обертка (app) — сюда входит цикл обработки сообщений, обработка пользовательского ввода, а также, что самое главное, менеджер состояний и обеспечение взаимодействия объектов game и engine. Вроде бы все просто, и можно начинать писать заголовочные файлы, но не тут-то было! На этом этапе оказалось очень сложно сориентироваться и понять, какие методы должны быть у этих классов. Понятно, что сказалось полное отсутствие опыта, и я решил прибегнуть к совету одной из книг: «Не пытайтесь с самого начала написать идеальный код, пусть он будет неоптимальным и сумбурным. Понимание приходит со временем, и рефакторингом можно заняться потом.» В итоге после нескольких итераций рефакторинга уже работающего макета определение трех основных классов приняло вид:

Класс TGame имеет всего 3 метода, которые может инициировать сам пользователь — New (новая игра), Select (выбор шара) и TryMove (попытка переместить шар). Остальные вспомогательные и вызываются контроллером в особых случаях. Например, DetonateTest (тест на взрывные комбинации) вызывается после появления новых шаров или после попытки перемещения. GetNewBallList, GetLastMovePath, GetDetonateList вызываются, соответственно, после появления шаров, после перемещения и после взрыва, с одной целью: получить список конкретных шаров и передать его на обработку объекту engine, чтобы он что-то нарисовал. На логике работы TGame не хочется подробно останавливаться, поскольку есть исходники с комментариями. Скажу только, что определение пути перемещения шара реализовано с помощью алгоритма Дейкстры по неориентированному графу с равными весами всех ребер.

Рассмотрим подробнее классы движка и контроллера.

TEngine

В классе определены поля для хранения handle окна и его прямоугольника. Они используются в методе OnResize, который контроллер вызывает при изменении размеров окна, для расчета новой матрицы проекции.
В поле CameraPos хранятся координаты наблюдателя в мировом пространстве. Вектор направления взгляда хранить не нужно, поскольку по моей задумке камера всегда направлена в начало координат, которое, кстати, совпадает с центром платформы.
Также имеются указатели на интерфейсы Direct3D: LPDIRECT3D9, который нужен только для создания устройства; LPDIRECT3DDEVICE9 — собственно, само устройство Direct3D, основной интерфейс, с которым приходится работать; LPD3DXFONT и LPDIRECT3DTEXTURE9 для работы с текстом и текстурой.
Поле currentTime используется для хранения текущего времени в миллисекундах и необходимо для отрисовки плавной анимации. Дело в том, что отрисовка каждого кадра занимает разное количество миллисекунд, поэтому приходится каждый раз замерять эти миллисекунды и использовать в качестве параметра при интерполировании анимации. Такой способ известен под названием синхронизация временем и используется повсеместно в современных графических приложениях.
Указатели на объекты класса TGeometry (cellGeometry и ballGeometry) хранят геометрию одной ячейки и одного шара. Сам по себе объект TGeometry, как понятно из названия, предназначен для работы с геометрией и содержит вершинные и индексные буферы, а также описание материала (D3DMATERIAL9). При отрисовке мы можем изменять мировую матрицу и вызывать метод Render объекта TGeometry, что приведет к отрисовке нескольких ячеек или шаров.
TParticleSystem — это класс системы частиц, имеющий методы для инициализации множества частиц, обновления их позиций в пространстве и, конечно же, рендеринга.
TBall *balls — массив шаров с информацией о цвете и статусе [прыгающий, перемещающийся, появляющийся].
Три объекта типа TAnimate — для обеспечения анимации. Класс имеет метод для инициализации ключевых кадров, которые представляют собой матрицы мирового преобразования, и методы для вычисления текущей позиции анимации и применения преобразования. В процедуре рендеринга объект engine последовательно отрисовывает шары и при необходимости вызывает метод ApplyTransform нужной анимации, чтобы сдеформировать либо переместить шар.
InitD3d, InitGeometry, InitAnimation вызываются только из конструктора TEngine и выделены в отдельные методы для наглядности. В InitD3d создается устройство Direct3D и устанавливаются все необходимые render state’ы, включая установку точечного источника освещения со specular-составляющей прямо над центром платформы.
Три метода AppearBalls, MoveBall и DetonateBalls запускают анимации появления, перемещения и взрыва, соответственно.
Методы IsSelected, IsMoving, IsAppearing, IsDetonating используются в функции менеджера состояний для отслеживания момента окончания анимации.
Методы с префиксом On вызываются контроллером при возникновении соответствующих событий: клика мышью, вращении камеры и т.д.

Рассмотрим основной метод Render:

В самом начале вычисляется, сколько миллисекунд прошло с предыдущего вызова Render(), затем обновляются прогрессы анимаций, если они активны. Очищаются буферы методом Clear и последовательно рисуются платформа, шары и система частиц, если она активна. Напоследок выводится строка с текущим значением заработанных очков.

TApplication

Класс имеет поле для хранения координат мыши, поскольку нам необходимо будет вычислять значения относительных смещений курсора, чтобы вращать камеру.
Булевы флаги appearStarted, moveStarted и detonateStarted необходимы для отслеживания статуса соответствующих анимаций.
В метод RegWindow вынесен код для регистрации класса окна.
Static-метод MsgProc — так называемая оконная процедура.
ProcessGame — упрощенная версия менеджера состояний, в котором оценивается текущее состояние игры и в зависимости от него предпринимаются какие-то действия.
MainLoop — цикл обработки сообщений.

Вот такой легковесный контроллер. Подобный цикл обработки сообщений можно встретить в любой книге по Direct3D:

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

А вот и функция менеджера состояний:

Что ж, пожалуй, на этом все!

Заключение

Здесь самое место, чтобы перечислить недостатки. Разумеется, в коде куча мест для оптимизаций. Кроме того, я не упомянул о таких вещах, как смена параметров видеорежима (разрешение экрана, multisampling) и обработка потери устройства (LostDevice). На счет последнего имеется подробное обсуждение на сайте gamedev.ru.

Надеюсь, мои изыскания принесут кому-то пользу. Кстати, исходники на github.

Источник статьи: http://habr.com/ru/post/251081/