Sunday, 15 December 2013

SharpDX, refactoring and complexity

I finally was able to spend some proper time to port over SlimDX dx11 to SharpDX (still on quite a few stressful projects, so I try to lock the little amount of spare time I have to test new goodies ;)

Main thing, I didn't redo all from scratch, here is my workflow in that case:

  • Port the core API: This is quite minimal, so I got rid of a lot of the boilerplate, less types, split some parts. API is now much more minimal and easy to work with. 
  • Port of the core: On first instance, I also just replace namespaces/namings. Then I started to refactor parts.
  • Nodes : Since you don't want to break all naming, I keep all very simple. I copy/paste all the nodes and remove the code inside ;) That means I don't have random compile errors, but I got all the in/outs up front (which is kinda similar to test driven development. When I think my core API is ready I push the code again.
So lately I was able to also add improvements, no more multi device helps a lot cleaning codebase, which would help 1 person in a lifetime but makes suffer all the others. Now dx nodes are simpler, easier to write.
There's sill a bit of work polishing API, but foundation seems much nicer for now.

Shader node finally got the improvement it deserved, and is much lighter api wise (eg, also decently faster in many cases).

I also looked to port a few of my high level nodes, and give some decent improvements to the layer system, and all of this is also promising, plan for next release being to provide more low level access to advanced users, while having more high level nodes for general patchers. This is for me a good step forward, but balancing this is hard ;)

On the week end I was able to test a bit API, and results are pretty promising:

Now one major issue with move to SharpDX is the following:

  • You want to support win7
  • You want access to latest DirectX (eg : 11.2)
Luckily, SharpDX makes it relatively easy, only pain part is file load/save. (In win7 you have dxut which makes it easy, in 8/8.1 you hve to do it yourself, or port DirectXTex from c++ to c#).

But that already makes 3 builds to maintain (I'd say ok, 2, 11.1 and 11.2 is not much difference for now).
And since in 4v you need to differenciate x86/x64, that makes 6 builds,uff, just a right pain.

So I looked again a bit more in 4v core, and oh man everything is so overcomplex.

SlimDX is really ultra tied to the core, and it's also the only assembly that forces this 32/64 bits build (90% of the rest could happily be anycpu).
But since it's tied to the core any plugin must choose.

This is a right pain.

I did a few tests, replacing SharpDX by SlimDX also for DX9, but it doesn't scale well, since then you tie yourself to the win7 assembly, which kinda sucks (assembly loading order can create some... interesting errors).

So easiest way ended up to be the brute force, eg, just get rid of SlimDX, and basically just break any plugin with DX9 mesh/layer/texture out.

For me right now it is the best and most sensible solution. I don't have access to the full 4v core, so I'm not able to split a few interfaces, so both of them can live together.

Since I'm really not into dx9/dx11 working in the same 4v instance, it's really not a biggie, but it can bring a few maintenance issues.

So what is the plan now?

Well it would be great to work with devvvvs in order to properly split standard pin logic to render pins, and properly isolate SlimDX (and any architecture dependent code) from he main core. I think it's primordial, but if i have to ship a custom core to avoid this nonsense, then so be it, I will gladly do it.

All those Matrices in 4v are also nonsense, I forgot some of the exact bits, but they add so much complexity to the system, and for me thinking that a simple 16 floats array create such a mess feels kinda bad.
So since I got mostly all of them with a much simpler, custom type, I might introduce that in the next build.
That would be a big thing since it would break backwards compatibility, but at the end I tend to plan for the future not the past.

Rest is to continue into SIMPLIFYING the system. I think most people tend to think too much about a problem, then the most you think of it the more twisted you mind becomes, then you produce a system 10 times more complex than it should be. This is wrong. Not saying that your system should be more flexible, but it needs to be easily testable/debuggable. More complexity never brings any good, over design is bad. 
For example, I looked a lot at code generation, and finally, I will only use it for fx->c# generation.
Doing it for all my types sounds good, but finally I ported all my geometry nodes in 20 minutes, would have taken 2 days to build a generator. For effects with reflection it stays a pretty good idea, since any user can write their own fx, so in that case it makes some sense.

The most fun part of it, you will complain about a system being overcomplex, decide to rewrite all, and makes something 5 times more complex up front (while repeating a lot of mistakes and adding new ones). Not worth it, refactor and improve.

Stop using crappy defaults, and inform user when something is wrong. Crappy defaults sounds a good idea on first instance, but it also makes your system more complex, and when your crappy defaults don't work anymore, you have to know if it comes from the user or yourself, and your user didn't learn anything. A few well placed defaults (with proper information eg : Ok you didn't provided this info, so I used this instead, but please be wary) is a step in the right direction. Choosing silent defaults is a NO GO.

Take more painful decisions if I need to ;) I know users hate changes in some ways (myself included), but then you have to decide and take the risk if you think this is future proof, not stay like ten years ago. I know on programmer side this is also a problem, but finally, changing library if you need is also taking care of users. I could just take AddFlow (the ui library used in 4v), which is now so crap that it's impossible to use vvvv in a live environment anymore (move a few nodes and all your render freezes). I wish they would take the painful path and just switch library, and it doesn't take that much time to do (just bit boring).

Ok stop mumbling, lot of new goodness on the way, be happy ;)

No comments:

Post a Comment