I'll pick this apart in detail at some point, but I'm fairly solidly done with batch. It's been an unnecessary time sink every time I touch it for years. I say that knowing my way around it fairly well.
Just for a bit of perspective, consider the fact that it takes this much effort to do something that should be trivial, drags in systems that shouldn't be involved (file IO), and still isn't a robust solution (hard coded wait and hope that the other processes have finished running). There are so many red flags it might as well be a Chinese parade. It's simply not the best tool for the job.
Configurable dead zone and inversion are already in the high level API (the low level API is meant to be unprocessed, raw input).Cornflakes_91 wrote: ↑Sun Feb 18, 2018 4:06 pm<snip>
configurable dead zone, zero point, sensitivity and inversion options individually for any and all axes
thats how inputs are handled properly
(the only improvement would be adaptable input-output mapping curves)
the interface also provides direct graphical feedback as to how the output behaves with the current input state.
i can see how the sliders change the behaviour of the mapping function.
runtime autodetect of removed/added input devices
Device connect/disconnect handling is already in the low level API.
Sensitivity will be handled by gameplay, not the input system. The input system always returns values from [-1, 1].
Zero point, custom curves, and graphical representation seem maybe unnecessary but I haven't done my HOTAS research yet. If any of them end up being necessary I'll make sure they're supported. Note however that you can currently set an exponent on input to tweak the curve a bit and that the UI will, of course, be easily moddable.
Probably an 8. I think it's a massive step in the right direction.
My ideal language would contain (at least):
- Keeps the simplicity and low level power of C
- Adds 'high level language' features in a way that doesn't annihilate performance
- Has robust meta-programming features
- Has a not-insane standard library
- Interops with C
- Doesn't require header files or forward declarations
- The 'build system' is written in the language itself and part of your code
- The compiler handles 'package management'
- The compiler is <100 MB and trivial to install
- Doesn't have/encourage exceptions
- Makes using other people's code easy (this is the motivation behind several of the other points)
- Statically typed
- Supports mixins
- Isn't garbage collected
My biggest reservation is adoption. Even if I love it, will I be able to use it in a professional capacity?
It's a programming language being developed by Jonathan Blow, the developer behind Braid and The Witness. He's an excellent programmer with ideals very close to my own. The language is intended to take the speed and power of C and bring it into the modern era, adding high level features without sacrificing speed and control. It also makes a point to remove 'friction' or unnecessary thought/work from actually writing code. He streams development on Twitch and archives the streams on Youtube. Development has been going on for about 2 years I think and the plan is to start releasing the compiler to larger and larger groups this year.
I've been following development pretty closely. Jon streams development of the compiler as well as semi-regular demos where he shows off the capabilities of the language. That makes it a bit more than just promises to me.