Digital Foundry Article Technical Discussion Archive [2014]

[Cyan]

Motion was decoupled from animation in the 2D sprite days, commonly characters would move at a fixed step and the animation would play at a lower rate, often holding different frames for different periods.

There was also a lot less input latency because the screen wasn't double buffered, you updated the sprites and scroll positions in the vblank.

I wrote a lot of genesis titles and they all ran at 60Hz, it was uncommon for that not to be the case. I used to hate supporting NTSC, because it meant you got 3.3ms less frame time and probably more importantly less time in the vblank.
Some of the early arcade games code are works of art.

Things have changed a lot back then it was about programming, now it's more about software engineering.

The first paragraph might explain why Super Nintendo (or similar consoles) emulators let you skip frames sometimes, although I don't know whether that affect the gameplay or not.

As for games running at 30 fps in the past, one of the uncommon ones, this article says that Strider 2 was 30 fps. I've never played a Strider game, but I've seen it on arcades and old consoles, but I am very surprised that is the case.

http://www.eurogamer.net/articles/digitalfoundry-2014-strider-next-gen-face-off

 

[steveOrino]

The original strider was an Capcom CPS game using a Motorola 6800, all sprites.

Strider 2 was made for the Sony ZN-2 ( a slightly beefed up PlayStation 1) 3D backgrounds and 2D sprites. I am not sure if the Arcade version was 60fps but the home version (PS1) was 30.

 

[Cyan]

The original strider was an Capcom CPS game using a Motorola 6800, all sprites.

Strider 2 was made for the Sony ZN-2 ( a slightly beefed up PlayStation 1) 3D backgrounds and 2D sprites. I am not sure if the Arcade version was 60fps but the home version (PS1) was.

Ah, okay, that explains it. I haven't had the opportunity to play it on the PS1, as Xbox -the original- was my first console, I was on PC back then.

Now that I think of it, I wonder if Digital Foundry staff could measure the framerate of 2D games.

 

[taisui]

Ah, okay, that explains it. I haven't had the opportunity to play it on the PS1, as Xbox -the original- was my first console, I was on PC back then.

Now that I think of it, I wonder if Digital Foundry staff could measure the framerate of 2D games.

If you can record at 60 fps, and you see if it changes every frame, or every other...? Typically [japanese] arcade games are 60fps.

 

[Cyan]

If you can record at 60 fps, and you see if it changes every frame, or every other...? Typically [japanese] arcade games are 60fps.

Sure, but not matter what you record, if the animation is decoupled from the framerate Digital Foundry equipment could fail.

Excuse me if I am wrong, but it's not the same finding out that the TV is outputting 60 Hz than counting the actual frames the games is running at when the game is 2D and the animation and framerate are decoupled.

 

[tuna]

If nothing is moving you can't measure the frame rate. Duh....

 

[Shifty Geezer]

Sure, but not matter what you record, if the animation is decoupled from the framerate Digital Foundry equipment could fail.

Excuse me if I am wrong, but it's not the same finding out that the TV is outputting 60 Hz than counting the actual frames the games is running at when the game is 2D and the animation and framerate are decoupled.

For 2D games, you either render updates every frame or multiple thereof. It's simple a case of counting how many unique frames a second. (this assumes it's v-synced and not tearing).

 

[taisui]

Sure, but not matter what you record, if the animation is decoupled from the framerate Digital Foundry equipment could fail.

Excuse me if I am wrong, but it's not the same finding out that the TV is outputting 60 Hz than counting the actual frames the games is running at when the game is 2D and the animation and framerate are decoupled.

The sprites don't have to animate, they can be moved without switching frame on the sprites, if that make sense.

 

[Cyan]

For 2D games, you either render updates every frame or multiple thereof. It's simple a case of counting how many unique frames a second. (this assumes it's v-synced and not tearing).

Thanks Shifty, you are awesome as usual. Always a thing to learn, like when you explained to me time ago why 2D games have a different FOV when switching resolutions, but 3D games don't.

Still I don't know what you mean by updates. (fps, Hz?) I am more into tuna's line of thinking, if the sprite doesn't move -even if it does, it is decoupled-, how can you measure the framerate?

taisui's post is more in line with what you say, but still how you can move what's not moving?

That has to be said, I don't understand it. When DF measures framerates, things are moving on the screen.

 

[Shifty Geezer]

That has to be said, I don't understand it. When DF measures framerates, things are moving on the screen.

Don't think of it as things moving - think of it as pixels changing. Whether those pixels change because a sprite has moved position or is showing a different frame of animation, makes no odds. The rendering frequency, the FPS or Hz (same thing!), is how many times the framebuffer is updated a second. If there are things moving on screen, it'll be how many unique frames per second. If the screen remains completely static, there's no way to count the framerate, but it doesn't really matter either as you'd be looking at a static image.

 

[taisui]

taisui's post is more in line with what you say, but still how you can move what's not moving?

well, imagine you have 4 pictures of a human walking.
every frame, you can move the image to the right a little.
every 2 frames, you switch onto the next picture.
This gives the sense of walking, but not every frame has a unique walking image.

You don't have to "animate" every frame, the actual movement can be done by moving that sprite only.

 

[Rurouni]

@cyan
As long as you can capture unique frames, then it's moving. Even static background can be used for counting as long as the character/screen is moving (usually to the right). In 2D games, the objects animation doesn't have to match the frame update.
I remember that some 2D capcom fighters converted to the consoles (PS1 era), they have to reduce the character animation to fit the small console memory.

 

[HTupolev]

In 2D games, the objects animation doesn't have to match the frame update.

Strictly speaking, that's not specific to 2D games, either.

 

[shredenvain]

The WiiU has more 1080p@60 games than the XB1 does! So in that measure it's PS4>WiiU>XB1.

But I guess in real terms it's still the little fish in this pond.

I dont understand how resolution and frame rate are the main factors that determine whats next gen or not. The Wii U may very well have more 1080p 60 fps games than the Xbox one but that doesnt really mean anything. Take one title as an example. Bf 4 on the X1 is 720p 60fps. Do you think the Wii U can run it at the exact same detail and picture quality settings as the X1? Im not sure it could even run the exact same version of that game at 480p 30fps.
The point is that resolution should not be the only thing that determines if a title is next gen.

 

[chris1515]

I dont understand how resolution and frame rate are the main factors that determine whats next gen or not. The Wii U may very well have more 1080p 60 fps games than the Xbox one but that doesnt really mean anything. Take one title as an example. Bf 4 on the X1 is 720p 60fps. Do you think the Wii U can run it at the exact same detail and picture quality settings as the X1? Im not sure it could even run the exact same version of that game at 480p 30fps.
The point is that resolution should not be the only thing that determines if a title is next gen.

+1, quality of pixel, number of polygon, complexity of shader Ryse is only 900p but better visually than all the Wii U title at 1080p 60 fps...

 

[pMax]

I dont understand how resolution and frame rate are the main factors that determine whats next gen or not.

...it just implies same pixel quality, I suppose.

 

[steveOrino]

I dont understand how resolution and frame rate are the main factors that determine whats next gen or not.

Because Next Gen is a meaningless term. Its all relative.

I am primarily play games on a PC, so 1000+ vert pixels/60+ fps with high quality IQ has been the norm for me for over a decade. Candy Crush Saga could be considered Next Gen depending on who you talk to.

 

[Rangers]

Candy Crush Saga could be considered Next Gen depending on who you talk to.

Somebody who came through a time warp from the days of the Atari 2600, certainly!

 

[liolio]

introducing the Brix, powered by a core i4770R
http://www.eurogamer.net/articles/digitalfoundry-2014-gigabyte-brix-pro-review.
Still costly the lower end still cost 529$ and uses a core i5 4570R, RAM and HDD and OS not included.
The HD4770R, 4670R and 4570R are only avilable to OEM, I'm interested to see how Intel will grow that line of products.
Looking at the GPU performances I would think that actually they could reach a lower price by going with core i3, for the sake of not lowering the value of they higher CPU they could cut some unnecessary functionalities like they do with their pentium and celeron line.
It could get really interesting if MSFT actually releases in the future a low overhead API that makes Atom based SoC an option.

 

[DavidGraham]

DF comment about Xb1 being match by a 100 Pounds GPU card even powered by a i3 or FX6300 makes me wonder about the CPU performance overhead ..

Maxwell did this with lower memory bandwidth and without access to "closer to the metal" layers of coding. It just gives you an indication for how the Jaguar CPU is handicapping both XO and PS4.

Anyhow, I would like to know about the kind of equipment and methodology DF uses to count frames, anyone have a link? that would be greatly appreciated.