Closed dotprodukt closed 8 years ago
Sorry for late reply, this is now merged, thanks!
Awesome! Thank you. I'm relatively new to writing for vvvv but not computer graphics. I have much more on the way if that's alright.
Hey sure, always cool to have some help around, was actually looking at improving quite some bits in runtime too, hopefully finally make the move to sharpdx one day ;)
I would definitely agree that a thinner wrapper would be best but there's also an extra bit of complexity in lifting some of the responsibilities from slimdx into this library. The sooner it happens the easier it will be. Not on the top of my list but I would be down to help with that if you start a branch for it sometime in the future.
I already got a sharpdx equivalent, so that work is pretty much done (actually my sharpdx runtime is much more advanced/complete than this one), after ideally would like to have as much standalone routines as possible and nodes just to be thin wrappers around those (which is the way my own tool works), and one day to have this plugin interface to move out of slimdx (to avoid this 32/64 bits build), but that side is on 4v guys and I don't see it hapenning anytime soon...
local includes are handled in a way that is more consistent with what is expected from C style includes. Local includes are first attempted relative to the file they are being included into, followed by relative to the origin shader file, followed by the system include path.
Push of relevant changes to dx11-vvvv pending.