Shared publicly  - 
 
[#geeksh!t]
Wow, in the middle of a major refactor; again... 8} Just undertaking the last major overhaul of the input components for handling entity state control in the TyphonRT entity system. One last core collections addition I did recently is the creation of an extensible enum set (ExtEnumSet) that is like the standard Java EnumSet except it packs multiple extensible enum types into an efficient Set implementation in a similar manner to EnumSet that is a lot faster than a normal HashSet, etc.

For the longest time since the beginning of the TyphonRT entity system years ago state was simply packed into an int bit field which is an intractable situation except for trivial use cases / simple purpose driven games. This also caused me to track state for movement inside the movement components (directional & rotation info) rather than as state in the entity itself. To keep things simple I also was limited to 32 action / states, 8 directional movement, and 4 rotation inputs. For reference on extensible enums review Item 34 in +Joshua Bloch's excellent book Effective Java. Extensible enums have been the answer to a lot of final architecture issues when it comes to cleanly separating components and decoupling common state between them. The ExtEnumSet now provides awesome control and visibility to combinations of unrelated states for entities. You can print them out and receive non-verbose or verbose output including the entire int array backed bit field and a summary of all set enums in a textual format. Not so easy to do with a bare int bit field.


There were some general tricks necessary to be memory efficient over EnumSet such as creating an "ExtEnumSetProvider" that will store all the packed enums and other house keeping data potentially separate of the ExtEnumSet instance. This greatly reduces memory requirements for entities of the same type or common types, or even one provider for all entities depending on requirements. This also handles the case if a new extensible enum is added to a particular entity and the ExtEnumSet grows then all entities referencing the same provider grow their respective ExtEnumSet. For 10k entities moving from a simple bit field to ExtEnumSet only 400k more memory is used which is not bad considering the flexibility. Without a separate ExtEnumSetProvider it balloons to more than 10Mb with even more increase when say storing 128 states. Basic micro benchmarking shows ~3X slowdown on Android against bit fields, but way better than a general Set especially for union testing which is 10X+ and worse depending on the union.

Besides everything in the input calibration components being externally configured via XML presently another neat feature I'm just wrapping up is mapping of configurable actions to potentially compound ExtEnumSets. IE the flying, god mode, eating cupcake action for instance; each state kept in a different extensible enum type and separate component package or whatever is clever. The the internal enum constants are accumulated of an actions set such that if key/button 1 triggers A&B state and key 2 triggers B&C state when key1 is pressed A&B is set; key 2 is pressed C is set; when key 1 is let go B&C states are maintained. I'm also supporting momentary push to make / push to break state changes in addition to toggle changes on key/button down press and reversed on the 2nd press; this all working fine with multiple actions defining same or overlapping state changes.

Over engineered; perhaps... A pleasure to use compared to the old bit field way; no doubt.
1
Add a comment...