Official DOTS Input Prototype - Hackweek 2020

Hey everyone,

A week ago, we had our annual Hackweek (this time, due to COVID-19, a "virtual" one with everyone working from home) and I used the opportunity to do some prototyping for input in DOTS and thought why not share the sum of that hacking here. It's all prototype code and as such, even if the ideas here in some form will end up making it into the eventual feature, there's still quite a gap between here and there. But anyway, thought some may find it interesting. And in case you have thoughts or concerns, voice away.

Gist...

• Extensive data sharing (actions and devices) between DOTS and non-DOTS input
• Little to no code sharing between the two (except for shared native backends)
• Code generation to support DOTS target
• Fully JobComponentSystem-based with component data as outputs

 

Hi, thanks for this video! From what version of Input System package is the "ECS generation" available, please?

 

ATM this is just a prototype. Too early to tell when exactly ECS support will land. We're hoping to have at least a preview with limited functionality available soonish.

Also, for more adventurous souls, I'd like to have the dots-input-hw2020 branch on GitHub in a state soon where it's viable for anyone to give this an early test drive and provide feedback.

 

Thanks for reply. Having this branch available would be awesome, let me know here once it is ready, please.

I am still learning and I am not planning to do anything production-ready yet so I am ok with living on edge

 

Nice work! I've been really pleased with the input system as its one of the few packages that's caused me minimal friction. I'll be looking forward to seeing more updates on the *gradual* development of DOTS support if you're happy to share with us!

 

@Rene-Damm Hi, can you share an ETA for a DOTS compatible preview release? If it's a long way away then for the time being please just release a decent tutorial to move a cube. The current hacky solutions in the forum have terribly verbose code.

 

Unfortunately, there's no ETA at this point.

 

Hey @Rene-Damm ! Great work on getting the input system dots-ready.

Whats the difference between the dots-input-hw2020 and dots-input branches?

 

I started cleaning things up and moving it past a HackWeek project into an actual usable prototype, thus the move from the dots-input-hw2020 (old) to the dots-input (new) branch. Unfortunately, the transition isn't yet quite complete. It's surprisingly functional for the amount of work that went in (I'm actually using it in a side project) but it's not very robust and falls over sideways rather easy.

One of the bigger things that will need to happen for DOTS Input (as pictured by that branch) to be able to fully spread its wings is to pull apart the event buffer as it currently works in the Unity runtime. There is a single one such buffer that all the events for all the devices get dumped into. Seemed like a smart and simple thing at the time. Background queue for async input and single main thread event buffer that everything ends up in and that gets passed to managed code.

Well, turns out it's stupid I think a better design is to have every device sit on its own separate event buffer that, if need be, can be used to negotiate any which threading setup makes most sense. Unfortunately, this will require making some changes to the native input runtime but I think for DOTS Input that will open the door to much better input setups. The current prototype handles that in the worst possible way by copying over the entire event buffer and handing it to the thread. Not only puts flushing of input into the scheduling rather than job execution phase but also means input jobs have to potentially crawl through tons of memory containing events of no interest to the particular job.

Anyway, my hope is to get the dots-input branch to a point where anyone interested can give this a go easily so that we can evaluate more fully what makes sense and what doesn't.

 

Ah, I see. Looking forward to hearing more about the progress then

 

Hi @Rene-Damm ,

Any update on getting a preview version of this DOTS Input System?

Thanks a lot!

 

Hi @nico_st_29, unfortunately no news yet :/

 

Still waiting for this gem. Its the last part missing in Chain at the moment.

UI Builder now works in ECS and the new Input System. It would be nice to handle the Button presses now in Dots.
Is there a Roadmap plan to support it?

 

Do you have a source for that? I have not found it by glancing over the release notes. That would be good news indeed.

 

Hey @Rene-Damm, is the "dots-input" branch still the best place to start for looking at using the new input system in DOTS?

Any gotchas or tips to be aware of before trying to use this in a DOTS project?

I know in the vid it was stated that things like reverse mapping aren't implemented, so there's some stuff to note, but the core functionality looks promising already.

 

Is this a tease because you're working on it during hack week right now?

 

Seems that this is the ideal way to go unless Rene has any news:

- Getting values directly from the Input System into a SystemBase: https://forum.unity.com/threads/input-system-update.508660/page-17#post-5768788
- Example of it in action: https://forum.unity.com/threads/new-input-to-ecs.1133965/#post-7285780

 

Hi @Rene-Damm. Any new updates?

 

Unfortunately, still no news at this point.

I've been very badly wanting to go back to this for a while now but priority with the input package has for some time now been pure stabilization.

Was using it a bit myself in a side project but in general, would recommend against doing much with the dots-input branch at this point. Just too much stuff that needs doing.

I think the approach taken by the branch has a lot of merit. I personally really like the fact you end up with your inputs looking like this

Code (CSharp):

1. public struct MyActions
2. {
3.     public ButtonInput Jump;
4.     public ButtonInput Fire;
5.     public Float2Input Move;
6.     public Float2Input Look;
7. }

Just still needs a good deal of work.

 

Hey, @Rene-Damm.
I don't suppose you have had a chance to work on the whole DOTS-input thing?

I know DOTS 1.0 is meant specifically for the hybrid workflow... but once DOTS 1.0 ships, do you believe that you will start working on this again in preparation for DOTS 2.0 where (presumably) a DOTS-input solution will be needed?