Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


greenvertex

Member Since 31 Jul 2012
Offline Last Active Nov 21 2012 07:12 PM

Topics I've Started

Call for Design Comments

08 November 2012 - 11:58 AM

I'd really like some opinions on the following idea:

struct DXBundle {
  ID3D11Device* device;
  ID3D11DeviceContext* context;
  D3D_FEATURE_LEVEL* featureLevel;
 
  DXBundle() {
    UINT createFlags = 0;
#if _DEBUG
    createFlags |= D3D11_CREATE_DEVICE_DEBUG;
#endif
    return D3D11CreateDevice(
	  0, D3D_DRIVER_TYPE_HARDWARE, 0, createFlags,
	  0, 0, D3D11_SDK_VERSION, device, featureLevel, context);
  }
  ~DXBundle() {
	  if(context) {
	    context->ClearState();
	    context->Flush();
	    context->Release();
	  }
	  if(device) {
	    device->Release();
	  }
  }
};

There's a couple places I could see using this, the above example is a simple one that appears fairly convenient. Automatic construction and release at the cost of a dot operator seems like a fair trade. Anyone know of any reasons to avoid creating little "construction wrappers" like this?

Note: I've left out copy and copy assign intentionally for readability, that and the jury's still out on how I want to handle them in this particular instance...

__stdcall Class Constructor

08 October 2012 - 06:49 PM

I've seen forms of this around here and there and I don't get it:

class Test {
public:
__stdcall Test()
{
  int x = 0;
  ++x;
}
};
int main(int argc, char** argv)
{
Test t;
return 0;
}

Why is the constructor declared to use the stdcall convention as opposed to thiscall? It doesn't actually seem to affect the assembly in debug mode (the following appears to be thiscall convention):

	12:  Test t;
0108143E  lea		 ecx,[t]
01081441  call		Test::Test (010810E1h)
	13:
	14:  return 0;
01081446  xor		 eax,eax

And Microsoft seems to confirm:

When you use the __stdcall keyword on a non-static member function, such as a constructor, the compiler will use the thiscall calling convention."


This was only tested in VS2012 so maybe this stdcall->thiscall behavior is implementation specific?

Function pointer return type overloading

24 September 2012 - 03:53 PM

I have a base class for a messaging system (pause, unpause, key state change, pointer state change, etc.) that does not provide "handler" functionality. By this I mean that it does not provide functionality to translate, say, Win32 messages received via a window procedure into internal message types. I am currently working on extending this class with a Win32 specific implementation (basically simply writing the window procedure atop the messaging class) but am running into the following problem:

Given the base class declaration of:

virtual inline void* getHandler() const = 0;

I can't declare an override that returns a function pointer:

typedef LRESULT(CALLBACK WinProc)(HWND, UINT, WPARAM, LPARAM);
virtual inline WinProc* getHandler() const;

Because the overridden return type "... is not identical to nor covariant with the return type "void *"..."

I've been considering two alternatives:

1) Functor return type for both:

typedef LRESULT(CALLBACK WinProc)(HWND, UINT, WPARAM, LPARAM);
struct BaseFunctor {};
virtual inline BaseFunctor* getHandler() const = 0;
struct Win32Functor : public BaseFunctor {
  WinProc* handler;
  LRESULT CALLBACK operator()(HWND window, UINT msg, WPARAM wp, LPARAM lp) {
	handler(window, msg, wp, lp);
  }
};
virtual inline Win32Functor* getHandler() const;


2) Fun with reinterpret_cast:

virtual inline void* getHandler() const
{
  return reinterpret_cast<void*>(&handler);
}
//Later...
typedef LRESULT(CALLBACK WinProc)(HWND, UINT, WPARAM, LPARAM);
WinProc* wp = reinterpret_cast<WinProc*>(messenger->getHandler());
wp(window, msg, wp, lp);

My question is threefold: Is there a way to resolve this more clearly? Which of the above two (or the TBD three) methods is generally better, or does it make any difference? Is there away to resolve it with function pointers as in the original code?

Linkage Woes

28 August 2012 - 05:39 PM

So the situation is that I have a library for a model format I'm working on and am having a problem importing extensions to it into another project. I export a set of three functions as follows:

namespace bof {
namespace dx {
__declspec(dllexport) D3D11_INPUT_ELEMENT_DESC* get_input_desc(
   const bof::Model& model,
   const std::string& name,
   size_t* stride = 0);
};
};

And attempt to use them in the target project:

descriptors = bof::dx::get_input_desc(model, "Cube", &vertex_stride);

However I get the following linker errors associated with that particular call:

2>BOFCube.obj : error LNK2019: unresolved external symbol "struct D3D11_INPUT_ELEMENT_DESC * __cdecl bof::dx::get_input_desc(class bof::Model const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int *)" (?get_input_desc@dx@bof@@YAPAUD3D11_INPUT_ELEMENT_DESC@@ABVModel@2@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PAI@Z) referenced in function "public: __thiscall BOFCube::BOFCube(struct ID3D11Device * const,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0BOFCube@@QAE@QAUID3D11Device@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)


There are six of them so I only picked one for brevity (three referencing calls from the 'model' type's definition file and three from 'bof::dx'). This is all using Visual Studio 2012 RC and I'm wondering if there's a project setting I've missed? I have yet a third project that makes reference to this library successfully to build a little command line tool for writing these models. As far as I can tell the two projects (the one successfully building with the library and the one that's not) are set up the same way.

Anyone have any ideas?

To DirectInput or Not to DirectInput

09 August 2012 - 12:14 PM

So creating a game I hope to be able to compile and run as both Win32 and .Net 4.5, I'm considering using DirectInput to handle all user input as it'll basically be unchanged across both. However, from Microsoft:

The use of DirectInput for keyboard and mouse input is not recommended.


Could anyone elucidate why this might be the recommendation? Are there serious drawbacks to using DirectInput for keyboard/mouse (I'll only be targeting PCs and possibly Windows 8 tablets). What makes the message loop/window procedure in Win32 or the events of .Net 4.5 more suitable?

PARTNERS