SteelSeries is happy to announce Dota 2 GameSense support in SteelSeries Engine!
We’ve worked with the team over at Valve to bring you another incredible experience.
We recently released Engine 3.4.1 with support for some new hardware and various improvements. Let’s look at what’s new.
For V1.0, I revisited the way primitive functions are handled to make them work more like regular functions (i.e. defined in Lisp using define/lambda). The visible change if you are writing primitives is that they now recieve evaluated arguments. I.e. they use applicative order of evaluation now. This is as it should be.
You’ve been able to use your SteelSeries hardware to provide input to your games since, well, forever. That is what SteelSeries products are for, afterall. But now, with the beta release of GameSense™, you can use your SteelSeries hardware to display game state information.
Why is this interesting? Well, it’s pretty cool to start with. But it can be quite useful as well. Imagine watching an event where each player has their health level dsplayed as the color of their headset lighting. Imagine playing Minecraft and seeing your hunger level, breath, direction you are facing, and even what tool you are holding and it’s durability all displayed on your keyboard. How about getting notified when spells and abilities are available again after their cooldown expires? Now make that all user customizable.
That’s just the start of what GameSense™ can do.
We recently released Engine 3.3.7, with support for new and old devices. Let’s look at what 3.3.7 includes.
Scheme (and thus GoLisp) is lexically scoped. This is implemented by the creation of a lexical environment (aka symbol table) for each lexical scope:
let structures, which hold the let bindingsdo structures, which hold the do bindingsFunctions and lambdas capture a reference to the environment in which they were defined, so they always have access to its bindings (that’s a closure, btw).
Each environment has a connection to its containing environment, and can override/hide bindings in outer scopes. When a symbol is evaluated, the most local environment is searched first. If a binding for the system isn’t found there, the containing environment is searched. This continues until a binding for the sybol is found or we go all the way to the global environment and still can’t find a binding.
Section 3.2 of [1] does a great job of explaining environments in Scheme, which is the basis for environments in GoLisp.
In Scheme, some environments are more important than others, mainly as they tend to be larger, long lived, and serve as the root of many other environments as a program runs. These are known as top level environments. Specifially, these are the global environment (the only environment that is contained by nothing), and any environments directly below it in the environment tree. The REPL runs in one such environment, which effectively sandboxes it, protecting the bindings in the global environment from corruption.
In standard Scheme, environments are first class objects. That is, they can be passed around, returned, manipulated, etc. I’ve recently added this ability to GoLisp, along with the majority of the environment manipulation functions from Scheme. These are described below.
We recently released Engine 3.3.6.1, with new features and new devices. Let’s look at what 3.3.6.1 includes.
We recently released Engine 3.3.4, with new features and new devices. Let’s look at what 3.3.4 includes.
We recently released Engine 3.3.3, with new features and new devices. Let’s look at what 3.3.3 includes.