Дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET

 
















"Дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET"

тривимірний графічний додаток dotnet



Анотація


Метою дипломної роботи є дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET. Як мова програмування для реалізації поставленого завдання була вибрана мова програмування С#, як середа розробки -Microsoft Visual Studio 2008.


Аннотация


Целью дипломной работы является исследование технологий создания трехмерных графических приложений на базе платформы dotNET. Как язык программирования для реализации поставленной задачи был выбран язык программирования C #, как среда разработки - Microsoft Visual Studio 2008.

Разделов 6, схем и рисунков 30, таблиц 5, библиографических ссылок 27, общий объем - 113.


The summary

purpose of degree work is research technologies create three-dimensional image on a platform dotNET. As a programming language for implementation of the task was chosen programming language C #, as the development environment Microsoft Visual Studio 2008.

Sections 6, circuits and figures 30, tables 5, bibliographic references 27, total amount - 113.



Вступ

- це набір API функцій, розроблених для вирішення завдань, пов'язаних з ігровим і відеопрограмуванням в операційній системі Microsoft Windows. Найширше використовується при написанні комп'ютерних ігор. Пакет засобів розробки DirectX під Microsoft Windows безкоштовно доступний на сайті Microsoft. На даний момент найновішою версією є DirectX 11. Часто, свіжі версії DirectX поставляються разом з ігровими додатками, оскільки DirectX API оновлюється достатньо часто, і версія, включена в ОС Windows часто є далеко не самою новою.DirectX - це підтримка DirectX з керованого коду, тобто з програм, написаних на платформі dotNET і для неї. Спочатку ця технологія називалася DirectX dotNET, але пізніше була перейменована в Managed DirectX.

Бібліотека Managed DirectX розділена на наступні простори імен:.DIRECTX.DIRECT3D - інтерфейси для реалізації 3D-графіки;.DIRECTX.DIRECTDRAW - старі, але дуже добрі функції для роботи з 2D-поверхнями і відповідною графікою;.DIRECTX.DIRECTSOUND - інтерфейси для роботи із звуком;.DIRECTX.DIRECTINPUT - інтерфейси для роботи з пристроями введення.

Це основні простори, крім того, в managed DirectX є інтерфейси для реалізації засобів безпеки і підтримка мережі.

Всі ці інтерфейси можна використовувати в наступних мовах програмування:

·MICROSOFT VISUAL C#;

·MICROSOFT VISUAL BASIC .NET;

·MICROSOFT VISUAL C++;

·MICROSOFT JSCRIPT .NET.DirectX планувався для використання в Інтернеті для створення сервісів з підтримкою 3D-графіки тих, що розробляються на таких мовах, як C# і VB.NET.

Технологія Managed DirectX - могутній засіб створення ігор. Уяви собі гру, написану C# у поєднанні з Managed DirectX. За заявами MS, програми .NET можуть виконуватися на будь-якій платформі за наявності відповідного .NET Framework, отже, ми одержуємо міжплатформену гру.

Щоб проілюструвати досліджені в теоретичній частині дипломної роботи технології нами був розроблений додаток, який реалізує практично весь спектр можливостей дослідженої нами технології.



1. Постановка завдання


.1 Найменування та галузь застосування


Розроблений програмний продукт є наочною ілюстрацією дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET.


1.2 Підстава для створення


Підставою для розробки є наказ № 62С-01 від 29 жовтня 2008 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 31.10.08. Закінчення робіт: 01.06.09.


1.3 Характеристика розробленого програмного забезпечення


Як мова програмування для реалізації поставленого завдання була обрана мова програмування С#, як середа розробки - Microsoft Visual Studio 2008. До складу системи входять:

-BookWriter3D.exe - виконавчий файл системи;

-3DTools.dll - бібліотеку взаемодії з DirectX


1.4 Мета й призначення


Метою роботи є створення системи, яка дозволяє наочно проілюструвати основні принципи створення тривимірних графічних додатків на базі платформи dotNET. Також в роботі було розглянуто теоретичні аспекти використання інструментів проектування тривимірних графічних одатків.

1.5 Загальні вимоги до розробки


Вимоги до програмного забезпечення:

·Робота в середовищі операційних систем Windows 2000/XP;

·Простота й зрозумілість інтерфейсу.

Мінімальні вимоги до апаратного забезпечення:

·IBM-сумісний комп'ютер, не нижче Pentium IІI, RAM-256Mb, SVGA-800*600*16bit;

·Вільний простір на жорсткому диску не менш 800 Мб;

·Додаткове програмне забезпечення: інсталяція DirectX


1.6 Джерела розробки


Джерелами розробки дипломної роботи є:

·довідкова література;

·наукова література;

·технічна література;

·програмна документація.



2. Особливості технологій розробки Windows додатків


2.1 Огляд основних технологій розробки Windows додатків


2.1.1 Програмування з використанням Win32/C

Спочатку під програмуванням під Windows малося на увазі програмування з використанням Windows Application Programming Interface (інтерфейсом прикладного програмування Windows, в 32-разрядних версіях Windows - Win32 API). З використанням цієї технології було створено безліч цілком гідних додатків, проте навряд чи хто-небудь сперечатиметься з тим, що написання додатка з використанням лише Windows API - це дуже трудомістке завдання.

Ще одна проблема полягає в тому, що С - досить сувора по відношенню до програміста мова. Тим, хто створює додатки цією мовою програмування, доводиться уручну займатися управлінням пам'яттю, виконати розрахунки при використанні покажчиків і працювати з абсолютно неприродними з точки зору людської мови синтаксичними конструкціями. Крім того, в С недостатньо можливостей для об'єктно-орієнтованого програмування.


2.1.2 Програмування з використанням C++/MFC

C++ - це величезний крок вперед відносно нових можливостей в порівнянні з початковою мовою С. В багатьох ситуаціях C++ цілком допустимо представити як об'єктно-орієнтовану надбудову над С. Така надбудова дозволяє використовувати переваги «стовпів об'єктно-орієнтованого програмування - інкапсуляції, поліморфізму і спадкоємства. Проте програмісти, використовуючи C++, залишаються незахищеними від багатьох і часто небезпечних особливостей С++ (тими ж самими низькорівневими можливостями роботи з пам'яттю і важкими для сприйняття синтаксичними конструкціями).

Існує безліч бібліотек для C++, основне призначення яких - полегшити написання додатків під Windows, надавши для цієї мети вже готові класи. Одна з найбільш поширених бібліотек - це MFC (Microsoft Foundation Classes). MFC - це додатковий рівень над Win32 API, який значно спрощує роботу програміста за рахунок використання готових класів, макросів і майстрів. Проте MFC - це лише часткове вирішення проблеми. Навіть при використанні MFC програмістові доводиться працювати з складним для читання кодом, вельми небезпечним з точки зору можливих помилок.


2.1.3 Програмування з використанням Visual Basic

Люди завжди прагнуть зробити своє життя простішим. Підкоряючись цьому прагненню багато програмістів на C++ обернули свої погляди до набагато простішої і доброзичливішої мови, якою є Visual Basic (VB). Visual Basic дозволяє працювати з досить складними елементами інтерфейсу користувача, бібліотеками коду (наприклад, Сом-серверами) і засобами доступу до даних при мінімальних витратах часу і сил. Visual Basic в набагато більшому ступені, чим MFC, ховає від користувача виклики Win32 API і надає великий набір інтегрованих засобів швидкої розробки.

Проте в Visual Basic є і недоліки. Головний з них - це набагато менші можливості, які надає ця мова, в порівнянні з C++ (це твердження справедливе, принаймні, для версій раніших, ніж VB.NET). Visual Basic - це мова «для роботи з об'єктами», а не об'єктно-орієнтована мова в звичайному розумінні цього слова. У Visual Basic немає класичного спадкоємства, немає підтримки створення класів, що параметризуються, немає власних засобів створення багатопоточних додатків - і цей список можна продовжувати ще довго.


2.1.4 Програмування з використанням Java

Мова програмування Java - це повністю об'єктно-орієнтована мова, яка відносно синтаксису багато що успадкувала від C++ . Звичайно, переваги Java далеко не вичерпуються міжплатформеностю. Мова Java в синтаксичному відношенні простіша і логічніша, ніж C++. Java як платформа надає в розпорядження програмістів велику кількість бібліотек (пакетів), в яких міститься велика кількість описів класів і інтерфейсів на всі випадки життя. З їх допомогою можна створювати стовідсоткові додатки Java з можливістю звернення до баз даних, підтримкою передачі поштових повідомлень, з клієнтською частиною, якою необхідний лише web-браузер, або на зворот, з клієнтською частиною, що володіє витонченим інтерфейсом.- це дуже елегантна і красива мова. Проте при його використанні проблем також уникнути не вдається. Одна з серйозних проблем полягає в тому, що при створенні складного додатку на Java нам доведеться використовувати лише цю мову для створення всіх частин цього додатку. У Java передбачено не так вже багато засобів для міжмовної взаємодії (що зрозуміло, зважаючи на призначення Java бути єдиною багатоцільовою мовою програмування). Але в реальному світі існують мільйони рядків готового коду, які хотілося б інтегрувати з новими додатками на Java. Проте це зробити дуже важко.- це далеко не ідеальна мова в багатьох ситуаціях. Простий приклад - якщо ми спробуємо створити лише Java додаток, що активно працює з 3d-графікой, швидше за все, працювати такий додаток буде не дуже швидко. Для роботи з 3d-графікой краще використовувати код, написаний на мові з розвиненішими низькорівневими можливостями (наприклад, на C++). Проте інтегрувати такий код з кодом на Java буде дуже складно. Оскільки можливості для звернення до API компонентів, створених на інших мовах, в Java дуже обмежені, говорити про реальну міжмовну взаємодію на основі Java не доводиться.

2.1.5 Програмування з використанням СОМ

Сучасний стан справ такий, що якщо програміст не будуєте Java-додатки, то велика вірогідність, що програміст освоює технологію Microsoft Component Object Model (COM). Сом-технологія проголошує: «Якщо ви створюєте класи в точній відповідності з вимогами СОМ, то у вас вийде блок повторно використовуваного програмного коду».

Краса двійкового Сом-сервера полягає в тому, що до нього можна звертатися з будь-якої мови. Наприклад, програмісти, використовуючи C++, можуть створювати класи, які можна буде використовувати з додатка на Vbasic. Програмісти, використовуючи Delphi, можуть використовувати класи, створені на С++ и т.д. Проте в міжмовній взаємодії СОМ є свої обмеження. Наприклад, немає можливості провести нового типа СОМ від того, що існує. Для повторного використання існуючих типів СОМ доведеться використовувати інші, набагато менш надійні і ефективні засоби.

Велика перевага СОМ полягає в тому, що програміст може не піклуватися про фізичне місцезнаходження компонентів. Такі засоби, як Application Identifiers (Appids, ідентифікатори додатків), стаби (stubs), проксі, середа виконання СОМ, дозволяють уникати при зверненні до компонентів по мережі необхідності поміщати в додаток код для роботи з сокетами, викликами RPC і іншими низькорівневими механізмами. Досить поглянути на такий код на Visual Basic 6.0 для клієнта СОМ:с as New MyCOMClass. Місцезнаходження класу визначається через AppID c.DoSomeWork.

Об'єктна модель СОМ використовується дуже широко. Проте внутрішній устрій компонентів вельми складний. Щоб навчитися знатися на нім доведеться витратити принаймні декілька місяців. Написання додатків з використанням Сом-компонентів можна спростити, використовуючи стандартні бібліотеки, наприклад біблітеку Active Template Library (ATL) зі своїм набором готових класів, шаблонів і макросів.

Деякі мови (наприклад, Visual Basic) також дозволяють приховати складність інфраструктури СОМ. Проте всіх складнощів уникнути все одно не вдається. Наприклад, навіть якщо працювати з відносно простим і підтримуючим COM Visual Basic, доведеться вирішувати не завжди прості питання, пов'язані з реєстрацією компонентів на комп'ютері і розгортанням додатків.


2.1.6 Програмування з використанням Windows DNA

Картина буде неповною, якщо не взяти до уваги як Інтернет. За декілька останніх років Microsoft додала в свої операційні системи велику кількість засобів для роботи з цією середою, у тому числі і засоби, покликані допомогти в створенні Інтернет-додатків. Проте, побудова закінченого web-додатки з використанням технології Windows DNA (Distributed internet Architecture - розподілена міжмережева архітектура) до цих пір залишається вельми складним завданням.

Значна частина складнощів виникає тому, що Windows DNA вимагає використання різнорідних технологій і мов (ASP, HTML, XML, Javascript, Vbscript, COM ( ), ADO і т. д.). Одна з проблем полягає в тому, що синтаксично всі ці мови і технології дуже мало схожі один на одного. Наприклад, синтаксис JavaScript більше схожий на синтаксис С++, тоді як VbScript є підмножиною Visual Basic. Сом-сервери, призначені для роботи в середі виконання СОМ, створені на основі здійснений інших підходів, ніж Asp-сторінки, які до них звертаються. Кінцевим результатом є лякаюче змішення технологій. Окрім всього іншого, в кожній мові, яка входить до складу Windows DNА, передбачена своя система типів, що також не є джерелом великої радості для програмістів. Наприклад, тип даних іnt у JavaScript - це не те ж саме, що іnt у С++, який, у свою чергу, відмінний від іnteger у Visual Basic.


2.2 Рішення .NET


Один з головних принципів .NET звучить так: «Змінюйте все, що хочете, звідки вам завгодно». .NET - це абсолютно нова модель для створення додатків під Windows (а в майбутньому, мабуть, і під іншими операційними системами). Ось коротке перерахування основних можливостей .NET:

·Повні можливості взаємодії з існуючим кодом.

·Повна і абсолютна міжмовна взаємодія. На відміну від класичного СОМ, в .NET підтримуються міжмовне спадкоємство, міжмовна обробка виключень і міжмовна відладка.

·Спільна середа виконання для будь-яких додатків .NET, незалежно від того, на яких мовах вони були створені. Один з важливих моментів при цьому - те, що для всіх мов використовується один і той же набір вбудованих типів даних.

·Бібліотека базових класів, яка забезпечує приховування всіх складнощів, пов'язаних з безпосереднім використанням викликів API, і пропонує цілісну об'єктну модель для всіх мов програмування, що підтримують .NET,

·Спрощення процесу розгортання додатка. У .NET немає необхідності реєструвати подвійні типи в системному реєстрі. Більш того .NET дозволяє різним версіям одного і того ж модуля DLL мирно співіснувати на одному комп'ютері.


2.2.1 Основи CLS

CLS (Common Language Specification) - загальна специфікація мов програмування. Це набір конструкцій і обмежень, які є керівництвом для творців бібліотек і компіляторів в середовищі .NET Framework. Бібліотеки, побудовані відповідно до CLS, можуть бути використані з будь-якої мови програмування, підтримуючого CLS. Мови, відповідні CLS (до їх числа відносяться мови Visual C# 2.0, Visual Basic, Visual C++), можуть інтегруватися один з одним. CLS - це основа міжмовної взаємодії в рамках платформи Microsoft .NET.

Немає необхідності доводити, що одні і ті ж програмні конструкції в різних мовах виглядають абсолютно по-різному. Наприклад, в С# і Delphi об'єднання рядків (конкатенація) проводиться за допомогою оператора плюс "+", а в Visual Basic для цієї мети використовується амперсант "&". Для середовища виконання .NET така різниця в синтаксисі абсолютно байдужа: все одно відповідні компілятори створять однаковий код IL. Проте мови програмування відрізняються не тільки синтаксисом, але і можливостями. Наприклад, в одних мовах програмування дозволено перевантаження операторів, а в інших - ні. Одні мови можуть використовувати беззнакові типи даних, в інших такі типи даних не передбачені. Тому потрібні деякі єдині правила для всіх мов .NET. Якщо їм слідувати, то програмні модулі, написані на різних мовах, нормально взаємодіятимуть один з одним. Такий набір правил визначений в універсальній специфікації мови (CLS).

Набір правив CLS не тільки гарантує нормальну взаємодію блоків коду, створених на різних мовах, але і визначає мінімальні вимоги, які пред'являються до будь-якого компілятора .NET. Необхідно пам'ятати, що CLS - це лише частина тих можливостей, які визначені в CTS. Правилам CLS повинні задовольняти і інструментальні засоби середовища розробки - якщо ми хочемо забезпечити міжмовну взаємодію, вони повинні генерувати тільки такий код, який відповідає вимогам CLS. У кожного правила CLS є назва (наприклад, CLS Rule 6). Ось приклад один з найважливіших правил - правило номер 1.

Правило 1. Правила CLS відносяться тільки до частин типу, призначених для взаємодії за межами збірки, в якій вони визначені.

З цього правила виходить, що при реалізації якого-небудь типу можна скільки завгодно порушувати правила CLS - це ні на що не вплине. Наприклад, можна створити додаток .NET, який взаємодіє із зовнішнім світом за допомогою трьох класів, і в кожному з цих класів тільки одна функція. Правилам CLS в цьому випадку повинні задовольняти тільки три цих функції (область видимості, угоди про іменування, типи параметрів і т.д.). У внутрішній реалізації цих функцій, класів або додатку в цілому може бути скільки завгодно відступів від правил CLS.


2.2.2 Основи CLR(Common Language Runtime) - Середовище Часу Виконання або Віртуальна Машина. Забезпечує виконання збірки. Основний компонент .NET Framework. Під Віртуальною Машиною розуміють абстракцію інкапсульованої (відособленої) керованої операційної системи високого рівня, яка забезпечує виконання (керованого) програмного коду.

Керований код - програмний код, який при своєму виконанні здатний використовувати служби, що надаються CLR.

Відповідно, некерований код подібною здатністю не володіє. Про особливості керованого коду можна судити по переліку завдань, рішення яких покладається на CLR:

·Управління кодом (завантаження і виконання).

·Управління пам'яттю при розміщенні об'єктів.

·Ізоляція пам'яті додатків.

·Перевірка безпеки коду.

·Перетворення проміжної мови в машинний код.

·Доступ до метаданих (розширена інформація про типи).

·Обробка виключень, включаючи міжмовні виключення.

·Взаємодія між керованим і некерованим кодами (у тому числі і COM-об'єктами).

·Підтримка сервісів для розробки (профілізація, відладка і т.д.).

Коротше, CLR - це набір служб, необхідних для виконання керованого коду

Сама CLR складається з двох головних компонентів: ядра (mscoree.dll) і бібліотеки базових класів (mscorlib.dll). Наявність цих файлів на диску - вірна ознака того, що на комп'ютері, принаймні, була зроблена спроба установки платформи .NET.

Ядро середовища виконання реалізоване у вигляді бібліотеки mscoree.dll. При компоновці збірки в неї вбудовується спеціальна інформація, яка при запуску додатку (EXE) або при завантаженні бібліотеки (звернення до DLL з некерованого модуля - виклик функції LoadLibrary для завантаження керованої збірки) приводить до завантаження і ініціалізації CLR. Після завантаження CLR в адресний простір процесу, ядро середовища виконання проводить наступні дії:

·знаходить розташування збірки;

·завантажує збірку в пам'ять;

·проводить аналіз вмісту збірки (виявляє класи, структури, інтерфейси);

·проводить аналіз метаданих;

·забезпечує компіляцію коду на проміжній мові (IL) в платформозалежні інструкції (асемблерний код);

·виконує перевірки, пов'язані із забезпеченням безпеки;

·використовуючи основний потік додатку, передає управління перетвореному в команди процесора фрагменту коду збірки.

·FCL (.NET Framework Class Library) - відповідна CLS-специфікації об'єктно-орієнтована бібліотека класів,

·інтерфейсів і системи типів (типів-значень), які включаються до складу платформи Microsoft .NET.

Ця бібліотека забезпечує доступ до функціональних можливостей системи і призначена служити основою при розробці .NET- додатків, компонент, елементів управління.бібліотека класів є другим компонентом CLR.FCL можуть використовувати ВСЕ .NET-приложения, незалежно від призначення архітектури використовуваного при розробці мови програмування, і зокрема:

·вбудовані (елементарні) типи, представлені у вигляді класів (на платформі .NET все побудовано на структурах або класах);

·класи для розробки графічного призначеного для користувача інтерфейсу (Windows Form);

·класи для розробки web-додатків і web-служб на основі технології ASP.NET (Web Forms);

·класи для розробки XML і Internet-протоколів (FTP, HTTP, SMTP, SOAP);

·класи для розробки додатків, що працюють з базами даних (ADO .NET) і багато що інше.


Рис.2.1 Послідовність виконання програм в середовищі CRL


.2.3 Стандартна система типів CTS

Стандартна система типів (CTS) - це всеосяжна специфікація, яка визначає, яким чином який-небудь тип (клас, структура, інтерфейс, вбудований тип даних і т.д.) повинен бути сформований для його правильного сприйняття середовищем виконання .NET. Система CTS описує синтаксичні конструкції (наприклад, перевантаження операторів), які можуть підтримуватися, а можуть і не підтримуватися конкретною мовою програмування .NET. Якщо необхідно створювати сбірки, які повинні використовуватися всіма мовами програмування .NET, то при створенні типів доведеться слідувати правилам стандартної системи типів.

Концепція класів - наріжний камінь будь-якого об'єктно-орієнтованого програмування. Вона підтримується всіма мовами програмування .NET. Клас - це необмежений набір полий, властивостей, методів і подій, складових єдине ціле. У CTS передбачені абстрактні члени класів, що забезпечує можливість застосування поліморфізму в похідних класах. Множинне спадкоємство в CTS заборонене. Клас відповідає всім вимогам об'єктно-орієнтованого програмування і може бути абстрактним, мати область видимості, використовувати інтерфейси, а також може бути закритим для створення похідних класів.

Крім класів в CTS також представлені і структури. У першому наближенні структури можна розглядати як спрощені різновиди класів. Структури CTS можуть мати будь-яку кількість конструкторів з параметрами (конструктор без параметрів зарезервований). За допомогою конструкторів з параметрами можна встановити значення будь-якого поля структури у момент створення цього об'єкту. Всі структури CTS проведені від єдиного базового класу System.ValueType.

Цей базовий клас визначає структуру як тип даних для роботи тільки із значеннями, але не з посиланнями. У структурі може бути будь-яка кількість інтерфейсів.

Проте структури не можуть бути успадковані від решти типів даних і вони завжди є закритими - іншими словами, вони не можуть виступати як базові з метою їх спадкоємства.

Члени типів CTS

Раніше було відмічено, що класи і структури можуть мати будь-яку кількість членів. Член - це або метод, або властивість, або поле, або подія. Для кожного члена в .NET існує набір характеристик. Наприклад, будь-який член в .NET характеризується своєю областю видимості (public, private, protected і т.д.). Член можна оголосити як абстрактний, щоб скористатися можливостями поліморфізму при роботі з похідними класами. Члени можуть бути статичними (такі члени можуть спільно використовуватися всіма об'єктами даного класу) і звичайними - що належать тільки одному об'єкту даного класу.

Перерахування CTS

Перерахування - це зручна програмна конструкція, яка дозволяє об'єднувати пари "ім'я-значення" в групи, до яких потім можна звернутися на ім'я груп.

У CTS всі перерахування є похідними від єдиного базового класу System.Enum. Цей базовий клас містить безліч корисних членів, які допоможуть в роботі з парами "ім'я-значення".

Делегати CTS

Делегати в світі .NET - це безпечні для типів вказівники на функції. Але на відміну від інших мов програмування, делегат .NET це вже не просто адреса в оперативній пам'яті, а клас, похідний від базового класу Multicast-Delegate. Делегати дуже корисні в тих ситуаціях, коли потрібно, щоб одна суть передала виклик іншої суті. Делегати - це наріжний камінь в технології обробки подій в середовищі.NET.

Вбудовані типи даних CTS

У середовищі .NET передбачений багатий набір вбудованих типів даних, причому цей набір використовується всіма мовами програмування .NET. Назви типів даних в різних мовах .NET можуть виглядати по-різному, але ці назви всього лише псевдоніми для вбудованих системних типів даних .NET, визначених в бібліотеці базових типів.


2.2.4 Простори імен

Після знайомства із загальниймовним виконуючим середовищем .NET звернемося до особливостей бібліотеки базових класів .NET. Важливість бібліотек коду очевидна.

Наприклад, бібліотека MFC визначає набір класів C++ для створення форм, діалогових вікон, меню, панелей управління і т.д. В результаті програмісти можуть не займатися створенням того, що вже давно зроблене, а зосередитися на унікальних аспектах застосування, що розробляється ними. Аналогічні засоби існують в Delphi, Visual Basic, Java і в решті всіх мов програмування.

Проте на відміну від цих мов програмування, в мовах для середовища .NET не існує бібліотеки базових класів тільки для однієї мови. Натомість розробники використовують бібліотеку базових типів для всього середовища .NET, а для організації типів усередині цієї бібліотеки використовується концепція просторів імен.

Ефективність роботи програміста, що використовує .NET, безпосередньо залежить від того, наскільки добре він знайомий з тим безліччю типів, які визначені в просторах імен бібліотеки базових класів. Найважливіший простір імен називається System. У нім визначені класи, які забезпечують найважливіші функції, і жодне застосування не обходиться без використання цього простору імен.

Простір імен - це спосіб організації типів (класів, перерахувань, інтерфейсів, делегатів і структур) в єдину групу. У одному просторі імен зазвичай об'єднуються взаємозв'язані типи. Наприклад, в просторі імен System.Drawing міститься набір типів, які покликані допомогти в організації виведення зображень на графічний пристрій. У .NET передбачені простори імен для організації типів, розрахованих на роботу з базами даних, мережею, багатопотоковістю, захистом даних і безлічі інших завдань.


2.2.5 Основи MSIL

(Microsoft Intermediate Language) - проміжна мова платформи Microsoft .NET. Початкові тексти програм для .NET-приложений пишуться на мовах програмування, відповідних специфікації CLS. Для таких мов може бути побудований перетворювач в MSIL. Таким чином, програми на цих мовах можуть транслюватися в проміжний код на MSIL.

Завдяки відповідності CLS, в результаті трансляції програмного коду, написаного на різних мовах, виходить сумісний IL-код.

Фактично MSIL є асемблером віртуального процесора.

МЕТАДАНІ - при перетворенні програмного коду в MSIL також формується блок метаданих, який містить інформацію про даних, використовуваних в програмі. Фактично це набори таблиць, які включають інформацію про типи даних, визначуваних в модулі (про типи даних, на які посилається даний модуль). Раніше така інформація зберігалася окремо. Наприклад, додаток міг включати інформацію про інтерфейси, яка описувалася на Interface Definition Language (IDL). Тепер метадані є частиною керованого модуля.

Зокрема, метадані використовуються для:

·збереження інформації про типи. При компіляції тепер не потрібні заголовні і бібліотечні файли. Всю необхідну інформацію компілятор читає безпосередньо з керованих модулів;

·верифікації коду в процесі виконання модуля;

·управління динамічною пам'яттю (звільнення пам'яті) в процесі виконання модуля;

·забезпечення динамічної підказки (IntelliSence) при розробці програми стандартними інструментальними засобами (Microsoft Visual Studio .NET) на основі метаданих.

Мови, для яких реалізований переклад на MSIL:

·Visual Basic,

·Visual C++,

·Visual C# 2.0,

·і ще багато інших мов.


2.2.6 Поняття збірки і виконувані модулі

Виконуваний модуль - незалежно від компілятора (і вхідної мови) результатом трансляції .NET-додатку є керований виконуваний модуль (керований модуль). Це стандартний переносимий виконуваний (PE - Portable Executable) файл Windows.

Однією з особливостей керованого коду є наявність механізмів, які дозволяють працювати з керованими даними. Керовані дані - об'єкти, які в ході виконання коду модуля розміщуються в керованій пам'яті (у керованій купі) і знищуються складальником сміття CLR. Дані C#, Visual Basic і JScript .NET є керованими за замовчанням. Виконуваний модуль - незалежно від компілятора (і вхідної мови) результатом трансляції .NET-додатку є керований виконуваний модуль (керований модуль). Це стандартний переносимий виконуваний (PE - Portable Executable) файл Windows. Однією з особливостей керованого коду є наявність механізмів, які дозволяють працювати з керованими даними.

Керовані дані - об'єкти, які в ході виконання коду модуля розміщуються в керованій пам'яті (у керованій купі) і знищуються прибиральником сміття CLR. Дані C#, Visual Basic і JScript .NET є керованими за замовчанням.

Дані C# також можуть бути помічені як некеровані.

Збірка (Assembly) - базовий будівельний блок додатку в .NET Framework. Керовані модулі об'єднуються в складки. Збірка є логічним угрупуванням одного або декількох керованих модулів або файлів ресурсів. Керовані модулі у складі складок виконуються в Середовищі Часу Виконання (CLR). Збірка може бути або виконуваним застосуванням (при цьому вона розміщується у файлі з розширенням .exe), або бібліотечним модулем (у файлі з розширенням .dll). При цьому нічого спільного із звичайними (старого зразка!) виконуваними застосуваннями і бібліотечними модулями збірка не має.

Декларація збірки (Manifest) - складова частина збірки. Це ще один набір таблиць метаданих, який:

ідентифікує збірку у вигляді текстового імені, її версію, культуру і цифрову сигнатуру (якщо збірка розподіляється серед додатків);

визначає вхідні в склад файли (по імені і хешу);

указує типи і ресурси, що існують в збірці, включаючи опис тих, які експортуються із збірки;

перераховує залежності від інших складок;

указує набір має рацію, необхідних збірці для коректної роботи.

Ця інформація використовується в період виконання для підтримки коректної роботи додатку.


3. Теоретичне дослідження роботи з графікою засобами Direct3D


3.1 Огляд бібліотеки DirectX 9.0


Створення складних і високопродуктивних мультимедійних програм вимагає безпосереднього доступу до апаратних ресурсів. Бібліотека DirectX містить набір низькорівневих програмних інтерфейсів, надаючий такий доступ Windows-програмістам. Якщо ви збираєтеся створити захоплюючу мережеву гру, мультимедійний додаток або хранитель екрану з використанням тривимірної графіки - безумовно, варто почати з розгляду можливостей DirectX.

За час свого існування бібліотека DirectX зазнала великі зміни. Ми розглядатимемо можливості найсучаснішої (на момент написання цієї книги) версії API DirectX версії 9.0. Крім різних технологічних нововведень, що відображають появу нових пристроїв, в цій бібліотеці вперше представлений managed-інтерфейс, що дозволяє легко використовувати DirectX в програмах для платформи .NET Framework.9.0 складається з наступних компонентів:

. DirectX Graphics: поєднує в собі можливості інтерфейсів DirectDraw і Direct3D попередніх версій, призначених для програмування графіки. Ми вивчатимемо можливості саме цього компоненту.

. DirectInput: надає можливості по обробці призначеного для користувача введення з найрізноманітніших пристроїв таких, як ігрові маніпулятори і "миші".

. DirectPlay: містить засоби для створення мережевих додатків (наприклад, розрахованих на багато користувачів ігор).

. DirectSound, DirectMusic і DirectX Media Objects (ці компоненти у версії 9.0 об'єднані під назвою DirectX Audio): надають засоби програмування звуку і MIDI-музики.

. DirectShow: засоби для захоплення і відтворення мультимедійних потоків. У версії 9.0 вперше з'явилися DirectShow Editing Services (DES): набір об'єктів, що дозволяють легко створювати програми для нелінійного монтажу або програвачів аудіо і відео із застосуванням real-time ефектів і красивих переходів між роликами.

. DirectSetup: програмний інтерфейс, що дозволяє настроювати установку DirectX на системах користувачів.

. DirectX Diagnostics: програмний інтерфейс для діагностики драйверів і устаткування.

Як бачимо, DirectX надає засоби для створення найрізноманітніших графічних і мультимедійних додатків, а також включає додаткові програмні інтерфейси (на відміну від свого основного конкурента, бібліотеки OpenGL, орієнтованої виключно на графіку).


3.2 Пакет DirectX 9.0 SDK


Для успішного запуску космічної «стрелялки», що використовує можливості Direct3D, цілком досить встановити пакет DirectX Runtime, який містить набір динамічних бібліотек, драйверів пристроїв і конфігураційних файлів. Цей набір файлів займає близько 36 мегабайт у повному складі, і його часто можна знайти на компакт-дисках з драйверами для нових відеокарт або з іграми останнього покоління.

Але для самостійного створення програм з використанням DirectX 9 його абсолютно недостатньо. Для цього необхідний пакет DirectX 9.0 SDK, що знаходиться у вільному доступі на сайті Microsoft.

Ось що входить до складу цього пакету:

·Набір заголовних файлів і бібліотек для компіляторів C++.

·Складки Managed DirectX для використання з .NET-компиляторами.

·Велика кількість документації у форматі Compiled HTML Help.

·Набір прикладів і покрокових інструкцій, організованих в цілу оболонку Sample Browser по категоріях і мовах розробки (див. рис 3.1).


Рис 3.1 Оболонка для доступу до прикладів і покрокового керівництва DirectX


"Майстри" (AppWizard) для створення стартових додатків в середовищах Visual С++, Visual C# і Visual Basic.NET.

Допоміжні утиліти для редагування файлів DirectX, проглядання системних параметрів і спостереження за системою.

Власне середовище виконання - пакет DirectX Runtime в двох версіях: налагоджувальної (Debug) і остаточної (Retail). Налагоджувальна версія дещо повільніше, але містить додаткові перевірки, що дозволяють відловлювати помилки на етапі розробки. Між двома цими версіями можна легко перемикатися.

Запустивши инсталлятор DirectX, можна вибрати, які компоненти пакету потрібно встановити на комп'ютер (рис 3.2). Рекомендується вибрати повну інсталяцію.

Рис 3.2 Установка DirectX 9 SDK


3.3 Створення програм з використанням DirectX Graphics


Почнемо з написання двох програм: для Windows і середовищ .NET. Виконавши покрокові описи, ми в результаті одержимо повноцінні програми, що використовують компонент DirectX Graphics для створення тривимірного зображення


3.3.1 Написання програм мовою C++

На жаль, майстер AppWizard, що поставляються у складі пакету DirectX 9.0 SDK, призначені тільки для використання в середовищах Visual Studio 6.0 і 7.0. Тому ми приводимо інструкцію, що дозволяє підключити DirectX SDK до пакету Microsoft Visual Studio .NET 2003 (7.1).

Отже, запустіть середовище Visual Studio і створіть новий проект Win32 Project (рис 3.3). Привласніть йому ім'я (у нашому прикладі - DX_Sample1), виберіть опцію Empty Project і підтвердіть створення проекту.



Рис 3.3 Створення нового проекту на C++


Тепер необхідно додати в проект новий файл .cpp. Для цього в меню Project виберіть пункт Add New Item. і знайдіть серед всіляких елементів значок C++ File (.cpp). Файлу також необхідно привласнити ім'я (наприклад, Hello.cpp), після чого можна приступати до «начинки».


3.3.2 Настройка середовища. Заголовні файли і бібліотеки

Перш за все, необхідно переконатися, що середовище Visual Studio правильно настроєне для компіляції програм, що використовують компоненти DirectX 9 SDK. Для цього зайдіть в пункт меню Tools - Options і знайдіть в лівому списку папку Projects. Розкрійте її і виберіть пункт VC++ Directories.

Потрібно переконатися, що в переліку шляхів до заголовних файлів (Include files) присутній рядок з вказівкою відповідного каталога DirectX SDK. Якщо ж такого рядка немає, необхідно додати її самостійно. У нашому прикладі (рис 3.4) це G:\dx9sdk\Include.



Рис 3.4 Настройка шляхів до заголовних файлів і бібліотек DirectX


Так само настроюється шлях до бібліотек DirectX. Для цього необхідно вибрати з випадного списку пункт Library files і додати в перелік рядок з вказівкою каталога Lib. Важливо, щоб шлях до каталогів dx9sdk/include і dx9sdk/lib стояв в списку раніше аналогічних каталогів (наприклад, від Platform SDK). Ну що ж, тепер компілятор знатиме, в якому місці шукати файли заголовків і бібліотек - самий час вказати їх. Додайте у файл Hello.cpp наступні рядки:


#include <d3d9.h>

#include <d3dx9mesh.h>

#pragma comment(lib, "d3d9.lib")

#pragma comment(lib, "d3dx9.lib")


Ці рядки означають, що ми використовуватимемо як бібліотеку Direct3D, так і бібліотеку допоміжних компонентів Direct3D Extension (D3DX), в якій містяться функції, що полегшують програмування графіки.


.3.3 Клас додатку і функція WinMain

Для створення програми застосуємо об'єктно-орієнтований підхід. Створимо клас додатку, в який помістимо функції ініціалізації і очищення DirectX, а також код побудови зображення.

Назвемо цей клас SampleApplication :


class SampleApplication

{

IDirect3D9 *pD3D;DDevice9 *pDevice;DXMesh *pTeapot;hWnd;

static LRESULT WINAPI MsgProc(HWND, UINT, WPARAM, LPARAM);

bool CreateMainWindow();

void CreateTeapot();

public:():D(NULL), pDevice(NULL), pTeapot(NULL), hWnd(NULL){

bool InitD3D();

void CleanupD3D();

void Render();

void MessagePump();

};


Клас зберігає ресурси Direct3D, які йому знадобляться для роботи, і дескриптор головного вікна додатку. Крім того, він надає допоміжні функції ініціалізації, очищення і управління чергою повідомлень Windows.

Звернемо увагу, що метод MsgProc є статичним. Це необхідно для коректної обробки Windows-повідомлень усередині класу. Але усередині статичного методу не можна звертатися до полів класу, оскільки невідомо, до якого саме екземпляру йде звернення. Для вирішення цієї проблеми застосований простий прийом: описаний глобальний екземпляр об'єкту SampleApplication. Всі звернення ззовні проводитимуться до полів цього об'єкту.

При всій простоті цей спосіб страждає істотним недоліком: у програмі може існувати тільки один екземпляр такого класу. Втім, для класу додатку це не дуже істотно. Як буде показано далі .NET-розробники не повинні вдаватися до таких хитрувань для обробки повідомлень.

Отже, додамо оголошення глобального екземпляра додатку і функції WinMain :

SampleApplication g_App;WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

{(g_App.InitD3D())

{_App.MessagePump();_App.CleanupD3D();

}0;

}


Виконання WinMain починається із спроби ініціалізації Direct3D. У разі успіху програма входить в цикл обробки повідомлень, а після його завершення виконує очищення Direct3D.

Це єдина глобальна функція в програмі, вся решта функцій буде методами класу SampleApplication.


3.3.4 Створення вікна

Як буде показано трохи нижче, метод InitD3D спочатку створює головне вікно додатку за допомогою виклику CreateMainWindow. Ось текст цього методу :

bool SampleApplication::CreateMainWindow()

{

// Реєстрація класу вікнаwc = { sizeof(WNDCLASSEX) CS_CLASSDC,, 0L, 0L(NULL), NULL, NULL, NULL

"Direct3D Class", NULL };( &wc );

// Створення вікна додатку= CreateWindow( "Direct3D Class",

"Direct3D для чайників"_OVERLAPPEDWINDOW,

, 100, 400, 300(), NULL.hInstance, 0 );(!hWnd)

{(0, "Помилка створення головного вікна"

MB_OK|MB_ICONSTOP);false;

}true;

}


Як і в звичайному Windows-додатку, спочатку відбувається реєстрація класу вікна, в якій необхідно, зокрема, вказати процедуру обробки повідомлень (ось і став в нагоді статичний метод MsgProc) і ім'я класу (у нашому прикладі - «Direct3D Class»). Потім створюється головне вікно додатку з розмірами 400x300 пикселов. У разі помилки видається діагностичне повідомлення.


.3.5 Обробка повідомлень

Метод MessagePump «прокачує» Windows-повідомлення, що поступають в програму. Крім реакції на необхідні події (наприклад, закриття вікна), це дозволяє брати участь в кооперативній багатозадачності Windows і понизити навантаження на процесор. Початковий код методу приведений в лістингу.

SampleApplication::MessagePump()

{msg;(GetMessage(&msg, 0, 0, 0))

{(&msg);(&msg);

}

}


Метод MsgProc нашого простого додатку обробляє тільки два повідомлення: WM_DESTROY (посилане вікну при його закритті) і WM_PAINT (що сигналізує про необхідність перемальовування).

WINAPI SampleApplication::MsgProc(hWnd, UINT msg, WPARAM wParam, LPARAM lParam)

{_App.hWnd = hWnd;( msg )

{WM_DESTROY:( 0 );0;WM_PAINT:

{ps;(hWnd &ps);_App.Render();(hWnd &ps);0;

}

}DefWindowProc(g_App.hWnd, msg, wParam, lParam);

}


До стандартної обробки повідомлення WM_PAINT ми додали тільки виклик методу Render для побудови тривимірного зображення.

Але, перш ніж використовувати бібліотеку Direct3D, необхідно її ініціалізувати. Розглянемо відповідні методи класу SampleApplication.


3.3.6 Ініціалізація і очищення бібліотеки

Код методу InitD3D спочатку створює головне вікно додатку викликом CreateMainWindow. У разі успіху програма приступає до ініціалізації бібліотеки DirectX.

Спершу намагаємося створити об'єкт Direct3D - стартову крапку для зручної ініціалізації компонентів Direct3D. Для цього викличемо функцію Direct3DCreate9 з константою D3D_SDK_VERSION як параметр. Якщо цей виклик завершиться невдачею, на комп'ютері відсутня підтримка DirectX потрібної нам версії, і далі продовжувати безглуздо.

Якщо ж функція повернула створений об'єкт Direct3D, то використовуємо його для створення і ініціалізації графічного пристрою, викликавши у нього метод CreateDevice з необхідними параметрами (ми повернемося до розгляду ініціалізації нижче).

Крім того, нам потрібен об'єкт, що відображається. Для прикладу використовуємо функцію D3DXCreateTeapot бібліотеки D3DX, яка дозволяє створити готовий тривимірний об'єкт, що моделює чайник. Відповідний символ для початку вивчення тривимірної графіки, чи не так? :)

І, нарешті, після успішної ініціалізації об'єктів DirectX, показуємо головне вікно. Тепер додаток зможе коректно перемальовувати його вміст, використовуючи Direct3D.

Текст функції ініціалізації приведений в лістингу:


bool SampleApplication::InitD3D()

{(!CreateMainWindow())

return false;D = Direct3DCreate9(D3D_SDK_VERSION);

if(!pD3D)

return false;DPRESENT_PARAMETERS params;( &params, sizeof(params));.Windowed = TRUE;.SwapEffect = D3DSWAPEFFECT_DISCARD;.BackBufferFormat = D3DFMT_UNKNOWN;hr = pD3D->CreateDevice(DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWndDCREATE_SOFTWARE_VERTEXPROCESSING,

&params &pDevice);

if(FAILED(hr))

{

pD3D->Release();D = 0;

return false;

}

D3DXCreateTeapot(pDevice &pTeapot, 0);(hWnd SW_SHOWDEFAULT);(hWnd);

return true;

}


Після закриття вікна функція викликає метод додатку для коректного очищення всіх виділених ресурсів Direct3D. Як буде показано в наступному розділі, об'єкти DirectX підкоряються правилам COM, і для їх звільнення також необхідно використовувати метод Release :


void SampleApplication::CleanupD3D()

{(pTeapot)>Release();

if(pDevice)>Release();

if(pD3D)D->Release();

}


Як вже мовилося, для відладки складних додатків DirectX буває корисно встановити Debug-версію бібліотеки, що входить до складу DirectX 9.0 SDK. Вона не тільки дозволяє контролювати правильність параметрів методів, але і видає діагностичне повідомлення при завершенні програми, якщо ви забудете видалити який-небудь об'єкт.


3.3.7 Побудова зображення

Для створення зображення обробник повідомлення WM_PAINT викликає метод Render. Настав час познайомитися і з ним.

Спочатку заповнимо область висновку синім кольором, викликавши метод Clear пристрою. Потім приступимо до підготовки зображення.

Всі команди виведення графічних об'єктів повинні обрамлятися операторними дужками BeginScene/EndScene для коректного відробітку конвейєра висновку.

Спочатку для сцени задається джерело світла і характеристики матеріалу, з якого виготовлений чайник. Потім до пристрою застосовується матриця світового перетворення (чайник злегка зменшується і відсовується по осі Z). Нарешті, виводимо довгождане зображення. Об'єкти Mesh бібліотеки D3DX самі уміють відображати себе в пристрій Direct3D, досить викликати метод DrawSubset. Насправді, як ми переконаємося пізніше, вони складаються з безлічі дрібних тривимірних примітивів (як правило, трикутників), але угрупування примітивів в об'єкт сильно полегшить нам завдання. Після завершення виведення сцени необхідно викликати метод EndScene, який і приведе до побудови зображення у вторинному буфері. Метод пристрою Present дозволяє вивести вміст вторинного буфера на екран.

Повністю текст методу Render приведений в лістингу.


void SampleApplication::Render()

{(pDevice)

{

// Очистимо область висновку темно-синім кольором>Clear( 0, NULLDCLEAR_TARGET,DCOLOR_XRGB(0,0,128), 0.0f, 0 );

// Малюємо сцену( SUCCEEDED( pDevice->BeginScene() ))

{

// створюємо джерело світлаDLIGHT9 light=

{ D3DLIGHT_DIRECTIONAL, // нескінченно видалене джерело

{1,1,0,0}// дифузне освітлення: жовтий колір

{0,0,0,0}

{0.1f,0.1f,0.1f,1}// розсіяне світло: тьмяний білий

{0,0,0}

{7-2,1} // вектор напряму

} ;>SetLight( 1 &light ) ;>LightEnable( 1, TRUE ) ;

// створюємо матеріал

D3DMATERIAL9 material = {

{1,1,1,1}

{1,1,1,1}

{1,1,1,1}

{0,0,0,0}


} ;

pDevice->SetMaterial( &material ) ;

float scale = 0.4f;DMATRIX transform = {, 0.0f, 0.0f, 0.0f

.0f, scale, 0.0f, 0.0f

.0f, 0.0f, scale, 0.0f

.0f, 0.0f, 1.0f, 1.0f

};

pDevice->SetTransform(D3DTS_WORLD, &transform);>DrawSubset(0);>EndScene();

}

// Виводимо вміст вторинного буфера>Present( NULL, NULL, NULL, NULL );

}

}


Отже, всі необхідні функції реалізовані. Відкомпілюйте одержану програму. Якщо не виникло жодної помилки, запустіть її на виконання. Ось воно, творіння наших рук (рис 3.5).


Рис 3.5 Зовнішній вигляд вікна першої програми


Ми обов'язково поліпшимо цей приклад, але зараз давайте ближче познайомимося з основою основ бібліотеки DirectX - моделлю COM.


3.3.8 Огляд моделі COM

У даному розділі ми стисло розглянемо особливості компонентної моделі COM, на якій побудована реалізація DirectX для платформи Windows. Знайомі з COM програмісти вільно можуть пропустити цей розділ без збитку для розуміння.

Програмування в термінах класів і об'єктів давно вже стало звичним. Мова C++ придбав величезну популярність завдяки підтримці об'єктно-орієнтованого програмування. За час існування C++ для нього була створена велика кількість бібліотек класів.

Проте сучасний світ багатий різноманітними технологіями, і сумісності на рівні початкових текстів вже недостатньо. Що, якщо вам знадобиться використовувати об'єкт, створений на іншій версії компілятора або взагалі на іншій мові? Один з варіантів рішення вже давно існує в операційній системі Windows.

Бібліотеки динамічної компоновки (DLL) дозволяють створити програмний код, доступний для завантаження і виконання. Експортуються з DLL функції стають доступними в зухвалій програмі, неначебто вони були в ній реалізовані. Схрестивши дві ці ідеї, ми і одержимо реалізацію компонентного програмування.

Отже, компонентне програмування цей логічний розвиток ідей об'єктно-орієнтованого програмування, яке дозволяє вирішити проблеми повторного використання коду з різних програмних середовищ і понизити витрати на супровід різних версій програмного коду. Це досягається за рахунок відділення інтерфейсів об'єктів від їх реалізації.


3.3.9 Інтерфейс і реалізація

Інтерфейсом об'єкту називають опис його функціональності (методів, властивостей і т.д.) на одній з мов високого рівня. У компонентних середовищах (таких, як COM) забороняється звертатися до об'єкту інакше, як через інтерфейси. Навіщо потрібні такі строгі обмеження? Давайте подивимося.

Якщо до якогось програмного об'єкту можна звернутися за допомогою певного інтерфейсу, то говорять, що об'єкт реалізує (підтримує) цей інтерфейс. Об'єкт може підтримувати одночасно декілька інтерфейсів.

На мові С++ інтерфейс звичайно описується як клас, набір абстрактних віртуальних функцій, що містить тільки. Наприклад, в лістингу 9 описується інтерфейс для роботи з домашніми тваринами (Pets), що містить два методи.

// інтерфейси прийнято іменувати із заголовної букви I interface IPet

{

int GetNumberOfLegs() = 0; // абстрактний метод - число ніг

void Speak() = 0; // абстрактний метод - видати звук

};


Для читачів, незнайомих з описом інтерфейсів на С++, пояснимо, що interface - це не нове ключове слово, а всього лише створене для наочності макроозначення (#define) звичного ключового слова struct:


// десь в системних заголовних файлах...

#define interface struct


Чому struct, а не class? Дуже просто: у структурах всі члени за умовчанням мають загальний доступ, тому при описі інтерфейсу не доведеться спеціально виписувати модифікатор доступу public. Відзначимо, що інтерфейс завжди проектується для доступу цілком: Ви або можете дістати доступ до всього інтерфейсу, або немає.

Звернемо увагу: явно вказано, що всі методи структури (або інтерфейсу) IPet є абстрактними (pure virtual). Це означає, що не можна створити безпосередньо екземпляр IPet. Натомість можна створити клас, успадкований від IPet, в якому реалізувати всі абстрактні методи. Говорять, що такий об'єкт називається реалізацією інтерфейсу. У лістингу приведений приклад такої реалізації.


class CDog : public IPet

{ GetNumberOfLegs();

void Speak();

}; CDog::GetNumberOfLegs()

{

return 4;

}

void CDog::Speak()

{(-1); // видамо системний звук Windows

}


Тепер уявимо собі, як міг би використовуватися придуманий нами інтерфейс в програмі на C++. Припустимо, ми збираємося створити об'єкт "собака" і покерувати їм через наш інтерфейс IPet. Ось черговий шматок коду, дуже схожого на реальне використання COM-об'єктів (зокрема, компонентів DirectX):

*pDog = CreatePet("Dog");

// дізнаємося, чи є наш друг чотириногим

int nLegs = pDog->GetNumberOfLegs();

// якщо лап не 4, примусимо собачку загавкати

if (nLegs != 4)>Speak();


Як бачимо, код використання інтерфейсу дуже схожий на звичайну роботу з об'єктами C++. Основна відмінність полягає в тому, що наша програма не використовує об'єкт CDog безпосередньо (вона про нього навіть не знає), а виконує всю роботу через покажчик на інтерфейс IPet. Тому ж в нашому прикладі міститься виклик гіпотетичної функції CreatePet, яка знала б про деталі реалізації інтерфейсу і уміла створювати екземпляр об'єкту "собака".

Такі обмеження злегка ускладнюють роботу з компонентами, але додають нашій програмі величезну гнучкість. Тепер ми можемо створювати і використовувати готові компоненти не тільки на мові C++. Взагалі кажучи, дослідивши уявлення в пам'яті, яке утворює інтерфейс, ми можемо відтворити це бінарне уявлення іншими засобами (наприклад, на мові C, в якій взагалі немає класів і віртуальних функцій).

Підтримка COM вбудована і в деякі інші програмні середовища, наприклад, в Delphi і Visual Basic. Це дозволяє створювати двійкові версії компонентів: скомпілювавши DLL, що містить код компоненту на одній мові, викликати і використати цей об'єкт на іншій мові програмування.

З останнім твердженням пов'язана одна проблема: механізми створення і знищення об'єктів розрізняються в різних програмних середовищах. Наша гіпотетична функція CreatePet повинна враховувати всі ці особливості, щоб уміти створювати об'єкти, що містяться в двійкових бібліотеках, що відкомпілювалися, і запрошувати у них підтримку необхідного інтерфейсу.

Для створення COM-компонентів звичайно застосовуються функції CoCreateInstance і CoGetClassObject. Ці функції надає бібліотека COM, тому перед їх викликом потрібна її ініціалізація.

Деякі об'єкти DirectX також можна створювати таким чином, але звичайно використовується простіший метод. Бібліотека надає спеціальні функції для створення необхідних програмних компонентів. Наприклад, для створення об'єкту Direct3D версії 9 існує функція Direct3DCreate9, описана в заголовному файлі d3d9.h. Саме цей спосіб був застосований в нашому прикладі.


3.3.10 Інтерфейс IUnknown

Приведений в попередньому розділі інтерфейс IPet не є інтерфейсом в стилі COM. Щоб задовольняти специфікації COM, всі інтерфейси, включаючи інтерфейси DirectX, повинні бути успадковані від спеціального інтерфейсу IUnknown. Не дивлячись на свою назву ("unknown" в перекладі з англійського означає "невідомий"), це - інтерфейс, про який знають все. У лістингу 12 приведене небагато спрощений опис інтерфейсу IUnknown для мови С++.

IUnknown

{HRESULT QueryInterface( const IID& iid void** ppv )= 0;

virtual ULONG AddRef() = 0;

virtual ULONG Release() = 0;

};


Розглянемо призначення методів IUnknown.

Про довільний COM-об'єкт звичайно можна сказати тільки те, що він підтримує інтерфейс IUnknown. Призначення QueryInterface - визначити, чи підтримує даний об'єкт будь-який інший інтерфейс. Пам'ятаєте приклад з інтерфейсом IPet? Якби він був створений з урахуванням специфікації COM, то у довільного об'єкту COM можна було б запитати, чи є він твариною:

*pUnk = ... // якимсь чином одержуємо покажчик на об'єкт*pPet = 0;

if(SUCCEEDED(pUnk->QueryInterface(IID_IPet, (void**)&pPet))

{

... // так, цей об'єкт є твариною

}


Пояснимо два моменти з цього прикладу.

Звичайно функції і методи об'єктів COM повертають спеціальне значення типу HRESULT, для індикації успішності або невдачі виклику. Макроси SUCCEEDED і FAILED є рекомендованим способом перевірки такого результату.

Щоб відрізняти один інтерфейс від іншого (і запрошувати їх підтримку), недостатньо просто рядки з ім'ям. Імена на зразок «IPet» досить поширені, і існує вірогідність одночасного використання таких імен двома різними розробниками. Щоб уникнути таких конфліктів творцями COM було ухвалене рішення використовувати для ідентифікації інтерфейсів і об'єктів спеціальний 128-бітовий ідентифікатор - GUID, який є статистично унікальним. При створенні нового інтерфейсу розробник просто створює новий GUID і описує його в заголовному файлі або бібліотеці типів об'єкту. У нашому прикладі передбачалося, що такої GUID описаний в заголовному файлі інтерфейсу під ім'ям IID_IPet., Release

Звичайний екземпляр класу C++ створюється в програмі викликом конструктора, а віддаляється при виході з області видимості або викликом оператора delete, якщо об'єкт був створений в динамічній пам'яті. Для COM типова ситуація, коли об'єкт реалізує відразу декілька інтерфейсів, і покажчики на ці інтерфейси зберігаються в клієнтах.

При цьому відстежування всіх таких покажчиків стає непростим завданням. Що, якщо об'єкт буде видалений, а посилання на нього десь збережуться? Подальша робота з цими посиланнями приведе до збою програми. Інша, часто виникаюча проблема це необхідність видалення об'єкту після того, як всі посилання на нього зруйновані. Якщо даремний об'єкт не віддаляється, він даремно витрачатиме оперативну пам'ять і інші цінні ресурси.

Призначення методів AddRef і Release - управління часом життя об'єкту. Одержавши в своє користування інтерфейс об'єкту, необхідно викликати AddRef. Це дозволить гарантувати, що об'єкт не буде зруйнований, поки використовується хоч би один його інтерфейс.

Завершуючи роботу з об'єктом, необхідно повідомити його про це. Для кожного одержаного від нього інтерфейсу необхідно викликати метод Release. Звичайно об'єкт знищується, якщо на нього більше немає зовнішніх посилань. Але реалізація цієї поведінки цілком контролюється програмістом компоненту. Значення методів AddRef і Release, що повертається, найчастіше містить поточне значення внутрішнього лічильника посилань об'єкту, але його рекомендується ігнорувати, оскільки на це значення немає чіткої специфікації. Проте, одному з авторів доводилося бачити ось такий сумнівний код "гарантованого видалення" об'єкту DirectX:

while(p->Release()); // (C) 1999, 2000 NVIDIA Corporation

Як бачите, великі корпорації іноді можуть дозволити собі ігнорувати рекомендації специфікацій COM.

Сподіваємося, що цього короткого знайомства з моделлю COM буде досить для того, щоб розібратися в прикладах, що наводяться. Якщо ви хочете дізнатися про неї більше, рекомендуємо прочитати спершу книгу Дейла Роджерсона «Основи COM».


3.4 Managed DirectX. Програмування для .NET


У .NET-программистов тепер теж є можливість легко створювати Direct3D-приложения. Починаючи з дев'ятої версії, до складу DirectX SDK включений так званий Managed DirectX - програмний інтерфейс до бібліотеки DirectX для платформи .NET. Він включає .NET-сборки з реалізацією компонентів DirectX, програмні приклади і документацію.

Для створення програм з використанням Managed DirectX необхідно, щоб крім середовища виконання DirectX на комп'ютері була встановлена остання версія .NET Framework (на даний момент - 1.1), а також набір складок Managed DirectX. Ось перелік цих файлів:

§Microsoft.DirectX.AudioVideoPlayback.dll

§Microsoft.DirectX.Diagnostics.dll

§Microsoft.DirectX.Direct3D.dll

§Microsoft.DirectX.Direct3DX.dll

§Microsoft.DirectX.DirectDraw.dll

§Microsoft.DirectX.DirectInput.dll

§Microsoft.DirectX.DirectPlay.dll

§Microsoft.DirectX.DirectSound.dll

§Microsoft.DirectX.dll

Ми створимо тестовий проект з використанням середовища Visual Studio 2003, хоча простий DirectX-додаток цілком можна створити і без цього середовища розробки: як і у випадку з GDI+, досить текстового редактора і компілятора командного рядка csc.exe. Отже, створіть новий проект (Рис 3.6). Із списку Project Types виберіть пункт Visual C# Projects, а з переліку проектів, що з'явився, - пункт Windows Application. Введіть ім'я нового проекту, виберіть каталог для збереження його файлів і натисніть OK.


Рис 3.6 Створення нового додатку для платформи .NET


У нас з'явиться вікно дизайнера форми - головного вікна майбутнього додатку. Ми не використовуватимемо дизайнер, а введемо початковий код всієї програми в редакторі. Тому натисніть на дизайнері праву кнопку миші і виберіть з контекстного меню, що з'явилося, пункт View Code.

Видаліть весь текст з редактора і введіть замість нього код з лістингу.


using System;

using System.Windows.Forms;

using Microsoft.DirectX;

using Microsoft.DirectX.Direct3D;

class TestForm: Form

{void Main()

{

TestForm form = new TestForm();.Text = "Direct3D для .NET";.Width = 400;.Height = 300;.InitD3D();.Show();

while(form.Created)

{

form.Render();.DoEvents();

}

}

Device device;teapot;

public void InitD3D()

{

PresentParameters parameters = new PresentParameters();.Windowed = true;.SwapEffect = SwapEffect.Discard;= new Device(0, DeviceType.Hardware, this

CreateFlags.SoftwareVertexProcessing, parameters);= Mesh.Teapot(device);

}void Render()

{

device.Clear(ClearFlags.Target,.Drawing.Color.Blue, 1.0f, 0);.BeginScene();

try

{

device.RenderState.Lighting = true;.Lights[0].Type = LightType.Directional;.Lights[0].Direction = new Vector3(7 -2, 1);.Lights[0].Diffuse = System.Drawing.Color.Yellow;.Lights[0].Commit();.Lights[0].Enabled = true;material = new Material();.Ambient = System.Drawing.Color.White;.Diffuse = System.Drawing.Color.White;.Specular = System.Drawing.Color.White;.Material = material;matrix = new Matrix();.Scale(0.4f, 0.4f, 0.4f);.M43 = 1; // перенесення по осі Z.Transform.World = matrix;.DrawSubset(0);

}

{

device.EndScene();

}

device.Present();

}

}


Програма виконує побудову тієї ж сцени, що і її еквівалент на C++, але текст її помітно коротший. Це пов'язано з тим, що нам не довелося возитися з низькорівневими деталями: реєстрацією класу вікна і обробкою повідомлень. Відмітимо також, що, хоча в .NET підтримується концепція інтерфейсів, при створенні Managed API для інтерфейсів DirectX було вирішено упакувати їх в классы- «обгортки», що помітно спрощує їх використання.

Для успішної компіляції одержаної програми необхідно додати в проект посилання на наступні складки Managed DirectX:

·Microsoft.DirectX.dll

·Microsoft.DirectX.Direct3D.dll

·Microsoft.DirectX.Direct3DX.dll

Для цього в меню Project виберіть пункт Add Reference. і в списку складок, що з'явився, по черзі виберіть подвійним клацанням миші всі три складки (Рис 3.7)

За умовчанням при установці Managed DirectX на комп'ютер ці файли поміщаються в каталог <Windows>\Microsoft.NET\Managed DirectX\v4.09.00.0900\. Якщо з якоїсь причини инсталлятор не помістив їх в глобальний кеш складок (таке трапляється), то ви зможете знайти їх там, щоб самостійно додати посилання на ці складки в свій проект.



Рис 3.7 Додавання складок Direct3D у проект на C#


Тепер компіляція повинна пройти без проблем. Побудуйте програму і переконайтеся, що воно виводить на екран таке саме зображення, як і приклад на C++.

Можна приступати до детальнішого знайомства з Direct3D. Почнемо з ініціалізації.


3.5 Початок роботи. Ініціалізація Direct3D


Будь-яка бібліотека містить, як правило, структури даних, що потребують правильної ініціалізації, і DirectX - не виключення.

У цьому розділі ми розповімо про особливості ініціалізації компоненту Direct3D, питаннях вибору доступних графічних пристроїв і установці відеорежимів.


3.5.1 Ініціалізація і перелік графічних пристроїв засобами C++

Як вже мовилося, у версії для C++ належна підготовка бібліотеки для роботи виконується створенням об'єкту Direct3D. Цей об'єкт реалізує COM-інтерфейс IDirect3D9, основне призначення якого - проведення подальшої ініціалізації і настройка режимів графічного пристрою.

Для створення об'єкту Direct3D у нашому прикладі використовувався код наступного вигляду:

IDirect3D9 *pD3D;D = Direct3DCreate9(D3D_SDK_VERSION);

Тут D3D_SDK_VERSION - константа, визначена в заголовному файлі d3d9.h (взагалі-то, у складі DirectX 9.0 SDK є і старий заголовний файл d3d8.h, у якому ця константа має інше значення, так що будьте обережні). Її призначення - переконатися в тому, що програма скомпільована і зібрана з однією і тією ж версією заголовних файлів і бібліотек.

В результаті виконання ми одержуємо покажчик на інтерфейс IDirect3D9, використовуючи який можна проводити подальші дії по настройці графічного устаткування.

Останнім часом набули поширення конфігурації ПК з декількома відеоадаптерами, наприклад, комбінація інтегрованої «офісної» відеокарти і додаткової «ігрової». Досить частим завданням є отримання списку доступних графічних пристроїв - наприклад, щоб дозволити користувачу вибрати відеокарту, яку він вважає за краще використовувати для віртуальної битви.

Для отримання кількості доступних в системі відеоадаптерів використовується метод IDirect3D9::GetAdapterCount(). Подальший перебір доступних адаптерів можна здійснювати, послідовно викликаючи метод IDirect3D9::GetAdapterIdentifier з порядковим номером Adapter, що збільшується:

GetAdapterIdentifier(UINT AdapterFlagsDADAPTER_IDENTIFIER9 *pIdentifier );


Як значення Flags потрібно передати 0 (для звичайного перебору) або константу D3DENUM_WHQL_LEVEL для перебору тільки тих адаптерів, драйвери яких мають сертифікацію Microsoft Windows Hardware Quality Labs (WHQL). У останньому випадку не дивуйтеся, якщо комп'ютер почне «стукатися» в Інтернет для завантаження новітніх сертифікатів.

Останній параметр - покажчик на структуру D3DADAPTER_IDENTIFIER9, у яку заноситься інформація про вибраний відеоадаптер. От як, використовуючи цю інформацію, вивести в консоль дані про всі встановлені відеоадаптери:


#include <stdio.h>

#include <d3d9.h>

#pragma comment(lib, "d3d9.lib")

int main()

{

IDirect3D9 *pD3D = Direct3DCreate9(D3D_SDK_VERSION);

if(!pD3D)

{

printf("Direct3DCreate9 failed!\n");

return 1;

}nCount = pD3D->GetAdapterCount();

for(int i=0; i<nCount; i++)

{

D3DADAPTER_IDENTIFIER9 info;D->GetAdapterIdentifier(i, 0 &info);("Adapter %d: \n"

"\tDriver: %s\n"

"\tDescription: %s\n"

"\tDeviceName: %s\n",, info.Driver, info.Description,.DeviceName);

}

return 0;

}

Приклад виведення цієї програми на комп'ютері з однією відеокартою:

Adapter 0:: ati2dvag.dll: RADEON 9600 SERIES: \.\DISPLAY1

А ось результат виконання на машині з трьома відеокартами:

Adapter 0:: nv4_disp.dll: NVIDIA GeForce DDR: \.\DISPLAY11:: perm2dll.dll: Appian Graphics Jeronimo Pro: \.\DISPLAY22:: perm2dll.dll: Appian Graphics Jeronimo Pro: \.\DISPLAY3


Схожим чином розв'язується і інше завдання: перерахувати список доступних для даного адаптера відеорежимів. Для переліку режимів інтерфейс IDirect3D9 надає методи GetAdapterModeCount і EnumAdapterModes. Але, на відміну від обмеженого числа доступних адаптерів, існує безліч різних комбінацій дозволу, колірних форматів і частоти оновлення екрану. Тому при переліку доступних режимів необхідно додатково указувати допустимі піксельні формати (кольори, що описують глибину, і порядок колірних складових). Константи форматів описані в переліку D3DFORMAT.

3.5.2 Перелік пристроїв і відеорежимів для Managed Direct3D

Версія Direct3D для .NET не вимагає явної ініціалізації бібліотеки. Функція Direct3DCreate9 викликається автоматично в статичному конструкторі класу Microsoft.DirectX.Direct3D.Manager.

За допомогою цього класу також легко одержати інформацію про список доступних графічних пристроїв. Його властивість Adapters повертає список структур AdapterInformation, що містять всі потрібні дані. У лістингу приведений приклад програми на C#, що також виводить список встановлених адаптерів.


using System;

using System.Windows.Forms;

using Microsoft.DirectX;

using Microsoft.DirectX.Direct3D;

class TestForm: Form

{void Main()

{(AdapterInformation adapterInfo in Manager.Adapters).WriteLine("Adapter: \n\tDriver: {0}n\t"+

"Description: {1}n\tDeviceName: {2}n",.Information.DriverName,.Information.Description,.Information.DeviceName);

}

}


Завдання отримання списку доступних для кожного адаптера відеорежимів також розв'язується дуже просто: у структурі AdapterInformation існує властивість SupportedDisplayModes, що надає список всіх доступних режимів.

Як вже мовилося, цей список може містити сотні комбінацій, тому розумно відбирати з нього тільки режими з відповідним колірним форматом. Тому властивість SupportedDisplayModes підтримує індексування за кодом формату, описаним в класі Microsoft.DirectX.Direct3D.Format просто вкажіть код формату в квадратних дужках після імені властивості.

Ось приклад виведення всіх доступних для першого відеоадаптера комбінацій відеорежимів з глибиною кольору High Color 5-6-5 (по 5 біт для представлення червоного і синього кольору і 6 біт для передачі зеленого):


foreach(DisplayMode mode in

Manager.Adapters[0].[Format.R5G6B5]).WriteLine("{0}x{1}, {2} Hz, Format: {3}",.Width, mode.Height, mode.RefreshRate, mode.Format);


Ви, можливо, відмітили, що нам знову допомагає особливість .NET Framework: всі константи переліків, як, наприклад, назви різних колірних форматів, повертають «читані» імена при їх висновку.


3.5.3 Ініціалізація графічного режиму для C++

Для виведення зображень в Direct3D використовується об'єкт Device (пристрій), який відповідає за взаємодію з апаратною частиною відеоадаптера. При створенні цього об'єкту необхідно вказати ряд параметрів, які ми зараз і розглянемо.

Пригадаємо фрагменти коду створення об'єкту Direct3D Device в своїй першій програмі:

hr = pD3D->CreateDevice(DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWndDCREATE_SOFTWARE_VERTEXPROCESSING,

&params &pDevice);


Перший параметр методу IDirect3D9::CreateDevice визначає адаптер, для якого створюється об'єкт Device. Можна вказати або порядковий номер, одержаний переліком (як в лістингу 14), так і константу D3DADAPTER_DEFAULT, при завданні якої буде використаний адаптер, вибраний користувачем за умовчанням.

Наступний параметр визначає тип пристрою і може приймати одне з трьох значень: D3DDEVTYPE_HAL, D3DDEVTYPE_REF або D3DDEVTYPE_SW. Другий і третій режими використовують програмну емуляцію всіх операцій Direct3D і можуть мати сенс тільки для відладки, оскільки виконуються дуже поволі.

Параметр hWnd необхідний для вказівки дескриптора вікна Windows, до якого буде прив'язане створення пристрою.

Наступний параметр вперше з'явився в DirectX 8.0 завдяки реалізації у відеокартах останнього покоління апаратної підтримки T&L (Transform and Lighting, Трансформація і освітлення). Ми вказали значення D3DCREATE_SOFTWARE_VERTEXPROCESSING, щоб використовувати програмну обробку вершин примітивів. Для включення апаратної підтримки T&L використовуйте константу D3DCREATE_HARDWARE_VERTEXPROCESSING. Це зніме велике навантаження з центрального процесора по обсчету вершин, але обмежить число відеокарт, що підтримують програму.

Далі необхідно передати покажчик на структуру D3DPRESENT_PARAMETERS, що містить додаткові параметри ініціалізації. Повний перелік полів цієї структури приведений в довідці по Direct3D. Як ми вже переконалися, для ініціалізації віконного відеорежиму досить ініціалізувати структуру нулями і вказати тільки три параметри:

D3DPRESENT_PARAMETERS params;( &params, sizeof(params));.Windowed = TRUE;.SwapEffect = D3DSWAPEFFECT_DISCARD;.BackBufferFormat = D3DFMT_UNKNOWN;


Ще чого одна користь установки налагоджувальної версії DirectX Runtime: вказівка значення D3DSWAPEFFECT_DISCARD у полі SwapEffect допомагає при відладці додатків Direct3D. При цьому кожен кадр, що виводиться, перед побудовою сцени заповнюється випадковим «шумом», і ви легко відмітите ситуацію, при якій зображення, що виводиться, не заповнює всю область кадру.

Ініціалізація повноекранного відеорежиму вимагає додаткової вказівки, як мінімум, ще чотирьох полів: BackBufferWidth, BackBufferHeight (дозвіл екрану), BackBufferFormat (колірний формат) і FullScreenRefreshRateInHz (частота оновлення екрану). У лістингу 16 приведений приклад ініціалізації відеорежиму 1024x768, TrueColor, з частотою кадрів за умовчанням:

DPRESENT_PARAMETERS params;( &params, sizeof(params));.Windowed = FALSE;.SwapEffect = D3DSWAPEFFECT_DISCARD;.BackBufferWidth = 1024;.BackBufferHeight = 768;.BackBufferFormat = D3DFMT_A8R8G8B8;.FullScreen_RefreshRateInHz = D3DPRESENT_RATE_DEFAULT;hr = pD3D->CreateDevice(DADAPTER_DEFAULT,DDEVTYPE_HAL, hWndDCREATE_SOFTWARE_VERTEXPROCESSING,

&params &pDevice);


Якщо відеокарта не підтримує вказаний колірний формат, виклик CreateDevice поверне помилку. Інакше змінна pDevice міститиме покажчик на створений пристрій IDirect3DDevice9.


3.5.4 Ініціалізація графічного режиму: версія для C#

Установка відеорежиму в реалізації Managed DirectX дуже схожа на версію для C++, з однією істотною відмінністю: об'єкт Device створюється викликом конструктора, що виглядає природніше. Ось опис цього конструктора:


public Device(

int adapterdeviceTyperenderWindowbehaviorFlagspresentationParameters

);


Сенс параметрів залишився тим же, що і у версії для C++. Значення констант містяться в класах-переліках DeviceType, CreateFlags і т.д., що не вимагає їх запам'ятовування. Вище вже був приведений код для ініціалізації віконного пристрою, а в лістингу 17 міститься приклад установки повноекранного відеорежиму (з тими ж характеристиками, що і в прикладі на C++)

parameters = new PresentParameters();.BackBufferWidth = 1024;.BackBufferHeight = 768;.BackBufferFormat = Format.A8R8G8B8;.FullScreenRefreshRateInHz =.DefaultPresentRate;.Windowed = false;.SwapEffect = SwapEffect.Discard;= new Device(0, DeviceType.Hardware, this

CreateFlags.SoftwareVertexProcessing, parameters);


Вказівка неправильних або непідтримуваних параметрів відеорежиму приведе до генерації виключення Microsoft.DirectX.Direct3D.InvalidCallException.


3.5.5 Видалення невидимих деталей

Наш симпатичний чайник малюється в дуже вигідному ракурсі, який приховує явні дефекти зображення. Признатися, ми ретельно підібрали положення об'єкту і кут огляду для першого прикладу: хотілося швидше одержати готове зображення, не стомлюючи вас зайвими проблемами.

Але настав час рухатися далі, і зараз ідилія буде зруйнована. Не лякайтеся, просто пора познайомитися з реалізацією алгоритмів видалення невидимих деталей в Direct3D.

Піраміда видимості

Достатньо злегка зрадити параметри сцени, як з чайником почне творитися щось недобре. Знайдіть в програмі на C++ наступний фрагмент:

DMATRIX transform = {, 0.0f, 0.0f, 0.0f

.0f, scale, 0.0f, 0.0f

.0f, 0.0f, scale, 0.0f

.0f, 0.0f, 1.0f, 1.0f

};

І заміните його новим (зверніть увагу на виділений текст):

DMATRIX transform = {, 0.0f, 0.0f, 0.0f

.0f, scale, 0.0f, 0.0f

.0f, 0.0f, scale, 0.0f

.0f, 0.0f, 0.3f, 1.0f

};


Аналогічна ділянка в програмі на C# виглядає так:

matrix.M43 = 1; // перенесення по осі Z

Також заміните тільки константу в рядку:

matrix.M43 = 0.3f; // перенесення по осі Z

У обох програмах зміна торкнулася тільки одного елементу матриці перетворення, елементу з індексом (4, 3).

Ми ще детально розглядатимемо геометричні перетворення в просторі Direct3D, зараз досить сказати, що цей елемент відповідає за переміщення об'єкту від центру координат по осі Z. Тобто ми відсунули чайник від камери не на 1 одиницю відстані, як в першому випадку, а на 0.3. Результат такої зміни показаний на рисунку 3.8.


Рис 3.8 Об'єкт відрізаний з боку спостерігача


Не менш вражаючий результат вийде, якщо зрадити той же елемент матриці із значення 1.0 до всього 1.05 (рис 3.9).

Рис 3.9 Об'єкт відрізаний з протилежної сторони


Як видно з малюнків, всі деталі об'єкту, що виходять за певні межі, акуратно «відрізуються». Якщо ви проведете експерименти з елементами матриці (4, 1) і (4, 2), що відповідають за переміщення об'єкту по двох іншим координатним осям, то відмітите, що висновок обмежений і в цих координатах. Це наочна демонстрація роботи механізму відсікання в Direct3D. Навіщо потрібні такі обмеження?

Якщо провести чотири уявні промені від точки спостереження до країв екрану, то вийде піраміда з прямокутником (екраном) в підставі. Продовжуючи промені далі, углиб віртуального світу, який «спроектований» на наш екран, ми одержимо піраміду видимості (viewing frustum). Все, що знаходиться за межами цієї піраміди, все одно буде поза полем проекції, так навіщо малювати ці деталі, даремно витрачаючи час?

Якщо розміркувати, то не потрібно малювати і дуже видалені об'єкти, потрібно уміти вчасно зупинитися. Все одно на шляху погляду рано чи пізно зустрінеться перешкода. Та і людське око не побачить чайник, видалений на відстань в, скажімо, десятки кілометрів. Те ж саме торкається, наприклад, предметів, що «знаходяться» у віртуальному світі позаду нас або перед екраном. Тому в DirectX і реалізовано відсікання об'єктів по усіченій піраміді, освіченій передній, задній і чотирма бічними відсікаючими площинами (рис. 3.10).


Рис 3.10 Проекція зображення і піраміда видимості


Це досить корисна функціональність, що дозволяє заощадити час при обробці складних сцен, а, отже, підвищити продуктивність. Проте зараз ми просто відключимо цей механізм, оскільки в наших учбових прикладах швидкодія не важливо.

Щоб відмовитися від відсікання в програмі на C++, перед виведенням об'єкту додайте строчку:

>SetRenderState(D3DRS_CLIPPING, FALSE);


Еквівалентна строчка на C# виглядає так:

.RenderState.Clipping = false;


Можете перевірити: переміщення об'єкту по сцені більше не відображатимуться на його цілісності.


3.5.6 Буфер глибини (Z-buffer)

Щоб проілюструвати чергову проблему, що виникає при зображенні складних об'єктів (або груп об'єктів), додамо в сцену динамічність.

Хай наш чайник обертається з постійною швидкістю навколо осі Y. Для цього потрібно, по-перше, примусити програму постійно перемальовувати сцену. Оскільки наша програма на C++ викликає метод Render в обробнику WM_PAINT, то для постійного перемальовування досить викликати функцію InvalidateRect після малювання:


case WM_PAINT:

{

PAINTSTRUCT ps;(hWnd &ps);_App.Render();(hWnd &ps);(hWnd, 0, TRUE);

return 0;

}


Для реалізації обертання об'єкту скористаємося бібліотекою утиліт D3DX. Нам допоможе функція D3DXMatrixRotationY, яка створює матрицю повороту на необхідний кут. Для її використання необхідно створити об'єкт D3DXMATRIX і передати кут повороту в радіанах.

Клас D3DXMATRIX, також наданий бібліотекою D3DX, є просто обгорткою над вже знайомою структурою D3DMATRIX. У цьому класі реалізований ряд корисних математичних операцій, а також операції порівняння матриць.

Для формування остаточної матриці помножимо одержану матрицю повороту на початкову матрицю transform, що існувала в первинній версії програми. Виправлений фрагмент методу Render представлений в лістингу.

scale = 0.4f;DXMATRIX transform(, 0.0f, 0.0f, 0.0f

.0f, scale, 0.0f, 0.0f

.0f, 0.0f, scale, 0.0f

.0f, 0.0f, 1.0f, 1.0f

);

D3DXMATRIX rotation;DXMatrixRotationY(&rotation, GetTickCount()/1000.0f);*= transform;>SetTransform(D3DTS_WORLD, &rotation);>SetRenderState(D3DRS_CLIPPING, FALSE);>DrawSubset(0);>EndScene();


Як видно з лістингу, для отримання монотонно зростаючого з кожним кадром кута повороту ми скористалися функцією GetTickCount, що повертає число мілісекунд з моменту старту програми. Ми ділимо це число на 1000, таким чином, наш чайник обертається строго із швидкістю 1 радіан в секунду (Рис 3.11).


Рис 3.11 Зображення малюється неправильно (носик «просвічує» крізь чайник)


А ось і обіцяний дефект: можна відмітити, що деякі деталі чайника «просвічують» крізь корпус, хоча винні їм затулятися. Якщо ми повторимо малювання об'єкту в цій же сцені, але з трохи іншими координатами, перетин двох цих фігур також не зображатиметься правильно.

Річ у тому, що наш об'єкт складається з трикутних примітивів, а порядок їх малювання не визначений. Якщо трикутники, з яких складається носик чайника, малюватимуться після зображення корпусу, це неминуче затре вже створене зображення.

Один з найефективніших способів рішення цієї проблеми давно реалізований апаратний у всіх сучасних відеокартах і називається алгоритмом Z-буфера, або буфера глибини. У його основі лежить простий принцип: кожному пикселу кадру відповідає спеціальна величина, звана завглибшки.

При включенні цього режиму виведення примітиву приводить до заповнення не тільки буфера кадру, але і Z-буфера: у нього записуються значення «глибини» (ступені віддаленості) відповідних крапок. Крапка виводиться тільки за умови, що вона ближче поточного значення в Z-буфері, при цьому Z-буфер заповнюється новим значенням.

Для включення буфера глибини при ініціалізації відеорежиму необхідно заповнити додатково два поля структури D3DPRESENT_PARAMETERS:

.EnableAutoDepthStencil = TRUE;.AutoDepthStencilFormat = D3DFMT_D16;


Перше поле вирішує використання Z-буфера, друге визначає його формат (в даному випадку, для кожного пиксела зберігатиметься 16-бітове значення глибини).

Перед виведенням кожного кадру на екран необхідно очищати буфер глибини, інакше старі значення в ньому заважатимуть висновку нових кадрів. У цьому нам допоможе вже знайомий метод Clear з використанням прапора D3DCLEAR_ZBUFFER. Як третій параметр потрібно передати в цей метод значення 1.0 (максимальна глибина). Крім того, необхідно включити перевірку Z test і вирішити запис в буфер глибини. От як виглядатиме почало методу Render:

>Clear( 0, NULLDCLEAR_TARGET|D3DCLEAR_ZBUFFER,DCOLOR_XRGB(0,0,128), 1.0f, 0 );>SetRenderState(D3DRS_ZENABLE, TRUE);>SetRenderState(D3DRS_ZWRITEENABLE, TRUE);


Після компіляції програми елементи об'єкту, що перекриваються, будуть отрисовываться коректно (рис 3.12).


Рис 3.12 Правильне зображення (після включення Z-буфера)


У C#-программе рендеринг вже і так проводиться безперервно, досить додати код повороту і включення Z-буфера. Щоб не повторюватися, привнесемо невелику різноманітність: чайник в нашій програмі буде не тільки обертатися, але і переміщатися по осі Z.

У лістингу приведений повний текст модифікованої програми:


using System;

using System.Windows.Forms;

using Microsoft.DirectX;

using Microsoft.DirectX.Direct3D;

class TestForm: Form

{void Main()

{

TestForm form = new TestForm();.Text = "Direct3D для .NET";.Width = 400;.Height = 300;.InitD3D();.Show();

while(form.Created)

{

form.Render();.DoEvents();

}

}

Device device;teapot;

public void InitD3D()

{

{

PresentParameters parameters = new PresentParameters();.Windowed = true;.SwapEffect = SwapEffect.Discard;.EnableAutoDepthStencil = true;.AutoDepthStencilFormat = DepthFormat.D16;= new Device(0, DeviceType.Hardware, this

CreateFlags.SoftwareVertexProcessing, parameters);= Mesh.Teapot(device);

}(Exception e)

{

MessageBox.Show(e.Message);

return;

}

}void Render()

{

{

device.Clear(ClearFlags.Target|ClearFlags.ZBuffer,.Drawing.Color.Blue, 1.0f, 0);.RenderState.ZBufferEnable = true;.RenderState.ZBufferWriteEnable = true;.BeginScene();.RenderState.Lighting = true;.Lights[0].Type = LightType.Directional;.Lights[0].Direction = new Vector3(7 -2, 1);.Lights[0].Diffuse = System.Drawing.Color.Yellow;.Lights[0].Commit();.Lights[0].Enabled = true;material = new Material();.Ambient = System.Drawing.Color.White;.Diffuse = System.Drawing.Color.White;.Specular = System.Drawing.Color.White;.Material = material;matrix = new Matrix();.Scale(0.7f, 0.7f, 0.7f);*= Matrix.RotationY(.Environment.TickCount / 300.0f );

float move = (float)Math.Sin(.Environment.TickCount/2000.0f)*4+6;.M43 = move;= move.ToString("##.##");.RenderState.Clipping = false;.Transform.World = matrix;.Transform.Projection = Matrix.PerspectiveFovLH(

(float)Math.PI / 4, 1.0f, 1.0f, 100.0f );.DrawSubset(0);.EndScene();.Present();

}

catch(Exception e)

{

return;

}

}

}


3.5.6 Видалення нелицьових граней

Інший спосіб оптимізації виведення складних сцен полягає в діленні всіх примітивів об'єкту на «обернені лицем до спостерігача» і «обернені особою від спостерігача». Якщо об'єкт не містить «дірок», то при будь-якому його положенні завжди видно тільки лицьові грані. Отже, відмовившись від виведення нелицьових примітивів, можна заощадити приблизно 50% часу на побудову сцени. Цей спосіб відсікання називається cull (англ. «отбраковка»).

У Direct3D режим cull включений за умовчанням. Лицьовими вважаються трикутники, вершини яких описуються проти напряму годинникової стрілки (на їх екранній проекції, зрозуміло). Як вже було показано, бібліотека D3DX створює об'єкти з урахуванням цього режиму. Якщо ж встановити зворотний режим відсікання, то малюватимуться тільки внутрішні порожнини об'єкту, що приведе до отримання досить химерного зображення (рис 3.13).


Рис 3.13 Зображення з оберненими лицьовими гранями


Для установки такого режиму Cull в програмі на C++ використовується метод SetRenderState:

>SetRenderState(D3DRS_CULLMODE, D3DCULL_CW);


А в програмі на C# застосовується наступний синтаксис:

.RenderState.CullMode = Cull.Clockwise;


Якщо створений об'єкт містить «дірки» або напівпрозорі ділянки, крізь них повинні бути видно нелицьові грані. Для цього необхідне відключення режиму cull (використовуйте, відповідно, константи D3DCULL_NONE і Cull.None).


4. Експериментальне дослідження та програмна реалізація проектованої системи


4.1 Програмна реалізація та опис основних процедур і функцій розробленої системи


4.1.1 Створення віконного додатку

Запускаємо інтегроване середовище розробки Microsoft Visual Studio .NET 2008. Вибераєм пункт меню File/New/New Project.


Рис. 4.1 Інтегроване середовище розробки Microsoft Visual Studio .NET 2008


У діалоговому вікні, що з'явилося, в списку Project Types обираємо пункт Visual C# Projects, в списку, що оновився, Templates выбераем пункт Windows Application. У поле введення Name вводимо назву проекту (наприклад, DXApp), в полі введення Location указуємо шлях до каталога проекту (наприклад, С:\). Галочку напроти рядка Create directory for new solution можна прибрати.


Рис. 4.2 Діалогове вікно


Після натиснення кнопки OK буде створений проект для віконного додатку. Для збірки проекту выбераем пункт головного меню Build/Build Solution або натисніть Ctrl+Shift+B.


Рис. 4.3 Пункт головного меню Build/Build Solution


Збірка повинна пройти без помилок. Для виконання програми выбераем пункт меню Debug/Start Without Debugging або натискаємо Ctrl+F5.


Рис. 4.4 Пункт меню Debug/Start Without Debugging


На екрані з'явиться вікно нашого додатку.


Рис. 4.5 Вікно додатку


4.4.2 Настройка властивостей вікна

У вікні Solution Explorer відображається список файлів проекту. Початковий текст на мові C#, відноситься до головного вікна додатку знаходиться у файлі Form1.cs. Натиснення над цим файлом правої кнопки миші приводить до появи контекстного меню, в якому присутні пункти View Code і View Designer, що визначають відображення у вікні редактора або початкового тексту або зовнішнього вигляду вікна.


Рис. 4.6 Вікно Solution Explorer


Натиснемо праву кнопку миші у вільній області редактора зовнішнього вигляду вікна і в контекстному меню, що з'явилося, обираємо пункт Properties.


Рис. 4.7 Пункт Properties


На екрані з'явиться вікно редактора властивостей форми. Переконуємося, що третя зліва кнопка, що відображає список властивостей, натиснута.


Рис. 4.8 Список властивостей


У властивостях вікна (форми) змінюємо властивість Text, задаючи заголовок вікна (наприклад, на «Додаток Direct3D»). У властивості Icon указуємо шлях до файлу піктограми ($LabFiles$\directx.ico). Тепер вікно додатку повинне виглядати таким чином.

Рис. 4.9 Вікно додатку


4.4.3 Створення пристрою Direct3D для роботи з тривимірною графікою.

Спершу необхідно підключити до проекту збірки DirectX.dll, Direct3D.dll і Direct3DX.dll, що містять managed класи для роботи з DirectX 9.0. Для цього у вікні Solution Explorer нажмаем праву кнопку миші над елементом References і выбераем в меню, що з'явилося, пункт Add Reference.


Рис. 4.10 Вікно Solution Explorer


У вікні, що з'явилося, за допомогою кнопки Browse додамо в проект перераховані вище складки з каталога $LabFiles$\DirectX Assemblies.


Рис. 4.11 Вікно Add References

Пристрій Direct3D зручно створювати при першому показі вікна на екрані. Створюємо обробник події Load. Для цього у вікні властивостей вікна (форми) обираємо список подій. Для цього нажмаем кнопку із зображенням блискавки. У списку подій двічі нажмаем ліву кнопку миші на подію Load.


Рис. 4.12 Створюємо обробник події Load


Буде створений метод з ім'ям Form1_Load, код якого відразу ж відобразиться в редакторі.

До цього моменту весь код створювала за нас Visual Studio, тепер код доведеться писати самим . Значну допомогу в наборі довгих ідентифікаторів надає технологія Intellisense, що пропонує вибір методів, властивостей або полів даних об'єкту після набору символу «крапка»

На самому початку початкового тексту додаємо дві директиви using. Це дозволить звертатися до класів DirectX не указуючи кожного разу довгих префіксів просторів імен.

System.Data;

using Microsoft.DirectX;

using Microsoft.DirectX.Direct3D;


У класі Form1 додаємо поле даних типу Microsoft.Direct3D.Device для зберігання посилання на пристрій Direct3D.class Form1 : System.Windows.Forms.Form { .

Device d3d = null; // Пристрій для відображення 3D-графики

. }


У метод Form1_Load додаємо код для ініціалізації пристрою Direct3D. Для обробки можливих помилок код ініціалізації помістимо в блок try/catch (цей фрагмент коду можна узяти у файлі $LabFiles$\sources.cs).

void Form1_Load(object sender, System.EventArgs e) {

try {

// Встановлюємо режим відображення тривимірної графікиd3dpp = new PresentParameters();dpp.BackBufferCount = 1;dpp.SwapEffect = SwapEffect.Discard;dpp.Windowed = true;

// Виводимо графіку у вікноdpp.MultiSample = MultiSampleType.None;

// Вимикаємо антиалиасинг

d3dpp.EnableAutoDepthStencil = true;

// Вирішуємо створення z-буфера

d3dpp.AutoDepthStencilFormat = DepthFormat.D16;

// Z-буфер в 16 бітd = new Device(0, // D3D_ADAPTER_DEFAULT - відеоадаптер за умовчанням DeviceType.Hardware, // Тип пристрою - апаратний прискорювач this, // Вікно для виведення графіки.SoftwareVertexProcessing, // Геометрію обробляє CPU d3dpp);

}

catch(Exception exc){

MessageBox.Show(this,exc.Message,"Ошибка ініціалізації");

Close(); // Закриваємо вікно }

}


Хорошим тоном в програмуванні вважається своєчасне звільнення всіх раніше одержаних ресурсів. Звільнення пам'яті бере на себе автоматичний складальник сміття, а звільнення ресурсів Direct3D треба вказати явно. Для цього додаємо наступний код у вже існуючий віртуальний метод Dispose(bool disposing) класу Form1:

override void Dispose( bool disposing ){ if(disposing){

if(components != null){

components.Dispose(); }

// Звільняємо зайняті раніше ресурси if(d3d != null) d3d.Dispose();

} base.Dispose(disposing);

}


Тепер проект можна зібрати і запустити. Зовнішній вигляд вікна не зміниться, але малювання тривимірних об'єктів у вікні можна буде виконувати, викликаючи методи об'єкту d3d.


4.4.4 Додавання коду для створення зображень

У вікні властивостей выбераем список подій класу Form1 і додаємо обробник події Paint таким самим чином як і обробник події Load.


Рис. 4.13 Обробник події Paint


У метод Form1_Paint додаємо код, що очищає буфер глибини, заповнюючий дублюючий буфер темно зеленим кольором і що показує його на екран.

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) {

// Очищаємо буфер глибини і дублюючий буфер

}

d3d.Clear(ClearFlags.Target|ClearFlags.ZBuffer,Color.Green,1.0f,0);

//.Показываем вміст дублюючого буфераd.Present();


Після виконання даних кроків вікно додаток повинен виглядати таким чином.


Рис. 4.14 Вікно додатку

4.4.5 Створення тривимірного об'єкту

У конструкторі класу Form1 встановлюємо режим перемальовування вмісту вікна при будь-якій зміні розміру

Form1() { .

InitializeComponent();

SetStyle(ControlStyles.ResizeRedraw,true);


У клас Form1 додаємо поле даних teapot типу Mesh для зберігання посилання на полігональний об'єкт.


сlass Form1 { .

Mesh teapot = null; // Модель книги

У метод Form1_Load додаємо код, що створює полігональну модель книги.

private void Form1_Load(object sender, System.EventArgs e) .

d3d = new Device(.);

// Створюємо модель і задаємо її властивості= Mesh.Teapot(d3d);

У метод Dispose додаємо код, що звільняє зайняті для полігональної моделі ресурси Direct3D.override void Dispose(bool disposing){ .

if(teapot != null) teapot.Dispose();

if(d3d != null)d3d.Dispose();


У метод Form1_Paint додаємо код, що відображає книгу на екрані. Для цього необхідно задати перетворення для перспективного проектування координат з системи координат спостерігача на екран, задати перетворення з системи координат об'єкту в систему координат спостерігача і викликати метод для отрисовки полігональної моделі на екрані.

private void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) {

d3d.Clear(ClearFlags.Target|ClearFlags.ZBuffer,Color.Green,1.0f,0); .

// Починаємо отрисовку кадру d3d.BeginScene();

// Задаємо матрицю проектуванняd.Transform.Projection = Matrix.PerspectiveFovLH( (float)Math.PI/3,

// Точка зору/(float)Height, // Відношення висоти і ширини вікна 0.5f,25.0f);

// Діапазон зміни координати z

// Задаємо матрицю перетворення світових координат для книги:

// зрушення на 3.5 умовні одиниці :) по осі z від спостерігачаd.Transform.World = Matrix.Translation(0,0,3.5f);

// Малюємо книгу

teapot.DrawSubset(0);

// Завершуємо отрисовку кадруd.EndScene();d.Present(); }


Після виконання цих дій у вікні повинен з'явиться силует книги.


Рис. 4.15 Силует книги

4.4.6 Джерела освітлення

Для підкреслення тривимірності об'єкту можна включити джерело освітлення. У клас Form1 додаємо поле даних teapotMaterial типу Material для зберігання властивостей поверхні книги.


сlass Form1 { .

Mesh teapot = null; // Модель книги

Material teapotMaterial; // Матеріал

. }


У метод Form1_Load додаємо код, задаючий колір дифузного (розсіяного) і дзеркального віддзеркалення для матеріалу книги.

void Form1_Load(object sender, System.EventArgs e) { .

// Створюємо модель книги і задаємо її властивості= Mesh.Teapot(d3d);

teapotMaterial = new Material();.Diffuse = Color.Blue;

teapotMaterial.Specular = Color.White;

. }


Клас, а точніше, структура Material не містить посилань на об'єкти Direct3D, тому звільнення матеріалів в методі Dispose не потрібне.

У методі Form1_Paint задаємо положення і властивості одного джерела освітлення. Перед малюванням книги встановлюємо матеріал для розрахунку освітлення полігональної моделі.

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) { .

d3d.BeginScene();

// Встановлюємо параметри джерела освітленняd.Lights[0].Enabled = true;

// Включаємо нульове джерело освітленняd.Lights[0].Diffuse = Color.White;

// Колір джерела освітлення

d3d.Lights[0].Position = new Vector3(0,0,0);

// Задаємо координати .d.Material = teapotMaterial;

// Встановлюємо матеріал для книги

teapot.DrawSubset(0); . }


Після виконання даних дій модель книги набуває об'ємного вигляду.


Рис. 4.16 Книга набуває об'ємного вигляду


4.4.7 Зміна точки зору на обєкт

На цьому кроці до тривимірної сцени буде додана анімація. Спершу необхідно організувати постійне перемальовування вікна. Для цього можна скористатися механізмом фонової обробки (idle processing). Як тільки додаток обробив всі повідомлення і чергу повідомлень опинилася порожня, викликається подія Application.Idle. Якщо обробник цієї події помітить головне вікно як що вимагає оновлення, то в чергу подій додатку майже відразу буде поміщений запит на перемальовування вікна (повідомлення WM_PAINT), який приведе до перемальовування вікна і, зокрема, до виклику методу Form1_Paint. Після обробки запиту на перемальовування вікна черга повідомлень знов опиниться порожня і буде викликана подія Idle, обробник якої знов помітить головне вікно додатку як що вимагає оновлення і т.д. Для реалізації цієї схеми додайте до класу Form1 наступний метод OnIdle.

Form1 { .

private void OnIdle(object sender,EventArgs e){

Invalidate(); // Позначаємо головне вікно (this) як що вимагає перемальовування }

. }


Для того, щоб пов'язати метод OnIdle з подією Application.Idle необхідно зрадити код методу Main, з якого починається виконання програми.

void Main() {

// Створюємо об'єкт-вікноmainForm = new Form1();

// Cвязываем метод OnIdle з подією Application.Idle

Application.Idle += new EventHandler(mainForm.OnIdle);

// Показуємо вікно і запускаємо цикл обробки повідомлень.Run(mainForm);

}


Якщо тепер зібрати і запустити проект, то в головному вікні спостерігатиметься неприємне мерехтіння. Це пов'язано з взаємодією подвійної буферизації Direct3D і отрисовки фону вікна. Щоб позбавитися цього неприємного ефекту додаємо в конструктор класу Form1 код для установки відповідного режиму перемальовування вікна.

public Form1() { .

SetStyle(ControlStyles.ResizeRedraw,true);

// Встановлюємо режим оновлення вікна

SetStyle(ControlStyles.Opaque,true);

SetStyle(ControlStyles.UserPaint,true); SetStyle(ControlStyles.AllPaintingInWmPaint,true);

}


Для того, щоб швидкість анімації не залежала від продуктивності комп'ютера, запам'ятаємо час почала анімації в полі даних класу Form1. Тоді при кожному перемальовуванні вікна можна визначити скільки часу пройшло від початку перемальовування і зрадити положення і стан об'єктів відповідним чином.

Додаємо поле даних з ім'ям startTime типу DateTime в клас Form1 для зберігання часу почала анімації.


сlass Form1 { .startTime; // Час почала анімації

. }

Ініціалізували цю змінну в кінці блоку try/catch в методі Form1_Load.void Form1_Load(object sender, System.EventArgs e) { try { .

startTime = DateTime.Now; // Засікаємо час почала анімації

}(Exception exc){

. } }


У початок методу Form1_Paint додаємо код для обчислення часу в секундах, що пройшов з моменту початку анімації до початку отрисовки поточного кадру.void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) {

// Заміряємо інтервал часу між отрисовкой цього кадру і початком анімації

DateTime currTime = DateTime.Now;

TimeSpan totalTime = currTime - startTime;

double totalSeconds = totalTime.TotalSeconds;

. }


Для обертання книги досить задавати матрицю перетворення світових координат залежно від значення змінної totalSeconds. Заводимо в класі Form1 дві константи типу double, визначальні частоту обертання (оборотов/c) книги навколо осей OX і OY.


сlass Form1 {double TeapotRotationX = 0.2;double TeapotRotationY = 0.3;

}


Змінюємо в методі Form1_Paint код для обчислення матриці перетворення світових координат, як твори перетворень обертання і перенесення. Перед малюванням книги можна відключити відсікання нелицьових граней, встановивши властивість d3d.RenderState.CullMode рівним Сull.None.

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) {

// Відключаємо відсікання нелицьових граней

d3d.RenderState.CullMode = Cull.None;

// Задаємо матрицю перетворення для книги

d3d.Transform.World =.RotationX((float)(totalSeconds*TeapotRotationX*2*Math.PI))* Matrix.RotationY((float)(totalSeconds*TeapotRotationY*2*Math.PI))* Matrix.Translation(0,0,3.5f);

. }


Після виконання цих дій книги повинен почати плавно обертатися навколо двох осей.


Рис. 4.17 Обертання навколо двох осей


4.4.8 Додання в сцену обєктів

На цьому кроці в сцену будуть додані прості об'єкти, що обертаються навколо книги. Додаємо в клас Form1 поля даних для зберігання цих об'єктів і параметрів їх руху.


сlass Form1 { .[] objects = new Mesh[10];

// Моделі об'єктів, що обертаються[] objectMaterials = new Material[3];

// Матеріал об'єктів const double OrbitRadius = 1.5;

// Радіус орбіти обертання навколо книги

const double RotationFreq = 0.4;

// Частота обертання по орбіті.

. }


У метод Form1_Load додаємо код, що створює моделі об'єктів, а саме полігональні апроксимації сфер радіусом 0.05, і задаючий властивості матеріалів.

void Form1_Load(object sender, System.EventArgs e) { .

// Створюємо моделі об'єктів, що обертаються навколо книги

// і задаємо властивості матеріалів(int i = 0;i<objects.Length;i++) objects[i]= Mesh.Sphere(d3d,

0.05f, // Радіус сфери

, // Кількість паралелей

); // Кількість меридіанів[0].Diffuse = Color.Red;

objectMaterials[1].Diffuse = Color.LightGreen;

objectMaterials[2].Diffuse = Color.LightBlue;

. }


Клас Microsoft.Direct3D.Mesh містить посилання на ресурси Direct3D, що вимагають явного звільнення. Тому в метод Dispose класу Form1 додаємо код для звільнення всіх ресурсів полігональних моделей їх масиву objects. Для зручнішого і незалежного від довжини масиву переліку його елементів застосуєте оператора foreach.

override void Dispose(bool disposing){ .

foreach(Mesh m in objects) if(m != null) m.Dispose();

if(d3d != null)d3d.Dispose(); . }

У методі Form1_Paint відображаємо створені об'єкти на екран. Для кожного об'єкту з масиву objects буде задана своя матриця перетворення світових координат, що здійснює обертання об'єктів навколо книги. При цьому кожен об'єкт обертається в своїй площині. Сфери є опуклими об'єктам, тому для зменшення об'єму обчислень відсікання нелицьових граней можна включити (цей фрагмент коду також можна узяти з файлу $LabFiles$\sources.cs).

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) { .

d3d.Transform.Projection = Matrix. PerspectiveFovLH(.)

// Включаємо відсікання нелицьових гранейd.RenderState.CullMode = Cull.CounterClockwise;

// У циклі малюємо всі об'єктиnumObjects = objects.Length; for(int i = 0;i<numObjects;i++){

// Задаємо наступне перетворення координат:

// Зрушуємо об'єкт на радіус орбіти

// обертаємо об'єкт на залежний від часу кут

// повертаємо площину обертання на кут, залежний від номера

// об'єкту і суміщаємо центр орбіт об'єктів з центром книгиа = i/(double)numObjects;

d3d.Transform.World = Matrix.Translation(0,0,(float) OrbitRadius)*

Matrix.RotationY((float)(2*Math.PI*(а + totalSeconds*RotationFreq)))*

Matrix.RotationZ((float)(Math.PI*a)*

Matrix.Translation(0,0,3.5f);

// Задаємо матеріал і малюємо i-й об'єктd.Material = objectMaterials[i % objectMaterials.Length];

objects[i].DrawSubset(0); }

. }

Тепер навколо книги обертаються декілька різноколірних сфер.


Рис. 4.18 Моделі об'єктів, що обертаються


4.4.9 Накладення текстури

Створюємо в класі Form1 змінну з ім'ям teapotTexture типу Texture для зберігання посилання на текстуру книги.


сlass Form1 { .teapot = null; // Модель книгиteapotMaterial; // Матеріал з якого виготовлений книгиteapotTexture = null; // Текстура для книги


Текстура буде завантажена з файлу. Класи для роботи з потоками даних (у тому числі і з файлами) знаходяться в просторі імен System.IO. Для того, щоб не указувати цей префікс при кожному зверненні до відповідних класів, додаємо в початок початкового тексту директиву using System.IO.

System.Data; using System.IO;


Як і багато інших об'єктів Direct3D, текстури зручно створювати при першому показі вікна на екран і необхідно явно звільняти, коли вони більше не потрібні. Код для завантаження текстури з файлу додайте в метод Form1_Load.

void Form1_Load(object sender, System.EventArgs e) { .

// Завантажуємо текстуру для книги з файлу з ім'ям spheremap.bmp(FileStream textureFile = new FileStream("spheremap.bmp",FileMode.Open)) {= Texture.FromStream(d3d,, // Потік даних з текстурою 0,

// використовуватимемо як звичайну текстуру.Managed); // Область пам'яті для розміщення текстури textureFile.Close(); }

Код для звільнення текстури розміщуємо в методі Dispose класу Form1.override void Dispose(bool disposing){ .(teapotTexture != null) teapotTexture.Dispose();(Mesh m in objects).; . }


Як ім'я файлу з текстурою був вказаний рядок «spheremap.bmp». Для того, щоб додаток знайшов цей файл скопіюємо з каталога $LabFiles$ його в кореневий каталог проекту (де лежить файл DXApp.sln).

Встановлюємо цей каталог як поточний каталог для запуску додатку. Для цього у вікні Solution Explorer нажмаем праву кнопку миші над елементом з ім'ям проекту (у нашому випадку це DXApp). У меню, що з'явилося, виберіть пункт Properties.


Рис. 4.19 Вікно Solution Explorer


На екрані з'явиться вікно властивостей проекту. У розташованому зліва ієрархічному списку выбераем розділ Configuration properties/Debugging, в розташованому справа списку установливаем у властивості Working directory вкажіть кореневий каталог проекту.


Рис. 4.20 Розділ Configuration properties/Debugging


Створена засобами Direct3D модель книги не містить координат текстури. Тому текстуровані координати (u,v) обчислюватимуться виходячи їх вектора нормалі [nx,ny,nz ]по наступним формулам u = 0.5(nx +1), v = 0.5(ny +1) що створює ілюзію відзеркалювальної поверхні.

У методі Form1_Paint безпосередньо перед малюванням книги додаємо код, що включає текстурирование і що встановлює відповідні режими текстурирования. Вимикаємо текстурирование перед малюванням сфер, що обертаються навколо книги.

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) { .

// Вимикаємо текстурированиеd.SetTexture(0,null);numObjects = objects.Length; for(int i = 0;i<numObjects;i++){

. } .

// Як текстуровані координати беремо вектор нормаліd.TextureState[0].TextureCoordinateIndex =

(int)TextureCoordinateIndex.CameraSpaceNormal; // Перетворимо текстуровані координати по заданих формулахd.Transform.Texture0 = Matrix.Scaling(0.5f,-0.5f,1.0f)*.Translation(0.5f,0.5f,0.0f);

// Передаємо блоку растеризации дві текстуровані координатиd.TextureState[0].TextureTransform = TextureTransform.Count2;

// Встановлюємо текстурк d3d.SetTexture(0,teapotTexture);

// Встановлюємо властивості матеріалу і малюємо чайник d3d.Material = teapotMaterial; teapot.DrawSubset(0);


Головне вікно додатку тепер повинне виглядати таким чином.



Рис. 4.21 Вікно додатку


Якщо уважно розглядати одержане динамічне зображення, то можна відмітити, що в деякі моменти часу при деяких положеннях об'єкту на текстурі виникають явно помітні прямокутні елементи. Для позбавлення від цього ефекту включаємо билинейную фільтрацію текстур, додавши наступний код перед малюванням книги в методі Form1_Paint

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) { .

// Включаємо билинейную фільтрацію текстурd.SamplerState[0].MinFilter = TextureFilter.Linear;d.SamplerState[0].MagFilter = TextureFilter.Linear;.DrawSubset(0);


4.4.10 Створення фону

На цьому кроці до сцени буде доданий фон. Або точніше, сцена разом із спостерігачем буде поміщена всередину текстурированного тора. Додаємо до класу Form1 поля даних для зберігання посилань на тор і на текстуру для тора (аналогічно полям даних для книги і її текстури).


сlass Form1 { .torus = null;

// Тор, усередині якого знаходиться спостерігачtorusTexture = null;

// Текстура для тора


У метод Form1_Load додаємо код для створення полігональної моделі тора і завантаження текстури для нього. Цей код також буде схожий на код для створення моделі книги.

void Form1_Load(object sender, System.EventArgs e) { .

// Завантажуємо модель тора з файлу з ім'ям torus.x= Mesh.FromFile("torus.x",.Managed,

// Область пам'яті для розміщення геометріїd);

// Завантажуємо текстуру для тора з файлу з ім'ям water.bmp(FileStream textureFile2 =FileStream("water.bmp",FileMode.Open))

{ torusTexture = Texture.FromStream(d3d,, // Потік даних з текстурою 0

// Використовуватимемо як звичайну текстуру.Managed);

// Область пам'яті для розміщення текстури.Close(); }

Скопіюємо в кореневий каталог проекту файли torus.x і water.bmp.

Точно також, як було зроблено для моделі книги, ресурси, зайняті для моделі і текстури тора, необхідно звільнити в методі Dispose.

protected override void Dispose(bool disposing){ .(torusTexture != null).Dispose();(torus != null) torus.Dispose();

Добавяєм код для малювання тора в метод Form1_Paint. Послідовність дій повністю аналогічна вживаною раніше: задається перетворення координат і настройки для освітлення і текстурирования. Потім отрисовывается сам об'єкт. Код для малювання тора відрізняється тим, що текстуровані координати беруться з геометричних даних моделі. Також при малюванні тора відключається розрахунок інтенсивності освітлення, оскільки на торі не задані вектори нормалей.

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) { ..DrawSubset(0);

// Встановлюємо перетворення координат для тораd.Transform.World = Matrix.Scaling(10,10,10)*.RotationZ((float)(Math.PI/2))*.Translation(0-12,0)*

// Включаємо згортку текстурованих координат для правильного відображення

// текстурированного тораd.RenderState.Wrap0 = WrapCoordinates.One|WrapCoordinates.Zero;

// Одержуємо текстуровані координати з даних моделіd.TextureState[0].TextureCoordinateIndex =

(int)TextureCoordinateIndex.PassThru;

// Встановлюємо текстуру для тораd.SetTexture(0,torusTexture);

// Вимикаємо перетворення текстурованих координатd.TextureState[0].TextureTransform = TextureTransform.Disable;

// Вимикаємо розрахунок освітленняd.RenderState.Lighting = false;

// Малюємо тор.DrawSubset(0);

// Включаємо розрахунок освітленняd.RenderState.Lighting = true;


Зовнішній вигляд вікна після виконання даних кроків показаний на наступному рисунку.


Рис. 4.22 Вікно додатку з фоном


4.4.11 Динамічна зміна фону

На попередньому кроці матриця перетворення текстурованих координат використовувалася для зрушення і масштабування координат векторів нормалей. Вирішивши перетворення текстурованих координат для тора і змінюючи матрицю перетворення текстурованих координат можна добитися цікавого ефекту рухомого фону.

У методі Form1_Paint додаємо наступний код замість рядка, в якому властивості TextureTransform привласнюється значення TextureTransform.Disable.

void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e) { .

// Встановлюємо текстуру для тораd.SetTexture(0,torusTexture);

// Обчислюємо зрушення текстурованих координатdeltaTex = totalSeconds*0.2;

// Приводимо його до діапазону [0..1]-= Math.Floor(deltaTex);

// Задаємо матрицю зрушення для двох текстурованих координатtexMatrix = Matrix.Identity;.M31 = (float)-deltaTex;.M32 = (float)-deltaTex;

// Застосовуємо матриці для перетворення текстурованих координатd.Transform.Texture0 = texMatrix;

// Вимикаємо розрахунок освітленняd.RenderState.Lighting = false;

// Малюємо тор.DrawSubset(0);

// Включаємо розрахунок освітленняd.RenderState.Lighting = true;


Після виконання цього кроку фон у вікні додатку повинен почати рухатися


Рис. 4.23 Остаточний вид створеного додатку


5. Економічне обґрунтування доцільності розробки програмного продукту


Визначення витрат на створення програмного продукту

Оскільки середа розробки є безкоштовною, витрати на створення програмного продукту складаються з витрат по оплаті праці розробника програми і витрат по оплаті машинного часу при відладці програми:


Зспп=Ззпспп +Змвспп+Зобщ,


де

Зспп - витрати на створення програмного продукту;

Ззпспп - витрати на оплату праці розробника програми;

Змвспп - витрати на оплату машинного часу;

Зобщ - загальні витрати.

Витрати на оплату праці розробника програми (Ззпспп) визначаються шляхом множення трудомісткості створення програмного продукту на середню годинну оплату програміста (з урахуванням коефіцієнта відрахувань на соціальні потреби):


Ззпспп=tTчас.


Розрахунок трудомісткості створення програмного продукту.

Трудомісткість розробки програмного продукту можна визначити таким чином:


t= to+ tа+ tб+ tп+ tд+ tот,


деo - витрати праці на підготовку опису завдання;а - витрати праці на розробку алгоритму рішення задачі;б - витрати праці на розробку блок-схеми алгоритму рішення задачі;п - витрати праці на складання програми по готовій блок-схемі;д - витрати праці на підготовку документації завдання;от - витрати праці на відладку програми на ЕОМ при комплексній відладці завдання.

Складові витрат можна виразити через умовне число операторів Q. У нашому випадку число операторів у відлагодженій програмі Q=1050.

Розрахунок витрат праці на підготовку опису завдань.

Оцінити витрати праці на підготовку опису завдання не можливо, оскільки це пов'язано з творчим характером роботи, натомість оцінимо витрати праці на вивчення опису завдання з урахуванням уточнення опису і кваліфікації програміста:

o= QB/(75…85K),


где- коефіцієнт збільшення витрат праці унаслідок недостатнього опису завдання, уточнень і деякої недоробки, B=1,2…5;- коефіцієнт кваліфікації розробника, для тих, що працюють до 2 років K=0,8;

Коефіцієнт В приймаємо рівним 2.

Таким чином отримаємо


to= 10502/(780,8) = 33,65 (люд-год).


Розрахунок витрат праці на розробку алгоритму.

Витрати праці на розробку алгоритму рішення задачі:


tа = Q/(60…75K)а = 1050/(700,8)=18,75 (люд-год).


Розрахунок витрат праці на розробку блок-схеми.

Витрати праці на розробку блок-схеми алгоритму рішення задачі обчислимо таким чином:


tб= Q/(60…75K)б = 1050/(710,8)=18,48 (люд-год).


Розрахунок витрат праці на складання програми.

Витрати праці на складання програми по готовій блок-схемі обчислимо таким чином:


tп= Q/(60…75K)п = 1050/(720,8)=18,23 (люд-год).


Розрахунок витрат праці на відладку програми.

Витрати праці на відладку програми на ЕОМ при комплексній відладці завдання:


tот=1.5 tAот,


де tAот - витрати праці на відладку програми на ЕОМ при автономній відладці одного завдання;


tAот= Q/(40…50K)Aот = 1050/(480,8)=27,34 (люд-год)


Звідси tот=1.527,34=41,01 (люд-год).

Розрахунок витрат праці на підготовку документації.

Витрати праці на підготовку документації по завданню визначаються:


tд= tдр+ tдо,


дедр - витрати праці на підготовку матеріалів в рукопису;до - витрати на редагування, друк і оформлення документації;


tдр= Q/(150…200K)др = 1050/(1800.8) = 7,29 (люд-год)до=0.75tдр

tдо =0.757,29=5,47 (люд-год)


Звідси


tд=7,29+5,47=12,76 (люд-год).


Отже, загальну трудомісткість програмного продукту можна розрахувати:


t = 33,65 +18,75 +18,48+18,23 +41,01+12,76 =142,88 (люд-год).


Розрахунок середньої зарплати програміста.

Середня зарплата програміста в сучасних ринкових умовах може варіюватися в широкому діапазоні. Для розрахунку візьмемо середню годинну оплату праці, яка складає Тчас.=8 грн/година, що означає 1408 грн/міс при 8-ми годинному робочому дні і 5-ти денному робочому тижню.

Витрати на оплату праці програміста складаються із зарплати програміста і нарахувань на соціальні потреби. Нарахування на соціальні потреби включають:

,2% - пенсійний фонд;

,4% - соціальне страхування;

.6% - відрахування до державного фонду зайнятості на випадок безробіття;

% - на соціальне страхування від нещасного випадку на виробництві і професійних захворювань, які спричинили втрату працездатності.

Разом нарахування на соціальні потреби складають 37,2%.

Тобто 1408грн37,2%=520,96 грн

Звідси витрати на оплату праці програміста складають:


Ззпспп= 1408+520,96=1928,96 грн.


Витрати на оплату машинного часу. Витрати на оплату машинного часу при відладці програми визначаються шляхом множення фактичного часу відладки програми на ціну машино-години орендного часу:


Змвспп =СчасtЕОМ,


де

Счас - ціна машино-години орендного часу, грн/год;ЕОМ - фактичний час відладки програми на ЕОМ;

Розрахунок фактичного часу відладки.

Фактичний час відладки обчислимо за формулою:


tеом = tп + tдо + tот ;еом =18,23 +5,47 +41,01 = 64,71 години

Розрахунок ціни машино-години.

Ціну машино-години знайдемо по формулі:


Сгод = Зеом/Теом,


де

Зеом - повні витрати на експлуатацію ЕОМ на протязі року;

Теом - дійсний річний фонд часу ЕОМ, год/рік.

Розрахунок річного фонду часу роботи ПЕОМ.

Загальна кількість днів в році - 365. Число святкових і вихідних днів - 114(10 святкових і 522- вихідні).

Час простою в профілактичних роботах визначається як щотижнева профілактика по 3 години.

Разом річний фонд робочого часу ПЕОМ складає:


Теом = 8(365-114)-523=1852 год.


Розрахунок повних витрат на експлуатацію ЕОМ.

Повні витрати на експлуатацію можна визначити по формулі:


Зеом = (Ззп+ Зам+ Зэл+ Здм+ Зпр+ Зін),


де,

Ззп - річні витрати на заробітну плату обслуговуючого персоналу, грн/рік;

Зам - річні витрати на амортизацію, грн/рік;

Зэл - річні витрати на електроенергію, споживану ЕОМ, грн/рік;

Здм - річні витрати на допоміжні матеріали, грн/рік;

Зпр - витрати на поточний ремонт комп'ютера, грн/рік;

Зін - річні витрати на інші і накладні витрати, грн/рік.

Амортизаційні відрахування.

Річні амортизаційні відрахування визначаються по формулі:


Зам=СбалНам,


де Сбал - балансова вартість компютера, грн/шт.;

Нам - норма амортизації, %;

Нам =25%.

Балансова вартість ПЕОМ включає відпускну ціну, витрати на транспортування, монтаж устаткування і його відладку:


Сбал = Срин +Зуст ;


де

Срин - ринкова вартість компютеру, грн/шт.,

Зуст - витрати на доставку і установку комп'ютера, грн/шт;

Комп'ютер, на якому велася робота, був придбаний за ціною

Срин =5000 грн, витрати на установку і наладку склали приблизно 10% від вартості комп'ютера.


Зуст = 10% Срин

Зуст =0.15000=500 грн.


Звідси, Сбал = 5000 +500 =5500 грн./шт.;


а Зам=55000,25= 1375 грн/год.


Розрахунок витрат на електроенергію.

Вартість електроенергії, споживаної за рік, визначається по формулі:

Зел = Реом Теом Сел А,


де

Реом - сумарна потужність ЕОМ,

Теом - дійсний річний фонд часу ЕОМ, год/рік;

Сел - вартість 1кВтгод електроенергії;

А - коефіцієнт інтенсивного використання потужності машини.

Згідно технічному паспорту ЕОМ Реом =0.22 кВт, вартість 1кВтгод електроенергії для споживачів Сел =0,2436 грн., інтенсивність використання машини А=0.98.

Тоді розрахункове значення витрат на електроенергію:


Зел = 0.22 1852 0.2436 0.30 = 29,78 грн.


Розрахунок витрат на поточний ремонт.

Витрати на поточний і профілактичний ремонт приймаються рівними 5% від вартості ЕОМ:


Зтр = 0.05 Сбал

Зтр = 0.05 5500 = 275 грн.


Розрахунок витрат на допоміжні матеріали.

Витрати на матеріали, необхідні для забезпечення нормальної роботи ПЕОМ, складають близько 1 % від вартості ЕОМ:


Звм =0,01 5500 =55 грн.


Інші витрати по експлуатації ПЕОМ.

Інші непрямі витрати, пов'язані з експлуатацією ПЕОМ, складаються з вартості послуг сторонніх організацій і складають 5% від вартості ЕОМ:


Зпр = 0,05 5500 =275 грн.


Річні витрати на заробітну плату обслуговуючого персоналу.

Витрати на заробітну плату обслуговуючого персоналу складаються з основної заробітної плати, додаткової і відрахувань на заробітну плату:


Ззп = Зоснзп +Здопзп +Зотчзп.


Основна заробітна плата визначається, виходячи із загальної чисельності тих, що працюють в штаті:


Зоснзп =12 ?Зіокл,


де

Зіокл - тарифна ставка і-го працівника в місяць, грн;

- кількість місяців.

У штат обслуговуючого персоналу повинні входити інженер-електронщик з місячним окладом 1500 грн. і електрослюсар з окладом 1200 грн. Тоді, враховуючи, що даний персонал обслуговує 20 машин, маємо витрати на основну заробітну плату обслуговуючого персоналу, які складуть:


Зоснзп = 12(1500+1200)/20=1620 грн.


Додаткова заробітна плата складає 60 % від основної заробітної плати:


Здопзп = 0.6 1620 = 972 грн.


Відрахування на соціальні потреби складають 37,2% від суми додатковою і основною заробітних плат:


Зотчзп = 0,372(1620 + 972) = 959,04 грн.


Тоді річні витрати на заробітну плату обслуговуючого персоналу складуть:


Ззп = 1620 +972 +959,04 = 3551,04 грн.


Повні витрати на експлуатацію ЕОМ в перебігу року складуть:


Зеом = 3551,04 + 1375+ 29,78 + 55 + 275+ 275= 5560,82 грн.


Тоді ціна машино-години часу, що орендується, складе


Сгод = 5560,82 /1852 = 3 грн.


А витрати на оплату машинного часу складуть:


Змвспп =Сгодtеом

Змвспп = 3 64,71= 194,13 грн.


Розрахунок загальних витрат.

Загальні витрати - 643


Зспп=Ззпспп +Змвспп+Ззаг

Зспп =1928,96+194,13 +643=2766,09 грн.


Тобто собівартість програмного продукту 2766,09 грн.

А зараз визначимо ціну програмного продукту:


Ц = Зспп + Р,


Где Ц - ціна програмного продукту;

Р - 15% від витрат на створення програмного продукту.


Ц = 2766,09 +414,91=3181 грн.


Ціна програмного продукту дорівнює 3181 грн.

В порівнянні з іншими програмними продуктами, які виконують аналогічні функції та мають вартість орієнтовно $1000, розроблена програма за умови тиражування обійдеться значно дешевше, ніж аналоги.

Економія від використання однієї розробленої програми представлятиме:

,7 - курс долара Національного банку України


ЕК = $1000 * 7,7-3181= 4519 грн.


6. Охорона праці


Охорона праці - система законодавчих актів, постанов, організаційних, санітарних, технічних мір, що забезпечують безпечні для здоров'я умови праці на робочому місці. Науково-технічний прогрес вніс зміни в умови виробничої діяльності працівників розумової праці. Їхня праця стала більш інтенсивною, напруженою, потребуює витрат розумової, емоційної й фізичної енергії.

Це має пряме відношення до фахівців, пов'язаних із проектуванням, розробкою, експлуатацією, супроводом і модернізацією автоматизованих систем керування різного призначення.

На робочому місці користувача повинні бути створені умови для високопродуктивної праці. У цьому розділі будуть розглянуті основні фактори, що на ці умови мають вплив та необхідні заходи, згідно законодавства, направлені на поліпшення умов праці. У цей час все більше застосування знаходять автоматизовані робочі місця, які оснащуються персональною ЕОМ і графічним дисплеєм, клавіатурою і принтером, тому охорона праці у цій галузі має свої особливості.

Законодавство України про охорону праці базується на:

Конституція України, яка гарантує права громадян на працю, відпочинок, охорону здоровя, медичну допомогу і страхування;

Закон України „Про охорону праці», де вказано, що державна політика в області охорони праці базується на пріоритеті життя і здоровя людей в умовах їх трудової діяльності. Відповідальність за створення нормальних і безпечних умов труда несе роботодавець незалежно від форми власності підприємства чи установи які здійснюють розробку виробництва та застосування ПЕОМ і ПК;

Норми штучного та природного освітлення визначені СНіП;

Закон України „Про забезпечення санітарного та епідемічного благополуччя населення» де вказані основні вимоги гігієни та санітарії;

Параметри мікроклімату на робочих місцях регламентовані Держстандартом і ДСН;

Категорія робіт по величині загальних енерговитрат встановлена ДСН;

Закон України „Про загальнообовязкове державне соціальне страхування від нещасного випадку на виробництві та професійного захворювання, які спричинили втрату працездатності», який гарантує право трудящих на соціальний захист і компенсацію постраждалим матеріальних втрат при травмуванні і професійного захворювання;

Кодекс законів про працю (КЗпП) де викладені окремі вимоги охорони праці;

Пожежна безпека викладена в законі України „Про пожежну безпеку» і „Правила про пожежну безпеку в Україні»

Крім того є ряд Державних стандартів, правил, норм, інструкцій та інших нормативних документів, регламентуючих питання охорони праці.


6.1 Аналіз шкідливих і небезпечних виробничих факторів при роботі на компютері


Фактори виробничого середовища впливають на функціональний стан і працездатність оператора. Наразі загальноприйнятою є класифікація небезпечних і шкідливих чинників, які згідно ДОСТ 12.0.003-74 по характерним видам дій на організм людини, підрозділяються на фізичні, хімічні, біологічні і психофізіологічні.

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

Оператор ЕОМ може зіштовхнутися з наступними фізично небезпечними й шкідливими факторами: несприятнливий мікроклімат робочої зони, підвищений рівень шуму на робочому місці, підвищений рівень електромагнітних випромінювань, відсутність або недолік природного світла, недостатня освітленість робочої зони, підвищена яскравість світла, знижена контрастність, підвищена пульсація світлового потоку, підвищений рівень статичної електрики, підвищена напруженість магнітного поля.

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

Значним фізичним фактором є мікроклімат робочої зони, особливо температура й вологість повітря.

Згідно з інструкцією по проектуванню будівель і приміщень для електронно-обчислювальних СН 512-78 будівлі і приміщення для ЕОМ повинні бути обладнані системами центрального опалювання, кондиціонування повітря, протипожежного водопроводу, гарячого водопостачання, каналізації.

Мікроклімат на робочому місці характеризується: температурою, відносною вологістю, швидкість руху повітря на робочому місці, інтенсивністю теплового випромінювання, барометричним тиском.

Відповідно до ДОСТ 12.1.005-88 нормовані параметри мікроклімату підрозділяються на оптимальні і допустимі.

Оптимальні параметри мікроклімату - таке поєднання температури, відносної вологості і швидкості повітря, яке при тривалій і систематичній дії не викликає відхилень в стані людини.

Допустимі параметри мікроклімату - таке поєднання параметрів мікроклімату, яке при тривалій дії викликає тимчасові зміни в стані людини.

Норми мікроклімату зазначені у санітарних нормах мікроклімату виробничих приміщень ДСН 3.3.6.042-99.

Шум - це безладне поєднання звуків різної частоти і інтенсивності. Шум виникає при механічних коливаннях в твердих, рідких і газоподібних середовищах. Механічні коливання з частотами 20 - 20 000 Гц сприймаються слуховим апаратом у вигляді чутного звуку. Коливання з частотою нижче 20 і вище 20 000 Гц не викликають слухових відчуттів, але надають шкідливу біологічну дію на організм людини. Шум погіршує умови праці, впливаючи на організм людини. При тривалому впливі шуму на організм людини відбуваються небажані явища: знижується гострота зору, слуху, підвищується кров'яній тиск, знижується увага. Сильний тривалий шум може бути причиною функціональних змін серцево-судинної й нервової систем, що приводить до захворювань серця й підвищеної нервозності.

Раціональне освітлення є одним з найважливіших чинників попередження травматизму і професійних захворювань. Правильно організоване освітлення створює сприятливі умови праці, підвищує працездатність і продуктивність праці. Освітленість виробничих, службових і допоміжних приміщень регламентується будівельними нормами і правилами (СНіП II-4-79) і галузевими нормами.

Освітлення на робочому місці повинне бути таким, щоб працівник міг без напруги зору виконувати свою роботу. Стомлюваність органів зору залежить від ряду причин - недостатність освітленості, надмірна освітленість, неправильний напрям світла.

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

Для штучного освітлення використовуються електричні лампи накалу і люмінесцентні лампи. Люмінесцентні лампи в порівнянні з лампами накалу мають істотні переваги: по спектральному складу світла вони близькі до природного денного освітлення, мають вище ККД, підвищений термін служби.

Шкідливий вплив на людину має електромагнітне поле. Електромагнітне поле великої інтенсивності призводить до перегріву тканин, впливає на органи зору і органи статевої сфери.

Нормованим параметром електромагнітного поля в діапазоні частот 60 КГц - 300 МГц, згідно з ДОСТ 12.1.006-84, є граничне допустиме значення складових напруг електричних і магнітних полів.

Перевищення цих значень призводить до виникнення депресії, стресового стану, головного болю, безсоння, подразнення шкіри, хвороби суглобів і розвиток синдрому "хронічної втоми". Тривале знаходження людини в полі системного блоку комп'ютера негативно впливає на його психіку. Рівень цих полів зазвичай перевищує біологічно безпечний, причому їх випромінювання впливає на людину на відстані до 2,5 м від передньої панелі системного блоку.

Спектр випромінювання комп'ютерного монітора містить у собі рентгенівську, ультрафіолетову й інфрачервону області, а також широкий діапазон електромагнітних хвиль інших частот. Електромагнітні хвилі мають незвичайну властивість: небезпека їхнього впливу зовсім не обов'язково зменшується при зниженні інтенсивності опромінення, певні електромагнітні поля діють на клітини лише при малих интенсивностях випромінювання або на конкретних частотах.

Дози ультрафіолету не можуть викликати катаракту навіть при дії на протязі всього життя. Після тривалої роботи з комп'ютером можуть виникати такі неприємні відчуття, як "роздратування" очей (червоність, сльозотеча або сухість рогівки), стомлення (загальна втома, біль і тяжкість в очах і голові), труднощі при фокусуванні зору. Можливі також болі в спині і м'язові спазми.

Зорове навантаження зростає через необхідність постійного переміщення погляду з екрану на клавіатуру і паперовий текст.

Людина дистанційно не може визначити, чи знаходиться установка під напругою чи ні. Можливість отримання електротравм має місце не тільки при дотику, але і через напругу кроку і через електричну дугу.

Електричний струм, проходячи через тіло людини надає термічну дію, яка приводить до набряків (від почервоніння, до обвуглювання), електролітичних(хімічне), механічних, які можуть призвести до розриву тканин і м'язів; тому всі електротравми діляться на місцеві і загальні.

Крайній випадок - стан клінічної смерті (зупинка роботи серця і порушення постачання киснем клітин мозку). В стані клінічної смерті знаходяться до 6-8 хв.

Причини поразки електричним струмом (напруга дотику і крокова напруга): дотик до частин, що знаходяться під напругою; дотик до відключених частин, на яких напруга може мати місце у разі залишковому заряді, у разі помилкового включення електричної установки або неузгоджених дій обслуговуючого персоналу, у разі розряду блискавки в електричну установку або поблизу. Також може бути поразка напругою кроку або перебування людини в полі розтікання електричного струму, у разі замикання на землю, поразка через електричну дугу при напрузі електричної установки вище 1кВ, при наближенні на неприпустимо-малу відстань, дія атмосферної електрики при газових розрядах, звільнення людини, що знаходиться під напругою.

Напруга дотику - це різниця потенціалів точок електричного ланцюга, яких людина торкається одночасно, зазвичай в точках розташування рук і ніг.

Напруга кроку - це різниця потенціалів j1 і j2 в полі розтікання струму по поверхні землі між місцями, розташованими на відстані кроку (« 0,8 м).

Спеціальні засоби захисту: заземлення, занулення, захисне відключення.

Захисне заземлення слід виконувати відповідно до ПУЕ і СНіП 3.05.06-85 («Електротехнічні пристрої»).

Ергономічна безпека комп'ютера оцінюється за двома вимогами: до візуальних параметрів дисплеїв (з урахуванням світлового клімату робочого місця) і до емісійних параметрів - випромінювань дисплеїв і ПК.

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

У першу виділено чотири параметри: яскравість, освітленість, кутовий розмір знаку і кут спостереження, нормування яких в цілях забезпечення ергономічної безпеки комп'ютера взаємозалежно.

Друга - нерівномірність яскравості, відблиски, мигтіння, тремтіння, геометричні і нелінійні спотворення і т.д. (всього більше 20 параметрів) незалежні, і кожен з них може бути окремо заміряний.

Оскільки електромагнітне випромінювання виходить від всіх частин монітора (багато вимірювань показали, що рівень випромінювання з боків і позаду монітора вище, ніж спереду), найбезпечніше встановити комп'ютер в кутку кімнати або в такому місці, де ті, хто на нім не працює, не виявлялися б збоку або ззаду від машини.

Не можна залишати комп'ютер або монітор надовго увімкненим. Якщо комп'ютер не використовується, його слід вимкнути. Це може бути не дуже зручно (і може навіть зробити деякий вплив на термін служби комп'ютера), але все таки це не дуже велика плата за захист від потенційної небезпеки електромагнітного поля.

Діти і вагітні жінки повинні проводити за комп'ютером не більше декількох годин в день. Рекомендації більшості лікарів зводяться в основному до обмеження часу роботи за комп'ютером, обов'язкові паузи під час роботи та інше.

Нерівномірність і складна форма розподілу змінних електромагнітних полів у ряді випадків може представляти велику небезпеку опромінювання для сусідів по робочому приміщенню, ніж для користувача даного ПК.

Монітори комп'ютерів є джерелом рентгенівського, бета - і гамма-випромінювань. Рентгенівське випромінювання присутнє тільки при роботі монітора. Для зменшення шкідливої дії іонізуючих випромінювань в моніторах було понижено анодну напругу, а в скло моніторів доданий свинець. Небезпечні або не небезпечні іонізуючі випромінювання, що випускаються моніторами комп'ютерів, - все залежить від рівнів іонізуючих випромінювань, що потрапляють в очі користувачів комп'ютера. Безпека рівнів іонізуючих випромінювань комп'ютерних моніторів регламентується ДОСТ Р50948-96 і нормами НРБ-99. ДОСТ Р50948-96 обмежує потужність дози рентгенівського випромінювання величиною 100 мкР/час на відстані 5 см від поверхні екрану монітора, а НРБ-99 установлює для населення межу річної еквівалентної дози випромінювань на кришталик ока - 15 мкР/час.


6.2 Заходи щодо нормалізації шкідливих і небезпечних факторів


Норми мікроклімату зазначені у санітарних нормах мікроклімату виробничих приміщень ДСН 3.3.6.042-99.

Температура повітря може відрізнятися від норм залежно від пори року та інших умов. Щоб уникнути небажаних відхилень потрібно встановлювати допоміжні засоби регулювання мікроклімату: кондиціонери, обігрівачі тощо.

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

Акустичний екран є перешкодою для звукових хвиль, що знижує рівень звуку за рахунок утворення акустичної тіні за екраном в зоні розташування робочого місця.

Звукопоглинальне облицювання поверхонь похідних приміщень зменшує інтенсивність відбитих звукових хвиль. Використання звукопоглинальних конструкцій дозволяє понизити УЗ в зоні відбитого звуку на 4-8 дб.

Проблеми з випромінюванням моніторів допомагають вирішити спеціальні окуляри з прогресивними лінзами, в яких зона ясного бачення відповідає переміщенню погляду при роботі з дисплеєм. Можливі також окуляри або контактні лінзи, в яких одне око фокусується на екран, а інший на папір з текстом

Застосування окулярів з такими покриттями у інтенсивних користувачів ПК дало зниження зорового стомлення і поліпшення показників акомодації в порівнянні із звичайними окулярами у 85% працівників.

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

Ергономічна безпека праці досягається за допомогою нескладних правил. Спина людини повинна бути нахилена назад під кутом в декілька градусів для збільшення кута між тулубом і стегнами, посилення кровообігу і зменшення тиску на хребет. Руки розслаблені і вільно опущені уздовж боків, передпліччя і кисті розташовані паралельно підлозі. Стегна знаходяться під прямим кутом до тулуба. Коліна - під прямим кутом до стегон.

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

Максимальний час безперервної роботи за комп'ютером не повинен перевищувати 4-х годин в день. Через кожні 7 хвилин потрібно робити коротку перерву на 10-15 секунд. Можна подивитися у вікно (у далечінь) або на картину з приємним для очей пейзажем, яку необхідно повісити за комп'ютером. У картині повинні переважати неяскраві, заспокійливі зір кольори, такі, наприклад, як зелені, блакитні. Також потрібно робити декілька простих вправ для очей.

Монітор повинен стояти так, щоб прямі сонячні відблиски з вікна і люмінесцентне світло денних ламп не падали на екран і безпосередньо на око. Якщо моніторів в кабінеті багато, то відстань між ними повинна бути не менш ніж два метри, щоб не підсилювати впливу шкідливих полів і бічним зором не бачити інший екран. Важливе правильне локальне і загальне освітлення навколо монітора. Розміщувати монітор потрібно трохи вище за рівень очей. Це дозволить розслабити ті групи м'язів, які напружені при звичайному погляді вниз і вперед. Відстань від очей до монітора повинна бути близько 70-80 см.

Тіло повинне бути достатньо розслаблене, руки вільно лежати на опорі. Тому в кріслі оператора ЕОМ повинні бути передбачені окремі підлопаткові і поперекові опори. Спинка крісла і підлокітники повинні регулюватися по висоті і розташуванню в площині, глибину крісла треба теж встановлювати індивідуально. Але як би зручно ви не влаштувалися за своїм комп'ютером, робочий день перед екраном не повинен перевищувати шести годин. Через кожні дві години принаймні, а то і частіше, необхідно робити перерви і короткі фізкультурні паузи - наприклад, обертання очима, повороти голови, розминка рук.

Захисне заземлення слід виконувати відповідно до ПУЕ і Сніп 3.05.06-85 («Електротехнічні пристрої»).

Стійкі, металеві кронштейни з ізоляторами, антенні пристрої ТБ, а також металеві частини шаф, кросів, пультів і інші металоконструкції устаткування, на яких встановлено електроустаткування напругою вище 42В змінного струму, повинні мати захисне занулення шляхом з'єднання з нульовою жилою електричної мережі напругою 380/220 В.

Величина опору заземлення устаткування повинна відповідати ГОСТ 464-79. Опір заземлення загалом не повинен перевищувати значення 2 Ом у будь-який час року.

Робоче заземлення устаткування зв'язку, сигналізації і диспетчеризації слід виконувати згідно технічним вимогам на це устаткування. Розрахунок заземлення наведено нижче.

Все устаткування будівлі підєднано до трифазної мережі, напругою 380В з ізольованою нейтралю. Загальна потужність джерел живлення мережі перевищує 100 кВА. Будівлю має залізобетонний фундамент на глинистому ґрунті. Площа, обмежена периметром будівлі 852000 м2.

Оскільки живляча мережа не перевищує 1000В, має ізольовану нейтраль і потужність джерел живлення більшу 100 кВА, як нормативний опір заземлення беремо Rн = 4 Ом.

Як природне заземлення використовуємо фундамент будівлі. Для нашого випадку опір ґрунту (глина) rr = 40 Ом * м; коефіцієнти сезонності, залежні від кліматичної зони СНД Yв = 1,5 - 1,8 при розрахунку вертикальних електродів і Y = 3,5 - 4,5 при розрахунку опору горизонтальних електродів, приймаємо рівними: Yв = 1,65 Yг = 4.

Питомий електричний опір ґрунту в зоні розміщення заземлення визначається по формулі:



Опір природного заземлення для залізобетонного фундаменту:


що перевищує Rн = 4 Ом.

Отже необхідний штучне заземлення, підключене паралельно природному, з допустимим опором:


Rн.доп. = Re * Rн /(Re - Rн) = 5б7 *4 /(5,7 - 4) = 13,4 Ом.


Штучне заземлення розташовуємо на зниженій і зволоженій ділянці території підприємства на відстані 30 м від будівлі. Заземлення виконуємо як систему розташованих в ряд вертикальних електродів у вигляді стрижнів довжиною l = 2,6м з кутової сталі з шириною b = 0,05м, верхні кінці яких лежать на глибині t0 = 0,7м і сполучені смугою зв'язку із сталі, перетином 5 х 40 мм.

Для вертикальних електродів, питомий опір ґрунту в зоні розміщення заземлення:



Опір одиночного вертикального електроду визначимо:



де l>>d; t = 0,5l = t0; l, d відповідно довжина і діаметр електроду;

для електроду із сталі значення d = 0,95b.

Визначаємо кількість вертикальних електродів:



Задавшись відстанню a між електродами у вигляді співвідношення a/l, знаходимо n (для a/l = 2; n = 2).

Знаходимо довжину L горизонтального провідника, що сполучає вертикальні електроди. При розташуванні в ряд:



при розташуванні по контуру



Опір горизонтальної смуги якщо L>>4 t0 >>c,



де с - ширина смуги, рівна діаметру вертикального електроду.

При ?/l = 2 і n = 2 знаходимо ?э?=0,91 і ?n?=0,94. Тоді результуючий опір штучного заземлення:



Набутого значення не перевищує допустимого опору Rн.доп=13,4 Ом.

Оскільки штучне заземлення достатньо віддалене від природного, можна нехтувати впливом їх полів розтікання струму. Тоді загальний опір всього комплексу заземлення, що складається з природного і штучного заземлення:


Rз = Rи * RЕ /(Rи + RЕ) = 3,12 Ом, що менше Rн = 4 Ом.

6.3 Пожежна безпека


Пожежа - неконтрольований процес горіння, що супроводжується знищенням матеріальних цінностей і що створює небезпеку для життя людей.

Горіння - хімічна реакція, яка супроводжується виділенням тепла і світла.

Класифікація приміщень і будівель за ступенем рівнем пожежної безпеки ОНТП 24-85.

Основні причини пожеж: коротке замикання, перевантаження проводів, утворення перехідних опорів.

Режим короткого замикання - поява в результаті різкого зростання сили струму, електричних іскор, частинок розплавленого металу, електричної дуги, відкритого вогню, ізоляції, що запалала.

Причини виникнення короткого замикання: помилки при проектуванні, старіння ізоляції, зволоження ізоляції, механічні перевантаження.

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

При 1,5 кратному перевищенні потужності резистори нагріваються до 200-300? С.

Пожежна небезпека перехідних опорів - можливість займання ізоляції або інших довколишніх горючих матеріалів від тепла, що виникає в місці аварійного опору (у перехідних клемах, перемикачах і ін.).

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

Пожежна небезпека струмів витоку - локальний нагрів ізоляції між окремими елементами і заземленими конструкціями.

Заходи по пожежній профілактиці: будівельно-планувальні, технічні, способи і засоби гасіння пожеж, організаційні.

Будівельно-планувальні визначаються вогнестійкістю будівель і споруд (вибір матеріалів конструкцій: що згорають, не згорають, важко згорають) і межа вогнестійкості - це кількість часу в перебігу якого під впливом вогню не порушується несуча здатність будівельних конструкцій аж до появи першої тріщини.

Всі будівельні конструкції по межі вогнестійкості підрозділяються на 8 ступенів від 1/7 години до 2 годин.

Для приміщень ОЦ використовують матеріали з межею стійкості від 1 до 5 ступенів. Залежно від ступеня вогнестійкості визначають найбільші додаткові відстані від виходів для евакуації при пожежах (5 ступінь - 50 хвилин).

Організаційні заходи - проведення навчання по пожежній безпеці, дотримання заходів по пожежній безпеці.

Способи і засоби гасіння пожеж: зниження концентрації кисню в повітрі, пониження температури горючої речовини нижче температури займання, ізоляція горючої речовини від окислювача.

Засоби вогнегасіння:

Ручні: вогнегасники хімічної піни, вогнегасник пінний, вогнегасник порошковий, вогнегасник вуглекислотний, бром етиловий. Протипожежні системи: система водопостачання, піногенератор. Система автоматичного пожежогасіння з використанням засобів автоматичної сигналізації: пожежний оповіщувач (тепловий, світловий, димовий, радіаційний), для ОЦ використовуються теплові датчики-оповіщувачі, димові, радіоізотопні. Система пожежогасінні ручної дії (кнопковий оповіщувач).

Для ОЦ використовуються вогнегасники вуглекислотні і системи автоматичного газового пожежогасіння, в яких використовується хладон або фреон як вогнегасний засіб.

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

Пожежі на обчислювальних центрах становлять особливу небезпеку. Як відомо, пожежа може виникнути при взаємодії пальних речовин, окислювача й джерела запалювання. У приміщеннях обчислювальних центрів присутні всі три фактори, необхідні для виникнення пожежі.

Виникнення пожежі в розглянутому приміщенні найбільше імовірно із причин несправності електроустаткування, до яких ставляться: іскріння у місцях з'єднання електропроводки, короткі замикання, перевантаження проводів і обмоток трансформаторів, перегрів джерел безперебійного живлення й інші фактори. Тому підключення комп'ютерів до мережі необхідно робити через розподільні щити, що дозволяють робити автоматичне відключення навантаження при аварії.

Особливістю сучасних ЕОМ є дуже висока щільність розташування елементів електронних схем, висока робоча температура процесора й мікросхем пам'яті. Отже, вентиляція й система охолодження, передбачені в системному блоці комп'ютера повинні бути постійно в справному стані.

Надійна робота окремих елементів і електронних схем у цілому забезпечується тільки в певних інтервалах температури, вологості й при заданих електричних параметрах.

Серйозну небезпеку становлять різні електроізоляційні матеріали. Материнські плати електронних пристроїв, а також плати всіх додаткових пристроїв ЕОМ виготовляють із гетинаксу або стеклотекстоліту. Пожежна небезпека цих ізоляційних матеріалів невелика, ставляться до групи важкопальних і можуть запалитися тільки при тривалому впливі вогню й високої температури.

Оскільки в розглянутому випадку при загоряннях електропристрої можуть перебувати під напругою, то використати воду й піну для гасіння пожежі неприпустимо, оскільки це може привести до травм. Іншою причиною, по якій небажане використання води є те, що на деякі елементи ЕОМ неприпустиме потрапляння вологи. Тому для гасіння пожеж у розглянутому приміщенні можна використати або порошкові склади, або установки вуглекислотного гасіння. Але оскільки останні призначені тільки для гасіння невеликих вогнищ загоряння, то область їхнього застосування обмежена. Тому для гасіння пожеж у цьому випадку застосовуються порошкові склади, тому що вони мають наступні властивості: діелектрики, практично не токсичні, не роблять корозійного впливу на метали, не руйнують діелектричні лаки.

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

Для профілактики пожежної безпеки організується навчання виробничого персоналу (обов'язковий інструктаж із правил пожежної безпеки не рідше одного разу на рік), видання необхідних інструкцій з доведенням їх до кожного працівника установи, випуск і вивіска плакатів із правилами пожежної безпеки й правилами поведінки при пожежі. Також необхідна наявність плакатів, що інформують людей про розташування аварійних виходів з будинку у випадку виникнення пожежі, плану евакуації людей в аварійних ситуаціях.



Висновки

Visual Studio .NET - це інтегроване середовище розробки (Integrated Development Environment (IDE)) для створення, документування, запуску і відладки програм, написаних на мовах .NET. Це могутній інструмент професійної розробки складних додатків.

Якщо сказати, що мова С# і пов'язана з ним середа .NET Framework є одній з найважливіших технологій для розробників за багато років, це не буде перебільшенням. .NET спроектована як нова середа, в рамках якої можна розробити практично будь-яке застосування для Windows, тоді як С# - нова мова програмування, призначена спеціально для роботи з .NET. За допомогою С# можливо, наприклад, створити динамічну Web-сторінку, Web-службу XML, компонент розподіленого застосування, компонент доступу до бази даних, класичний настільний додаток Windows або навіть інтелектуальне клієнтське програмне забезпечення, що має засоби онлайнової і автономної роботи.- це набір API функцій, розроблених для вирішення завдань, пов'язаних з ігровим і відеопрограмуванням в операційній системі Microsoft Windows.

Створення складних і високопродуктивних мультимедійних програм вимагає безпосереднього доступу до апаратних ресурсів. Бібліотека DirectX містить набір низькорівневих програмних інтерфейсів, надаючий такий доступ Windows-програмістам. Технологія Managed DirectX - могутній засіб створення ігор. Уяви собі гру, написану C# у поєднанні з Managed DirectX. За заявами MS, програми .NET можуть виконуватися на будь-якій платформі за наявності відповідного .NET Framework, отже, ми одержуємо міжплатформену гру. Щоб проілюструвати досліджені в теоретичній частині дипломної роботи технології нами був розроблений додаток, який реалізує практично весь спектр можливостей дослідженої нами технології.

Список літератури


.Алексей В. Технология XSLT. - BHV - Санкт-Петербург, 2005

.Аллен Э. Типичные ошибки проектирования. - Питер, 2003

.Арчер Т.. Основы С#. - М.: Русская Редакция, 2002

.Грэхем И. Объектно ориентированные методы. - М.: Издательский дом "Вильямс", 2004

.Гуннерсон Э. Введение в C#. - Питер, 2001

.Дубовцев А. Microsoft .Net в подлинеке. - БВХ-Петербург, 2008

.Кариев Ч.А. Разработка Windows-приложений на основе Visual C# . БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007

.Кент Бек. Экстремальное программировнаие. - Питер, 2002

.Мартин Ф. Архитектура корпоративных программных приложений. - М.: Издательский дом "Вильямс", 2004

.Нейлгел К., Ивьен Б., Глинн Дж. С# 2008 для профессионалов. -М.: Издательский дом "Вильямс", 2008

.Прайс Дж., Гандерлой М. Visual C# .NET : Пер. с англ. - К.: ВЕК+, 2005

.Рихтер Дж.. Программирование на платформе Microsoft .Net Framework. - М: Русская Редакция, 2007

.Робинсон С., Корнес О., Глинн Дж. С# для профессионалов. - М: Лори, 2008

.Стивенс Р. Протоколы TCP/IP. Практическое руководство. - BHV - Санкт-Петербург, 2003

.Таненбаум. Э. Компьютерные сети. - Питер, 2007

.Троелсен Э. Язык программирования С# 2005 и платформа .Net 2.0. - М.: Издательский дом "Вильямс", 2007

.Фейт С. TCP/IP. Архитектура, протоколы, реализация. - Лори, 2008

.Филимонов А. Построение мультисервисных сетей Ethernet. - БВХ-Петербург, 2007

.Чакработи А., Кранти Ю., Сандху Р. Microsoft .NET Framework: разработка профессиональных проектов: Пер. с англ. СПб.: БХВ-Петербург, 2006

.#"justify">21.#"justify">.#"justify">23.#"justify">24.#"justify">25.#"justify">.#"justify">.http://www.gotdotnet.ru


"Дослідження технологій створення тривимірних графічних додатків на базі платформи dotNET"

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ