Thread: Re: [GD-Windows] Windows paints my window!
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Rich <leg...@xm...> - 2002-09-09 17:23:33
|
In article <006001c25820$2a348d00$ab02000a@mcaf.local>,
"Javier Arevalo" <ja...@py...> writes:
> Any ideas where to look at? Even the slightest trace of a pointer will be
> greatly appreciated.
I thought there was a message you had to handle by returning TRUE (or
FALSE, can't remember) to tell windows not to repaint your background.
Check the DirectXDev archives, I know this has come up there before.
I think it was WM_ERASEBKGND
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book <http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Steve L. <st...@mi...> - 2002-09-09 18:01:49
|
This has always been the case. You must pump messages, USER will paint your client area white if you don't. The following is purely a theory about the behaviour change. When fullscreeen, previously you might have switched to the non-GDI surface, so when windows paints it white you wouldn't see it. Maybe now you have flipped to the surface that GDI knows about and you're seeing the white paint. Cheers, Steve Steve Lacey - Chief Code Wrangler - ironWorks Entertainment -----Original Message----- From: Javier Arevalo [mailto:ja...@py...]=20 Sent: Monday, September 09, 2002 9:44 AM To: GDWindows Subject: [GD-Windows] Windows paints my window! Hi! During long load times (not so long actually, but hey) Windows sometimes seems to decide that the game's window needs repainting and erasing. The app is not responding to messages because it's busy loading stuff. I thought that setting the hbrBackground of the WNDCLASS struct to NULL was enough to prevent this, but it still paints the window white. This only happens when the game runs in fullscreen mode, never in the windowed mode we use for development. Even funnier is that it only started happening a few days ago, but we have been unable to find any changes we might have done to the Window or DirectX handling code for the past _months_. Any ideas where to look at? Even the slightest trace of a pointer will be greatly appreciated. Thanks, Javier Arevalo Pyro Studios ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390 _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 |
|
From: Brian S. <bs...@mi...> - 2002-09-09 18:03:22
|
> In article <006001c25820$2a348d00$ab02000a@mcaf.local>, > "Javier Arevalo" <ja...@py...> writes: >=20 > > Any ideas where to look at? Even the slightest trace of a=20 > pointer will be > > greatly appreciated. >=20 > I thought there was a message you had to handle by returning TRUE (or > FALSE, can't remember) to tell windows not to repaint your background. > Check the DirectXDev archives, I know this has come up there before. >=20 > I think it was WM_ERASEBKGND It is, but Jare said he's not pumping messages when this happens. And if you aren't pumping messages, then I know some versions of the OS will decide you're "hung" and erase your window (signified by the "Not Responding" added to the title bar of your window). I didn't think it happened to full-screen apps, but I don't know that for certain. Does it only happen at startup, or anytime during the game? Could it be prompted by some other window trying to come to the foreground, like ICQ/AIM/MSN? What OS versions do you see it on? --brian |
|
From: Tom F. <to...@mu...> - 2002-09-09 18:16:21
|
> I thought that setting the hbrBackground of the > WNDCLASS struct to NULL was enough to prevent this IIRC, you need to set it to a transparent brush, not just to NULL. But beware of other nasty things that happen when you neglect your = message pump. It might be an idea to call the message pump regularly during the loading process. You can also draw progress bars, etc at the same time = - keeps both Windows and the user from worrying. Tom Forsyth - purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Ignacio Casta=F1o [mailto:cas...@ya...] > Sent: 09 September 2002 18:10 > To: gam...@li... > Subject: Re: [GD-Windows] Windows paints my window! >=20 >=20 > Hi, > Are you returning TRUE to the WM_ERASEBKGND message? >=20 >=20 > Ignacio Casta=F1o > cas...@ya... >=20 >=20 > Javier Arevalo wrote: > > Hi! > > > > During long load times (not so long actually, but hey)=20 > Windows sometimes > > seems to decide that the game's window needs repainting and=20 > erasing. The > app > > is not responding to messages because it's busy loading=20 > stuff. I thought > > that setting the hbrBackground of the WNDCLASS struct to=20 > NULL was enough > to > > prevent this, but it still paints the window white. This=20 > only happens when > > the game runs in fullscreen mode, never in the windowed=20 > mode we use for > > development. Even funnier is that it only started happening=20 > a few days > ago, > > but we have been unable to find any changes we might have=20 > done to the > Window > > or DirectX handling code for the past _months_. > > > > Any ideas where to look at? Even the slightest trace of a=20 > pointer will be > > greatly appreciated. > > > > Thanks, > > Javier Arevalo > > Pyro Studios >=20 >=20 > _______________________________________________________________ > Copa del Mundo de la FIFA 2002 > El =FAnico lugar de Internet con v=EDdeos de los 64 partidos.=20 > =A1Ap=FAntante ya! en http://fifaworldcup.yahoo.com/fc/es/ >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 >=20 |
|
From: Javier A. <ja...@py...> - 2002-09-09 20:14:33
|
Tom Forsyth <to...@mu...> wrote:
>> I thought that setting the hbrBackground of the
>> WNDCLASS struct to NULL was enough to prevent this
>
> IIRC, you need to set it to a transparent brush, not just to NULL.
I didn't find explicit mentions of a transparent brush, but I guess
BS_HOLLOW will do:
LOGBRUSH lb = { BS_HOLLOW };
wcex.hbrBackground = (HBRUSH)CreateBrushIndirect(&lb);
Hopefully this will do the trick.
> But beware of other nasty things that happen when you neglect your
> message
> pump. It might be an idea to call the message pump regularly during
> the
> loading process. You can also draw progress bars, etc at the same
> time - keeps both Windows and the user from worrying.
Yeah we have a progress bar but we don't call the message pump, just update
the screen. I'm concerned about letting messages interfere with the loading
process. We support surface/vb loss & restoration allright, as well as all
incarnations of Ctrl-Alt-Del we have figured out (we only got one rare case
where the three-finger salute will BSOD Win2k), plus mission loading with
the device lost (app minimized). However, I wonder how stable can I get this
thing if I allow a device loss in the middle of reloading surfaces & such
(easy to get into reentrancy trouble I guess).
Thanks, I'll post if / when this is solved.
Javier Arevalo
Pyro Studios
|
|
From: Brian S. <bs...@mi...> - 2002-09-09 20:35:49
|
Who said you have to actually process the messages? :) From MSDN: IsHungAppWindow You call the IsHungAppWindow function to determine if=20 Windows considers that a specified application is not=20 responding, or "hung". An application is considered to=20 be not responding if it is not waiting for input, is=20 not in startup processing, and has not called PeekMessage=20 within the internal timeout period of 5 seconds. http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/winui/= W inUI/WindowsUserInterface/Windowing/Windows/WindowReference/WindowFuncti ons/IsHungAppWindow.asp Call PeekMessage when you update your progress bars and all should be well. --brian > -----Original Message----- > From: Javier Arevalo [mailto:ja...@py...]=20 > Sent: Monday, September 09, 2002 1:17 PM > To: gam...@li... > Subject: Re: [GD-Windows] Windows paints my window! >=20 >=20 > Tom Forsyth <to...@mu...> wrote: >=20 > >> I thought that setting the hbrBackground of the > >> WNDCLASS struct to NULL was enough to prevent this > > > > IIRC, you need to set it to a transparent brush, not just to NULL. >=20 > I didn't find explicit mentions of a transparent brush, but I guess > BS_HOLLOW will do: >=20 > LOGBRUSH lb =3D { BS_HOLLOW }; > wcex.hbrBackground =3D (HBRUSH)CreateBrushIndirect(&lb); >=20 > Hopefully this will do the trick. >=20 > > But beware of other nasty things that happen when you neglect your > > message > > pump. It might be an idea to call the message pump regularly during > > the > > loading process. You can also draw progress bars, etc at the same > > time - keeps both Windows and the user from worrying. >=20 > Yeah we have a progress bar but we don't call the message=20 > pump, just update > the screen. I'm concerned about letting messages interfere=20 > with the loading > process. We support surface/vb loss & restoration allright,=20 > as well as all > incarnations of Ctrl-Alt-Del we have figured out (we only got=20 > one rare case > where the three-finger salute will BSOD Win2k), plus mission=20 > loading with > the device lost (app minimized). However, I wonder how stable=20 > can I get this > thing if I allow a device loss in the middle of reloading=20 > surfaces & such > (easy to get into reentrancy trouble I guess). >=20 > Thanks, I'll post if / when this is solved. >=20 > Javier Arevalo > Pyro Studios |
|
From: Javier A. <ja...@py...> - 2002-09-11 09:59:42
|
Brian Sharon <bs...@mi...> wrote: > Who said you have to actually process the messages? :) From MSDN: > IsHungAppWindow [...] > Call PeekMessage when you update your progress bars and all should be > well. --brian Thanks guys, with either the hollow brush thing or the PeekMessage trick, the window is now fine. However, when we put PeekMessage inside our KeepAlive call (which we call frequently from various load functions), we got a nasty DirectX crash if we Alt-Tab repeatedly. Until now we had only been able to generate this crash in convoluted Ctrl-Alt-Del sequences... it bombs in the middle of a vertex buffer refill: Device was ok, Lock() call was ok, the vertex buffer memory was accesible, but somewhere in the middle of the vertex buffer fill loop, the vertex buffer memory is lost and the rep movsd crashes halfway. I was under the impression that the only way to lose the device when fullscreen was either by Ctrl-Alt-Del (which has special considerations and doesn't take away locked memory), or by actually processing messages and letting your app be deactivated. We PeekMessage with PM_NOREMOVE during load, don't actually process messages, and most certainly don't call that function inside the vertex buffer fill loops, so AFAIK the only effect this PeekMessage should have is to let windows know we're not dead. Will cross-post this to the DirectXDEV list and see what people think. [ Note: funny thing, the crash showed up when I was using Photoshop, had the color picker dialog up, and tried to set the game to fullscreen 640x480 resolution. For some reason, Photoshop's color picker will not let any other app go fullscreen 640x480 (any other resolution is fine). You can try it with the DX samples. Bummer. ] Javier Arevalo Pyro Studios |
|
From: jason z. <dir...@21...> - 2002-11-07 06:33:59
|
SGkgZm9sa3MsDQogICAgSSBoYWQgcHJvZ3JhbWVkIGFuIG9iamVjdCBjbGFzcyB3aGljaCBoYXMg c3RkOjp2ZWN0b3IgYXMgaXRzIG1lbWJlci4gIEFzIHRoZSBvYmplY3RzDQphcmUgY3JlYXRlZCBh bmQgZGVsZXRlZCBpbiBydW50aW1lLCAgdGhlIG1lbW9yeSBvZiB0aGUgcHJvY2VzcyBiZWNvbWVz IGJpZ2dlci4gVGhlIA0KZm9sbG93aW5nIGlzIGEgc2ltcGxpZmllZCB2ZXJzaW9uLCBpbiB3aGlj aCBtZW1vcnkgZ3Jvd2luZyBzZWVtcyBubyBoYXJtIHNpbmNlIHRoZSBtZW1vcnkNCmlzIHJlbGVh c2VkIHRvIHN5c3RlbSBvbmNlIHRoZSBwcm9jZXNzIGV4aXRzLiAgDQogICBCdXQgZm9yIHJlYWwg cHJvZ3JhbSwgbWVtb3J5IGdyb3dpbmcgaW4gcnVudGltZSB3aXRoIG9iamVjdHMgY3JlYXRpbmcg YW5kIGRlc3Ryb3lpbmcgaXMgDQpub3QgYWNjZXB0YWJsZS4NCg0KI2luY2x1ZGUgPHZlY3Rvcj4N CiANCnN0cnVjdCBUZXN0T2JqDQp7DQogICAgc3RkOjp2ZWN0b3I8ZmxvYXQ+IGFycmF5Ow0KfTsN CiANCmludCBtYWluKCkNCnsNCiAgICAvKmNoZWNrIHRoZSBtZW1vcnkgdGhpcyBwcm9jZXNzIGNv bnN1bWUuIEl0IGlzIDYyNEtCIG9uIG15IGNvbXB1dGVyKi8NCiAgICBmbG9hdCBib2FyZCA9IDA7 DQoNCiAgICBmb3IoIGludCBpPTA7IGk8NTsgaSsrICkNCiAgICB7DQogICAgICAgIFRlc3RPYmog KnBvYmpzWzIwMF07DQogICAgICAgIGludCBqOw0KICAgICAgICBmb3IoIGo9MDsgajwyMDA7IGor KyApIHBvYmpzW2pdID0gbmV3IFRlc3RPYmo7DQogDQogICAgICAgIGludCBrOw0KICAgICAgICBm b3IoIGs9MDsgazwxMDA7IGsrKyApDQogICAgICAgIHsNCiAgICAgICAgICAgIGZvciggaj0wOyBq PDIwMDsgaisrICkgcG9ianNbal0tPmFycmF5LnB1c2hfYmFjayggYm9hcmQgKTsNCiAgICAgICAg ICAgIGZvciggaj0wOyBqPDIwMDsgaisrICkgcG9ianNbal0tPmFycmF5LmNsZWFyKCk7DQogICAg ICAgIH0NCiANCiAgICAgICAgZm9yKCBqPTA7IGo8MjAwOyBqKysgKSAgICBkZWxldGUgcG9ianNb al07DQogICAgfQ0KDQogICAgLypjaGVjayB0aGUgbWVtb3J5IGFnYWluLiAgSXQgaXMgNjUyS0Ig bm93Ki8NCiAgICByZXR1cm4gMDsNCn0NCg== |
|
From: Ivan-Assen I. <as...@ha...> - 2002-11-07 09:47:47
|
> I had programed an object class which has std::vector as its member. As the objects > are created and deleted in runtime, the memory of the process becomes bigger. The > following is a simplified version, in which memory growing seems no harm since the memory > is released to system once the process exits. > But for real program, memory growing in runtime with objects creating and destroying is > not acceptable. In most STL implementations, vectors only grow in capacity and never shrink. This is perfectly OK for 90% of the cases, and can be easily circumvented if you are aware of it in the other 10%. |
|
From: Colin F. <cp...@ea...> - 2002-11-07 13:05:51
|
2002 November 7th
Thursday
For Visual Studio .NET, the <vector> header has:
void clear()
{
_Tidy();
}
The destructor has an identical implementation:
~vector()
{
_Tidy();
}
The vector method _Tidy() supposedly frees all
storage.
Okay, even if this is not the case on your STL
implementation, I don't think this is the cause
of your "leak", since you apparently allocate
and delete objects that CONTAIN vector objects.
Regardless of vector's "shrinking" policy, destruction
of the vector object itself should free associated
storage.
I have three wild guesses about what you might be
observing:
[A] Best guess: You are doing "new" and "delete"
on a regular "struct", instead of a "class".
This may simply allocate raw bytes with the
same size as your structure. This means that
the "std::vector<float> array" member is NOT
CONSTRUCTED, but is simply given space to exist.
Even though C++ compilers may implement
"struct" as "class", I don't know if "new" will
CONSTRUCT members of a "struct".
Anyhow, I'm guessing that the "delete" calls
aren't calling the destructor of the "array"
object within the "struct" (TestObj).
EXPERIMENT:
Change the "struct" to "class" (TestObj), and
just add "public:". Don't make any other changes.
[B] Some kind of DLL page(s) just wasn't (weren't)
added to your process until you touched the
"new" and "delete" operators (implemented as
malloc() and free(), but enhanced with
calls to constructor and destructor functions).
So, maybe your program won't grow any more than
the observed 28KB even when you "new" and
"delete" 2000000 of your objects instead of
200.
[C] The C run-time library malloc() and free()
are "lazy" when it comes to returning memory
pages back to the OS -- for efficiency.
So, your process appears to remain bigger
even after you free all allocated memory.
The C run-time library may have tuned rules
to decide when to ask for more memory from
the OS, and when it seems obvious from the
passage of time that pages aren't likely to
be used again and can be returned to the OS.
I'll bet the CRT is trying to avoid system
calls in a big way.
I actually have no idea what might be going
on, but it would be interesting to change your
loop counters to 200000 iterations instead of
200, and see if the process growth is anything
other than 28KB.
If not, it would be interesting to reduce the
loop total to "1" iteration (a single "new"
and "delete"). If this is still 28KB, then
it appears that [B] explains everything!
Also, it would be interesting to wait a couple
of minutes, running other miscellaneous applications
that might demand lots of memory, and check
the process size of your test application.
If it shrinks, then [C] is the likely answer.
--- Colin
cp...@ea...
|
|
From: Mickael P. <mpo...@ed...> - 2002-11-07 13:14:03
|
Colin Fahey wrote:
> [...]
> I have three wild guesses about what you might be
> observing:
>
> [A] Best guess: You are doing "new" and "delete"
> on a regular "struct", instead of a "class".
> This may simply allocate raw bytes with the
> same size as your structure. This means that
> the "std::vector<float> array" member is NOT
> CONSTRUCTED, but is simply given space to exist.
> Even though C++ compilers may implement
> "struct" as "class", I don't know if "new" will
> CONSTRUCT members of a "struct".
> Anyhow, I'm guessing that the "delete" calls
> aren't calling the destructor of the "array"
> object within the "struct" (TestObj).
>
> EXPERIMENT:
> Change the "struct" to "class" (TestObj), and
> just add "public:". Don't make any other changes.
>
> [...]
There is absolutely no difference in C++ between class
and struct, except the fact that class are private by
default, and struct are public by default.
Construction/destruction behavior should be the same.
Mickael Pointier
|
|
From: Jon W. <hp...@mi...> - 2002-11-07 18:31:11
|
> [A] Best guess: You are doing "new" and "delete"
> on a regular "struct", instead of a "class".
> This may simply allocate raw bytes with the
> same size as your structure. This means that
Not true.
#include <stdio.h>
struct bar {
bar() { puts("bar::bar()"); }
~bar() { puts("bar::~bar()"); }
};
struct foo {
bar b;
};
int
main()
{
foo * f = new foo[ 1 ];
delete[] f;
return 0;
}
This prints the appropriate constructor/destructor. In fact, the
auto-generated assignment operator will also do the right thing.
However, if you implement your own assignment operator, it will
have to do all that manually.
> [B] Some kind of DLL page(s) just wasn't (weren't)
> added to your process until you touched the
> "new" and "delete" operators (implemented as
Possible.
> [C] The C run-time library malloc() and free()
> are "lazy" when it comes to returning memory
> pages back to the OS -- for efficiency.
This is usually the case. Similarly, the OS may be lazy about
returning pages from your general pool, even if you have marked
them as uninteresting. Hence, the Task Manager's "memory" display
is often a little bit misleading.
A good memory tracking subsystem is important to any decent-size
project.
Cheers,
/ h+
|
|
From: Brian H. <bri...@py...> - 2002-11-07 19:00:29
|
> A good memory tracking subsystem is important to any decent-size > project. This can't be emphasized enough. It takes a couple hours, if that, to write a decent memory allocation tracker. This will help identify leaks in your own program very quickly, as they occur, and also has the handy side effect of letting you trap on certain allocations, check for guard bytes being modified, and also gives you an indication of your run time memory requirements (not including stack, statics and globals). Brian |
|
From: Grills, J. <jg...@so...> - 2002-09-11 15:58:33
|
There is an issue between some drivers and the D3D runtime which will cause D3D to return invalid pointers when you lock resources. This is apparently not fixable in the drivers, so it has to be worked around in the app. We see this a lot filling dynamic vertex buffers. You can use IsBadWritePtr() or some other exception handling technique to deal with this. Hopefully DX9 will fix this. j -----Original Message----- From: Javier Arevalo [mailto:ja...@py...] Sent: Wednesday, September 11, 2002 5:02 AM To: gam...@li... Subject: Re: [GD-Windows] Windows paints my window! Brian Sharon <bs...@mi...> wrote: > Who said you have to actually process the messages? :) From MSDN: > IsHungAppWindow [...] > Call PeekMessage when you update your progress bars and all should be > well. --brian Thanks guys, with either the hollow brush thing or the PeekMessage trick, the window is now fine. However, when we put PeekMessage inside our KeepAlive call (which we call frequently from various load functions), we got a nasty DirectX crash if we Alt-Tab repeatedly. Until now we had only been able to generate this crash in convoluted Ctrl-Alt-Del sequences... it bombs in the middle of a vertex buffer refill: Device was ok, Lock() call was ok, the vertex buffer memory was accesible, but somewhere in the middle of the vertex buffer fill loop, the vertex buffer memory is lost and the rep movsd crashes halfway. I was under the impression that the only way to lose the device when fullscreen was either by Ctrl-Alt-Del (which has special considerations and doesn't take away locked memory), or by actually processing messages and letting your app be deactivated. We PeekMessage with PM_NOREMOVE during load, don't actually process messages, and most certainly don't call that function inside the vertex buffer fill loops, so AFAIK the only effect this PeekMessage should have is to let windows know we're not dead. Will cross-post this to the DirectXDEV list and see what people think. [ Note: funny thing, the crash showed up when I was using Photoshop, had the color picker dialog up, and tried to set the game to fullscreen 640x480 resolution. For some reason, Photoshop's color picker will not let any other app go fullscreen 640x480 (any other resolution is fine). You can try it with the DX samples. Bummer. ] Javier Arevalo Pyro Studios ------------------------------------------------------- In remembrance www.osdn.com/911/ _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
|
From: Rich <leg...@xm...> - 2002-09-11 16:25:26
|
In article <9EA...@ma...>,
"Grills, Jeff" <jg...@so...> writes:
> There is an issue between some drivers and the D3D runtime which will cause
> D3D to return invalid pointers when you lock resources. This is apparently
> not fixable in the drivers, so it has to be worked around in the app. We
> see this a lot filling dynamic vertex buffers. You can use IsBadWritePtr()
> or some other exception handling technique to deal with this. Hopefully DX9
> will fix this.
I thought this was discussed on the DirectXDev list a while back --
the workaround was to be more picky about when and where you call into
Windows.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book <http://www.xmission.com/~legalize/book/>
izfree: Open source tools for Windows Installer
<http://izfree.sourceforge.net>
|
|
From: Javier A. <ja...@py...> - 2002-09-11 17:37:14
|
[I moved most of this stuff to the DXList] Rich <leg...@xm...> wrote: >> There is an issue between some drivers and the D3D runtime which >> will cause D3D to return invalid pointers when you lock resources. >> This is apparently not fixable in the drivers, so it has to be >> worked around in the app. > the workaround was to be more picky about when and where you call into > Windows. So, bottom line: should PeekMessage() be called or shouldn't it while loading video resources? We're going to try commenting it out (since the window white effect was successfully removed by the hollow brush) and see if it happens less often. Javier Arevalo Pyro Studios |
|
From: Andrew G. <ag...@cl...> - 2002-09-11 18:23:03
|
I found doing Pump message loop TestCoopLevel Lock/Load/Unlock Between each resource and handling errors accordingly got rid of these ctrl+alt+del crashes on nvidia hardware. I may just have been lucky however. Andy @ Climax Brighton -----Original Message----- From: Javier Arevalo [mailto:ja...@py...] Sent: 11 September 2002 18:39 To: gam...@li... Subject: Re: [GD-Windows] Windows paints my window! [I moved most of this stuff to the DXList] Rich <leg...@xm...> wrote: >> There is an issue between some drivers and the D3D runtime which >> will cause D3D to return invalid pointers when you lock resources. >> This is apparently not fixable in the drivers, so it has to be >> worked around in the app. > the workaround was to be more picky about when and where you call into > Windows. So, bottom line: should PeekMessage() be called or shouldn't it while loading video resources? We're going to try commenting it out (since the window white effect was successfully removed by the hollow brush) and see if it happens less often. Javier Arevalo Pyro Studios ------------------------------------------------------- In remembrance www.osdn.com/911/ _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X