Dan Smith: I agree 100%


- null_pointer
Sabre Multimedia

Hey, guys. Have you never experienced something like that while running your games? I''ve noticed that too when I am using the NeoRageX emulator. If we should not to change the priority, there must be another way to turn Windows off... Of course - it''s easy to blame Windows for something like that, but my code is so simple that I don''t think I''m doing something wrong...

Thanks,

André Luiz Silva
"There is no knowledge that is not power"

Well, I asked around for a month to get a better fix, but nobody ever gave me one. This is the ONLY thing that has alleviated me of the problem, and my code is doing nothing it shouldn''t be. Until somebody gives me another fix I''m going to stay on the priority train.

Rock

Andre, if other games don''t seem to have that problem, I''d agree with Ridcully that it''s your game that''s responsible for the swap. It''s not necessarily an error of yours; I think that if you alocate something then dealocate inside a cicle, while it is perfectly legal, you could make windows start rearanging the virtual mem. If this is the case, you could try to pass frequently allocated/dealocated memory to outside cycles or functions that get called often, or even alocating that memory once at the start of the program. If not for this reason, it will at least give you some speedup
Boa sorte

Ugh, once again, ignorance abounds...

PeekMessage( &msg, hwnd, 0,0, PM_NOYIELD );

Use this to process your windows messages. This prevents the idle system process from kicking in unnecessarily.

MSN

P.S. You might want to add in some post-processing of WM_QUIT to make sure your program cleans up correctly.

Hey..

Thank you all guys. I will try each of the suggestions you have posted.

Obrigado!

André Luiz Silva
"There is no knowledge that is not power"

PM_NOYIELD doesn''t do anything on the 32bit systems. It''s only there for backward compatability with win3.1.

Rock

Rock2000: I almost posted the same thing, but in the MSDN 6.0a docs it doesn''t seem to mention that anywhere? Perhaps they updated the information, as I think it has something to do with WaitForInputIdle. (The 4.0 version of MSDN does say it doesn''t do anything, though.) Odd, isn''t it? Anybody know more about it?


- null_pointer
Sabre Multimedia

Well, god only knows with Microsoft. One second they say ''don''t use it, it doesn''t do anything'', and the next they say ''hey guess what, its back''. If they''re reusing an old value for something new, then I''ve lost yet more faith in them, which is almost impossible.

But even if does do something new now, it wouldn''t be what msn said, because running a normal PeekMessage loop doesn''t allow for idle processing anyway, according the msdn (Direct quote below).

------------------------------------------------------

// This PeekMessage loop will NOT let the system go idle.

for( ;; )
{

while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
if (msg.message == WM_QUIT)
return TRUE;

TranslateMessage(&msg);
DispatchMessage(&msg);
}

BackgroundProcessing();
}
-----------------------------------------------------

Rock

quote: Original post by Rock2000

But even if does do something new now, it wouldn''t be what msn said, because running a normal PeekMessage loop doesn''t allow for idle processing anyway, according the msdn (Direct quote below).

Rock

Hmm... that wasn''t the point I was making, so let me clarify...

PeekMessage should be used as opposed to GetMessage, since GetMessage tells the system your app is **WAITING** for messages, hence, it''s an opportunity for the system to perform some background stuff. PeekMessage tells the system you''re still busy and youwant to make sure your messages don''t get backed up. This prevents the system from flagging your process as [Not-Responding].

Trust me, I know what I''m talking about. Knowledge is more than just bitfields and flags...

MSN