Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Boreal Games

Member Since 24 Oct 2011
Online Last Active Today, 02:21 PM

Topics I've Started

Low-level platform-agnostic video subsystem design: Resource management

22 February 2015 - 10:11 AM

Something I've been stuck on for a while is the part of the low-level video subsystem that relates to creating/deleting resources and handling memory transfers between the CPU and GPU.  There are lots of resources for the submission, batching and drawing itself but never anything about how those buffers, textures, etc. got there in the first place or how the API for resource management is designed.  Note that I'm not talking about loading and caching resource files from disk.  This is concerned with the low-level aspects of memory and resource management across processors.


One idea I had was a layered API loosely based off of D3D11, where you separate the memory itself (buffer, texture) from how it's going to be used (view).  This way, for example, you can allocate a texture and use it as both a render target and a sampler target.  Of course, this also brings up the issue of making sure access is "exclusive", i.e. you can't sample from it and render to it at the same time.  Another issue I'm interested in is making the API thread-safe.  While this is relatively trivial to do with D3D11 thanks to the Device/Context separation, with OpenGL it's more complicated since you have to deal with context sharing and currency.


Basically I'm just looking for some advice, ideas, open-source code to look at, or anything else that can help me see how this stuff has been taken care of before.

Designing an efficient multithreading architecture

10 December 2013 - 03:04 PM

I'm designing an engine for my big 3D game project, and I want to make sure everything is very scalable to processors with many cores, without having more threads than necessary spawned at a time.


This is the architecture I'm considering right now in terms of different threads:

  • 1 scheduling thread
    • Runs the main loop
    • Spawns work and I/O jobs
    • Sends draw/compute calls to the GPU
  • 1 I/O thread
    • Blocks on calls to fread and fwrite
    • Spawns work jobs for decoding
  • 1 sound thread
    • Runs from within OpenAL or satisfies SDL audio callbacks
  • n worker threads, where n = ncores - 3
    • Run serial work jobs (embarassingly parallel jobs will be run on the GPU)

While this makes sense to me for processors like Intel i7's or AMD FX's which generally have more than 4 (logical) cores, for a 4-core processor like an i5, there is only one worker thread.

Should the scheduling thread also be able to run work jobs?  If so, is it safe enough to have any thread be able to send draw/compute calls to the GPU (using OpenGL 4)?

Omnipresent DAG scene graph - thoughts

21 March 2013 - 07:45 PM

I've been thinking about ways to integrate features that traditionally require a flat list into a hierarchical scene graph structure, and improving upon the tree structure a scene graph uses.  My solution was to replace the simple tree with a directed acyclic graph, which allows nodes to have more than one entry point.  I also realized that generalizing the scene graph and allowing for more than one entry point per node would allow constructs for spatial partitioning and integration with a physics engine, among others.


The main inspiration for this came when I was trying to find a way for an object to be part of more than one partition, for example, when a character is standing in the doorway of a building.  It's simple when you can add another entry into the node, so both the "outside" and "building" partitions point to the character, and it can be rendered if either partition is visible.


Generalizing the graph would allow for more flexibility.  Typically, every node in a scene graph is associated with a transformation, but this is clunky when physics is put into the mix.  Say a character is holding a ball.  The "ball" node would be a child of the "hand bone" node.  When the character throws the ball, the "ball" node must be moved and its transform changed to keep the same world position.  It gets even worse when the character has to pick the ball up again.  My solution is to implement transformation nodes as physics constraints.  A typical transformation would be a weld joint.  Bones in skeletons could be implemented as ball and socket joints.  This works well with my engine where animations are all procedural and depend on the physics engine.


Why stop there?  The whole high-level rendering process could be implemented in the graph.  You could have a shader node, a texture node, and then a mesh node.  Because each node can have more than one entry point, you could create multiple passes by forking into two material groups and then joining at a mesh.  Instancing could be done automatically for rendering paths identical except for transformation.  Nodes could also be general-purpose programming constructs, like a condition (if condition, choose this path, else, choose another path), a random selector, and so on, like nodes in a behaviour tree.


What are your thoughts on this?  I want to get some feedback before I hunker down and code this.

Code::Blocks 10.05 crashes when starting a new project

15 June 2012 - 08:10 AM

I've been using Visual Studio for a little while but I want to go cross-platform. I've just done a fresh install of Code::Blocks 10.05 (with MinGW) from the binary. I open it up and whenever I go to start a new project (whether from the file menu or the start page) it crashes. I saw on the CB forums that it would output the error log to the codeblocks.RPT file, so here's that:

Error occured on Friday, June 15, 2012 at 11:06:10.
C:\Program Files (x86)\CodeBlocks\codeblocks.exe caused a Privileged Instruction at location 01df58a1.
eax=0028f497 ebx=001a0e6a ecx=001a0e6a edx=00000000 esi=0028fb84 edi=0028f488
eip=01df58a1 esp=0028fadc ebp=0028fb08 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
6CD1BC4C C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_cb.dll:6CD1BC4CDwarf Error: found dwarf version '50548', this reader only handles version 2 information. _ZN11wxEventLoop17PreProcessMessageEP6tagMSG
6CD1BCF9 C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_cb.dll:6CD1BCF9 _ZN11wxEventLoop14ProcessMessageEP6tagMSG
6CD1B9E6 C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_cb.dll:6CD1B9E6 _ZN11wxEventLoop8DispatchEv
6CDD4B27 C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_cb.dll:6CDD4B27 _ZN17wxEventLoopManual3RunEv
6CDABF29 C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_cb.dll:6CDABF29 _ZN9wxAppBase8MainLoopEv
00405A86 C:\Program Files (x86)\CodeBlocks\codeblocks.exe:00405A86
6CC7BC3E C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_cb.dll:6CC7BC3EDwarf Error: found dwarf version '50469', this reader only handles version 2 information. _Z12wxInitializeiPPw
6CCE543F C:\Program Files (x86)\CodeBlocks\wxmsw28u_gcc_cb.dll:6CCE543F _Z7wxEntryP11HINSTANCE__S0_Pci
00401D38 C:\Program Files (x86)\CodeBlocks\codeblocks.exe:00401D38
00467BA6 C:\Program Files (x86)\CodeBlocks\codeblocks.exe:00467BA6
004010B6 C:\Program Files (x86)\CodeBlocks\codeblocks.exe:004010B6
00401128 C:\Program Files (x86)\CodeBlocks\codeblocks.exe:00401128
7700339A C:\windows\syswow64\kernel32.dll:7700339A BaseThreadInitThunk
77EA9EF2 C:\windows\SysWOW64\ntdll.dll:77EA9EF2 RtlInitializeExceptionChain
77EA9EC5 C:\windows\SysWOW64\ntdll.dll:77EA9EC5 RtlInitializeExceptionChain

Has anyone ever had this problem before and/or does anybody know how to fix it?

Efficient coding in C#

07 June 2012 - 06:25 PM

I've been working on a game engine using C# and SlimDX for about a week now. I only really worked with one entity in the world for a while, until today. I then realized that my engine is incredibly inefficient and really needs a rewrite. I am fine with this.

The most likely reason for my poor performance is my heavy reliance on lots and lots of .Net classes, especially dictionaries and lists, to manage everything. I usually end up creating a ton every step, and that's a no-go. So when I'm writing my new engine, how can I stop myself from making too many unnecessary objects? If it really comes down to trying to thwart the garbage collector, I'm up for switching over to C++ and doing manual memory management.