Closed mrvux closed 10 years ago
On some parts, please note I plan to do cross development for that (eg: I will not stop to improve/fix current version), but obviously for a certain period of time that will be slowed down a bit.
Is it possible to still use Feraltic as a layer like in the proxy pattern and move to native DirectX C++ API ? If yes, for sure, using the custom wrapper option is more expensive at the beginning, but will not slow down development, at least there is a really big project like SlimDX that can add all the support we need.
Another issue I see is the very low "bus factor" in DX11 vvvv implementation as well as in girlpower: we need more people contributing and mantaining. I hope unlocking gittip could help if there is even a small amount of dollars per week, since it is a very time consuming task.
I'm very interesting in maintain and implement regular solids and tesselations, but I need time t get practice with DX11.
the c++ route will probably be not so attractive to people..as you already mentioned. vvvv is all about c# now, therefore i'd vote for sharpDX to give this project a chance to broaden the developer base
@fibo : Yes in that case idea is to use my c++ version of FeralTic, and have a managed wrapper for it (so only the top core is c++), Ideally if I keep some decent naming it would even help quite a bit porting over nodes. I will provide native pointers (as IntPtr) so using SlimDX/SharpDX in nodes would be possible (probably some extention methods could even make things quite easier too).
@wirmachenbunt : I agree with that, idea is not to rewrite the whole subsystem tho, only the really low level part and provide a managed wrapper for it. So for end user (eg: node programmer, and even for most of the graph part) it will still be managed. One big issue I have with c# is most wrappers are not fully up to date (which is true for directx and opengl actually), so accessing last feature set often requires quite a lot of work. c# lack of support for #define and #include is also an issue, since they allow to switch implementation much more easily.
@fibo (again) : Yes need more examples, I plan to open a lot of my shaders personal folder in later releases, but more samples/templates/help patches are needed, and it obviously takes time.
I'm comfortable with c++, so i'd be happy with having a mixed framework, but it seems that anyway nodes will be seeing .NET wrapping by FeralTic, so it doesn't seem to be an issue.
It'd be ideal if SlimDX gained support for all the extra functionality:
How about forking SlimDX and slowly pushing your wrapping back into the SlimDX core, whilst keeping all functionality mirrored in FeralTic c++ until those changes are merged? I guess this way takes the most effort :)
@elliotwoods as far as I remember SlimDX people wanted to have a pretty low level API (eg: just wrap resources and that's it). Which is cool can still push the changes needed for extra functionality and wrap around it in another library.
One nice thing with having FeralTic in c++ would be that it also becomes useable in other frameworks (thinking ofx/cinder), while still having c# wrapper so for vvvv users they can stay in managed world.
What's the status of SlimDX? Have you asked the maintainers if they had plans to add new features? I know many people use SlimDX, extending it would benefit everyone. But I would guess that doing it alone might take some time.
Creating a C++ core might be a good idea and as I understood you already got a good part of it. How many people right now really help you developing dx11 vvvv integration? Maybe they don't mind digging into C++ if it's worth it.
The idea to separate a C++ core to be able to use it in ofx/cinder doesn't look good because most of the people using these are mac users.
what'd be even more awesome would be if there could be a way in future to interpret a vvvv dx11 render-pipeline back into c++ ;) (e.g. this could be as simple as switching out the FeralTic library for an API call logger of sorts)
Back to less fantasy territory...
ofxFeralTic sounds neat, but I presume it'd be called ofxDirectX11 and implement ofBaseRenderer There is a Microsoft dev evangelist (who's job is to increase microsoft support in creative coding communities) on the oF dev list at the moment who's pushing for DX11 implementation, it might be possible to get them to sponsor you to implement this.
I haven't got enough experience with FeralTic so far to comment deeply on how it's used. I'm also a little confused as to exactly what it's role is (so far it seems to be a DX resource management + utility set which exposes SlimDX objects underneath?) It'd be great to have a few more words on what it is at https://github.com/mrvux/FeralTic/blob/master/README.md
Elliot
On 10 July 2013 07:59, Valentin Simonov notifications@github.com wrote:
What's the status of SlimDX? Have you asked the maintainers if they had plans to add new features? I know many people use SlimDX, extending it would benefit everyone. But I would guess that doing it alone might take some time.
Creating a C++ core might be a good idea and as I understood you already got a good part of it. How many people right now really help you developing dx11 vvvv integration? Maybe they don't mind digging into C++ if it's worth it.
The idea to separate a C++ core to be able to use it in ofx/cinder doesn't look good because most of the people using these are mac users.
— Reply to this email directly or view it on GitHubhttps://github.com/mrvux/dx11-vvvv/issues/32#issuecomment-20711486 .
Elliot Woods elliot elliot@kimchiandchips.com@KimchiAndChips.comhttp://www.kimchiandchips.com/
We should focus only on vvvv to minimize effort (it's a pity but resources are limited). I think that an original name like FeralTic is ok, if in the future we will have DirectX17 or OpenGL or whatever, it will be the lib we use for vvvv graphic nodes (look at OGRE, for example).
C++ should be great, as well as helping vux in minor tasks like releasing and documenting so he can spend more time on software goodness.
@elliotwoods : we could also edit this https://github.com/mrvux/dx11-vvvv/blob/alphatest/README.md saying that FeralTic is a submodule and drop a link to the dx11-vvvv repo in FeralTic
In fact it is difficult at first "discover" the three repos: FeralTic, dx11-vvvv and girlpower. @mrvux : does it make sense to create a github organization or something to group the repos together and add volunters that will contribute? If yes, please create one.
As practical programmer, i always trying to use more widespread and well documented libraries, this libraries can be not the newest ones or the fastest ones. So i prefer "extending SlimDX approach".
Currently for me was really easy to google some vector math methods from SlimDX. I can always find some similar questions on Stack Overflow, gamedev forums, etc. In other cases, i always need to go to IRC channel, Skype, dig into source code, which is not so fast.
@valyard and @elliotwoods Yes I got a quite good part of feraltic implemented in c++ (some parts are actually even better than the c# version, but it's still a bit incomplete). Technically I already have a Renderer class (window), but for Cinder only for the moment. It also even works for dx11.1 and can run as a metro app.
Yes feraltic is more or less just a little extra layer which provides a few extra functions (wraps resources with proper associated views, resource pool, base geometry, stacks for rendertargets and states, shader compiler), it quite saves some time when doing nodes or working with core since otherwise you do a bit always the same thing.
From what I know about SlimDX I'm not too sure, the last release was in January 2012, which is quite a while ago. I know they planned to implement a new version, but seems it got stalled.
And now since mentioning cinder/ofx, I don't believe it's only mac users (even if there is a decent userbase for it). One benefit of using c++ would be to extend it to a broader community, eg, more people having access to source code and being able to extend it/fix bugs, so it would also impact vvvv in a beneficial way (since all 3 would share the same codebase).
@fibo would be nice indeed to edit readmes in repos to link to other repositories.
I guess for now what I might test is a mini test version for dx using all 3 options (just a depthbuffer/rendertarget + renderer) and make myself an idea.
@smakhtin I really only plan to make the minimal wrapper for resources, for math classes slimx/sharpdx and most other tools already have that, I'm not gonna reinvent it ;)
Wasn't sure whether to put this in forum or here, but found it would be nicer in github, so here it is.
DX11 development reaches (for me at least) a few major issues. Before to consider doing drastic change I thought that I would expose those and maybe people could also submit ideas.
Main problem is now DX11.1 / Win8 is out, and SlimDX has pretty much no support for it (and I'm not sure if it will ever have).
So for now it seems using SlimDX is slowing down my way to add access to extra features, some of them which are really useful (new video decoder, new pipeline functions...)
So I see 3 options to move forward: -Add new features and namespaces in SlimDX -Move to another API (eg SharpDX, which is pretty much the only one) -Move the core engine to c++ and provide custom wrapper (eg something a bit more high level than just wrapping interfaces, which is what feraltic does actually).
From what I see time wise for each option: -SlimDX : That would likely be quite time consuming, also there's a lot of things in the current architecture than I'm not too fond of (Object Table for example). -SharpDX move : Probably the fastest in some ways (I already did some tests porting over), still lot of rebarbative work and lot of testing. -Custom Move: I already have a c++ version of FeralTic (not as big as the c# one yet). So that would speed things up. That's probably a bit more time consuming than others, but I see quite some benefits for it, like not having to wait for updates, still possibility to have interop with above wrappers. Biggest drawback will likely be that it will be harder to maintain by community since I know most people are more comfy with c#.
Any thoughts/comments/ideas welcomed...