Jump to content
  • Advertisement
Sign in to follow this  
Jiia

Window mode error [updated]

This topic is 5271 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quote:
Original post by Halsafar
QueryPerformanceTimer is much more accurate than getTickcount especially on faster machines...

I'm not using getTickCount. I could have sworn I told you that I'm using windows media timers with a callback function. The timer I use is accurate enough that I can turn the resolution down and still get more accuracy than I need. This timer requires very little overhead, as I've been using it since way back when I was running a 233mhz laptop. It's not safe to assume that what you use is the best, and everything else should be avoided. That's not how it works.

Quote:
Okay seriously, think about it. Have you written a proper msgPump/gameLoop, your gameLogic is also updating the window and recieving and dealing with any incoming window messages, which means your game updates, then the window updates.

Yep, that's how it works. But the only updating that usually takes place is simply asking windows if it has messages. That's not much more than if( msg_count != 0 ). Doesn't seem like something to freak out about or something to throw into a seperate thread. You'll probably hate to hear this, but most DirectX functions have more overhead than windows message checks.

Quote:
In my solution, I have the window simple pause on GetMessage like a regular WinApp does and my gameLoop is just constantly udpating and since a gameLoop is suppose to written to manage itself it all works out. Now not only is your gameLoop going to update faster, the window does not have to wait for the gameLoop if it needs to udpate for some reason.

There's no reason to care if windows has to wait 4 milliseconds for your game frame to finish. I've made windows wait 30 seconds before checking messages during loading calls in the past. The worst thing that happened was my window didn't get repainted when I dragged something over it. If I were full-screen, there would have been no differences.

Quote:
As for making resource management easier, well it requires a few small messaging tricks and adding a wait event having your game thread pause when necessary using WaitForMultipleObjects. For example, your game thread returns device lost on the PRESENT, send a message to the window, pause the thread. The msg pump will recieve the message and go "oh, time to reset" and it will enter a TestCooperativeLevel loop waiting for the window to recieve focus, once it does, reset, restore, unpause the thread by setting the event it is waiting on. You'd have to get a working model of the application to see how blissfully easy the Reset/Restore/ of resources becomes.

That's supposed to be easier? Why not just call the same function that is called when an object/game-mode is loaded or released? There's no reason to write brand new routines just to handle a reset.

Quote:
Performance increase, well the guy who tipped me into the project was Electroman from VbForums as he wrote a rather nice tutorial project to cover this. He claimed he was achieving with a blank gameLoop that simply cleared the device with a new color each frame around 5000fps but that would attribute to the mighty GPU he has I believe. When I ran it with my pathetic onboard card I got around 600fps. I wouldn't doubt that in most case's the performance increase is negligable but it is worth it since in many case's, especially on slower comps, the increase will be noticed, especially if you have a heavy WndProc.

The part I can't get over is why you were "shocked and amazed". The performance increase, if not negative, is not even a factor. It's like arguing that I should use while loops instead of for loops. Except using a seperate thread is not as trivial as changing a keyword. I've yet to hear anything that sounds like any kind of advantage to be gained. Forgive me if I'm just too dumb to grasp it.

Quote:
Sorry I took so long to reply, I forgot about this thread.

I did too. Why did you dig it up? [smile]

Share this post


Link to post
Share on other sites
Advertisement
Because I disagree with everything your saying and still do :)

Well most of it, I mean good points but I've made several game engines and as soon I multithreaded it made things a lot easier to tie together. I notice a minor speed increase but that was with a blank loop.

Not to mention, I was recently informed that UT2k3 uses a seperate thread for AI, objects, players, etc.

[Edited by - Halsafar on June 12, 2005 8:31:57 PM]

Share this post


Link to post
Share on other sites
I don't know much about processor functionality, so I can't comment on what kind of bonus there would be by seperating several CPU-intense activities. My engine always caps the CPU usage out at 100%. I don't see how I could push it any further. Still, it's possible that by using different threads, the CPU is able to pull more load with the same usage.

I don't think seperating something like messaging would make much difference. And even if seperating CPU-intense routines had an impact, it would have to be a pretty big impact for me to want to try seperating my logic into simultaneous components.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!