One of my biggest irritations with MoveLib was that it was a cumbersome, heavy piece of shit library that solved a lot of problems in really bad ways.
I learned a lot maintaining and developing it. For starters, how I was handling partial pixel preservation was not good. The main source of bugs was the fact that I was allowing nested movement calls to muck with the process, and avoiding encapsulating information into datums to avoid overhead. It really made the whole problem way worse than it needed to be.
I've been attempting to rectify some of the problems with MoveLib by planning around an entirely new internal structure while maintaining an extremely similar API for developers to use.
I wanted some input on some of these new ideas from other developers, and how to best implement some of these things in such a way that my code isn't getting in the way of how you like to write your code (BTW, it's wrong. Your code is always wrong. You don't matter. Give up. =P... Kidding of course.).
Below I'll be bantering about design considerations I'm messing with right now, and would appreciate some input if y'all got the time or inclination.
Jul 4, 5:55 pm