З обмеженням на обсяг пам'яті ми зіткнулися, коли визначали максимально допустиму кількість спрайтів 1 , І пов'язано це було з тим, що наша програма переміщення спрайтів працювала в реальному режимі DOS, що відрізняється наступними особливостями. Повний обсяг доступної пам'яті становить 640 Кбайт, причому частина її займають сама ОС і її драйвери. Виконується програма здатна використовувати лише 400-550 Кбайт. І головне, цей обсяг не залежить від місткості ОЗУ комп'ютера - неважливо, чи становить вона 1 або 64 Мбайт. Крім того, пам'ять сегментована, і розмір одного сегмента не перевищує 64 Кбайт. Таким чином, робота з пам'яттю, реалізована за допомогою поширеного компілятора Borland Pascal, обмежує максимальний розмір будь-якої структури або масиву величиною в 64 Кбайт. Цю ж величину не повинен перевершувати сумарний обсяг усіх статичних змінних і констант. Так що розробнику часто доводиться передбачати, навіть при використанні графічного режиму з дозволом 320x200 точок, можливість завантаження з диска нових зображень під час гри при переході на наступний рівень, в інші локацію або ігровий режим. Застосовувати більш високу роздільну здатність в реальному режимі стає майже неможливим.
Щоб задіяти всю наявну в комп'ютері пам'ять, програма повинна працювати в захищеному режимі процесора (PM - protected mode), вперше з'явилося в 286-му процесорі. У Borland Pascal є кошти для створення програм, що працюють в цьому режимі. Максимально доступний обсяг пам'яті був збільшений з 640 Кбайт до 16 Мбайт, проте обмеження в 64 Кбайт на розмір масиву або статичних даних не тільки збереглося, а й стало суворішим 2 . Поява 386-го процесора з 32-розрядних захищеним режимом усунуло відразу обидва обмеження, і 16-розрядний захищений режим відійшов у минуле. На жаль, Borland Pascal новий режим не підтримує. Однак існують компілятори мови Паскаль, що допускають таку підтримку [1], зокрема вільно розповсюджуваний ТМТ Pascal ( www.tmt.com ). У ньому, на відміну від Borland Delphi, збережена ідеологія Borland Pascal, тому ми і будемо використовувати саме його для подальшого вдосконалення нашої програми.
Трідцатідвухразрядние додатки DOS (далі - DOS32) можуть працювати в середовищі будь-якої сумісної з DOS операційної системи, наприклад, в DOS-сесії Windows 9х / Me. У текстовому режимі вони практично не відрізняються від консольних додатків багатозадачною ОС, а в повноекранному графічному - від додатків, написаних за допомогою DirectDraw. Більш того, програми DOS32 часто працюють швидше додатків Windows, особливо при виведенні інформації на екран. Але оскільки в середовищі DOS не застосовуються 3D-прискорювачі, а також виникають складнощі з сучасними звуковими платами, вона практично витіснена з ігрової індустрії. А ось для виведення спрайтові графіки додатки DOS32 цілком підходять.
Переробимо нашу програму таким чином, щоб можна було відображати рух анімованих спрайтів в графічних режимах з високою роздільною здатністю через сервіс VESA [2, 3]. Стандартний модуль graph TMT Pascal містить засоби для роботи в цих режимах 3 .
Багато програм, написані в середовищі Borland Pascal, не потрібно змінювати, щоб вони могли функціонувати і в ТМТ. Однак захищений режим має свої особливості. Так, програми, створені в реальному режимі Borland Pascal, не завжди працюють в захищеному режимі цього ж компілятора. Це ж властиво і програмами, компільовані за допомогою TMT Pascal: якщо вони працюють в захищеному режимі Borland, то, швидше за все, будуть функціонувати і в ТМТ. Деяку несумісність реального режиму з захищеним мають операції з покажчиками, з прямою адресацією пам'яті, з перериваннями DOS і BIOS, а також з апаратними перериваннями.
У нашій програмі крім основного блоку накопичилися ще сім модулів. З них bmpread, mouse і timer18 не потребують будь-якої переробці - вони без змін можуть «працювати» і в захищеному режимі. Модуль sprites через зміну екранного режиму в будь-якому випадку доведеться переробляти. Решта три модуля з тих чи інших причин виявилися несумісні з захищеним режимом: pal і text256 - з передачі адреси в переривання BIOS, а keyboard - по оброблювачу апаратного переривання.
Внесемо зміни в модулі sprites і pal, а модулі keyboard і text256 тимчасово відключимо. Крім того, додатково подсоединим модуль graph, що входить в стандартні бібліотеки.
Почнемо з pal. Звичайно, всі складнощі з викликом переривання реального режиму із захищеного переборні, але все ж буде краще використовувати альтернативний спосіб установки палітри - безпосередню запис в порти відеокарти. Порти $ 3c7 і $ 3c8 призначені для того, щоб ставити номер кольору при читанні та встановлення палітри відповідно, а $ 3c9 - для запису складових RGB, які пишуться в один і той же порт по черзі: червоний, зелений, синій. Читання відбувається аналогічно. Текст змін наведено в лістингу 1 .
У модулі sprites змін набагато більше. Якщо серед стандартних видеорежимов VGA лише в одному допускається використовувати 256 кольорів, то серед режимів SVGA таких буде досить багато, і тому нерозумно прив'язуватися до якогось одного з них. Так як при розробці програми неодноразово доводиться вказувати розміри екрану, то доцільно встановити чотири додаткові константи, що характеризують просторову роздільну здатність.
const ScrSizeX = 800; ScrSizeX1 = ScrSizeX1; ScrSizeY = 600; ScrSizeY1 = ScrSizeY1;
Тепер в модулі sprites всюди замінимо 319 на ScrSizeX1, а 199 - на ScrSizeY1, а також помістимо посилання на модуль graph, в якому передбачені процедури не тільки для установки режимів SVGA, але і для роботи з екранним буфером і спрайтами ( лістинг 2 ). До речі, обсяг екранного буфера, що становив 64 тис. Байт, тут явно не задається і навіть не обчислюється виходячи з розмірів екрану, а повертається функцією GetPageSize з модуля graph. Це пов'язано з тим, що обсяг буфера повинен бути дорівнює обсягу використовуваної відеопам'яті, а конструкція деяких відеоплат така, що пам'яті під екран виділяється більше, ніж потрібно. Природно, функція GetPageSize повинна викликатися тільки при встановленому графічному режимі.
Закінчення в наступному номері.
Повні тексти програм перебувають за адресою www.pcworld.ru .
література
1. Андріанов С. Паскаль сьогодні // Світ ПК. 2001. № 4. С. 68.
2. Андріанов С. А. VESA: стандарт новий, проблеми старі // Світ ПК. 1998. № 7. С. 62.
3. Андріанов С. А. VESA 2.0: програмуємо в захищеному режимі // Світ ПК. 1998. № 8. С. 22.
1 Див. «Мир ПК» за 2001 р - № 7, с. 87 ; № 10, с. 99 ; № 11, с. 100 ; № 12, с. 98 ; за 2002 р - № 1, с.117 ; № 2, с. 107 ; № 3, с. 100 ; № 5, с. 108 ; № 6, с. 103 ; № 9, с. 96 ; № 10, с. 98 ; № 11, с. 112 .
2 У реальному режимі за допомогою обчислення сегментной частини адреси можна було направляти більше 64 Кбайт, а в захищеному замість адрес використовуються селектори, арифметичні дії над якими заборонені.
3 Включаючи режими з більшою глибиною кольору: 15, 16, 24 і 32 розряди на піксель.
