BattleCity демо-недоделка

[NEO SPECTRUMAN]

структурированных сайтов,

близко нет
все в перемешку

есть некоторые сайтеке
которые содержат большой набор процедур для матана
просто для z80

не факт что оптимизированные и оптимальные...


может чего то я не знаю
и за пару лет все изменилось?

вангую что воз и ныне там

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

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

про хранение "змейкой" и для общего развития
прочитай эту статью
https://zxpress.ru/article.php?id=8659

тоже иногда можно применять

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

Нужно время, чтобы переосмыслить полностью.

смысл таков
забываем про десятичные цифры при размышлении
и переходим на шестнадцатеричные и двоичные

осмысляем выравнивание по кратным адресам и как этим пользоватсо
ну и таблицы с любым количеством переменных в любой форме и в любом направлении

представляем память спека как квадрат 256х256 с координатами H и L...
а не как "с 32768 на резинке у нас быстра память"...

итд...

и будет вам счастие

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

В качестве авторитетного примера приведу вот эту поделку alone coder-а

(вертикальные столбцы это младшие 256 байт)

где видно что видео буфер лежит "вертикально" а в образовавшихся щелях понапихано еще

в моем представлении
$0000 верхний левый угол
$FFFF нижний правый

а тут все повернуто на 90 градусов

да и термины типа нижняя\верхняя память не люблю
пушо как по мне вверху должен быть и так естественней адрес 0
а называют совершенно на оборот...

[Advertiser]

[Biland]

а не проще бегло просмотреть готовые BattleCity (на вирте их штук 10) ?

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

про хранение "змейкой" и для общего развития
прочитай эту статью
https://zxpress.ru/article.php?id=8659

тоже иногда можно применять

Да, интересный метод. В голове проскакивала мысль об управление битами при смещении, а здесь более подробно метод описан, 26 тактов на байт, без стека. А со стеком

pop bc ;10
ld (hl),b ;7
inc l ;4
ld (hl),c ;7
set/res N,l;8

pop bc ;10
ld (hl),c ;7
dec l ;4
ld (hl),b ;7
set/res N,l ;8

и змейкой - 36 тактов на два байта, т.е. 18 тактов на один. Итого 576 тактов на квадратный спрайт-фон из 4-х выровненных знакомест, без подготовки.

[zx-kit]

В качестве авторитетного примера приведу вот эту поделку alone coder-а

(вертикальные столбцы это младшие 256 байт)

где видно что видео буфер лежит "вертикально" а в образовавшихся щелях понапихано еще

Получается, что буферы бывают двух типов ? Линейный по-горизонтали и вертикли как описанный у alone и линейный только по-горизонтали, когда идут подряд линии по несколько байтов. А при копировании на экран эти линии переставляются как надо. При этом по-горизонтали может быть 32 байта или меньше.

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

Или в играх бывают и другие варианты ?

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

Я когда-то тоже игру про танчики пытался написать. Можете посмотреть мои исходники: http://www.zxkot.ru/software/s01

[NEO SPECTRUMAN]

буферы бывают двух типов ?

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

[zx-kit]

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

Я хочу сделать аппаратное копирование буфера на микросхемах. Два типа копирования сделать можно. По предварительным подсчетам копирование 32-х байтов займет 16 тактов, а загрузка параметров для копирования из Z80 командами LD A, N; OUT (ADR), A 72 такта. Надо бы оптимизировать скорость загрузки адресов в буфере и на экране.

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

А какие еще вы встречали способы расположения байтов в буферах ?

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

Если применить 4 команды OUTI, то время уменьшится до 64 тактов.

[NEO SPECTRUMAN]

Я хочу сделать аппаратное копирование буфера на микросхемах. Два типа копирования сделать можно. По предварительным подсчетам копирование 32-х байтов займет 16 тактов, а загрузка параметров для копирования из Z80 командами LD A, N; OUT (ADR), A 72 такта. Надо бы оптимизировать скорость загрузки адресов в буфере и на экране.

раз ты уже пилишь свой велосипед то
как вариант
завести буфер килобайт на 8
а памяти видео карты\или прямо в памяти спека

и записывать в него

1 управляющий байт
d0 инкримент\декремент адреса источника
d1 инкримент\декремент адреса приемника
d2 инкримент\декремент старшего\младшего байта источника
d3 инкримент\декремент старшего\младшего байта приемника
d4 итд
d5
d6
d7
2 байта адрес источник
2 байта адрес приемник
1/2 байта число байт для пересылки

потом засылаешь такой список в видеокарту
или кидаешь в видео карту адрес от куда читать такую таблиц

и чтоб потом оно само автоматически по этой таблице
перекину все что нужно в нужном виде (с зеркалинием\столбиками как напишешь)

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

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

[zx-kit]

раз ты уже пилишь свой велосипед то
как вариант
завести буфер а памяти видео карты\или прямо в памяти спека

и записывать в него

1 управляющий байт
d0 инкримент\декремент адреса источника
d1 инкримент\декремент адреса приемника
d2 инкримент\декремент старшего\младшего байта источника
d3 инкримент\декремент старшего\младшего байта приемника
d4 итд
d5
d6
d7
2 байта адрес источник
2 байта адрес приемник
1/2 байта число байт для пересылки

потом засылаешь такой список в видеокарту
или кидаешь в видео карту адрес от куда читать такую таблиц

и чтоб потом оно само автоматически по этой таблице
перекину все что нужно в нужном виде (с зеркалинием\столбиками как напишешь)

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

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

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

[Lethargeek]

раз ты уже пилишь свой велосипед то
как вариант
завести буфер килобайт на 8
а памяти видео карты\или прямо в памяти спека

и записывать в него

1 управляющий байт
d0 инкримент\декремент адреса источника
d1 инкримент\декремент адреса приемника
d2 инкримент\декремент старшего\младшего байта источника
d3 инкримент\декремент старшего\младшего байта приемника
d4 итд
d5
d6
d7
2 байта адрес источник
2 байта адрес приемник
1/2 байта число байт для пересылки

потом засылаешь такой список в видеокарту
или кидаешь в видео карту адрес от куда читать такую таблиц

и чтоб потом оно само автоматически по этой таблице
перекину все что нужно в нужном виде (с зеркалинием\столбиками как напишешь)

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

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

чего только эти русские не придумают, лишь бы нормальные дороги не строить и нормальный блиттер не делать

[NEO SPECTRUMAN]

нормальный блиттер не делать

как бы у 99% платформ которые меня интересуют
никаких блитеров нету
я и не знаю какие у него должны быть возможности
только поверхностное представление


попривыкали к своим бгмерским амигам понимаешь

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

как бы у 99% платформ которые меня интересуют
никаких блитеров нету

до походу как минимум одна платформа есть (в одной из версий эту приблуду впилили)
но ее железную часть я еще не изучил

[Bedazzle]

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

К примеру, при копировании из буфера на экран может происходить масштабирование.

stretch_to_scr:
	ld   b,	#08		; pixelrows in char

draw_scanline:
	push de
	ld   	c, #20

	dup #20
		ldi
	edup

	bit  	0, b
	jr   	nz, next_scanline

	ld   	de, -32
	add  	hl, de		; draw same bytes on even line

next_scanline:
	pop  	de
	inc  	d
	djnz 	draw_scanline

	ex   	de, hl
	ld   	bc, -32*63			; #F820	= -2016
	add  	hl, bc
	ex   	de, hl
	dec  	a
	jr   	nz, stretch_to_scr

	ret