Hi, i'm running a game loop to update my animations. Thanks to the answers i've received now the game animation work well. It remains a very strange problem: when i start the executable, sometimes the speed of animation movement is very slow. Then, if i restart the PC the loop speed is fast as i think it should be. If someone have some idea .... many thanks Angelo
You don't happen to be Angelo Mottola (sorry if I misspelled it), do you?
no, i'm not. I'm new of win32asm. Ciao
Angelo Mottola? ANGELO MOTTOLA??? He owes me MONEY !!!!!
Just a thought, but is it just the game thats running slow? or the whole PC? Perhaps the game doesn't exit properly, and the next time you run it the previous version is chewing up the processor - or even another application.... Umbongo
i'm happy to see that my message is returned back again at the top of the list because i've not totally solved the problem of my little game speed: now the problem of the speed happen only sometimes. I've analized it better and it seems happening if i had other applications open togheter with the game. At the base i think it is a problem of my beginner wrong coding: i load many bitmaps, and create a CompatibleDC for every bitmap. I had to know better the SelectObject using. In any case on exit i use DeleteDC for every CompatibleDC created but i'm not sure to release all the memory used. By the way, another problem is that using PeekMessage and a GameLoop called at every MessageLoop, the movements of animation depends from PC clock -> bitmaps move faster on PC with faster clock. So i've done a little routine that run at game start that measure time elapsed to execute a loop of mov instructions for several times. So i can select some Sleep pauses to introduce in the game loop. Also for this, I think there is a more professional way. Sorry for my bad english. Hope you can understand. Angelo
Other apps... aaahh Is it using DirectX? If not, then you ned to take over the whole system. Word is notorious for taking up cpu time (like 50%) just sitting idle. Other things to look for:- FastFind.exe running - it's a load of old pants which will make you system judder like crazy, even if you're not gaming kill it! ICQ running in the background with a flashing tray icon will kill you too. Try, and be careful here, raising the priority of you process to realtime, that will give you the processor over anyone else. I'd say use DirectX in exclusive mode, that normally stops things messing your CPU about during a game :) Edited note: Use a separate thread to run your game, not PeekMessage etc.. have the main thread running your basic windows loop, then create a new thread to play the game in, look up CreateThread on how to do this, or reply here, and I'll post an example for you :) umbongo This message was edited by umbongo, on 3/27/2001 4:38:04 PM
1. In proccessor reality there is no such thing as "process priority" there is only thread priority from 0 to 31 But we can't set this priority number directly using API. That is where we meet the abstruct term "process priority" Which is used with fiction pseudo "tread priority" by system in tables to assign real value of thread priority and there is no straight correlation between those pseudo values and real thread priority values wich will be assigned by system. 2. There is no garantie that even you get the highest priority for your thread your prog will run faster. It's a BIG question. The only thing you can be sure of - if you don't have clear picture of how thread priority works and affect your machine you will have problems of hunging up vital system parts. It's complex topic, and it's impossible to discuss it in one message, I can offer for the starter something from J.Richter textbook: An Abstract View of Priorities When Microsoft developers designed the thread scheduler, they realized that it would not fit everyone's needs all the time. They also realized that the "purpose" of the computer would change over time. When Windows NT first came out, object linking and embedding (OLE) applications were just starting to be written. Now, OLE applications are commonplace. Game software is much more prevalent, and certainly the Internet wasn't discussed much in Windows NT's early days. The scheduling algorithm has a significant effect on the types of applications that users run. From the beginning, Microsoft developers realized that they would need to modify the scheduling algorithm over time as the purpose of the system changed. But software developers need to write software today and Microsoft guarantees that your software will run on future versions of the system. How can Microsoft change the way the system works and still keep your software running? Here are a few answers: Microsoft doesn't fully document the behavior of the scheduler. Microsoft doesn't let applications take full advantage of the scheduler's features. Microsoft tells you that the scheduler's algorithm is subject to change so that you can code defensively. The Windows API exposes an abstract layer over the system's scheduler, so you never talk to the scheduler directly. Instead, you call Windows functions that "interpret" your parameters depending on the version of the system you're running on. So, in this chapter, I'll be discussing this abstract layer. When you design an application, you should think about what other applications your user might run along with your application. Then you should choose a priority class based on how responsive you need the threads in your application to be. I know that this sounds vague; it's supposed to. Microsoft doesn't want to make any promises that will break your code in the future. Windows supports six priority classes: idle, below normal, normal, above normal, high, and real-time. Of course, normal is the most common priority class and is used by 99 percent of the applications out there. The table below describes the priority classes. Priority Class Description Real-time The threads in this process must respond immediately to events in order to execute time-critical tasks. Threads in this process also preempt operating system components. Use this priority class with extreme caution. High The threads in this process must respond immediately to events in order to execute time-critical tasks. The Task Manager runs at this class so a user can kill runaway processes. Above normal The threads in this process run between the normal and high priority classes (new in Windows 2000). Normal The threads in this process have no special scheduling needs. Below normal The threads in this process run between the normal and idle priority classes (new in Windows 2000). Idle The threads in this process run when the system is otherwise idle. This process is typically used by screensavers or background utility and statistic-gathering software.
Well, I suppose I was using the word 'thread' and 'process' interchangeably. Most people think of a process as the main thread in a single threaded program, if you add more threads then it becomes a multi-threaded program and the process becomes the sum of the threads. I think reasons to raise priority are like this: If your CPU utilisation across the system is only 50% then no thread is CPU bound, i.e. increasing the priority will not help. If you CPU utilisation is 100% for your own thread then the program is trying to do too much/inefficiently etc, and raising the priority won't help. However, if you CPU is at 100% utilisation and your program is getting 50% and another process is using 50% then raising your priority will help, because you will be scheduled before the other process. Of course the best course of action is to prevent that thread running. Hence the reason for my previous post, I used to play SubSpace regulary, it was a massive on-line game, and the most often asked question was - "why is my system jerky all of a sudden?" The reason was FastFind.exe Microsofts little program which trundles though your hard-drive cataloging your files, so you can search quicker. FastFind is rubbish to be honest, with modern hard drives it, at best, will speed your search up by .5 seconds - why bother - it's also taking up RAM. Which as I type reminds me of the real problem that caused the jerkyness, it wasn't just the fact FastFind was running, it was the fact it accessed your disk, which generates an interrupt, which halts the processor until it has finished - cauing the game to jerk.... Umbongo