Цитата
len
Может быть рассчитан на основе кооридант. Т.е. его передача по сути не требуется.
Цитата
local _,_,r1,r2 = usl:find("R%((%d+)%-*(%d*)")
local _,_,g1,g2 = usl:find("G%((%d+)%-*(%d*)")
local _,_,b1,b2 = usl:find("B%((%d+)%-*(%d*)")
local _,_,RG1,RG2 = usl:find("R%-G%[(%-*%d+)%s*(%-*%d*)")
local _,_,RB1,RB2 = usl:find("R%-B%[(%-*%d+)%s*(%-*%d*)")
local _,_,GB1,GB2 = usl:find("G%-B%[(%-*%d+)%s*(%-*%d*)")
r1=tonumber(r1) r2=tonumber(r2)
g1=tonumber(g1) g2=tonumber(g2)
b1=tonumber(b1) b2=tonumber(b2)
RG1=tonumber(RG1) RG2=tonumber(RG2)
RB1=tonumber(RB1) RB2=tonumber(RB2)
GB1=tonumber(GB1) GB2=tonumber(GB2)
Можно избавиться передавая вместо стринга массив. Что-то врод:
{r={0, 255}, g={100, 200}}
При этом парсинг, как таковой не очень нужен, читаемость едва ли шибко хуже, но при этом уже полностью стандартизирована и чистый луа в который можно и переменной задать какие-то куски.
Обращаю внимание на то, что избавиться можно именно от парсинга, но вот таблицу привести к массиву ради скорости работы все же нужно. Задание переменными по сути структуры не очень хорошо - массивы как-то логичнее (навсякий случай проверить скорость работы).
Цитата
function FindRGB
local опять уплыл.
Цитата
for
Хз насколько применимо к луа, но учитывая то, что перебор идет достаточно большого объема данных, то имена переменных вероятно стоит сделать однобуквенными - даст некоторый прирост производительности. Так же рекомендую следовать правилу, что внутренний цикл должен быть на меньшее количество итераций, чем внешний. Это тоже влияет на скорость.