An update in under 1 year - oh snap!
So what is one supposed to do when one has a stable(ish) software which isn't widely much used (which means care factor to the author=low), relies on closed source libraries, has been broken way too many times from library updates (with emergency firefighting sessions to fix everything), and someone sends the author yet another black box update?
I suppose most people reading this probably answered "don't touch it" or "reject everything for the sake of stability and fear of regressions". And that's fine I guess, that's how I almost reacted when I got sent a said update. Actually my knee-jerk reaction was to reply "prove to me that it works 100%, try all sample projects, then get all people using rb+ to try the change and report back with success and only then I'll implement it". But I didn't do that either. Frankly I was really puzzled about how to handle this.
Then, other and more interesting stuff came along and this was shelved for many days. At one point I thought of a good compromise on how to solve the above problems but again put it aside as I'm not that enthusiastic about the project anymore and I'll take stability over new features any day.
Long story short, I remembered about this 1 hour ago and set about implementing the feature. It worked first time, at least with one example I tried.
(okay, I suppose this introduction dragged on for too long, so let's cut to the chase)
Well, that came out really wrong. It all boiled down to: I delayed applying this because a) I was afraid it would break compatibility if I replaced the original unpacking method, b) When I figured out how to apply it without breaking anything it still took a long while because rb+ is low priority for me. So just disregard the above! (left there for historic purposes - I'm not afraid to own up if I make a mistake and I won't wipe my posts just so I look good!)
The build system now accepts a new switch called FASTDEPACK. If you invoke this while building a ROM then a new GPU depack routine will be used which leads to faster startup times while booting. If the switch is not used then the old (but 100% robust) routine will be used instead. For example:
build myproject ROM FASTDEPACK
Which brings us to the disclaimer part: Consider the feature experimental for now! While I'm pretty sure it won't wipe your hard drive it might have bizarre side effects on your ROMs!.
Of course any feedback about it is welcome: Does it work for you? Does it not work for you? Is the old depack working ok? Is that broken? You are welcome to download the latest version and try it out!
Also, thanks to the person sending me the update in the first place .
Edited by ggn, Thu Feb 8, 2018 11:03 AM.