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!


Member Since 24 Mar 2001
Offline Last Active Today, 12:53 AM

Posts I've Made

In Topic: Multithreading problem when reloading a D3D model on user input

19 July 2015 - 02:44 PM

Lets get started here:

  1. Why aren't you using std::thread?
  2. The function you're passing to CreateThread MUST be __stdcall (WINAPI). Microsoft goes to a lot of effort to detect when people do bad things like pass in cdecl or similar calling conventions. All that work is overhead you inherit when you do it wrong.
  3. Having a function called "createThreadFunction" that takes a VOID POINTER as a function parameter is just flat out wrong. Don't do this.
  4. bool, and std::atomic<bool> are not mutexes. You can use std::mutex if you need mutex like behavior.
  5. While std::atomic<bool> does enforce a memory barrier, it does not prevent multiple pieces of the same code from running at once.

In Topic: How do game designers communicate?

13 July 2015 - 02:25 PM

How do they communicate?

With Flowdock of course.

In Topic: D3DXCreateTextureFromFileInMemoryEx in a thread failing

13 July 2015 - 08:26 AM

Did you create your device with D3DCREATE_MULTITHREADED specified?

In Topic: Is Haxe used much professionally?

12 July 2015 - 10:38 PM

Here are some questions I've started using before bothering to evaluating the use of any more languages:

1. How much of the AST is available to tools. I'm thinking: Auto-complete tools that don't have to do source analysis, tools for profiling, etc.

2. What does the development environment look like: What kind of immediate debugging tools are available for both stand alone development AND embedded development. Debugging tools that only work on the stand alone code are, frankly, useless.

3. Why should I use this? What problems does it solve that existing mature scripting languages don't solve well. Is it's tool environment that much better? Does it have a significant performance advantage?

4. What does it look like from the embedded perspective. How hard is it to integrate? Are we talking C like bindings? Boost python? How hard is it to control it, how much control do I have over things like the libraries it includes by default, memory management, etc?

In Topic: [SlimDX] Information on the history of SlimDX

11 July 2015 - 02:31 PM

I ultimately solved the problem through the aforementioned object table, a tool that in retrospect I still have extremely mixed feelings about. In the vast majority of cases, it actually does its job quietly and magnificently, as well as enabling some very useful debugging techniques. But in the bad cases, it gets really problematic. As Josh noted, we had not planned on using that design again if we were going to take another crack at rearchitecting the whole library.

The object table was both a great solution, and the worst possible one.

For the vast majority of the simple use cases for DirectX objects, the object table solved the issue trivially and cleanly, and made lifetime management in C# enjoyable. On the other hand, when things got a bit less trivial it very quickly devolved to a point where you had to write your own lifetime management code in C#, simply because we were not exposing AddRef/Release semantics in C#. Ultimately, I think we should have gone for a two fold approach of having an object manager and the ability to expose AddRef/Release semantics with it being a choice of one or the other. Non-trivial to implement, sure, but much less annoying in those non-trivial use cases.