4 ms·
Meeting the frame deadline is about scene complexity, not code. Keeping scene complexity under the limit is nearly impossible in large, rich game worlds. On sma
by Daniel_Newby 13y ago
Meeting the frame deadline is about scene complexity, not code. Keeping scene complexity under the limit is nearly impossible in large, rich game worlds. On small console games it is done by putting in walls and strictly limiting the visual budget, but that would remove much of the appeal of a game like Skyrim.
- TheZenPsycho 13y agoSkyrim exists on at least one console. Isn't it possible to make a game with a similar level of richness of skyrim within a budget? can hardware help with enforcing the budget? I intuit that there must be some kind of trademark you can make to get under the deadline- like for instance, perhaps, progressive rendering of a frame, so that if the frame doesn't finish in time you get a half resolution frame, instead of just the top half of a frame?
- jblow 13y agoSee my Rocket comment above. But in reply to this specific comment I will drop you a hint (this hint is still just a small piece of the whole situation): 3D rendering is so deeply pipelined that it is difficult or even impossible for the program to know if a frame render is going to finish on time. It takes a long time to get information about completed results back from a GPU; on PCs you almost certainly can't get that info during the same frame you are rendering, unless you are rendering tremendously slowly. In order to make an estimate about whether the frame is going to be done in time, you would have to guess. Okay, then, so now you decided to stop rendering this frame, what do you do? Leave a giant hole in the scene? Turn off the postprocess? Draw low-detail versions of some things (hint: still very slow)? Your program does not even really know for sure which pieces of the scene are fast to render and which are slow. It does not know if specific textures are going to be paged out of VRAM by the time you get to a specific mesh, or not. etc etc
- TheZenPsycho 13y agoSo you are saying it's completely impossible to start out just rendering the lowest complexity scene and progressively refine it, so that if you stop at any point in time, you still have something reasonable to show for it? And that GPU manufacterers have been working on making steady frame rates more and more difficult instead of easier?
- asdfs 13y agoWhat you are suggesting could lead to horrific flicker. If you render one frame in low complexity follow by another frame at medium complexity, followed by another frame in low complexity... etc., you'd get flashing as (for example) shadows appeared and disappeared repeatedly.
- TheZenPsycho 13y agoWell, wouldn't that depend on what you mean by "low complexity" ? That's what we mean nowadays, but could you not design a version of "low complexity" that reduces the appearance of flicker?
- asdfs 13y agoThe problem is that if the low quality render differs in any appreciable way from the high quality one, there will be flickering. So the low quality renders have to be extremely similar to the high quality ones, in which case why not just use the low-quality ones all the time? Though come to think of it, there is one example that almost does what you describe. Dynamic resolution scaling has some artifacts, but is being used in some games (and is notably used in Dead Rising 3). Though one has to decide before the frame is rendered what resolution to use, so you still get frames that take longer than 16.7ms or whatever your target is. One could do something similar with render quality, but it has the same drawback that you have to decide beforehand what quality you want to use. One would also have to ramp up and down the quality slowly, which is difficult as the complexity of a given scene can vary wildly over the space of a single second. It also wouldn't help with spikes in rendering time.