Winamp's notification boosts DirectDraw speed???
Author
I have added alpha functionnality to ddraw with my wrapper and something strange was happening and now I can reproduce it, but it''s way too strange.
When running my test (which is basically just blitting the back surface to the primary surface, it runs at 130fps, but when Winamp 5''s notification appears (if you''ve used it you know what I mean), the frame rate goes up to ~200fps, and I know that the game does the exact same thing. The other thing I noticed, which makes sense, is that when that happens, the CPU usage goes to 100%, contrary to the rest of the time where it somehow doesn''t exceeds 50%...
What on earth is going on?
hrm, do you have dual CPUs? i wonder if the winamp notification is somehow shuffling you to the other CPU where you get more processor time or something. this theory makes no sense 
Do you have sleep messages peppered throughout your code? 50% CPU utilization is wierd to get for most game-type apps. unless you call sleep in your code somewhere apps tend to take 100% of the available CPU budget.
-me
Do you have sleep messages peppered throughout your code? 50% CPU utilization is wierd to get for most game-type apps. unless you call sleep in your code somewhere apps tend to take 100% of the available CPU budget.
-me
"I have added alpha functionnality to ddraw with my wrapper.."
I assume via a locked surface and software routine since alpha is not implemented via most graphics cards using Direct Draw?
I assume via a locked surface and software routine since alpha is not implemented via most graphics cards using Direct Draw?
What is going on is this:
Both your app and something in Winamp are both running as fast as possible (i.e. they each receive approx 50% of the CPU). Then, when Winamp''s notification appears, it stops its CPU gobbling (it''s probably in a different loop, because a different window is active), freeing up the CPU - which your app then is free to take over because your app is still trying to get as much as possible. So Windows gives the now-spare CPU time to your app, your app''s CPU usage doubles and your FPS jumps. Turn off Winamp altogether, and I bet your app will run at near-100% CPU usage and ~200 fps as well.
I still use Winamp 2.9, because its CPU usage is just so dang low all the time.
Brian
Both your app and something in Winamp are both running as fast as possible (i.e. they each receive approx 50% of the CPU). Then, when Winamp''s notification appears, it stops its CPU gobbling (it''s probably in a different loop, because a different window is active), freeing up the CPU - which your app then is free to take over because your app is still trying to get as much as possible. So Windows gives the now-spare CPU time to your app, your app''s CPU usage doubles and your FPS jumps. Turn off Winamp altogether, and I bet your app will run at near-100% CPU usage and ~200 fps as well.
I still use Winamp 2.9, because its CPU usage is just so dang low all the time.
Brian
Author
Palidline:
No, I have a normal P4 without HT.
2dCoder:
Exactly, currently I have only bothered to implement the 32 bits standard versions, no MMX or whatever for the moment... Except one blit with MOVNTQ, as someone suggeseted me and it works fast.
As for the blit I''m using to blit back to front, it''s DDraw''s Blt, simply.
And in fact, it''s this blit that''s making CPU usage remain low, when I remove it, CPU goes back to 100% (but nothing is shown on screen of course). I guess it has something to do with DMA use, but why isn''t the function returning control before it''s finished, if so??? And why is something like winamp can make it go faster?
BriTeg:
Good try But when winamp is unloaded, it does the same thing. It''s just when it''s notification appears that the whole thing goes faster! When it''s not in memory at all, the program goes on at its normal 130fps pace.
No, I have a normal P4 without HT.
2dCoder:
Exactly, currently I have only bothered to implement the 32 bits standard versions, no MMX or whatever for the moment... Except one blit with MOVNTQ, as someone suggeseted me and it works fast.
As for the blit I''m using to blit back to front, it''s DDraw''s Blt, simply.
And in fact, it''s this blit that''s making CPU usage remain low, when I remove it, CPU goes back to 100% (but nothing is shown on screen of course). I guess it has something to do with DMA use, but why isn''t the function returning control before it''s finished, if so??? And why is something like winamp can make it go faster?
BriTeg:
Good try
But when winamp is unloaded, it does the same thing. It''s just when it''s notification appears that the whole thing goes faster! When it''s not in memory at all, the program goes on at its normal 130fps pace.
quote:
Good try
Are you sure it's not running in the background, in the tray or something? The notification (like any app) can't start itself, something has to be running to make it appear.
Here's how to find the culprit: when your app is running at 50%, hit ctrl-alt-delete to bring up the Task Manager, click on the "CPU" column-header to sort the tasks by CPU usage, and see what app is taking the other 50% (or near-100% if your app is not running).
[edited by - BriTeg on March 30, 2004 10:01:11 AM]
I suggest you try the same thing BriTeg. I don''t know about you but I''ve got WinAmp 5 playing an MP3 right now with CPU usage so close to zero that it doesn''t even register in the task manager. I really doubt it would cause any noticable speed hit while it ISN''T playing anything, even if it is still running.
As for what''s actually happenning....no idea
As for what''s actually happenning....no idea
Author
Yeah, well I''m at a loss completely. What is happening?
It must have something to do with the DMA transfer that''s happening when using DDraw''s blit. Because when I use my custom SSE blitter, first it''s slower, and second it uses 100% CPU, contrary to DDraw''s blit.
But I would really like to know what it is that winamp''s notification is doing to trigger that particular effect. I guess it must allow the blit to return before it''s finished, as opposed to waiting before it finishes to return.
If anyone else has experienced this, please do tell me. Anyone has tried running his/her DDraw app (that uses system memory for processing and then updates to vram) with winamp''s notification to see the speed change? Perhaps I''m not the only one.
It must have something to do with the DMA transfer that''s happening when using DDraw''s blit. Because when I use my custom SSE blitter, first it''s slower, and second it uses 100% CPU, contrary to DDraw''s blit.
But I would really like to know what it is that winamp''s notification is doing to trigger that particular effect. I guess it must allow the blit to return before it''s finished, as opposed to waiting before it finishes to return.
If anyone else has experienced this, please do tell me. Anyone has tried running his/her DDraw app (that uses system memory for processing and then updates to vram) with winamp''s notification to see the speed change? Perhaps I''m not the only one.
Seems to me more likely that WinAmp is messing with the PerformanceTimer or something than actually speeding your program up. Since your refresh rate is probably below both 200fps and 130fps, you won''t be able to tell visually.
Maybe you could try adding a lot of sprites/polys/particles/whatever so that your engine gets 10fps, and then if WinAmp is really speeding it up, you should be able to see the increase? Just an idea.
Maybe you could try adding a lot of sprites/polys/particles/whatever so that your engine gets 10fps, and then if WinAmp is really speeding it up, you should be able to see the increase? Just an idea.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
