Well everything is more complicated than if u dont do it now isnt it, doesnt mean you shouldnt do it tho does it.
Actually, it does mean you shouldn't do it. In terms of CPU cycles, the bitwise shifting would take more resources than a simple string-to-integer parse. Given that control codes are processed in each line displayed to a window, the speed of the parser is of the utmost importance.
What you have described is certainly
possible and might prove advantageous given the right situation, however in this context it is not
plausible to do the extra processing required, which provides no added advantage over a simple string parser.
If this was the concern this doesnt limit the ability of local colorizing beyond 16 colors, it could have been simply noted that any value higher than 15 would be made mod 16.
That is a good point and would likely be the best solution for the problem and would prove easy to implement, however input text would need to be parsed and any values greater than 15 would be N % 16 - 1 (since it's zero based
). Furthermore, various shades of red would have to be parsed in such a way that they turned out to be red, otherwise mIRC's extended control codes would look like random colors to any other client.
