Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

529 Good

About dougbinks

  • Rank

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. dougbinks

    C++ as a scripting language

      Runtime Compiled C++ is also used in http://kythera.ai/ which is in StarCitizen and other titles such as Umbra https://umbragame.com/   Unsurprisingly since I'm the author of RCC++ it's also in my game http://www.avoyd.com   Lots of edits to this, as by heck is the editor great at losing what you type if it can't parse it.
  2.   UE4's UI is written using their own UI called Slate running on top of thier rendering layer - so a port of the rendering engine leads to a port of the editor UI, which is handy.   A common approach is to use web technology, either through an embedded simple web server in your game or by embedding Webkit such as the Chromium Embedded Framework (other alternatives can likely be found through a search on these forums).
  3.   Yes, it's tricky. Eric Lengyel's transvoxel algorithm is one of the best for marching cubes (http://www.terathon.com/voxels/), and Miguel Cepero's Voxel Farm seams are pretty decent http://procworld.blogspot.fr/2013/07/emancipation-from-skirt.html, though I'm not sure what technique he uses as he has dual contour voxels. I use simple skirts for now with the skirt normal adjusted to minimize transition contrast, though I've not had time to cater for certain edge cases such as the one you spotted.   The main issue with shadow maps for me is the lack of light propagation in occluded volumes, such as caves. Otherwise they're great.
  4. Funnily enough I've been thinking about the lighting system in my own work recently, and there's some similarities as I'm using an Octree as well.   You can probably do decent per-vertex lighting the Minecraft way by subdividing the large voxels. In my own game I subdivide large nodes to the smallest voxel size for nearby regions, and use higher nodes of the branch of the Octree for level of detail in the distance. Hopefully you can see the LODs working in this (debug rendering) video. Using this approach has the advantage of fast vertex generation without seams, using skirts between LOD regions. So if you use this approach and have slow moving  or stationary lights you should be able to do fairly decent lighting which gives you some global illumination like properties.   I'd disagree that deferred rendering doesn't scale well - indeed that's it's purpose. Culling can be done via tiles in DX11+ (or equivalent in OpenGL), see Andrew Lauritzen's work, or you can use the stencil buffers. I've been considering using the voxel octree itself to do CPU side culling, but haven't looked into it yet.   I'm also considering voxel cone tracing or light propagation volumes, doing the work CPU side using the octree and then uploading the results asynchronously to either a light-map or 3D texture cascade. I've no results or even back of the napkin calculations of feasibility yet, but  will try to blog the results when I do.
  5. 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.]
  6. 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]...
  7. 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.
  8. 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.
  9. 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).
  10. 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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!