Intel, there are no 3GHz AMD:s.
But the 3100+ is ok, im thinking about getting a 3500+ or a 3800+, but im not shure i need a new one this soon.

yes, there are no *real* 3Ghz AMD cpu's, but there's a sempron named 3Ghz (3000), which runs at 1800 Mhz I think.

You also have to remember. The above games mentioned are commercial quality games. That means as well that they are well optimized. The code bottlenecks were redone in assembly. More than likely anyway. On top of that, you have to remember that early NEHE tutorials use OpenGL immediate mode. As in glVertex3f() this is spoonfeeding the vid card which is the slowest way to do it. Either using display lists(NEHE #10 I think) of Vertex arrays(don't remember what number) greatly increases the speed of about any app. I'm sure that the commercial games you mentioned use one, the other, or both of these optimizations. NEHE's tutorials teach both of the above, but later in the tutorials. Also, I don't recommend using the windows message pump for input if you are. It is probably the slowest method, which may hinder your proggies as well.

Thanks for the tip, kburkhart84.
What's a fast recommended way to read input?

If you need really hard core speed, I'd say Direct Input. I tend to use the Win32 functions. The main one works like this.
if(GetAsyncKeyState(Key) & 0x8000)
Key is the ASCII keycode(same as for the message pump input). This doesn't wait on the windows message loop, rather it checks directly on the keyboard hardware itself at the time of the function call. It has always been plenty fast for me.

Quote:

Original post by bitprog I ran NeHe's lesson 09 program on my machine ( P2 400 Mhz ) and it runs fine and fastly. As soon as i start moving the cursor, the execution speed drops greatly and if I press some keys meanwhile it almost stops (close to 9 FPS).

Hey bitprog, one last piece of advice to try. How about downloading various ports of the lesson and see if those work. If you have SDL, GLUT, etc... see if those work any better.

- Drew

I think the problem would be your processor. Windoze, in case you hadn't noticed, isn't very fast (under statement). Your poor processor is already rolling off as many baches as it can manage, feeling quite stressed, when you move the mouse. Windows kicks in with a mouse over message or some such thing, which takes priority over the display message and proceeds to waste it's time doing not much (an operating system is much like a government in that respect). So the redraw message is delayed and your framerate drops. Then, just when the poor processor thought things couldn't get any worse, you press a key. This takes priority over pretty much anything and goes through some beurocratic proceedure until it finally arrives at your application because it's selected. And is most likely ignored. And there we have the story of a cpu's bad day.

My guess as to how to speed things up is just lighten the load on the cpu. Use direct input cause it probly shortcuts some of the message stuff. Do as much as possible in as few batches (highly recommended). Whatever else you can think of.

Quote:

Original post by kburkhart84 If you need really hard core speed, I'd say Direct Input. I tend to use the Win32 functions. The main one works like this. if(GetAsyncKeyState(Key) & 0x8000)

I thought this was a faulty function, or at least harder to handle than the way you showed. Doesn't it miss some keys sometimes? When I started programming (many years ago) I built a keylogger just to know if I could get through with it, and I used GetAsyncKeyState and it missed some keys sometimes. Nevertheless I will try it - thanks for the suggestion.

Quote:

Original post by Drew_Benton Hey bitprog, one last piece of advice to try. How about downloading various ports of the lesson and see if those work. If you have SDL, GLUT, etc... see if those work any better.

Like I said, I've already tried all of those. The only one I did not knew about was GLFW, which I am yet to try.

Quote:

Original post by RAZORUNREAL My guess as to how to speed things up is just lighten the load on the cpu. Use direct input cause it probly shortcuts some of the message stuff. Do as much as possible in as few batches (highly recommended). Whatever else you can think of.

Well, I already knew about how MS Windows® works, but I like your way of explaining it better. :D
It looks like DirectInput is the way to go. I'll try DirectInput and GLFW and see how they work out. Notwithstanding the results, I promise I'll buy a better computer (with a better OS) as soon as money comes in. :)

Until now, I haven't had any problems with GetAsyncKeyState. I have heard that if the keys are pressed really fast, it can skip, but my stuff usually has at least 60FPS, so it would be pretty hard to press and release a key that fast. I still say that DirectX is probably the way to go. The only other thing that I can think of is that if your OpenGL drivers are not working correctly. If your video isn't doing the acceleration, then OpenGL is doing it in software mode, which is really slow. That may be the other problem. Think about this. Quake was a fully 3d game, models and all. It wasn't semi 3d like DOOM rather the models are 3d. Descent was a 3d game with 6 degrees of freedom, with 3d models(maybe not all that pretty) as well. Both of these games ran on 90mhz processors with no hardware acceleration(correct me if I'm not accurate). I know descent worked in DOS, but I think quake had to have windows. OpenGL isn't really that slow, unless it is in software mode.