Sorry your browser is not supported!

I wasn't planning on making a post about this until I had gotten it a bit more polished, but I have some other things to tend to during the coming weeks and I don't know how much time I'll get to spend on this until that is over with so I thought I might as well put it out there for some feedback.

Features
Pure DirectX 11 engine written from scratch.
Backwards compatible with DX10 hardware*.
Supports vertex, hull, domain, geometry and pixel shader version 5.
Supports DirectCompute with compute shader versions 4 and 5.
Can import a great many 2D and 3D formats including .X, .DAE, .OBJ, .B3D and .DDS, .BMP, .PNG, .JPG, .GIF.
Supports importing and playing back skeletal animations.
Attempts to correlate to the standard DBPro library with concepts such as objects, limbs, vertex data etc.
Comprehensive 3D math function set which include returning temporary vectors / matrices from functions performing mathematical functions, thus allowing expressions like this to be written:
Uses standardized naming; set for setter-type functions, get for getter-style functions (except for boolean getters which use is), create for creating resources, delete for releasing resources and so on.
Supports writing to up to 8 different render targets from the same camera render pass - perfect for deferred shading.
(* Only available with DX11 capable hardware, on DX10 hardware there is a limitation of at most one output resource at any one time; this holds for render targets as well as writable resources used by compute shaders).
Supports up to 16 textures per limb.
Supports texture arrays for even more textures per limb / object.
Supports cubemaps.
Supports single draw-call instancing.
Supports sprite shaders.
Supports direct drawing to the screen of simple shapes, text, images and sprites (akin to DBPro's TEXT, PASTE IMAGE / PASTE SPRITE, BOX, CIRCLE, LINE commands).
Supports buffered textual input (reminiscent an extended version of DBPro's ENTRY$ command).
Supports changing resolutions (and to and from fullscreen mode) during runtim. There is no need to reload any media after changing display mode, unlike with standard DBPro.
Supports multi-pass shading.
Supports "null meshes", which leave it to the GPU to construct actual geometry - useful for things like screen quads for post processing effects and particles.
Comes with nine (and counting) example projects as well as relatively comprehensive dbp-esque help files (it must have taken me about a week to write each of those function references...)
* Update: over 740 help documents as of 2016-01-04!

Rough to-do list (in no particular order)
Add support for hull, domain and geometry shaders. [DONE]
Add support for DirectCompute / compute shaders. [DONE]
Implement animation system. [DONE]
Improve error handling system for the DBPro version. [Ongoing undertaking]
Refactor the current, rather naïve culling approach. Improved as of build 0.4.7.1
Interface with DirectSound.
Interface with PhysX.


Known issues
(Let me know if you find any and I'll add them here and look into them when I get the chance).
Several wrapper functions do not validate resource existence prior to manipulating them, causing crashes instead of clean failures.
The dx11 get mouseMoveX/Y/Z functions have a very coarse granularity to their returned values, making movement using those seem "laggy".




Installation
The installation is the same simple drag and drop + restart your editor as it is for any plugin. Download the attached archive and extract its contents in your main DBPro installation folder. This will give you the plugin, a keywords file, all 590 help files (yes, I can't get over writing those! ) and eight example projects that demonstrate things ranging from how to get a program running using the plugin to implementing a GPU-driven particle system and using realtime hardware tessellation.
If you have a previous version of the plugin installed you should just overwrite all conflicting files with the new ones as there usually are changes to multiple files between releases.


Usage guide
I suggest looking at the supplied example projects to see how everything works together. The spinning cube example explains each function it uses in great detail, the instancing example documents a little less but demonstrates doing some more advanced things, including custom shaders. There is also a well commented animation example as well as a new, less verbose spinning cube implementation that use default resources (the original created all required resources itself making it appear a bit off-putting to the new user). Once you get your bearing, the function names should be relatively self-explanatory as to what they do and function lists for 20 categories can be found in the help files. There is also a decent correspondence to the standard DBPro library functions - if you install this plugin you can probably guess what commands like dx11 create object cube, dx11 move camera and dx11 sync does.
There are some big differences from standard DBPro you have to be aware of though;
first out are vertex layouts. These essentially correspond to the Flexible Vertex Formats (FVFs), but you can put anything in them now (although it is probably not a good idea to store a 64x64 pixel image with each vertex in your terrain). You have to create a vertex layout that describes the format of the vertex buffer used by your meshes before you can create any meshes / limbs / objects. When importing a mesh (or creating one of the built-in primitives) all vertexdata that is recognized thanks to the semantics defined in your vertex layout will be loaded into its vertex buffer, any data that exists in the mesh file but isn't in your vertex layout will be stripped out. If there is semantics in your layout that doesn't exist in the file, they will be zero-initialized. It is also important to note that a vertex layout should correspond directly to the input struct you use in the vertex shader you're going to render said mesh using.
As of version 0.2.0.0, vertex layouts can now be created from FVF flags if preferred. The default vertex layout corresponds to FVF 338, which is the default format used by standard DBPro asd well.
The effects framework has been deprecated. This is what lets you define techniques in your .fx shader files, set sampler states and color write enable flags etc. in them in DBPro. Because it has since been dropped by Microsoft, I didn't include it and instead there is the shader technique type resource which is intended to correspond to those. A shader technique maintains a vertex and a pixel shader that are used in concert to render an object (any other shader stages supported in the future will also integrate into the shader techniques, except compute shaders). It also has an associated blend state, a rasterizer state and up to 8 sampler states (one per texture stage used by your shaders). Together, these make the shader technique resource cabable to do all that was possible to do from within a .fx file in DBPro, with the advantage that you can change any states and/or shaders on the fly in your program if you wish.
Pixel maps are like 32-bit image memblocks that can be used to create or manipulate images on the CPU. Pixel maps can be converted to images and the other way around.
Fonts and labels are used to get text on the screen. There is a default 12px grayscale bitmap font included in the dll which can be used for most general purpose text output (since it is grayscale, you can also change the colour of your displayed text using some internal pixel map magic). Labels are essentially sprites which draw on top of all other 2D and sprites and display an image created from a bitmap font put together to spell out text. Just take a look at the examples, labels are very simple to get your head around.



Questions and answers

DBPro is open source and it wouldn't be hard to modify and recompile DBProCore.dll to not initialize DX9.


The latest versions (starting with 0.2.0.0) will support Windows Vista SP2 and later, assuming the DX11 runtime is installed. When run in backwards compatibility mode, a DX10-capable graphics card will be enough (that is you don't need a DX11-exclusive card), however the DX11 runtime is still needed.


It appears that old attachments can no longer be deleted from a post.
The one on top will always be the latest; additionally their file names should hint at their build date as well.

Change log
The latest version will always be attached to this post.
High speed download links to an external site will also be provided.

Update 2016-10-01
The previously uploaded version 0.4.7.5 build has expired. A new, extended trial is now available from the download link below and attached to this post.
If you already have the plugin installed you only need to replace the DX11.dll file in your Compiler/plugins-user folder, so rather than download the entire installation folder again you can get just the plugin from here.
This version is set to expire in July 2017, by which time I certainly hope to have gotten a newer version out.

Latest build build (0.4.7.5) 2016-01-04 - high speed download
Support for creating and using texture arrays, cubemaps and cubemap arrays has been implemented.
Limbs will now have their bounding boxes recalculated to take changes to their associated meshes' vertex data into account.
The old DX11 SET CAMERA RENDER TARGET function has been renamed to DX11 SET NEW CAMERA RENDER TARGET, since it creates a new render target. It is now possible to create standalone render targets using DX11 CREATE RENDER TARGET and then set them to cameras using the (new) DX11 SET CAMERA RENDER TARGET function.
Finally fixed the input initialization bug that caused the escapekey to be recorded at startup and thus trigger an immediate close of the program unless the escapekey was disabled for this purpose. This would happen if another window took focus or if the render window was clicked in before it was fully loaded.
The DX11 IS MOUSE BUTTON XXX / DX11 IS KEY XXX functions have been changed to return signed integers instead of unsigned booleans. This means that you can now write shorthands like DX11 MOVE CAMERA cam, (DX11 IS MOUSE BUTTON DOWN(0) - DX11 IS MOUSE BUTTON DOWN(1)) * speed# with it working properly. Previously the resulting "-1" if only the right mouse button was pressed would be interpreted as an unsigned value and wrap around to ~4.3 billions instead.
Added the available D3D11_COMPARISON_XXX constants to DX11Constants.dba.
The mouse cursor will no longer be automatically positioned in the upper left corner of the rendering window upon initialization. If you want this behaviour (or to otherwise set the starting position for the mouse cursor) you can use the DX11 SET MOUSE POSITION function.
Four sampler slots have been reserved for the lighting system. As such only 12 are available for user shader techniques as of now. This number may increase up to 14 in the future. 12 samplers should still be more than enough as most different textures will be sampled in the same way (ie. using the same sampler state) anyway.

Unreleased build Build 0.4.7.1 MA on 2015-11-30
Fixed a bounding box transformation oversight that would sometimes result in incorrect bounds being used for objects, thus for example causing them to be culled when not actually being out of view of the rendering camera.
Fixed a bug which caused render target setting to fail when using a Texture2DArray as the render target resource to bind. Note that Texture2DArrays weren't available in previous official demo builds anyway so this issue should never have occurred.
Added support for specifying a set of optional paths that will be searched if a file to be loaded cannot be found in the current working directory.
-> Along with this, loading of media included with DBPro executables is also facilitated.
-> New functions: DX11 REGISTER FILE PATH, DX11 UNREGISTER FILE PATH and DX11 RESET FILE PATHS.

Unreleased build 0.4.7.0 on 2015-11-08
Added functionality for changing screen resolution / fullscreen state at runtime (DX11 SET DISPLAY MODE). Unlike it's DBPro counterpart, all data loaded into VRAM at the point of calling this function will be retained, ie. there is no need to manually reload all objects, textures, etc.
Available display modes supported by the current system can also be retrieved.
When alt+tabbing, or otherwise forcefully changing focus from a fullscreen exclusive window, the render window will be automatically windowed to allow this. When switching back to the window, ie. by clicking in it, alt+tabbing to it, or minimizing the window(s) that are on top of it, it will now switch back to fullscreen mode.
Added the Display category to the documentation, complete with some new basic functions (window moving, caption changing, etc.).
Added text input functionality.
Added manual camera viewport control.
Fixed a bug where attempting to draw text would sometimes cause a crash if the text only contained control characters and nothing actually visible.
Fixed various discovered errors in the documentation.

Unreleased build 0.4.6.5 on 2015-11-02
Fixed a bug where glued objects/limbs/cameras did not have their world sectors properly updated if only a parent object was moved, but not the child object itself, which could thus lead to erroneous early clipping of objects and limbs.
Fixed an issue where box objects had an "incorrect" texture coordinate orientation. The uv coordinates for primitive cubes and boxes now match those created by the standard DBPro library.
Added an optional parameter for the DX11 CREATE OBJECT QUAD function to allow orienting it so that it faces in the negative Z-direction ("towards the screen") instead of facing the positive Z-direction ("away from the screen") as all other objects do by default. In order to maintain backwards compatibility the default behaviour is that quads created using this function still face the in positive Z-direction.
Added DX11 GET OBJECT SECTOR X/Y/Z and DX11 GET WORLD SECTOR X/Y/Z functions.

Unreleased build 0.4.6.4 on 2015-10-29
Fixed a string table bug where DX11 PRINT TO PIXELMAP was accidentally called DX11 PRINT TEXT TO PIXELMAP instead.
Added missing functions DX11 GET CAMERA FOV, DX11 GET CAMERA ASPECT, DX11 GET CAMERA NEAR RANGE and DX11 GET CAMERA FAR RANGE.
Fixed a bug with the DX11 GET MATRIX ELEMENT function where this would check the range and thus potentially return zeroes for valid row/column indices while also having the possibility to try to index into non-existing rows/columns, thus causing an invalid access operation.
Fixed the documentation for various DX11 BUILD ??? MATRIX functions which accidentally didn't list that these functions return the created matrix.
Added functions DX11 BUILD ROTATION MATRIX X, DX11 BUILD ROTATION MATRIX Y and DX11 BUILD ROTATION MATRIX Z.
Changed the transform class to compute rotation matrices in a different way. This (hopefully) alleviates an issue where there would be rotational discrepancies when combining euler and free-flight rotations for the same object/limb/camera.
Changed the decomposition method from rotation matrix to euler angles (for correct reporting by DX11 GET OBJECT ROTATION X/Y/Z while using free-flight rotations) to a more efficient one. The resulting angles are identical to those computed with the previous approach.
Changed the way view matrices are built for cameras. This should hopefully lessen accumulative floating point errors when using free-flight rotations.
Fixed a bug with the sector object grouping system where objects could potentially be "left behind" if they moved into a new sector by such a large difference from its previous positioning that it would no longer be in a shared sub-sector, thus making the object stuck in its old sector, to which its new position wouldn't even belong.

Unreleased build 0.4.6.3 on 2015-10-24
Fixed a bug where a per-mesh buffer table allocation was accidentally several times too large. Should reduce memory usage by 224 bytes per mesh.
Fixed a bug where absolute include file names failed to be resolved during precompilation.
Fixed a bug where attempting to generate mip maps for an uncompressed DDS texture would fail with an error message saying the texture could not be loaded.
Fixed an issue where setting the same state of a sprite would overwrite a flag stating that the sprite needs to be updated even if the cause of this requested update was a different state. This was the cause of the visual artifacts with drawn text suddenly jumping horizontally or appearing blurred sometimes when the printed text would change from one string to another.
Added functionality for attaching 3D entities (camera, objects and limbs) to each others' transforms ("GLUE XXX TO YYY"-style behaviour).

Unreleased build 0.4.6.2 on 2015-09-23
Fixed a bug where DX11 FRUSTUM CULL BB was accidentally returning true if the bounding box in question did PASS culling.
Also fixed return type of DX11 FRUSTUM CULL BB to a full integer; it would previously only work if assigned to variables explicitly declared "as boolean".
Fixed a documentation bug where DX11 ENABLE ESCAPEKEY was accidentally listed as DX11 ENABLE ESCAPE KEY.
Added DX11 GET CAMERA VIEWPORT WIDTH / HEIGHT functions.
Added convenience DX11 GET SCREEN WIDTH / HEIGHT functions.

Unreleased build 0.4.6.15 on 2015-09-21
Implemented a means of live patching the DBPro compiler upon execution, as well as performing compile-time "precompilation" on the DBPro source.
This facilitates the introduction of line number reporting upon errors arising within the plugin.
It also eliminates the arbitrary limit of the DBPCompiler only allowing linking to the first 1000 functions within a single dll, which the DX11 plugin is going to go beyond shortly.
Beware that further testing is required to ascertain the feasability of this approach.

Unreleased build 0.4.6.1 on 2015-09-14
Added support for drawing 2D to any camera complete with individual sprite masking (previously 2D operations were restricted to only the main (screen) camera).
Fixed a string table oversight where DX11 SET CAMERA ASPECT RATIO was previously accidentally called DX11 SET CAMERA ASPECT, while the documentation still added the RATIO word, prompting confusion at compilation time from DBPro.
Fixed a bug where orthographic cameras would not have their transform data properly initialized, thus potentially causing incorrect rendering results unless the transform had all its components manually set from DBPro after creating such a camera.
Added pivot fixing functionality for objects, limbs and cameras.
Fixed a bug where DX11 CREATE OBJECT SPHERE would fail if it wasn't created from a vertex layout containing a TANGENT0 semantic element.

Unreleased build 0.4.6.0 on 2015-09-11
Added support for free-flight transformations.
Forward, up and right vectors can now be obtained for objects, limbs and cameras to afford space and orientation calculations using those.
Fixed a bug where DX11 MOVE OBJECT / LIMB / CAMERA would not always update to use the latest rotation before moving.
Fixed a bug introduced in build 0.4.5.4 where primitive objects created using the DX11 CREATE OBJECT XXX functions would not have the default shader technique set on creation.

Unreleased build 0.4.5.4 on 2015-09-09
Added support for multi-pass shaders. The DX11 SET OBJECT SHADER TECHNIQUE and DX11 SET LIMB SHADER TECHNIQUE functions now take an optional third argument for setting the pass that the technique is to be used for.
Also added a new, very simple example project demonstrating the basics of multi-pass shading.

Unreleased build 0.4.5.3 on 2015-09-05
Rewrote the mip map auto generation functionality for DDS texture loading; it should now work with arbitrary formats, including compressed ones.
DDS textures now support import-time conversion to the standard BGRA32 (0xaarrggbb) pixel format if requested via the fourth parameter to DX11 LOAD IMAGE.
Added the DX11 SAVE TEXTURE function.
This saves a previously imported texture (image) including mip maps and specific pixel formats. It is faster to load a precomputed texture saved using this function than it is to import it from a 2D image format (BMP, PNG, JPG, etc.) each time you run your program / game.

Unreleased build 0.4.5.2 on 2015-09-04
Fixed an oversight where there was no automatic generation of mip maps for DDS textures when setting the generateMipMaps flag.

Unreleased build 0.4.5.1 on 2015-09-03
Fixed a bug where cylinder meshes (such as created using the DX11 CREATE OBJECT CYLINDER function) had a counter-clockwise face winding order and as such appeared to be in-facing.
Imported as well as engine-constructed meshes can now either import per-vertex tangents and binormals, or have these be generated from existing normal and uv data.
Fixed a bug where vertex colours would be written to the vertex buffer as four float instead of four byte values when imported from external object files, thus potentially overwriting any subsequent 12 bytes of per-vertex data if these had a higher priority such that they were imported before the colour (ie. normal data).
Fixed a bug where the meshes created by DX11 CREATE OBJECT SPHERE accidentally had their top and bottom normals reversed.
Changed the built-in quad (plane) creation routine so that these will have a proper orientation (facing the positive instead of negative Z axis).
Objects created using DX1 CREATE OBJECT QUAD will be rotated 180° around its Y axis by default to account for this.
This solves the issue where using DX11 SET OBJECT LOOKAT for an internally generated quad caused its back face (as opposed to front face) to face the given position.
Fixed an oversight where the documentation and keyword file was stating the function name DX11 GET MATRIX IDENTITY instead of DX11 GET IDENTITY MATRIX, which is the actual callable function.
Moved the DX11 GET VIEW MATRIX and DX11 GET PROJECTION MATRIX functions from the math documentation list to the camera documentation list.
Removed the DX11 GET WORLD MATRIX and replaced it with separate DX11 GET OBJECT WORLD MATRIX and DX11 GET LIMB WORLD MATRIX, in order to allow better user control.
Added the DX11 SET BOOLEAN PARAMETER / DX11 SET INTEGER PARAMETER / DX11 SET FLOAT PARAMETER functions.
These are intended for future use to allow setting further parameters without having to provide them all to the DX11 INIT function.
Fixed a string table typo making the 3-parameter version of DX11 DRAW IMAGE not being callable from DBPro.

Build 0.4.5.0 on 2015-03-04 - high speed download
Completely rewrote the mesh animation system. This fixes previous bugs (incorrect mesh deformation and an incorrect string table entry causing DX11 GET ANIMATION FRAMES PER SECOND to not return anything at all) as well as provides a generally better animation platform for possible future extensions, such as shader-based animation.
Better animation interpolation approach should provide smoother transitions when changing animations being played on a certain object.
Animations can now be played in reverse.
A certain frame range of an animation can be played instead of the entire animation, complete with a custom settable frame in that range to start the animation at.
Animations can be resumed from where they were previously stopped.

Build 0.4.0.0 on 2014-10-19 - high speed download
Added support for DirectCompute (compute shaders and GPU-writable buffer and texture resources).
Added read-only buffers for use with any shader stage to complement the GPU-writable ones. A GPU-writable buffer can be written to by one shader and read from by another. Of course such GPU-generated buffer contents can also be read back to the CPU.
Added SetBuffer()-functionality to allow up to 8 data buffers as well whereever textures could previously be bound (objects, limbs, sprites).
Added a null mesh type that allows executing vertex shaders without any actual vertex data. This increases efficiency by removing some CPU dependency where a vertex shader can construct its geometry itself, such as for screen quads or particle planes for example.
Added depth/stencil states which allow configuration of depth and stencil per-pixel testing.
All shaders will now compile using shader model 5 if in DX11 mode or shader model 4 in DX10 mode, unless you specify your own version to the shader loading functions. This differs from the earlier behaviour where shader model 5 would be used by default even in DX10 mode (which only supports SM4).
The DX11 LOAD XXX SHADER functions will now properly terminate the program if the shader compilation fails. The previous behaviour allowed the program to continue with invalid shaders, waiting for a crash when trying to access it.
Fixed a faulty string table entry which made the fillColour argument of DX11 CREATE PIXELMAP not being used.
Fixed faulty documentation and keyword entries for the DX11 TRANSFORM VECTOR ... functions to reflect the fact that they can either write their result to a target vector or create and return a temporary vector.
Added constants for sampler state texture address modes and access modes for resources (textures / buffers).
Changed the way in which mesh transform data is supplied to shaders to use a structured buffer bound to register t24 indexable by the instance id (available from the input assembler using the SV_InstanceId semantic in your vertex shaders) instead of the previous approach where per-instance data was intermingled with per-vertex data. All default and example shaders have been updated to use this new approach.
Fixed memory leaks where Rasterizer and Sampler states weren't released when changed (recreated) during runtime.
Reduced number of available cbuffer stages to 12. My previous assumption that there were 16 available was wrong and it is in fact limited to 14 (as weird a number as that is). The top two buffer resources are reserved for future per-frame data that will be supplied by the engine.
Added DX11 SET CONSTANT BUFFER which allows changing the cbuffer currently bound to a certain shader technique stage during runtime.
Improved error handling.
Added DX11 GET CAMERA FORWARD VECTOR X/Y/Z.
Fixed a bug where DX11 GET PROJECTION MATRIX accidentally returned the view matrix instead.
Fixed a bug where the various DX11 SET XXX LOOKAT functions didn't update the rotation of the underlying transform properly.
Fixed a bug where the introduction of sprite shaders from the latest version (0.3.0.0) accidentally caused sprites to be depth clipped by 3D geometry.
Fixed a problem where the DBPro program would hang after displaying the message box as part of the Ziggurat engine's error handling.
(¤ Requires more testing).
Added DX11 ??? EXISTS functions for all resource types.
Added DX11 IS SPRITE OVERLAPPING which allows for developing crude collision detection.
Fixed DX11 DRAW RECT to draw the rectangle with normal corner interpolated colours instead of using bilinear filtering, which to me is the more expected result of a gradient.
Added two new examples demonstrating how to make a screen quad without any vertex data (using a "null mesh") as well as a particle system running entirely on the GPU using a mixture of compute shader programs and rendering shaders using data generated by the compute shaders.

Build 0.3.0.0 on 2014-07-25 - high speed download
Added support for hull, domain and geometry shaders; good for hardware tessellation, displacement mapping, particles etc.
Increased maximum number of textures and sampler states per limb from 8 to 16.
Added support for custom sprite shaders
Added various updates and extended functionality to the 2D drawing system
Added sprite layers as a way of grouping sprites together with regards to draw ordering.
Added functionality for drawing shapes, text, images and sprites directly to the screen on a per-frame basis.
The full-screen mode now lets you use a custom resolution instead of being locked to the current system resolution.
Added string table entries / dll exports for certain functions that had been previously left out of the DBP dll.
Added two new example programs with full DBPro and HLSL source demonstrating how to achieve dynamic displacement mapping using hardware tessellation and mass-foliage rendering using geometry shaders.


Build 0.2.0.0 on 2014-05-01:
Added backwards compatibility for DX10 / DX10.1 graphics cards. The computer must still have the DX11 runtime installed, but won't need an actual DX11-capable GPU in order for this to work. All default shaders have been recompiled using shader model 4 so that they will work with these cards.
Added support for importing and playing skeletal animations.
Added functionality for drawing lines in 3D space.
Added functionality for retrieving a limb from an object by its name.
Added functionality for creating vertex layouts from the perhaps more familiar flexible vertex formats (FVF) used for the same purpose in standard DBPro.
Added an optional flag to the DX11 GET LIMB POSITION X/Y/Z functions for retrieving limb positions after applying any animation influence.
Added various default resources that the engine will use if none are specified (vertex layouts, fonts, shaders, default textures etc.).
Improved error handling.
Fixed various issues found during development (I gave up trying to keep track of them).

Build 0.1.0.1 on 2014-03-06:
Added rudimentary error handling - at least it shouldn't just outright crash in ~75% of the cases or so now.
Added checks for whether external media files actually exist before trying to read them.
Added a default vertex layout to reduce the necessary code to setup simple tests somewhat.
Added DX11 ADD CONSTANT BUFFER to the string table (it had accidentally been omitted from there and thus unusable in the previous releases).
Fixed a bug where DX11 GET CAMERA ANGLE Y was actually returning the X angle instead.

O.o

Tagging in for now...

nice work man. i see you gave on this one lots of work.
but i think its not a good idea to wrap DX11 to DBP users.

you see, everyone who got DBP, wants to make games in easy way,
your 1st example of a cube can be done with 4 lines of code in DBP languange
your code is about 50 (without notes)

if you will manage to optimize your languange into something smaller, people would even buy it from you..

This a major must-have plugin; not quite what I expected to see on a typical Saturday morning observing new DBP WIPs.

I get a crash when I run the spinning cube. It crashes on the call to DX11 Sync. I am running Windows 7 with Direct X 11 (in addition to Direct X 9.0c).

I appreciate Sergey's opinion in all honesty. But I am afraid I will have to disagree because in reality I would use your plugin regardless of the issues Sergey pointed out, knowing that the least ideal state of ones project, is at its beginning. Please excuse my disposition because I am not aware of any DX11 development library that could do the same in 4 lines; and cannot see what is so complicated about the example, even in my first 30 seconds of reading through it... you even get formatted help documents.

If you need any help testing, snippet examples, documenting, web-dev, graphics or any web-space then let me know, it would be well worth it. (Although it would be nice if I could get it to work)

Although you are quite well known for your advanced programming skills, it would be unfortunate if you did not receive any help from the community on this.

It appears that this is serious and you have been hard at work; I hope all goes well with it and that you get what you deserve in the end.

This is a historical moment, and a new generation in the making.

I see your point, however most of those "extra lines" are just for setting things up; if you start doing more advanced things 30 lines won't really seem like much in the grand scheme of things. But for such a simple thing as a spinning cube, sure, it might seem a lot.
If you consider the underlying C++ code, the DBPro code length isn't that much - just creating the vertex buffer for that cube takes slightly over 200 lines, and that is using a semantic managing class to reduce code length...
Anyway, I hear what you're saying and it might be possible to get more things done behind the scenes for you, however that would also mean taking away some of the possibilities of setting things yourself. DX11 is also completely shader based, so you won't get away from using some more advanced features, looking from a standard DBPro standpoint. It would be possible to provide more default states (mainly for vertex layouts I suppose) that would be set if you do not specify any though. I'll take that into consideration for the next build.


@Chris Tate: Thank you very much for your kind words

Hm, yes I was afraid there were going to be issues like that.
Did you change the example code in any way? I suppose not, but the main reason for crashes from the sync function is if an invalid value has been entered somewhere; since there pretty much isn't any error checking at all yet, such data is happily accepted by setter functions and then you get an out-of-bounds or access violation exception when trying to make use of it at a later point in time.
Are you able to see where / why it crashes (through chosing to debug it using visual studio or similar)? Maybe it says something like "trying to access 0x0000000d" when it fails?
Feel free to send me an e-mail (the link from the button below should work) so that we can try to work this issue out.


Testing and some example writing would be very welcome; the other things are probably a bit off into the future yet.

@ Rudulpho,

As Chris Tate said, a major breakthrough for DBPro.

Keep up the great work on this!

@ Duffer: thanks

I've managed to identify and resolve two bugs in the original plugin; the new version has been attached to the opening post and also has a direct link available in the second post.
I've also included a second plugin version in the downloadable zip archive that will output a log file to C:\DX11.log in order to help better identify the cause of a crash, in case Chris Tate's issue will persist even after the two afforementioned bugfixes.

Hello again


I attempted to pin point where the crash occurred in the original example. I achieved this via message box before each significant command in the example. The last message to occur was the one before the sync call; so that is how I knew where it crashed. - (Although in an ideal scenario, the crash would not have occurred in the most complicated part of the engine which I am guessing is the synchronization process.)

I did not manage to get the latest version to run; it crashes the same way during the sync call and it seems the executable is not able to create the log file. I do not know how to provide it with access. I copied the new content from the archive with overwrites, and replaced the DX11.dll with the debug version (DX11-Debug.dll) in the plugins-user folder.

Did anyone else have any trouble compiling the example?

Yeah, I got that much.


Hm, that sounds most strange indeed. Are you sure you checked for the file in the correct place ("C:\DX11.log") and refreshed your browser to ensure it would show up? If that doesn't work, are you sure your created program has write access to your C: drive (UAC settings, run it as an administrator and all that jazz)? It shouldn't even get to the sync part if it fails to create the file.
If you want I can change it to show a message box for each log entry instead? That would be quite the thing to sit through but I guess it would at least display.

You can produce a message box alternative if you feel that would be efficient. I have no issue with clicking through message boxes if it helps.

I tried running it in administrator mode. The log file was created however it is empty; 0 bytes.

I could not run a debug procedure by the way. There is no error message, just a report that the program had to close and that Windows will notify me of a solution, bla bla bla.

I do not mind posting my experiences here, unless you prefer to discuss the problem via email.

Ah, well that explains something, I suppose the internal file buffer doesn't get filled up enough that it is actually written to disk before the program crashes. Try the attached version instead, it manually flushes the output stream after each write (so no message boxes, hopefully the file will be written to now).


If you have Visual Studio installed it will allow you to try to debug the program when that "Windows couldn't find a solution" message comes up. It won't give you much but a stack trace that may or may not be of interest to the point of the crash can usually be provided. It isn't particularly important I believe, but there is some dll file (whose name I can't remember at the moment) that DirectX 11 programs will tend to crash in a function of if the system they are run on have a too overclocked GPU.

There was no debug button on the error message box; what must I do to get Visual Studio express 2010 to debug it? I will google that question in a moment in anycase...

Here is my error log enclosed in code tags. It seems to be the rendering phase.



I have to run it in admin mode to give the program access to my root directory.

For me you will get a dialog box saying "Program xxx has stopped working" that gives you two buttons to either "debug" or "close program" if you wait until "Windows has failed to discover any solutions to this problem". If you just abort that (completely useless) search it has to do everytime it will not give you the debugging option. Also I'm using the full version of Visual Studio 2010 rather than Express, but I don't think that should matter.

Anyway, looking at your log I'm wondering if it may not be the nvwgf2um.dll problem I mentioned in my last post. Can you run any other DX11 games (Battlefield 3 / 4, Crysis 3, Civilization 5, Asassins Creed 4, World of Warcraft)? If not you should try up-/downgrading your graphics drivers.
If you can run other DX11 programs I can recompile the dll with more logging in the rendering part.

Hmm, this is not the case on my system for some reason; even with traditional DBPRO applications crashing. See the message box image attached.



I can run Civ 5 in DX11 mode. They actually label that mode Direct X 10 & 11, so I do not know if that means I am running it in version 10 for Windows 7. I have an NVidia Geforce 210 graphics card.

Hm, I see... Well, if you have Visual Studio you can put a message box at the top of your DBPro program so that it halts there until you press OK on it, then run it and go to Visual Studio, then choose "Debug -> Attach to process", find your DBPro process in the list and click on the "Attach" button. Then you accept your message box prompt and let the program do its thing, the VS debugger should then catch the crash.


OK, that's probably DX11 in backwards compatibility mode for DX10. Problems should occur there too if that was it I believe. It does seem you have a somewhat "old" graphics card but that shouldn't need to cause crashes like that.

Try the attached plugin, it does more extensive logging inside the offending function.

Impressive!! One of the most exiting things which were made for DBPro last time! Such plugins can work very various on various PC but if it wil be stable enough I can pay for it. How much speed does it gave? And are any ways to have this on directx 9 ?
Amazing! This means that it will be able to create realtime Global Illumination on DBPro!!

Thanks


That differs from case to case and card to card. One of the things it is good for is rendering lots of identical meshes (like foliage or particles) in realtime. In DX9 you would emulate this effect by merging vertex data for all such objects (ie. all grass tuft objects in a level / a large chunk of them) into single, very large objects to avoid the overhead of having to issue a draw call for each one of them. On modern cards, draw calls are less expensive than they used to however so the actual difference isn't all that tremendous; again it depends a bit with what you're using it for though.
Here's a simple comparison of rendering 10 000 TreeMaker trees in standard DBPro (left side) and using this plugin (right side). As you can see, standard DBPro makes 20002 (yep, I failed and made it 10001 trees... oh well) draw calls while the DX11 plugin only makes two (one for the trunk and one for the leaves limbs). The DX11 plugin, which uses hardware instancing, draws the same scene ~2.6 times faster (this maintains roughly the same if you increase the number of trees to 20 000, making the DX11 version run at 34 FPS and the DBPro version at 12).

In any normal scene you would probably at most have some 5 - 10 000 meshes visible at once, which yields "playable" speeds with DX11 and DX9 alike. Of course, more headroom opens up for more possibilities to run more demanding shaders or post processing steps.

@Rudolpho
not bad)))) Still no way to do this in DirectX9? Maybe it is possible to change DBPro .dlls?
Also Instancing Demo Crashes for me =(



Here is log:
@dx11Init

Attempting to create DX11 device .... OK.

Creating input manager .... OK.

Initializing sector engine .... OK.

Creating depth stencil states .... OK.

Creating back buffer .... OK.

Creating default (screen) render target .... OK.

Creating default depth stencil buffer .... OK.

Testing state binding .... OK.

Initializing common render states .... OK.

Creating constant buffers .... OK.

Creating instance buffer .... OK.

Creating screen camera .... OK.

Creating 2D camera .... OK.

Preparing default shaders .... OK.

Compiling default shaders .... OK.

RC: 0

> DX11 initialization complete!


Extracting default font .... OK.

Loading default font .... OK.


My PC: i7-2500k gtx580 16gb Ram Win 7 64bit

This... This is exciting
Nice work Rudolpho, this is brlliant! I've got to try this...

Hey Rudolpho, just want to say that this project is motivating me to stay coding with Dbpro. I really hope you continue working on this plugin because it seems like it could have some huge potential to make the rendering pipeline a lot more efficient. Of course, there's some dx11-specific features to look forward to such as geometry shaders too

looks like a very useful addition for DBP. tagging in.

Rudolpho, have you thought about mentioning this plugin to Lee for use in FPSC Reloaded? I think he'd be be happy to pay for the source code to something as awesome as this! It could save him quite a bit of development time in the future...

nice idea.DBPro and FPS Creator still have not any impressive updates for years even on Directx9

Wow Dx11 ..this will bring a huge difference in my programming routine. All those awesome GPU articles that i cant try to replicate on dx9 would be a possibility now ...

You are a legend Rudolpho. Thanks for cooking this up man.

Spot on!



Now this the first time I have used the Visual Studio debugger in this manner, so please forgive me if I have not posted the correct information; however, the call stack indicates the following: " [Frames below may be incorrect and/or missing, no symbols loaded for nvwgf2um.dll", this is the dll you mentioned yesterday.

Hopefully this helps; otherwise let me know what else I can do. Let me know if I should attempt to temporarily downgrade my graphics card.

Full call stack:

Debugger message: "Unhandled exception at 0x6b235bfe in Application.exe: 0xC0000005: Access violation reading location 0x00000358."

This sounds very worthwhile.

This is probably one of the biggest improvements I've seen for DBP in quite a long time. Possibly even since I've been here (since 2006 I believe), so great work. Can't wait to see what comes of this!

Thanks for the support everyone, kind of funny it managed to attract so many new posts on my 25:th birthday of all days.

@Brightside_

Hardware instancing was an advertised new feature of DirectX 10, so no, it was not available in DX9. As said you can achieve the same effect to some extent by merging all your objects using the same materials into one object, but that's a work-around that was usually used if it was found to cause increased rendering times only (I seem to recall this having been done in DBPro by some people throughout the years also; the most common such solution being to add objects as limbs to a master object (which ironically still causes just as many draw calls, although some other overhead from having separate objects gets nullified)).


You get that error message if you try to use a DXGI_FORMAT_XXX value that the byte size isn't known for. It is quite possible I've forgot to add one of the more exotic formats to the size-lookup function, but if that error was present in the instancing demo code the error would occur all the time, there is no way it should be system-dependent. As such, may you have changed any format types or possibly you forgot to include the constants file (thus making all DXGI_FORMAT_XXX constants default to 0, which isn't a valid format)? If this is not the case, please tell me what formats you are using and I'll see if it is missing from the lookup-switch.

@SamKM

I don't think the time would be quite right for that; as far as I can tell, FPSC Reloaded is just going through some final polishing at the moment, while this library in all likelihood has months of work left before it can be considered "completed".
It would be truly awesome if TGC would be interested in it at some point in time though

@Chris Tate
I was afraid of that, that means it is failing inside the actual DX11 DrawPrimitive call. Seeing to that dll and the many posts on it around the net, I believe this particular problem cannot be fixed by me; in all likelihood it is your graphics driver's fault. If possible, I would try to upgrade your drivers (otherwise try to downgrade one step at a time) and undo any overclocking settings for your graphics card if you have that (note that it is not uncommon that cards are overclocked "by default" straight out of the factory). That's taken from reading through posts on this issue on various forums. It is odd that Civ 5 does work for you though; perhaps it is DX11 specific and not present when in "DX11 in DX10 mode". Would it be possible for you to run a true DX11 game (Dragon Age 2, Battlefield 3/4, World of Warcraft etc. or if you can force Civ 5 to use DX11 instead of DX10) to see if this issue would occur there as well?

@Rudolpho
anyway your work is great.Waiting for updates
You said that DBPro is in open source.So do you ever try to change it by yourself?I mean native DBPro dlls and compiler files?Is it possible to rewrite and fix bugs?Because seems like Lee don't want to update DBPro in future..

Thank you again


The compiler unfortunately isn't open source, but yes, I have recompiled some of the native libraries. I do believe IanM has been granted commit rights to the [url=https://code.google.com/p/darkbasicpro/]official DBPro repository, so he's been doing some "semi-official" bug fixes over there.

I don't have any DX11 games; but I will spend some time running some Dx11 tests to see how it goes - hopefully there are some free Dx11 applications I can find, otherwise I might by a video game although I have banned myself from playing them to free up more time for my projects. Perhaps later on a solution will come up.

I tested your plugin on my little laptop and received a "Failed to initialize image from PixelMap" error, followed by a crash during the "Resetting render states" phase. This foreknowledge might be helpful in future when anyone running your plugin on an AMD/ATI HD4200 or similar graphics card experiences problems.

Spinning Cube Example:
Log:

Following on with my main PC issue, I will take your advice regarding the overclocking; perhaps my card is overclocked by default, it would not suprise me because the card is a bit wierd... it has had an inconsistent history in my experiences running it on two computers so far and can get really hot.

In time I am sure a solution will be found. I might have to write up a bare bones example to see if the simplist possible dx11 application still causes problems.

You can play World of Warcraft up to level 20 for free, although it is a rather big thing to download for a simple test.


That can probably be explained by the administrative rights for the program again; the dll extracts the default font sheet and loads that as a pixel map on each run through. If it doesn't have read / write access to your temp folder this will fail.
You can also try to load your own font and vertex / pixel shader instead - doing this will still cause that message to appear but it will probably prevent the crash since the default (unloaded) instances would never be used during runtime.


I do hope a solution will be found indeed. It would be quite sad if a new graphics card would be required just to run it at all.

This is awesome Rudolpho, keep up the good work. Happy birthday man

Ouh nice, could you make a lib out of it, like GDK?
Everyone is waiting for a better GDK

Lol, I do not want to install World of Warcraft because I fear I will end up getting addicted to it again.

I will need a new PC or two later on this year to expand my little office. A new graphics card will be necessary because I want to test advanced features of my world editor.

I would end up buying your plugin to build display mode options to run on typical hardware of tomorrow, not for this generation; so I am not too concerned about it not working on my somewhat dated computer.

I tend to prefer building on older PCs so I can run my engine in the worst possible conditions to feel what it is like to run it on a budget.

I have not read much of the help documentation yet; but great work with it. The last library with so many commands was Matrix1. It is very interesting seeing some new concepts in there such as limb look at points, vertex data to vector assignments, labels, pixelmaps. I do not think people realize how much is actually in the plugin just yet. Looking forward to using it one day once I get my DX9 viewports out of the way.

Downloaded Latest build 2014-03-02 on my Win8Home lappy and the spinning cube worked perfectly first time!
I got an error with the instancing program though:

I might have to restart my 3DBangBang game in DX11 now!

Very nice work!

Thank you


A straight wrapper library for the DBPro functions (like DarkGDK is too) would probably be possible to make in an hour or so. For the underlying engine it would be harder to compile it to a static library since it uses lots of small, inlined functions that are declared directly in the class header files (yes, it is object oriented). That said it is of course possible with some effort, I want the engine to look a bit more solid before making it public though, so it might be a while yet.

@Chris Tate

Fair enough x)
There is a new version attached to the main post now again that provides some rudimentary error trapping. The log file also contains some new fallback data about what feature levels are available on your system, if you could try that one and see whether it reports using DX 11.0 or something else?


Yay, finally it is working for someone else but me!

To anybody who cannot run the instancing demo, there is a slight oversight where it includes the constants file from its absolute location on my harddrive. Apparently DBPro doesn't report not being able to find it but just happily skips including it in silence. If you manually go to the includes page / solution explorer of your editor and change it to refer to the constants file included with the examples folder it should hopefully run. This problem has also been fixed in the new version (1.0.0.1) uploaded today.

Hello again

I tried the latest build and it confirms that it would need to run in DX10.1 compatibility mode and results in an early crash with the following output: @dx11Init

Attempting to create DX11 device ....

Interesting, since DXDiag indicates I am running DX11. My graphics card simply does not support it it seems.

I am downloading the DirectX 11 3D Benchmark program to confirm this.

Confirmed. I will replace my graphics card; later on in the year.

Has anyone performed any DX11 experimentation yet?

While it never is funny to find out things have been posing as something they were not, I'm glad we at least found the reason for that elusive issue.

Anyone do anything cool with this plugin yet? I'm planning on making a small simulation game involving this.

I hope that's not an april fool's joke...
On a more serious note, would be really cool if you did

Unfortunately it seems this project didn't attract very much interest; I suppose the lack of updates doesn't really help either.
As for that, the next release is intended to support bone animations as well as geometry shaders. Unfortunately I'm quite tied up trying to finish my degree paper before the end of this term so I pretty much have no spare time to work on this at the moment. But one day in the hopefully not all too distant future...

No, I'm serious! I'm really excited about the speed of instancing with this plugin. I'm thinking of creating a half tech demo, half short game that will showcase the increased speed. Something like Goat simulator!

I don't think the problem is that the project didn't attract interest, I just think that the forums are slower nowadays in general. Part of the reason is the fact that dbpro is becoming dated... something that this plugin is moving to solve! Now we just need OOP-style code

[EDIT] One issue I have noticed is regarding the fullscreen mode. Even with the fullscreen mode active, it doesn't use fullscreen exclusive mode or the resolution specified - it just expands the screen window to the native resolution, somewhat like dbpro's current "fulldesktop". In the future will there be more specific flags to specify fullscreen exclusive modes as well as a "fulldesktop" like mode?

Haha, well that sounds nice; nothing like a good goat for tech demonstrative purposes.


Hm, I wasn't aware of that but it shouldn't be too hard to fix so that it will use the desired resolution. If DX is locked to the current display resolution in fullscreen mode (which I'm guessing may be possible), it could just be separatedly changed at startup and then restored again before shutting down.

Edit: As for fullscreen exclusive mode, how exactly would this differ from the used approach?
I suppose it means to take direct control of the screen's front/back buffers, bypassing the window rendering? I haven't really given that much thought; the fullscreen mode is actually supplied by DX itself. The following quote seems to indicate things should be about as efficient in this fullscreen mode as in a would-be exclusive mode:

I will look into it further when I get the time though, thanks for pointing it out.


Thanks for the encouragement.

I have some more suggestions, regarding 2d commands. The current 2d command set is pretty limited. The label and sprite systems are pretty good and plenty fast, but they have some disadvantages.

First of all, it would be nice to have a version of the command that draws text or images to the screen for one frame only (like the paste image command). I'm not entirely sure how the system works under the surface though, so if that doesn't work or will be inefficient that's okay.

Second, since the window is DX11-based, we can't use useful graphics-based plugins such as d3d or image kit. The main features I'm looking for are:
-Box and line drawing with gradients
-Shaders on sprites

Actually, everything could be simplified down to having shaders on sprites. Shaders could allow one to modify vertex colors and create box / lines with gradients. All I'm looking to ensure is that we don't have to create images and load all of them for graphics effects that can be generated in realtime. I'm sure you noticed this already though Just useful suggestions! I want to convert my OpenFPS engine to use DX11 as well, but there are a few things I do in the engine that can't be done here yet... all 2d commands.

Lastly, what do you think about the availability of DX11? I don't have much experience with it but by using this plugin am I disallowing older computers from running my game?

Yes, the 2D functionality hasn't really been a priority.
The label system is just there for convenience; a label is really simply a sprite with an associated font and text and a priority of 0 to ensure it will always be drawn on top of any other 3D / 2D. When the text changes the associated image is recreated from the pixel map that belongs to the associated font. You can implement this yourself using the DX11 PRINT TO PIXELMAP, DX11 CREATE IMAGE FROM PIXELMAP and DX11 SET SPRITE IMAGE* functions.

Sprite pasting would be entirely possible to add; at its simplest it would just be a matter of maintaining a second list of sprites that is cleared every frame. This will of course not really increase efficiency though, but it might still have its uses. Another approach would be to lock and write pixels directly to the back buffer. This is limited in what it can do without getting overly complicated however (all such drawing would be on top of everything rendered and it wouldn't be possible to use shaders or draw anything but pure 2D data. Also any blending would have to be done on the CPU which is obviously slower than having the GPU do it). For drawing simple shapes like boxes, lines and circles this approach may be suitable however. It would also be a good solution for pasting single-frame text.

A sprite is really just a 3D plane that is rendered in a separate pass after any 3D rendering (and only to the main screen camera at the moment) with an orthographic projection corresponding to the screen size. This opens up for some nice possibilities such as drawing any 3D object in 2D at an exact pixel size. It also means that the engine inherently supports shaders on sprites, although this functionality isn't exposed in the plugin at the moment. It should be easy enough to add in the next build (although I seem to recall there being some optimizations made based on the fact that all sprites would use the same shader that would have to be undone).


Yes, there won't be any compatibility with other plugins that are based on DX9. This is unfortunate but unavoidable. In a perfect world, another kind of globstruct could be made available to other libraries, allowing their authors to interface with DX11 much in the same way as they currently do with DX9 though, but that's probably getting way ahead into the future.



Unfortunately yes. As far as "legitimate" (non-hacked) versions of DX11 go, they can only be installed on Windows 7 and 8. DX11 is inherently backwards compatible with DX10 graphics cards however, which are supported on Windows Vista and upwards (as well as pretty much any graphics card manufactured in the last eight or so years). Of course this backwards compatibility comes at the price of not being able to use DX11 specific functionality such as tesselation. It also seems not to be quite as easy to actually get anything to run in DX10 mode; I've done some tests that all ended in access violation crashes in system dll's for which there are no debug information. It *should* be possible to provide a backwards compatible mode however. As a matter of fact, a DX11 program that only use certain features is supposed to be able to run on DX9 hardware, but this mostly seems like a vague selling point used in advertisements when DX11 was new rather than something that actually is likely to work. It warrants a more thourough look at some point in time however.
By the way, apparently Microsoft has announced DirectX 12 on the 20:th of March this year
I can only imagine that will only be available for Windows 8 and possibly the XBOX One however.



Yes indeed, I admit some of those points hadn't really crossed my mind, so thank you for pointing them out


* Upon inspection, it seems the DX11 SET SPRITE IMAGE function isn't present in the current plugin version but it is present in the underlying engine and just needs to be wrapped up.

Version 0.2 is released and can be downloaded from the opening post or from here.

The main new features in this release are backwards compatibility with DX10 hardware and skeletal animation support.
The DX11 plugin can now be run on DX10 graphics cards as long as the system has the DX11 runtime (software) installed. This should be the solution to the issues Chris Tate were having earlier in the thread and also means that Windows Vista can be added to the list of supported operating systems (SP2 is required in order to install DirectX 11 on Vista). With the exception of DX11 specific functionality (of which the plugin currently only has one, shader model 5 support) all functions should work on DX10 hardware. All internal shaders used by the engine have been recompiled using shader model 4 in order to accomodate this.
There is also a new skeletal animation system which allows efficient vertex data deforming based on joints / bones, aka "limbs" (animating a FPS Creator character I get about 18% higher frame rate using the DX11 plugin compared to standard DBPro). There is a new example project included that shows the basics of how to use the features of the animation system such as combining different animations on different limbs at the same time or getting smoother transitions between two different animations. Some previously existing functionality has also been extended as a result of the animation system; for example limb positions may now be retrieved that optionally take the animation influence into account and a child limb in a object can be searched for by name for convenience.

Apart from these two main things there have been various default resources added to the engine that will be used should you opt not to specify your own which makes simple coding less verbose. There is a secondary version of the spinning cube demo project included with the download now that makes use of this. Granted it doesn't yet meet the desireable 4 line quota suggested by Sergey K, but the 13 required lines (of which 4 are used for implementing a timer based movement system) aren't that far off!
You can also create vertex layouts from the perhaps more familiar flexible vertex format (FVF) flags used for the same purpose in DBPro. There is also a new function hidden away in the "core functions" section of the documentation that allows drawing lines between two 3D coordinates. I found it quite handy for debugging the bone animation system; I'm sure it can be used for lots of other debugging as well (raycasting illustrations come to mind). Furthermore, the error handling has been improved a bit, although I would be lying to call it perfect or even decent as of yet. An inclusion guard has also been added to all example projects to avoid the hard-to-spot errors that can arise if the DX11Constants.dba file isn't included and undefined constants default to zero values during compilation.


Planned for version 0.3.0.0:
Improved 2D functionality as suggested by thenerd
Support for geometry shaders



Let me know if anything isn't working as intended, any wished future features and so on.

If you were wondering why I have not yet replied to your latest post; I am really busy at the moment with work on my engine.

The good news is I got your compatible version to work on the same PC the previous one did not work on.

Realistically speaking I am just about getting my DirectX 9 viewport engine started; so it will be a while before I can fully implement your DirectX 11 plugin in my engine, and I will still need to upgrade my PC to test true DirectX 11 functionality. The good thing is that my Direct X 11 viewport will inherit the functionality of the Direct X 9 version and extend it, so it should not take too long, I only need to override the 3D rendering using your library.

I will discuss how I implement your plugin in my WIP posts in future; perhaps with some tutorials for the community. Hopefully I can get a stable viewport put together by next year and include it in Sports Fiction and the X-Producer as a direct X 11 display mode credited to you.

Just thought I'd check what's happening with this project, good to know it's still in development

I can't speak for anyone else, but to be honest, as much as I love the idea of Dx11 in DBPro, I'm too lazy to switch at the moment
Another reason I'm not making use of of this plugin is that I'm using several shader-based systems such as Evolved's Advanced Lighting in my current projects, and these wouldn't work in Dx11.
When Dx9 finally dies for good though, your awesome plugin will save us all, Rudolpho