NFS: Hot Persuit 2

[VNZ]

BenSkywalker:

One more question, do you consider the original Zelda to run @60FPS?

I never owned the NES Zeldas, and haven't seen it in action for almost 15 years. I would be quite surprised if the sprite positions are updated only every second frame, though, so I my guess is that it does run at 60fps. However, since it didn't feature any real full-screen scrolling the framerate wasn't too obvious, or important.

Anyway, the majority of Atari 2600, NES, PC Engine, Megadrive, arcade etc titles of the 80s ran at 60fps. With 2D scrolling it's painfully obvious when you cut it down to 30fps. That said, slowdown was common, but in most cases the games ran at 60fps most of the time.

Those machines were practically built to do one thing; move background and sprite graphics at 60fps. I don't understand why the concept of 2D graphics at 60fps seems to be so hard to comprehend.

 

[BenSkywalker]

VNZ

OK, so you don't remember Zelda(it actually did have fully scrolling screens, whenever you went up or down, left or right the entire screen would scroll over, this is the single best example I could think of in FPS terms for that era's games).

The reasons why I have been asking these questions are due to the amount of possible animations and what you are stating constitutes 60FPS. Super Mario Bros offered around eight frames of animation for each 'type' of Mario(small, large and fire powered) and yet you consider it to be a 60FPS game. I already mentioned the comparison with Quake(IIRC) running @100Hz @50FPS, without the proper amount of differing animations to utilize you are simply redisplaying the same image over and over.

The reason why I brought up resolution? You have brought up numerous times the scrolling background issue and how poor it looks running at 30FPS. Given the resolution of the earlier games you were only utilizing 1/3 the horizontal resolution that today's consoles use. If you were scrolling the background @60FPS you were looking at just over four seconds to scroll the bg 'pixel by pixel'(that would be as smooth as you could have gotten). That means you had to 'clear' a bg area(complete change of bg scenery) within four seconds which certainly was not possible on all games of the era. You were reutilizing the same frames of animation most of the time and you were not scrolling the bg nearly as fast as you could most of the time. Yet you consider these titles to be running @60FPS despite them not displaying 60 distinct frames of animation?

Phat-

1) We can tell the difference between 60fps and 30fps games on NTSC.

I'm not speculating, and you using video feeds as examples wasn't good to bolster your argument

Walter R. G. Baker, who worked for the General Electric Company and served as chairman of the National Television System Committee (NTSC), played a major role in the resolution of conflicting views that enabled the television industry to reach this important stage of development. The NTSC standards that have lasted to the present day included a 525 line picture with interlaced scanning at 30 frames per second and a channel bandwidth of 6 MHz. The Federal Communications Commission (FCC) had approved the recommended standards and issued specific rules for operation in April 1941. Baker presided over the NTSC from July 1940 to March 1941 and also served as chairman of a second NTSC that formulated standards for color television in the early 1950's.

http://ieee.cincinnati.fuse.net/reiman/04_2001.html

Actually, they are slightly off as NTSC runs @29.97FPS

A TV display works by displaying the image from the top down to the bottom, displaying 576 lines for the PAL TV standard or 486 for NTSC. As it scans down the screen, it only updates every other line, so in effect it on does 263 (or 243) lines on each pass. When it scans down the screen again, it fills in the missing rows of the image with the next frame, this gives 50 fields per second for PAL and 60 for NTSC, or 25/30 whole frames per second. Because of the playback speed, this interlacing effect cannot be seen by the majority of viewers and is even less apparent on NTSC screens which play back the images even faster.

http://www.imashination.com/tv.html

NTSC video uses a frame rate of 30 (actually 29.97) fps which is identical to NTSC video material. Film material is usually converted from 24 to 30 fps by a '3/2 pulldown' whereby frames are repeated to convert the 24fps film to 30fps video. However this is not necessary for DVD since the player can carry out the frame rate conversion. Therefore the video can be stored on disc at 24fps and displayed by the player at 30 fps. The encoder embeds MPEG-2 repeat_first_field flags into the video stream to make the decoder perform 3/2 pulldown.

The result is that both PAL and NTSC versions of the same movie will comprise the same number of frames but as PAL frames are larger than NTSC frames they are likely to require more data rate for the same quality.

http://www.disctronics.co.uk/technology/dvdvideo/dvdvid_videnc.htm

A discontinuity exists between the NTSC video frames rate (29.97 Hz) and LTC timecode (30 Hz). This discontinuity exists due to an alteration of the original monochrome frame rate of 30 fps so that NTSC could carry a colour standard as well as be compatible with current (at the time) monochrome television sets. Drop Frame counting misses out frame numbers 0 and 1 in the first second of every minute except for every tenth minute. Drop frame timecode is at best an imprecise method of ensuring timecode and NTSC video track together.

http://www.broadcastpapers.com/sigdis/LeitchSPG03.htm

Also, if it were true that the same frame is redrawn twice, then imagine what the implications would have been for the poor analog engineers that created NTSC.

Redrawn isn't quite correct although neither is half drawn really(as 525 lines of res is not standard in terms of what your TV will disaplay). I think you are selling the engineers of the time a bit short if you don't think they could handle it Video is displayed at 30FPS(29.97) on NTSC TVs. The refresh rate is 60Hz.

 

[marconelly!]

without the proper amount of differing animations to utilize you are simply redisplaying the same image over and over.

It's quite simple really - if the console updates it's video output every 1/60 sec (and if the contents of the screen changes every 1/60 sec while the game is moving), you have a rate of 60FPS (in the case of interlaced TVs, it's 60 fields per second) The amount of character animation has nothing to do with it.

As it scans down the screen, it only updates every other line, so in effect it on does 263 (or 243) lines on each pass. When it scans down the screen again, it fills in the missing rows of the image with the next frame, this gives 50 fields per second for PAL and 60 for NTSC, or 25/30 whole frames per second. Because of the playback speed, this interlacing effect cannot be seen by the majority of viewers and is even less apparent on NTSC screens which play back the images even faster.

NEXT frame. The whole thing with interlaced TV is that 60FPS games never form the singular picture, like they do on progressive scanning TVs. At any given moment, picture on your screen is consited of two interlaced, consecutive frame buffer outputs. Only one field updates per 1/60 sec but it's always updated from the contents of the next frame buffer. Therefore, for all the motion purposes, you can say the output is 60FPS (fields/sec)

All that still doesn't change the fact that tons of games this gen (Xbox games mostly) support 480p progressive scan output AND run at 60FPS.

 

[Tagrineth]

VNZ

OK, so you don't remember Zelda(it actually did have fully scrolling screens, whenever you went up or down, left or right the entire screen would scroll over, this is the single best example I could think of in FPS terms for that era's games).

The reasons why I have been asking these questions are due to the amount of possible animations and what you are stating constitutes 60FPS. Super Mario Bros offered around eight frames of animation for each 'type' of Mario(small, large and fire powered) and yet you consider it to be a 60FPS game.

Mario has around 8 frames per state... so what? If the background scrolls smoothly (and it DOES), it's 60FPS, even if Mario himself is only changed at 20 or 30FPS.

Also to use one of your OWN quotes against you:

A TV display works by displaying the image from the top down to the bottom, displaying 576 lines for the PAL TV standard or 486 for NTSC. As it scans down the screen, it only updates every other line, so in effect it on does 263 (or 243) lines on each pass. When it scans down the screen again, it fills in the missing rows of the image with the next frame, this gives 50 fields per second for PAL and 60 for NTSC, or 25/30 whole frames per second. Because of the playback speed, this interlacing effect cannot be seen by the majority of viewers and is even less apparent on NTSC screens which play back the images even faster.

http://www.imashination.com/tv.html

It fills in the missing rows not by completing the previous frame, but by using the NEXT frame. So at 60FPS you're doing 60 half-frames per second, technically, but it's still SIXTY discrete fields per second.

 

[BenSkywalker]

Marconelly!-

It's quite simple really - if the contents of the screen changes evey 1/60 sec, you have a rate of 60FPS (in the case of interlaced TV, it's 60 Fields per second) The amount of character animation has nothing to do with it.

Reread what I wrote again. It has been hammered out pretty well that scrolling bgs are the big issue(as obviously Mario isn't animated at 60FPS) and even for those the majority of games weren't displaying differences @60FPS.

The whole thing with interlaced TV is that 60FPS games never form the singular picture, like they do on progressive scanning TVs do. At the any given moment, you have a picture that is consited of two interlaced, consecutive frame buffer outputs. Only one field updates per 1/60 sec but it's always updated from the contents of the next frame buffer. Therefore, for all the motion purposes, you can say the output is 60FPS (fields/sec)

And there aren't that many games that do that has been what I've been saying all along. Several of the games people bring up as 'rock solid 60FPS' have regular dips into the ~20FPS range(PGR is one that has been brought up in this discussion, EG3 also has dips in to the ~20FPS range despite being touted as a solid 60FPS).

In this discussion we have already seen mention of the framerate of video brought up as evidence that games run @60FPS. The overwhelming majority of people think 30FPS is perfectly smooth. You yourself mentioned that PGR had occasional dips in to the 30FPS area while it falls well south of that figure(which is actually extremely obvious in some instances, drive over a man hole cover with steam coming out of it, you'll be in the ~15FPS area in PGR). Most people over estimate framerate. Control input latency is the best way to judge framerate running on a non progressive scan TV. The fade rate of TVs combined with the inerlaced nature make visible distinctions very difficult in most gaming situations without side by side comparisons.

 

[BenSkywalker]

Tagrineth-

You posted while I was typing my last reply

If the background scrolls smoothly (and it DOES), it's 60FPS, even if Mario himself is only changed at 20 or 30FPS.

The issue is the pixel resolution versus the smooth scrolling. You can't get any smoother then pixel by pixel, which means that you have to be moving at a pace that would require the bg to scroll at a rate of complete transition every four seconds. If you aren't moving that fast then you are not displaying distinct frames per second. You must force the screen to update and move things at 60 pixels per second in order to hit 60FPS(looking at the bg as we have to use that due to Mario's limited animation).

It fills in the missing rows not by completing the previous frame, but by using the NEXT frame. So at 60FPS you're doing 60 half-frames per second, technically, but it's still SIXTY discrete fields per second.

A static(non moving) image represents a field. A static(non moving) completely black frame without any audio represents a field too

 

[marconelly!]

And there aren't that many games that do that has been what I've been saying all along. Several of the games people bring up as 'rock solid 60FPS' have regular dips into the ~20FPS range(PGR is one that has been brought up in this discussion, EG3 also has dips in to the ~20FPS range despite being touted as a solid 60FPS).

Well, I certainly don't care if the game is skipping frames every once in a blue moon, if it's obvisuly running at 60FPS 99.9% of the time.

The overwhelming majority of people think 30FPS is perfectly smooth.]

That's fine, but still doesn't change a fact that tons of games this gen run at 60FPS (and yeah, skip frames every now and then if you want to be anal...)

You yourself mentioned that PGR had occasional dips in to the 30FPS area while it falls well south of that figure(which is actually extremely obvious in some instances, drive over a man hole cover with steam coming out of it, you'll be in the ~15FPS area in PGR).

OK, OK, it slows down even below 30FPS, I know - however, it's running at 60FPS 99.9% of the time.

You never said that your definitiuon of 60FPS game is a game that never-ever skips frames. You seemed to be very straight claiming that DOA3 runs at 30 FPS, while that simply is not true, and that is one of the games that practically never skips frames.

 

[Thowllly]

It's getting hot in here...

The reason the old 2d consoles could scroll an entire screen smoothly at 60fps was because they used 'tilemaps'. To scroll the screen you only need to change the pointer into that tilemap, and when you had to update the tilemap you only had to move a few hundred bytes.

I actually wrote a scroller for the c64 that scrolls at 60fps just to demonstrate that it was very easy to do so, but when I was done the discussion had already moved on...

I will post the code anyway, even though it's very crappy

; Quick'n'dirty scroller by Thowllly
*=$c000
	sei
_start	lda #252
	sta $d020
_w	cmp $d012
	bne _w
	ldx #$0
	stx $d020
_l1	lda $0400,x
	sta $03d8,x
	inx
	bne _l1
_l2	lda $0500,x
	sta $04d8,x
	inx
	bne _l2
_l3	lda $0600,x
	sta $05d8,x
	inx
	bne _l3
	ldx #$18
_l4	lda $06e8,x
	sta $06c0,x
	inx
	bne _l4
_l5	lda $03d8,x
	sta $07c0,x
	inx
	txa
	cmp #$28
	bne _l5
	beq _start

Usage:
1. compile with favourite cross compiler
2. load with: load "filename",8,1
3. to start: sys 49152

Looks best on a real c64 (on an emulator the scrolling will not be synchronised to your screen refresh, on a real c64 it will)

Anyway, the code is horribly unoptimized (it could have been almost twice as fast), but still runs at 60 fps.

edit: new version of code, shows cpu usage in border.

 

[phat]

http://www.imashination.com/tv.html

NTSC video uses a frame rate of 30 (actually 29.97) fps which is identical to NTSC video material. Film material is usually converted from 24 to 30 fps by a '3/2 pulldown' whereby frames are repeated to convert the 24fps film to 30fps video. However this is not necessary for DVD since the player can carry out the frame rate conversion. Therefore the video can be stored on disc at 24fps and displayed by the player at 30 fps. The encoder embeds MPEG-2 repeat_first_field flags into the video stream to make the decoder perform 3/2 pulldown.

The result is that both PAL and NTSC versions of the same movie will comprise the same number of frames but as PAL frames are larger than NTSC frames they are likely to require more data rate for the same quality.

Also, if it were true that the same frame is redrawn twice, then imagine what the implications would have been for the poor analog engineers that created NTSC.

Redrawn isn't quite correct although neither is half drawn really(as 525 lines of res is not standard in terms of what your TV will disaplay). I think you are selling the engineers of the time a bit short if you don't think they could handle it Video is displayed at 30FPS(29.97) on NTSC TVs. The refresh rate is 60Hz.

Clearly you understand the text, Ben, but not the concepts. In all of your sources, nothing says that NTSC animation is 30fps. The "frames" that are being referred to are spatial frames. There are only 30 spatially complete frames per second in NTSC. But they are formed from two fields each, and there is no requirement that the two fields come from the same frame of animation, and usually they do not, with the only common examples being film material and video games that aren't 60fps.

The bit you quoted about 3/2 pull-down for film material actually also goes to show that the two fields of an NTSC spatially complete frame need not come from the same frame of animation. With 3/2 pulldown, given two consecutive film frames A and B, frame A is put on fields 1, 2, and 3, and frame B is put on fields 4 and 5. Think about what that implies if you believe that NTSC fields are neatly paired to form frames of animation. In your view, given NTSC fields 1, 2, 3, and 4, fields 1 and 2 form one frame of animation and fields 3 and 4 form the next. But in the film 3/2 pulldown example, fields 1 and 2 form film frame A, but fields 3 and 4 form a mix of film frames A and B, and field 5 will combine with the next to form a mix of film frames B and C. The neat pairing you think exists doesn't really exist at all.

Anyway, what it all boils down to is NTSC is 60 fields per second, and each field is displayed 1/60th of a second one after another, and each field can be from a different frame of animation to achieve 60Hz animation. Two consecutive fields are required to form one spatially complete frame, so while there are only 30 spatially complete frames per second, people shouldn't confuse this to mean that there are only 30 animation frames per second.

Phat.

 

[marconelly!]

Looks best on a real c64 (on an emulator the scrolling will not be synchronised to your screen refresh, on a real c64 it will)

Not if you use CCS64 emu that can force you rmonitor to 100Hz and display every C64 frame twice (PAL C64 emulation, of course)

It looks sooooo smooth, skips frame every 10 seconds or so, maybe, but so close to real C64 smoothy goodness )

 

[Ratty]

I had almost this exact same discussion with Ben about 6 months ago.

http://www.beyond3d.com/forum/viewtopic.php?t=1025&postdays=0&postorder=asc&start=80

It went on for ages! Where were you all then?

 

[VNZ]

Haha, this thread turned too funny today. I won't pursue this "debate" any longer.

BenSkywalker shifted arguments from perfectly stupid ones concerning cartridge bandwidth and resolution, to the downright silly pixels scrolled per frame and amount of animation frames per sprite. Doh! Why would a person even care about framerate, let alone debate its definition, when he clearly isn't within reach of grasping the basic concept.

 

[DemoCoder]

Tile scrolling will run less than 60fps on consoles/computers like the C64 if the CPU lacks the leftover CPU power to copy the entire contents of the screen and color buffers (C64 you had to scroll 2 buffers) and at the same time, update all the game logic.

A typical example of this happening is when the tiles themselves are animated (explosions, animated turrets, parallax scrolling, etc) and/or you have large number of multi-sprite effects (displaying more than 8 sprites per screen by using raster tricks) OR you have some very complex music (using the "4th" noise channel)

A typical high-end C64 game would max out every CPU cycle and some animations would have to be deferred to being updated every N screens (e.g. some bitmap effects, like ROL/ROR scrollers). If you took such a game and moved it from NTSC to PAL or back, you would encounter serious problems and typically have to drop out something.


So just because the smooth-scroll register can scroll the whole screen with a single instruction (usually by 8 pixels), doesn't mean you can update the state of all the animations on the screen at 60fps.


That said, the vast majority of console and C64 games strived for 60fps. However, not all of them made it. Even the NeoGeo which had oodles of hardware to accelerate sprites and backgrounds slowed down on many games when excessive numbers of junk was on the screen.

 

[BenSkywalker]

VNZ-

BenSkywalker shifted arguments from perfectly stupid ones concerning cartridge bandwidth and resolution, to the downright silly pixels scrolled per frame and amount of animation frames per sprite.

They are all the same thing. If the carts had the bandwith(or the console had enough RAM) and memory capacity to hold and display the amount of distinct animation per frame then they could display 60 actual frames per second.

You have continued to bring up the examples of scrolling backgrounds as an example of 60FPS while you need to scroll the BG at a fast rate in order for it to make any difference. In order for that to be incorrect you have to state that these systems worked with sub pixel accuracy.

Doh! Why would a person even care about framerate, let alone debate its definition, when he clearly isn't within reach of grasping the basic concept.

It's your line of thought. Using your own basis most games are not running @60FPS. I brought up the resolution for a reason, and the subsequent questions were trying to figure out your line of thought on how you define these games to run @60FPS. Based on your reasoning, most games don't.

Phat-

The neat pairing you think exists doesn't really exist at all.

Huh? 'Neat pairing' wouldn't be possible on any interlaced display unless you never updated the scene. You are going to have half a frame offset half the time when running at 30FPS anyway.

Anyway, what it all boils down to is NTSC is 60 fields per second, and each field is displayed 1/60th of a second one after another, and each field can be from a different frame of animation to achieve 60Hz animation.

I've not disagreed with any of that. I've not argued that it isn't possible(obviously as some things do run at 60FPS). Out of all the video feeds I've ever captured from cable, non of them have been running @60FPS(FZeroX is btw, it isn't HW limitations).

 

[randycat99]

Out of all the video feeds I've ever captured from cable, non of them have been running @60FPS...

Is it possible that your capturing equipment inherently applies a de-interlacing filter/processing stage, preventing you from seeing the true difference in sequential fields when sampling from cable, as you review your frame sequence?

 

[BenSkywalker]

Is it possible that your capturing equipment inherently applies a de-interlacing filter/processing stage, preventing you from seeing the true difference in sequential fields when sampling from cable, as you review your frame sequence?

It shows the difference in FZX. I did think of that possibility

 

[marconelly!]

Still, how does all that change the fact that great many games this gen run at 60FPS (interlaced) and many even support 480p?

That was how this whole discussion started, if I remember. Ben saying that only few games run at 60FPS...

 

[VNZ]

BenSkywalker:

You have continued to bring up the examples of scrolling backgrounds as an example of 60FPS while you need to scroll the BG at a fast rate in order for it to make any difference. In order for that to be incorrect you have to state that these systems worked with sub pixel accuracy.

Actually scrolling 1 pixel per frame is very slow, even at the 8/16-bitters lower resolutions of around 256*224 to 320*256. Slow-paced games like SMW are generally moving faster than that. Not that it really matters, the thing is that the systems and the code running on them are capable of updating all scrolling backgrounds and sprite positions every frame if necessary. When that is accomplished the game runs in 60fps and will be perceived as smooth, regardless if there happens to be no movement at all if you're just idling. Most of the time there's some object (ie sprite) moving around that updates every frame anyway.. A perfect example is 2D fighters. Nowadays they've gone mad ofcourse, scrolling around like crazy etc, but even if the background was static and the sprites only updated its image 1/3 of the frames, they would count as moving at 60fps if the sprite positions updated every single frame - according to everyone sans your definition of framerate.

Again, I can't believe you're still mentioning the amount of sprite animation. There's lots of C64 games with NO sprite or BG animation that runs in 50/60 (most of them were PAL) fps. And for example the Metal Slug series, arguably the most well-animated games created runs at 30fps despite having more animation frames than an average collection of NES and SNES games.

 

[Nappe1]

a bit of knowledge of makers of NFS -series:

The Need For Speed:
- 3DO: EA Canada (good old Distinctive Software Inc get bought by EA and became EA Canada.)
- PC: EA Canada

The Need For Speed SE / The Need For Speed (PSX, Saturn versions)
- PC: EA Canada & EA Seattle
- PSX: EA Seattle (just port)
- Saturn: EA Seattle (just port)

Need For Speed II:
- PC EA Canada & EA Seattle
- PSX: ???

Need For Speed II SE:
- PC: EA Seattle

Need For Speed III: (Hot Pursuit)
- PC: ???
- PSX: ???

Need For Speed: Motor City (started)
- PC: EA Canada

Need For Speed IV: (High Stakes)
- PC: EA Seattle
- PSX: EA Canada (??)

Need For Speed: Motor City almost finished.

Motor City Online (EA's worst idea of all time turning almost ready NFS: MC to just onlin based MCO and moving the project to Seattle from Vancouver.)
- PC: EA Seattle (starting to work with net code for game based on NFS MC.)

Need For Speed V: (Porsche Unleashed)
- PC: started by EA Seattle, shifted and most work done by EA Canada.
- PSX: small european software developer did this, but it failed badly.

Motor City online released 1.5 years late and only for American markets.

Need For Speed 6: (Hot Pursuit 2) (project starts)
- PS2: Black Box Entertainment (QA EA Canada.)
- PC / XBox, GC: EA Seattle

EA Buys Black Box Entertainment:
-> Old EA Canada becames as EA Canada Vancouver.
-> Black Box gets name of EA Canada Phoenix.

EA almost completely sacks everyone at EA Seattle.

Need For Speed 6: (HP2) (released versions.)
- PS2: EA Canada Phoenix.
- PC: started by EA Seattle, finished by EA Canada Phoenix.
- GC, XBOX: ???

IMO: after taking a looooong look of PC version files, it seems to be pretty obious that EA Seattle just failed to deliver something they should have. this caused a small panic on EA officers and that they pulled at least PC version out from Seattle and quickly transferred to guys at Phoenix. After a quick look on game's state and available time before deadline they pulled a classic stunt. They just took everything from PC version that was ready and easily usable and ported rest from the PS2 version. The result is awful. There's a lot of menus that give much more things to tune on graphics options, there's better replay control screens, the list of things that are there but aren't implemented on exe file is huge.

Maybe this and the real f*ck up with turning NFS MC to MCO was enough. EA decided at last do something.