Digital Foundry Article Technical Discussion [2018]

If DF analysis never found over 1080p and they have videos of the footage they analysed how is it a mistake on DFs part that the game never dynamically scaled higher than 1080p?

In that situation the game clearly was 1080p. Since DF are professional about their work, very early on when VGTech pointed out it is dynamic and some of the oddities about their dynamic scaling, then DF went back, verified for themselves and made updates to their written article and video writeup. The DF update was made long before the devs went on a rampage claiming fake news and spouting their own wrong message.

The devs claims seem to be more false than the original finding that in some play situations the game produced 1080p results. The dev claims were 4K@60fps with dynamic scaling from 50% to 90%. Were they simply talking per axis? Because 1080p is 25% of 4k (50% of X and 50% of Y) and 1080p@45 fps is even less than 25% of 4K@60fps overall.

Hopefully the devs can learn to ignore the gamers comments on Twitter and how to professionally act to build good will.

 

As per John in the resetera thread

The developers claimed dynamic and they went with what they assumed was standard load changing. If it's built into the track to lower and increase resolution as required, that's not dynamic in the way the industry has come to know the term. It's on DF to check these statements, but they are also looking at the 4K@60 marketing language which it clearly is not. They were looking for areas where they thought it would have been 4K, but didn't realize that developers are allegedly statically controlling resolution to sections of the track.

I don't see anything embarrassing here for DF, perhaps a small adjustment to process to avoid this again, but it fully appears as though they tested this as they would any other game.

 

Ohhhhhh. So it's specific to track sections and not track location or track position as in being in 1st or 3rd or 10th or last. So it's like the straight away is tied to resolution X1*Y1 while the left curve is tied to resolution X2*Y2.

Is this a fair statement then?
The game has a set of static resolutions (1080p to 1944p) that switch between based on the area. If Section A is 1080p it will always be 1080p. If section B is 1944p it will always be 1944p.

If so, that's not the way we've seen dynamic resolution used before.

 

My opinion is if the developer had cared enough that their game wasn't working better on more capable hardware we wouldn't be here talking about the low quality upgrade. Mistake is clearly on them.

Tommy McClain

 

Because it strongly suggests DF used mere seconds of capture for their analysis article. Here is the take of somebody who did their job properly, VGTech

Here we have some actual analysis, where somebody has spent time looking into the dynamic scaling and identifying causes in fluctuations.

I don't about the game or what the developer has said, promised or delivered here, I am only concerned with the job DF does. This is the DF thread and we rely on them to do a thorough job.

Part of parcel of any analysis is to begin without preconceived ideas. Redout is doing something different with scaled resolution which I think makes likely make sense for a racing game with a fixed track. If the tracks are designed in such a way that, competitors aside, certain areas are more demanding on the rendering pipeline by virtue of geometrical complexity or effects, they having certain sections of the track dictate a median target resolution makes perfect sense.

DF half-arsed this one. VGTech did not.

And that is my point. The number of updates and corrections, which are not the result of game patches, feel too high. It does not feel like they are getting better. I wonder if they are more concerned with getting articles out quickly than them being comprehensive.

 

I saw someone mention that the base Xbox One game can hit as low as 540p. I'm not sure if that's true or not. If so, then doubling to 1080p isn't a bad upgrade, if it wasn't for the fact they didn't seem to improve the textures or other image quality we've seen in other enhancement treatments.

 

Based on what I understand of this game's setup I don't know if I'd consider it to be dynamic, more like switching between static predefined setups regardless of what's happening on the screen all based on the players location within the track -- Section A will always be 1080p and Section B will always be 1944p.

 

If it's not static, it is by definition dynamic, but I take your point.

I'm speculating on the implementation here; maybe the buffer does scale frame to frame reactively but there are 'suggested' target resolutions at various points of the track so when you approach a particularly complicated area, it begins to lower the resolution pre-emptively to minimise a sudden drop in resolution or frame rate. That would make perfect sense if your dynamic scaling resolution needed a little help.

A distribution table of the various individual resolutions, and the percentage they occur in any given capture, would be helpful but I can't see DF publishing that even though it's something their capture solution should be able to produce automatically.

 

I was thinking the same, but I can't expect any place to take that amount of time. It would be harsh to even sample 1 frame every 6 seconds on a track that takes 1 minute to traverse, not to mention how many you'd have to look at if the tracks are longer and take 5 to 6 minutes.

But boy if we could get to that point it would make the analysis part more interesting and we could break things down to percentile distributions etc.

Maybe someone could create some Pixel Counting Image Analysis AI to do the job for us meager humans.

 

Is there not already an algorithm for this? Is feels like one of the less challenging determinations to make on a bunch of pixels.

Incidentally, that's not me offering to write one

 

My obvious concern with calling it dynamic resolution, is that we have come to an understanding that dynamic resolution by design lowers resolution to ensure that frame rate is unaffected. It is a load balancing tool in which is by design supposed to maximize GPU through put.

Statically assigning areas to increase or decrease resolution in areas based seems at absolute best, the worst case implementation of dynamic resolution; You’re not maximizing through put when you should be and your losing frame rate when you shouldn’t be.

 

Because that's the implementation we've mostly seen - as far as we are aware. And there's no evidence that Redout isn't doing conventional dynamic scaling. Again, speculation.

Again, speculatively, it might be the best case implementation because you don't know what performance would be like with a different predictive/reactive algorithm. Dynamic resolution scaling is a tricky problem to solve and its complexity can depend on the rest of your pipeline. I've never seen any developer suggests they believe their dynamic scaling resolution to be optimal. There are likely many instances where the game is outputting a lower resolution than it otherwise could have if it had some additional data not limited to previous frame production timings.

I've never before heard somebody argue more data is bad!

 

We need a FLOPs Capacitor powered by Mr. Apu Fusion. If their game hits 88 milliseconds per frame you're gonna see some serious shit.

 

This Redout shitstorm is a mess.

DF were sloppy and this no-doubt led to a shitstorm that the developers didn't deserve. But there's no doubting DF did find the frame rates and resolution they stated - and calling it "fake news" and threatening legal action is a mistaken, emotion driven response that won't help them. Oh, and 1920 x 1080 is not 50% of 4K. Stop it. Stop saying that. That's "fake".

The really sad thing is that the game looks good and it wasn't on my radar untill this mess. But now it is, and I'm downloading the demo (60 fps PC, of course) as I type this.

 

Trawling through the ever-growing resetera there and couple of things stick out. Whoever is posting Dark1x is reluctant to comment on any analysis they didn't do (several comments along the lines of "I didn't do that analysis") and also posted here, in response to a query about methodology, this:

So it appears there isn't a standardised approach, it depends on who does the analysis. It's also clear that the various DF conspiracy theorists (pro-Sony, anti-Sony, pro-Microsoft, anti-Microsoft) factions are well represented!

Surely that's good? And better still if you like it.

 

Based on the current speculation... The per track section settings would be fine if they were merely hints as to what the initial target should start off as, but there should be a way for the engine to adjust to higher or lower settings. IE: have fine grain control system on top of the course grain control system.

From a time and resource perspective, the course grain control might not be a bad for a quick first pass. The trouble then becomes how soon after can they release a second or third pass with refinements. Though how long did the first pass take and how long would the second pass take?

From a game engine perspective, what engine is being used for this game?

 

One that is not optimized enough for a 6TFlop GPU.

Tommy McClain

 

We need a tool to make stats about resolution: mean, median, 95th and 99th percentile etc.

But first we need a thread for that.

 

Some games will need to have those statistics based on level. It was pointed out that the recent Sonic game was patched to have different resource usage based on the level stage, where some busier levels have lower res while less hectic levels have higher res.

Them once you have the stats per level, you need to weight those based on how often and for what duration of time the user is in that level, which means another set of statistics mean, median, 95th and 99th percenticle for the various level of gamers. Like if a gamer rushes through the main story a level could be less than 2% of the game but if they're going for all Achievements/Trophies that same level could be 25% of the game.

 

PPM (pixels per minute). It’s a stat that’s independent of the developer methods but can also be used to complement them.