Все о графике и программировании. Программирование графики Pascal ABC. Средства разработки баз и хранилищ данных
Богатые возможности Delphi и C++ Builder легко развиваются подключением других библиотек компонентов. В настоящее время существует множество различных библиотек для этих сред программирования, начиная от библиотек визуальных компонентов до мощных библиотек математического анализа. Особенный интерес при разработке программного обеспечения исследовательского оборудования представляет библиотека Component Works, разработанная американской фирмой National Instruments. Эта библиотека функционально повторяет библиотеку инструментов других продуктов этой компании - LabWindows/CVI и LabView, существенно расширяя спектр возможностей программ, созданных на Delphi или на C++ Builder.
Таким образом, средства визуального программирования, основанные на ООП - Borland Delphi и C++ Builder, благодаря скорости разработки программ и функциональным возможностям наиболее привлекательны для использования при разработке программного обеспечения исследовательского оборудования нового поколения практически в любой его части, а особенно в части программного обеспечения высшего уровня. Использование этих средств возможно и при разработке ответственных частей программного обеспечения, таких как программное обеспечение серверов, модули работы с сетью или модули управления оборудованием благодаря как возможности использования функций API в составе программы, так и возможностью написания программы с применением только функций API.
Средства графического программирования
Средства графического программирования занимают особое место в ряду средств разработки программного обеспечения. Для разработки программы с помощью средств графического программирования кроме некоторых навыков, как правило, не надо знать языков программирования, владеть методикой программирования в среде Windows и т. д. Все программирование производится на уровне структуры и алгоритма программы.
Изначально средства графического программирования были предназначены для упрощения доступа инженеров и научных работников, не знакомых с программированием, к разработке систем автоматизации. В основном, имелось в виду программное обеспечение для управления измерительным оборудованием и обработки результатов измерений. Но постепенно развитие графических средств программирования позволило существенно расширить сферу их применения вплоть до разработки программ мониторинга и управления производством или технологическими процессами. Особого прогресса в данной области добилась фирма National Instruments. Ее продукты LabView, LookOut и BridgeView следует рассмотреть отдельно.
LookOut представляет собой систему мониторинга и управления технологическими процессами: работа в реальном времени, поддержка большого количества стандартных измерительных и управляющих устройств, несколько уровней секретности и объявления нештатных ситуаций. Программная система в LookOut строится по принципу логической схемы, что оптимально для технологического процесса и абсолютно не приемлемо для более сложных задач (например, научных исследований), так как не позволяет строить сложные алгоритмы управления различными устройствами, осуществлять серьезную математическую обработку данных и многое другое. Поэтому для разработки программного обеспечения исследовательского оборудования LookOut непригоден.
LabView функционально ничем не уступает другим продуктам National Instruments (LabWindows/CVI или Component Works). LabView содержит подобные инструменты для создания интерфейса пользователя, работы с измерительным и управляющим оборудованием, математической обработки данных, работы в сети и т. д. К LabView также можно подключать программные модули, созданные в Других средах программирования, например, C++ или LabWindows/CVI. Программирование в LabView ведется на уровне Диаграмм. Диаграммы в LabView - это схемы алгоритмов. Основные элементы "алгоритмического языка" Lab View практически повторяют основные конструкции языка программирования Си.
При наличии определенных навыков создание достаточно сложной программы на LabView занимает у разработчика времени примерно на два порядка меньше, чем разработка такой же программы, например, на C++. Однако, основу LabView составляет runtime-engine, подобный аналогичному средству в LabWindows/CVI. Но в LabView оно выполняет значительно больше задач, благодаря чему LabView является практически самой быстрой и самой надежной системой в своем классе.
Однако LabView при всей своей привлекательности предназначена для создания небольших измерительно-управляющих систем, работающих в реальном времени, и не предназначена для разработки мощных, развитых программных комплексов, а тем более системного программного обеспечения, так как для этого LabView слишком громоздкая и медленная система. При создании подобных систем LabView будет проигрывать программам, созданным на C++, как по скорости работы, так и по необходимым компьютерным ресурсам. Поэтому LabView не подходит для создания программного обеспечения исследовательского оборудования.
BridgeView представляет собой построенную на основе LabView систему управления предприятиями и технологическими процессами с элементами разграничения доступа и системы предупреждений, заимствованных из LookOut, и ее использование при создании программного обеспечения для исследовательского оборудования также нецелесообразно.
Операционные системы разделяют на два основных класса: ОС общего назначения и ОС реального времени (ОС РВ), хотя в последнее время границы между ними заметно стираются - многие задачи реального времени успешно решаются современными версиями систем общего назначения.
Операционные системы общего назначения Применительно к задачам автоматизации наиболее популярны такие ОС как Windows 3.1/95/NT, HP-UX, Solaris, MacOS, UNIX. Все они являются многозадачными системами и, в основном, используются в решении задач автоматизации с централизованным управлением, когда в системе имеется конкретная управляющая ЭВМ. Для ОС общего назначения характерна единая среда, используемая как для разработки прикладных программ, так и для их исполнения. Операционные системы общего назначения по сравнению с ОС РВ дешевле, проще в использовании и отладке приложений.
Операционные системы реального времени. Основными преимуществами систем реального времени по сравнению с ОС общего назначения являются:
· гарантированное время реакции системы на запросы и прерывания от внешних устройств при возникновении непредвиденных ситуаций;
· разделение среды разработки прикладного ПО и среды его исполнения.
ОС РВ предназначены, как правило, для применения в распределенных многопроцессорных системах с децентрализованным управлением, поэтому они дороже и сложнее в использовании. Среди наиболее известных ОС РВ можно назвать следующие системы: OS-9/OS-9000, VxWorks, LynxOS, VMEexec.
Средства разработки баз и хранилищ данных
Программирование. Графика Pascal-Паскаль
Формирование изображения на экране
Работа с графикой в Паскале
Константы, определяющие графический режим
Некоторые процедуры для работы с графикой
Основные понятия графики
В современных компьютерах изображения на экране строятся в виде растров , и всегда прямоугольных.
Пример растра и изображения, построенного на нем:
На рисунке вы видите сильно увеличенную картинку, на самом же деле элементарные точки , из которых состоит изображение, или пиксели , должны быть очень маленькими, чтобы глаз воспринимал картинку как единое целое. Пиксель (Pixel ) – сокращение от Picture Element (элемент рисунка).
Экраны цветных мониторов состоят из прямоугольной решетки точек (пикселей), светящихся разным цветом. Каждый цветной пиксель образован тремя более мелкими по площади участками красного, зеленого и синего цветов. При свечении этих участков с разной интенсивностью цвета смешиваются, создавая элементы изображения различных оттенков и яркости.
Важной характеристикой растра является его расширение , т.е. количество точек (пикселей) на единицу длины. Чем это число выше, тем более мелкими являются сами пиксели, и, соответственно, более плотно они располагаются на плоскости, что и приводит к тому, что мы воспринимаем их как единое, цельное изображение. Из года в год разрешающая способность мониторов, принтеров, сканеров и т.п. растет.
Итак, на растровом устройстве отображения любая фигура состоит из множества точек пикселей. Естественно, положение каждой точки изображения задано координатами X и Y. Координаты – целые числа, они задают номера колонки и строки растра и не зависят от физического размера экрана. Оси координат направлены следующим образом: горизонтальная ось X направлена слева направо; вертикальная ось Y направлена сверху вниз; верхний левый угол имеет координаты (0,0).
Очевидно, что запись изображения требует хранения информации о положении множества точек, для каждой из которых должен быть задан цвет. Цветное изображение получается смешиванием трех основных цветов – красного, зеленого и синего. Такая модель представления цвета называется моделью RGB (Red - Green - Blue). Управляя интенсивностью компонентов, можно получить различные оттенки и степени интенсивности цвета. В частности, для получения градаций серого надо взять интенсивности трех основных цветов равными друг другу.
В современных SVGA мониторах предусмотрено, как правило, по 2 6 =64 уровня интенсивности каждого из основных цветов, таким образом, в целом можно получить (2 6) 3 =262144 цвета. Для представления большего числа цветов необходим больший объем памяти. Один бит может кодировать два цвета: 1 – белый, 0 – черный. Два бита могут хранить 2*2=4 цветовых комбинации, 4 бита – 16, 8 бит – 256, 16 бит – 65536, 32 бита – 4294967296.
Если для каждой точки задавать уровни красного, зеленого и синего цветов, то потребуется достаточно большой объем памяти для хранения информации об изображении. Для сокращения объема памяти используются палитры. При этом ограничиваются некоторым количеством цветов, например, 16 или 256, каждому из цветов присваивается номер (соответственно, от 0 до 15 или от 0 до 255), и при записи изображения используют именно этот код. «Точка цвета номер 5». Информация о палитре, то есть данные, сколько красного, зеленого и синего нужно взять для получения «цвета номер 5», хранится и используется отдельно от записи изображения.
Важное понятие в машинной графике – графический примитив – совокупность пикселей, определяющая некоторую геометрическую фигуру. Наиболее распространенные примитивы – это точка, линия, прямоугольник, закрашенный прямоугольник, окружность и эллипс .
Растровые изображения обладают одним очень существенным недостатком: их трудно увеличивать или уменьшать, т.е. масштабировать. При уменьшении растрового изображения несколько соседних точек преобразуются в одну, поэтому теряется разборчивость мелких деталей. При увеличении – увеличивается размер каждой точки, поэтому появляется ступенчатый эффект. Кроме того, растровые изображения занимают много места в памяти.
Чтобы избежать указанных проблем, изобрели так называемый векторный способ кодирования изображений.
Векторный способ представления графики заключается в том, что геометрические фигуры, кривые и прямые линии, составляющие рисунок, хранятся в памяти компьютера в виде математических формул и геометрических абстракций: круг, квадрат, эллипс и т.п. Для каждого примитива существуют свои характерные параметры. Например, для отрезка – это координаты концов; для окружности – координаты центра и радиус. Т.е. размеры, кривизна, местоположение элементов изображения хранятся в виде числовых коэффициентов. Благодаря этому появляется возможность масштабировать изображения, поворачивать, подвергать любым другим геометрическим преобразованиям с помощью простых математических операций, в частности, простым умножением параметров на коэффициент масштабирования. При этом качество изображения не меняется.
Формирование изображения на экране
Из книги Румянцева Дмитрия, Монастырского Леонида «Путь программиста: Опыт созидания личности программиста». – М.: «Издательский Дом ИНФРА-М», 2000.
Программисту не обязательно знать технические подробности конструкции монитора, но общее представление о его схеме он иметь должен. Еще важнее представлять, как программа работает с памятью, когда осуществляет вывод информации на какое-либо из устройств визуального отображения, подключенных к компьютеру.
Участок оперативной памяти компьютера, где хранится информация об изображении, появляющемся на экране, называется видеопамятью . Иногда эту область называют видеобуфером . Видеопамять занимает определенную область в адресном пространстве оперативной памяти компьютера, следовательно, видеопамять имеет ограниченный размер .
Видеопамять и похожа, и в то же время не похожа на RAM . Обычная память соединена с центральным процессором специальным устройством, которое называется шина данных. Не останавливаясь подробнее на конструкции шины данных, скажем лишь, что это просто пакет проводов, количество которых кратно двум. Можно сказать, что чем больше проводов в пакете, тем быстрее происходит обмен данными между процессором и памятью. Современные Pentium -машины имеют 32-разрядную шину, т.е. процессор может сразу читать 4 байта из памяти (и столько же в нее записывать). Разрядность шины данных – одно из самых узких мест в конструкции компьютера.
Видеопамять, как и любая другая память, соединена с процессором шиной данных. Но видеопамять, кроме того, подключена к специальной электронной схеме, которая на основе данных, хранящихся в видеобуфере, формирует изображение на экране. Физически экранное изображение обновляется 60 раз в секунду – с такой частотой упомянутая электронная схема осуществляет сканирование видеобуфера. Поэтому любое изменение состояния видеобуфера практически мгновенно (с точки зрения человека, смотрящего на экран) приводит к изменению изображения на экране.
Электронная схема, сканирующая видеобуфер и преобразующая двоичные числа в видеосигнал, называется адаптером видеодисплея или просто видеоадаптером .
Сегодня все большую популярность приобретают так называемые жидкокристаллические мониторы. Но большинство действующих сегодня мониторов по-прежнему представляют собой устройства, изображения в которых строится с помощью электронно-лучевой трубки. Напомним еще раз известный из курса физики принцип формирования изображения, получаемого в этом случае.
Этот способ называется растровым сканированием . Изображение «рисуется» тщательно сфокусированным электронным лучом. Поток электронов «бомбардирует» экран, покрытый специальным светящимся веществом – люминофором. Места, в которые ударяются электроны, начинают фосфоресцировать. В каждой точке свечение затухает приблизительно в течение нескольких сотых долей секунды, поэтому необходимо постоянно повторять «бомбардировку» поверхности экрана. Это задача специального устройства – электронной пушки. Наводчик электронной пушки (специальное электронное устройство) рассматривает весь экран как последовательность множества линий. Он «простреливает» последовательно каждую линию – слева направо, точка за точкой.
Движение луча по экрану происходит с огромной скоростью. Чтобы изображение, которое воспринимает человек, не было мерцающим, весь цикл – от первой до последней строки – должен быть закончен за 1/60 секунды (или еще быстрее). Следовательно, за секунду происходит не менее 60 проходов луча по всему экрану, строка за строкой. Такая схема формирования изображения называется растром . После того, как луч доходит до последней точки последней строки (до правого нижнего угла экрана), он мгновенно по диагонали переносится в начало первой строки экрана (левый верхний угол), и процесс повторяется.
Формирование цветного изображения осуществляется не одним, а тремя электронными лучами (красным, зеленым и синим), перемещающимся по экрану одновременно. Три луча подсвечивают сразу три элемента экрана, расположенных на очень незначительном угловом расстоянии друг от друга, поэтому человеческий глаз воспринимает эти три элемента как одну точку. Благодаря различной интенсивности свечения каждой из трех точек и эффекту аддитивного смешения трех цветов такая составная точка может иметь любой цветовой оттенок. Качество изображения тем выше, чем меньше расстояние между двумя отдельными точками. В современных мониторах расстояние между точками не превышает 0.25–0.26 мм.
Вернемся к видеоадаптеру. Помимо всего прочего, он должен подавать специальные синхронизирующие сигналы электронной пушке для правильного формирования изображения на экране. Первый синхронизирующий сигнал – V -сигнал – подается для начала сканирования экрана; второй сигнал – H -сигнал – для начала сканирования очередной строки. Кроме того, видеоадаптер должен управлять интенсивностью сканирующего луча. Интенсивность луча может меняться при прохождении каждой растровой точки, а значит можно произвольно менять и интенсивность свечения точки.
Существует два принципиально разных способа указания интенсивности свечения пикселя.
Первый применяется в так называемых цифровых мониторах. В этом случае для каждой точки монитору подается информация об ее интенсивности в виде двоичного числа. Используя аддитивную модель, передавая два бита для каждого цвета (красный, зеленый и синий), из которых формируется цвет точки, можно получить 64 цвета (4*4*4). Однако при увеличении количества цветов нужно увеличивать и количество битов для каждого цвета (т.е. количество проводов для каждого цвета).
Поэтому конструкторы мониторов, в конце концов, отказались от цифровой схемы и пришли к аналоговой. При этой схеме сигналы V и H остаются по-прежнему цифровыми, а сигналы о трех составляющих цвета становятся аналоговыми и поступают по трем проводам. На каждом проводе поддерживается напряжение от 0 до 1 вольта с плавным переходом из одного состояния в другое. Ноль вольт на проводе указывает на отсутствие свечения, 1 вольт – на максимальное свечение. При такой схеме каждый из трех цветов условно может принимать бесконечное число оттенков. Следовательно, таким образом можно задавать десятки миллионов цветов.
Работа с графикой в Паскале
Инициализация графического режима. Множество графических процедур и функций среды программирования Pascal собраны в модуле Graph . Для подключения библиотеки графических функций и процедур необходимо подключить модуль к вашей программе строкой Uses graph ;
Взаимодействие программы и видеосистемы в графических режимах обеспечивают драйверы. Драйверы собраны в файлах, имеющих расширение BGI: CGA.BGI, EGAVGA.BGI, HERC.BGI, IBM 8514.BGI, ATT.BGI, PC 3270.BGI и др. Драйвер – это специальная программа, осуществляющая управление тем или иным техническим средством ПК. Графический драйвер управляет графическим адаптером в графическом режиме.
Графические возможности конкретного адаптера определяются разрешением экрана, т.е. общим количеством пикселей, а также количеством цветов. Кроме того, многие адаптеры могут работать с несколькими графическими страницами.
Для инициализации графического режима используется процедура:
InitGraph(var Driver, Mode: integer; Path:string);
где Driver – переменная типа integer , определяющая тип графического драйвера; Mode – переменная того же типа, задающая режим работы графического адаптера; Path – выражение типа string , содержащее путь доступа к файлу драйвера.
Таблица 1. Константы, определяющие графический режим.
|
Графический драйвер |
Константа режима |
Растр |
Палитра |
Число страниц |
||
|
Значение |
Значение |
|||||
|
Выбор драйвера автоматически |
||||||
Пример фрагмента программы, где инициализируется графический режим
Program primer ; Uses graph ; Var D , m: integer ; {переменные для установки драйвера и режима работы} Begin D:=9; M:=2; InitGraph (d , m,‘здесь нужно указать путь к драйверу EGAVGA.BGI’}
Наиболее простой способ выбора графического драйвера и режима – автоматический (detect ).
Пример фрагмента программы, где инициализируется графический режим
Program primer ; Uses graph ; Var D , m: integer ; {переменные для установки драйвера и режима работы} Begin D:= detect ; InitGraph (d , m , ‘здесь нужно указать путь к драйверу EGAVGA . BGI ’}
Проверка результата инициализации графического режима. Для проверки успешности инициализации графического режима существует функция GraphResult , которая имеет тип результата integer , в котором закодирован результат последнего обращения к графическим процедурам. Если ошибка не обнаружена, значением функции будет 0, в противном случае – отрицательное число, имеющее следующий смысл:
GrOk =0 ; {нет ошибок}
GrInitGraph =-1 {не инициирован графический режим}
GrNotDetect =-2 {не определен тип драйвера}
GrFileNotFind =-3 {не найден графический драйвер}
GrInvalidDriver =-4 {неправильный тип драйвера}
GrNoLoadMem =-5 {нет памяти для размещения драйвера}
GrNoScanMem =-6 {нет памяти для просмотра областей}
GrNoFloodMem =-7 {нет памяти для закраски областей}
GrFontNotFound =-8 {не найден файл со шрифтом}
GrNoFontMem =-9 {нет памяти для размещения шрифта}
GrInvalidMode =-10 {неправильный графический режим}
GrError =-11 {общая ошибка}
GrIOError =-12 {ошибка ввода-вывода}
GrInvalidFont =-13 {неправильный формат шрифта}
GrInvalidFontNum =-14 {неправильный номер шрифта}
Завершение работы графического режима. Завершает работу адаптера в графическом режиме и восстанавливает текстовый режим работы экрана процедура CloseGraph .
Запомните! Любая программа, использующая графический режим, будет иметь одну и ту же структуру:
определение графического драйвера;
установка графического режима;
инициализация графического режима;
построения;
закрытие графического режима .
Напишем заготовку типовой программы работы с графикой:
Пример заготовки к графическому режиму.
Program primer ; Uses graph ; Var D , m: integer: {переменные для установки драйвера, режима} Begin D:= detect; InirGraph(d,m, ‘ путь к драйверу ’); If GrapfResult =0 then {если инициализация прошла успешно} begin <описание всех ваших построений> closeGraph ; end else writeln (‘произошла ошибка при инициализации графики’); end .
Некоторые процедуры для работы с графикой
Установка цвета.
Драйвер EGAVGA . BGI позволяет использовать 16 цветов. Каждому цвету присвоен код – целое число, которое используется процедурами и функциями.
Таблица 2. Константы цветов
|
Имя константы |
Номер цвета | |
|
Темно-синий |
||
|
Темно-зеленый |
||
|
Бирюзовый |
||
|
Фиолетовый |
||
|
Коричневый |
||
|
LightGray |
Светло-серый |
|
|
DarkGray |
Темно-серый |
|
|
LightBlue | ||
|
LightGreen |
Светло - зеленый |
|
|
LightCyan |
Светло-бирюзовый |
|
|
LightRed | ||
|
LightMagenta |
Малиновый |
|
Цвет выводимых в графическом режиме на экран линий и символов можно задать процедурой SetColor(color: word);
аргумент которой – целое число от 0 до 15 или имя одной из приведенных выше констант.
Установка цвета действует на те линии и тексты, которые выводятся после ее вызова, но не меняет цвет линий и символов, выведенных на экран ранее. Таким образом, процедуру SetColor следует вызывать каждый раз перед выбором нового цвета. Если цвет не установлен, то используется белый цвет.
Установка цвета фона.
Чтобы установить цвет фона для всего экрана, используется процедура:
SetBkColor(color: word);
Если процедура установки цвета фона не вызвана, экран будет черным.
Установка указателя вывода
Процедура MoveTo (x,y:integer) перемещает указатель в точку с координатами x, y.
Процедура MoveRel (dx, dy: integer) перемещает указатель на dx, dy пикселей относительно последнего положения.
Функции GetX и GetY возвращают координаты x, y указателя вывода.
Установка точки
Процедура PutPixel (x, y: integer; color: word) устанавливает точку с координатами (x, y) и закрашивает ее указанным цветом color .
Функция GetPixel (x, y: integer): word возвращает значение цвета, в который окрашена точка с координатами (x, y).
Рисование линий
Процедура Line (x1, y1, x2, y2: integer) вычерчивает линию между двумя точками экрана с координатами (x1, y1) и (x2, y2).
Процедура LineTo (x, y: integer) вычерчивает линию от последнего положения указателя до точки с координатами (x, y).
Окружность, эллипс, дуга, сектор
Процедура Circle (x, y: integer; r: word) вычерчивает окружность радиуса r с центром в точке с координатами (x, y).
Процедура Arc (x, y, ugol_begin, ugol_end, r: integer) вычерчивает дугу окружности радиуса r с центром в точке с координатами (x, y). Параметры ugol_begin и ugol_end задают угловые координаты начала и конца дуги. Отсчет углов ведется против часовой стрелки. Значения угловых координат задается в градусах.
Процедура Ellips (x, y: integer; ugol_begin, ugol_end, rx, ry: word) вычерчивает эллипс или дугу эллипса с центром в точке с координатами (x, y). Параметры ugol_begin и ugol_end задают угловые координаты начала и конца дуги. Параметры rx и ry определяют горизонтальный и вертикальный радиусы эллипса.
Процедура PieSlice (x, y: integer; ugol_begin, ugol_end, r: word) вычерчивает сектор окружности радиуса r с центром в точке с координатами (x, y). Параметры ugol _begin и ugol_end
SetFillStyle (о ней чуть позже).
Процедура Sector (x, y: integer; ugol_ begin, ugol_ end, rx, ry: word) вычерчивает сектор эллипса с центром в точке с координатами (x, y) и горизонтальным радиусом rx , вертикальным - ry . Параметры ugol_begin и ugol_end задают угловые координаты начала и конца сектора.
Сектор может быть закрашен в соответствии со стилем, заданным процедурой SetFillStyle .
Прямоугольник; закрашенный прямоугольник; параллелепипед
Процедура Rectangle (x1, y1, x2, y2: integer) вычерчивает контур прямоугольника. Параметры x1, y1 задают положение левого верхнего угла, x2, y2 – правого нижнего.
Процедура Bar (x1, y1, x2, y2: integer) вычерчивает закрашенный прямоугольник. Параметры x1, y1 задают положение левого верхнего угла, x2, y2 – правого нижнего. Стиль и цвет заливки определяется процедурой SetFillStyle .
Процедура Bar3 D (x1, y1, x2, y2: integer; глубина: word; граница: boolean) вычерчивает параллелепипед. Параметры x1, y1 задают положение левого верхнего угла, x2, y2 – правого нижнего угла ближней грани. Параметр глубина задает расстояние между передней и задней гранями в пикселях. Параметр граница определяет, нужно ли вычерчивать верхнюю границу задней грани параллелепипеда. Стиль и цвет заливки ближней грани определяется процедурой SetFillStyle .
Вывод текста в графическом режиме.
Процедура OutText (text: string) выводит строку символов text от текущей позиции указателя вывода и перемещает указатель в точку, расположенную за последним выведенным символом.
Естественные языки, хотя и интересны во многих аспектах, совершенно не подходят для описания алгоритмов. Поэтому не удивительно, что алгоритмы значительно лучше описываются на алгоритмическом языке.
Алгоритмический язык, “понятный” компьютеру, называется языком программирования высокого уровня, или просто языком программирования. В дальнейшем будем иметь в виду именно такое применение, но несколько расширим понятие и будем считать язык программирования действительно “языком
высокого уровня”, если не только компьютер, но так же и человек может понимать его по возможности эффективно и просто. Мы не будем требовать, чтобы язык был легко читаемым для всех. Математические символы непонятны большинству восьмилетних детей, но без них не могут обойтись математики и инженеры. Таким же образом и языки программирования совсем не обязательно должны быть понятными для всех, но они совершенно необходимы профессиональным программистам. Здесь мы будем применять язык Си не только потому, что он достаточно распространен, но главным образом из-за его высокого качества. Для программирования на языке Си нужно быть очень аккуратным, на языке Си логические ошибки приводят к синтаксическим ошибкам гораздо реже, чем, например, на языке Паскаль. Поэтому такие логические ошибки в программе на языке Си могут привести к неправильным результатам или к выводу сообщений о технических ошибках, которые могут оказаться совершенно непонятными. Другими словами, ошибки могут привести к непредсказуемым результатам. Это постоянно следует иметь в виду при программировании на языке Си. При написании программ всегда желательно, чтобы они были легко читаемыми, но это совершенно другой аспект. Люди, которые сами не используют этот язык, полагают, что программы на языке Си воспринимаются с трудом. Но с проблемой читаемости всегда очень сложно. Если одна строка программы на языке Си соответствует десяти строкам программы на языке Бейсик, то несерьезно утверждать, что одну строку языка Си труднее прочитать, чем десять строк языка Бейсик. Если попытаться разобраться в короткой программе на языке Си, заранее предполагая, что она простая, поскольку короткая, то можно очень быстро разочароваться. Об этом нельзя забывать при чтении примеров в этой книге: очень короткие программы на языке Си могут быть совсем не тривиальными и даже интересными!
Для серьезного изучения семантики языка Си в конце книги упомянуто несколько книг о данном языке. Но для пояснения применения языка Си в этой книге ограничимся только такими конструкциями, которые являются специфичными для этого языка. Некоторые сведения о языке Си приведены в Приложении. Рассмотрим здесь самую первую графическую Сопрограмму:
(кликните для просмотра скана)
Программа содержит обращения к четырем графическим подпрограммам:
initgr инициирует графический вывод;
move перемещает перо (реальное или фиктивное) в точку с координатами ху у;
draw вычерчивает отрезок прямой линии из текущей позиции пера в точку с координатами х, у;
endgr выполняет заключительные операции по выводу оставшейся информации из выходного буфера.
В языке Си для обозначения технических терминов “процедура” или “подпрограмма” применяется термин “функция”. Обращение к функции записывается обязательно с парой круглых скобок, даже если аргументы отсутствуют. Перед обращениями к функциям move и draw обязательно должно стоять обращение к функции Аналогично вслед за последним обращением к функции move или draw должно стоять обращение к функции endgr. Обе функции, обеспечивают перемещение реального или фиктивного пера в точку с координатами х, у причем при работе функции перо перемещается в поднятом положении, а при работе функции в опущенном. Все упомянутые четыре функции не относятся к языку Си. Это внешние функции, после компиляции любой программы они должны быть добавлены к ней с помощью редактора связей. Если эти программы недоступны непосредственно, то они могут быть выражены через обращения к другим доступным графическим подпрограммам.
В этой книге не будут рассматриваться вопросы об используемых технических средствах. Вместо обсуждения особенностей различных плоттеров и других графических устройств здесь все внимание будет сфокусировано на общих, приборно-независимых принципах программирования. При технических средствах, использовавшихся автором, подпрограмма просит пользователя выбрать один из возможных режимов работы - “немедленный” или “задержанный”. Выбор режима “немедленный” приводит к тому, что сформированный графический вывод сразу же посылается на экран терминала, что обеспечивает возможность взаимодействия. Режим “задержанный” приводит к записи информации о чертеже в файл на диске, который затем может
быть преобразован для пересылки на различные устройства, такие как перьевой плоттер, матричное печатающее устройство, или на упомянутый ранее графический терминал. Все эти устройства будут хорошо работать, если диапазоны изменения координат х и у будут удовлетворять условиям То есть точка с координатами х, у располагается на расстоянии х дюймов справа от оси у и на расстоянии у дюймов над осью х. Иначе говоря, начало О системы экранных координат располагается в нижнем левом углу экрана. Те читатели, которым это почему-либо не нравится, могут внести любые изменения в систему координат, особенно после изучения данной книги! Кроме того, в главе 2 будет рассмотрена возможность задания границ рисунка более элегантным способом.
Графическое изображение на рис. 1.1 состоит из 50 квадратов. Сначала вычерчивается квадрат затем на стороне выбирается точка А такая, что Аналогичным образом вычисляется положение точек на сторонах квадрата соответственно. После этого точкам присваиваются имена и процедура повторяется.
Всех, кто не любит Android, Live Wallpaper, Minecraft, велосипеды, поток сознания, который слабо привязан к теме и всё около того, хочу сразу предупредить, что их может огорчить содержание этого поста, поэтому продолжайте чтение на свой страх и риск. Оставлю тут также и предупреждение для пользователей мобильного или просто небезлимитного интернета: дальше последует довольно много картинок .
Здравствуйте!
Я разработчик ПО с многолетним стажем. Нельзя сказать, что моя работа однообразна и скучна. Я решаю задачи разного уровня, иногда придумываю решения, иногда сам же и реализую их, иногда ищу уязвимости в системах, а иногда и просто рассказываю, почему монитор - это не компьютер. Пожалуй именно то, что я не занят только кодингом, вносит долю разнообразия и творчества в рабочий процесс.Бывает также, что из-за различных проблем (бюджет или время на разработку ограничены или просто кого-то из вышестоящих петух клюнул не туда, куда было необходимо), приходится искать готовые решения для многих вещей, что превращает мою работу в детскую игру с кубиками, где требуется “класть кубик на кубик” и смотреть, как манагеры хлопают в ладоши. Пожалуй это и есть та вещь, которая превращает мою работу в рутину (хотя да, даже в моменты “игры с кубиками”, я обычно продолжаю рассказывать, что монитор - это не компьютер). Чтобы хоть как-то избежать рутины и не забыть, каково же реализовывать простые вещи, я люблю в свободное время программировать “всё подряд”. И я заметил, что обожаю именно программирование графики…
О чём речь?
Начну с начала, без особых отступлений о том, кто я и почему. Купив новый телефон (тут уже вырисовывается тенденция моих статей на хабре...), мне захотелось поставить себе “живую обоину”, т.к. уж не знаю почему, но нравится мне, когда на экране что-то шевелится. Наверное всё потому, что тогда я чувствую, что купил телефон с четырёхядерным процессором не зря. Погулял по стору, подумал, что бы я хотел видеть на экране и решил, что хочу что-то в стиле майнкрафта, но к сожалению не нашёл ничего, что бы должным образом радовало меня. Тут то я и имел неосторожность решить сделать всё сам…Первые сомнения на этот счёт...
Следует немного отвлечься от основного рассказа и пояснить, почему у меня были сомнения на счёт идеи “а напишу - ка я себе что-то сам”. В школьные годы на компьютерах была установлена игра (как я узнал совсем недавно, игра называлась “Клад” для БК-0010), где белый человечек (за кого и следовало играть) собирал что-то (в моей памяти это были именно ключи, хотя, как выяснилось позже, это должны были быть сундуки), а чёрный человечек за что-то очень ненавидел белого и убивал его прикосновением. Не знаю почему, но мысли об игре вызывали у меня ностальгические чувства, и поэтому я решил “а напишу-ка я её сам”.Чтобы не утомлять Вас рассказом о процессе разработки и прочих деталях (не о том моя история), просто опишу смысл: написал, работало именно так, как я запомнил, поиграл один раз, бросил, т.к. уже “наигрался” в процессе отладки .
Для тех, кому интересно, результат получился вот такой:
Внутренний голос и тут говорил мне о том, что я не стану пользоваться результатом своих трудов, т.к. слишком насмотрюсь на него за время разработки, но я, как обычно, решил, что “уж в этот раз такого точно не будет” (сила самоубеждения, ага). Забегу вперёд и скажу, что внутренний голос был прав…
А где тут программирование графики?!
Попробую вернуться к основному рассказу. Я сразу решил, что не буду использовать ни OpenGL, ни ещё чего-то, что помогло бы мне реализовать задачу - только хардкор. Тем более, меня всегда интересовало взаимодействие Java кода с нативным кодом под Android, а тут ещё и подвернулась неплохая возможность попробовать свои силы в решении этой задачи.Сразу решил проверить, смогу ли я вообще реализовать прорисовку с достаточной частотой кадров, с постоянным вызовом нативной библиотеки. Для проверки я реализовал следующую задачу - заполнение экрана картинками с каким-то произвольным коэффициентом “затенения” (по сути просто с параметром яркости, где исходная картинка считается максимально яркой). Написал вариант на Java и C++. Прогнал оба варианта с грубым тестом подсчёта времени и увидел, что в среднем вариант на C++ работал немного быстрее, даже несмотря на то, что сам вывод готового изображения “на экран” всё-же делала Java. В качестве картинок я сразу взял одну из симпатичных, на мой взгляд, текстур для майнкрафта, результат получился примерно таким:
Поскольку я с самого начала решил, что стану всё реализовывать сам и не буду подглядывать в литературу или искать помощь в интернете, то в края моего изображения выглядели примерно так:
Очевидно, что неверно обрабатываются изображения, от которых следовало нарисовать только часть, исправляем…
Итак, задача решаема, а значит можно браться за дело и начинать искать решение и оптимальную реализацию.
Поскольку для реализации я выбрал решение с использованием JNI, то в результате разработку вёл в смешанном режиме. Основную логику я писал и проверял под Windows, генерируя сразу изображение для 10-и экранов (это и есть те широкие изображения, которые последуют далее в статье), а время от времени я проверял решение на телефоне.
“Результаты”
Итак, линия горизонта (пока случайными блоками, даже не знаю, почему сделал случайными - пишу статью и сам с себя удивляюсь):
Большие картинки кликабельны, но habrastorage немного уменьшил их размер (оригинал был 7200 х 1280)
Теперь от случайного мусора, переходим к осмысленному содержанию. Линия горизонта «осмысленно»:
Далее было необходимо создать “пещеры” (углубления в поверхности), чтобы рельеф не смотрелся так примитивно. Т.к. к тому моменту реализация была ещё сырая, то проверка алгоритма создания пещер представляла собой рисование “пещер” другой текстурой:
Следующим шагом было решено разделить всё на передний и задний план, причём задний план должен был отличаться более тёмной текстурой:
Это уже похоже на что-то, но ещё очень далеко от результата.
Поменял текстуры, решил добавить внизу источник света - лаву, но ошибся с текстурой, поэтому низ был «заполнен факелами»:
Исправляю и добавляю ещё один источник света - факелы:
Понял, что соотношение блоков переднего и заднего плана меня не устраивает и поменял коэффициенты:
Забегая вперёд, следует отметить, что это та часть, которую я менял много раз, чтобы добиться такого результата, чтобы успокоиться и больше не трогать его.
Целью добавления источников света было более адекватное освещение - освещение от источников света. Источники света были поделены на три группы:
- Освещение от неба. Самый яркий источник света, но изначально была задумана смена времени суток, а значит и освещение от неба зависит от времени.
- Освещение от лавы. Менее яркий источник света, чем небо днём, но яркость не меняется во времени.
- Освещение от факелов. Наименее яркий источник света. Яркость также постоянна.
Слева распространение света от источников, а справа просто “задний план темнее, чем передний”.
Тут стала напрашиваться прозрачность, ведь нельзя оставлять факелы с белым фоном. Чтобы избежать вопросов “и в чём же проблема?”, напомню, что у меня есть массив одних циферок (пикселей) и других циферок (тоже пикселей) и все правила переноса и прорисовки необходимо было ещё написать. Хотели прозрачность - вот вам прозрачность (ещё чуть чуть прозрачнее и было бы необходимо рисовать картинку с камеры телефона, чтобы было достаточно “прозрачно”):
Исправляем…
Исправляя фон, случайно “закрасил” и пещеры землёй:
Я знаю, что может показаться, что-то из этого было сделано умышлено, но уверяю вас, что все результаты были получены случайно. По правде говоря, я даже затрудняюсь сказать, как мне это удалось, но результат такой, какой он есть. Исправляем и это…
Освещение блока за факелом вычисляется неверно (блок за факелом темнее, чем соседние блоки):
Ошибка довольно глупая, но сразу я как-то и не подумал, что факел может быть в хорошо освещённом месте и считал освещённость блока максимальным значением яркости факела. Решений могло быть по крайней мере два - исправить освещение или убрать факелы из освещённых мест. Я решил исправить освещение.
Теперь я решил, что необходимо сделать возможность указывать строку (seed), которая задаёт уникальную “карту”, а значит нужна была и своя реализация генерации случайных чисел (на самом деле не была нужна, т.к. хватило бы и обычного rand, но просился велосипед):
и
Вышло довольно “случайно”, если не сказать больше.
Следующим шагом, были добавлены дополнительные блоки (этот шаг я упускаю, уж извините, и так очень много картинок), чтобы разнообразить внешний вид рельефа и тут пришла очередь деревьев.
Про деревья я хочу отдельно сказать пару слов… К середине процесса разработки у меня уже был комментарий в коде, несколько записей на бумаге и одна пометка к скриншотам, примерно такого содержания: “i h8 3s”. И на то были причины. Деревья сразу пошли как-то сложно. Каждая мелочь, каждая правка кода обязательно сказывалась на деревьях. В целом, как бы смешно это не звучало, но самой большой занозой оказались именно деревья.
Итак, первая итерация мучений с деревьями:
Для начала было решено сделать ствол дерева и листья над стволом (пока без листьев по бокам), но даже тут я перепутал блоки и получил перевёрнутый результат.
В результате, после смены количества деревьев, получился вот такой результат:
Затем я решил, что алгоритм генерации линии горизонта огорчает меня и что было бы неплохо его поправить, что я и сделал. Результат был довольно предсказуемый - ничего хорошего:
Потом последовал обычный для многих разработчиков quick-fix, без особого вникания в суть проблемы (ведь я же только что писал этот код, очевидно, что я могу его исправить не задумываясь!), что, как и можно было предположить, к положительному результату это не привело:
Довольно любопытно то, что линия горизонта не совершенно ровная, а имеет небольшое искажение в начале.
В результате я поэкспериментировал с разными параметрами и после множества результатов успокоился и перестал думать о исправлениях для линии горизонта. Вот несколько результатов для линии горизонта:
После того, как я получил работающий прототип, пришло время отладить его, почистить код и заняться оптимизацией. Начал я с того, что стал избавляться от magic numbers, которых было около 10 и которые привязывали большую часть параметров к размеру экрана и блоков на момент тестов.
А деревья всё продолжали огорчать - необходимо было сделать так, чтобы они генерировались только на земле, для объёма добавил затенение на некоторые блоки листьев (что кстати тоже к тому моменту не работало так, как хотелось бы):
Стало ясно, что нужно отладить функцию прорисовки затенённый блоков, а заодно и оптимизировать в ней кое-что. Снова быстрое исправление “ошибок”, снова довольно забавный результат:
Тут меня почти моментально “осенило”, что же я сделал неправильно и новое исправление не заставило себя долго ждать:
Тут следует сразу оговориться, что обычно я не пишу код в таком стиле (т.е. в стиле “сначала пишу, потом думаю”). Но в данном проекте я находил это очень забавным. Ведь каждая моя ошибка, каждая глупость, обязательно приводила к результату, причём очень редко я мог предсказать этот результат или сразу объяснить “почему так”.
К этому моменту, текстура листьев и травы (земля с травой) была определённого зелёного цвета. Просилась реализация, которая позволяла бы менять цвет, позволяя малой кровью менять время года. Да, я отлично знаю, что это можно было легко сделать в джаве и не придумывать ничего, но спортивный интерес был слишком силён. Для этого, текстура была изменена и была написана функция для “покраски текстуры”:
Саму функцию пришлось несколько раз исправлять, т.к. она создавала эффект разнокалиберного полосатика (два изображения в середине), но не делала того, что необходимо (правое изображение). Вот несколько результатов работы алгоритма:
Время от времени, я правил те или иные методы, чтобы привести в порядок код и время от времени получал самые разные результаты. Ещё один из примеров:
Время от времени всплывали и довольно забавные ситуации из мира отладки. Например, ошибка в прорисовке градиента (очередной генератор разноцветных полосатиков):
Во время отладки этой ошибки, когда у меня уже стали заканчиваться идеи, отладчик выдал вот такое значение цвета:
В тот день отладку я оставил и решил отдохнуть, чтобы отладчик перестал рассказывать про плохое качество еды.
На этом моменте я решил начать параллельно тестировать результат и на телефоне. В телефоне порядок цветов оказался немного другим, поэтому красная и синяя составляющие цвета поменялись местами:
Кстати, я забыл лишний раз напомнить, что ненавижу деревья… Деревья ночью вели себя странно:
В это время, у телефона вообще был свой собственный взгляд на то, как следует рисовать картинку после смещения (скролинга пальцем):
и 
Ладно, цвет на картинке слева такой, потому что я забыл про положение синей и красной составляющей, а вот модный эффект motion blur - это уже “спасибо” android за то, что он совершенно верно рисовал моё изображение, у которого я не подумал про альфа канал (в альфа канале к тому моменту могло быть всё что угодно).
Кстати! Давно я не показывал Вам свои деревья! Вот:
Проблем тут довольно много - и неверное освещение некоторых блоков листьев, и неверная прорисовка “прозрачных пикселей”.
Параллельно я начал работу над системой waypoint’ов или, говоря простым языком, алгоритмом поиска путей. Путь был нужен, чтобы была возможность добавить зомби и прочих персонажей и при этом не пришлось бы каждый раз просчитывать их поведение на несколько шагов вперёд (чтобы они не тупили на месте). Для себя я стал отмечать пути визуально, чтобы оценить качество алгоритма:
Более продвинутый вариант визуализации смотрелся вот так:
В какой-то момент, когда я пытался исправить внешний вид деревьев, получил ещё один “положительный”:
Вот ещё несколько любопытных багов с телефона, которые напрямую связаны с прозрачностью (альфа каналом):
и 
Затем были и ошибки из-за добавления дополнительных текстур (а значит и сменой индексов текстур):
Потом я “поправил” что-то в алгоритме прорисовки и получил довольно странный эффект (скорее всего напутал с размером и положением текстур):
В результате последних оптимизаций алгоритма прорисовки, я получил сразу две ошибки (снова разнокалиберные полосатики):
и 
Процесс прорисовки этого чуда смотрится так (очевидно, что это самый оптимальный вариант):
Последней вещью, которую было необходимо реализовать, был эффект обьёма (грани блоков), чтобы картинка не была такой плоской и простой. Для граней необходимо было написать два алгоритма - алгоритм изменения размера картинки и алгоритм наклона изображения.
Начну с алгоритма уменьшения размера картинки:
Сверху вниз - результаты работы алгоритма. В самом низу - желаемый результат (тест проводился на большой картинке, для наглядности).
Больше отличился алгоритм поворота:
Слева наверху - начальное изображение, а справа внизу - желаемый результат, а в середине всё то, что получалось по пути к результату.
Когда алгоритмы были готовы, сделать объём уже было довольно просто. Блок составляли 3 грани (взгляд с одной стороны, псевдо-3д или так называемый 2.5d). Для красоты на грани был нанесён линейный градиент, который тоже пришлось отладить, чтобы получить желаемый результат:
Поскольку с размером граней блока я так и не смог определиться, сделал возможность изменять этот параметр:
После всех изменений, было необходимо оптимизировать процесс прорисовки, чтобы не отрисовывать ничего из того, что не нужно рисовать. Результатом этой оптимизации снова стала проблема с каналом прозрачности, которая всплыла во время тестов на телефоне. Должен признать, что полученный результат смотрелся довольно любопытно:
и 
Результатом исправления этой ошибки стал не столь интересный эффект:
Итоги
В конце концов все критические ошибки были отлажены, добавил текстур и плюшек в виде эффектов. Были сделаны две версии для стора - бесплатная (очень упрощённая) и платная (со всеми плюшками).Техническую сторону решил даже не поднимать в этой статье, т.к. и так не уверен, что кто-то дочитает её до конца. Если людям, которые осилили эту статью, будет интересно узнать о технической стороне этой истории, то напишите в комментариях или в личку, и я обязательно расскажу про сложности с которыми столкнулся, особенностями реализации и прочими деталями.
Надеюсь, что это подтолкнёт ещё кого-то на создание чего-либо своими руками, а не только используя готовые фреймворки и библиотеки.
Спасибо тем, кто хоть долистал до конца статьи!