ZX Like Pascal

[Andrew771]

А вот реально, проверка бит не помешала бы.

Тебе уже на ассемблер нужно переходить

Как такое сделать в данном паскале?

repeat
anim:=anim+1;
if anim>3 then anim:=0;
case anim of
0: огонек_0, алиса_0;
1: огонек_1, алиса_0;
2: огонек_0, алиса_1;
3: огонек_1, алиса_1;
end;
until...

Хотя, если огонек и алиса независимы, то лучше две переменных юзать.

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

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

Заведи обычный массив. Генери в нем рандомно и/или обнуляй неиспользуемые. Нулевые позиции не выводи.

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

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

Заведи обычный массив. Генери в нем рандомно и/или обнуляй неиспользуемые. Нулевые позиции не выводи.

[Advertiser]

[ALKO]

.Заведи обычный массив. Генери в нем рандомно и/или обнуляй неиспользуемые. Нулевые позиции не выводи.

Дофига проверок. А мне нужен шустрый скролл при этом.

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

Прост с таким подходом придётся в цикле по массиву шерудить в поисках неиспользуемого.

[Andrew771]

Ну если препятствий 5-10 штук, то можно и массив перебрать, недолго. А если больше, то проще завести карту. Операторы (процедуры) для карт имеются.

[ALKO]

Ещё есть некоторые замечания по СпрайтГену.
Во-первых, он генерит инверсно. То есть чёрный цвет на BMP-шке для него будет нулевым битом, что при чёрном INK и белом Paper спектрума тождественно белому пикселю.

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

[ALKO]

Что я делаю не так по атрибутам?
Почему-то ресетится прога.

код в писькале

attrx:=1;
attry:=1;
asm(ATTR);

код в блоке асма

ATTR
LD B, _ATTRY
LD C, _ATTRX
; расчет адреса атрибутов знакоместа в DE, B-вертик.координата, C-гориз.координата
LD A,B
RRCA
RRCA
RRCA
LD E,A
AND 31
OR 88
LD D,A
LD A,E
AND 252
OR C
LD E,A
LD (DE),0
RET

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

хмм... ща ищу доки по Z80... кажись LD (DE) берёт значения только с аккумулятора.
Или я чёто путаю...

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

Наверное всё-таки надо присвоить в аккум. значение цвета

LD A, 0
LD (DE), A

Так ведь? Ща прост не за компом, не могу проверить.

[Andrew771]

Ещё есть некоторые замечания по СпрайтГену.
Во-первых, он генерит инверсно. То есть чёрный цвет на BMP-шке для него будет нулевым битом, что при чёрном INK и белом Paper спектрума тождественно белому пикселю.
Во-вторых он генерит неиспользуемые знакоместа в том числе, что приходится вручную подчищать, и менять в инициализации общее количество знакомест. Тоже малость неудобно.

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

Что я делаю не так по атрибутам?
Почему-то ресетится прога.

В тексте программы на асме Ттолько метки в начале строки должны быть, а команды не в начале строки, иначе они воспринимаются как метки.
Команды ld (de),0 не существует, так что ты правильно написал:
ld a,0
ld (de),a
Правда, принято у продвинутых перцев вместо ld a,0 писать xor a, команда занимает 1 байт и выполняется быстрее.
А в данной процедуре можно заменить во всех командах de на hl (т.е. d на h, e на l), тогда можно будет написать одной командой ld (hl),0, такая команда есть.

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

Так что было бы правильнее не ректанглом копировать фон в память, а по контуру знакомест спрайта.

Не факт, что будет быстрее копировать. Т.к. нужно бегать по всему спрайту, вычислять координаты каждого знакоместа. А так прямоугольная область копируется ldir-ами. Вычисляются только адреса начала строк.

[ALKO]

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

При рисовании спрайта так или иначе придётся вычислять адреса. Почему бы не сделать копирование прямо в цикле рисования спрайта?
То бишь - копируем байт фона (полосочку пикселей 8х1), затем сразу же шлёпаем полосочку спрайта 8х1 на экран. И так до конца знакоместа....
А впрочем, вам виднее. Я ж вообще нубасик в таких вещах.

[Andrew771]

При рисовании спрайта так или иначе придётся вычислять адреса. Почему бы не сделать копирование прямо в цикле рисования спрайта?
То бишь - копируем байт фона (полосочку пикселей 8х1), затем сразу же шлёпаем полосочку спрайта 8х1 на экран. И так до конца знакоместа....
А впрочем, вам виднее. Я ж вообще нубасик в таких вещах.

Это уже выходит за рамки Паскаля. Либо надо плодить новый нестандартный оператор для спрайтов.

[ALKO]

Либо надо плодить новый нестандартный оператор для спрайтов

Ну вот я про это и говорю, что для СДК надо бы функционал расширить, тогда был бы спрос, и все бы резко отвыкли от AGD и MK2

[haywire]

Серьёзного спроса на подобные продукты уже не будет никогда. Кое-какой спрос (среди любителей ретро) был бы, если бы реализация Паскаля была не настолько "урезанной". В первую очередь это касается обещанной нормальной работы с процедурами - локальные переменные, аргументы, работа со стеком. А спрайты в Паскале на 8-и битах - интересно как эксперимент, конечно, но они тут не нужны, вообще. Их и на 16-и то битах никто никогда не делал, потому что не нужно это тут, а если и нужно, то только после нормальной реализации языка.