Jump to content
  • Advertisement

dougbinks

Member
  • Content count

    67
  • Joined

  • Last visited

Everything posted by dougbinks

  1. dougbinks

    Dynamic Resolution Rendering

    Only just spotted this was put up here - the author link, though having my name, wasn't posted here by me as the original article was from some work I did whilst at Intel (many thanks @Gaiiden for putting it up). I know the last post here was some years back, but I thought I'd answer some of the questions since I have a few minutes spare!   @Doug Rogers (a) - there's pretty much no discussion in literature about this technique, and when made the presentation at GDC I was unaware of any product using dynamic (versus static) resolution scaling. I hope there's still value in having an open discussion and data + sample code even if the idea isn't new. Only the art came from Project Offset, though I didn't have time (or the desire in a demo) to implement the rendering techniques needed to show off their wonderful artwork as well as possible. Our in house sample team artist did a great job in converting things for a demo though!   @Doug Rogers (b) -  The sample uses both the CPU measure of frame time and a GPU measure of rendered frame time to calculate what the current frame time is. If you use just the CPU rate then you can't accurately measure how much under the refresh time you are, and if you use the GPU rate you can miss out on some CPU side pipeline issues. I also remove cases where the CPU frame time spikes as this can be caused by non rendering stalls. The control seems stable, but you could add hysteresis bands if needed easily. I think an improvement might be to use set bands of resolution scales with the resolution lerping between them to keep things stable and smooth.   @Doug Rogers (c) - Agreed, understanding your rendering pipeline and art limitations is important. With many modern games using deferred lighting and complex post processing pipelines, frame times tend to scale with pixel count over a wide range. If your frame times don't depend on resolution, dynamic resolution makes it easy to increase the resolution to the maximum (or even go to super-sampling).   @Hodgman - It probably would have been better in frame times ;) However whilst inter frame times need to be measured as times so as to be easily added up, the overall frame rate is sometimes more easy to measure against refresh rates. Mostly I just needed folk to see that there's fairly good scaling for a reasonably realistic scene in terms of polycount.   @Lewis_1985 - the code is single threaded, and tested on a dual core MacBook Air system of the same generation CPU & GPU but under much lower power constraints gives better scaling, and has the nice side effect of allowing the resolution to scale as the GPU power is lowered by the system when the CPU starts eating into it's budget (which I tested by running a second high CPU bound process alongside, but don't have the data any more sadly).   @InvalidPointer - I was also concerned about multiresolution temporal data, and thought I'd have to fix the resolution in pair sets resulting in some flickering when it changes. It turned out to just work fairly well. As for load factors, I'd love to have a decent PS time measure on a cross platform basis, but failing that I'd agree that multiple measures are the way forwards. I'm no longer with Intel, but if I get around to trying it I'd like to measure indicators prior to rendering so as to be able to predict the resolution to set. Vertex count, particle & deferred light numbers (perhaps with a simple area measure) and move/turn rates if using motion blur could all help.   Oops. Long post on old topic, apologies!   [FYI if you tried out the demo when this article came out, you might want to take a look at the updated code which has a few improvements.]
  2. dougbinks

    Runtime Compiled C++

    Yes - that does sound like a great approach, since you can write new code for visual objects on the fly, then play with them. I was wondering about using this with Google's [url="http://code.google.com/p/blockly/?redir=1"]Blocky[/url]...
  3. dougbinks

    Runtime Compiled C++

    [quote name='evolutional' timestamp='1339950528'] And even then, the JIT systems implemented in script libraries nowadays will challenge that assertion. [/quote] An important consideration for console developers is that data can't be executed due to content protection measures, so JIT systems can't be used. I know of several developers bitten by script performance on consoles, indeed Havok Script was developed in part to address this issue by creating a higher performance script interpreter for consoles.
  4. dougbinks

    Runtime Compiled C++

    @evolutional - take a look at the source code for one of the runtime objects or headers. Basically in the current prototype you derive from a base class, declare the class in a C++ file with a macro, and optionally declare headers as being runtime editable. There's a video of the later just gone up on the site. @Saruman - this isn't C++ scripting, but runtime compiling and loading of C++. That I know of this is the first public example of this approach, though some developers have hot loaded dll's for similar functionality. The C4 example is actually not altering C++, but using a data driven GUI node graph which is interpretted to provide scripting functionality, akin to CryENGINE's Flowgraph or Unreal's Kismet. I agree with you on giving designers better tools than scripting to create gameplay, with visual tools being a great way to do that.
  5. dougbinks

    Runtime Compiled C++

    We only support windows at the moment, with Visual Studio as the IDE. However only a few changes are needed to add a new compiler, probably less work than is needed to make changes to the codebase to support this style of approach (changes are required to make the code hot swappable).
  6. dougbinks

    Runtime Compiled C++

    Glad you liked our project. Our primary goal is to make it possible to use C++ for rapid iteration for C++ developers, however we also believe the approach can be extended to other use cases avoiding the issues mentioned by Aardvajk. The compilation tool we currently use in the prototype is the Visual Studio compiler, for which a free version exists. Developers don't even need to use the Visual Studio IDE - we have an example where people can write code in the prototype console. Future versions could ship with an open source compiler such as LLVM + Clang, avoiding the need for any installed tools. The actual language itself is an issue which can be dealt with in a few approaches:[list] [*]via cross-compilation, see[url="https://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/"] HipHop for PHP[/url] as to why that might be a good approach [*]through a DSL which is based around C++ (see Games Programming Gems 8, DSLs in Game Engines) [*]through a graphical tool which outputs C++ but allows the designers to work with symbols [/list] There will always be cases where scripting is a preferred approach, but we hope to offer a viable alternative. We hope to write more about why this is needed in future.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!