ZX Like Pascal

[Reobne]

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

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

KEY_1	EQU 0FEF7H
KEY_2	EQU 0FDF7H
KEY_3	EQU 0FBF7H
KEY_4	EQU 0F7F7H
KEY_5	EQU 0EFF7H
KEY_0	EQU 0FEEFH
KEY_9	EQU 0FDEFH
KEY_8	EQU 0FBEFH
KEY_7	EQU 0F7EFH
KEY_6	EQU 0EFEFH
KEY_Q	EQU 0FEFBH
KEY_W	EQU 0FDFBH
KEY_E	EQU 0FBFBH
KEY_R	EQU 0F7FBH
KEY_T	EQU 0EFFBH
KEY_P	EQU 0FEDFH
KEY_O	EQU 0FDDFH
KEY_I	EQU 0FBDFH
KEY_U	EQU 0F7DFH
KEY_Y	EQU 0EFDFH
KEY_A	EQU 0FEFDH
KEY_S	EQU 0FDFDH
KEY_D	EQU 0FBFDH
KEY_F	EQU 0F7FDH
KEY_G	EQU 0EFFDH
KEY_EN	EQU 0FEBFH
KEY_L	EQU 0FDBFH
KEY_K	EQU 0FBBFH
KEY_J	EQU 0F7BFH
KEY_H	EQU 0EFBFH
KEY_CS	EQU 0FEFEH
KEY_Z	EQU 0FDFEH
KEY_X	EQU 0FBFEH
KEY_C	EQU 0F7FEH
KEY_V	EQU 0EFFEH
KEY_SP	EQU 0FE7FH
KEY_SS	EQU 0FD7FH
KEY_M	EQU 0FB7FH
KEY_N	EQU 0F77FH
KEY_B	EQU 0EF7FH

KEYTEST
	pop hl
	inc hl
	ld a,(hl)
	inc hl
	in a,(0feh)
	or (hl)
	inc hl
	inc a
	RLCA
	AND 1
	ld (_KEYPRESSED),a
	jp (hl)

_KEYPRESSED defw 0

использовать нужно так(проверка пробела):
asm(keytest)
asm(key_sp);
if keypressed<>0 then game_state:=1;

Именно два вызова подряд. Второй вызов это не вызов, а передача константы.
Переменная keypressed возвращает 0-не нажато или 1-нажато.

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

На счёт проверки коллизий, тоже есть идея, как сделать это проще. Завести матрицу 32 на 16, и там хранить номер объекта, и нужно-ли очистить это знакоместо. Две проблемы сразу решатся.

Завтра попробую написать.

[ALKO]

Неплохо. Но для диагональных перемещений высокоуровневые IF-ы всё равно нужны.
Проверить клавишу то я проверю, но ведь там отличается затирание следа атрибутами при том или ином направлении.
А если делать выше указанным методом, то персонаж будет летать ступеньками, а не диагоналями. То бишь вложенные IF-ы таки нужны.

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

Процедура затирания следа от персонажа усложняется ещё тем, что сам персонаж не все знакоместа отведённого ректангла использует (в виду экономии памяти и скорости обновления).

[Reobne]

Писал-писал, но не дописал.
Написал процентов 80. Конец уже виден.
Вечером постараюсь выкроить ещё время.

Стараюсь добавлять комментарии. Патчу встроенные процедуры. (Возможности написать свою библиотеку, аналогичную встроенной, сильно не хватает.) Процесс идёт...

[Reobne]

Закончил писать, начал отлаживать.
И сразу заметил, что клавиатурный проверятель работает не совсем удобно, ноль правильно выдаёт, когда не нажато, а когда нажато - всякий разный неноль. А хотелось-бы чтобы именно 1. Исправил

[Reobne]

ALKO, Доотлаживал, добился что прога запустилась. Прислал по почте.

Andrew771, Пока отлаживал, заметил, что иногда оптимизатор LikePascal-я влияет на логику. Когда результат работы с однобайтовой переменной остаётся двубайтовый в HL. При переполнении старший байт изменяется, естественно не сохраняется в ячейке переменной, но используется в следующих операциях.

Как илюстрация, иногда этот IF сработает:
byte1:=byte1-dby;
if byte1=65535 then

Когда команды идут сподряд. А если их разбить, вставив между ними что нибудь, то уже не сработает. Так как произойдёт повторная загрузка из ячейки byte1, с обнулением старшего байта. И тут уже нужно сравнивать с 255.

[Andrew771]

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

[Advertiser]

[Reobne]

Если переменная однобайтовая, то зачем ее сравнивать с 65535?

Для илюстрации.
Переменная равна 255, но сравнивать её с 255 бесполезно.
Перечитай моё сообщение внимательнее.
За переполнением мы прекрасно следим, и знаем что у нас, при отнимании 1 от нуля должно получиться 255.

[Andrew771]

Переменная равна 255, но сравнивать её с 255 бесполезно.

Ты писал про 65535, а не 255. С 255 нормально сравнится.

За переполнением мы прекрасно следим, и знаем что у нас, при отнимании 1 от нуля должно получиться 255.

Отрицательные числа этим Паскалем сейчас не поддерживаются, так что лучше не получать заведомо отрицательные числа. Про переполнение думаю в будущей версии, чтоб было, как правильно (0-1=255).

[Bolt]

Andrew771, он вот про что:

byte1:=byte1-dby;

переменная типа byte, в ней значение 0...255, даже если ушли в минус

if byte1=65535 then

значение типа byte никогда не будет равно 65535, но результат сравнения при определённых условиях всё-таки true из-за оптимизаций в компиляторе.

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

Reobne, может и мою поделку потестируешь?

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

Отрицательные числа этим Паскалем сейчас не поддерживаются, так что лучше не получать заведомо отрицательные числа.

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

var x,y:longword;
begin
   x:=0;
   if (x-1)=$FFFFFFFF then ...
   y:=$FFFFFFFF;
   if (y-1)=$FFFFFFFE then ...
end.

Попробуй представить ассемблерный код, который учтёт, что X-1=-1 и это -1 не равно $FFFFFFFF, а вот Y-1 всё-таки равно $FFFFFFFE.

[Reobne]

Попробуй представить ассемблерный код, который учтёт, что X-1=-1 и это -1 не равно $FFFFFFFF, а вот Y-1 всё-таки равно $FFFFFFFE

Это будет уже больше чем Паскаль. В обычном Паскале к этому относились проще. Хотя это позорная неоднозначность, заставляет программиста делать эксперименты, чтобы проверить как именно работает конкретный компилятор. Если он будет вычислять в 32битной арифметике, то результат один, а если приведёт всё к 64-битным числам, то другой.
А ты хочешь сделать действительно математический Паскаль. Такой Паскаль должен решать эту проблему на этапе компиляции. Он должен действительно понимать, что такое типы, и каковы их интервалы с математической точки зрения. По идее он должен воспринимать какие угодно большие константы. byte должен быть интервальным типом 0..255, shortint = (-128..127), и так далее.
Такой компилятор, на этапе компиляции поймёт, что в результате вычисления (x-1) получатся числа в интервале -1..$fffffffe, и это число будет заведомо не равно $ffffffff, а значит, такой IF вообще можно не кодировать.
Такой компилятор, также в принципе правильно обработает условие x<834658348562893465823648526348956328465893648563 48. Хотя нет фиксированного типа, в котором можно было-бы сохранить такую константу, но на этапе компиляции видно, что условие будет выполнено всегда.