Kert wrote:
Any ideas on how to measure the processing time for each note taking overlaps and density into consideration?
I can only think of using objects' fade-in times as a base and altering these somehow depending on the overlap time/percentage
Yeah, that sounds like a decent approach. I would work on developing an algorithm that compares all the visual objects at a particular time position and spits out a composite "noise" rating. Once you have that you can just run that algorithm at each object's time position and use the resulting noise rating to come up with a per-object weighted processing time. Obviously the algorithm itself is the real challenge, and you'll likely have to heavily tweak the factor by which the base time is altered to get the weighted time, but that's how I'd start.
Evaluating the non-visual component is the tougher problem I think.
Edit: Just to spitball some ideas for the algorithm...
The most obvious component is the proximity of all the visual objects. Next to that is probably overlapping cursor paths (e.g., the path between the current note and the next note overlaps the path between two notes later in the pattern). Notes fade in over time, so you'll need some way of determining how much each object has faded in at any given time position, and once you can determine that you could probably use that fade-in percentage as a multiplier for the note and its outgoing cursor path. This would make notes closer to the current time position more heavily weighted, which I think is accurate.
However, you won't just need to evaluate the objects that are actually on-screen, you'll need to look at hot spots as well, meaning areas of the screen that tend to have more notes than other areas (the easiest way to understand why this matters is to think of taking all of a map's patterns and putting them in one corner of the screen - the object density in that corner would skyrocket, making everything happening in that corner tougher to read). I can't think of an efficient way to implement this, but I think an ideal implementation would work very similarly to the noise algorithm, but would be localized to a specific point; that is to say, you pick a point and a time position and the algorithm looks through all the objects that occurred before that time and, for each object, adds some value corresponding to the distance, both in a time and screen position, between that object and the given point/time.
Now that I think about it, those two algorithms could actually be combined. Instead of running one to check for hot spots and one to check noise, just give visual objects a higher weighting than non-visual objects, and have that additional weight correspond to how visual the object is.
If I had any familiarity with osu's file formatting I'd put together a prototype for you, but alas...