Alucardx23
Regular
I guess, but I think that if used well, it could be a good technique to reduce framerate slowdown awareness.
Display planes use
- Thread starter Alucardx23
- Start date
I guess, but I think that if used well, it could be a good technique to reduce framerate slowdown awareness.
There are at least some minor bandwidth savings doing it in the display controller like this instead of doing it in the GPU. The former needs three reads, while the latter needs four reads and one write. Or the cost of one resolve. You also get slightly higher intermediate precision this way, assuming the GPU solution is dealing with 32bpp frame buffers, and you get upscaling which may need more than just TMU sampling to reproduce on the GPU.
Mobile SoCs have had exactly this sort of hardware forever now. Or at least TI has had it since OMAP3 and probably earlier.
Mobile SoCs have had exactly this sort of hardware forever now. Or at least TI has had it since OMAP3 and probably earlier.
You're not really answering the question here.Alucardx23 said:
Do you make your cross-hair move around the screen rather than rotating the camera? Do you re-think the rendering of "slow-plane" to render a much larger field-of-view (requiring multiple passes) to accommodate for faster scrolling of the cross-hair plane?
Devil is in the details - decoupling update-FPS of two things is the easiest part of the problem to solve (and some of these solutions wouldn't even work properly with just 2d-plane merging).
Anyway - "accuracy" in online-shooters is all smoke&mirrors - this would just add another layer of illusion - although I agree it's one that can improve player-comfort.
Last edited by a moderator:
In the 360, there's silicon that scale the game's output to make the display output (screen resolution). So what does this mean? It means all non-game UI must output to the same resolution as the game. While this is fine for game console. It makes non-gaming UI falling back to the game resolution. By extension, this means the 720 now untie game's resolution to system output resolution (system UI such as chat message, achievements popup, notifications, etc). So while you're playing a game at 720p60, the Coke-Cola ad is in Full HD. 
Nothing special here...just make life of some people easier...Coke's artist can't complain that their ads downscaled to 720p is making the fine lines in the logo not acceptable...
Nothing special here...just make life of some people easier...Coke's artist can't complain that their ads downscaled to 720p is making the fine lines in the logo not acceptable...
Silent_Buddha
Legend
So with that example in mind, let’s look at this image from Call of Duty. How much better will the gameplay experience be when you are trying to point to someone with the crosshair running at 60 frames solid, versus the way the game runs now with an unstable framerate.
How is it going to be better if, for example, that person you are aiming at is only being updated at 30 FPS while your crosshairs are being moved and updated at 60 FPS? you still wouldn't be able to accurately line up the shot. It would just introduce even more of a disconnect between the player and the game.
In other words, even if the crosshairs are moving at 60 FPS. You are still reacting and aiming at things based on their 30 FPS positions and movements.
In the 360, there's silicon that scale the game's output to make the display output (screen resolution). So what does this mean? It means all non-game UI must output to the same resolution as the game. While this is fine for game console. It makes non-gaming UI falling back to the game resolution. By extension, this means the 720 now untie game's resolution to system output resolution (system UI such as chat message, achievements popup, notifications, etc). So while you're playing a game at 720p60, the Coke-Cola ad is in Full HD.
Actually, in theory since the HUD display plane will likely be at native 1080p (just like the UI display plane), that means that even if the game is rendered at 720p, it'll be upscaled to 1080p before being composited with the UI display plane.
So, technically, they could claim that all games are running at 1080p.
Either way, if no one told anyone what resolution the game was running at, most people will think that the above game actually was being rendered at 1080p because the UI is usually what gives away whether a game is running at a non-native resolution for your average gamer that doesn't bother going onto gaming forums. Assuming they even really cared what resolution the game was running at, or even had a clue how to tell.
Regards,
SB
So, technically, they could claim that all games are running at 1080p.
Either way, if no one told anyone what resolution the game was running at, most people will think that the above game actually was being rendered at 1080p because the UI is usually what gives away whether a game is running at a non-native resolution for your average gamer that doesn't bother going onto gaming forums. Assuming they even really cared what resolution the game was running at, or even had a clue how to tell.
Regards,
SB
Yeah, but that's not the point of it. I don't think this feature was designed to trick anybody. It was to keep the system UI standard. And they have only a couple of option. Forcing all devs to output 1080p or providing an infrastructure that will allow them to hook in and take control. Personally, I think this is a nice touch.
So with that example in mind, let’s look at this image from Call of Duty. How much better will the gameplay experience be when you are trying to point to someone with the crosshair running at 60 frames solid, versus the way the game runs now with an unstable framerate.
in this case with more than 50% occluded, we can have a double framerate or a better graphics
what are you talking about? just write here a single game that uses tiled based deferred rendering
a single game
Hardware early Z reject has been a feature of video cards since at least the Radeon 7500.
What are YOU talking about? This display planes feature does not grant durango TBDR, don't be silly...
A game could simply adjust the area into which it draws its graphics to match a rectangle sized after the scope. Most games with scope views probably do this already.
And half the view area for the game.
Betanumerical
Veteran
Not to mention a wildly varying framerates / graphics.
Making the experience inconsistent which is exactly what you don't want.
from what we know durango IS A TBDR MACHINE, DS, DME's and eSRAM are here for this
just write a single game name that does this and adjust dynamically the size of framebuffer when occluded area occours
I'm waiting
maybe you ignore that there're already games that change resolution/framebuffer on the fly, inconsistent what?
Last edited by a moderator:
Betanumerical
Veteran
Yes but they dont double the graphics or frame rate randomly and often, which is what your suggesting, it would be a very jaring.
And i personally would hate it. It would be very obvious too.
You raised this in another thread where it was already explained it's nothing the display planes enable. IF Durango is a TBDR, or the developers write a TBDR, then they could reduce rendering (when you have the scope up covering half the screen, but then performance will crash when you drop the scope), but that's a whole other topic.
Even that wouldn't help much, modern graphics cards contain scissor rects and trivially reject any polygons outside them in the geometry stage which is where a TBDR would.
I'm not sure I'd bother in this case because you already get a massive performance win from the reduced FOV.
I didn't know that. Although reading up on them briefly, sounds like they are an inclusive area, and not exclusive. The idea that the geometry under a UI element can be skipped if occluded doesn't seem a fit for scissor rects, which sound like they are effectively a rectangular window region. A tile-based renderer that's cutting the screen into portions can elect to reject portions under a UI element like a radar. For the above scope example, scissor rects would suffice.
Similar threads
