Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Sep 2012
Offline Last Active Oct 01 2012 01:52 PM

Posts I've Made

In Topic: Platform-agnostic renderer

08 September 2012 - 11:30 AM

To be implemented in the D3D11-specific renderer implementation and its OpenGL counterparts. :-)

The engine already contains a robust and "battle-proven" sub-library I call the "HAI" (Hardware Abstraction Interface). It can pull all of the important information about a machine's graphics hardware from DXGI or OpenGL, and it also finds (among other things) the amount of CPU cores, total physical memory (RAM), HDD space, logical drives, etc. My D3D11 renderer implementation will of course use that to allocate rendering tasks to dynamically-generated threads, the number of which is selected to be optimal for the CPU speed and the amount of cores.

Wow, i think this was a lot of work and many ifdefs. (-;

I thnik allways the solution is what fit for your needs and if you have selfmade code you understand you get even more productive
enstead of learning lots of diffrent tools and Version changes.


In Topic: Compile Time. How to reduce it?

08 September 2012 - 10:49 AM

I have seen some larger Projects where a lot of developers was involved. A smart but effective way is splitting the whole Great Project in smaller Statically Lib Projects. (*.lib) wich can single compiled. Then you only have generic Base EXE Stub where you should link against with and wich is the Host of your Lib Project.For example: If you compile
tthe Subproject (for exampe physics.lib or render.lib) you can simply build run/debug it within seconds. This is why you only have to build you Lib Project.
Of cause. If you compile all you Projects, this will takes a long time if your Project is relly hugh, but working with small subprojects dramaticall brings
down you effective working cycle recompiletime. It is also recommended in large projects to have an Buildserver wich periodically builds the whole project drivven
by a Taskmanager or Cronjob on an diffrent machine.At the End you have a Single Exe build from various subprojects. This works like a charm for Exe related
things. For other, more generic Suprojects it might be better to build some DLL (or on mac Linux SO - Shared Objects) to avaoid completly monolitic structures
and be more modular.

If you use VC++ make sure you use WIN32_LEAN_AND_MEAN as preprocessor makro and if possible Precompiled Headers, this saves also much compiletime
and make realy sure to use Include Guards to avaoid multiple inclusion of the same Headers. This can also cause strange Linker Errors wich can you cause extreme headache to solve.If you use an GCC Compiler try the compiler cache. At debugging you can use the reply feature for modify values, reply and got ahead, so you are not forced to recompile every 30 sec. for debugging purposes only.


In Topic: Platform-agnostic renderer

08 September 2012 - 07:43 AM


Here's how I'm currently doing things, thanks to some of the brilliant suggestions I've recieved here from our community's most brilliant and senior members... Posted Image

Yeah, there are some amazing peoples out there Posted Image


[source lang="csharp"] public class RenderOp { public string[] CmdString { get; set; } public MeshData Mesh { get; set; } public Material Material { get; set; } }; public class RenderOpBatch { // Pseudo-implementation not shown to save space }; public abstract class Renderer { RenderOpBatch currentBatch; Queue<RenderOpBatch> RenderBatches; public virtual void StartRenderBatch() { currentBatch = new RenderOpBatch(); RenderBatches.Enqueue(currentBatch); } public virtual void QueueOp(RenderOp op) { currentBatch.Add(op); } public abstract void FlushAllBatches(); // blah, blah, blah... you get the idea [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] };[/source]

I think this pretty straith forward, But i think you can change your rederque with task based sheduling like (i recommended
the free OpenSource Version of Intel Thread building blocks). Then your Renderque can spread over multiple cores.
In TBB you have Namespaces and OOP Classes instead of dealing with native Posix or Winthreads so it is much
more easier - and - it is crossplatform and works with the Intel/Visual C/C++ and GNU GCC Compiler.


In Topic: OpenAL on Mac?

07 September 2012 - 03:59 PM

Try http://kcat.stranges...l.html#download

OpenAL Soft. Its not properitary like OpenAL now and can be build with GCC on Linux/Unix and 32 and 64-Bit MacOSX 10.5/10.6./10.7/.10.8
Bit Shared object and on Windows as DLL. Its comes with a CMake buildsystem, so you also can build it easly on a non posix ready platform
like Win32 with Visual C/C++. Its tiny and robust like freeglut and i like a much. You have 3D-Audio and Realtime Sound.


In Topic: Multithreading in games

07 September 2012 - 03:48 PM

Not if you use cuda or opencl. In this scope any CPU/GPU is only a core. You are not forced in most cases to transfer data from memory to GPU Memory and vice versa.You can write an opencl kernel wich can access the videoram directly without waiting of the CPU Cores or RAM. Anyway: If the Future is no longer Multicore and now Genereal Puporse Cores for anything, i a few years 16 cores per CPU is Standad like Quadcore is today standard. GPU's are todays 500 upto 2000 and counting. We have to deal with thousands of core in the Future and some code wich is not limited or using only one core is future ready.