LASER BASIC 2

[Barmaley_m]

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

[Oleg N. Cher]

Справедливо, и я согласен. Для того и поменял. Такты, правда, не считал, но более чем уверен, что скорость познакоместного вывода спрайтов всегда выше, чем построчного, для ширины < 8 и, как минимум, не ниже для > 8. Но с уточнением: если при выводе используется логическая операция. И, как следствие, нельзя использовать LDI или вывод стеком.

Кто-нибудь поделится подпрограммами для пиксельного скроллинга знакоместных окошек? Интересует прямой и циклический скроллинг, с буфером или без, горизонтальный на 1, 2, 4 и 8 пикселей и вертикальный на 1. Без атрибутов. Можно конечно взять процедуры Лазер Бейсика как есть, но надо хотя бы посмотреть, насколько они эффективны. Это как бы следующий этап моей работы (над игрой).

Также наверное интересует зеркалирование (эффект mirror) знакоместных окошек.

P.S. Процедурка PutSprite вроде удачная получилась, да? По кр. мере никто не ругался и не обзывал код ламерским. ;-) Даже мудрый жерри (Destr хело!), который пробегал мимо, не к ночи буде упомянут. ;-)

[newart]

А вывод спрайтов с прозрачными знакоместами будет? Как в книге "как написать игру".

[drbars]

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

SPRT_CHAR_IN$: LD A, (HL)
SPRT_MODE_IN$: NOP ; NOP | AND (HL) | OR (HL) | XOR (HL)
LD (DE), A

Тут берётся байт спрайта, затем делается наложение байта спрайта самого на себя?

Наложение на экран делается иначе. Взятый байт экрана, накладывается на байт спрайта и возвращается на экран.

[Oleg N. Cher]

drbars, издеваетесь? Это просто опечатка в логике. Вот что значит код не тестировать. Исправим.

Вывод спрайтов с прозрачными знакоместами не планируется. Я прикинул, что мне нужны такие процедуры:

ATON ATOF PTBL PTOR PTND PTXR
INVM
INVV MIRV SETV CLSV
WL1V WR1V WL4V WR4V WL8V SL1V SR1V SL4V SR4V SL8V SR8V
WCRV SCRV
AWLV

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

Я переписал спрайтовую демку, выложенную SfS в теме Спрайты, ps/2 и куча утилит, заменив его процедуру на свою, получается и экономия байтиков, и рост скорости вывода:

DemoSpr 7520 байт
DemoSpr2 7461 байт

Laser2Demo.zip

Такты не знаю как мерять. Если кто займётся, было бы интересно сравнить.


SfS, я оптимизировал Ваш спрайтовый вывод в двух местах. Там DEC B: JR NZ нужно изменить на DJNZ. И при переходе к следующему знакоместу можно использовать INC L вместо INC HL, получится быстрее. Ну а то, что там построчно выводится, так упс. Просто берите мою процедуру, это самое удачное в этом весе, что я встречал. ;-)

Да, ещё там как-то странно вычисляется адрес атрибутов, но спишем это на возможность работы со вторым экраном.

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

Исправил.

[Oleg N. Cher]

Реализовал INVM, INVV, SETV и CLSV.

В принципе, всё, что мне было нужно, есть здесь:

• http://zxpress.su/book_articles.php?id=1026

• http://zxpress.su/book_articles.php?id=1027

Но я не стал передирать код буквально, а переосмыслил. И, думаю, мои процедуры при самом незначительном росте размера обходят приведённые в книге "Как написать игру на ассемблере для ZX Spectrum" по скорости. Хотя такты, опять же, точно не считал.

[Advertiser]

[drbars]

Oleg N. Cher, я думаю в процедуру отрисовки спрайта стоит добавить возможность зеркалирования используя таблицу в 256 байт. Для игр это необходимо.

		LD HL,MIRROR_TAB	; Таблица зеркалирования (адрес кратен 256)
		LD B,#00
MIRR_L1		LD A,L
		LD C,#08
MIRR_L2		RLA
		RR E
		DEC C
		JR NZ,MIRR_L2
		LD (HL),E
		INC L
		DJNZ MIRR_L1
		RET

Зеркальный вывод байта спрайта LD:

		LD B,high MIRROR_TAB

		LD C,(HL)
		DEC L
		LD A,(BC)
		LD (DE),A
		INC E

Зеркальный вывод байта спрайта OR:

		LD B,high MIRROR_TAB

		LD A,(DE)
		DEC E
		LD C,A
		LD A,(BC)
		OR (HL)
		LD (HL),A
		INC L

[Sinner]

А будет LASER BASIC 2 совместим с LASER BASIC хотя бы на уровне исходных кодов?
Оригинальный LB был когда-то широко распространён и описан в ранней Р.Ф. в литературе, имевшей широкое хождение.

Если, напротив, общего останется - одно название, то зачем его вообще "заимствовать"?

Первый LB, кажется, мог быть использован просто как компилятор чистого Spectrum Basic. Только, опять же, кажется, не работал корректно на 128k-машине, на 48k не давал использовать User Defined Graphics (режим Graph (CS + 9))...

Будет ли LASER BASIC 2 компиляторм Spectrum Basic'а, но лишённым этих ограничений оригинала?

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

А будет LASER BASIC 2 совместим с LASER BASIC хотя бы на уровне исходных кодов?

Имею в виду - на уровне интерпретатора.

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

оригинальный LASER BASIC я вообще не рассматриваю как серьёзный инструмент для разработки - на сегодняшний день есть более совершенные средства, генерирующие настоящий машинный код (в отличие от интерпретатора или компилятора LASER BASIC в пи-код). Поэтому я беру только принцип.

А как работал LASER Compiler - компилил пи-код вместе с интерпретатором - ну если говорить упрощённо, для людей весьма далёких от низкого уровня, таких как я и ещё с полдюжины людей здесь? Об этом ли говорилось в литературе года 92-94-го, когда писали, что существующие на тот момент компиляторы приписывают себя или свою часть, содержащую определённые процедуры, к самому скомпилированному коду, а также ни один из известных на тот момент в России компиляторов не поддерживал полностью полный набор инструкций интерпретатора Spectrum Basic? Почти дословно так писали в "Диалектах Бейсика для ZX Spectrum", "Как написать игру для ZX Spectrum на языке BASIC" и т.п.

[goodboy]

А как работал LASER Compiler - компилил пи-код вместе с интерпретатором - ну если говорить упрощённо, для людей весьма далёких от низкого уровня, таких как я и ещё с полдюжины людей здесь?

очень похоже что после `компиляции` исходный текст программы практически неменяется. скорее он более быстро (по сравнению с родными процедурами) обрабатывается.
Oleg N. Cher только сотрясает воздух, показать что-то уровня HeartBroken или Venturama он не способен,
а эти игры практически целиком на скомпиленном бейсике, компилятор 83его года !!!

а авторы книжек вероятно не знали про HisoftBasic http://www.worldofspectrum.org/infos...cgi?id=0008249
вот игра сделанная на нём http://www.worldofspectrum.org/infos...cgi?id=0018540

[Oleg N. Cher]

А будет LASER BASIC 2 совместим с LASER BASIC хотя бы на уровне исходных кодов?

Нет.

Первый LB, кажется, мог быть использован просто как компилятор чистого Spectrum Basic. Только, опять же, кажется, не работал корректно на 128k-машине, на 48k не давал использовать User Defined Graphics (режим Graph (CS + 9))...

Вертикальный скроллинг оригинального LB использует буфер принтера для своей работы. В версии Михайлова/Мазницы, а также в LASER BASIC 2 это исправлено и есть возможность задавать экран или буфер для графического вывода.

Будет ли LASER BASIC 2 компиляторм Spectrum Basic'а, но лишённым этих ограничений оригинала?

Нет. Я не вижу смысла разрабатывать компилятор Бейсика. LB2 как графическую библиотеку можно использовать из Оберона, Си и ассемблера.

А как работал LASER Compiler - компилил пи-код вместе с интерпретатором - ну если говорить упрощённо, для людей весьма далёких от низкого уровня, таких как я и ещё с полдюжины людей здесь?

Там пристёгивался большой кодовый блок, а операторы Бейсика и Лазер Бейсика компилировались в его вызовы, по-моему, в шитый байт-код с прямой или косвенной адресацией, хотя я не уверен. Это уже не столь интересно, ибо: a) сильно медленнее машкода; b) пристёгиваются все графические подпрограммы, даже неиспользуемые.

Если, напротив, общего останется - одно название, то зачем его вообще "заимствовать"?

Я заимствую название, ибо народ падок до слов и названий - от слова "Паскаль" млеет, а от слова "Оберон" морщится. Хотя по сути это почти одно и то же. А вообще - имею право, как автор. Я беру название LASER BASIC чтобы показать полную преемственность при работе с графикой. По сути же это не язык, не интерпретатор, просто графический движок. Как его ещё назвать, если он по сути и есть Лазер Бейсик, начиная с названий процедур и заканчивая логикой их работы?

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

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

goodboy, мели-мели языком, я вообще не гейммейкер. А ты небось лопатой копать соревноваться с экскаватором заманаешься. Кстати, это надо ещё доказать, что эти игры "практически целиком на скомпиленном бейсике, компилятор 83его года !!!", потому что это баян, такой же как "Буратина на лазер бейсике". Проверяется элементарно, за две минуты в дебаггере.

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

если говорить упрощённо, для людей весьма далёких от низкого уровня, таких как я и ещё с полдюжины людей здесь?

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