ZX Like Pascal

[Reobne]

Для проверки нажатости:
GetKeyState(VirtualKeyCode:word):boolean;
Определить константы для каждой клавиши:
ZXK_1=$f701; // старший байт порта FE и маска
Можно сделать константу и для эникей.
И ещё GetVirtualKeyCode:word, для удобства написания кода выбора игроком кнопок управления. Он вернёт код нажатой сейчас клавиши, в готовом формате для GetKeyState.

[Advertiser]

[Oleg N. Cher]

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

[Reobne]

Oleg N. Cher, Иногда модульность вредна. Человеческое сознание не беспредельно. Человеческое внимание ограничено. Заставлять программиста помнить названия модулей, каждый раз перечислять их в начале программы, может стать занудной бюрократической особенностью языка.

[AzAtom]

Сделал генератор спрайтов ZXSprGen V2.0.1.rar.

Обновлено.

[Oleg N. Cher]

Reobne, никто не заставляет ту самую модульность излишне пользовать. Просто в случае ZX Like Pascal, получается, невозможно разработать свою библиотеку, остаётся только надеяться убедить Andrew добавить то да сё в язык. Разве это хорошо? А хорошо ли иметь исходник всего в виде одной простыни? Это 70-е.

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

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

Гораздо более занудной и бюрократической особенностью языка может стать то, что непонятно какая сущность откуда приходит, что является частью языка, что библиотеки. Это я наблюдал, к примеру, в PureBasic. Да будет также известно, что в TurboPascal графика и другие особенности реализованы библиотечно.

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

[Andrew771]

Сделал генератор спрайтов ZXSprGen v1.0.rar.

классно! Только не на чем проверить, бросил бы в дистрибутив какую-нибудь тестовую картинку. Если суперский, то буду поставлять вместе с дистрибутивом ZX Like Pascal
До этого времени для конвертации спрайтов я рекомендовал пользоваться моей утилитой. Я ей сам пользуюсь всегда. Но твой конвертер наверно еще удобнее, посмотрю, перейду.

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

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

Вдруг выяснилось, что если захочется попробовать спрайты с атрибутами и без них, то придётся править все спрайты, что неудобно. Почему бы не сделать все спрайты с атрибутами, а при сброшенном флаге "спрайты с атрибутами" просто не копировать атрибуты. Да, это будет на 10% больше места занимать, но будет гораздо удобнее.

10% - это для памяти Спектрума непозволительно много. И так спрайты большую часть памяти занимают, а тут еще отгрызется 10% - пару-тройку килобайт. Лучше не надо.

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

Сейчас у меня вот, что получилось TestZXPas02.rar.

классно! Исходник бы паскалевский приложил, чтоб прочувствовать

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

Просто в случае ZX Like Pascal, получается, невозможно разработать свою библиотеку, остаётся только надеяться убедить Andrew добавить то да сё в язык. Разве это хорошо? А хорошо ли иметь исходник всего в виде одной простыни? Это 70-е.

Ассемблерные вставки можно делать сколько угодно, для этого есть оператор Asm. В Zdemo2 я вставил процедуру вывода карты 4х4 знакоместа например.
Также можно редактировать саму библиотеку libasm.lib - это обычный текстовый файл (правда, не забыть сохранить тогда резервную копию на всяк.случай).
Вот оператор свой нельзя вставить.
А чем плоха простыня, в которой всё сразу под рукой, и Паскаль, и асм, и данные все?

[Oleg N. Cher]

Тем, что когда она становится неподьёмной - ты устаёшь её листать, глаза разбегаются. Человеческое восприятие устроено так, что воспринимает информацию ограниченными порциями.

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

Наконец, удобно при проектировании больших систем. Я сейчас не о твоём Паскале, Андрей. В случае написания игры, возможно, тебе модули и не нужны, в силу специфики мышления. Но то тебе.

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

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

[s_kosorev]

Поддержка модулей-то имеется?

А в pascal модульности и не было, был include

[Oleg N. Cher]

Ну да, в виртовском Паскале так и было. В TP модульность появилась начиная с версии 4 (или 5?).

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

Концепт модульности происходит из желания разделить задачу на подзадачи. Разложить всё по полочкам, упорядочить. Процедура - это элементарная единица, а модуль - композитная, составная. Из-за нарушения принципов модульности мы имеем уродливые монолитные решения в IT, которые потребляют много памяти. Взять dll. Это самодостаточная единица? Нет. Чтобы её заюзать - нужен сишный хидер или биндинг. То есть там есть набор вызовов, а описатели параметров и проч. вынесены отдельно. Всё хранится не вместе, из-за чего получаем рассинхронизацию (старый биндинг отстаёт от новой версии). Разумеется, есть целая куча причин, по которым в электронике модульности достичь проще, чем в программировании.

[AzAtom]

Только не на чем проверить

Можно той картинкой из твоего архива.

бросил бы в дистрибутив какую-нибудь тестовую картинку

Бросил и обновил архив http://zx-pk.ru/threads/24967-zx-lik...l=1#post882316.
Ещё хорошая идея в твоей программе, указывать сколько байт получилось в массиве.

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

Исходник бы паскалевский приложил, чтоб прочувствовать

program TestZXPas;

{$APPTYPE CONSOLE} // Эта директива для работы команд ввода/вывода.
uses
  windows, ZXPas in 'ZXPas.pas';

var
  x,y:word;
  k1,k2:byte;

  GG1     :array[0..240]of byte = (24,
    0,2,  15,  7,  3,  3,  7, 29,246,155,
    0,3, 252,254,255,234,255,245,255,255,
    0,4,   0,  0,  0,  0,  0,128,128,128,
    1,1,   3,  7,  6, 14, 15, 31, 63, 63,
    1,2, 237,119,183,191,127,237,246,123,
    1,3, 227,240,248,248,252,252,254, 95,
    1,4, 128,  0,  0,  0,  0,  0,  0,  0,
    2,1, 127,126,124, 63, 63, 31, 15,  7,
    2,2, 104,223,254,253, 94,255,245,239,
    2,3,   1,255, 71,255,127,234,103,243,
    2,4,  12,255,255,170,255,224,224,128,
    2,5,  64,240,240,188,224, 64, 56,  0,
    3,1,   3,  0,  0,  0,  0,  1,  1,  1,
    3,2,  31,255,255,255,255,252,252,252,
    3,3, 248,252,254,255,255,255,127, 31,
    3,4,   0,  0,  0,  0,128,192,224,240,
    4,1,   1,  1,  3,  7, 14, 29, 51,103,
    4,2, 120,184,112,240,240,224,192,128,
    4,3,  15,  3,  1,  1,  0,  0,  0,  0,
    4,4, 184, 88,176,248,184,184,216, 92,
    5,0,   0,  0,  0,  1,  1,  1,  1,  1,
    5,1, 206,220,248,240,112,248,254,127,
    5,4, 108, 44, 60, 60, 46,127,127,103,
    5,5,   0,  0,  0,  0,  0,128,224,240);

  ball1:array[0..40]of byte = (4,
    0,0,   3, 15, 31, 51,103,111,255,  0,
    0,1, 224,248,252,254,255,255,255,  0,
    1,0, 255,111,103, 51, 19, 15,  7,  0,
    1,1, 255,255,254,254,252,248,240,  0);

  mapspr:array[0..41*5-1]of byte = (
    4, // Стена
    0,0,   0,  0,  0,  0,  0,  0,  0,  0,
    0,1,   0,  0,  0,  0,  0,  0,  0,  0,
    1,0,   0,  0,  0,  0,  0,  0,  0,  0,
    1,1,   0,  0,  0,  0,  0,  0,  0,  0,
    4, // Кирпич
    0,0,  85,  1,  1,255, 85, 16, 16,255,
    0,1,  85,  1,  1,255, 85, 16, 16,255,
    1,0,  85,  1,  1,255, 85, 16, 16,255,
    1,1,  85,  1,  1,255, 85, 16, 16,255,
    4, // Основание колонны
    0,0,  36, 36, 36, 36, 36, 36, 36, 36,
    0,1,  36, 36, 36, 36, 36, 36, 36, 36,
    1,0,  36, 36, 36, 36, 72,136,136,255,
    1,1,  36, 36, 36, 36, 18, 17, 17,255,
    4, // Середина колонны
    0,0,  36, 36, 36, 36, 36, 36, 36, 36,
    0,1,  36, 36, 36, 36, 36, 36, 36, 36,
    1,0,  36, 36, 36, 36, 36, 36, 36, 36,
    1,1,  36, 36, 36, 36, 36, 36, 36, 36,
    4, // Верхушка колонны
    0,0, 127,144,136, 72, 36, 36, 36, 36,
    0,1, 254,  9, 17, 18, 36, 36, 36, 36,
    1,0,  36, 36, 36, 36, 36, 36, 36, 36,
    1,1,  36, 36, 36, 36, 36, 36, 36, 36);

  map:array[0..15,0..11]of byte = (
    (4,3,3,3,3,3,3,3,3,3,2,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (0,0,0,0,0,0,0,0,0,0,0,1),
    (4,3,3,3,3,3,3,3,3,3,2,1));

  dig0:array[0..10]of byte = (1, 0,0,   0, 28, 34, 42, 42, 34, 28,  0);
  dig1:array[0..10]of byte = (1, 0,0,   0, 24, 56, 24, 24, 24, 60,  0);
  dig2:array[0..10]of byte = (1, 0,0,   0, 60, 66,  2, 28, 32,126,  0);

begin
  // Инициализация модуля ZXPas. Флаги соответствуют галкам компилятора.
  ZXPas.init(true,true,false,true,true,true,true,true);
  // Далее можно писать программу для ZX Like Pascal

  border(0);
  textbackground(0);
  textcolor(7);
  clrscr;
  VirtScreenClear;

  MapSet(map[0,0],mapspr,0,0,32,24);

  x:=4;
  y:=1;
  repeat
    VirtScreenClear;
    MapPut(0,0);
    SpritePutClear(ball1,10,x);
    SpritePutClear(GG1,x,16);
    SpritePutClear(ball1,12,2);
    ReadKey(k1,k2);
    if (k1=49) or (k2=49) then SpritePutClear(dig1,4,4) else SpritePutClear(dig0,4,4);
    if (k1=50) or (k2=50) then SpritePutClear(dig2,6,4) else SpritePutClear(dig0,6,4);
    VirtScreenPut;
    Delay(1);
    x:=x+y;
    if (x>19) or (x<4) then y:=-y;
  until (k1=48) or (k2=48) or (k1=32) or (k2=32);

  ZXPas.Deinit;
end.

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

а тут еще отгрызется 10% - пару-тройку килобайт.

Это да... Но с другой стороны, много ли игр двухцветные, а по сути одноцветные? Обычно только часть спрайтов может быть без своих атрибутов и принимать другие атрибуты. А спрайты ГГ, врагов и подобные будут разноцветные, так что, впустую потратится не 2-3 КБ, а гораздо меньше. Думаю, это приемлемо. По крайней мере, есть повод подумать над этим.

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

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