Windows Vs. My Game

Started by
26 comments, last by Andre Luiz Silva 24 years ago
Well, OK, nobody is going to dispute that statement, but that isn''t really what we''re talking about. I certainly hope nobody is using GetMessage for games. The point is that using a loop like the example I quoted I above (except where BackgroundProcessing is the game loop), the game still loses time to Window''s stuff every once in a while. As I''ve said, the only way around it that I''ve seen is to up the priority to keep that from happening.

Rock
Advertisement
Rock2000 - maybe you are right, as you said you had always used SetPriorityClass. I had never tried the PeekMessage loop, and although we loose some time, maybe, it will be faster than the problems I''ve encountered. My game really stops for some milliseconds, I can hear my hard disk reading/writing and then things come back to normal. What I am trying to say is that we should give a try to every entry here. That''s the only way to discover the pros/cons each one has to offer.

Thanks,


André Luiz Silva
"There is no knowledge that is not power"
"- To begin with, said the Cat, a dog's not mad. You grant that? - I suppose so, said Alice. - Well, then, - the Cat went on - you see, a dog growls when it's angry, and wags its tail when it's pleased. Now I growl when I'm pleased, and wag my tail when I'm angry. Therefore I'm mad."
I''ve seen commercial games use thread priorities. Check this out.
I have this Win32 SDK tool called Pview 95 (process viewer) which
shows all running processes, their priority, and how many threads
they are using.

I just downloaded a game demo called Metal Fatigue, ran it, alt-tabbed
out to windows, ran process viewer, and it showed that the game
had two threads running, one was set at 28 (time critical!) and the
other was set at 13 (normal).

I also have a Starcraft demo, and it showed it had 5 threads running,
3 were 8 (normal), 1 was 9 (above normal), and 1 was 10 (highest).

So, I think it is perfectly ok to use those functions, especially
if you have more than one thread running. For instance, if you had
a rendering thread and an input thread, you could give one a higher
priority than the other.

Rasta
quote:Original post by Rasta

So, I think it is perfectly ok to use those functions, especially
if you have more than one thread running. For instance, if you had
a rendering thread and an input thread, you could give one a higher
priority than the other.

Rasta



Normally, when discussing advanced resource utilization on these boards, most people:

a.) Have no idea what they are talking about.
b.) Have some idea of what they''re talking about, but their program/app probably needs improvement elsewhere (algorithm, API calls, structure, etc.) Like the PeekMessage loop.
c.) Have a good idea of what they need to do.

C never happens here (Actually, rarely... normally those issues come out on the algo/sweng lists.)

So, I tend to view most problems as a or b (leaning heavily towards a as of late...)



So, before you go off into thread priority hell, here are some helpful guidelines you should not violate unless you know exactly what you are doing or you''re running exclusively on SMP machines.

1. Use higher priorities for threads that will do less work, but need to do it w/ little latency: input, network, etc... NOT video.

2. Make sure those threads (from 1) sleep as much as possible.

MSN
msn12b,

I agree 100% with you. I''m not an expert, and I have never stated that I
was an expert. So don''t listen to me. All I would tell someone else to
do is run your favorite game, check out how many threads it is running and
see what priorities they are set at, and make your own decision on what you
should do.

Rasta
quote:Original post by Rasta

msn12b,

I agree 100% with you. I''m not an expert, and I have never stated that I
was an expert. So don''t listen to me. All I would tell someone else to
do is run your favorite game, check out how many threads it is running and
see what priorities they are set at, and make your own decision on what you
should do.

Rasta


Hee-hee, now we get into the apology cycle of this thread

Rasta, that first paragraph had nothing to do w/ your post. Just a general rant. (I had enclosed it in RANT tags, but they got eaten up by the HTML renderer.)

MSN
Hehe, you''re full of insults, aren''t you msn? And I suppose you fit squarely into group C, huh?

Well, I''m not going to get roped into a flame war, so I''ll just say this. I didn''t say priority cranking was the best solution, but the best one I''ve seen to solve the problem. You haven''t added anything but the obvious so far. Of course we should be running a Peekmessage loop, but that doesn''t stop Window''s from severley interrupting, it just limits idle processing. I''m glad you suggested it, but I''m just saying I do that it doesn''t fix the problem.

Rock
There are two basic problems that are being addressed here. Firstly, while Win16 systems relied on "cooperative multitasking", the new Win32 systems throw in "preemptive multitasking". Hence, your game will always be interrupted on a regular basis, being determined by the priority. However, when reading from the message queue using GetMessage, Windows automatically kicks in its copperative code and task switches. So, obviously, using PeekMessage (which never blocks/task switches) should be your first fix. If that doesn''t provide enough CPU time, then you may (or may not; there may be something else wrong) need to adjust priorities.

This topic is closed to new replies.

Advertisement