Path: chuka.playstation.co.uk!chuka.playstation.co.uk!news
From: jamesr@peace.co.nz
Newsgroups: scee.yaroze.programming.libraries
Subject: Re: Timers
Date: 22 Sep 1997 16:58:11 GMT
Organization: PlayStation Net Yaroze (SCEE)
Lines: 103
Message-ID: <606836$5328@emeka.playstation.co.uk>
Reply-To: jamesr@peace.co.nz
NNTP-Posting-Host: 194.203.13.2
Originator: news@emeka

From: Lewis_Evans@Playstation.sony.com
To: news@playstation.co.uk






To:       Lewis Evans
cc:
From:     news @ playstation.co.uk
Subject:  Re: Timers:scee.yaroze.programming.libraries




From: James Russell <jamesr@peace.co.nz>
Newsgroups: scee.yaroze.programming.libraries
Subject: Re: Timers
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lewis_Evans@PLAYSTATION.SONY.COM wrote:
>
> All you need is a method for translating frameCounter times in your
program
> to seconds in the real world.
> (assuming you have a frameCounter variable that's updated every pass
> through the main loop).
>
> Firstly detect PAL or NTSC; now you know 50 or 60 frames per second.
>
> Secondly calculate the program's own frame rate from its hsync count.
(Get
> hsync by VSync(1);
But that won't work if the frame rate is variable.

-- You're right; but you can get pretty close estimate of variable frame
rate without wasting too much memory.
Just store the
> 240 scan lines for one frame of NTSC and 270 for PAL (roughly)). This
tells
> you the frame rate divider
> (integer, typically 1 to 4). Now you know how long one frame takes.
>
> Eg in a PAL program with hsync count 340, frame rate divider is 2, ie
> running at 25 fps.
>
> Hence you can detect when N.M seconds have passed.
>
Whoa, didn't get that at all.

-- All I mean is: the hsync (horizontal scan line count) of a single pass
through your program determines the frame rate.
Lots of sample code has lines like this

cpuLoad = VSync(1);      // find number of scan lines taken by CPU work
DrawSync(0);             // wait for all draw processes to finish
gpuLoad = VSync(1);      // find GPU load
VSync(0);           // wait for vertical blank interrupt

The part about 270 - PAL and 240 - NTSC is the limits on what you get per
scan line;
eg in PAL,

FrameRateDivider = 1;
hsyncCopy = hsync;       // copy the number of scan lines taken per single
pass through main loop
while (hsyncCopy > 270 )
     {
     FrameRateDivider++;
     hsyncCopy -= 270 ;
     }

knowing the FrameRateDivider tells you the actual frame rate (maximum
divided by the divider).
One solution I could use would be to use Bresenhams (!) algorithm.
If in PAL, run the program as normal (50 times a second) but if in NTSC
you've got to run the interrupt on MOST (but not all) Vsync interrupts.
To figure out which ones, draw an imaginary line from (0,0) to
(width 60 (or X*60),50 (or X*50)). Every frame, advance 1 pixel to the
right
and if you go 'up' a pixel, call the interrupt, otherwise don't.
This effectively calls the interrupt 5/6 of the time on an NTSC system,
i.e. 50 times a second. Because Bresenhams handles the error nicely,
you don't get the slight speedup/slowdown caused by an inaccurate
fraction representation of 5/6.
I would LIKE to use the root counters, and the User Guide *briefly*
mentions
something about the root counter and interrupts, but ends there.

-- See an SCEE demo (I think it's called 'profile') for use of the root
counter.
Basically, GetRCnt(1) returns the value of the counter. I think it uses
hsyncs (scan lines)
as unit of measurement (not sure though).
No luck then.

Cheers,
James