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

← →
NikeOLD (2004-04-22 21:46) [0]

Специально для 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-22 22:15) [1]

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

← →
VMcL © (2004-04-22 23:21) [2]

>>miek © (22.04.04 22:15) [1]

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

← →
VMcL © (2004-04-22 23:24) [3]

>>Единственная трудность, которая у меня сейчас есть - с восстановлением поверхностей в win2000.
>Под 98-й все пашет и не чихает.

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

← →
miek © (2004-04-23 16:37) [4]

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

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

>Скорее всего в 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.

← →
NailMan © (2004-04-23 17:16) [5]

miek ©
ну попробовал я твою прогу альт+табом на w2000 и xp. В обоих случаях AV вылетал. Даже на W98 прога нестабильна.
Чего добиваешься?

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

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

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

← →
miek © (2004-04-23 18:46) [6]

>ну попробовал я твою прогу альт+табом на w2000 и xp. В обоих случаях AV вылетал. Даже на W98 прога нестабильна

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

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

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

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

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

← →
NikeOLD (2004-04-23 19:07) [7]

Незря все-таки отдельную ветвь завели...

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

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

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

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

← →
NikeOLD (2004-04-23 19:18) [8]

А как ты поверхности восстанавливаешь? Если они залочены, хрен ты что восстановишь под 98, в 2000 улучшенная модель памяти там возможно прокатит.
Мой совет использовать RestoreAllSurfaces главного объекта DirectDraw. Так надежнее, чем восстанавливать каждую вручную, можно нарушить порядок чередования.
Кстати, если у тебя ведется лог программы, а он ОБЯЗАН БЫТЬ, т.к. Delphi не умеет отлаживать DirectX приложения, то очень легко отследить твой AV.

← →
miek © (2004-04-23 19:27) [9]

>Нетрудно догадаться, при попытке записать что-либо по этому адресу, получается 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:52) [10]

> у меня поверхности не связаны в цепь - вторая OFFSCREENPLAIN.

Это не принципиально. Данный метод восстанавливает ВСЕ имеющиеся поверхности. Тебе останется только восстановить палитру и загрузить заново графику.

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

Ересь какая-то. А лог очень подробный? Ладно, попробую сейчас в исходниках покопаться.

← →
miek © (2004-04-23 20:12) [11]

Короче, свежая новость (плохая) - вставка обратно Lock/UnLock проблему на NT не решает и поведение не изменяет.

Может, дело в том, что я использую IDirectDraw? Шестой поставить, что ли?

← →
NailMan © (2004-04-23 20:45) [12]

miek ©

Насчет W2000 пока не спорю. Про 98 - как именно нестабильна?
После alt+tab она зависала и после этого Директ умирал до перезагрузки компа. Т.е. после принудительного сваливания из задач твоей проги не могла запуститься ни одна DirectX программа.

Win98SE, DX 9b. Сейчас правда комп этот не доступен, так как он не у меня дома.

← →
NikeOLD (2004-04-23 20:51) [13]

Нет проблема не в этом.
Короче, я приведу некоторые соображения по беглому просмотру исходников.
1. Зачем вызывать Halt в процедуре Quit после отправки PostQuitMessage(0)? Это и так даст винде команду прибить приложение. Хотя PostQuitMessage(0) принято посылать в обработчике сообщения WM_Destroy. Лирика...
2. Код слабо комментирован, точнее вообще никак! Поверь моему опыту, через месяц каникул ты потритишь ни один час на восстановлении в памяти всех подробностей кода. Разобраться из-за этого сложно.
3. Не понимаю необходимости при восстановлении поверхностей делать повторные вызовы SetCooperativeLevel и SetDisplayMode. Direct это делает автоматически, равно как и при закрытии приложения (последнее - дурной тон). А вот при переключении Alt-Tab гонять разрешение туда сюда нет никакой необходимости.

Черт, как сложно без комментариев разобраться что к чему.

4. if curtime - lastframetime > 1000 div maxfpsallowed then begin lastframetime := curtime; r1 := makerect(0, 0, ScreenX, ScreenY); if setup.WaitForVerticalBlank then ddrawobject.WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN, 0); // secondarysurface.Lock( nil, desc, DDLOCK_WAIT, 0); // ppublicdib( screen).fbits:= desc.lpSurface; primarysurface.BltFast(0, 0, secondarysurface, @r1, setup.bltwait); // secondarysurface.Unlock( desc.lpSurface); end;
Зачем тартить процессорное время на получение r1. Он же один на всю игру, кроме того передай вместо нее NULL, т.е. nil и получишь тот же эффект. Кстати рекомендую для полного экрана организовать chain.

5. Попробуй изменить лог таким образом, чтобы он анализировал результат выполнения каждой функции на корректное значение HRESULT (DD_OK) или лог - в противном случае. Много нового о своей программе узнаешь, честное слово. Код от этого сильно увеличится, но за быстродействие не волнуйся. Просто анализировать результат функции не только правило хорошего тона, но и хороший ответ по всяким багам. Для вывода инфы в лог воспользуйся функцией function DDErrorString(Value: HResult): string;. В параметр Value - результат любой функции или метода DirectDraw.

Кстати, хорошая новость для тебя: у меня 98 и карточка Riva TNT2 64МВ. Alt-Tab без проблем много раз.

← →
NikeOLD (2004-04-23 20:56) [14]

> Может, дело в том, что я использую IDirectDraw? Шестой поставить,
> что ли?

Не вздумай!
DirectX это технология COM, надеюсь в общих чертах ты с ней знаком. Если поставишь 6 Direct, то интерфейсы 7 версии сосать будут и тебе придется полпрограммы переписать, тем более, что часть методов в интерфейсе 6 версии отсутсвует, например метод RestoreAllSurfaces. У меня стоит 9b, но интерфейсывсе работают и как видишь не жалуюсь. До этого стояли две 8 версии. Если потерпишь до понедельника, то могу протестировать твою прогу на 2000.

← →
NikeOLD (2004-04-23 21:12) [15]

Слушай, хоть убей не пойму, почему после Alt-Tab у тебя происходит потеря поверхности. Гонял свою прогу. Потеря поверхности происходит только после засыпания компа! При Alt-Tab все ОК.
В общем переделывай лог, пока не увидим воочию, что выдает каждая твоя функция, хрен что поймем. Однозначно, проблема не в интерфесах, возможно даже не Lock/Unlock, но больше ничего не могу сказать.
Через часок еще загляну, а то время из дома жалко.

← →
miek © (2004-04-23 21:40) [16]

>После alt+tab она зависала и после этого Директ умирал

А ты Esc нажимать пробовал? У меня это тоже выглядело как "смерть", но прога нормально ловила Esc и выходила.

>Зачем вызывать Halt

У меня после установки патча на винду некоторые проги, выходящие обычным способом (скринсэйверы, например), оставляют пустое окошко на таскбаре. Halt решает эту проблему.

>Код слабо комментирован

Я намерен это исправить, как только будет готова демо-версия игры.

>Не понимаю необходимости при восстановлении поверхностей делать повторные вызовы SetCooperativeLevel и SetDisplayMode

Это уже от отчаяния. Не помогло, точно.

>Зачем тартить процессорное время на получение r1

Логично, так и сделаю.

>Попробуй изменить лог таким образом, чтобы он анализировал результат

Уже есть. Функция check() как обертка для всех вызовов DirectDraw. Просто она ничего не выводит в случае DD_OK.

>Не вздумай! Если поставишь 6 Direct

Я имел в виду IDirectDraw6 (или IDirectDraw4) - поскольку в первом нет метода RestoreAllSurfaces.

>протестировать твою прогу на 2000.

У меня здесь есть 2000-й.

Кстати: >Riva TNT2 64МВ. Alt-Tab без проблем много раз

Я делал так: (машина 64КБ ОЗУ, Win98, S3 Virge) запускал игру, альттабился, запускал фотошоп, создавал офигенную картинку - 5000 на 2000, ждал, пока он ее сделает, потом выходил из фотошопа и переключался на прогу. Все работало. В фоне постоянно играл Винамп, причем даже без щелчков-пауз-рывков!

← →
NikeOLD (2004-04-23 22:35) [17]

С тем экзешником, который я выдернул с твоего сайта все в порядке. У меня на 98SE он прошел и твой изуверский тест (впрочем, картинка там создается не в видеопамяти, а в свапе) и еще один: запуск параллельно еще одной DirectDraw программы (моей). Обе программы живут практически одновременно и все корректно восстанавливается.
Один минус: пока прога находится в фоне, у тебя похоже идет обработка логики игры - персонаж куда-то зачем-то двигается. Надо бы паузу поставить, а то улетает черт знает куда.

> Я имел в виду IDirectDraw6 (или IDirectDraw4) - поскольку
> в первом нет метода RestoreAllSurfaces

Не надо. 7 версия самая надежная. Жаль, что DirectDraw больше не поддерживается. Хотя 3D перспективнее, все же DDraw тоже хорош для определенных задач, рад что кто-то им еще не брезгует.

> >Зачем вызывать Halt

Забей, это бывает и то не всегда. В 2000 этого не происходит. Иначе нет смысла в PostQuitMessage(0);

> >Код слабо комментирован
> Я намерен это исправить, как только будет готова демо-версия
> игры.

Лучше сразу, затраты времени с лихвой окупаются удобством.

> >Попробуй изменить лог таким образом, чтобы он анализировал
> результат
> Уже есть. Функция check() как обертка для всех вызовов DirectDraw.
> Просто она ничего не выводит в случае DD_OK.

Что-то не заметил. Хотя, если это присутствует и все DD_OK, то ошибка кроется в другом. Проверь все указатели, динамические массивы и т.п.

И все же совет: надыбь где-нибудь книжку по DirectX. Лучше Ламота, но там, если с С++ никак, то лучше не соваться. Еще Краснов есть (почти классика :) ).
Забыл что-то важное, вспомню - допишу.

Слушай-ка, ты случаем не из Нижнего Новгорода будешь?

← →
Mihey © (2004-04-24 00:14) [18]

>машина 64КБ ОЗУ, Win98, S3 Virge

Однако не думал, что винды такие скромненькие.

← →
miek © (2004-04-24 09:42) [19]

>Не надо. 7 версия самая надежная

Но я-то использую первую!

>ты случаем не из Нижнего Новгорода

Увы, нет.

← →
NikeOLD (2004-04-24 10:43) [20]

Жаль, что не местный.

Прошу прощения, что не обратил внимания сразу. Блин, попробуй переделать на интерфейсы 7 версии.
Код инициализации: DDrawObject: IDirectDraw7; PrimarySurface: IDirectDrawSurface7; DXResult: HRESULT; DXResult := DirectDrawCreateEx(nil, DDrawObject, IID_IDirectDraw7, nil); log(DDErrorString(DXResult)); if Failed(DXResult) then Exit;
Далее по SDK. Потом посмотришь, что получилось. Желаю удачи, но ветка еще не закрыта.

← →
VLoB (2004-04-26 01:44) [21]

> Цитировать талмуды - это, конечно, здорово

это даже больше, чем здорово =))

> А на MSDN иногда и положить можно

нельзя

судя по твоим постам, ты основываешся только на интуитивном и экспериментальном опыте, но, к сожалению, плохо представляешь, что происходит в памяти с поверхностями ДиректХ, советую тебе почитать первый пост в этой теме, если не дойдет, почитай еще несколько раз...

з.ы.: прога твоя после альт-таба валится "Exception Exception in module spacediver.exe at <адрес>. Access violation in module..." и дальше как заказывали
запускал под ХР - конфиг более чем - 780mb ram/128mb video, чего ей не хватает? а не хватает ей здравого рассудка автора, который лучше чем мелкософт знает, как правильно работать с памятью DX.

без обид, удачи =)

← →
miek © (2004-04-27 22:05) [22]

Итак, в результате долгих экспериментов проблема локализована и скоро будет решена. (Смена интерфейса на IDirectDraw7 ничего, разумеется, не дала). Можно смело считать, что одной недокументированной дырой в MSDN стало больше.

Причина глюков до смешного проста - при смене видеорежима почему-то теряется не только первичная поверхность, но и вторичная (хотя во многих доках уверяют, что такого быть не должно - может, тут все дело в 8-битном режиме? Не знаю). Это, конечно, было бы полбеды. Вторые полбеды в том, что при ее восстановлении она разом оказывается в видеопамяти и вылезать оттуда не желает! Естественно, обращение к ней позле разлочивания - дает ошибку, сообщение о которой, видимо, не видно из-за монопольного режима экрана.

Неприятность в том еще, что это не ошибка DirectDraw и его процедуры всегда, даже перед самым глюком, возвращают DD_OK, а система при выводе сообщения "забывает" переключить режим экрана...

Вот так. Товарищу NikeOld - большое спасибо за помощь, остальным м*кам - большое "фу".

← →
VMcL © (2004-04-27 22:20) [23]

>>miek © (27.04.04 22:05) [22]

Давай исправленную прогу (если есть). Будем тестить.

← →
miek © (2004-04-27 23:10) [24]

Завтра к девяти вечера, сейчас слишком времени мало.

← →
NikeOLD (2004-04-27 23:58) [25]

Очень рад, что мои труды не пропали даром.

> ты основываешся только на интуитивном и экспериментальном опыте

Что ж это тоже неплохо, когда человнк пытается самостоятельно до чего-то докопаться, значит есть надежда. А то частенько здесь на форуме просят едва ли не за них программу написать и принести на блюдечке.

Однако, мне хотелось бы уточнить в какой момент при смене видеорежима происходит потеря поверхности? Может попытаюсь объяснить.

> Вторые полбеды в том, что при ее восстановлении она разом
оказывается в видеопамяти и вылезать оттуда не желает! Естественно, обращение к ней позле разлочивания - дает ошибку, сообщение о которой, видимо, не видно из-за монопольного режима экрана.

Объясняю сразу. При создании поверхности DirectDraw пытается поместить ее в видеопамять сразу же, если не задано в лоб иное. В случае, если поверхность невозможно создать в видеопамяти, она создается в системной памяти. Если в лоб задать видеопамять, а таковой не хватит, вывалится ошибка "Недостаточно видеопамяти".
Похоже, что обе твои поверхности создаются в видеопамяти (спасибо 8 битному режиму за малое количество отъедаемой памяти). После первого залочивания и последующего разлочивания у тебя остается указатель на корректный адрес поверхности в видеопамяти. Однако при переключении по Alt-Tab и последующем восстановлении, адрес поверхности меняется, а ты пытаешься обратиться по старому адресу в непринадлежащий больше тебе участок видеопамяти, что естественно вызывает протест со стороны системного диспетчера памяти. Вот и все объяснение. Наилучший выход это каждый раз делать Lock/Unlock заново, чтобы получить КОРРЕКТНЫЙ АДРЕС ПОВЕРХНОСТИ.

Кстати, замечу, что 8 битный режим, хотя и имеет большое число прелестей, навроде создания спецэффектов при смене индексов палитры, но все же доставляет куда больше хлопот, чем 16, 24 или 32 битный режим.

> Неприятность в том еще, что это не ошибка DirectDraw и его
> процедуры всегда, даже перед самым глюком, возвращают DD_OK,
> а система при выводе сообщения "забывает" переключить режим
> экрана...

Да она и не обязана его переключать. Чтобы иметь возможность выводить стандартные виндовые окна из-под DirectX, надо использовать функцию FlipToGDISurface(); главного объекта DirectDraw, которая позволяет выводить поверхность GDI поверх поверхности DirectDraw. Без ее вызова ни одно стандартное диалоговое окно, или любое другое, ты никогда не увидишь!
Вот, что по этому поводу сказано в SDK DX7:
"This method can be called at the end of a page-flipping application to ensure that the display memory that the GDI is writing to is visible.
The method can also be used to make the GDI surface the primary surface so that normal windows such as dialog boxes can be displayed in full-screen mode. The hardware must have the DDCAPS2_CANRENDERWINDOWED capability. For more information, see Displaying a Window in Full-Screen Mode"

Удачи, если что пиши на мыло. Обсуждение НЕ закрыто!

← →
miek © (2004-04-28 20:34) [26]

ЮСТАС АЛЕКСУ ТЧК БАБУШКА ПРИЕХАЛА ВСКЛ ЗН

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

← →
VMcL © (2004-04-28 21:02) [27]

>>miek © (28.04.04 20:34) [26]

1. После спящего режима:
а) в твоей программе - белый экран (также было слышно по звуку, что где-то вылезла ошибка);
б) нельзя переключить битность цвета, то бишь, к примеру, вместо 1024x768x32 можно поставить 1024х768х8;
в) завершить программу можно только менеджером задач.

2. Не по сабджу: программа при переключении в фоновый режим потребляет ~100 % CPU time, игра продолжается, но уже без участия игрока-человека.

P.S. OS: WinXP Rus SP1.

← →
miek © (2004-04-28 22:25) [28]

>После спящего режима

А что в логах?

>при переключении в фоновый режим потребляет ~100 % CPU

Это вполне возможно, я пока не занимался оптимизацией.

← →
NikeOLD (2004-04-28 22:45) [29]

Отлично, теперь вижу нормальный лог!
Сразу пара замечаний.
Во-первых, было бы куда правильнее создавать палитру не после установки уровня кооперации, а после изменения разрешения экрана. Во-вторых, при закрытии программы все шаги необходимо выполнять в обратной созданию последовательности, т.е. сначала удаление всех поверхностей, а уж только после этого восстановление режима дисплея, затем нормального уровня кооперации.
В общем при тесте по Alt-Tab все ОК, пока не возникает необходимость выйти из программы обычным путем (по Esc). Программа закрывается, но при этом слышен звук ошибки. Самой ошибки не выдается.

При засыпании - белый экран. В этот моент программа пытается усиленно восстановить первичную поверхность. Вот фрагмент лога, который повторяется до удаления программы через диспетчер задач:
Primary surface lost! Restoring...
*** Restore This surface can not be restored because it was created in a different mode.
Primary surface restored...
*** primarysurface.SetPalette Access to this surface is being refused because the surface memory is gone. The DirectDrawSurface object representing this surface should have Restore called on it.
Palette restored...
*** BltFast Access to this surface is being refused because the surface memory is gone. The DirectDrawSurface object representing this surface should have Restore called on it.
....тоже самое и т.д.

Если честно, то можно забить на восстановлении из спящего режима. Явидел всего пару игр, которые могли корректно восстановиться после усыпления компьютера. А я, поверь, повидал их несколько сотен. Только полоумный юзер усыпит комп во время игры, и поделом ему. Но восстановить по Alt-Tab - святое.
Могу заметить, что корректным был бы подход когда в случае невозможности восстановить поверхность с первого-третьего раза, программа завершала бы свою работу, а не продолжала осуществлять бесконечные попытки восстановления, загрузки палитры (поверхности нет - некуда загружать!) и пр. Miek, исправляй положение срочно. Можно даже сообщить пользователю после уничтожения DirectDraw в обычном окне диалога почему была закрыта программа.

> программа при переключении в фоновый режим потребляет ~100
> % CPU time, игра продолжается, но уже без участия игрока-человека.

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

> нельзя переключить битность цвета, то бишь, к примеру, вместо
> 1024x768x32 можно поставить 1024х768х8;

Не понял вопроса. Выйти по Alt-Tab, сменить разрешение Рабочего стола Windows и вернуться в программу? Это невозможно однозначно! Поверхность не может быть восстановлена ни при каких обстоятельствах, если она была создана при другом разрешении экрана. Это ограничение DirectDraw, надо смириться!

← →
NikeOLD (2004-04-28 22:48) [30]

> *** Restore This surface can not be restored because it
> was created in a different mode.

Совсем забыл. После такого сообщения можно не пытаться работать дальше - бесполезно. Смотри выше в самом последнем абзаце.

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

:) Ладно, будет сделано.

>можно забить на восстановлении из спящего режима

Наверное, ты прав. Но попытку я все-таки сделаю.

← →
NikeOLD (2004-04-28 23:06) [32]

> >можно забить на восстановлении из спящего режима
>
> Наверное, ты прав. Но попытку я все-таки сделаю.

Достойный ответ! Но сильно не заморачивайся, силы пригодятся в другом!

а вы подеритесь.

← →
NikeOLD (2004-04-28 23:24) [34]

> TButton © (28.04.04 23:09) [33]

Мистер, вы я вижу не вникали в суть проблемы! По моему мнению, мы вполне поладили и нашли общий язык. А упорство и отстаивание собственной точки зрения, пусть и ошибочной, достойно похвалы, если аргументы весомы. Что ж Miek убедился в некоторых аспектах игроделания, дальше разберется сам или с помощью, если захочет о ней попросить. И драться нам вовсе не требуется...

ну я это в хорошем смысле предложил
во-первых разрядка
во-вторых разминка
в-третьих просто свежая мысль

← →
NikeOLD (2004-04-29 11:53) [36]

:))

уже не требуется

>>NikeOLD (28.04.04 22:45) [29]

>Не понял вопроса. Выйти по Alt-Tab, сменить разрешение Рабочего стола Windows и вернуться в программу?
>Это невозможно однозначно! Поверхность не может быть восстановлена ни при каких обстоятельствах,
>если она была создана при другом разрешении экрана.
>Это ограничение DirectDraw, надо смириться!

Я о том, что запущенный Space Diver после пробуждения компа, не дает сменить битность экрана, пока его не снимешь через менеджер задач.

>Только полоумный юзер усыпит комп во время игры, и поделом ему.

1. Допустим, я играю. Потом переключаюсь по Alt+Tab - пауза в игре. В настройках электропитания стоит: спящий режим через M минут. Мне нужно уйти на некоторое время. Комп засыпает. Я возвращаюсь, бужу его. Вуаля.

2. Я режимом Hibernate дома пользуюсь постоянно - меньше времени Win2K грузится ;)

>>NikeOLD (28.04.04 22:45) [29]

P.S.
ИМХО, полоумный не юзер, который использует стандартные возможности ОС, а программист, который клал на них.

← →
NikeOLD (2004-04-29 13:59) [39]

> 1. Допустим, я играю. Потом переключаюсь по Alt+Tab - пауза
> в игре. В настройках электропитания стоит: спящий режим
> через M минут. Мне нужно уйти на некоторое время. Комп засыпает.
> Я возвращаюсь, бужу его. Вуаля.

Покажи мне ту игру, даже на 100% которая бы не умерла после засыпания компа. Стремиться к идеалу нужно, но не заморачиваться до потери пульса, если ничего не выходит.

>>NikeOLD (29.04.04 13:59) [39]

1. Counter-Strike 1.6
[Protocol version 47, Exe version 1.1.2.4 (cstrike), Exe build: 11:35:45 Feb 4 2004 (2659)]

a) OpenGL - всё ОК;
b) D3D - глючит.

2. Quake 3, v. 1.32
Всё ОК.

Lock Unlock поверхностей DirectDraw Найти похожие ветки