Graphics — VESA(VBE in PM) + shaders


Содержание

Graphics — VESA(VBE in PM) + shaders

Since Bochs 1.4 it is possible to use VESA graphics. There are some limitations in the current implementation, but in general it should work ok (we have run several test programs, the XFree86 VESA display driver, etc.)

Note: The VGABIOS is already included in the Bochs release, so no separate download is necessary.

Note: To take advantage of the VBE, you must tell Bochs to use the LGPL’d VGA BIOS version 0.4c or higher. A current version of the VGA BIOS will work.

4bpp modes support is incomplete (8, 15, 16, 24 and 32bpp should work)

banked mode is very slow (if you can, just use Linear Frame Buffering instead!)

only 320×200, 640×400, 640×480, 800×600, 1024×768 are currently supported

You need a display driver capable of using the VESA BIOS for this to work (a recent XFree86 will do, Windows 9x/NT/2K/XP probably will not work ‘out of the box’.

Currently the VBE2 extension should be supported ok

This was contributed by Martin Bochnig in February 2004.

Instructions for Win95/98: ========================== I can only confirm that SciTech finally made a VBE driver for Windows. It works out of the box, at least with win95 as guest OS, provided you use Bochs 2.1 with the LGPL vgabios. Here is how I did it : — install win95 with the vga driver. — download sdd 7 beta from http://www.majorgeeks.com/download382.html — download pmhelp.vxd from http://unununium.org/viewcvs/snap/redist/release/pmhelp.vxd — copy pmhelp.vxd to the win95 system directory — install sdd7 800×600 and 1024×768 in 16 and 24 bpp modes here. I did not try 32bpp.

This was contributed by Stanislav Shwartsman in September 2004.

VESA BIOS Extensions — VESA BIOS Extensions

VESA BIOS Extensions ( VBE ) является VESA стандарт, в настоящее время в 3 -й версии, который определяет интерфейс , который может использоваться программным обеспечением для доступа совместимые видеоплаты в высоких разрешениях и разрядности. Это отличие от «традиционных» INT 10h BIOS вызовов, которые ограничены разрешением 640 х 480 пикселей с 16 цветами (4 бита) глубиной или меньше. VBE будет доступны через BIOS видеокарты , которая устанавливает во время загрузки до некоторых прерываний векторы , которые указывают на себе.

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

содержание

стандарты

VESA BIOS Extensions (VBE ядро) 2,0 [ноябрь 1994]

Этот стандарт обеспечивает основную функциональность VESA BIOS Extensions. Это позволяет приложениям определять возможности видеокарты и предоставляет возможность устанавливать режимы отображения, которые найдены. VBE 2.0 добавляет некоторые новые функции выше предыдущего стандарта VBE 1.2 , включая линейный фреймбуфера доступа и защищенного режима банковских услуг. Некоторые из особенностей VBE ядра 2.0 включают в себя:

Линейный доступ к фреймбуферу Обеспечивает прямой доступ фреймбуйер в защищенном режиме, как одна большая область памяти вместо менее эффективных мелких кусков. Защищенный режим банковской Позволяет получить доступ к фреймбуферу из защищенного режима без «thunking» вплоть до реального режима . Super VGA покадрового Позволяет более анимация производительности для обеспечения плавной анимации для компьютерных игр и других графических программ высокой производительности. Супер VGA виртуальные экраны Позволяет программное обеспечение для создания виртуальных разрешения экрана , размер которых превышает фактическое разрешение отображаемой и плавно прокручивать или панорамировать увеличенное изображение. High Color и TrueColor режимы Промышленный стандарт 16-битовые и 24-битовые графические режимы разрешения от 320 × 200 до 1600 × 1200.

VESA BIOS Extensions (VBE ядро) 3,0 [сентябрь 1998]

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

Тройная буферизация Позволяет высокоскоростные приложения для выполнения мульти-буферизации с меньшим экраном мерцанием и без необходимости ждать графического контроллера. Обновить управление скоростью с помощью ГТФ тайминги Это позволяет приложениям и служебные программы операционной системы, чтобы изменить частоту обновления стандартным образом на всех VBE 3.0 графических контроллеров. Важное значение для стерео приложений, так как, когда стерео включена, эффективная частота обновления пользователя разрезают пополам. Стерео покадрового При просмотре приложения с помощью стерео очков , программное обеспечение должно перелистывания в два раз чаще, чем нормальный, потому что он должен генерировать отдельные изображения для каждого глаза. Эта новая функция позволяет стерео — совместимое программное обеспечение для правильного отображения. Оборудование стерео синхронизации Позволяет стерео программное обеспечение, чтобы определить, есть ли разъем для подключения стереоочков на пользователя видеокарты.

VBE / ускоритель функции (VBE / AF) [август 1996]

VBE / AF обеспечивает низкий уровень, стандартный интерфейс для общих функций ускорения , доступных на большинстве аппаратных средств. Некоторые из функций , определенных в стандарте, доступ к аппаратным курсорам, битовый блок Передаче (бит BLT), выключение экрана спрайтов , аппаратное панорамирования, рисование и другие функции.

Дополнительные характеристики

Дополнительные характеристики обеспечивают аппаратно-независимый интерфейс между прикладным программным обеспечением и аппаратными средствами Super VGA. Номера функций назначаются комитетом VESA Software стандартов (SSC) с помощью.

Расширения управления питанием (PM)

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

Плоские расширения интерфейса панели (FP)

Позволяет получить доступ к особенностям в контроллерах плоских панелей.

Аудио расширения интерфейса (AI)

Обеспечивает стандартное аудио услуг.

В настоящее время (версия 1.00), спецификация VBE / AI определяет три класса устройств: WAVE, MIDI и VOLUME. Типы устройств не распространяются на:

управление CD-ROM которая покрыта Extensions CD-ROM в Microsoft. процессоры эффектов Этот класс устройств будет расширен в будущей версии спецификации VBE / AI.

расширения OEM

Обеспечивает стандартную запись для конкретного поставщика расширений.

Отображение канала передачи данных (DDC)

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


Последовательный интерфейс управления (SCI)

Обеспечивает аппаратные независимые средства для операционной системы и приложений для чтения и записи данных через I²C последовательный интерфейс управления.

номера режима VBE

Несмотря на то, номер режим представляет собой 16-битное значение, необязательные числа режимов VBE 14 бита. Бит 15 используется VGA BIOS как флаг, чтобы очистить или сохранить память дисплея. VBE определенные номера режима следующим образом:

Немного Имея в виду
0-8 номера режима. Если бит 8 равен 1, это определяется режим VESA VBE.
9-10 Зарезервировано для расширения. Должен быть установлен в 0.
11 Обновление управления скоростью Выбор. Если установлено значение 1, пользователь использует указанный КТРТК значения скорости обновления, в противном случае использовать частоту обновления BIOS по умолчанию.
12-13 Зарезервировано для VBE / AF. Должен быть установлен в 0.
14 Линейный / Flat Frame Buffer Select. Если установлено в 1, использовать линейный буфер кадра, в противном случае использовать буфер кадра хранящихся в банке.
15 Сохранение памяти дисплея Выберите. Если установлено в 1, сохранить память дисплея, в противном случае очистить память дисплея.

Начиная в VBE / Core 2.0, VESA больше не определяет новые номера режима VESA и больше не требует устройств для реализации старых номеров. Для того, чтобы правильно определить информацию о режиме экрана, используйте функцию 01h — Return VBE Mode Информацию .

Режим 81FFh это специальный режим видео предназначен для сохранения текущего содержимого памяти и предоставлять доступ ко всей видеопамяти.

Режимы определяется VESA

Начиная со стандартом VBE 2.0, никакие новые режимы не будут определены стандартом VESA, и старые режимы больше не является обязательным. Использование определенных режимов следует считать устаревшим: современные видеокарты могут или не могут использовать эти номера режима (даже если большинство из них для обеспечения обратной совместимости), а также современное программное обеспечение не должен использовать их. Правильный путь для программного обеспечения, чтобы открыть доступные режимы отображения, чтобы получить список режимов (с использованием «Функция 00h — Возвращение VBE контроллер Информация»), а затем проверить каждый режим (с помощью «Функция 01h: Return VBE Mode Information») до тех пор, пока не найдет режим / с требует.

графика режимы 320 × 200 640 × 400 640 × 480 800 × 600 1024 × 768 1280 × 1024
16-цветовая палитра 258 (0102h), 106 (6Ah) 260 (0104h) 262 (0106h)
256-цветовая палитра 256 (0100h) 257 (0101h) 259 (0103h) 261 (0105h) 263 (0107h)
15-битный (5: 5: 5) 269 ​​(010Dh) 272 (0110h) 275 (0113h) 278 (0116h) 281 (0119h)
16-битный (5: 6: 5) 270 (010Eh) 273 (0111h) 276 (0114h) 279 (0117h) 282 (011Ah)
24-бит (8: 8: 8) 271 (010Fh) 274 (0112h) 277 (0115h) 280 (0118h) 283 (011Bh)

Режимы 264-268 являются режимы текста. 264 (0108h) составляет 80 столбцов × 60 строк (80 × 60), 265 (0109h) составляет 132 × 25, 266 (010Ah) составляет 132 × 43, 267 (010Bh) составляет 132 × 50 и 268 (010Ch) составляет 132 × 60.

режимы текста Колонны
Ряды 80 132
25 265 (0109h)
43 266 (010Ah)
50 267 (010Bh)
60 264 (0108h) 268 (010Ch)

Другие доступные графические режимы

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

графика режимы 320 × 200 640 × 400 640 × 480 800 × 500 800 × 600 896 × 672 1024 × 640 1024 × 768 × 720 тысяча сто пятьдесят-две 1280 × 1024 1440 × 900 1600 × 1200
16-цветовая палитра 258 (0102h),
106 (6Ah)
260 (0104h) 262 (0106h)
256-цветовая палитра 256 (0100h) 257 (0101h) 367 (016Fh) 259 (0103h) 303 (012Fh) 362 (016Ah) 261 (0105h) 357 (0165h) 263 (0107h) 352 (0160h) 284 (011Ch)
15-битный (5: 5: 5) 269 ​​(010Dh) 289 (0121h) 272 (0110h) 368 (0170h) 275 (0113h) 304 (0130h) 363 (016Bh) 278 (0116h) 358 (0166h) 281 (0119h) 353 (0161h) 285 (011Dh)
16-битный (5: 6: 5) 270 (010Eh) 290 (0122h) 273 (0111h) 369 (0171h) 276 (0114h) 305 (0131h) 364 (016Ch) 279 (0117h) 359 (0167h) 282 (011Ah) 354 (0162h) 286 (011Eh)
24-бит (8: 8: 8) 271 (010Fh) 291 (0123h) 274 (0112h) 370 (0172h) 277 (0115h) 306 (0132h) 365 (016Dh) 280 (0118h) 360 (0168h) 283 (011Bh) 355 (0163h) 287 (011Fh)
32-бит (8: 8: 8) 292 (0124h) 297 (0129h) 371 (0173h ) 302 (012Eh) 307 (0133h) 366 (016Eh) 312 (0138h) 361 (0169h) 317 (013Dh) 356 (0164h) 322 (0142h)
  1. ^ Абгр Режимы , доступные через традиционные 10h вызова BIOS

номера в режиме видео Linux

Ядро Linux позволяет пользователю выбрать режим VESA во время загрузки путем передачи кода в памяти ядра. Загрузчик LILO передает этот код на основе параметра «УПА» в конфигурационном файле. Он принимает вид «= XXX VGA», где XXX является десятичным значением, или «= 0xHHH VGA», где HHH является шестнадцатеричным значением. Тем не менее, «VGA =» параметр загрузчика непосредственно не принимает VESA номер видеорежима; скорее, Linux , номер режим видео является VESA номер плюс 512 (в случае десятичного представления) или 0x200 плюс (в случае шестнадцатеричного представления). Например, определенное значение VESA 257 (0x101), что составляет 640×480 и 256 цветов, имеет эквивалентную Linux значение режима видео из 769 (0x301).

Как указывалось выше, стандарт VESA определяет ограниченный набор режимов; в частности, ни выше 1,280 × 1,024 не покрыты и, вместо этого, их реализация не является обязательной для производителей графического адаптера. Как производители могут свободно использовать любые дополнительные значения , которые они , пожалуйста, это означает , что в приведенной ниже таблице, режимы , обозначенные красным цветом (и выражается в десятичной форме) не может применить к графическим адаптером !

Graphics — VESA(VBE in PM) + shaders

If you use either the vDosWP method or the DOSBoxWP method for running WPDOS, this this page is NOT for you! Ignore everything on it! If you try to use it, you will only cause problems for yourself. I mean it! Don’t be clueless!

The information on this page applies to 32-bit Windows only! If you have 64-bit Windows (as you almost certainly do if you bought you computer after around 2010), then you must use either the vDosWP method or the DOSBoxWP method for running WPDOS and ignore this page.

Important note: This page concerns the «graphics mode» that WordPerfect uses for print preview, for editing graphics images, and (in WPDOS 6.x only) for editing documents in graphics mode and page mode. The standard «text mode» in WordPerfect is typically the familiar blue screen with white lettering. This page is only about «graphics mode»! See a separate page for notes on WordPerfect’s normal text mode.

WPDOS graphics mode under Windows 95, 98, Me, NT, 2000, and XP: Windows versions from Windows 95 through Windows XP can display WPDOS graphics mode when WPDOS is running in «full-screen» mode (that is, when WordPerfect occupies the full screen, with none of the Windows desktop, taskbar, or start menu showing anywhere). If you want to display WPDOS graphics mode in a window (with a frame around it, and the Windows desktop in the background), see this site’s page about WPDOS running under 64-bit Windows (the methods described there also allow graphics mode to be used under 32-bit Windows versions that cannot otherwise display WPDOS graphics).

WPDOS graphics mode under Vista and Windows 7: Windows Vista and Windows 7 cannot display WP graphics mode unless you are able to set up special v >WPDOS running under 64-bit Windows (the methods described there also allow graphics mode to be used under 32-bit Windows versions that cannot otherwise display WPDOS graphics).

To set up the software «driver» for WordPerfect’s graphics mode, use Shift-F1, Display, Graphics Screen (and, in WPDOS 6.x, Graphics Screen Type). You should ignore all the listed options except IBM VGA (or some variant) and VESA VBE (or some other VESA mode); see the full discussion of high-resolution graphics elsewhere on this page. Do not choose the «IBM 8514/A» driver unless you are one of the two or three people on earth who still use a 1989-vintage IBM PS/2 computer (and you almost certainly are not one of those people).

Very important note: You will find the abbreviations «VESA» or «VESA VBE» throughout this page. Both abbreviations refer to a set of standards that allow video hardware from different manufacturers to produce high-resolution graphics in DOS applications such as WordPerfect for DOS and many old DOS-based games. Modern video hardware based on Nvidia, ATI, and S3 tends to support VESA-based graphics, but not all video cards support VESA-based graphics, and not all operating systems make it possible to use VESA-based graphics. VESA-based graphics are available only with certain combinations of hardware and software. (VESA VBE stands for Video Electronics Standards Organization Video BIOS Extensions.)

A high-resolution VESA graphics driver is supplied with WPDOS 6.x; it is listed as «VESA VBE» in the list of graphics drivers in the installation program and under Shift-F1/Display (but see the slightly altered version of the driver below if you have trouble); VESA support is available in WPDOS 5.1 only after you download and install the 5.1 VESA driver provided elsewhere on this page.

If you have a modern ATI video card, do not use WP’s «ATI» driver; it will not work with modern ATI hardware. Use only VESA or VGA with modern video hardware. See the recommendations below for further information.

If you have any trouble with Microsoft’s drivers for your video card, download and install the drivers supplied by the hardware manufacturer.

What do you mean by «graphics mode» and «text mode»?

WordPerfect for DOS can appear in a number of different modes. If you do not understand what is meant by WordPerfect’s «text mode» and «graphics mode,» or by the «windowed» and «full-screen» modes that WP can use under Microsoft Windows, study the following illustrations:

This picture (click the picture for a larger image) shows WordPerfect’s Text Mode running in a window under Microsoft Windows.

This picture (click the picture for a larger image) shows WordPerfect’s «hardware-based» Text Mode running full-screen so that nothing else is visible on screen (as it always appeared under MS-DOS). This mode uses the hardware fonts built into your video card; it does not use Windows fonts! )

This picture (click the picture for a larger image) shows an example of WordPerfect’s Graphics mode (in this instance, WPDOS 5.1 Print Preview).

Important note: Tame also provides a full-screen text based mode, but Tame’s full-screen mode uses Windows fonts, not the hardware fonts in your video card. If you cannot tell the difference, and if you do not know whether you are using hardware-based full-screen mode or Tame’s full-screen mode using Windows fonts, then do this: Press Alt-Space while working in full-screen WP. If you see something like this illustration, with a Windows-style menu at the top left corner of the screen, then you are using Tame’s full-screen mode based on Windows fonts. If, however, Alt-Space causes you to be switched away from WP to the Windows desktop, then you are using WordPerfect’s «hardware-based» full-screen text mode. Please, please, please do not get these two modes confused when asking about WP in full-screen mode.

High-resolution graphics in WPDOS


WordPerfect for DOS uses graphics drivers that make it possible to use the program’s print preview (and, in WPDOS 6.x only, graphics mode and page mode) with a variety of graphics hardware. Many of these drivers support hardware that is now obsolete, and no drivers have been written (and probably will never be written) for newer hardware. This page has some suggestions for using WPDOS in graphics mode with current video cards and chips.

To select a graphics driver in WPDOS 5.1, choose Shift-F1/Display/Graphics Screen Type. In WPDOS 6.x, choose Shift-F1/Display/Graphics Mode Screen Type/Screen Type.

Corel’s web site has a list of WPDOS 5.1 downloads, including graphics drivers (and a single file containing all the WPDOS 5.1 graphics drivers available from Corel) and for various WPDOS 6.x downloads, including graphics drivers (see also Corel’s summary list of WPDOS 6.1 patches and drivers). Graphics drivers filenames have a .VRS extension.

Two additional WPDOS 6.x graphics drivers are available from other sites: a Trident WPDOS 6.x graphic driver, a copy of which may be downloaded from this site, and a driver for the Alliance Semiconductor Promotion 6140, also available from this site.

A set of WPDOS 5.1 video drivers for the Oak VGA chip, slightly more flexible than the one that shipped with WP itself, may be downloaded from a self-extracting archive on this site; I have not tested these drivers. A set of WPDOS 5.1 video drivers for the S3 video chip may be downloaded from a self-extracting archive on this site; I have not tested these drivers.

For all versions of WPDOS, start with the IBM VGA drivers; these will work with any current hardware, but are limited to 640×480 resolution. For WPDOS 5.1, the IBM VGA driver may be your only possible choice among the original drivers, but, with many modern video cards, you should use the new WPDOS 5.1 VESA graphics driver. Do not choose the IBM 8514/A driver, no matter how tempting it looks to you.

For WPDOS 6.x, you will probably get best results with the VESA VBE driver supplied with the original WPDOS installation disks. In DOS and Windows 95, 98, or Me, the VESA driver provides up to 1280×1024 resolution with many current desktop video boards; under Windows NT, 2000, and XP it works with some, but not all, boards that support VESA under DOS or Windows 9x. Some boards work with WordPerfect’s VESA driver only if you use the patched driver found elsewhere on this page. Do not choose the IBM 8514/A driver, no matter how tempting it looks to you.

Important note for users of WPDOS 6.0 through 6.0c only: The VESA VBE driver that came with your copy of WPDOS will probably not work when you run WPDOS under Windows, and you will be limited to VGA 640×480 graphics; to fix this problem, download and install the VESA VBE driver from Corel’s site, using the link near the start of the preceding paragraph; if that does not work, use the patched driver also described in the preceding paragraph.

Unfortunately, the IBM VGA driver may be the only driver that will work with some boards that do not support VESA. Under Windows NT, 2000, or XP, you may be required to use the IBM VGA driver even with boards that support VESA graphics under DOS and Windows 9x or Me, because the NT/2000/XP drivers for those boards do not include VESA support. Matrox boards seem to be an example of such boards: you can use the WPDOS VESA drivers with a Matrox board under DOS, Windows 9x, and Windows Me, but not under Windows NT, 2000, or XP. (For more information on Matrox boards, see a separate section on this page.)

Please contact me if you have information on using WPDOS graphics mode with any video chip or board not specifically mentioned on this page.

Which video hardware for WPDOS graphics?

For high-quality WPDOS graphics, you will probably need a modern video card, or a motherboard that has modern video graphics hardware built-in. This includes virtually any motherboard made after 2006 that includes integrated Intel graphics. For details, see the section on video cards below.

If, like every modern computer, your computer uses a flat-panel (LCD) monitor, instead of a CRT-tube monitor, you will probably need to choose a monitor that uses a DVI (see the illustration below), HDMI, or DisplayPort connection — either in addition to or instead of an old-style VGA connection. (Search the web for illustrations of HDMI and DisplayPort). You will also need a video card or laptop hardware that includes a DVI, HDMI, or DisplayPort connector; your card may also include a VGA connector, but it almost certainly will need a DVI, HDMI, or DisplayPort connector if you want to use WPDOS graphics. The cable that connects the DVI connector on your video card to the DVI connector on your monitor looks like the cable on the left in the illustrations below:

DVI — use this cable:

The connector ends on a DVI cable are typically white in color, and the pins are flat, not round. The connector is rectangular, with two rounded corners.

VGA — do not use this:

The connector ends on a VGA cable are typically blue or black, and the pins are round and needle-like. The connector is trapezoidal, not rectangular.

If you want to use WPDOS graphics with a flat-panel monitor, you will almost certainly need a DVI, HDMI, or DisplayPort cable and a monitor and video card with DVI, HDMI, or DisplayPort connectors.

Note: After around 2015, you may not need to think about these matters, because HDMI and DisplayPort will be the only ports available on computers built after that date. HDMI and DisplayPort work perfectly well with WPDOS graphics.

Which video card for WPDOS graphics?

This is a vexed and vexing question, and the answer may change almost any day. Briefly, to use high-resolution VESA graphics with WPDOS on a desktop computer, you will almost certainly need a separate video card, not the built-in graphics built into inexpensive motherboards. Some video cards can display high-resolution VESA graphics; some cannot; some can do so under earlier versions of Windows but not under Windows XP or Windows Vista; some can do so with some version of the Windows XP or Vista driver software but not with others; some combinations of LCD monitors and video hardware can display VESA graphics effortlessly; other combinations require the use of a DVI connection (see below) and will not display VESA graphics with a conventional VGA connector.

Desktop video cards based on Nvidia graphics chips:

Recent desktop video cards based on Nvidia chips seem to support VESA graphics extremely well if and only if they are used either with a flat-panel LCD monitor that uses a DVI, HDMI, or DisplayPort connector or a traditional CRT (television-tube-style) monitor. Older models (through the GeForce 7×00 series) provide a continuous underline in monochrome mode; more recent models provide a dashed underline, with a slight gap between the underlines beneath each letter.

Important note: Not every combination of video card and monitor supports VESA graphics, and some combinations of video card and monitor do not permit any WordPerfect graphics to display at all. I was unable to switch to any WordPerfect graphics mode with an Nvidia GeForce 7300-based card, although a GeForce 7600-based card worked perfectly. It is at least possible that the 7300-based card would have worked correctly with a different monitor from the one I used. Please do not ask me why any specific combination of monitor and video card do not work correctly. I do not know the answer to any such question.

Desktop hardware based on ATI video chips:

Recent desktop video cards based on ATI chips seem to support VESA graphics extremely well. When I experimented with one such card, VESA graphics were solid and stable under Windows XP with the latest drivers from ATI (now AMD)’s web site. However, the hardware-based font used in full-screen DOS and WPDOS sessions seems quite ugly, although ATI seems to have improved it in recent years. Older ATI desktop hardware provided a dashed underline in monochrome mode, but recent models provide a continuous underline.

Laptop hardware based on ATI video chips:

Video hardware based on the ATI Mobility chip in recent laptop computers displays VESA graphics extremely well, has a less ugly hardware font than ATI’s desktop hardware, and uses a continuous underline. Such chips are likely to work well with WPDOS.

Laptop and desktop hardware based on Intel Graphics Accelerator chips:

Intel graphics hardware can generally display VESA graphics and work smoothly with WPDOS in graphics mode. You may need to use the patched version of the WPDOS 6.x VESA driver available elsewhere on this page.

Macintosh hardware:

Windows XP can be installed on Intel-based Macintosh computers through the Mac OS X Boot Camp feature, and WordPerfect for DOS can be run full-screen in such Windows XP systems. Any WPDOS graphics mode screen will look excessively wide on all current Macintosh systems, because current Macintosh monitors (whether separate or built-in to a portable computer) are all wide-screen models. Presumably, a Mac Mini or similar standalone machine attached to a conventional monitor will not show this problem.

Except for the inevitably wide screen, any high-resolution VESA graphics mode for WPDOS 5.1 will run perfectly on older Macintosh systems that use the ATI Radeon X1600 or HD 2600 graphics hardware (and presumably the HD 2400 also); unfortunately, VESA graphics for WPDOS 6.x will not work on such systems (although standard VGA graphics mode works perfectly). I have not tested any other ATI graphics hardware used on Macintosh computers.

Except for the inevitably wide screen, any high-resolution VESA graphics mode for WPDOS 5.1 will run perfectly on Macintosh systems that use the Intel GMA X3100 graphics hardware; VESA graphics for WPDOS 6.x may also be used on such systems, but only after WPDOS displays multiple «Divide overflow» error messages when switching from text to graphics mode. I have not tested any other Intel graphics hardware used on Macintosh computers.

I have not tested WPDOS on Macintosh computers that use Nvidia graphics hardware.

If you have any additional information, please send me feedback.

Цукерберг рекомендует:  Android - android. Вопрос про работу с ArrayList

A WPDOS 5.1 VESA driver for high-resolution graphics

A VESA graphics driver for WPDOS 5.1. On most recent computers, the print preview screen in WordPerfect for DOS 5.1 is limited to a low-resolution, high-flicker image. But a VESA graphics driver has been written for WordPerfect 5.1 that will give 5.1 users the same high-resolution, low-flicker images available under WordPerfect for DOS 6.x. The was written by Michal Necasek, a graphics engineer for SciTech Software, who has generously made it available at no charge. Download it in this zip archive; open the archive file in Windows Explorer (under Windows XP) or with any Zip management program; extract the VESA.VRS file and copy it into your WPDOS 5.1 directory. Further instructions are included in a Readme file in the archive.

This VESA.VRS driver may also be used with PlanPerfect 5.x and DrawPerfect 1.x.


To reduce screen flicker when using this driver with a traditional tube-style CRT monitor, use one of the VESA utilities listed elsewhere on this page.

Warning: The VESA graphics standard may or may not be supported by your video hardware, so there is no guarantee that this driver will work on your system. See the discussion of video hardware above.

Special note for users of older video cards (especially Matrox cards): If you receive an «invalid driver» message when you select one of the higher resolutions available with this driver (e.g. 1024×768), check the version of your graphic card’s BIOS and make sure you have updated to the latest version. Some older Matrox cards (and other cards) do not have a true VESA-compatible BIOS. This problem is not caused by the WPDOS VESA driver; the problem is caused by your video card. If you own a Matrox card based on the G100, G200, or G400 chip, you can install a memory-resident program that will make possible high-resolution graphics with the WPDOS VESA driver; see the details in the note on Matrox boards elsewhere on this page.

Note: On some systems that use a flat-panel LC monitor connected to the computer with a traditional analog (VGA) cable, two minor problems with the VESA driver have been observed in DrawPerfect only; these problems do not occur with a flat-panel LCD monitor connected to the computer by a digital (DVI) cable. At 1024×768 resolution (only), the DrawPerfect List Files screen displays an extra character at the left side of any line that includes a file name. At 1280×1024 (only), the lower edges of the dropdown menus remain visible after the menu is closed; the workaround is to record a macro that switches between the two screens and back (Shift-F3 twice) and assign it to an Alt-key. When the menu fragments appear, run the macro to restore the screen.

«Divide Overflow» error messages in WPDOS 6.x

When switching from text mode to graphics mode in WPDOS 6.x, you may see one or more error messages that say «Divide Overflow», and then graphics mode may display normally. This error message seems to result from some obscure conflict in your video hardware. The only solution seems to be to change to a different video card, or sometimes to a different monitor, although it is sometimes possible to fix the problem by making fine adjustments in the Windows video driver using special-purpose software for this task. (Please do not ask me about such software; I know nothing about any such software currently available.)

If you are using a laptop computer, and encounter these error messages, then there is probably no solution, as you cannot change the graphics card or monitor that is built into a laptop.

What to do if WPDOS locks up when switching to graphics mode

When you use Alt-F1, Display, and change the Graphics Display Mode in WPDOS, and then switch to graphics mode for Print Preview or any other graphics-based display, WPDOS may «crash» (lock up), and Windows may pop up an error message about «NTVDM» with a warning that WordPerfect has performed an «illegal» instruction. If this occurs, do not worry about it. Simply click any button on the Windows error message to shut down WPDOS; if necessary, right-click on the WordPerfect button on the Windows Taskbar at the foot of the screen, and choose Close; then, if necessary, continue to click OK until WordPerfect is completely closed and has disappeared from the Taskbar. Then start WPDOS again and choose Print Preview; it is very likely that the crash will not occur a second time.

If the crash does occur again, restart WPDOS, return to Alt-F1, Display, and simply choose a different graphics driver or choose Auto-Select. If you are using WPDOS 6.x, and you cannot restart WPDOS because you have set it to begin in graphics mode but it crashes when it starts up, then start WPDOS 6.x with the command-line switch /tx by using the Start menu, then Run, and entering c:\wp62\wp /tx ( or a similar command using the actual path of your WPDOS program). (This last instruction applies only to WPDOS 6.x, not to WPDOS 5.1, which can only start in text mode, not in graphics mode.)

Technical note: The reason WPDOS sometimes crashes when you first change to a new graphics mode, but does not crash after you restart it seems to be this: The first time you switch into graphics mode, the program apparently tries to access memory that it has not reserved for itself when it first started up. This is harmless under earlier versions of Windows, but causes a crash under Windows 2000, XP, or Vista. The next time you start WPDOS, the program will reserve the correct amount of memory when it starts up, and the problem will not occur.

Improve the smoothness of mouse movement for WPDOS 6.x under Windows

If you create or edit documents in the page or graphics mode of WPDOS 6.x, you may experience «jerky» or uneven responses from the mouse. Two ways of fixing this problem may be worth trying:

Under Windows 95 or 98: Edit your c:\Autoexec.bat file (or create one if you do not have one) and add a line that loads a DOS-based mouse driver. This will typically have a name like MOUSE.COM. Add a line to your Autoexec.bat file that loads this driver. (If you do not how to do this, search for help online or consult a knowledgeable friend.) Note that this probably will not help the performance of a mouse connected to a USB port.

Under Windows 2000 or XP: Install Tame on your system. It will probably improve the performance of the mouse and everything else in DOS-based programs.

Flicker-free high-resolution graphics with CRT monitors

This section applies only to systems with old-style CRT monitors. Ignore this section entirely if you have a modern LCD (flat-panel) monitor.

Few if any current graphics board come with software that sets the refresh rate for DOS graphics applications, so WordPerfect’s graphics screens display at the default refresh rate of 60Hz, with an irritating flicker on CRT monitors, instead of a restful 75Hz or higher. If the board supports the VESA graphics standard (see the section above), and works with the WPDOS 6.x VESA driver or the new WPDOS 5.1 VESA driver, a third-party solution may provide the answer.

Some older boards will not work directly with the WPDOS VESA driver, but can be made to work with it through third-party utilities. The most effective of these is SciTech Display Doctor, which includes a memory-resident utility called UniVBE that allows you to select the VESA graphics driver in WPDOS and set refresh rates for DOS or Windows 9x; use the DOS-based component of this product, not the Windows driver, which is less reliable. SciTech formerly offered freely downloadable versions of this software on its FTP site, but these no longer seem to be available.

For many recent boards that support the VESA 3.0 standard, but do not include utilities that let you set DOS refresh rates for the VESA driver, two third-party solutions to the problem are available: the freeware VBEHz utility, and the (highly recommended) shareware Unirefresh utility by Rob Muller. (Download the program from one of the links on the MajorGeeks.com site; you may need to try more than one link.) These programs work with many graphics boards made in the late 1990s and early 2000s based on Nvidia and 3Dfx chips, and the Matrox G450 (and possibly the G200 and G400 if upgraded with a later BIOS formerly available on Matrox’s web site); I have not tested it with ATI graphics hardware. Both these software solutions work under DOS, Windows 9x, and Windows Me. They will also work with some video boards under Windows 2000 and XP if started from a full-screen Windows 2000 and XP DOS prompt (but not with the Matrox boards; see further notes below). I have not tested these programs under Windows NT.

Windows NT, 2000, and XP provide built-in VESA support for at least some very old and mostly obsolete video boards (such as those based on the Tseng 6000 chip), and, with these boards, Windows NT, 2000, and XP automatically allow WPDOS VESA graphics to display at high refresh rates and without flicker.

If you are certain that your video card supports VESA graphics, but WordPerfect 6.x reports that its VESA driver is incompatible with your hardware, see the note immediately below.

A patched WPDOS 6.x VESA VBE driver for use with some current video cards

If you are using a graphics card that supports VESA graphics, but WordPerfect 6.x refuses to display VESA graphics, a solution to your problem has been generously provided by Haye van den Oever. The WordPerfect VESA VBE driver (VESA.VRS) asks the graphics card’s BIOS how much memory is on the card. If the BIOS reports 16 MB or more, the driver refuses to load, perhaps in order to avoid problems that were common when the driver was written. Unfortunately, because all current graphics cards have far more than 16 MB of memory, VESA.VRS may refuse to load when used with these cards.

Fortunately, the BIOS on many video cards reports that the card has only 4 MB of memory, even if the card really has 16 MB or more. As a result, the original VESA.VRS does work with these cards. Furthermore, many Windows video drivers intercept the request by VESA.VRS and report that the card has only 8 MB or less of memory, no matter how much memory is actually on the card. This means that some cards with a BIOS that reports 64 MB of memory in pure DOS will instead report 8 MB when used from a Windows DOS box, and VESA.VRS will work with these cards when WordPerfect is run from a Windows DOS box, but not when run from pure DOS. To determine how much memory your card’s BIOS reports, you may run VESAMEM.EXE by Haye van den Oever. The Matrox G450 card, for example, reports 32 MB memory when tested in pure DOS, but 8 MB when tested from a Windows DOS box. (Remember, this patched driver is for WPDOS 6.x only!)

If VESAMEM.EXE reports 16 MB or more, you should replace the original WordPerfect VESA.VRS graphics driver (found in your WordPerfect program directory) with a patched copy of VESA.VRS prepared by Haye van den Oever. The file is contained in this self-extracting Vesavrs.exe archive file; after downloading, Vesavrs.exe, run it in a temporary directory to extract the patched VESA.VRS file and copy it to your WordPerfect program directory. This patched version does not test for 16 MB of memory, and will work with any VESA-compatible graphics card, no matter what quantity of memory is reported by its BIOS . The patched version uses English to list the available video modes, but will work with any language-specific version of WPDOS 6.x. If you want a version that lists the video modes in another language, please contact me. If the original VESA driver works with your video card, you will not get any advantage from replacing it with the patched driver.

Note: The patched version of VESA.VRS is known to work under Windows 95, 98, and Me with Matrox and ATI Radeon cards. It may not work as well under Windows NT, 2000, or XP.

A note on Matrox boards

If you use any recent Matrox board in pure DOS (not a Windows DOS box), and you want VESA graphics in WPDOS 6.x, you will almost certainly need the patched version of VESA.VRS described elsewhere on this page.

Older Matrox boards (through the G200 models) include instructions for running two memory-resident programs, VBETSR and VBESETUP, which provide refresh rates higher than 60Hz with VESA graphics and add resolutions not supported by the BIOS in these boards.

The G400 series uses a similar program called VBEXT, but it suffers from some limitations that may be overcome by using the freeware utilities included in this self-extracting file provided by Haye van den Oever. See the enclosed text files for details.

An alternative solution for Matrox G100, G200, and G400 series boards is a third-party utility that enables high-resolution graphics when used together with the WPDOS VESA driver. The utility, Gx00VBE, by Carsten Sørenson («SurfSmurf»), may be downloaded in this self-extracting archive (run the self-extracting program in a temporary directory; move Gx00VBE.EXE to a convenient directory and run it from a batch file that launches WPDOS).

The G450 series supports high-resolution VESA graphics without the use of a memory-resident utility, but only at the default 60Hz refresh rate. You may obtain higher refresh rates in DOS or a Windows DOS box by installing the VBEHz utility described elsewhere on this page.

Unfortunately, VESA graphics are not available with any Matrox board in Windows NT, 2000, or XP, even though the boards support VESA graphics in DOS, Windows 9x, and Windows Me.

Important: Note that the Matrox VESA implementation does not support 16-color modes at high resolutions; you must choose a 256-color mode in WordPerfect.

For a note on Matrox boards in monochrome mode, see this site’s text mode survival guide.

Don’t choose the ATI driver with modern ATI hardware

Read this paragraph if you have ATI video hardware in your computer. Under Shift-F1, Display you may be tempted to select one or more of the ATI options for your text or graphics display type. Unless your ATI card was manufactured before around 1995, do not choose these options! You will only make your WP setup more or less unusable. These options do not work with any ATI hardware used on current computers. Instead, choose AutoSelect from the menu at the foot or side of the screen, or choose «IBM VGA» (or some similar item), and, if you want, choose a font type if a font type setting is available under «IBM VGA.» If your system includes a VESA graphics driver, you may want to experiment with it, but the only selection that is guaranteed to work is AutoSelect or IBM VGA.

Monitor recommendations


Brief notes on flat-panel and CRT monitors may be found on this site’s text mode survival guide page.

Help! I need to download a new driver for my video card!

If your computer will not display WPDOS on screen, or if it displays an error message about being unable to display a video mode when you try to start WPDOS, or if it locks up when you Alt-Tab between WPDOS and the Windows desktop, you may be able to solve the problem by updating the Windows drivers for your video card. (But the problem may also be unsolvable.)

To update your Windows video driver, first try Windows Update, which is available either from your Start Menu or from Internet Explorer’s Tools menu. If a video driver update is listed among the available updates, install it.

If Windows Update does not list an update, you will need to download a driver from the video card manufacturer’s web site. You probably have video hardware made either by Nvidia, ATI, or Intel. To determine which you have, right-click on an empty area of the Windows desktop; choose Properties from the pop-up menu; and go to the Settings tab. Under «Display» you should see a description of your video hardware, in the form «[the name of your monitor] on [the name of your video hardware].» Write down the name of your video hardware.

Important note: If you have a Dell computer, do not follow the instructions below, but use only a video driver downloaded from Dell’s web site. Go to the site, create an account for your computer, and follow the instructions for downloading and installing new video drivers.

If the name of your video hardware includes Nvidia, download a new driver from Nvidia’s web site; start where it says «Start here» and follow the prompts. You should probably begin by clicking Graphics Driver; then select the hardware type that most closely matches the name of your video hardware; then your Windows version. Download and install the driver, following the instructions on the site.

If the name includes ATI, download a new driver from ATI (now AMD)’s web site; start by selecting your Windows version; then Graphic Driver; then the hardware type that most closely matches the name of your video hardware; if you do not find a close match, try Legacy Products instead of Graphic Driver in the middle column. Download and install the driver, following the instructions on the site.

If the name includes Intel, download a new driver from Intel’s web site; start by clicking Graphics from the column on the left; choose the graphics controller that most closely matches the name of your video hardware; select your Windows version; and download the driver marked «Latest Available» that does not say it is «intended for use by developers.» Install the driver, following the instructions on the site.

If the name includes the name of some other manufacturer, you will need to find the manufacturer’s web site and follow a similar procedure to download a new video driver.

Drawing pixels in VESA graphic mode

How to draw a pixel in VESA graphic mode?

I am trying interrupt 10h function 0ch , but it’s not working. What is wrong?

(Note: I wrote this code in NASM syntax and tested it with qemu)

1 Answer 1

The function Int 10h/AH=0Ch should work even when using a VESA VBE mode.

Make sure to use it correctly, the pixel’s colour goes into al .

Technically, you should use Int 10h/AX=4F01h to retrieve the video mode information, including bit 2 (2 BIOS output supported) of the mode attributes field, to check if the BIOS functions will work.

Writing a high-resolution image using the BIOS function could be too slow, it may be worth investing in writing directly to a linear or windowed frame buffer.
Writing to a linear framebuffer will probably require using the unreal mode, it’s possible to avoid that by using a windowed framebuffer.
This, besides being slower, is also more cumbersome.

Here is a very simple program that fills 30 rows with a horrible shade of grey.
Note that I stripped all the checks for the sake of compactness and clarity, I made a lot of assumptions to avoid making some math.
This is a bad practice, I used it only for prototyping.
I strongly encourage you to read the full information returned by Int 10h/AX=4F01h and use that information to select the correct window, do the right padding and calculations.

This is in NASM syntax, I usually use TASM (out of affection) for DOS programs but this time I was in a hurry.
The result is

Remember that each scanline can, in general, be padded (the size of a scanline is returned in the video mode information).
For a 1024 pixel wide scanline, with 3x8bpp we have 3072 bytes/scanline, since this is divisible by 4, no padding is likely to happen.
The window start address is given in the granularity unit (also found in the v > The window size is also found in the video mode information.

All this is enough to write to the framebuffer.
A linear framebuffer is easier to handle (padding is still an aspect to consider) once the unreal mode has been set up.

Современная терминология 3D графики

Мир 3D графики, в том числе игровой, наполнен терминами. Терминами, которые не всегда имеют единственно правильное определение. Иногда одни и те же вещи называются по-разному, и наоборот, один и тот же эффект может называться в настройках игры то «HDR», то «Bloom», то «Glow», то «Postprocessing». Большинству людей из похвальбы разработчиков о том, что они встроили в свой графический движок, непонятно, что в реальности имелось в виду.

Статья призвана помочь разобраться, что же значат некоторые из этих слов, наиболее часто употребляемые в подобных случаях. В рамках этой статьи речь пойдет далеко не обо всех терминах 3D графики, а только о тех, которые получили большее распространение в последнее время в качестве отличительных особенностей и технологий, применяемых в игровых графических движках и в качестве наименований графических настроек современных игр. Для начала, настоятельно рекомендую ознакомиться с теоретическими статьями под авторством Александра Медведева.

Если что-то в этой статье и в статьях Александра вам не понятно, то есть смысл начать с самого раннего, с «Терминологии 3D-графики» и других теоретических статей из раздела «Видеосистема» нашего сайта. Эти статьи уже несколько устарели, конечно, но основные, самые начальные и важные данные там есть. Мы же с вами поговорим о более «высокоуровневых» терминах. Основные понятия о 3D графике реального времени и устройстве графического конвейера у вас должны быть. С другой стороны, не ждите математических формул, академической точности и примеров кода — статья предназначена совсем не для этого. Термины

Shader (Шейдер)

Шейдером в широком смысле называется программа для визуального определения поверхности объекта. Это может быть описание освещения, текстурирования, постобработки и т.п. Шейдеры выросли из работ Кука (Cook’s shade trees) и Перлина (Perlin’s pixel stream language). Сейчас наиболее известны шейдеры RenderMan Shading Language. Программируемые шейдеры были впервые представлены в RenderMan компании Pixar, там определены несколько типов шейдеров: light source shaders, surface shaders, displacement shaders, volume shaders, imager shaders. Эти шейдеры чаще всего программно выполняются универсальными процессорами и не имеют полной аппаратной реализации. В дальнейшем, многие исследователи описывали похожие на RenderMan языки, но они уже были предназначены для аппаратного ускорения: система PixelFlow (Olano и Lastra), Quake Shader Language (применен id Software в графическом движке игры Quake III, который описывал многопроходный рендеринг), и другие. Peercy сотоварищи разработали технику для того, чтобы программы с циклами и условиями выполнять на традиционных аппаратных архитектурах при помощи нескольких проходов рендеринга. Шейдеры RenderMan разбивались на несколько проходов, которые комбинировались во фреймбуфере. Позднее появились языки, которые мы видим аппаратно ускоренными в DirectX и OpenGL. Так шейдеры были адаптированы для графических приложений реального времени.

Видеочипы раннего времени не были программируемы и исполняли только заранее запрограммированные действия (fixed-function), например, алгоритм освещения был жестко зафиксирован в железе, и нельзя было ничего изменить. Затем, компании-производители видеочипов постепенно ввели в свои чипы элементы программируемости, сначала это были очень слабые возможности (NV10, известный как NVIDIA GeForce 256, уже был способен на некоторые примитивные программы), которые не получили программной поддержки в Microsoft DirectX API, но со временем возможности постоянно расширялись. Следующий шаг был за и NV20 (GeForce 3) и NV2A (видеочип, примененный в игровой консоли Microsoft Xbox), которые стали первыми чипами с аппаратной поддержкой шейдеров DirectX API. Версия Shader Model 1.0/1.1, появившаяся в DirectX 8, была сильно ограничена, каждый шейдер (особенно это относится к пиксельным) мог быть сравнительно малой длины и сочетать весьма ограниченный набор команд. В дальнейшем, Shader Model 1 (SM1 для краткости) была улучшена с пиксельными шейдерами версии 1.4 (ATI R200), которые предлагали большую гибкость, но также имели слишком ограниченные возможности. Шейдеры того времени писались на так называемом assembly shader language, который близок к ассемблеру для универсальных процессоров. Его низкий уровень доставляет определенные сложности для понимания кода и программирования, особенно, когда код программы большой, ведь он далек от элегантности и структурированности современных языков программирования.

Версия Shader Model 2.0 (SM2), появившись в DirectX 9 (что было поддержано видеочипом ATI R300, ставшим первым GPU с поддержкой шейдерной модели версии 2.0), серьезно расширила возможности шейдеров реального времени, предложив более длинные и сложные шейдеры и заметно расширившийся набор команд. Была добавлена возможность расчетов с плавающей запятой в пиксельных шейдерах, что также стало важнейшим улучшением. DirectX 9, в лице возможностей SM2, также привнес и язык шейдеров высокого уровня — high-level shader language (HLSL), весьма похожий на язык Си. И эффективный компилятор, переводящий HLSL программы в низкоуровневый код, «понятный» для аппаратных средств. Причем, доступно несколько профилей, предназначенных для разных аппаратных архитектур. Теперь, разработчик может писать один код HLSL шейдера и компилировать его при помощи DirectX в оптимальную программу, для установленного у пользователя видеочипа. После этого выходили чипы от NVIDIA, NV30 и NV40, которые улучшили возможности аппаратных шейдеров еще на шаг, добавив еще более длинные шейдеры, возможности динамических переходов в вершинных и пиксельных шейдерах, возможность выборки текстур из вершинных шейдеров и др. С тех пор пока качественных изменений не было, они ожидаются ближе к концу 2006 года в DirectX 10…

В целом, шейдеры добавили к графическому конвейеру множество новых возможностей по трансформации и освещению вершин и индивидуальной обработке пикселей так, как этого хотят разработчики каждого конкретного приложения. И все-таки, возможности аппаратных шейдеров до сих пор не раскрыты в приложениях полностью, а ведь с увеличением их возможностей в каждом новом поколении «железа», мы скоро увидим уровень тех самых шейдеров RenderMan, которые когда-то казались недостижимыми для игровых видеоускорителей. Пока в шейдерных моделях реального времени, поддерживаемых на сегодняшний день аппаратными видеоускорителями, определено лишь два типа шейдеров: Vertex Shader и Pixel Shader (в определении DirectX 9 API). В будущем DirectX 10 к ним обещает добавиться еще и Geometry Shader.

Vertex Shader (Вершинный Шейдер)

Вершинные шейдеры — это программы, выполняемые видеочипами, которые производят математические операции с вершинами (vertex, из них состоят 3D объекты в играх), иначе говоря, они предоставляют возможность выполнять программируемые алгоритмы по изменению параметров вершин и их освещению (T&L — Transform & Lighting). Каждая вершина определяется несколькими переменными, например, положение вершины в 3D пространстве определяется координатами: x, y и z. Вершины также могут быть описаны характеристиками цвета, текстурными координатами и т.п. Вершинные шейдеры, в зависимости от алгоритмов, изменяют эти данные в процессе своей работы, например, вычисляя и записывая новые координаты и/или цвет. То есть, входные данные вершинного шейдера — данные об одной вершине геометрической модели, которая в данный момент обрабатывается. Обычно это координаты в пространстве, нормаль, компоненты цвета и текстурные координаты. Результирующие данные выполняемой программы служат входными для дальнейшей части конвейера, растеризатор делает линейную интерполяцию входных данных для поверхности треугольника и для каждого пикселя исполняет соответствующий пиксельный шейдер. Очень простой и грубый (но наглядный, надеюсь) пример: вершинный шейдер позволяет взять 3D объект сферы и вершинным шейдером сделать из него зеленый куб :).

До появления видеочипа NV20 у разработчиков было два пути, либо использовать собственные программы и алгоритмы, изменяющие параметры вершин, но тогда все расчеты делал бы CPU (software T&L), либо полагаться на фиксированные алгоритмы в видеочипах, с поддержкой аппаратной трансформации и освещения (hardware T&L). Первая же шейдерная модель DirectX означала большой шаг вперед от фиксированных функций по трансформации и освещению вершин к полностью программируемым алгоритмам. Стало возможным, например, выполнять алгоритм скининга полностью на видеочипах, а до этого единственной возможностью было их исполнение на универсальных центральных процессорах. Теперь, с сильно улучшенными со времен упомянутого чипа NVIDIA возможностями, с вершинами при помощи вершинных шейдеров можно делать уже очень многое (кроме их создания, разве что)…

Примеры того, как и где применяются вершинные шейдеры:

    Скининг (skinning). Matrix pallete skinning для скелетной анимации персонажей с большим количеством «костей». Примеры вы видите практически во всех играх. Но приведу один скриншот из Call of Duty 2, над вершинами каждого из персонажей поработал алгоритм скининга. Причем, с шейдерами версии 3.0 сделать скининг стало заметно проще, для шейдеров версии 1.1 нужно было писать несколько шейдеров для каждого вида скининга (с определенным количеством «костей»).

Pixel Shader (Пиксельный Шейдер)

Пиксельные шейдеры — это программы, выполняемые видеочипом во время растеризации для каждого пикселя изображения, они производят выборку из текстур и/или математические операции над цветом и значением глубины (Z-buffer) пикселей. Все инструкции пиксельного шейдера выполняются попиксельно, после того, как операции с трансформированием и освещением геометрии завершены. Пиксельный шейдер в итоге своей работы выдает конечное значение цвета пикселя и Z-значение для последующего этапа графического конвейера, блендинга. Наиболее простой пример пиксельного шейдера, который можно привести: банальное мультитекстурирование, просто смешение двух текстур (diffuse и lightmap, например) и наложение результата вычисления на пиксель.

До появления видеочипов с аппаратной поддержкой пиксельных шейдеров, у разработчиков были лишь возможности по обычному мультитекстурированию и альфа-блендингу, что существенно ограничивало возможности по многим визуальным эффектам и не позволяло делать многое из того, что сейчас доступно. И если с геометрией еще что-то можно было делать программно, то с пикселями — нет. Ранние версии DirectX (до 7.0 включительно) всегда выполняли все расчеты повершинно и предлагали крайне ограниченную функциональность по попиксельному освещению (вспоминаем EMBM — environment bump mapping и DOT3) в последних версиях. Пиксельные шейдеры сделали возможным освещение любых поверхностей попиксельно, используя запрограммированные разработчиками материалы. Появившиеся в NV20 пиксельные шейдеры версии 1.1 (в понимании DirectX) уже могли не только делать мультитекстурирование, но и многое другое, хотя большинство игр, использующих SM1, просто использовали традиционное мультитекстурирование на большинстве поверхностей, выполняя более сложные пиксельные шейдеры лишь на части поверхностей, для создания разнообразных спецэффектов (все знают, что вода до сих пор является наиболее частым примером использования пиксельных шейдеров в играх). Сейчас, после появления SM3 и поддерживающих их видеочипов, возможности пиксельных шейдеров доросли уже до того, чтобы с их помощью делать даже трассировку лучей (raytracing), пусть пока с некоторыми ограничениями.

Цукерберг рекомендует:  C++ - Чем обусловлена популярность Python’а


Примеры применения пиксельных шейдеров:

    Мультитекстурирование. Несколько слоев текстур (colormap, detailmap, lightmap и т.д.). Используется вообще во всех играх.

Procedural Textures (Процедурные Текстуры)

Процедурные текстуры — это текстуры, описываемые математическими формулами. Такие текстуры не занимают в видеопамяти места, они создаются пиксельным шейдером «на лету», каждый их элемент (тексель) получается в результате исполнения соответствующих команд шейдера. Наиболее часто встречающиеся процедурные текстуры: разные виды шума (например, fractal noise), дерево, вода, лава, дым, мрамор, огонь и т.п., то есть те, которые сравнительно просто можно описать математически. Процедурные текстуры также позволяют использовать анимированные текстуры при помощи всего лишь небольшой модификации математических формул. Например, облака, сделанные подобным образом, выглядят вполне прилично и в динамике и в статике.

Преимущества процедурных текстур также включают в себя неограниченный уровень детализации каждой текстуры, пикселизации просто не будет, текстура как бы всегда генерируется под необходимый для ее отображения размер. Большой интерес представляет и анимированный Normal Mapping, с его помощью можно сделать волны на воде, без применения предпросчитанных анимированных текстур. Еще один плюс таких текстур в том, что чем больше их применяется в продукте, тем меньше работы для художников (правда, больше для программистов) над созданием обычных текстур.

К сожалению, процедурные текстуры не получили пока должного применения в играх, в реальных приложениях до сих пор зачастую проще загрузить обычную текстуру, объемы видеопамяти растут не по дням, а по часам, в самых современных ускорителях ставят уже 512 мегабайт выделенной видеопамяти, которую надо чем-то занимать. Более того, до сих пор чаще делают наоборот — для ускорения математики в пиксельных шейдерах используют lookup tables (LUT) — специальные текстуры, содержащие заранее просчитанные значения, получаемые в результате вычислений. Чтобы не считать для каждого пикселя несколько математических команд, просто читают заранее вычисленные значения из текстуры. Но чем дальше, тем сильнее акцент должен смещаться именно в сторону математических вычислений, взять те же видеочипы ATI нового поколения: RV530 и R580, у которых на каждые 4 и 16 текстурных блоков приходится 12 и 48 пиксельных процессоров, соответственно. Тем более, если речь о 3D текстурах, ведь если двухмерные текстуры без проблем можно разместить в локальной памяти ускорителя, то 3D текстуры требуют ее намного больше.

Примеры процедурных текстур:

Bump Mapping/Specular Bump Mapping

Бампмаппинг — это техника симуляции неровностей (или моделирования микрорельефа, как больше нравится) на плоской поверхности без больших вычислительных затрат и изменения геометрии. Для каждого пикселя поверхности выполняется вычисление освещения, исходя из значений в специальной карте высот, называемой bumpmap. Это обычно 8-битная черно-белая текстура и значения цвета текстуры не накладываются как обычные текстуры, а используются для описания неровности поверхности. Цвет каждого текселя определяет высоту соответствующей точки рельефа, большие значения означают большую высоту над исходной поверхностью, а меньшие, соответственно, меньшую. Или наоборот.

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

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

Для продолжения необходимо напомнить о составляющих освещения. Цвет точки поверхности рассчитывается как сумма ambient, diffuse и specular составляющих от всех источников света в сцене (в идеале от всех, зачастую многими пренебрегают). Вклад в это значение от каждого источника света зависит от расстояния между источником света и точкой на поверхности.

Составляющие освещения:

А теперь добавим к этому бампмаппинг:

Равномерная (ambient) составляющая освещения — аппроксимация глобального освещения, «начальное» освещение для каждой точки сцены, при котором все точки освещаются одинаково и освещенность не зависит от других факторов.
Диффузная (diffuse) составляющая освещения зависит от положения источника освещения и от нормали поверхности. Эта составляющая освещения разная для каждой вершины объекта, что придает им объем. Свет уже не заполняет поверхность одинаковым оттенком.
Бликовая (specular) составляющая освещения проявляется в бликах отражения лучей света от поверхности. Для ее расчета, помимо вектора положения источника света и нормали, используются еще два вектора: вектор направления взгляда и вектор отражения. Specular модель освещения впервые предложил Фонг (Phong Bui-Tong). Эти блики существенно увеличивают реалистичность изображения, ведь редкие реальные поверхности не отражают свет, поэтому specular составляющая очень важна. Особенно в движении, потому что по бликам сразу видно изменение положения камеры или самого объекта. В дальнейшем, исследователи придумывали иные способы вычисления этой составляющей, более сложные (Blinn, Cook-Torrance, Ward), учитывающие распределение энергии света, его поглощение материалами и рассеивания в виде диффузной составляющей.

Итак, Specular Bump Mapping получается таким образом:

И посмотрим то же самое на примере игры, Call of Duty 2:

Что касается первого аппаратного применения, то некоторые виды бампмаппинга (Emboss Bump Mapping) стали использовать еще во времена видеокарт на базе чипов NVIDIA Riva TNT, однако техники того времени были крайне примитивны и широкого применения не получили. Следующим известным типом стал Environment Mapped Bump Mapping (EMBM), но аппаратной его поддержкой в DirectX в то время обладали только видеокарты Matrox, и опять применение было сильно ограничено. Затем появился Dot3 Bump Mapping и видеочипы того времени (GeForce 256 и GeForce 2) требовали три прохода для того, чтобы полностью выполнить такой математический алгоритм, так как они ограничены двумя одновременно используемыми текстурами. Начиная с NV20 (GeForce3), появилась возможность делать то же самое за один проход при помощи пиксельных шейдеров. Дальше — больше. Стали применять более эффективные техники, такие как Normal Mapping.

Примеры применения бампмаппинга в играх:

Displacement Mapping

Наложение карт смещения (Displacement Mapping) является методом добавления деталей к трехмерным объектам. В отличие от бампмаппинга и других попиксельных методов, когда картами высот правильно моделируется только освещенность точки, но не изменяется ее положение в пространстве, что дает лишь иллюзию увеличения сложности поверхности, карты смещения позволяют получить настоящие сложные 3D объекты из вершин и полигонов, без ограничений, присущих попиксельным методам. Этот метод изменяет положение вершин треугольников, сдвигая их по нормали на величину, исходя из значений в картах смещения. Карта смещения (displacement map) — это обычно черно-белая текстура, и значения в ней используются для определения высоты каждой точки поверхности объекта (значения могут храниться как 8-битные или 16-битные числа), схоже с bumpmap. Часто карты смещения используются (в этом случае они называются и картами высот) для создания земной поверхности с холмами и впадинами. Так как рельеф местности описывается двухмерной картой смещения, его относительно легко деформировать при необходимости, так как это потребует всего лишь модификации карты смещения и рендеринга на ее основе поверхности в следующем кадре.

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

Большим преимуществом наложения карт смещения является не просто возможность добавления деталей к поверхности, а практически полное создание объекта. Берется низкополигональный объект, разбивается (тесселируется) на большее количество вершин и полигонов. Вершины, полученные в результате тесселяции, затем смещаются по нормали, исходя из значения, прочитанного в карте смещения. Получаем в итоге сложный 3D объект из простого, используя соответствующую displacement карту:

Наложение карт смещения впервые получило поддержку в DirectX 9.0. Это была первая версия данного API, которая поддержала технику Displacement Mapping. В DX9 поддерживается два типа наложения карт смещения, filtered и presampled. Первый метод был поддержан забытым уже видеочипом MATROX Parhelia, а второй — ATI RADEON 9700. Filtered метод отличается тем, что позволяет использовать мип-уровни для карт смещения и применять для них трилинейную фильтрацию. В таком методе мип-уровень карты смещения выбирается для каждой вершины на основе расстояния от вершины до камеры, то есть уровень детализации выбирается автоматически. Таким образом достигается почти равномерное разбиение сцены, когда треугольники имеют примерно одинаковый размер.

Наложение карт смещения можно по существу считать методом сжатия геометрии, использование карт смещения снижает объем памяти, требуемый для определенной детализации 3D модели. Громоздкие геометрические данные замещаются простыми двухмерными текстурами смещения, обычно 8-битными или 16-битными. Это снижает требования к объему памяти и пропускной способности, необходимой для доставки геометрических данных к видеочипу, а эти ограничения являются одними из главных для сегодняшних систем. Или же, при равных требованиях к пропускной способности и объему памяти, наложение карт смещения позволяет использовать намного более сложные геометрически 3D модели. Применение моделей значительно меньшей сложности, когда вместо десятков или сотен тысяч треугольников используют единицы тысяч, позволяет еще и ускорить их анимацию. Или же улучшить, применив более сложные комплексные алгоритмы и техники, вроде имитации тканей (cloth simulation).

Другое преимущество в том, что применение карт смещения превращает сложные полигональные трехмерные сетки в несколько двухмерных текстур, которые проще поддаются обработке. Например, для организации Level of Detail можно использовать обычный мип-маппинг для наложения карт смещения. Также, вместо сравнительно сложных алгоритмов сжатия трехмерных сеток можно применять привычные методы сжатия текстур, даже JPEG-подобные. А для процедурного создания 3D объектов можно использовать обычные алгоритмы для двухмерных текстур.

Но у карт смещения есть и некоторые ограничения, они не могут быть применены во всех ситуациях. Например, гладкие объекты, не содержащие большого количества тонких деталей, будут лучше представлены в виде стандартных полигональных сеток или иных поверхностей более высокого уровня, вроде кривых Безье. С другой стороны, очень сложные модели, такие как деревья или растения, также нелегко представить картами смещения. Есть также проблемы удобства их применения, это почти всегда требует специализированных утилит, ведь очень сложно напрямую создавать карты смещения (если речь не идет о простых объектах, вроде ландшафта). Многие проблемы и ограничения, присущие картам смещения, совпадают с таковыми у наложения карт нормалей, поскольку эти два метода по сути — два разных представления похожей идеи.

В качестве примера из реальных игр приведу игру, в которой используется выборка текстур из вершинного шейдера, возможность, появившаяся в видеочипах NVIDIA NV40 и шейдерной модели 3.0. Вершинное текстурирование можно применить для полностью выполняемого видеочипом простого метода наложения карт смещения, без тесселяции (разбиения на большее количество треугольников). Применение такому алгоритму ограничено, они имеют смысл, только если карты будут динамическими, то есть, будут изменяться в процессе. Например, это рендеринг больших водных поверхностей, что и сделано в игре Pacific Fighters:

Normal Mapping

Нормалмаппинг — это улучшенная разновидность техники бампмаппинга, описанной ранее, расширенная ее версия. Бампмаппинг был разработан Блинном (Blinn) еще в 1978 году, нормали поверхности при этом методе наложения рельефа изменяются на основе информации из карт высот (bump map). В то время как бампмаппинг всего лишь изменяет существующую нормаль для точек поверхности, нормалмаппинг полностью заменяет нормали при помощи выборки их значений из специально подготовленной карты нормалей (normal map). Эти карты обычно являются текстурами с сохраненными в них заранее просчитанными значениями нормалей, представленными в виде компонент цвета RGB (впрочем, есть и специальные форматы для карт нормалей, в том числе со сжатием), в отличие от 8-битных черно-белых карт высот в бампмаппинге.

В общем, как и бампмаппинг, это тоже «дешевый» метод для добавления детализации к моделям сравнительно низкой геометрической сложности, без использования большего количества реальной геометрии, только более продвинутый. Одно из наиболее интересных применений техники — существенное увеличение детализации низкополигональных моделей при помощи карт нормалей, полученных обработкой такой же модели высокой геометрической сложности. Карты нормалей содержат более подробное описание поверхности, по сравнению с бампмаппингом и позволяют представить более сложные формы. Идеи по получению информации из высокодетализированных объектов были озвучены в середине 90-х годов прошлого века, но тогда речь шла об использовании для Displacement Mapping. Позднее, в 1998 году, были представлены идеи о перенесении деталей в виде карт нормалей от высокополигональных моделей в низкополигональные.

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

Карты нормалей обычно создаются на основе двух версий модели, низко- и высокополигональной. Низкополигональная модель состоит из минимума геометрии, основных форм объекта, а высокополигональная содержит все необходимое для максимальной детализации. Затем, при помощи специальных утилит они сравниваются друг с другом, разница рассчитывается и сохраняется в текстуре, называемой картой нормалей. При ее создании дополнительно можно использовать и bump map для очень мелких деталей, которые даже в высокополигональной модели не смоделировать (поры кожи, другие мелкие углубления).

Карты нормалей изначально были представлены в виде обычных RGB текстур, где компоненты цвета R, G и B (от 0 до 1) интерпретируются как координаты X, Y и Z. Каждый тексель в карте нормалей представлен как нормаль точки поверхности. Карты нормалей могут быть двух видов: с координатами в model space (общей системе координат) или tangent space (термин на русском — «касательное пространство», локальная система координат треугольника). Чаще применяется второй вариант. Когда карты нормалей представлены в model space, то они должны иметь три компоненты, так как могут быть представлены все направления, а когда в локальной системе координат tangent space, то можно обойтись двумя компонентами, а третью получить в пиксельном шейдере.

Современные приложения реального времени до сих пор сильно проигрывают пререндеренной анимации по качеству изображения, это касается, прежде всего, качества освещения и геометрической сложности сцен. Количество вершин и треугольников, рассчитываемых в реальном времени, ограничено. Поэтому очень важны методы, позволяющие снизить количество геометрии. До нормалмаппинга были разработаны несколько таких методов, но низкополигональные модели даже с бампмаппингом получаются заметно хуже более сложных моделей. Нормалмаппинг хоть и имеет несколько недостатков (самый явный — так как модель остается низкополигональной, это легко видно по ее угловатым границам), но итоговое качество рендеринга заметно улучшается, оставляя геометрическую сложность моделей низкой. В последнее время хорошо видно увеличение популярности данной методики и использование ее во всех популярных игровых движках. «Виной» этому — комбинация отличного результирующего качества и одновременное снижение требований к геометрической сложности моделей. Техника нормалмаппинга сейчас применяется почти повсеместно, все новые игры используют ее максимально широко. Вот лишь краткий список известных ПК игр с использованием нормалмаппинга: Far Cry, Doom 3, Half-Life 2, Call of Duty 2, F.E.A.R., Quake 4. Все они выглядят намного лучше, чем игры прошлого, в том числе из-за применения карт нормалей.

Есть лишь одно негативное последствие применения этой техники — увеличение объемов текстур. Ведь карта нормалей сильно влияет на то, как будет выглядеть объект, и она должна быть достаточно большого разрешения, поэтому требования к видеопамяти и ее пропускной способности удваиваются (в случае несжатых карт нормалей). Но сейчас уже выпускаются видеокарты с 512 мегабайтами локальной памяти, пропускная способность ее постоянно растет, разработаны методы сжатия специально для карт нормалей, поэтому эти небольшие ограничения не слишком важны, на самом деле. Гораздо больше эффект, который дает нормалмаппинг, позволяя использовать сравнительно низкополигональные модели, снижая требования к памяти для хранения геометрических данных, улучшая производительность и давая весьма достойный визуальный результат.

Parallax Mapping/Offset Mapping

После нормалмаппинга, разработанного еще в 1984 году, последовало рельефное текстурирование (Relief Texture Mapping), представленное Olivera и Bishop в 1999 году. Это метод для наложения текстур, основанный на информации о глубине. Метод не нашел применения в играх, но его идея способствовала продолжению работ над параллаксмаппингом и его улучшении. Kaneko в 2001 представил parallax mapping, который стал первым эффективным методом для попиксельного отображения эффекта параллакса. В 2004 году Welsh продемонстрировал применение параллаксмаппинга на программируемых видеочипах.

У этого метода, пожалуй, больше всего различных названий. Перечислю те, которые встречал: Parallax Mapping, Offset Mapping, Virtual Displacement Mapping, Per-Pixel Displacement Mapping. В статье для краткости применяется первое название.
Параллаксмаппинг — это еще одна альтернатива техникам бампмаппинга и нормалмаппинга, которая дает еще большее представление о деталях поверхности, более натуралистичное отображение 3D поверхностей, также без слишком больших потерь производительности. Это техника похожа одновременно на наложение карт смещения и нормалмаппинг, это нечто среднее между ними. Метод тоже предназначен для отображения большего количества деталей поверхности, чем есть в исходной геометрической модели. Он похож на нормалмаппинг, но отличие в том, что метод искажает наложение текстуры, изменяя текстурные координаты так, что когда вы смотрите на поверхность под разными углами, она выглядит выпуклой, хотя в реальности поверхность плоская и не изменяется. Иными словами, Parallax Mapping — это техника аппроксимации эффекта смещения точек поверхности в зависимости от изменения точки зрения.


Техника сдвигает текстурные координаты (поэтому технику иногда называют offset mapping) так, чтобы поверхность выглядела более объемной. Идея метода состоит в том, чтобы возвращать текстурные координаты той точки, где видовой вектор пересекает поверхность. Это требует просчета лучей (рейтрейсинг) для карты высот, но если она не имеет слишком сильно изменяющихся значений («гладкая» или «плавная»), то можно обойтись аппроксимацией. Такой метод хорош для поверхностей с плавно изменяющимися высотами, без просчета пересечений и больших значений смещения. Подобный простой алгоритм отличается от нормалмаппинга всего тремя инструкциями пиксельного шейдера: две математические инструкции и одна дополнительная выборка из текстуры. После того, как вычислена новая текстурная координата, она используется дальше для чтения других текстурных слоев: базовой текстуры, карты нормалей и т.п. Такой метод параллаксмаппинга на современных видеочипах почти также эффективен, как обычное наложение текстур, а его результатом является более реалистичной отображение поверхности, по сравнению с простым нормалмаппингом.

Но использование обычного параллаксмаппинга ограничено картами высот с небольшой разницей значений. «Крутые» неровности обрабатываются алгоритмом некорректно, появляются различные артефакты, «плавание» текстур и пр. Было разработано несколько модифицированных методов для улучшения техники параллаксмаппинга. Несколько исследователей (Yerex, Donnelly, Tatarchuk, Policarpo) описали новые методы, улучшающие начальный алгоритм. Почти все идеи основаны на трассировке лучей в пиксельном шейдере для определения пересечений деталей поверхностей друг другом. Модифицированные методики получили несколько разных названий: Parallax Mapping with Occlusion, Parallax Mapping with Distance Functio ns, Parallax Occlusion Mapping. Для краткости будем их все называть Parallax Occlusion Mapping.

Методы Parallax Occlusion Mapping включают еще и трассировку лучей для определения высот и учета видимости текселей. Ведь при взгляде под углом к поверхности тексели загораживают друг друга, и, учитывая это, можно добавить к эффекту параллакса больше глубины. Получаемое изображение становится реалистичнее и такие улучшенные методы можно применять для более глубокого рельефа, он отлично подходит для изображения кирпичных и каменных стен, мостовой и пр. Нужно особенно отметить, что главное отличие Parallax Mapping от Displacement Mapping в том, что расчеты все попиксельные, а не повершинные. Именно поэтому метод имеет названия вроде Virtual Displacement Mapping и Per-Pixel Displacement Mapping. Посмотрите на картинку, трудно поверить, но камни мостовой тут — всего лишь попиксельный эффект:

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

Также, дополнительное преимущество в том, что карты высот могут динамически изменяться (поверхность воды с волнами, дырки от пуль в стенах и многое другое). В недостатках метода — отсутствие геометрически правильных силуэтов (краев объекта), ведь алгоритм попиксельный и не является настоящим displacement mapping. Зато он экономит производительность в виде снижения нагрузки на трансформацию, освещение и анимацию геометрии. Экономит видеопамять, необходимую для хранения больших объемов геометрических данных. В плюсах у техники и относительно простая интеграция в существующие приложения и использование в процессе работы привычных утилит, применяемых для нормалмаппинга.

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

Postprocessing (Постобработка)

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

Простой пример из фотографии: вы сфотографировали красивое озеро с зеленью при ясной погоде. Небо получается очень ярким, а деревья — слишком темными. Вы загружаете фотографию в графический редактор и начинаете изменять яркость, контраст и другие параметры для участков изображения или для всей картинки. Но вы уже не имеете возможности изменить настройки фотоаппарата, вы делаете обработку готового изображения. Это и есть постобработка. Или другой пример: выделение заднего плана в портретной фотографии и применение blur фильтра к этой области для эффекта depth of field с большей глубиной. То есть, когда вы изменяете или подправляете кадр в графическом редакторе, вы и делаете постобработку. То же самое может делаться и в игре, в реальном времени.

Существует множество разных возможностей по обработке изображения после его рендеринга. Все видели, наверное, в графических редакторах множество так называемых графических фильтров. Это как раз то, что называется постфильтрами: blur, edge detection, sharpen, noise, smooth, emboss и др. В применении к 3D рендерингу в реальном времени это делается так — вся сцена рендерится в специальную область, render target, и после основного рендеринга это изображение дополнительно обрабатывается при помощи пиксельных шейдеров и только потом выводится на экран. Из эффектов постобработки в играх чаще всего используют Bloom, Motion Blur, Depth Of Field. Существует и множество других постэффектов: noise, flare, distortion, sepia и др.

Вот парочка ярких примеров постобработки в игровых приложениях:

High Dynamic Range (HDR)

High Dynamic Range (HDR) в применении к 3D графике — это рендеринг в широком динамическом диапазоне. Суть HDR заключается в описании интенсивности и цвета реальными физическими величинами. Привычной моделью описания изображения является RGB, когда все цвета представлены в виде суммы основных цветов: красного, зеленого и синего, с разной интенсивностью в виде возможных целочисленных значений от 0 до 255 для каждого, закодированных восемью битами на цвет. Отношение максимальной интенсивности к минимальной, доступной для отображения конкретной моделью или устройством, называется динамическим диапазоном. Так, динамический диапазон модели RGB составляет 256:1 или 100:1 cd/m 2 (два порядка). Эта модель описания цвета и интенсивности общепринято называется Low Dynamic Range (LDR).

Возможных значений LDR для всех случаев явно недостаточно, человек способен видеть гораздо больший диапазон, особенно при малой интенсивности света, а модель RGB слишком ограничена в таких случаях (да и при больших интенсивностях тоже). Динамический диапазон зрения человека от 10 -6 до 10 8 cd/m 2 , то есть 100000000000000:1 (14 порядков). Одновременно весь диапазон мы видеть не можем, но диапазон, видимый глазом в каждый момент времени, примерно равен 10000:1 (четырем порядкам). Зрение приспосабливается к значениям из другой части диапазона освещенности постепенно, при помощи так называемой адаптации, которую легко описать ситуацией с выключением света в комнате в темное время суток — сначала глаза видят очень мало, но со временем адаптируются к изменившимся условиям освещения и видят уже намного больше. То же самое случается и при обратной смене темной среды на светлую.

Итак, динамического диапазона модели описания RGB недостаточно для представления изображений, которые человек способен видеть в реальности, эта модель значительно уменьшает возможные значения интенсивности света в верхней и нижней части диапазона. Самый распространенный пример, приводимый в материалах по HDR, — изображение затемненного помещения с окном на яркую улицу в солнечный день. С RGB моделью можно получить или нормальное отображение того, что находится за окном, или только того, что внутри помещения. Значения больше 100 cd/m 2 в LDR вообще обрезаются, это является причиной тому, что в 3D рендеринге трудно правильно отображать яркие источники света, направленные прямо в камеру.

Сами устройства отображения данных пока что серьезно улучшить нельзя, а отказаться от LDR при расчетах имеет смысл, можно использовать реальные физические величины интенсивности и цвета (или линейно пропорциональные), а на монитор выводить максимум того, что он сможет. Суть представления HDR в использовании значений интенсивности и цвета в реальных физических величинах или линейно пропорциональных и в том, чтобы использовать не целые числа, а числа с плавающей точкой с большой точностью (например, 16 или 32 бита). Это снимет ограничения модели RGB, а динамический диапазон изображения серьезно увеличится. Но затем любое HDR изображение можно вывести на любом средстве отображения (том же RGB мониторе), с максимально возможным качеством для него при помощи специальных алгоритмов tone mapping.

HDR рендеринг позволяет изменять экспозицию уже после того, как мы отрендерили изображение. Дает возможность имитировать эффект адаптации человеческого зрения (перемещение из ярких открытых пространств в темные помещения и наоборот), позволяет выполнять физически правильное освещение, а также является унифицированным решением для применения эффектов постобработки (glare, flares, bloom, motion blur). Алгоритмы обработки изображения, цветокоррекцию, гамма-коррекцию, motion blur, bloom и другие методы постобработки качественней выполнять в HDR представлении.

В приложениях 3D рендеринга реального времени (играх, в основном) HDR рендеринг начали использовать не так давно, ведь это требует вычислений и поддержки render target в форматах с плавающей точкой, которые впервые стали доступны только на видеочипах с поддержкой DirectX 9. Обычный путь HDR рендеринга в играх таков: рендеринг сцены в буфер формата с плавающей точкой, постобработка изображения в расширенном цветовом диапазоне (изменение контраста и яркости, цветового баланса, эффекты glare и motion blur, lens flare и подобные), применение tone mapping для вывода итоговой HDR картинки на LDR устройство отображения. Иногда используются карты среды (environment maps) в HDR форматах, для статических отражений на объектах, весьма интересны применения HDR в имитации динамических преломлений и отражений, для этого также могут использоваться динамические карты в форматах с плавающей точкой. К этому можно добавить еще лайтмапы (light maps), заранее рассчитанные и сохраненные в HDR формате. Многое из перечисленного сделано, например, в Half-Life 2: Lost Coast.

HDR рендеринг очень полезен для комплексной постобработки более высокого качества, по сравнению с обычными методами. Тот же bloom будет выглядеть реалистичнее при расчетах в HDR модели представления. Например, как это сделано в игре Far Cry от Crytek, там используются стандартные методы HDR рендеринга: применение bloom фильтров, представленные Kawase и tone mapping оператор Reinhard.

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

Другие примеры применения HDR рендеринга в приложениях реального времени:

Tone Mapping

Tone mapping — это процесс преобразования диапазона яркостей HDR к LDR диапазону, отображаемому устройством вывода, например, монитором или принтером, так как вывод HDR изображений на них потребует преобразования динамического диапазона и цветового охвата модели HDR в соответствующий динамический диапазон LDR, чаще всего модель RGB. Ведь диапазон яркости, представленный в HDR, очень широк, это несколько порядков абсолютного динамического диапазона единовременно, в одной сцене. А диапазон, который можно воспроизвести на привычных устройствах вывода (мониторах, телевизорах), составляет лишь около двух порядков динамического диапазона.

Преобразование из HDR в LDR и называется tone mapping, оно выполняется с потерями и имитирует свойства человеческого зрения. Такие алгоритмы принято называть операторами tone mapping. Операторы разделяют все значения яркости изображения на три разных типа: с темной, средней и яркой освещенностью. На основе оценки яркости средних тонов, корректируется общая освещенность, значения яркости пикселей сцены перераспределяются для того, чтобы войти в выходной диапазон, темные пиксели осветляются, а светлые затемняются. Затем, наиболее яркие пиксели изображения приводятся к диапазону устройства вывода или выходной модели представления. На следующей картинке изображено самое простое приведение HDR изображения к LDR диапазону, линейное преобразование, а к фрагменту в центре применен более сложный оператор tone mapping, работающий так, как было описано выше:

Видно, что только с применением нелинейного tone mapping можно получить максимум деталей в изображении, а если приводить HDR к LDR линейно, то многие мелочи просто теряются. Единственно правильного алгоритма tone mapping нет, существует несколько операторов, дающих хорошие результаты в разных ситуациях. Вот наглядный пример двух разных операторов tone mapping:

Совместно с HDR рендерингом, с недавнего времени tone mapping начали применять в играх. Стало возможным опционально имитировать свойства человеческого зрения: потерю остроты в темных сценах, адаптацию к новым условиям освещения при переходах от очень ярких областей к темным и наоборот, чувствительность к изменению контраста, цвета… Вот так выглядит имитация способности зрения к адаптации в игре Far Cry. Первый скриншот показывает изображение, которое видит игрок, только что повернувшийся от темного помещения к ярко освещенному открытому пространству, а второй — то же изображение через пару секунд, после адаптации.

Цукерберг рекомендует:  Алгоритм - Тестирование нового алгоритма машинного обучения.

Bloom

Bloom — это один из кинематографических эффектов постобработки, при помощи которого наиболее яркие участки изображения делаются еще более яркими. Это эффект очень яркого света, проявляющийся в виде свечения вокруг ярких поверхностей, после применения bloom фильтра такие поверхности не просто получают дополнительную яркость, свет от них (ореол) частично воздействует и на более темные области, соседствующие с яркими поверхностями в кадре. Проще всего показать это на примере:

В 3D графике Bloom фильтр делается при помощи дополнительной постобработки — смешивания смазанного фильтром blur кадра (всего кадра или отдельных ярких его областей, фильтр обычно применяется несколько раз) и исходного кадра. Один из наиболее часто применяемых в играх и других приложениях реального времени алгоритм постфильтра bloom:

  • Сцена рендерится во фреймбуфер, интенсивность свечения (glow) объектов записывается в альфа-канал буфера.
  • Фреймбуфер копируется в специальную текстуру для обработки.
  • Разрешение текстуры уменьшается, например, в 4 раза.
  • К изображению несколько раз применяются фильтры сглаживания (blur), на основе данных об интенсивности, записанных в альфа-канал.
  • Полученное изображение смешивается с оригинальным кадром во фреймбуфере, и результат выводится на экран.

Как и другие виды постобработки, bloom лучше применять при рендеринге в широком динамическом диапазоне (HDR). Дополнительные примеры обработки конечного изображения bloom фильтром из 3D приложений реального времени:

Motion Blur

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

В трехмерной же анимации, в каждый конкретный момент времени (кадр) объекты расположены по определенным координатам в трехмерном пространстве, аналогично виртуальной камере с бесконечно быстрой выдержкой. В результате, смазывание, подобное получаемому камерой и человеческим глазом при взгляде на быстро движущиеся объекты, отсутствует. Это выглядит неестественно и нереалистично. Рассмотрим простой пример: несколько сфер вращаются вокруг некоей оси. Вот изображение того, как это движение будет выглядеть со смазыванием и без него:

По изображению без смазывания нельзя даже сказать, движутся сферы или нет, в то время как motion blur дает четкое представление о скорости и направлении движения объектов. Кстати, отсутствие смазывания при движении служит и причиной того, почему движение в играх при 25-30 кадрах в секунду кажется дерганым, хотя кино и видео при этих же параметрах частоты кадров смотрится прекрасно. Для компенсации отсутствия смазывания в движении желательна или высокая частота кадров (60 кадров в секунду или выше) или использование методов дополнительной обработки изображения, для эмуляции эффекта motion blur. Это применяется и для улучшения плавности анимации и для эффекта фото- и кинореалистичности одновременно.

Самый простой алгоритм motion blur для приложений реального времени заключается в использовании для рендеринга текущего кадра данных из предыдущих кадров анимации. Но есть и более эффективные и современные методы motion blur, которые не используют предыдущие кадры, а основываются на векторах движения объектов в кадре, также добавляя лишь еще один шаг постобработки к процессу рендеринга. Эффект смазывания может быть как полноэкранным (обычно делается постобработкой), так и для отдельных, наиболее быстро движущихся объектов.

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

Depth Of Field (DOF)

Depth of field (глубина резкости), вкратце, это размывание объектов в зависимости от их положения относительно фокуса камеры. В реальной жизни, на фотографиях и в кино мы видим одинаково четко не все объекты, это связано с особенностью строения глаза и устройства оптики фото- и киноаппаратов. У фото- и кинооптики есть определенное расстояние, объекты, расположенные на таком расстоянии от камеры находятся в фокусе и выглядят на картинке резкими, а более удаленные от камеры или приближенные к ней объекты выглядят, наоборот, размытыми, резкость снижается постепенно при увеличении или снижении расстояния.


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

Одним из распространенных методов при рендеринге в реальном времени является смешивание оригинального кадра и его смазанной версии (несколько проходов blur фильтра) на основе данных о глубине для пикселей изображения. В играх, для эффекта DOF есть несколько применений, например, это игровые ролики на движке игры, повторы в спортивных и гоночных играх. Примеры depth of field в реальном времени:

Level Of Detail (LOD)

Уровень детализации (level of detail) в 3D приложениях — это метод снижения сложности рендеринга кадра, уменьшения общего количества полигонов, текстур и иных ресурсов в сцене, общее снижение её сложности. Простой пример: основная модель персонажа состоит из 10000 полигонов. В тех случаях, когда в обрабатываемой сцене он расположен близко к камере, важно, чтобы использовались все полигоны, но на очень большом расстоянии от камеры в итоговом изображении он будет занимать лишь несколько пикселей, и смысла в обработке всех 10000 полигонов нет никакого. Возможно, в этом случае будет достаточно сотни полигонов, а то и пары штук и специально подготовленной текстуры для примерно такого же отображения модели. Соответственно, на средних расстояниях имеет смысл использовать модель, состоящую из количества треугольников большего, чем у самой простой модели, и меньшего, чем у наиболее сложной.

Метод LOD обычно используется при моделировании и рендеринге трехмерных сцен, с использованием нескольких уровней сложности (геометрической или какой-то иной) для объектов, пропорционально расстоянию от них до камеры. Метод часто используется разработчиками игр для снижения количества полигонов в сцене и для улучшения производительности. При близком расположении к камере используются модели с максимумом деталей (количество треугольников, размер текстур, сложность текстурирования), для максимально возможного качества картинки и наоборот, при удалении моделей от камеры используются модели с меньшим количеством треугольников — для увеличения скорости рендеринга. Изменение сложности, в частности, количества треугольников в модели, может происходить автоматически на основе одной 3D модели максимальной сложности, а может — на основе нескольких заранее подготовленных моделей с разным уровнем детализации. Используя модели с меньшей детализацией для разных расстояний, расчетная сложность рендеринга снижается, почти не ухудшая общую детализацию изображения.

Метод особенно эффективен, если количество объектов в сцене велико, и они расположены на разных расстояниях от камеры. Для примера возьмем спортивную игру, такую как симулятор хоккея или футбола. Низкополигональные модели персонажей используются, когда они далеко от камеры, а при приближении, модели заменяются другими, с большим количеством полигонов. Этот пример очень простой и в нем показывается суть метода на основе двух уровней детализации модели, но никто не мешает создать несколько уровней детализации для того, чтобы эффект смены уровня LOD не был слишком заметен, чтобы детали по мере приближения объекта постепенно «прирастали».

Кроме расстояния от камеры, для LOD могут иметь значение и другие факторы — общее количество объектов на экране (когда один-два персонажа в кадре, то используются сложные модели, а когда 10-20, они переключаются на более простые) или количество кадров в секунду (задаются пределы значений FPS, при которых изменяется уровень детализации, например, при FPS ниже 30 снижаем сложность моделей на экране, а при 60, наоборот, повышаем). Другие возможные факторы, влияющие на уровень детализации — скорость перемещения объекта (ракету в движении вы рассмотреть вряд ли успеете, а вот улитку — запросто), важность персонажа с игровой точки зрения (тот же футбол взять — для модели игрока, которым управляете вы, можно использовать более сложную геометрию и текстуры, вы его видите ближе всего и чаще всего). Тут все зависит от желаний и возможностей конкретного разработчика. Главное — не переборщить, частые и заметные изменения уровня детализации раздражают.

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

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

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

Global Illumination

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

Алгоритмы освещения можно разделить на две модели: прямое или локальное освещение и глобальное освещение (direct или local illumination и global illumination). Локальная модель освещения использует расчет прямой освещенности, свет от источников света до первого пересечения света с непрозрачной поверхностью, взаимодействие объектов между собой не учитывается. Хотя такая модель пытается компенсировать это добавлением фонового или равномерного (ambient) освещения, но это самая простая аппроксимация, сильно упрощенное освещение от всех непрямых лучей источников света, которое задает цвет и интенсивность освещения объектов в отсутствии прямых источников света.

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

В глобальной модели освещения, global illumination, рассчитывается освещение с учетом влияния объектов друг на друга, учитываются многократные отражения и преломления лучей света от поверхностей объектов, каустика (caustics) и подповерхностное рассеивание (subsurface scattering). Эта модель позволяет получить более реалистичную картинку, но усложняет процесс, требуя заметно больше ресурсов. Существует несколько алгоритмов global illumination, мы вкратце рассмотрим radiosity (расчет непрямого освещения) и photon mapping (расчет глобального освещения на основе карт фотонов, предрассчитанных при помощи трассировки). Есть и упрощенные методы по симуляции непрямого освещения, такие, как изменение общей яркости сцены в зависимости от количества и яркости источников света в ней или использование большого количества точечных источников света, расставленных по сцене для имитации отраженного света, но все же это далеко от настоящего алгоритма GI.

Алгоритм radiosity это процесс расчета вторичных отражений лучей света от одних поверхностей к другим, а также, от окружающей среды к объектам. Лучи от источников света трассируются до тех пор, пока сила их не снизится ниже определенного уровня или лучи достигнут определенного числа отражений. Это распространенная техника GI, вычисления обычно выполняются перед визуализацией, а результаты расчета можно использовать для рендеринга в реальном времени. Основные идеи radiosity основаны на физике теплового переноса. Поверхности объектов разбиваются на небольшие участки, называемые патчами, и принимается, что отраженный свет рассеивается равномерно во все стороны. Вместо расчета каждого луча для источников света, используется техника усреднения, разделяющая источники света на патчи, основываясь на уровнях энергии, которые они выдают. Эта энергия распределяется между патчами поверхностей пропорционально.

Еще один метод расчета глобальной освещенности предложен Henrik Wann Jensen, это метод фотонных карт photon mapping. Использование фотонных карт — это другой алгоритм расчета глобального освещения, основанный на трассировке лучей и используемый для имитации взаимодействия лучей света с объектами сцены. Алгоритмом рассчитываются вторичные отражения лучей, преломление света через прозрачные поверхности, рассеянные отражения. Этот метод состоит в расчете освещенности точек поверхности в два прохода. В первом выполняется прямая трассировка лучей света с вторичными отражениями, это предварительный процесс, выполняемый перед основным рендерингом. В этом методе рассчитывается энергия фотонов, идущих от источника света к объектам сцены. Когда фотоны достигают поверхности, точка пересечения, направление и энергия фотона сохраняются в кэш, называемый фотонной картой. Фотонные карты могут сохраняться на диске для последующего использования, чтобы не просчитывать их каждый кадр. Отражения фотонов просчитываются до тех пор, пока работа не останавливается после определенного количества отражений или при достижении определенной энергии. Во втором проходе рендеринга выполняется расчет освещения пикселей сцены прямыми лучами, с учетом данных, сохраненных в фотонных картах, энергия фотонов добавляется к энергии прямого освещения.

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

Но вот что давно используют — так это статическое предпросчитанное глобальное освещение, что приемлемо для сцен без изменения положения источников света и больших объектов, сильно влияющих на освещение. Ведь расчет глобального освещения не зависит от положения наблюдателя и если в сцене не изменяется положение таких объектов сцены и параметров источников освещения, то можно использовать заранее просчитанные значения освещенности. Это используют во многих играх, сохраняя данные GI расчетов в виде лайтмапов (lightmaps).

Существуют и приемлемые алгоритмы для имитации глобального освещения в динамике. Например, есть такой простой метод для использования в приложениях реального времени, для расчета непрямого освещения объекта в сцене: упрощенный рендеринг всех объектов с пониженной детализацией (за исключением того, для которого считают освещение), в кубическую карту низкого разрешения (ее также можно использовать для отображения динамических отражений на поверхности объекта), затем фильтрация этой текстуры (несколько проходов blur фильтра), и применение для освещения этого объекта данных из рассчитанной текстуры в качестве дополнения к прямому освещению. В случаях, когда динамический расчет слишком тяжел, можно обойтись статическими radiosity картами. Пример из игры MotoGP 2, на котором хорошо видно благотворное влияние даже такой простой имитации GI:

Напоследок еще один пример direct illumination против global illumination рендеринга, чтобы развеять оставшиеся сомнения о полезности вторичного освещения (источник света один, ambient освещение отсутствует):

Теоретические статьи на нашем сайте под авторством Александра Медведева:

Рисование пикселей в графическом режиме VESA

Как нарисовать пиксель в графическом режиме VESA?

Я пытаюсь прерывать 10h функцию 0ch , но она не работает. Что случилось?

(Примечание: я написал этот код в синтаксисе NASM и протестировал его с помощью qemu)

Функция Int 10h/AH = 0Ch должна работать даже при использовании режима VESA VBE.

Обязательно используйте его правильно, цвет пикселя переходит в al .

Технически вы должны использовать Int 10h/AX = 4F01h для извлечения информации о режиме видео, включая бит 2 (2 выхода BIOS) в поле атрибутов режима, чтобы проверить, будут ли работать функции BIOS.

Запись изображения с высоким разрешением с использованием функции BIOS может быть слишком медленной, возможно, стоит инвестировать в запись непосредственно в линейный или оконный буфер кадров.
Запись в линейный фреймбуфер, вероятно, потребует использования нереального режима, это можно избежать, используя оконный фреймбуфер.
Это, помимо медленного, также более громоздко.

Вот очень простая программа, которая заполняет 30 строк с ужасным оттенком серого.
Обратите внимание, что я разделил все проверки ради компактности и ясности, я сделал много предположений, чтобы избежать математики.
Это плохая практика, я использовал ее только для прототипирования.
Я настоятельно рекомендую вам прочитать полную информацию, возвращаемую Int 10h/AX=4F01h и использовать эту информацию, чтобы выбрать правильное окно, выполнить правильное заполнение и вычисления.

Это в синтаксисе NASM, я обычно использую TASM (из-за привязанности) для программ DOS, но на этот раз я спешил.
В результате

Помните, что каждая строка сканирования, в общем, может быть дополнена (размер строки сканирования возвращается в информации о видеорежиме).
Для сканирующей линии шириной 1024 пикселя с 3x8bpp у нас есть 3072 байта /scanline, так как это делится на 4, никакое дополнение не может произойти.
Начальный адрес окна задается в блоке детализации (также в информации о видеорежиме), общий фреймбуфер составляет 1024x768x3 байта = 2,25 MiB, при условии отсутствия отступов.
Размер окна также можно найти в информации видеорежима.

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

Graphics — VESA(VBE in PM) + shaders

VESA BIOS Extensions — (VBE) расширение BIOS в стандарте VESA, дополнительные функции видео BIOS видеокарты по отношению к стандартному видео BIOS для VGA, позволяющие запрашивать у адаптера список поддерживаемых видеорежимов и их параметров (разрешение, цветность,… … Википедия

VESA BIOS Extensions — Die VESA BIOS Extension (VBE) ist ein Standard der V >Deutsch Wikipedia

VESA Display Power Management Signaling — (or DPMS) is a standard from the VESA consortium for managing the power supply of v >Wikipedia

VESA — V >Википедия


VESA — The V >Wikipedia

VBE — VESA BIOS Extensions (VBE) расширение BIOS в стандарте видеокарты по отношению к стандартному видео BIOS для По сути, VBE является унифицированным стандартом программного интерфейса с VESA совместимыми картами при работе через видео BIOS он… … Википедия

Qemu — Entwickler: Fabrice Bellard Aktuelle Version: 0.10.3 (1. Mai 2009) Betriebssystem: Windows, GNU/Linux, BSD, Mac OS X … Deutsch Wikipedia

QEMU — Entwickler Fabrice Bellard Aktuelle Version 0.15.0[1] (9. August 2011) Betriebssystem Windows, GNU/Linux, BSD, Mac OS X … Deutsch Wikipedia

Небольшая инструкция по редактированию биоса в VBE 7.0.0.7b. с последующей прошивкой.

На форуме часто появляются сообщение о том как редактировать биос, в какой программе и так далее. Вот решил написать небольшую инструкцию к программе VBE для видеокарт AMD на основе чипа GCN 1.0, т.е. всех RADEON HD7000, 280Х, по крайней мере тех, что на чипе ревизии XT2 и, конечно же, за исключением 7790 (ибо уже GCN 1.1).

Для начала немного о самой программе. Для тех, кто понимает по английски вот тут описание возможностей и ограничений.
Для непонимающих, приведу перевод:
Можно:

  • Менять VendorID/SubsystemID карты (но не нужно)
  • Менять частоту и напряжение ГПУ и частоту памяти
  • Менять частоту Boost, TDP, лимиты
  • Делать свою кривую вращения вентилятора

НЕ можно:

  • Менять частоты и напряжения ГПУ/памяти для 2D и режима UVD (так сделано специально, иначе энергосберегалки карты не работают как должны)
  • Менять напряжение на памяти (очень печально, кстати)
  • Задавать любые напряжения на ГПУ для всех типов VRM, кроме CHL822x, CHL8214, UP1637, UP1801, ST6788A, VT1556M (для всех остальных типов, только выпадающая таблица напряжений)

Приступим.

  • Собственно сама программа VBE.
  • Прошивальщик Atiwinflash.
  • Коллекция разнообразных биосов AMD.

  • Открываем программу. Жмем на кнопку Open и выбираем необходимый вам биос.
  • Если редактируете чужой биос, то лучше запустить 2 копии программы и сравнить оба биоса, это убережет от многих проблем.

Вкладка Overview

реклама

  • Обведенные красной рамкой строчки, должны совпасть в обоих биосах. Не касается случая, если вы сознательно шьете биос от другого производителя, хотя и там как минимум VRM и Memory Type(s)обязаны быть одинаковыми.


Вкладка PowerPlay

реклама

  • Изменение частоты ГПУ (Core Clock) и памяти (Memory Clock) в 3D, а также вольтаж чипа (VDDC), делаем в обведенной красной рамкой части вкладки.
  • Касаемо строчки VDDC. Не рекомендуется повышать напряжение выше 1256 на воздушном охлаждении, особенно если у вашей карты не очень качественное охлаждение и слабая система питания. (Замечание от себя — Было дело гнал свой старый Асус ДС2 до 1350мВ по чипу, ничего страшного не случилось. Но на постоянную основу это можно проделать только под водой, и только при очень хорошем охлаждении зоны VRM)
  • И снова про VDDC, если на предыдущей вкладке напротив строчки VRM был явно указан его тип, то можете тут выставлять любое значение, в пределах разумного конечно, с шагом 0,006в. А вот если там было написано unknown, то здесь будет выпадающее меню с вольтажом из таблицы напряжений, т.е. точно подобрать напряжение будет невозможно.
  • Чтобы отключить Boost, нужно поставить одинаковые частоты и вольтаж в #6 и #0 (в вашем биосе # может отличаться).

Вкладка OverDrive&PowerTune

реклама

Раздел OverDrive.

  • В строчках Max. Core Clock и Max. Memory Clock нужно выставить частоты не меньше, чем вы выставляли на предыдущей вкладке, иначе глюки в драйверах обеспечены.
  • В строчке TDP Limit (%) можно выставить любое значение от -50 до +50. Это аналог управления питанием из Aftreburner.

реклама

  • Строчка TDP (W) позволяет прямо указать максимальный теплопакет карты.
  • В Power Limit (W) можно задать минимальный и максимальный теплопакет видеокарты.

Хотя автор программы намекает, что TDP (W) и Power Limit (W) работают не всегда и не у всех.

Вкладка Fan Profile

реклама

  • Тут можно поиграть с оборотами вентилятора и температурой. Никаких советов не будет. Все зависит от СО вашей видеокарты. Если она плохо охлаждает, то нет смысла особо сильно занижать кривую температуры/скорости вращения. В общем есть смысл поиграть с графиком в сторонних программах, а потом уже вшить их в биос.
  • В строчке Temperature Hysteresis можно указать значение погрешности измерения температуры и скорости вентилятора, но лучше не трогать. Иными словами это сглаживает набор\падение оборотов вентилятора.
  • Ну и кнопки Save Profile и Load Profile позволяют сохранять и загружать ваше творчество в программу.
  • Нажимаем Save и сохраняем свой отредактированный биос.

Переходим к прошивке биоса в видеокарту.

Сразу оговорюсь, что я не сторонник прошивки биоса из под ДОС, поэтому тут только Виндовс версия прошивальщика. Уже прошился раз 100 на многих картах и пока ни одного сбоя не было. Но, за любые риски ответственности не несу.

  • Распаковываем архив с прошивальщиком в корень диска С:, должно получиться что-то вроде С:\Atiwinflash.
  • Копируем сохраненный ранее биос в эту папку.
  • Открываем консоль с правами администратора и вводим:
  1. cd c:\atiflash
  2. atiwinflash -unlockrom 0 — запустится программа, разблокирует на запись биос номер 0. Появиться окошко, что разблокировка произведена, в нем жмем ОК. (В некоторых видеокартах биос не заблокирован на запись, так что эту строчку можно не вводить. Хотя если даже и введете, плохого не случится).
  3. atiwinflash -p -f 0 имя_вашего_биоса.rom — собственно прошивка биоса, ждем 5-10 секунд и перезагружаемся. (Начиная с версии VBE 7.0.0.7b автор сделал проверку контрольной суммы при сохранении биоса, поэтому параметр -f уже не обязателен, хотя и не вредит).

В конце вы должны увидеть такое окно:

  • Обратите внимание на обведенную зону, все байты должны совпасть. Если не совпали, перешиваемся снова, но НЕ перезагружаем ПК.

Если не уверены, что прошивка прошла гладко (слишком долго бегали полоски или еще чего нибудь) то лучше не перезагружаться, а повторить процесс.

Функции VBE

Для вызова функций VBE используем прерывание 10h

Функция AL=00- Return VBE Controller Information Получение Информации о VBE контролере. Input: AX = 4F00h ES:DI = Буфер 512 байт для структуры VbeInfoBlock Перед вызовом функции нужно записать в поле VESASignature=”VBE2” – дело совместимости.

Для тех, кто не знает: ASCIIZ – это строка, закачивающаяся на 0 BCD десятичный формат. Старшая часть хранится во втором байте, младшая — в первом байте. Каждые 4 бита это числа от 0 до 9. Примеры: 0102h=>1.02; 0300h=>3.0 VideoModePtr – указатель на список WORDов. Значение FFFFh — последний элемент в списке. Каждый Word это номер поддерживаемого видео режима (за исключением FFFFh). Capabilities – возможности видеоадаптера.

Reserved2 – предназначено для хранения OEM такой информации, как строки PTRVESAVersion, NameFirme, NameVESA.

Функция AL=01- Return VBE mode information Получение информации об одном из режимов VBE. Input: AX = 4F01h CX=MODE ES:DI = Указатель на буфер для структуры ModeInfoBlock

VBE в защищенном режиме

В защищенном режиме поддержка функций VESA реализована крайне странно. Во второй версии стандарта введена функция 0AH — RETURN VBE PROTECTED MODE INTERFACE, которая позволяет вызывать ряд функций, но функционал её очень мал. Зато появился линейный буфер LFB. Почти вся видео память доступна одним окном в верхних адресах физической памяти. Есть расширение “PMID”, но оно может и отсутствовать. Расширение “PMID” введено в третьей версии стандарта.

Для проверки поддержки БИОСом видео карты “PMID”, следует произвести поиск сигнатуры “PMID” в диапазоне адресов 0C0000h-0DFFFFh “PMID” – это расширение VESA 3, поэтому может и отсутствовать. Структура PMID такова:

Ссылки

1. VBE версия 3.0 от ассоциации VESA
vbe3.pdf
2. VBE версия 2.0 от ассоциации VESA
vbe20.txt
3. VBE версия 1.2 от ассоциации VESA
vesasp12.txt

Graphics — VESA(VBE in PM) + shaders

There is one major problem with the VESA standard. It was designed several years ago while people were still using 286 machines, so it is a real mode API with a 16 bit interface. You can still use it from a 32 bit protected mode system like djgpp, but this means that every time you call a VESA function the cpu has to switch into real mode in order to run the 16 bit driver code, and then it has to switch back into protected mode before it can return to your program. These mode switches are slow, and can be a real performance problem because you will often need to switch banks many hundred times while drawing a complex image. The VBE 2.0 API is a more recent extension to the original standard, and adds some features designed to improve the performance of protected mode programs.

Not every machine will have a VBE 2.0 driver installed. This can be detected by checking that the high byte of the vesa_info.VESAVersion field contains a value greater than or equal to two: if it does not, you have an old VESA 1.x driver that will not support any of the functions described in this document.

VBE 2.0 provides a new bank switching mechanism that can be used in a protected mode environment without the expensive switch to real mode. This is implemented as a small stub of relocatable 32 bit code provided by the VESA driver, which can be copied into your address space and then called directly to perform the bank switch, hardware scrolling, and palette setting functions. It is very easy to add support for this method into an existing body of VESA 1.x code, and the speed improvement can be dramatic.

The 32 bit code stubs are obtained by calling VESA function 0x4F0A, for example:

This code will give you a pointer to the protected mode bank switching function, but you cannot call this directly from C because it uses a special register based argument passing convention. A little bit of inline asm is needed to make sure the parameters go into the correct registers, eg:

This routine is an exact drop-in replacement for the set_vesa_bank() function described in the previous chapter, but will run several hundred times faster!

VBE 2.0 also provides the ability to use a linear framebuffer mode in which the entire video memory can accessed as a single block at some location other than the standard 0xA0000, which gets rid of the need for bank switching altogether. This is both the fastest and the easiest way to program SVGA graphics, but unfortunately you can’t count on it being supported by all hardware. Even if the card has a VBE 2.0 driver, many older boards don’t support linear framebuffers at all, and a few of the more recent ones can only use linear addressing in certain resolutions.

Setting a linear framebuffer mode is extremely simple. After calling the find_vesa_mode() function, check that bit 7 of mode_info.ModeAttributes is set, to make sure that linear addressing is possible in this mode. Assuming that it is supported, when you call function 0x4F02 to select the mode you should put (mode_number | 0x4000) into the BX register, instead of just mode_number, and you will have a linear framebuffer!

The video memory is located at the physical address specified by the mode_info.PhysBasePtr field, but you must map this area into your address space before you can access it. This can be done with the code:

You can now write to any part of the screen using the selector that we just created, and without any need for bank switching, eg:

Finally, at the end of your program you should free the video memory mapping with the code:

It is also possible to use the «Fat DS» trick from to access the framebuffer directly with a normal C pointer. This is a very appealing technique because it allows you to treat the entire SVGA screen exactly like a normal C array, but you should be aware that it won’t work under some DPMI hosts (notably Windows NT and Linux DOSEMU), plus if you write all your code in this way it will be difficult to later add support for banked SVGA modes in case you ever need to make your program run on hardware without a linear framebuffer. But if you are happy to restrict yourself to systems that are capable of linear addressing and support the Fat DS method, you can set this up with the code:

Drawing a pixel is now just a matter of getting a pointer to the video memory by adding the framebuffer address onto the __djgpp_conventional_base value, and then using array syntax to access individual pixels, eg:

Before you exit from a program that uses the nearptr system, you should call the functions:

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