Sprite graber - проба пера

[Alex Rider]

Работа над сабжем начата с глубочайшего рефакторинга, ибо внутри слишком много скотча. Надеюсь выпустить релиз с хотелками после новогодних каникул. Будет более лучший GUI (текущий страдает пережитками Капульцевича, посему переписывается чуть более, чем полностью). Будет несколько форматов хранения и опциональное включение разного кода в выгружаемый модуль.
Вопрос: а как отнесется общественность к 128-фикации грабера? (это не относится к выгружаемым модулям).

[drbars]

Работа над сабжем начата с глубочайшего рефакторинга, ибо внутри слишком много скотча. Надеюсь выпустить релиз с хотелками после новогодних каникул. Будет более лучший GUI (текущий страдает пережитками Капульцевича, посему переписывается чуть более, чем полностью). Будет несколько форматов хранения и опциональное включение разного кода в выгружаемый модуль.
Вопрос: а как отнесется общественность к 128-фикации грабера? (это не относится к выгружаемым модулям).

48K это глубокий андерграунд, поэтому 128К — норма для утилит (особенно спрайтовых).

И спасибо за труды, это позволяет полностью погрузиться в написание игры и не отвлекаться (пока) на утилиты.

зы. пока не смотрел, но есть ли возможность переделать dehrust чтобы на лету на экран спрайт распаковывал?
Уж больно не хочется буфер выделять под распаковку спрайта.

[Alex Rider]

зы. пока не смотрел, но есть ли возможность переделать dehrust чтобы на лету на экран спрайт распаковывал?

Не уверен что это сделать просто и получится быстро. Говорят, он использует историю уже распакованного в процессе работы и надеется, что распакованный блок непрерывен в памяти. Да и вообще говоря, идея упаковки спрайтов по отдельности мне не нравится. Вижу такие минусы:

• упаковка отдельных маленьких спрайтов будет менее эффективна, чем упаковка спрайт-файла;
• распаковка спрайта на экран добавит тормозов (особенно при многократном выводе одного и того же запакованного спрайта), что не надо совсем;
• спрайты обычно хорошо группируются по области программы - общие спрайты, уровень 1, уровень 2, ..., меню, funal cut. Эффективнее паковать их группами и распаковывать при необходимости.

[drbars]

Да смысл в том, чтобы распаковать сразу на экран без распаковки в буфер. Всегда чем-то жертвовать приходится.

Я сейчас как раз работаю над пакетом процедур для вывода спрайтов.

[Alex Rider]

Да смысл в том, чтобы распаковать сразу на экран без распаковки в буфер.

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

[drbars]

В соседнем топике уже решили, что лучше всего использовать для компресии.
http://zx.pk.ru/showpost.php?p=561732&postcount=10

Вот, можешь интегрировать в свой граббер этот способ сжатия.

[Alex Rider]

Вот, можешь интегрировать в свой граббер этот способ сжатия.

Читал. Пока не буду. Пока надо собрать базоывй функционал на новом UI. ПОтом в планах последовательно:

1. выделение с точностью до пикселя;
2. вращенияя/отражения/скролл выделенной области;
3. яркостная сетка;
4. help;
5. менеджер памяти;
6. автомаска;
7. разные форматы хранения и кастомизированный набор процедур для вывода в выгружаемом модуле;
8. улучшенная работа с диском (каталог, смена дисковода, сохранение опций грабера, например)

[Alex Rider]

Пользуясь случайным интересом к сабжу, выложу последнюю версию с фиксом одной проблемы, найденной AER (спасибо ему!)

upd: версия в первом посту

[goodboy]

выложу последнюю версию с фиксом одной проблемы

случайно не порча цветных спрайтов ?

[Alex Rider]

Да, при захвате атрибутов нижней трети они брались из верхней. Опечатка в исходнике Если кто-нить (еще кроме меня) проверит работоспособность, я буду весьма рад и спокоен.