Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Lock\Unlock поверхностей DirectDraw

Страницы: < 1 2 3
NikeOLD © (2004-04-22 21:46:00)
Специально для miek !
Если не веришь мне, вот несколько примеров:
1. Запирать поверхность необходимо, поскольку позиция поверхности в системной памяти может меняться, системный менеджер памяти по каким-то своим соображениям может перемещать блоки памяти. (Краснов М. "DirectX. Графика в проектах Delphi", стр. 76);
2. Видео память не остается на одном и том же месте - она вполне может быть виртуальной. Если же эту память заблокировать, она гарантированно остается в одном и том же адресном пространстве в течение времени блокировки. (Ламот А. "Программирование игр для Windows. Секреты профессионала", стр. 250);
3. While you have a surface locked, you can directly manipulate the contents. The following list describes some tips for avoiding common problems with directly rendering surface memory:
a) Never assume a constant display pitch. Always examine the pitch information returned by the IDirectDrawSurface7::Lock method. This pitch can vary for a number of reasons, including the location of the surface memory, the type of display card, or even the version of the DirectDraw driver. For more information, see Width vs. Pitch.
b) Make certain you blit to unlocked surfaces. DirectDraw blit methods will fail, returning DDERR_SURFACEBUSY or DDERR_LOCKEDSURFACES, if called on a locked surface. Similarly, GDI blit functions fail without returning error values if called on a locked surface that exists in display memory.
(DirectX 7 SDK, "Accessing Surface Memory Directly")
Это, что касается Lock\Unlock.
Теперь относительно доступа к поверхности через графический контекст устройства (знакомо?). Полученный DC тоже нужно освобождать после работы и чем быстрее, тем лучше поскольку они неявно вызывают Lock\Unlock! Читай SDK внимательно.

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

miek (2004-04-23 19:27:00) [41]
>Нетрудно догадаться, при попытке записать что-либо по этому адресу, получается AV.

Это - очень спорный вопрос. Если бы дело было именно так, прога просто падала бы, возможно, с выводом сообщения. НО ОНА ПРОДОЛЖАЕТ РАБОТАТЬ!

>При разработке игр оговорок быть не может! Если это shareware, игроманы розочаруются в твоем софте

Ты совершенно правильно заметил, это я не могу не признать. Фокус в том, что вернуть на место Lock/Unlock дело двух секунд.

> тебя понял, ты хочешь отделаться малыми потерями

Да нет - как раз дело не в быстродействии. Мне очень нравится возможность малой кровью создать DirectDraw-движок на моей SpriteUtils-2.

>А как ты поверхности восстанавливаешь

Проверяю, находится ли прога в фоне. Если да, ничего не делать. Если мы работаем, проверка на IsLost и затем Restore/SetPalette. Короче, оучше я код выложу, блин мне на голову.

http://www.miek.narod.ru/spacediver.zip

>Мой совет использовать RestoreAllSurfaces главного объекта DirectDraw. Так надежнее, чем восстанавливать каждую вручную, можно нарушить порядок чередования.

О! Вот это дельный совет. Правда, у меня поверхности не связаны в цепь - вторая OFFSCREENPLAIN.

>Кстати, если у тебя ведется лог программы, а он ОБЯЗАН БЫТЬ, т.к. Delphi не умеет отлаживать DirectX приложения, то очень легко отследить твой AV.

Вот именно лог-то и позволяет видеть, что никакого AV нет. Наоборот, что под 98, что под NT - DirectDraw бодро рапортует об отсутствии ошибок.

NikeOLD (2004-04-23 19:18:00) [42]
А как ты поверхности восстанавливаешь? Если они залочены, хрен ты что восстановишь под 98, в 2000 улучшенная модель памяти там возможно прокатит.
Мой совет использовать RestoreAllSurfaces главного объекта DirectDraw. Так надежнее, чем восстанавливать каждую вручную, можно нарушить порядок чередования.
Кстати, если у тебя ведется лог программы, а он ОБЯЗАН БЫТЬ, т.к. Delphi не умеет отлаживать DirectX приложения, то очень легко отследить твой AV.

NikeOLD (2004-04-23 19:07:00) [43]
Незря все-таки отдельную ветвь завели...

Уважаемый miek, я тебе десятый раз твержу и сам ты с этим уже столкнулся. Если ты залочил память, или получил на нее указатель, а потом переключил Alt-Tab или усыпил компьютер или еще что-нибудь DirectX запустил, то вот и получаешь свою проблему!
Моя прога прекрасно переживает все указанные действия под любыми ОС (под Me не тестировал за неимением), даже 95 жрал и не подавился, а все потому, что не страдал всякой ерундой, а следовал документации.
Пойми, когда ты переключаешь Alt-Tab или усыпляешь комп, то твой указатель после возвращения в программу будет в большинстве случаев указавать на неверный адрес поверхности в видеопамяти. Далее Нетрудно догадаться, при попытке записать что-либо по этому адресу, получается AV.
Вообще, где обещанный участок исходника!?

> Претендует, хотя и с оговорками.

При разработке игр оговорок быть не может! Если это shareware, игроманы розочаруются в твоем софте! Пойми же это наконец.

Я тебя понял, ты хочешь отделаться малыми потерями в быстродействии, экономя на Lock/Unlock, но это чревато. Тебе это уже все сказали. Елки-палки, пора бы уже смириться и делать так, как советуют профессионалы (себя я к ним не причисляю, но смотри самый верхний пункт!). Ивообще чем меньше у тебя в программе непосредственного доступа к поверхностям, тем лучше! Используй Blt или BltFast для вывода спрайтов, а необходимость вывода отдельных пикселей оставь на самый крайний случай. В конце концов твой однопиксельные звезды гораздо быстрее вывести, если представить их как спрайт размером 1х1 пиксель и выводить через BltFast!

miek (2004-04-23 18:46:00) [44]
>ну попробовал я твою прогу альт+табом на w2000 и xp. В обоих случаях AV вылетал. Даже на W98 прога нестабильна

Насчет W2000 пока не спорю. Про 98 - как именно нестабильна?

>Твой способ бесспорно возможный, но никоим образом не претендует на правильность

Претендует, хотя и с оговорками.

>непонятно на каком языке правила

Слово "рыба" когда-нибудь слышал?

NailMan (2004-04-23 17:16:00) [45]
miek ©
ну попробовал я твою прогу альт+табом на w2000 и xp. В обоих случаях AV вылетал. Даже на W98 прога нестабильна.
Чего добиваешься?

Твой способ бесспорно возможный, но никоим образом не претендует на правильность по всем законам D3D. Ты бы доказал бы свое мнение разработчикам Direct3D - я бы посмеялся вместе с ними.

Имхо, советовать заведомо бажный алгоритм другому собрату не достойно Мастера(если уж когда то им станешь).

PS:
Что и говорить - у тебя в проге даже непонятно на каком языке правила и т.д. написаны(хотя знаю как и прочесть сии каракули).

miek (2004-04-23 16:37:00) [46]
>Не могу понять твоего недоверия к документации

Не могу понять твоего недоверия к объективному опыту.

>Скорее всего в 98-й MS проверки какие-нибудь похерила

Что-что? Мне, между прочим, никто так и не сказал, что такого страшного может случиться при "моем" подходе (он не мой на самом деле). Что следует ожидать? AV, GPF, вылета? Ничего подобного нет.

А вот, кстати, отрывок из ДРУГОЙ доки, тоже микрософтовской, между нами:

Responsibility for managing page locking is entirely in the hands of the application developer. DirectDraw will never page lock or page unlock a surface. Additionally, it is up to you to determine how much memory you can safely page lock without adversely affecting system performance.

VMcL (2004-04-22 23:24:00) [47]
>>Единственная трудность, которая у меня сейчас есть - с восстановлением поверхностей в win2000.
>Под 98-й все пашет и не чихает.

Во-во. Скорее всего в 98-й MS проверки какие-нибудь похерила, а в 2000-й сделали уже по-человечески.

VMcL (2004-04-22 23:21:00) [48]
>>miek © (22.04.04 22:15) [1]

Не могу понять твоего недоверия к документации.

miek (2004-04-22 22:15:00) [49]
Цитировать талмуды - это, конечно, здорово. (Ты, навероне, думал, что я про MSDN видом не видывал и слыхом не слыхивал?). Как насчет подумать самому? Все пункты легко опровергаются, если не "читать SDK", а поэкспериментировать.
Единственная трудность, которая у меня сейчас есть - с восстановлением поверхностей в win2000. Там какая-то особенность есть... Под 98-й все пашет и не чихает.

Страницы: < 1 2 3

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »