Программирование

[svofski]

LFSR-ом по байтам лучше. И не совсем резко и не надо ждать полчаса. Еще можно фейдить палитру в черное.

Upd: сделал через три строки, получилось просто и симпатично.

[Advertiser]

[ivagor]

По моему впечатлению так лучше.
Что касается предельности сетпикселя. Не обязательно пытаться прошибить лбом этот порог, можно обойти. Нам известна вся картинка, поэтому можно кодировать не абсолютные значения точек, а изменения относительно уже имеющегося в данной позиции цвета. Ускорение за счет того что:
1. Не будет спарок ora c\ xra c, максимум xra c
2. Можно пропускать неизменные плоскости (это главный выигрыш)
Вопрос в том, сожмется ли такой вариант не хуже абсолютного.

[svofski]

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

[svofski]

Опасение подтвердилось, сжимается заметно хуже.

- - - Добавлено - - -

Но я все-таки смог срезать 4 такта на setpixel1

[parallelno]

А если картинки сжимать не по пикселям, а по байтам будет хуже сжиматься?

[svofski]

parallelno, картинки заворачиваются в прогрессивную последовательность пикселей-полубайт. Полубайты объединяются в байты, а байты уже потом сжимаются.

[parallelno]

svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?

[svofski]

svofski, извини, но если честно то я не понял как твой ответ соотносится с моим вопросом. Если сжимать по байтово то будет хуже сжиматься?

Значит я не понял твоего вопроса. Что значит сжимать побайтово? С моей точки зрения все уже и так сжимается побайтово.

- - - Добавлено - - -

Надо ли это делать - не уверен, но если что - резерв по сжатию есть.

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

[parallelno]

svofski, я имел ввиду данные картинки в том виде в котором она лежит в видеопамяти сжать как линейный кусок памяти от $8000 до $ffff.

- - - Updated - - -

ivagor уже ответил что так хуже сжимается.

[ivagor]

Как известно, одна голова - хорошо, а две - некрасиво. Зато есть эффект.

и вскрываем резерв еще на 16 тактов

setpixel1:
                push d
                rrc \ rrc \ rrc
                mov b, a      ; b = saved a, c free 
                ani 11110b
		sta setpixel1setjmp+1
                mov a, e
                sub m
                mov e, a      ; update pixel addr 
                inx h         ; hl -> pixel mask
                mov c, m      ; c = set mask
                inx h         ; hl -> next in tile sequence
                push h        ; save hl
setpixel1setjmp:
		lhld setpixel1tab
		ldax d
		ora c
		pchl

[свернуть]

- - - Добавлено - - -

Если поменять знак у смещений возьмужек, то еще -4 такта за счет замены
mov a,e
sub m
на
mov a,m
add e