What happened to the uber selection shapes widget?

[aeonios]

Recently this came up in a discussion on zk forums, that BAR had a really awesome selection shapes widget that merges overlapping shapes and has cool effects. Specifically this (from 2014!).

However after scanning through all the widgets in bar several times I couldn't find it. That was a really cool project, where'd it go? (and why isn't it already the default in bar?)

[Silentwings]

You can find it in http://imolarpg.dyndns.org/trac/balates ... ed%20units, I have no idea if it will function with current Spring.

Reasons why it was removed (and is unlikely ever to return) can be found in http://imolarpg.dyndns.org/trac/balatest/ticket/615, essentially major perf issues and non-maintainable spaghetti code.

[Floris]

Shortly after I created it the whole unitshapes functionally was screwed due to a new spring engine release.
Also while it looked awesome on Tabula, at most maps it wasn't that great at all, because those maps are too bright overall. Together with the performance cost (and the work optimizing it), the engine bug and the so so looks on most maps, I didnt bother working on it any longer. Who knows I might give it a shot later, because good bloom and map darkening effects are availible now.

[aeonios]

hmm.. the widget makes heavy use of display lists, which are bad. They perform badly, are pointless because you basically have to remake them every frame, and they break on ati cards. DisplayLists have been deprecated and removed from the openGL specification so modern cards don't support them in general. It also uses gl.Push/PopAttrib which have been deprecated in the GL spec. I dunno about spring, since it does tend to randomly change the interface often for seemingly no reason.

I think if the indirection from the display lists was removed it would be much easier to read and maintain. It also has too many configurable settings, most of which are things that players really shouldn't mess with.

[Silentwings]

(1) Spring does not use the latest GL spec
(2) You do not necessarily remake display lists every frame on all cards, although you are right that their use in that widget is mostly pointless due to the need for constant re-makes. Display lists are not inherently bad, they are just "old tech". When used properly in suitable situations they did/do result in a huge speed-up on older cards.
(3) Removing display lists is dead easy and you could test it with 30 mins work. On newer cards/systems I would expect the difference to be negligible; the major issues are simply the volume of gl calls and unnecessary hash table iteration per frame which would both remain essentially unaffected. It won't by itself make the code easier to maintain, see previous link for what would.
(4) You'll also need to take account of https://springrts.com/mantis/view.php?id=4494
(5) Best of luck with it.

[Forboding Angel]

[offtopic] I'm not particularly deep with learning to draw using GL, but I do appreciate that info, Silentwings.