::DirectX::HowTo:: know if the debug layer is activated

Just this once won’t hurt, I’m not talking about openGL or iPhone today.

I found the DirectX10/11 control panel really awful to set the debug layer. Sometimes on some computers, for any unknown reason it has no effect either if you set it to “forced on“. Moreover, it could be hard to verify if the path added for the application you want to debug is correct, etc…

Here is a little but useful trick I’m using to know inside my application if the debug layer is really currently activated or not (could be used also to know if the user overrides your device creation layer setting via the control panel) :

bool IsDebugLayerActivated(const ID3D10Device& a_rDevice)
{
ID3D10InfoQueue* pInfoQueue;
a_rDevice.QueryInterface(__uuidof(ID3D10InfoQueue), (void **)&pInfoQueue);
bool bActivated =  (pInfoQueue != NULL);

if (bActivated)
{
pInfoQueue->Release();
}
return bActivated;
}

Advertisements

::Mac/iPhone:: Trying XCode4

If you are an iOS developer you probably know that the brand new build of Apple XCode has been released on march and is available for free with SDK 4.3. New features are quite sexy, especially the single window as I was totally disappointed and stressed with XCode3 and its 23 dialogs across the screen and beyond…

The first 30 minutes were troublesome and I was lost again like when I ported my engine to Mac the first time on XCode3.
It was hard to find all the things I often use, I had to remap again my keyboard shortcuts to more friendly ones to me, find how to correctly use the new LLVM 2.0 and the new “schemes” concepts in my existing projects, etc… but after this little accommodation time, I’m really seduced.
However, I’m not a heavy user of XCode ([a little bit of my life story]I like to code cross-platforms things on my windows laptop, comfortably installed on the sofa, then try things on device using the desktop mac[/end]) so the move was not a big pain. I don’t have a lot of practice and tricks on this IDE. I guess this is probably different for an old Mac-maniac.

To finish, just a big inconvenience for me: SVN and Git were really nicely integrated (it seems), but perforce isn’t supported yet… Apple, if you hear me.


::’Z’ Engine:: concept overview (I)

What I call ‘Z’ engine is my own game engine I’m implementing from scratch. As a personal project it is deserved to be in continuous evolution an refactoring, but here is a shot description (and non-exhaustive) of my key features :

  • Why ‘Z’: I really don’t know why, but if you have an idea…
  • Mobile platforms in mind: My first idea was to implement an engine for mobile platforms (handheld consoles, smartphones, …) especially iPhone. So the performances is a big topic.
  • Simplicity: Within my job, I worked with many 3D engine, libraries and production tools. From famous ones like Criterion’s Renderware or Sony’s PhyreEngine, to studio’s in-house. Generally, whatever they are rigorously structured or not, they all have a common characteristic: complexity. Of course I don’t pretend to be a better skilled nor better organized programmer and I’m totally aware of all an engine has to managed including some production constraints within a large team. But here is the key: it’s my own engine, not deserved to be used by someone else coder nor artist, not associated to a complex level editor, etc…
    So I can assume the user (me) know the engine and know what to do with to prevent errors, and it is implemented as a big sequencer. Each “sequence” could manage lot of things including low-level calls or other high-level sequences (and so be quite a sequencer itself). It’s a kind of hard-coded world -but with bounds- the oposite view of any regular team producted engine which needs to be robust.
  • Cross-platform at no-cost: As said before, my engine is first designed to allow me to play easily with iPhone SDK features. So the engine uses openGL API (I like directX but…) without a lot of abstraction within a high-level encapsulation (simplicty, you know).
    It could also be used on desktop Windows PC and Mac OS. The platform specific system stuff is kept to minimum, with no vitual-calls as I’m sure one and only one implementation is used at any time. I also use cross-platform libraries when possible (OpenAL, etc…)
    I’m not excluding possibility to later use other 3D API like the one in XNA framework (I’d like to play with Windows phone development too, or with consoles one day), but currently I like to implement my “sequences” draw without any astraction.
    The engine is implemented in C++. Objective-C is used only for specific iOS stuff (Cocoa, File loading, etc..) not because I dislike it, just because I love C++ and know him well for many years.

That’s all that currently come to min mind. Maybe I will give other fatures or detail this ones in another post.