gay_drums: Cache track_get_state

gay_drums implements partial redraws, which is a somewhat misguided approach - it can fully redraw itself fast enough (about 9 FPS), so while it does provide some additional smoothness, it's not exactly addressing the real issue at all.

What's actually slow are track_get_state calls in draw_track_step_marker, which have no reason to be this slow - in fact, they could be entirely omitted if gay_drums maintained its own view of the track state.

changed the description

Some initial code towards that is now in !339 (merged). It only skips track_get_state when transitioning and when the track state hasn't been touched by the user yet, so it could still be made better.

oh cool missed that thanks!

should do that bl00mbox side, thread safe table is ultra slow for no reason, next update will have that fixed

update: we implemented this in several different ways on several different layers only to find it crashes after some random runtime. gdb says it's a consistent function pointer crash in the graphics backend. we have the suspicion that somehow we flood the graphics pipeline by drawing too many things too fast, but we have yet to find evidence of that. it's the weirdest thing. we wanna improve the debug tools a bit to tackle this.

bug seems to be outside of bl00mbox: #131 (closed)

mentioned in issue #131 (closed)

mentioned in commit 01735ff2

fixed in newer bl00mbox versions, no caching necessary

closed