Last DX11 Release...

Using SlimDX ;)

http://vvvv.org/blog/directx-11-beta-31.2-update

Beta31.2 marks a little history as now the plan is to make a full move to SharpDX.

Some people might ask what is the benefits, or if I'm some kind of masochist who like to redo everything again :)

First, a move to SharpDX sounds like the smart option so far, and offers quite a few cool bits:

• It's quite actively maintained
• Support for DX11.2
• Generally API calls are better for performance
• No more dreaded 32/64 bits builds

And now I'm not rewriting everything, but I feel a lot of things which are already nicer than in old DirectX9 can be done in an even smarter way. Some years of programming in DX taught me a lot as well, and there's definitely some parts that I'm looking forward to improve or rework.

On a first note, writing an API is hard, it takes a lot of time, trial and error, to find a decent compromise between performances/features/ease of programming. So far I consider the first round as a success, there's still a few bugs/features missing, but hey, I'm more or less on my own writing the core, even tho I of course want to thanks people who contributed nodes/shaders ;)

So besides moving to SharpDX, there's of course many plans to improve what is there, in no particular order.

1/Wrapper

New wrapper is almost as fully featured as previous one, but has quite a decent amount of improvements:

• Clear separation between Device/DeviceContext (multi threaded rendering in mind).
• Resources are much thinner and much less abstract class/overrides, which should decently help where sometimes it was just a right pain to link 2 elements.
• Now most of the runtime (not finished yet), is unit tested. So I can quickly see if a change breaks resource creation, pool... This is such a time saver.
• Resource also have much easier to use creation methods, copies are much more streamlined (only one method to copy to dynamic texture now.
• Wrapper will mostly manage many addons too (vlc/kinect/geometries...) so most of this can be independently tested in a much cleaner way.
• Input layout handling is still one of the area for me, it's a bit of a pain to find the right model (for a game engine you can safely build a small hash, but in 4v case, there's so many permutations that it's really not easy).

2/VVVV

Now on the vvvv side, there are also quite some (drastic) changes on the main core. Please don't be afraid as a patcher, on your side it shouldn't be any change.

Death of multi device. Having to handle resource dictionary per device sucks (pain to do anything thread safe), it never got used , and single device works on multi graphics card anyway (tested on a decently fat project). Maybe there's a 0.00001% scenario would pop up where it has a usage, but to be honest I prefer to ease the pain of the 99.9999% of other people ;)

That will mean some performance improvement (specially for large patches) more streamlined coding (less mess up with interfaces).

Layer system is also getting a little improvement, with better stacks for camera, reserved cbuffers, easier rebinding.

Scheduler improvement is also on the way, and small Task based rendering is an area I'm actively looking and experimenting.

3/Shader management

That's the main area where I want to work on, I find shader management in 4v sucks at the moment, you have gazillions of little pieces of code messing around that you can way too easily modify.

Not that modifying shader to fit you needs is bad, but it's just a pain for standard ones. That involves 2 big changes.

Shader package:

basically you have a pack folder and you can compile a library with the following:

• Precompiled shaders (namespaced as in folder structure)
• Json content file

So instead of having 200 shaders lying around, you can pack all that lot and easily distribute.

FX Projects

I always found FX projects to be a bit of an issue (an fx project is just a single file, so technically it's not even a project ;)

Also having an extension for each shader type gives some limitations (you don't want to give 50 extensions, but you still want to allow to give a shader a context). Context is for me what is the most missing in vvvv, most stuff is just... stuff.

Giving context to a shader, as selecting host via gui, would allow to create different ways of interpreting it (geometry generator/particle emitter....) in a much easier way, improving quality of contributions.

Ah and on the loop, shader will compile in background, no more massive freeze when you press Ctrl+S on this big fatty compute shader blur :)

I'm not sure if this one will be ready for first release, but it's definitely on decent priority list.

4/Shader API footprint

When you batch like a nutter, Shader API footprint doesn't matter much (you end up <100 draw calls anyway).

But now with compute you can also easily build data structures and manage a decent amount of logic directly in your gpu (on our last project we ended up having most of the processing hosted in there).

So API footprint starts to make sense again, specially on compute side.

There's already some prototypes/experiment done on that side, stay tuned, it rocks believe me ;)

5/Be high (No connotations with any type of substance... )

For now I consider 4v to be fairly low level. 

First part of the plan for DirectX11 was to build a backbone to have people getting used to it. Plan to have high level nodes was always there, but it's not that useful without a decent backbone, now time is getting there.

Many more high level nodes are needed, where people can really do things out of the box.

• Deffered Renderers
• Better Light equations
• Easier to use materials
• Pluggable particle systems
• Geometry processors
• All that wrapped in proper plugins (sandboxed) to also ensure quality API usage.

Some people will claim that it's less tweakable when you sandbox, but for many users they don't write shaders anyway, so some defaults where you can do quality rendering is one thing that is definitely needed.

Resource management, Smart ordering is where normally most user will fail, so giving them a decent start up is not a bad thing (and of course you still have access to the low level API if you feel up for it ;)

And please note that if you want to contribute you are more than welcomed, since doing all that lot takes time and I'm more or less on my own, and I also do projects ;)

That includes mostly:

• One person to help manage GitHub/Builds (really that would be god send)
• People to do help patches/examples
• People for writing some nodes (even tho with new system it will be a bit different).

So that's it for this post, would say, one chapter closes, one new chapter opens, exciting times ;)