Author Topic: check for CPU speed  (Read 4641 times)

0 Members and 1 Guest are viewing this topic.

RAIN CODE

  • Guest
check for CPU speed
« on: June 24, 2014, 03:53:10 AM »
hi  guys

I noticed the pacman game still have speed issue when run on a faster PC. Especially if pacman is stationary; monsters moves very fast. The effect is very obvious if run on fast PC.

I am in the dark as do not know how to balance the speed as pacman have few speed : speed boost, somersault and hurling.

Below is a lisp (written by irneb but I made slight adjustment with 2000000.0) to check CPU speed. My pentium P4 returns a result around 1320. Am trying to use ratio of different speed to balance the speed.

(defun c:CpuT (/ time tick)
  (setq time (getvar "millisecs")
            tick (getvar "cputicks")
  )
   (while (< (-  (getvar "millisecs") time) 1000))
   (/ (-  (getvar "cputicks") tick) 2000000.0)
)

Can someone with a fast PC run this lisp 5 times and paste the result of the 5 returns, if possible please state your CPU speed.

Thanks.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: check for CPU speed
« Reply #1 on: June 24, 2014, 05:12:54 AM »
On my double Xeon X5650 2.67GHz (Acad 2014) I get the following:
Code: [Select]
Command:  CPUT
1337.86
Command:  CPUT
1334.22
Command:  CPUT
1332.86
Command:  CPUT
1338.7
Command:  CPUT
1329.59
« Last Edit: June 24, 2014, 05:21:23 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: check for CPU speed
« Reply #2 on: June 24, 2014, 05:47:08 AM »
I fear you'll never get this right if you go along the route you're heading. A much "simpler" approach is to time the cpu's ticks:
Code - Auto/Visual Lisp: [Select]
  1. (defun c:CPUSpeed (/ time tick)
  2.   (setq time (getvar "millisecs")
  3.         tick (getvar "cputicks"))
  4.   (while (< (-  (getvar "millisecs") time) 1000))
  5.   (setq time (getvar "cputicks"))
  6.   (princ (strcat "Current CPU ticks "
  7.                  (rtos (- time tick) 2 16)
  8.                  " times per second = "
  9.                  (rtos (/ (- time tick) 1e9) 2 2)
  10.                  "GHz"))
  11.   (princ))
Then testing it on mine:
Code: [Select]
Command:  CPUSPEED
Current CPU ticks 2663884040 times per second = 2.66GHz
Command:  CPUSPEED
Current CPU ticks 2687612537 times per second = 2.69GHz
Command:  CPUSPEED
Current CPU ticks 2675238147 times per second = 2.68GHz
Command:  CPUSPEED
Current CPU ticks 2685703835 times per second = 2.69GHz
And that tallies pretty well with my 2.67GHz CPU.

This was a mistake many a game developer did in the 80s. I remember several games I had during my school years. They ran perfectly on my XT 8086 4.7MHz 8bit 640kb PC, but when I tried to use them later on a friend's 80286 (12MHz 16bit 1MB) the game became unplayable. And even later, with my first CAD workstation (386 32bit 33MHz 4MB) the game's screen simply became a blur.

All the game developers learnt from this or went out of business: "Don't rely on the CPU's speed at all! Rely on the timer to govern the updates. There are simply too many variables which can affect the game's performance, so choose a time interval between updates and time the game between updates."

So you need to look at the millisecs, only allowing a move of the relevant object after a specific time has elapsed. This time is what you fine-tune instead of trying to figure out how fast the PC is. That's because even if you figure some factor to use for your particular CPU's speed and then how to compute that factor for any CPU - you're still not perfect as something may be using the CPU in the background either during the test or during the game-play. In both cases your game is going to run either too slow or too fast. With the timing governing game speed the worst that can happen is one single move "stuttering" as some background process uses up the CPU during one of your intervals.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

RAIN CODE

  • Guest
Re: check for CPU speed
« Reply #3 on: June 24, 2014, 05:49:14 AM »
On my double Xeon X5650 2.67GHz (Acad 2014) I get the following:
Code: [Select]
Command:  CPUT
1337.86
Command:  CPUT
1334.22
Command:  CPUT
1332.86
Command:  CPUT
1338.7
Command:  CPUT
1329.59

hi irneb

First, thanks for the suggestion by using timer to regulate the game speed. Before  that I was using a fixed math equation to check how many times or loop it can get it done in few seconds to find pc speed.

Then you also suggest a way to find the CPU speed. Thanks again.

I am abit suprised to see your result is only slightly different from mine. Then my idea of using the ratio of this result to balance the game speed may not work.


RAIN CODE

  • Guest
Re: check for CPU speed
« Reply #4 on: June 24, 2014, 06:01:57 AM »
sorry that is my reply to your 1st post.
The 2nd post is interesting. Let me read thru and digest it first...

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: check for CPU speed
« Reply #5 on: June 24, 2014, 06:28:42 AM »
I am abit suprised to see your result is only slightly different from mine. Then my idea of using the ratio of this result to balance the game speed may not work.
Exactly, the cputicks simply measure how many times the cpu has done an instruction per second. I.e. it should give you the GHz of the CPU. If I compare your value to mine, I'd say your P4 is probably very close to 2.5GHz.

The actual "speed" of execution is affected by many more things. E.g. newer CPUs have special instructions which may run the same amount of processing an older CPU did in 10 instructions in only one single instruction. It may pipeline RAM fetches such that while one instruction runs it's already fetched the RAM for the next 2 or more instructions. And that doesn't even consider anything regarding the display through CPU / graphics card.

I'd say your best bet is to define a "speed of movement" per object in your game. See this as saying "Ghost 1 moves at 1.5 positions per second, Ghost 2 @ 2.25 positions / sec, etc.". In which case you don't even consider how fast to update, you simply update whenever, read the millisecs and use that to figure out how far each object should have moved. That's exactly how games of today work - thus the speed never changes, but if the PC is faster the gameplay simply becomes more smooth (with a very slow PC it might be noticeably jerky).

Or (depending if you find this math easier) define the speed per object as - how long does it take to move from one position to the next. E.g. G1 = 1.5/sec = 1/1.5 = 0.67sec = 667msec. Then you measure how many millisecs have elapsed since the previous move, and divide that by the object's time to move one space - giving you a factor which is the distance covered by that object. E.g. say the number of millisecs is 50 (i.e. 1/20th of a second) then 50/667 = 0.075 positions.
« Last Edit: June 24, 2014, 06:34:43 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

RAIN CODE

  • Guest
Re: check for CPU speed
« Reply #6 on: June 24, 2014, 06:57:06 AM »
I remember several games I had during my school years. They ran perfectly on my XT 8086 4.7MHz 8bit 640kb PC, but when I tried to use them later on a friend's 80286 (12MHz 16bit 1MB) the game became unplayable. And even later, with my first CAD workstation (386 32bit 33MHz 4MB) the game's screen simply became a blur.

All the game developers learnt from this or went out of business: "Don't rely on the CPU's speed at all! Rely on the timer to govern the updates.

So you need to look at the millisecs, only allowing a move of the relevant object after a specific time has elapsed.

With the timing governing game speed the worst that can happen is one single move "stuttering" as some background process uses up the CPU during one of your intervals.

 Its great to know you have written games before then I found the right person to get tips from or the right direction to go from here.

Ya. I did follow your previous suggestions by using timer to check if time lapsed if yes then do animation.  below is a rough code via handphone

(setq pmdt 0
           monsdt 0
          gameloop t
           PmGameSped 10
            GameSped 10)

(while gameloop
(if (> (- current-time pmdt) PmGameSped) ;;time lapsed then
  (progn
   --- do pacman animation---
   (setq pmdt (getvar current-time))

   )
)

(if (> (- current-time monsdt) GameSped) ;;time lapsed then
  (progn
   --- do monsters animation---
   (setq monsdt (getvar current-time))

   )
)
) ;;while gameloop
 
 


XXL66

  • Newt
  • Posts: 99
Re: check for CPU speed
« Reply #7 on: June 24, 2014, 07:45:29 AM »
C:CPUSPEED
Command: CPUSPEED
Current CPU ticks 3428237991.000000 times per second = 3.43GHz
Command: CPUT
1713.84
Command:
Command: CPUT
1717.75
Command:
Command: CPUT
1709.01
Command:
Command: CPUT
1712.46
Command:
Command: CPUT
1705.12


on a 3.4Ghz

CAB

  • Global Moderator
  • Seagull
  • Posts: 10401
Re: check for CPU speed
« Reply #8 on: June 24, 2014, 07:52:02 AM »
Command: cput
1463.94

Command:
Command: CPUT
1465.89

Command:
Command: CPUT
1465.49

Command:
Command: CPUT
1461.03

Command:
Command: CPUT
1479.06

Command:
Command: CPUT
1476.0
I've reached the age where the happy hour is a nap. (°¿°)
Windows 10 core i7 4790k 4Ghz 32GB GTX 970
Please support this web site.

RAIN CODE

  • Guest
Re: check for CPU speed
« Reply #9 on: June 24, 2014, 07:54:45 AM »

I'd say your best bet is to define a "speed of movement" per object in your game. See this as saying "Ghost 1 moves at 1.5 positions per second, Ghost 2 @ 2.25 positions / sec, etc.". In which case you don't even consider how fast to update, you simply update whenever, read the millisecs and use that to figure out how far each object should have moved. That's exactly how games of today work - thus the speed never changes, but if the PC is faster the gameplay simply becomes more smooth (with a very slow PC it might be noticeably jerky).

Or (depending if you find this math easier) define the speed per object as - how long does it take to move from one position to the next. E.g. G1 = 1.5/sec = 1/1.5 = 0.67sec = 667msec. Then you measure how many millisecs have elapsed since the previous move, and divide that by the object's time to move one space - giving you a factor which is the distance covered by that object. E.g. say the number of millisecs is 50 (i.e. 1/20th of a second) then 50/667 = 0.075 positions.

These are 2 good suggestions.  Previously I should have ask you for more details first before going for the changes but I didn't becos when I heard you say use timer to regulate game speed and immediately I thought you were saying that (please see rough coding above)

 I have to see how much of changes it will affect the coding. If it affect alot then I will use one of these on my next project if I have the same free time again to write.

I like the first suggestions. It make more sense. Thanks again irneb.
Now you have given me something to think about - to change or not to change ?





RAIN CODE

  • Guest
Re: check for CPU speed
« Reply #10 on: June 24, 2014, 08:19:06 AM »
hi XXL66
hi CAB

more people post the result now I realized that it is actually the clock speed. (embarassing LOL)

In that case no need to post anymore.


PKENEWELL

  • Bull Frog
  • Posts: 309
Re: check for CPU speed
« Reply #11 on: June 24, 2014, 09:32:24 AM »
From My AMD Phenom II X6 1055T 3.46Ghz, 64 bit, AutoCAD 2014, 8Gb RAM:

EDIT: OOPS - Sorry did not see the last message before posting :-p

Quote
Command: CPUT
1731.19

Command:
Command: CPUT
1734.65

Command:
Command: CPUT
1734.5

Command:
Command: CPUT
1735.42

Command:
Command: CPUT
1736.36
"When you are asked if you can do a job, tell 'em, 'Certainly I can!' Then get busy and find out how to do it." - Theodore Roosevelt

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: check for CPU speed
« Reply #12 on: June 24, 2014, 10:06:56 AM »
Its great to know you have written games before then I found the right person to get tips from or the right direction to go from here.
I did some game dev very long ago - as part of my CS course (third year thesis). So I'd not call myself a game developer, but I do have some insight as to what they need to think about.

Anyhow, I'd go about such in a more OOP like design. Even though AutoLisp doesn't provide object-orientation, I'd still try to keep the ghosts and the man as items with their properties.

So to design, think of what properties a ghost has at any one instant. E.g. a name to identify it, a drawing object which displays it, the current position, the current direction of movement, the current speed, the time of its last move. Then you have a list of all those and you run through each in an loop while asking the user for input (e.g. using grread, though I'd imagine you'd rather just use an infinite loop and reactors to fire when the user provides input).

So depending on what the user does, you may want to alter one (or more) of those "actors" in the list. E.g. change the direction of pacman if the user presses an arrow key.

No matter what the user did, you would still run an "update" routine on each of the "actors" in that list. This routine does the following:
  • get the current-millisecs
  • move the object by (* actors-speed (- current-millisecs actos-last-move)) in the actos-angle
  • subst the actors-last-move with current-millisecs
I'd do this through a mapcar which re-sets the actors list each time.

Of course this is very simplified. E.g. You might need to check if the actor can move in its current direction, say testing if the "map" has a wall in front of it. Depending on that it might need to change direction - for the ghosts using some "AI" or random principle, for the PacMan you might need to stop it until the user presses something else.
« Last Edit: June 24, 2014, 10:10:56 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

RAIN CODE

  • Guest
Re: check for CPU speed
« Reply #13 on: June 27, 2014, 01:14:12 AM »
sorry irneb

I tends to misread as now using hphone to write posting. Screen is small. only realized reading mistake when reread it

Anyway thanks for your time for helping me work around this problem.

Your last post is quite long. will reply after lunch break.

thanks again

RAIN CODE

  • Guest
Re: check for CPU speed
« Reply #14 on: June 27, 2014, 05:11:18 AM »
Hi irneb
Now I understand why the game speed is not consistent. The return of timer result is always above 15 or 16 millisecs. It just cannot detect anything below 15 or 16 ms.

And if I set the game speed at 12 ms via F8 function key thru the speed setting dialog box. When game run it just simply cannot detect anything below 15 ms. It returns 0 or 15. If result is 0 then the IF statement is true then it do animation.

Now I am trying to use repeat loop to replace timer but the lisp didnt work on faster PC as danallen ran the lisp but it works on my PC. 

Please see new post
 http://www.theswamp.org/index.php?topic=47326.0


So depending on what the user does, you may want to alter one (or more) of those "actors" in the list. E.g. change the direction of pacman if the user presses an arrow key.


Grread isnt so good at detecting keyboard. I wrote a short lisp to detect keyboard key but it only detect about once every 30 loops if I remember correctly.

My phone isnt link to my PC else I could paste here.