Sorry your browser is not supported!

unlocked

Thanks for the unlocking BatVink!

So it has been a long while and little news on this project.
I realize that the scope for version 0.5 probably turned out to be a bit of a far stretch; it is yet a while off but significant progress has at least been made on the lighting and common shader library functionality.
However, the last quarter of 2015 has also seen lots of unrelated additions, improvements and bugfixes to the engine, many of them stemming from e-mail correspondence with Shawn Bower who has been kind enough to give plenty of suggestions and tested the plugin for hitherto undiscovered bugs. Since all these changes are improvements on their own over the previous version 0.4.5 release while not dependent on the as-of-yet incomplete lighting system, it only seems appropriate to release this to the general public. And the fact that the old version timed out by the turn of the year further attests to this so...

Download version 0.4.7.5 of the plugin from the opening post or here.
High-speed download link (external site)

Main new features
Supports DirectDraw Surface textures (.dds files) for both loading and saving.
These files correspond to the memory layout used for images internally by DirectX and as such are faster to load than to import and interpret other image formats like PNG, BMP, etc. You can import such images and then save them out as DDS textures for faster loading in the future; DDS textures also contain the specific pixel format of the image as well as any mip maps.

Supports multi-pass shaders.
This is achieved by being able to set multiple shader techniques on a single object / limb that will execute in sequence and can blend (using various blend modes per stage) with what was drawn in the previous pass.
There is a new, very simple example project included with the archive that demonstrates the basics of this.

Supports texture arrays.
Texture arrays are, like the name implies, a collection of textures. The main selling point here is that a single array only occupies a single shader registry slot, thus potentially allowing you to bind up to 16 texture arrays, which in turn can hold up to 2048 unique textures each, to a single object / limb.
Of course you would probably run out of VRAM before reaching those numbers but there shouldn't need to be any problems with not enough texture slots anymore
Also it is a nice, hardware supported replacements for the texture atlases of eld - no more weird edge clampings and special wrapping cases since each sub-texture in an array is indeed a texture in its own right that can be wrapped, clamped, and so forth just as a normal, single texture can be.
The limitation on texture arrays is that the format, dimensions and number of mip maps (if any) must be the same for all textures in the same array. Most of the time this shouldn't pose a problem, and if you would happen to need it you can always bind multiple arrays, such as one for diffuse maps with one format, another for normal maps with another format and maybe a third for specular maps with a smaller resolution.

Supports cube maps.
There is also support for arrays of cube maps, which function like the array textures described above, only that each cube map then occupies six elements in the array. Unlike texture arrays, cube map arrays require a feature level of at least DXVERSION_10_1, ie. they won't work with DXVERSION_10_0.

Supports free-flight transformations to better correspond to standard DBPro, such as DX11 MOVE OBJECT UP, DX11 ROLL OBJECT RIGHT, etc. Of course the old euler-angles and exact positioning is also still available.

Supports attaching objects/limbs/cameras to one another to make for relative transform hierarchies ("glueing" using DBPro naming). This is done using functions like DX11 GLUE OBJECT TO CAMERA, DX11 GLUE CAMERA TO LIMB and so forth. The hierarchies can be arbitrarily complex and culling etc. will take this into account. Naturally, "unglueing" is also available.

Supports pivot fixing for objects, limbs and cameras.
Position, rotation and scaling can all (or just a combination of them) be fixed as the "default" of the entity.

Supports changing the display mode at runtime.
Doing this will not require any media to be reloaded unlike the case is with standard DBPro.
Alt-tabbing from fullscreen mode will also work as expected now (the application becomes temporarily windowed until this window is activated again, ie. by clicking in it or alt-tabbing again) as opposed to in earlier releases.
Available display modes can also be retrieved in order to allow a user to choose one or select the highest one available etc.

Supports changing the render window at runtime as well.
This allows changing the window size, position on screen, the client size (ie. the actual drawing area without the borders), the caption of the window and its style.
There is also a helper function for building a limited set of common window styles from a set of boolean flags, namely DX11 BUILD WINDOW STYLE. This makes it easy to create styles that for example hide / show the window, removes its borders, sets whether it can be resized, which buttons to show at the top of the window and so on.
There are also functions for retrieving the current screen size as well as the desktop width / height.

2D can now be drawn to any camera instead of just the main (screen) one.

Images can now be locked for direct pixel buffer access.
This is faster than using the pixelmap conversions, but you'll have to deal with raw memory that corresponds to whatever format (which may be a compressed one as well) the image is using.
Supports locking individual textures in a texture array as well as locking a certain mip level. See the included documentation for further details.

Supports buffered, interpreted textual input.
This works rather like DBPro's ENTRY$ function, but with some improvements. You can chose when to start / stop capturing textual input (standard DBPro's entry buffer just grows and grows even when unused unless you call CLEAR ENTRY BUFFER) and you can also set what will happen when certain keys are pressed, for example allowing the input to cancel when the return key is pressed, or only accept numeric input characters etc. Of course the textual input is asynchronous and can be run simultaneously with your other code, ie. it won't block everything like the INPUT command does.
There is also functionality for moving the cursor in the input, both across columns and rows for multi-line input.

Supports looking for files in additional paths than the one from where your executable is run.
You can specify any number of additional folders to look for files in if they aren't found in the main one.

Can now load media files that are included with the executable using the DBPro editors.

Loaded / created meshes can now have per-vertex tangent and binormal data either imported, assuming they're present in the loaded file, or generated from existing UV and normal data.
Set the correponding semantics TANGENT and BINORMAL in the vertex layout used to load / create a mesh / object to facilitate this.

Improved error reporting system that will tell you the function name as well as the source file and line number where an error occurred^*.


Fixed issues
This is just a selection of the most severe ones, see the complete changelog for further details.
Various string table entry discrepancies (causing functions to not have their intended name or to not allow all parameters that they should) have also been fixed, as well as some incorrections in the help files as well as updates to these to correspond to the current state of affairs.

Fixed an oversight in the bounding box calculation that caused them to be incorrect.
This was especially noticeable for rotated objects which would not seldom get culled (and thus clipped) while still being within the view of the camera rendering them.

Clicking in or outside the render window while it is loading no longer causes the DX11 QUIT function to erroneously return true right away at the start.

Fixed a bug where setting the same state of a sprite two times in succession would overwrite a flag stating that the sprite needed to be updated with the value false (because it already had the previous state) without taking into account the fact that a previous sprite operation could require it to be updated still. This would for example sometimes cause sprites and text to appear blurry or in the wrong position.

Providing a string that only contained special control sequences, such as "[c=0xaarrggbb]" for colouring text, to DX11 DRAW TEXT, DX11 SET LABEL TEXT or DX11 PRINT TO PIXELMAP would cause a crash. This has now been fixed and an empty string is "displayed" (or rather not displayed) instead.

Fixed a bug where DX11 FRUSTUM CULL BB accidentally returned true instead of false if the bounding box did indeed pass the culling rather than fail it.
Also fixed the return type of this function; it would previously only work when assigned to variables explicitly declared as as boolean or as byte.

Fixed a bug where DX11 CREATE OBJECT SPHERE would fail unless its vertex layout contained an element with the TANGENT0 semantic.

Fixed a bug where orthographic cameras would not have their data properly initialized and as such could render incorrectly unless you would manually reset all of their data.

Fixed a bug where DX11 MOVE OBJECT / LIMB / CAMERA would not always use the latest rotation before carrying out the movement.

Fixed a bug where vertex data colours were accidentally stored as four floats instead of a DWORD.
This could cause issues where the erroneous colour data would overwrite any subsequent data (such as for example vertex normals) if the colour data was written after the following data.

Fixed a bug where DX11 CREATE OBJECT SPHERE and DX11 CREATE OBJECT CYLINDER generated some inverse normals.


Changes
I generally tend to try to keep compatibility with previous releases so far as code that worked with a previous version of the plugin should also work with a latter.
There have been some changes required to function names to better reflect what they actually do, as well as some that were found to be faulty (ie. the documentation listed their intended name but due to oversights they had a different name to actually use them from DBPro).
There were some example projects that needed minor changes to compile with these changes and as such you will find updated versions of those in the archive under the "Projects/DX11 Examples" folder.
There have also been some additions made to the DX11Constants.dba file, which also appears in the "Projects/DX11 Examples" folder, so I suggest that you use this version from now on instead of any older version.
The most important changes in this release are these:

DX11 SET CAMERA RENDER TARGET has been renamed to DX11 SET NEW CAMERA RENDER TARGET.
This was done since render targets can now be created without immediately associating them with a camera using the new DX11 CREATE RENDER TARGET function, so DX11 SET CAMERA RENDER TARGET is now used to set a pre-existing render target instead of creating a new one, as DX11 SET NEW CAMERA RENDER TARGET does.

The mouse cursor will no longer be automatically moved to the upper left corner of the render window when calling DX11 INIT.
You can still position the cursor where-ever you want using the DX11 SET MOUSE POSITION function, should you want to.

The number of available sampler states have been reduced from 16 to 12.
This was done to reserve certain sampler states for use with the lighting system. It is possible that some more can be freed back up for custom usage in the future but for now four are reserved for use by the engine itself. 12 should still be more than enough so no worries there.

The default orientation of objects created using DX11 CREATE OBJECT QUAD has been changed so that these will now face positive instead of negative Z.
You can still flip them around to achieve the previous orientation with a flag to DX11 CREATE OBJECT QUAD. In this way, the functionality now corresponds to that of CREATE OBJECT PLANE from standard DBPro.

The documentation has been updated to use the correct name DX11 GET IDENTITY MATRIX, which was previously wrongly listed as DX11 GET MATRIX IDENTITY. DX11 GET IDENTITY MATRIX has always been the callable name of the function.


Compiler patching and precompilation
The plugin now contains more commands and functions than the DBPro compiler recognizes (there are currently 1078 exported functions but the compiler only checks the first 1000).
In order to work around this I have included a modified MD5.dll file with the latest release. This is intended to go in your DBPro/Compiler folder and overwrite the MD5.dll file already present there (you may want to back it up first though!).
The effect of the dll mod is that it will get loaded by the compiler at runtime, at which point it is able to hotpatch the compiler's code. The idea was that this would probably be considered more legal than to patch the physical compiler executable on disk. The modded MD5.dll has been testes and found to work with the compilers from DBPro version 1.0.7.6 and U77. Hopefully it could also work with earlier releases (it uses pattern scanning to detect the value to patch) but I cannot vouch for this.
Now since the DBPro compiler has recently became open source, I plan on just providing my own rebuild of this in future versions instead. Unfortunately the rebuilt compiler won't work with the old 7.6 / 7.7 dll's though so I may have to bundle it all together. In that case there are some issues since the open source'd DBPro source does have quite a few differences from the old, well-known one, for the purpose of GameGuru development. I will look into what options are available here in the future, but for now the MD5 mod will work with the compilers included with DBP 1.0.7.6 as well as the RC for 7.7.

Besides patching the limit to allow DBPro to access more than a thousand functions from the dll my MD5 mod also does some precompilation on the source. This is used to allow the reporting of source files and line numbers by automatically appending this information to all function calls to the DX11 Plugin.
In other words, besides not being able to use the last ~80 functions exported by the plugin, you also wouldn't get any error line reporting if you don't use my modified MD5.dll library.
Just to clarify, there is nothing special that needs to be done to accomplish this; merely copy all the files from the attached archive to your DBPro installation folder and overwrite any conflicts.


Regarding the annoying splash screen...
If you have used any of the latter releases of this plugin you will know that it displays a splash screen for ~5 seconds before starting up. Every single time.
I realize that this gets annoying, especially when doing some minor edits and recompiling only to have to sit through it again. As such, starting with the current version (0.4.7.5) the splash screen will only appear if the executable haven't been run in the last 30 minutes. Hopefully this should reduce the frustration at it while still keeping it there as an identifier.



That should be the major points of interest for now. Further details can be found in the patch notes below (note that no build listed there since version 0.4.5.0 has been publicly released until now).
Work on the default lighting system, common shader libraries and the engine as a whole is ongoing (as well as plans for audio, physics and gamepad support in the future).
Thank you for reading and your continued interest

Changelog

Wow man, lots of good stuff here. I'm excited to play around with it hopefully soon

Cool haven't had much time to play around but compiled them to have a look, also tried them with new compiler used in GameGuru and they seem to work, some don't as some of the commands you use from matrix1utils won't compile, I assume IanM needs to redo them to make them compatible but thought I would mention it anyway, cheers

Thanks guys, hope you'll have some fun with it


Oh really, that is nice to hear. Since the final machine code of the compiler may differ depending on build environment as well as any changes made to the code I haven't really looked into supporting that. And again, the MD5 mod solution came about before the compiler's source was made available so in the future I will probably just use a custom rebuild of the compiler instead, so it should really be a non-issue, but still it is nice to hear that it works with the GameGuru version as well!


Yes, I encountered this when playing around with the latest DBPro ("GameGuru") source.
The problem is quite simple; apparently the old compiler would ignore any string table function names beginning with a character that isn't a letter (or so I assume; at the very least it ignores any function name that begins with a '!' character). Matrix1Util_32.dll makes use of this and prefixes some old function names like APPLY VIEW MATRIX with an exclamation point character as a means to "comment them out". The new (GameGuru) compiler doesn't recognize this and will instead fail upon encountering such a character however.
To solve this you can either modify the compiler source to account for such function names to be ignored when looking for available command names, or you can just edit the string table of Matrix1Util_32.dll to remove those entries.

Keep up the good work

I don't know the first thing about coding outside of DBP so I assume modifying the source is not as easy as editing the string table? If so what is the best free software to edit string tables? I only have the vaguest of a clue on what a string table is - having once many moons ago followed the "how to write a plugin" instructions I think by IanM. Also would there be any legal issue in editing the string table?

Edit - Never mind I have worked out how to edit them

Thanks Chris

@James H: Sorry for the late reply.
Yes, modifying the string table is definately easier. If you have Visual Studio, at least 2010 and later can edit string tables if you load a dll using it. A simpler solution still may be to use Angus Johnsson's Resource Hacker. It is freeware and intended to edit resource files of executables, to which string tables belong.
I cannot think there would be any legal issues in doing this for your own usage, though there might be if you spread it. After all, the string table's sole use in those dll's is to let the DBPro compiler know what function names to bind to what actual functions exported by the dll, and they're available in a very unencrypted and readily available format, so it isn't like you're modifying anything confidential. Since you still do have to provide the modified dll with your executables one could argue that it may be against some usage policy to actually alter the binary file at all though. In this case a recompiled compiler for personal use shouldn't pose any such issues.
But since IanM has listed the conditions of use for his plugin collection as simply "none", I cannot see this being a problem. It might still be prudent to ask him about it before actually releasing anything built using modified dll's though, as a courtesy if nothing else.

Oh hah, I didn't even read your edit until now. That's what I get for starting to type replies after reading half a post...
Glad you got it sorted anyway!


On the development front, things are starting to come together with the lighting system at long last.
Here's a video showcasing directional, point and spot lights with normal, specular and dynamic cascaded shadow maps in action:

Sorry for the poor block compression, that's what Youtube decided to throw on my 10Gb raw AVI file once it finally finished uploading...

There is still some work to be done, but as can be seen there is a pretty solid foundation by now
The temple and palm tree models in the demo scene were borrowed from an Advanced Lighting example since it's really hard to find any free-for-use media that has proper normal and specular maps; I'm not sure whether Evolved made said models himself, but all credits to whoever did for that. The statue is some example stock object that is all over the net and the circular thing I hacked together myself, which may be evident from its bad UV mapping.

Wow looking fantastic, I will be only to happy to pay for this when it is released, any clues as to a rough idea of the price?

The tree used is probably produced using Evolved's "Tree It" app which he made completely free some time ago

Awesome. My first thought before reading the details was hey that looks like advlighting! great work man. Let me know if you need any mapped objects / textures.

Any plans to work on PBR rendering for this,?

Thanks guys


Ah yes, indeed it is; that particular tree even features on his page for it. I wasn't aware that that had been made free, seems like a very nice program for generating better quality trees than TreeMagic!


That is a tricky topic. The original plan was to have it published by TGC as an official add-on for DBPro, but with their focus shift towards purely GameGuru and AppGameKit, as well as DBPro and all^* its official plugins going open source I don't see this being a possibility anymore.
Since it is definately made for this particular niche market these recent developments offer some unforeseen issues. I do have some ideas on alternative ways to see it released, though it is a bit soon to commit to by talking publicly about it before I have ascertained its feasability. Anyway, had TGC published it I would have assumed a price of ~60 euro (so ~65 USD or 45 GBP) for the finished engine. If I end up having to publish it myself we can take TGC's cut out of that, but on the other hand there won't be as much exposure without additional marketing costs. Also as I mentioned above I may end up having to do some additional work besides the engine / plugin itself to try to make it appeal to new users as well as the old DBPro veterans. But as a rough estimate at the time of writing, let's say around €60, although this is of course subject to change depending on how things will turn out in the future.

^* This was mentioned to be the goal somewhere by Lee, but it has probably not happened to 100% yet, if it ever will.



Haha thanks. Not quite; Advanced Lighting certainly has some extra tricks up its sleeve. But the plan here is to provide a standard, baseline lighting system that lives up to modern standards and which can either be used as-is (hence the term "default") or be extended as the DBPro programmer sees fit.
Among the features is that you can easily add the default lighting system to your own shaders simply by including the lighting library and call "ComputeLightingContribution()" from your pixel (or vertex, if you want per-vertex lighting) shaders. You can provide normals and specular coefficients sampled from maps or elsewhere to this function as you wish. There will also be versions that leave specular and normal mapping out for less realistic, simpler lighting effects. And if you want to further specialize the lighting effects you can write your own shaders that use the light source and shadow data provided by the Ziggurat engine as well.


I have no current plans for this, however as outlined above you can use the engine-provided data to write your own lighting shaders so it should be quite achievable in that way if you want to take a dab at it. It is also simple enough to provide the light source data to compute shaders for expanding the simpler engine input to a collection of more specific parameters. I cannot claim to know much about PBR besides from some overview videos but I believe this should essentially be enough to implement such a system. But currently there are no plans of including this as a pre-made thing with the engine itself anyway, it would be up to the user of the engine to implement this type of lighting.


I just may take you up on that!
I think some objects for a similar outdoors scene to that in the video above would be useful for including with an example project, should you be willing to produce that?

Yeah, I can put a few assets together across some different material types wood, stone, metal etc.

AdvLighting uses several channels in the spec map to control both intensity and hardness, are you using the same specular texture layout or just a flat greyscale?

Thanks a lot, I would appreciate that!
My specular maps are just grayscale images acting as an intensity multiplier. How would this "hardness" thing work though, maybe it's something I could add in if it adds enough visual effect to be worth it, at the cost of (I suppose) harder to make textures?

Specular hardness is also called 'gloss'

Specular power or intensity determines how bright / strong the shine is, hardness or gloss determines how tight / glossy the shine is. Typically high values makes a small hard edge pin point, low values spread the shine wide and make it matte.

Ah right, thanks for the explanation.
That is actually already in place but working off of a per-limb constant value so it should be perfectly possible to sample that from a texture as well

@Rudolpho

Thanks for creating this

anther fine expansion and update to the "DBP"

my computer being one of the best out there well maybe like 3 years ago no
did not slow down but the cooling fan did speed up just a bit but not as much as i have seen with
a couple of games have played

i would have liked it if the two other examples you showed
would have been included but given enough time i can create my own

Again Thanks for Making this

Thanks for your kind words, and you're welcome


Are you talking about the lighting example videos?
These are just there to showcase what I'm currently working on and so this functionality isn't in any released version of the plugin as of yet. It is planned for the next release though.
As for the other examples they should be included, albeit sometimes with some changes. When recording a video I'm usually writing the example program in C++ first (not uncommonly before the DBPro plugin gets updated with the relevant functionality) and then porting it over to DBPro as an included example project once it is finished. In this way I have a better overall idea of what the purpose of the project is and it helps me to write better comments in the DBPro version. It also makes it easier to spot and think twice about things that may be different between the C++ and DBPro versions.

Wow, this is a godsent. Thanks Rudolpho!

If we use this plugin, will we be able to develop Oculus Rift plugin too? (as Oculus abandons DirectX 9 already)

@Rudolpho

a couple of things i noticed when running the examples

they all seem to open up in separate window
which shows it's edges .. thats one thing i would like fixed up

the other is there is no example of for fonts
being able to pick which one and setting the size

all the example run fine and do not crash on my system even pushed to the max
the fan on the system dose speed up but we know that's to be be expected with all the things going on

any possibility of posting the lighting example ?

Thank you
Interaction with Oculus Rift, or other VR equipment, should certainly be possible.



Hm, how do you mean the edges are showing? Can you perhaps post a screenshot of this as it isn't anything I have seen?
As for the separate window, it is intended to render to its own window. Normally you would hide the standard DBPro window (this is tied to the D3D9 surface by default). It might be possible to attach and render to an external window in a future version but this isn't planned as of right now.


You're right; there are several more examples that could (and will) be made in due time.
What you're mainly interested in for fonts is the DX11 LOAD FONT function. You will give it the file name of an image that contains a font sheet and some further parameters that describe what ASCII code characters the font sheet contains. The size will be determined by the font sheet (technically the text printed using a font could be resized but this would cause loss of pixel quality; thus it makes sense to provide font sheets with the appropriate sizes to begin with). A function that could create a font sheet from a system-installed font wouldn't be a bad addition though, I'll add that to my list


That is good to hear


That will be included with the release of version 0.5.
There are still some things to be worked out for it (mainly another shadow mapping algorithm alternative and per-object/limb material properties), as well as writing some example projects and documentation. Hopefully it will be ready to be released in 3 - 4 weeks.

@Rudolpho

umm when it comes to the text and the size
loading up the font as it sits and picking the size
would be a how i would do it if i could

font as a image file would need a function to help place them
just food for thought

here is what i see when i run an example

Nice work as always R. Looking forward to seeing the examples in particular; there is a lot of functionality in what you have constructed; the examples will make the functionality much more simple to understand

@Resourceful: Hm... judging by your screenshot, the explorer window in the back is unresponsive. May this be the cause (unresponsive windows don't redraw and as such the background of the render window may not be updated)?

@Chris: Thanks, I'm hoping so!

@Rudolpho

despite it saying that the program showing it is not running it is

what i learned is that the program DBP runs is told to hid the program window it creates

then it's told to open up a window just for DX11
but without the minimize and expand to full-screen buttons at the top right corner

that's what the arrows are pointing to

Oh I see.
This can be changed using the DX11 SET WINDOW STYLE function (a window style argument can also be provided directly at startup to DX11 INIT).
There is also a helper function, DX11 BUILD WINDOW STYLE, that can be used to create a style (which is just a collection of bit flags stored in a DWORD) from a few, commonly used boolean flags.
It is used like so:

@Rudolpho

thanks

umm how come your plugin opens up a completely new window ?

i know the DirectX that DBP is built on is old
but i would have thought it should run from the window program that DBP made

things definitely run fast and there is a lot more that can be dune
but with all the other plugins that i have
i do not know if i will be able to use them with this

and i have a long list of pay and free plugins installed

This is mainly because my engine isn't dependent on DBPro; it creates its own render window to facilitate this.
It is also more appropriate that sole ownership of the window belongs to the plugin so that it can do as it pleases with it (sure this would be possible with a captured window as well, but it feels a bit wrong). Thirdly, DBPro attaches its D3D9 render surface to its own window. Now imagine that you were to try to render to it using both DX9 and DX11. Probably the only thing that would happen is that one of the surfaces would overwrite the other but still. There may also be situations where you want to render using both DX9 and DX11 side-by-side; I've used this to debug some transform errors in my engine for example. Though I imagine that functionality would be less required by others than to me as the engine developer.
But first and foremost it is to do with the fact that the engine is independent on DBPro such that it should be possible to use it from any language that can use the dll sometime in the future (C#, Java on Windows systems, etc.).


This is indeed a bit of an issue.
What you must realize is that this isn't so much a plugin to extend the functionality of DBPro as it is a completely new rendering system to replace the old one. As such there will be incompatibility with multiple other plugins that have been designed with "standard" DBPro in mind.
As I wrote some months ago in this thread any plugin that depends on core functionality of DBPro (such as objects, images, memblocks, etc., or the Direct X interface itself, like BlitzTerrain) will not work with the DX11 engine. Plugins that don't depend on this, like (most of) the Matrix1Utilities collection or DarkAI will work with it. Basically if it depends on interacting with the Globstruct of DBPro it will have no effect on my engine. Plugins like BlueGUI should technically work as long as you manually tell them to use the DX11 window instead of the "main" DBPro one.

I am also adding in some functionality that corresponds to what other plugins do for standard DBPro in the Ziggurat engine itself. For example it already has comparable functionality to the official plugins Enhanced Animations and DarkShader built in. Physics (akin to the DarkPhysics / DarkDynamix plugins) will also be added directly into the engine. And of course you get various things not available directly through standard DBPro like texture arrays, hardware tessellation and the built-in lighting system.
Once things start to finalize a bit I also intend to provide a means to obtain the internal data of my engine to third party dll's, much like DBPro's Globstruct pointer, such that extensions can be developed for it by others (or indeed, if their authors are still around and interested in doing so, porting their already existing dll's to work with the DX11 engine).

But would they work in the DBP window? Or does the use of the DX11 plugin prevent doing things like loading a terrain in the DBP DX9 window to be converted into a vertex array in order to load into the DX11 window.

I perfectly understand why the DX11 window is different from the DX9 window, but can they work side by side? I would like to try to use vanilla DX9 commands for an editor and some physics, and the DX11 window as a viewport. I hope that the question makes sense.

Oh yes, running them side-by-side like that should be perfectly possible. You'd end up with some duplicated data for meshes and textures since the DX9 and DX11 engines will require their own resources but that is the only issue I can think of with such a setup.
What I meant is that you cannot expect for example a physics plugin to work with my engine out-of-the-box since it will look at DBPro's mesh data rather than mine and such things.

The viewport idea is actually quite intriguing. It should be possible to capture the window, change its styles to remove frames and borders and such and attach it as a child control of another window to fit it into a panel for example. I haven't tried this but I can't think that it shouldn't work. Might make for a nice example project actually

Id be very interested in this for c#! I've tried SlimDX but it is a little too bare metal for me. What's so nice about dbpro is how wraps up all the nitty gritty of DX into an easier, higher level command set

True that.

I can honestly see myself purchasing this plugin to behave like a viewport and a DX11 graphics option; it being in a different window is actually perfect for me. What would be useful is to return the window handle from the DX11 plugin, otherwise one will have to run a window search for it in order to parent it correctly to the DBP window or other window.

With my setup, PhysX runs in its own 'virtual window' in anycase, so it wouldn't matter if it does not interact directly with DX11 objects; PhysX does not control my client objects in DX9 either, much like Dark AI; most of all the game mechanic physics takes place on a server. I just need to learn the modern shader models to make the transition more of a benefit for the players.

If Ziggurat(DX11) and DBPro (DX9) can run side-by-side (DX11 as viewport) , I wonder it's possible to:
- use DX9 for some part (3D object control, memblocks,shaders), game logics that was developed previously in old DBPro
- then render it to 2 camera for VR
- and then DX11 transform the 2 camera into s screen for Oculus Rift.
- then use positional tracking from Oculus and feed it back to DX11. And that data should be free for both DX11 and DX9 to use

Just speaking out loud to myself

Nice video Rudolpho!
Ive recognize Evolved's scene with palms))
Your work is really outsatnding and future capabilities of Dx11 looks very impressive ( tesselation and instansing )
Dont you won't to create something like kickstarter project or personal site where people can donate you? I mean that DBPro now is like underground - there is no support or updates and there is no hope that GitHub version will
evolves in something new.But there is people which are still interested in language which is easy to code.I mean that there is people to whom Unity and Unreal is too much complicated to go in for. So fresh DBPro on Directx11 will
be good resolve for them. Still you have to add many things, which DBPro already have ( memblocks , vertexdata edition or PhysX ) - thats why I told you about some ways to donation and as a result inspiration to continue your work.
It maybe is possible now because DBPro became opensource - so you can create its modifications ( I mean Its would be legal )
Anyway - good job here! Keep it moving!

Agreed; donations are a good idea; I was just thinking about donations and your plugin earlier today.

You can even aim towards streaming on Twitch to attract attention and get some community support. I am not a KickStarter fan, but if KickStarter really is beneficial, then by all means go for it.

How goes this plugin?

Thanks guys, it's nice to see this thread attracting some more activity again

I had never really thought to use it as a separate viewport solution of sorts, but as said that is an intriguing, and presumably perfectly plausible, prospect. I may have to re-evaluate some decisions in light of this, haha.


Of course, I have added a function for retrieving that in so that I won't forget to do it later; it will be in the next release.


That is indeed an intriguing idea! Is this mainly done for logical decoupling or is it so that you can use lower resolution meshes for physics calculations? Also are you using PhysX directly rather than through a plugin like DarkDynamix (maybe even through another language than DBPro)?


Such interactions should be possible... however, do you mean to render the 2 "eye" cameras from DX9?
If so this isn't supported by DX9.0c that DBPro runs on by default; however using DX9Ex this can be done through shared surfaces. I actually have a rebuild of the GitHub "Game Guru" source of DBPro, modified to run on DX9Ex. I made this by request of StarWraith 3D Games so I will have to check in with Shawn, but maybe this could be released to the general TGC community as well. However, as you may be aware there are some changes with the "GameGuru" source that breaks compatibility with the older DBPro versions. We've tried to fix all such issues that were found but I'm sure there are still a bunch of them in parts of the code that SW3DG just haven't had any use of so as to discover them yet. In any case, using this then yes, it should technically be possible to set up a shared render target that can be drawn to from DX9 and then funneled to a VR device through DX11.

You could of course also go the viewport route and rebuild the scene using DX11 and draw that directly to your OR. The positional tracking shouldn't have anything to do with either DX version and as such be possible to use with either (ie. both DX9 and DX11; it will just be a set of values available to your DBPro code in general).
Of course I should say that this is all just theory so far as I haven't really had a good look at the Oculus SDK yet (and as such there naturally isn't any functionality supporting this in my plugin *right now*). I intend to add such suport further down the line, though I will have to get my hands on the actual hardware for testing before being able to do so.


@Kuper: Thank you for your support
I have thought of making a website for it; in fact my signature already links to an external page that I intended to set up sometime; for now it just redirects back to the first page of this thread however. The thing is that then I would have to spend a not insignificant amount of time building a website, which is time that I could've instead spent on the engine. So I've been putting it off until I have something a bit more complete to show off. Of course I guess I could just set up a Wordpress or so; that would remove most of the work with actually building a website from scratch. As you may have noticed I'm not super good at posting regular updates though, which I feel would probably be expected by someone visiting such a site; at the very least some kind of development blog and maybe even nightly builds. Not that I would mind to write such a thing but it feels a bit stupid if it would end up with entries like "kept butting my head against the wall today" and similar as is wont to happen every now and then
But yes, maybe with version 0.5 out the door I will see about setting something up. That said, there is a rather niche market for this project and it feels rather more likely the interested people would find it through this site than a random website they'd have to end up on by accident; I certainly cannot afford any kind of marketing campaign at the moment.
For that a Kickstarter project may not be a bad idea though as it gets it out there so that it might catch the eyes of people through random "projects of the day" and similar. However, I feel like Kickstarter rather expects you to be pretty much done and just have some finishing polishing left to do before putting a project up there for it to be taken seriously.
Donations would always be welcome though; I may look into ways to accept that in case someone would be interested in helping to speed up this endeavour through funding.


Yes, the plan is to eventually try to replace all of these things from standard DBPro. For now there are buffers which work rather like memblocks, though they are all meant for communication with the GPU; a CPU-only buffer type (like a memblock) would be a nice addition to have.
As for vertex data editing this is already supported and is in fact used in the foliage demo to manipulate a high-resolution segmented plane into the terrain object. Physics will be another large scale addition like the lighting system and is planned for version 0.7 or 0.8. I do intend to use the PhysX library for this.


Haha it is interesting you would put it like that. I rather see those two as taking over and putting game development in the hands of anyone through being free to use, very high quality and essentially drag and drop and "go to the asset store and buy some pre-made scripts!" as the solution for anything that would have been a programming problem. Still, I hope some of us still prefer to do the programming more ourselves! In my mind Unity is trying to make my line of work more or less obsolete and relegate me to a "scripter" rather than a "programmer", should I develop games using it.



Hm that is a novel idea... There isn't that much to show off yet though, and people mostly look for fancy graphics (which isn't really my forte). Or should I post eight hour sessions of me coding? Haha.
But as you say, attracting attention will be necessary some time in the future and that may not be a bad way to do it, free and all. Thanks for the suggestion! And also thanks for supporting the donation idea.


It is coming along, slowly but surely.
As of late there are some periods when I have less time to put into it and then there are others where I have more time for it so the progression can be a bit unpredictable. I am currently adding in some finishing touches to the lighting system and material property support for hardware-instanced meshes. Then there are some nice-to-have features also being added in like the possibility to save and load precompiled shaders for faster loading. The shader system is also getting a bit overhauled, allowing inclusion of other HLSL source files and manual object draw order sorting for proper drawing of skyboxes and such things. The main (lighting system + material properties) functionality intended for version 0.5 is functional though; it may need some polishing and optimzation here and there but the fundamentals are in place and working.
As for the future, the next planned step is to add sound support.

A little bit of both, DBPRO compiler complications, aswell as other concerns.
Lower resolution meshes for physics just makes sense (Having more than one object pool reduces object search times).
It's the only way to communicate and manage the physics (and AI) with a different core/cpu, and the only way to use more than 2GB of RAM with a 32bit game.
If the user selects different rendering methods (EG: DX9/DX11), the game continues.
If the rendering crashes, the game continues, with a new render initialized.
If the user is hosting a game and does something performance intensive on the frontend, the performance of backend is not affected.
When the rendering program loads new geometry as the player moves through the world, any FPS drops never affect gameplay timing (Although the rendering lag will be visible, the actual entities are moving and where they aught to be)

Stuff like that.







Quite a debatable subject; the vast array of free video game templates and prefabs makes for an easy or difficult life for different types of video game developers. Quite interesting to also see many 'AAA' titles are being created in such tools.

At the end of the day it is as much about the developer as it is about the tool.

The players are a lot more knowledeable about what to expect from the developers, you just cannot get away with BS. The players can tell whether they are playing an original work of art or a cheap reskin. This issue came to mind recently with work on my game audio; I once considered using royatee free audio, but there comes a time when one can recoginize the original source of audio, music and graphics in other games.

After hearing a number of songs and sounds, and seeing some royatee free graphics in my library used in commercials, games and events; I think the audience having spent 10 times the amount of time I have spent experieincing such content will be more sensitive to determine the source of what they are experiencing.

And then if you make a nice small game, some of you fans might put together quick 'clone' or 'fan' projects which turns out to offer quite the same, if not a better experience; thus the competition becomes fierce.

This would seem like nonsense to certain ones. There are creative ways to use such tools to avoid being unoriginal (as state earlier). Difficult to create concepts can still be cloned by some. I am grateful to be able to play some of my favourite games which where made with such tools. But I also have to skip past a few 1000 clones to find them.

The same is true in the movie world, with netfix and low budget high quality video templates and cameras; there a so many low budget films to compete against now that it is easier to make them.

But keep doing your thing, I am sure we can all help draw attention to the plugin by using it and crediting in our games.

Ah yes, I see. That is quite clever and akin to the idea of running physics simulations on a different thread (and commonly higher framerate) than the rendering for the purpose of mainly a smoother simulation and being independent from rendering-based lag as you mention. Nice gravy with the other aspects too, though hopefully one shouldn't have to assume that the rendering portion will crash during runtime...? I suppose it could happen if running out of video memory though; I've found out that it is annoyingly difficult and there are no standard ways of finding out how much VRAM is free across different cards.


Regarding Unity that may have come across a bit wrong on my side. Certainly it is a great engine and in the hands of the right people it is indeed capable of creating very different types / styles of games. The scripting system is excellent and provides pretty much anything you'll ever need to alter any aspect of your game to your liking. It also has great support and a low learning curve, at least to start out, since as I mentioned it doesn't really require much technical know-how at all. In fact Unity was famous back at my university for just taking whatever you threw at it in regards to media formats, which greatly pleased my modeller friends. And of course made them quite annoyed with me when I had them go through three different pieces of modelling software to export a functional X-file
Ultimately the availability of such tools for near-zero investment cost is making most people move on to and advocate said engines. Which is of course perfectly understandable and in a way to be looked at as something positive; they are certainly more stable and powerful than what you could come up with with your own small game development company and also takes away the need for making the more technical, low-level and ultimately not very game-related details at all, allowing you to put all of your time into actual gameplay-related development. Now for myself I quite enjoy being able to make the foundation myself too however. Because of this and the fact I'm well aware I could never match the AAA-engines out there it stings a bit whenever I'm told to "give up on it and just use Unity". Sure I might be better off doing that for a lot of projects but for me personally this grounds-up approach is more fulfilling. On the plus side of things this means I attain some skills and knowledge that fewer and fewer game developers who use pre-made engines do these days, which should give me an edge while looking for jobs. But in an age where most people judge a game by their visual quality and frame rate alone I will of course never even qualify to be judged along the thousands upon thousands of new indie game developers using the awesome tools available to them. That's not to say I'm bitter about the situation; just trying to explain why I tend to get annoyed when comparisons to these giants are being made. Of course the fact that game making is becoming more available is a good thing.
On a side note I kind of wish that Unity did what UDK does and would provide you with the full source code for the engine on purchase, to tweak and learn from as you will.


As for my engine here of course I intend to finish it, so no worries on that part
It will probably be a bit difficult to create more than a niche market for it amongst old, nostalgic DBPro users since DBPro itself isn't really attracting more users at this point, and given the availability of such more readily accessible alternatives won't really make it viable to the greater public. Much like DBPro ended up doing I believe the target audience would be people who are interested in learning to program in general, using the game creation as a carrot for this. As I mentioned before I have some ideas for this and we will see how it turns out; I want to finish the lighting, audio and gamepad input devices before exploring these things in earnest though, but hopefully it'll turn out to be viable.

I understand what you mean. I also like to do my own thing, to learn more by developing my own shaders and gaming functions, but not too much low level work to the point where the whole project is spent working in the programming IDE, and not enough in design and play testing. This differs from your work which I feel is more technical.

What you say about people telling you to' just use unity' reminds me of what people try to say to Bert Monroy about his hyperrealism photoshop art, they say; why spend two years making a realistic painting in photoshop, when you can just take a photo in a few seconds? His answer is that it is not the end result that counts, its the steps inbetween which matter, teaching himself techniques along the way which can be used in commercial work. Not to say that there is nothing to learn in photography, but there is much that can be learned from other forms of hard work. This principle is good for game development aswell, most of my work would be impossible without me learning the seemingly 'unnecessary'.

Well I personally hope one day the gap between AppGameKit, GameGuru and DBP is reduced so that what you create in either tool can be automatically converted for each other, with the exception of incompatible features. A single product, use the language you have invested your time learning, bringing the community back together in one piece to make a stronger stance against Unity; not spreading things thin with three seperate tools; and in the most extreme case if things have to be seperate, make sub-products as extensions or content libraries so that all invokes and supports strong brand. I will have to keep dreaming.

So I commend you for sticking with your work. I look forward to making a DX11 mode for my game. I have purchased other engines for DX11 via .NET, but would prefer to use your plugin since it is closely linked with DBP, and is good for shader development.


Indeed on should not. Sadly image memory crashes are quite common; just because one object or image fails to load, the whole application has to be closed. I can't have someone playing a 5 hour game only to have all their effort wasted by such a crash; although there are also other measures made to preserve the player's accomplishments.

Excellent job Rudolpho.

How likely is to have this working on Dark GDK? ajem

Well said Chris.

That would be something indeed; I have to admit that the diversification into different and incompatible products is a bit weird. It probably stems from there being lots of legacy code that is reusable for GameGuru but that obviously won't apply for AGK. I also feel like AppGameKit is trying to change the language a bit from the DarkBASIC syntax we're used to. I can only guess at the reasons for this but in a sense things like there being uniformity in function names between user functions and core / library ones (such as how in DB you can have function names with spaces, but your own functions can't) probably is for the better. It also is a step along the way to approach other languages with its somewhat more "standard" (C-like) syntax like "if(condition)" instead of "if condition". I must admit to hardly ever using AppGameKit beyond playing around with it a bit some years ago, so I don't know if it does but if it fixes things like DBPro's "inverted" logical and bitwise operators (compared to most any other languages) and having a separate operator for equality and assignment ('=' vs. '==') would be very nice changes. Of course, if you know the older syntax by heart it comes with a learning curve, but it should still be easier to adapt to than straight into something like C (or Java or C#, but those are naturally even more different with their strong object oriented model).
The missing link is of course updating DBP to this new syntax. I suppose the goal is that AppGameKit will one day be capable of as much as DBP but it looses out heavily since they have to mind the lowest common denominator with the mobile development - whether that is the future market for indie games or not, it is still nice to be able to use the raw power and capabilities of a proper PC/graphics card combo for your games.


Ah, are you referring to DBP's heinous standard error management?
That terminate-on-failure approach is definitely something I would see replaced, even though I use it myself in my engine for the time being. In time I hope to present a replacement system for it that will allow the programmer to recover from non-critical errors without the need to restart their application.


Thank you
I don't know if it will ever work alongside DarkGDK; it was never intended to do this.
Its C++ interface is however quite akin to an object-oriented DarkGDK. Unlike the DBPro interface which can be kept relatively stable between releases, the underlying C++ classes change a lot over time though so I don't think I will release it in that for for a while yet.
As mentioned the original idea was essentially to create an alternative, albeit similar engine to the DBPro one to replace it rather than co-exist as such. The recent realization that there may be merit to be able to run them side-by-side means that I may have to re-evaluate the purpose of the engine a bit however. Naturally running my engine from the same program that runs DarkGDK shouldn't be a problem and like Chris outlined previously, capturing the window of either process to merge into another window as a viewport would use the very same process and as such be possible in either case.

I've also got my copy of AGK; the first version. I have a few ideas for some apps for accessing information about my game; but I have no plans to use it for general game development.

Just been prompted by Chris Tate to have another look at this.

Wow! You've achieved a lot since I last checked and that cascade shadow mapping video was fantastic - makes my attempts at shadow mapping look very amateurish. I'd definitely buy this when the time comes. Keep it up.

Edit

Just tried the latest download - and nothing works now. I get an error message which says DX11 does not exist on this computer - but it does and certainly did a few months ago when I first tried your examples.

I then tried the earlier version which was still on my PC - but that was time expired so I tried redownloading the earlier version and I keep getting syntax errors. The first error is on line 1 - which uses the rem command!

Any ideas what could have gone wrong?

[Actually it seems I've screwed something up somewhere since nothing compiles - not even my programs. Looks like I've accidentally overwritten something essential. Looks like I'd better start again - with everything, starting with a reboot.

It's been that sort of day. I was struggling getting Visual Studio to work earlier. ]

Thanks GG!

That sounds odd... the only thing I can think about would be if you have DX10 hardware and some DX11-exclusive function call has snuck in without me noticing it that will cause issues in backwards compatibility mode. To rule this out you can call DX11 INIT with DXVERSION_11_0 - if it isn't present you'll get a popup telling you so and that DXVERSION_10_0 will be used instead.
Given your edit it sounds like something else is acting up and may very well be the source of the "DX11 does not exist" issue as well. Is it possible that you managed to uninstall the DX11 drivers (check with dxdiag.exe)?
The errors on line 1 (or 0) reported by DBPro usually means that some auto-injected code by the compiler failed, such as setting the display mode or creating the D3D interface. So this again can hint at DirectX drivers possibly being missing / corrupted. I would probably try reinstalling those if the reboot doesn't help (I suppose it could be a RAM error (not good) or simply previous memory leaks or exhaustion (harmless after rebooting) being responsible if it does).


Those days are... something yeah.
As for me, I had the brilliant idea to make a gizmo tool for easier realtime transformations of 3D entities in my test projects. Should be quick and easy right? Still here I am with it yet unfinished more than two weeks later...

Dxdiag.exe says I'm using DX11.1 - see image attached. Is it possible that I accidentally flipped a DX10 vs DX11 switch while I was experimenting with Visual Studio?

Incidentally, I've just tried again and your error message refers to DX11.0 whereas I have DX11.1. Could that be an issue?



Me or my laptop?

Edit: As an experiment I've just tried running some Visual Studio DX11 tutorials and get loads of error warning messages such as:



It's just possible I last tested your demos (successfully) before I upgraded to W10 from W7. Not sure though. Sounds like I need to source that SDK or something.

Rudolpho - would this of been any use to you? https://forum.thegamecreators.com/thread/199163

Green Gandalf - you once did a demo of transparent shadows with just a plane with a tree on it and a number of spheres moving around the scene in an orbital fashion, I don't suppose you recall this and have a link to it? I can never find anything with the new forums search tool.....Regarding dx11, it requires windows 8 x64 to run so I doubt you ran the demo's before you switched to windows 10. This is just a stab in the dark but could it be that the vcredist package is needed? I only thought about this as its something I needed for Battlefield 4 even though I don't currently have visual studio installed and it also happens to be a developer requirement.

I guess you mean this. Took quite a while to find that. I miss the old search facility too - and the option to look at a user's threads.



This is getting embarrassing - see my earlier post here.

I obviously need a brain transplant. The really stupid thing is that I had to trawl through my old emails to discover this.

I'll check out the latest demos carefully tomorrow with a clear head.

Yes thats the demo, thanks very much At least you have things sorted now which is the main thing

@Rudolpho

now that you have created DX11 plugin and basically switch off
a large part of the physics engine's and related plugin's

it would be a thought to contact "Stab in the Dark" and get him to move
the 3d physics over to Direct x 11

It shouldn't be no, DX 11.1 and 11.2 just add some small features on top of 11.0, meaning that anything that works with 11.0 should work the same with the latter two. Since 11.1 requires Windows 8 and 11.2 requires Windows 8.1 (or later) I'm not explicitly targeting those so that as many OS:es as possible can be supported.


Hah, good one!


A flag value of two means to load the debug layer, which requires a separate SDK to be installed. I'm not sure about how compatible this is with Windows 10 but I can't imagine it shouldn't be available. Or you can just remove the "2" flag from where you're calling D3D11CreateDevice.


I was actually looking into using LibGizmo at first, which Aaron Miller suggests was used by that plugin. However its license seemed to indicate that it was free for personal use only and as such probably wouldn't be fully legal to put in my engine because of its redistributable nature. Because of this I decided to write my own system. No worries though, it is almost functionally complete at this point in time (though it could definitely do with some shaping up and tweaking). Currently I'm mucking around with the non-essential feature of drawing arcs to indicate the current rotation.


It doesn't; DirectX 11.0 runs perfectly fine on Windows 7 and can even be used with Windows Vista if you have the latest service pack and hack around a bit.
DX 11.1 on the other hand requires Windows 8, though I'm unsure if it has to be the 64-bit version (albeit realistically speaking, who would use a 32-bit system in the days of Windows 8 and beyond? (not considering Windows Phones, tablets and the like of course)).


I certainly do too; why on earth would they remove that?
Out of curiosity, is there even a new search facility? I've been using Google with "site:forum.thegamecreators.com" which is... less than ideal.


Ah, was that it then? At least easily solved and the error messages would make sense then!
But yes, that sounds like quite the annoyance to have to switch back and forth between the cards and remember which one to use. Maybe I should add a function to show the name of the currently used graphics adapter (or let you choose one for your program without having to change the default one for that matter).


Should he be interested in that then by all means.
Otherwise I did ask Matty H a while back; he sent me the source for DarkDynamix so I have that to start from once I get to the physics.