Разработка findcolor, findimage, Pure lua Опции

[sutra]

Я переворачивал построчно через memcpy.

Спасибо. Да, именно так. Благо меня этому уже научили. Просто при загрузке файла смотрю высоту и если минус, построчно копирую снизу вверх. Тут тоже вроде всё решил, как и говорил, создал уже массив этих масок с большим запасом, так что манипулировать ими нет проблем. При записи не знаю пока, можно тоже построчно копировать в обратном порядке, чтобы не быть белой вороной. Скорость копирования в памяти - это крохи, тут нет никаких проблем, кроме эстетической - противно смотреть на собственный код.

[sutra]

Кстати, вырезалку из образа, тоже таким же способом.

[Madeus]

Если брать луа, то искать перевернутую сохраняя направление поиска не очень удобно. for тут работать на понижение не умеет, т.е. работа пойдет через while, а он медленный. Ну и писать несколько тяжелее.

For же умеет назад считать, с отрицательным шагом.

[DarkMaster]

sutra, принципиально делаем две версии одинаковые?)

For же умеет назад считать, с отрицательным шагом.

хм. Видимо что-то с математикой косячил. Тупо не входило в цикл когда старт больше окончания и отрицательный шаг. Видимо что-то из этого было с ошибкой.

[sutra]

sutra, принципиально делаем две версии одинаковые?)

Нет, Дарк, не в этом дело. Просто я люблю всё попробовать сделать сам, чтобы чётко понимать что и как работает, так сказать для опыта. Мои потуги нисколько не умаляют твой вклад в общее дело. Ну и в конце концов, ты же всё это делаешь не только для меня, хоть я тут намутил больше всех. Во-вторых, ну бывает просто не терпится поскорее решить проблему, а не ждать милостыню, да и кто знает, а вдруг тебе будет некогда ... Ну и наконец, я максималист, если у меня есть ощущение, что можно что-то ускорить - я это делаю. Я вообще любитель низкого уровня, мне как-то это ближе, ну кроме ASM-а конечно, хотя были времена, когда и без него ну никак было не обойтись. Когда рисовал обработку графики (ещё для CGA), там прирост по сравнению с Паскалем был очень солидный. Я же не зря спросил про копирование - это же основа работы с массивами данных. Теперь я знаю как это тут делать, так что всё в полном ажуре. Ещё раз спасибо и тебе и всем кто не был безучастен!

[sutra]

Дело всё ещё в том, что я совершенно не понимаю принципы работы lua. Что и чего там делается я не знаю. Изучать всё это - мне жаль убивать своё время, я далеко не молод. Тупо ориентируюсь на готовые решения (примеры) и на интуицию. Вот пример. rmem - это что? Я не знаю. Это аббревиатура доступа к данным? или полноценная функция? Если функция (о чём я интуитивно подозреваю), тогда это однозначные тормоза, т.к. уже задействуется память, т.к. используется стек, хотя х.з. как сейчас всё реализуется, может всё уже распёхано по памяти.
Раньше я чётко понимал ... передал в функцию параметр как var - передал адрес, без него - будет создана новая переменная, почему и было глупо передавать массивы как параметр, а не как переменную. Почему и используется буфер (даже понятие придумано конкретное) при передаче массивов данных ... Ну в общем ты меня понял, примерно так.

[DarkMaster]

rmem - это что? Я не знаю. Это аббревиатура доступа к данным? или полноценная функция?

Это сишный cast.

ну кроме ASM-а конечно

В луа можно делать вставки на аме (IMG:style_emoticons/default/crazy.gif)
Не знаешь луа, но знаешь асм?) Пиши на асме - уже в продаже доступно.

[cirus]

rmem - это что?

Тоже самое что ffi.cast.

Код

local rmem = ffi.cast

Для примера:

Код

--lua
local print = log
print(123)

[sutra]

Это сишный cast.

(IMG:style_emoticons/default/biggrin.gif)
И даже это требует для меня перевода. Ты думаешь я что-нить понял? СИ я тоже не изучал - дурак был, да и не было возможности, пришлось принципиально менять направление деятельности, я начал свой трудовой путь в августе 91 года, надеюсь не надо объяснять, что тогда творилось в стране. Пришлось всё бросить и надеть погоны. Да и ASM я напрочь забыл, да и знал то немного.

Конкретный вопрос. rmem тормозит или нет? Мне показалось что тормозит. Именно поэтому я и делал функцию ImageToArray.

Сейчас есть прямой доступ к битовой маске, вот поэтому и спрашиваю, есть ли смысл использовать rmem.

А вообще не тратьте на меня своё время, для меня всё это теперь просто хобби, забава. Мой поезд давно на запасном пути. Не сдохнуть бы и то хорошо. (IMG:style_emoticons/default/biggrin.gif)

[sutra]

Дарк, давай уж приходи к единообразию. Если уж начал облагораживать меняя
math.floor(w*3/4+0.75)*4 на math.ceil(w*3/4)*4
Так везде поменяй. Или ты хотел продемонстрировать ВСЁ многообразие подходов и методов решения.

[DarkMaster]

И даже это требует для меня перевода.

Это функция си, которая преобразует один тип данных в другой. Зачастую используется чтобы компилятор отстал со своими претензиями, что ты подсовываешь какой-то сраный int вместо MicrosoftSuperReanamed5or6TimesDataTypeForLookSoCool, который на самом деле все тот же int. Если совсем по деревянному:
a=int
b=a
c=b
d=c
-- а вот тут тебя копилятор пошел нахрен ибо
-- функция ждет на входе тип данных d.
-- и пофиг, что оно все друг другу равно.
result = cool_func(int)
-- а если ты сделаешь
result = cool_func(cast"d" int)
-- то оно заткнется и сожрет.
-- и вот за этот бред мне очень хочется убивать.
-- причем зачастую нативно не понятно, что ему надо
-- на входе. int/unsigned int/word/long long или еще чего.

Конкретный вопрос. rmem тормозит или нет?

Да, тормозит. Насколько? А кто бы знал. Я очень сильно подозреваю, что это его вина в проблемах финдимиджа.


По поводу malloc и приколов garbage collector, который хвостиком махнул и снес все к хренам. Если произошло преобразование cdata pointer -> number -> cdata pointer, то для него уже связь потеряна, можно сносить. В остальном шуршит.

[sutra]

Это функция си

Ну вот видишь, "предчуствия меня не обманули". (IMG:style_emoticons/default/biggrin.gif)

функция ждет на входе тип данных d

Вот именно это мне и не нравится. Я понимаю, хотели сделать всё для дурачка, а в итоге, как обычно мучаются специалисты. Меня лично просто бесит, когда вместо меня начинают думать. Если я сказал byte - значит байт, и не надо за меня решать. Извини, привычка думать по Паскалевски.

Примерно я всё понял, нужен тотальный контроль типов данных.

А ещё меня раздражает, что всё так сильно перемешано по типам. Лично для меня существуют лишь следующие типы: 1 байт; 2; 4; 8; 16; 32 и 64. А как я их буду интерпретировать, не их собачье дело.

В идеале доступ к нетипизированным данным, что собственно мы и делаем, объявляя массивчик для битовой маски. Есть доступ к любому байту, а уж что-то умножить или разделить на 256 мы всегда сумеем сами. Кстати, мне очень помогают твои скрипты, я на них учусь, я только на днях узнал (изучая твои поделки), что можно просто использовать %, чтобы получить целое от деления, вместо бесящих меня math.

[DarkMaster]

А ещё меня раздражает, что всё так сильно перемешано по типам. Лично для меня существуют лишь следующие типы: 1 байт; 2; 4; 8; 16; 32 и 64. А как я их буду интерпретировать, не их собачье дело.

Ну целые со знаком/целые без знака/с плавающей точкой имхо адекватное решение. Ну тупо чтобы +-*/ и прочая математика не дурела и каждый раз не писать велосипед.
У меня когда был подход лет 10 назад к си, так у меня самыми используемыми были memcpy, там где надо и не надо и pragma pack, чтобы он выравнивать перестал и можно было спокойно с памятью работать. У сишников была кровь из глаз(и я согласен с этим) и вопросы "а оно реально работает?"))

что можно просто использовать %, чтобы получить целое от деления, вместо бесящих меня math.

Но не нужно. Тормозной он. Я всегда стараюсь избегать, но тут мне было так лень, да и там всего одна операция.

Деление кстати еще тормозное. Лучше заменять умножением, если это возможно.

[sutra]

Ну целые со знаком/целые без знака/с плавающей точкой имхо адекватное решение

Ну конечно, это уж я так. Хотя мне ничего не мешает в нужный момент интерпретировать так, как я хочу. Ну вот есть у меня минусовое. Когда я это пишу в файл - глубоко фиолетово что там имелось ввиду - запишется конкретная комбинация из 8 битов.

Грубо говоря всегда должна быть возможность работы с буфером. Понятно, что она есть, но в lua это всё так хитро накручено, что мне с моими 3 классами приходится туго.

Вот хоть верь, хоть не верь. До сих пор работаю даже на битовом уровне. Как уже говорил, у меня всё работает по сценариям, которые прописаны в обычных текстовых файлах. Мне нужно задать кучу параметров по принципу ДА-НЕТ. Тащить массив очень неудобно, а кинуть число, в котором зашиты все эти да и нет очень удобно.

Точнее, текстовый файл - это и есть массив, в котором каждое число тоже массив, только битовый - очень удобно для читабельности таких файлов.

Но не нужно. Тормозной он

Странно, вопрос, а чем же так тогда принципиально быстр math.modf ?

[DarkMaster]

Странно, вопрос, а чем же так тогда принципиально быстр math.modf ?

А беспонятия. Где-то на бенчмарк натыкался.

[sutra]

Да брось, это всё просто крохи, для смеха попробовал.
for i=1,100000000 do
a=8%3
-- a=math.modf(8/3)
end

За то как красиво и элегантно, и запоминаемо, я до сих пор путаю modf и fmod

[Cockney]

Это функция си, которая преобразует один тип данных в другой. Зачастую используется чтобы компилятор отстал со своими претензиями, что ты подсовываешь какой-то сраный int вместо MicrosoftSuperReanamed5or6TimesDataTypeForLookSoCool, который на самом деле все тот же int. Если совсем по деревянному:
a=int
b=a
c=b
d=c
-- а вот тут тебя копилятор пошел нахрен ибо
-- функция ждет на входе тип данных d.
-- и пофиг, что оно все друг другу равно.
result = cool_func(int)
-- а если ты сделаешь
result = cool_func(cast"d" int)
-- то оно заткнется и сожрет.
-- и вот за этот бред мне очень хочется убивать.
-- причем зачастую нативно не понятно, что ему надо
-- на входе. int/unsigned int/word/long long или еще чего.

Это не бред. Это очень хорошие пинки компилятора(а он умнее, можно не спорить, это факт) глупому человеку. Каст явно режет точность числа, например double a = 2.0 не равно int b = 2 по определению представления дробных чисел. И передав 2.0 в функцию, которой нужен int. Вы уверены что хотите потерять дробную часть ? Компилятор и говорит об этом. И так со знаковыми типами. Компилятор все проверяет. И это хорошо. Если это вызывает ужас, то я думаю после знакомства с rust можно получить инфаркт.

А ещё меня раздражает, что всё так сильно перемешано по типам. Лично для меня существуют лишь следующие типы: 1 байт; 2; 4; 8; 16; 32 и 64. А как я их буду интерпретировать, не их собачье дело.

Эта идеология умерла минимум 30 лет назад. И это хорошо.

[DarkMaster]

Добавлен loadimage, image_mirror_v(по вретикали переворачивает), image_copy.
Опять переработан буфер на 10 раз. Переделан saveimage, getimage и все, что только можно.
loadimage сделан по хардкору по оффсетам. Вроде как работать должно на всех версиях и офсеты никогда не менялись. Будет смысл хоть какой-то - можно переписать с получением всех заголовков (зачем мне пока не ясно).

Удаление изображений по image = nil пока не реализовано, только deleteimage.

Сообщение отредактировал DarkMaster - 9.4.2021, 18:10

[DarkMaster]

Это не бред. Это очень хорошие пинки компилятора(а он умнее, можно не спорить, это факт) глупому человеку. Каст явно режет точность числа, например double a = 2.0 не равно int b = 2 по определению представления дробных чисел. И передав 2.0 в функцию, которой нужен int. Вы уверены что хотите потерять дробную часть ? Компилятор и говорит об этом. И так со знаковыми типами. Компилятор все проверяет

Я понимаю, когда я вместо int сую double. Речь о том, что когда ожидаются 4 байта целого и ты ему посылашь 4 байта целого, а он орет, что тип не тот, хотя там тупо через define все это переобъявлено. Если чесловек вместо int сует double, то он скорее всего идиот, уж простите =)

[Cockney]

Я понимаю, когда я вместо int сую double. Речь о том, что когда ожидаются 4 байта целого и ты ему посылашь 4 байта целого, а он орет, что тип не тот, хотя там тупо через define все это переобъявлено. Если чесловек вместо int сует double, то он скорее всего идиот, уж простите =)

Ну с другой стороны, ошибок на пустом месте тоже не бывает, так ? Значит все же не совсем те же 4 байта целого. Возможно тип знаковый. Я вот сейчас поигрался с виндовым LPCSTR и некоторыми типами из библиотеки c++ - не вижу проблем. Можно проблему как-то воспроизвести ? Кусочек кода там показать.