Расширенный colormode, с "правильными" цветами.

[dramster]

 Многие помнят ту тему, где обсуждали существующий колормод, где была раскрыта тайна его работы, и эта тема была удалена. Я после этого еще долго ломал голову над тем, как должна работать коррекция. В итоге, перечитав кучу инфы (впустую), потратив кучу времени на различные комбинации, расчеты и пр. - иии, ПРОФИТ  . Конечно работает он не так изящно и быстро как оригинальный, но зато появляется больше возможностей. Да и сам алгоритм оказался не таким уж и сложным, пару битовых операций, и готово.
 
 Написал это все на км, скорость все равно подводила  . А тут наконец удалось заставить работать DLL библиотеки. Переписал все это дело в делфи. Скорость вполне себе ничего вышла, мой калькулятор справляется с областью (0, 0, 1000, 100)=100кпикс за 1.5сек. При этом пишет это все сразу в память км.

 Небольшое описание:

Режимов в моем случае - 23. С каждым следующим режимом добавляется один бит на пиксель.
Режимы коррекции-
1   - 2 цвета
2   - 4 цвета
3   - 8 цветов
4   - 16 цветов
5   - 32 цвета
.... и так далее, до 23 - 8388608 цветов

как выглядят обработанные изображения:

оригинал


по нарастающей, до двенадцатого режима
                     
и так далее...

Написано строго под версию 4.13.014b. При первом вызове подпрограммы, произведется поиск адреса начала графического буфера км, занимает пару секунд. Далее работает довольно быстро.
Интересно, как поведет себя данная процедура на других ПК.

Код пока не буду выкладывать, пусть побудет у меня  .

Пример вызова:

Code: (clickermann) [Select]

SUB(s_cmode, $x1_cm, $y1_cm, $x2_cm, $y2_cm, $mode_cm)
   IF($adress_cm = 0)
      $pid_cm = HGETPID($_hwnd_self)
      PXLREPLACE (0, 0, $_xmax, $_ymax, -1, 0)
      PXLREPLACE (0, 0, 0, 0, -1, 1234567)
      CALL("adress_clip.dll", $pid_cm)
      $adress_cm = $_return1
      GETSCREEN
   END_IF
   CALL("c_mode.dll" ,$x1_cm, $y1_cm, $x2_cm, $y2_cm, $mode_cm, $pid_cm, $adress_cm, $_xmax)   
END_SUB
///////////////////////////////////////////////////////


$x1 = 540
$y1 = 310
$x2 = 780
$y2 = 460

GETSCREEN
//вызов
s_cmode($x1, $y1, $x2, $y2, 3)

SCREENSHOT // смотрим
   

halt
Естественно, длл-ки в одной дерриктории со скриптом. Две библиотеки во вложении. У кого фобия к неизвестным длл, проходим мимо  .

Знаком с делфи всего пару дней, так что скорее всего буду совершенствовать эти библиотеки по мере моих способностей.

[Johnny]

госпади, уже в память кликера лезут...
пару дней с делфи знаком, а артмани написал.

методу поиска пиксельной карты я оценил, но смотри за границы не выпрыгни, а то все сломаешь.
у getscreen так то и параметры могу быть, сужающие поле зрения до точки

но вообще талантливо

[Vint]

А при чём параметры getscreen? Они же только сканирование ограничивают. Буфер какой был во весь экран, такой и есть.
Или в 4.13 всё изменилось?

[Johnny]

А при чём параметры getscreen? Они же только сканирование ограничивают. Буфер какой был во весь экран, такой и есть.
Или в 4.13 всё изменилось?

немного не так выразился. точнее выразился с точки зрения "внутренностей", раз уж в них полез автор.
буфер то "во весь экран". но он адаптируется в зависимости от текущего разрешения этого самого экрана. если вы запустили кликер из винды, а потом решили побегать в quake II в 640х480 то буфер будет уменьшен относительно исходного рабочего стола. и получив изначально указатель на начало и рассчитанный размер матрицы, при смене разрешения плагин получит классический "range out"

[dramster]

госпади, уже в память кликера лезут...
пару дней с делфи знаком, а артмани написал.

 Да ладно, цикл перебора адресов в определенном диапазоне и сравнения их значений с тем что мы вписали в память, тут сильно много ума не надо. Скорее всего это нужно было сделать как то более правильно, ...но и так работает  . А в память то мы уже полезли давно, начиная еще вот отсюда http://crapware.aidf.org/forum/index.php?topic=2134 . В версии 4.12 было хорошо, там был указатель на начало буфера в памяти. В 4.13 так уже не прокатывает, пришлось писать "артмани".

 А насчет смены разрешения во время работы, так это мне както ни разу в голову и не пришло  . Как то даже ни разу не тестил как себя кликер ведет в таких случаях.

 А вообще, хотелось показать, что возможности кликермана безграничны. И если что либо не реализуемо встроенным функционалом, то никто вам не мешает написать нужное в другом языке и подключить это с помощью длл.
 Тут кстати вам и шифрование готовое, какие то определенные куски кода закинули в длл, и все проблемы  .

[Vint]

С размером буфера может быть проблема только в полноэкранных приложениях.
Но кто пишет скрипты под fullscreen, тот сам себе злобный буратино. Там и с остальным беда.
Только оконный режим является тру для любого советского гражданина!

[James]

Я бы тоже постарался воткнуть что - нибудь в кликер при помощи dll написанной на C#, но не по цветам конечно, эта тема для меня сложна прилично так
Только вот в C# дллки какие - то неподключаемые чтоли, неужели даже в delphi они нормальные, а в шарпе нет