PDA

Просмотр полной версии : Спрайты



tnt23
28.03.2019, 18:29
КДПВ:

68602

(Пре-альфа арканоида растет там же, где и тетрис на гитхабе)

jerri
30.03.2019, 11:12
tnt23, а какое строение экрана у Океана?

tnt23
31.03.2019, 15:47
tnt23, а какое строение экрана у Океана?

256 строк по 512 пикселей в строке в монохромном режиме, и 256 пикселей в строке в цветном режиме. Экран начинается с адреса 4000h и растет с левого верхнего угла вниз до 40FFh, затем следующая колонка 4100h-41ffh и так далее. В монохромном режиме один бит - один пиксель.

В цветном режиме цвет каждого пикселя задается двумя битами: одним с адреса 4000h (если взять для примера верхний левый угол), а другим с адреса 4100h. Получается, что в цветном режиме есть два цветовых битплана, которые "перемешаны" друг с другом: один битплан занимает адреса 40xxh, 42xxh, 44xxh..., второй занимает адреса 41xxh, 43xxh, ... .

По поводу рисования спрайтов. Сейчас для будущего Арканоида взята без изменений процедура PaintBitmap из Тетриса, которая просто выводит на экран цветной битмап 8x8 пикселей:


; *************************************************
; PaintBitmap - нарисовать битмап 8х8
; HL - адрес битмапа
; BC - X и Y
; A - биты плоскостей
; *************************************************

В аккумуляторе передаются биты плоскостей, которые нужно нарисовать. Сам битмап кодируется просто: в памяти последовательно идут 8 байт для первого битплана, следом за ними 8 байт для второго битплана. Если установлен бит 0 в аккумуляторе, то выводятся (копируются) байты для первого битплана, для установленного бита 1 - то же для второго битплана.


; *************************************************
; PaintBitmap - нарисовать битмап 8х8
; HL - адрес битмапа
; BC - X и Y
; A - биты плоскостей
; *************************************************
PaintBitmap
di
push bc
push de

push a
; Отключаем ПЗУ для доступа к экранному ОЗУ
mvi a, ENROM
out BANKING

push hl
lxi h, SCREEN
mov d, b
mvi e, 0
dad d ; hl = SCREEN + X*256
mvi d, 0
mov e, c
dad d ; hl = hl + Y
pop de ; de = адрес битмапа

pop a ; плоскости

Plane1
rrc
jnc Plane2
call Copy8
Plane2
rrc
jnc PlaneDone

; Второй план битмапа
push h
lxi h, 8
dad d
xchg

; Перейдем ко второму плану экрана
pop h
inr h
call Copy8

PlaneDone
; Включаем ПЗУ обратно
xra a
out BANKING

pop de
pop bc
ei
ret

Copy8
push h
push d
push a
mvi c, 8
PBLoop ldax d
mov m, a
inx d
inx h
dcr c
jnz PBLoop
pop a
pop d
pop h
ret


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

ivagor
31.03.2019, 16:15
Экран начинается с адреса 4000h
С 4000h он в основном для пзушных процедур начинается, игрушкам работающим в озу имхо удобнее использовать экран с 0C000h (сам я в океанских программках только такой вариант и использовал).

tnt23
31.03.2019, 16:29
С 4000h он в основном для пзушных процедур начинается, игрушкам работающим в озу имхо удобнее использовать экран с 0C000h (сам я в океанских программках только такой вариант и использовал).

Да, это я перепутал. Экранное ОЗУ находится по адресу 0C000h, конечно.

tnt23
08.04.2019, 10:16
По мотивам обсуждения с ivagor переделал простой вывод мячика на более сложный, буферно-слоёный. Теперь мячик рисуется не прямиком на экран, а в отдельный буфер 8x16 пикселей:


сначала в буфер рисуется фон. Пока он исключительно черный, но в перспективе ничто не мешает вместо нулей подложить изображение размером с игровое поле или вообще во весь экран;
затем в буфер отрисовываются кирпичи из ближайших к мячику окрестностей;
затем в буфер отрисовываются несуществующие пока спрайты несуществующих еще врагов;
и апофеозом по OR туда лепится мячик. Я уже морально созрел добавить маску мячика (в виде множества фаз) и лепить его в буфер по AND маски и OR спрайта.


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

68712

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

ivagor
08.04.2019, 10:37
tnt23, признайся, ты специально провоцируешь мою занудную компоненту? :) Если есть различие по направлениям, то это анизотропия.

tnt23
08.04.2019, 10:40
tnt23, признайся, ты специально провоцируешь мою занудную компоненту? :) Если есть различие по направлениям, то это анизотропия.

Я не специально :) у меня помесь лени с дизлексией. Помнил про анизотропность, но ленился проверить, то ли это или нужен антоним (надеюсь, с применением слова "антоним" я не облажался)

ivagor
08.04.2019, 10:47
Откуда я помню этот ненужный термин
1. Анизотропное шоссе у Стругацких.
2. Каждый год много лет долбил про диффузное (однородное и изотропное) звуковое поле, в итоге даже сам запомнил.

tnt23
08.04.2019, 10:52
1. Анизотропное шоссе у Стругацких.

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

ivagor
10.04.2019, 06:43
В продолжение закадровой дискуссии про новую обработку приращений по X и Y. Все же вариант с "задержками" на мой взгляд менее гибкий и плавный по сравнению с фиксированной точкой. Например приращение 1.25 (5/4) в варианте с задержками будет приводить к рывкам на 5 точек с заметными паузами между ними, а при использовании фиксированной точки будут 3 приращения на 1 и одно приращение на 2, т.е. заметно плавнее.

tnt23
10.04.2019, 07:09
Мне представлялось оправданным использовать набор фиксированных углов вместо произвольных. Вырожденный вариант, понятно, только 1 к 1 (45 градусов), более играбельный - наборы 1/2, 1/3, 1/4 и 1/5. Можно подобрать максимально точно аппроксимирующие углы, кратные 15 градусам.

Вопрос плавности движения остается открытым.

ivagor
10.04.2019, 08:15
В данном случае лучше оперировать конкретными цифрами. Прикинул на матлабе.
Углы от 0 до 90 градусов с шагом 15: 0 15 30 45 60 75 90
Синусы этих углов: 0 0.2588 0.5000 0.7071 0.8660 0.9659 1.0000
Косинусы: 1.0000 0.9659 0.8660 0.7071 0.5000 0.2588 0.0000
Приблизительные аппроксимации дробями (для синусов, для косинусов, понятное дело, аналогично, но в другом порядке): [0 1/4 1/2 8/11 19/22 1 1]
Хочу обратить внимание, что 8/11 и 19/22 будут плохо (и очень плохо) обрабатываться с "задержками" и вполне приемлемо с фиксированной точкой, по крайней мере с точностью дробной части в байт. Для такой точности можно даже и получше аппроксимировать.

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

Вместо 8/11 и 19/22 можно использовать 3/4 и 4/5, но это все равно плохо.

tnt23
10.04.2019, 08:23
По-моему, это интуитивно все то же рисование по Брезенхему, иносказательно.

Почему вариант с задержками будет тормозить, не пойму.

(16-битная арифметика в 8080 так себе)

ivagor
10.04.2019, 08:33
Это скорее DDA (https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_D DA-%D0%BB%D0%B8%D0%BD%D0%B8%D0%B8)
Про тормоза я не говорил, но я писал про рывки с паузами в случае использования "задержек" для дробей вида 3/4, 4/5 и тем более 8/11 и 19/22, т.е. у которых числитель (величина "рывка") много больше единицы (знаменатель, который фактически "задержка", конечно еще больше, т.к. мы говорим о дробях <=1, а дроби >1 легко получить масштабированием).

tnt23
10.04.2019, 10:52
ivagor, спасибо за ссылку на DDA, почитаю-подумаю.

Будучи выраженным аудиовизуалом, накликал пикселей в graf (https://github.com/timtashpulatov/ok240/blob/master/graf.asm), чтобы лучше осмыслялось:

68719

Я правильно понимаю, что других способов растеризации траектории мячика, движущегося равномерно и прямолинейно, кроме приведенных на картинке исчезающе мало? И вопрос только в том, нужны ли здесь операции с фиксированной точкой (я вовсе не против их попробовать) или, поскольку результат один фиг растровый, можно сразу обойтись восьмибитными целыми.

ivagor
10.04.2019, 12:18
tnt23, я не понял, что ты нарисовал. Можно визуализировать лучи с шагом 15 градусов по вышеприведенным приращениям, только программировать не хочется.

tnt23
10.04.2019, 12:48
Я нарисовал траектории движения объекта (пикселя или спрайта) для разных соотношений dx/dy. Снизу вверх: 2/1, 3/1, 4/1 и 5/1.

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

Пришлось полезть в гугл за воспоминаниями об арктангенсе. Соответствующие вышеприведенным соотношениям углы вышли 26, 18, 14 и 11 градусов. Набор более живенький, чем просто 45 :)

svofski
10.04.2019, 13:00
Мячик отлетает как шальной, поэтому может быть есть смысл сделать какой-то разумный минимум и сфокусироваться на других аспектах игры. А детализацию углов оставить на потом, если хватит сил.

Есть важный аспект, он вроде как-то всеми подразумевается, но я не уверен, что все было проговорено вслух. Шарик имеет широкий диапазон скоростей. От вообще чуть ли не пиксель на кадр (если объесться (-S-) ) до омгвтфbbq что это было. Это усложняет использование алгоритма Брезенхема, хотя не запрещает: вместо интервала времени между шагами равного единице берем дробный интервал (насколько я понимаю, это то, что ivagor называет вариантом с задержками). Если шарик делает больше пикселя за кадр, что по-моему очень часто случается, понадобится по нескольку итераций на кадр.

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

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

Псевдокод, совсем не похожий на Си. Входные данные: x_direction, y_direction ∈ [-1,1], dda_table_x[], dda_table_y[] - коэффициенты приращений такие, что [0,1) -> [0,255). angle_index - индекс угла в табличке коэффициентов. Подразумевается, что строго горизонтальные и строго вертикальные полеты мяча невозможны. ball_x, ball_y - координаты мяча.


for (int i = 0; i < speed; ++i) {
x_accu += dda_table_x[angle_index];
if (x_accu & 0x100) { /* carry */
ball_x += x_direction;
x_accu &= 0xff; /* clear carry */
}

y_accu += dda_table_y[angle_index];
if (y_accu & 0x100) { /* carry */
ball_y += y_direction;
y_accu &= 0xff; /* clear carry */
}
}

Я практически уверен, что вместо dda_table_x[] и dda_table_y[] и одного индекса угла, можно сделать dda_table[] и два индекса угла. Но это будет оптимизация шкуры неубитого медведя, поэтому пока в сторону.

ivagor
10.04.2019, 13:07
Озвучу, то что я предлагал tnt23 - использовать арифметику с фиксированной точкой в варианте байт целый и байт дробный, т.е. фактически дробные числа для перевода в этот формат нужно умножить на 256. Например .75*256=192, 12.345=примерно 3160 и т.д. Для позиционирования при отрисовке используем только целую часть, т.е. старший байт. Единственная 16-битная операция, которая требуется - сложение. И так удачно получилось, что у 8080 есть команда dad. Надо ли писать пример?

svofski
10.04.2019, 13:31
ivagor, а как учитывается скорость мячика?

ivagor
10.04.2019, 13:57
Вот эти 0.75 или 12.345 - это и есть скорость шарика по одной из координат.

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

Подумал, что возможно ты разделяешь угол и скорость и про скорость спросил в этом смысле. Фактически я про это уже написал раньше, когда перечислял косинусы и синусы, которые <=1, а разные скорости можно получить масштабируя (делением или умножением или даже по таблице) эти коэффициенты.

svofski
10.04.2019, 14:20
То есть масштабируя, внося таким образом скорость в коэффициенты.

У моего третьего варианта с псевдокодом по-моему есть пара важных преимуществ по сравнению с более "прямолинейными" подходами: все предварительные расчеты делаются на этапе компиляции, все сложения 8-битные + перенос. Очевидный недостаток - итеративность. Может быть например получится слишком много итераций в среднем, тогда 16-битный FP и сложные предварительные расчеты окажутся более практичными.

ivagor
10.04.2019, 14:45
svofski, у тебя фактически тоже арифметика с фиксированной точкой, но частный случай, когда коэффициенты <1. И масштабирование ты делаешь сложением вместо умножения или набора таблиц (я бы сам скорее всего сделал набором таблиц, по крайней мере в ротозумере именно так делал). В сухом остатке одно значимое отличие - 8-битное сложение вместо 16-битного. На мой взгляд оно того не стоит - некоторое усложнение и замедление (когда скорость>1) программы в обмен на 8-битные таблицы, но это только мое мнение.

svofski
10.04.2019, 14:55
ivagor, да, все верно. 8 бит только дробная часть, а целая часть оседает в координате через флаг переноса. В общем это просто немного другое представление 16-битной координаты и если мы твой и мой способы запишем строго формально, то получим эквивалентные выражения.

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

ivagor
10.04.2019, 15:08
В твой вариант я бы все же одну хаку добавил. Когда 255 - сразу прибавляем единицу к x_accu (или y_accu). Или так - перед тем, как использовать dda_table_x (или y) для сложения прибавляем туда единицу, в этом случае в dda_table надо хранить коэффициенты уменьшенными на единицу.

tnt23
10.04.2019, 20:23
Для позиционирования при отрисовке используем только целую часть, т.е. старший байт. Единственная 16-битная операция, которая требуется - сложение. И так удачно получилось, что у 8080 есть команда dad. Надо ли писать пример?

Я б взглянул.

ivagor
10.04.2019, 21:27
Программка заставляет нижний левый угол экрана испускать лучи добра. Процедуру Round закомментил, т.к. ее влияние практически не заметно, но можно раскомментить при желании.
Небольшой оффтоп. Периодически возникает срач на тему мнемоник 8080 и z80, какие лучше. Так вот 8080 имеет инструкцию ana l, а у z80 такой инструкции нет.

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

Забыл режим при выходе восстановить. Можно использовать Esc60

Denn
11.04.2019, 11:33
Периодически возникает срач на тему мнемоник 8080 и z80, какие лучше. Так вот 8080 имеет инструкцию ana l, а у z80 такой инструкции нет.

https://pp.userapi.com/c631322/v631322907/b2a0/SU_A6sKx11c.jpg

tnt23
11.04.2019, 12:45
Denn, в качестве платы за оффтопик сконверти это изображение в битмап 256x256 с цветовой палитрой RGB для "Океана".

Denn
11.04.2019, 13:32
tnt23, на Океане всё равно не откроется страница форума, увы.. :-р

tnt23
13.04.2019, 11:07
Пока обдумывается вопрос с приращениями, сделал болванку для работы со списком выбиваемых бонусов.

http://sensi.org/~tnt23/ok240/bonus.png

Список бонусов - фиксированной длины, каждый элемент списка состоит из типа бонуса (0 - пустой слот), скорости падения, и координат X и Y. При выбивании очередного кирпича в списке ищется пустой слот, в который заносится (в будущем рандомный) тип бонуса, координаты его месторождения, и скорость падения (пока одинаковая для всех, но для живости будет разная).

Выглядит уже довольно потешно: https://www.youtube.com/watch?v=nFD_k2lfcFM&feature=youtu.be

ivagor
13.04.2019, 11:23
tnt23, бонусы - это хорошо, но вот мигания шарика меня смущают. Понимаю, что это эмулятор и в нем к развертке не привязаться, но все же мигание на мой взгляд слишком сильное.

tnt23
13.04.2019, 11:51
ivagor, меня тоже моргание огорчает, а еще медленность перерисовки всей движухи. Хотя я там и делал привязку к лучу, но на эмуляторе не работает.

svofski
13.04.2019, 12:30
То, что я вижу, соответствует большой скорости мячика. В принципе, на таких скоростях уже все равно работает спинной мозг без особого участия сложных органов чувств.

А в реале привязка к лучу есть?

tnt23
13.04.2019, 12:58
То, что я вижу, соответствует большой скорости мячика. В принципе, на таких скоростях уже все равно работает спинной мозг без особого участия сложных органов чувств.
Скорость вообще никак сейчас не ограничена, чтобы познать границы возможного.

А в реале привязка к лучу есть?
В реале-то есть, но на реале еще не смотрел.

ivagor
13.04.2019, 14:26
Решил сам попробовать, будет мигать или нет. Это просто тест, все сделано максимально тупо и очень медленно, но не мигает.

ivagor
13.04.2019, 17:04
Но чудес нет и на скролле без привязки к развертке не все гладко. Надеюсь или b2m добавит в emu бит ГК (или КГ? забыл) или Pyk добавить эмуляцию океана в Emu80.

tnt23
13.04.2019, 17:45
Чуть изменил проверку луча (JZ вместо JNZ в простом коде ожидания бита в порту 41h), на реале мячик сечется в верхних ~20 растровых строках, на остальном экране не мерцает.

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

ivagor
13.04.2019, 17:55
Железобетонный вариант (для реала) - использовать 2 экранные страницы и переключать по биту ГК. Но программу придется сильно переделывать.

tnt23
13.04.2019, 18:12
Железобетонный вариант можно будет попробовать для демки, если когда-нибудь дойдут руки.

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

tnt23
14.04.2019, 11:01
1) Видел у svofski в Рива Рейде отладочные полоски на бордюре, сделал себе такие же, чтобы хоть примерно представлять, сколько отъедает процессинг разных частей.

http://sensi.org/~tnt23/ok240/palettedebug.png
78773

Белая полоса - мячик, красная - ракетка, зеленая - бонусы, черная - idle.

2) Спрямил циклы в выводе битмапа, стало 799 тактов вместо 1073.

svofski
14.04.2019, 13:04
Самый зыкий способ отлаживать такты. Но не пойму - ¿куда смотреть? – тут всех полосок по много раз. Или ты возвращаешься к вопросу по нескольку раз за кадр? Получается, что мяч отъедает процентов 60 всего времени?

tnt23
14.04.2019, 14:27
На картинке с эмулятора смотреть сложно, там нет битика ГК и поэтому попытки синхронизироваться по лучу мгновенно получаются всегда. Попробую снять картинку с тринитрона.

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

svofski
14.04.2019, 14:55
А какая разница сколько кирпичей? Что ты с ними делаешь?

Я представлял себе так: при выводе мячика, для каждого его байтика при выводе проверяем, случилось ли наложение. Если да, то уже ответвляемся и начинаем разбираться, об Гоголя, или об Пушкина. Это может показаться накладно, зато монотонно, что для расчета времени исполнения на кадр важнее. Немного толку от быстроты процедуры, которая обычно супер быстрая, но иногда вдруг становится медленной и срывает собой всю оркестровку.

Или я вообще не о том?

tnt23
14.04.2019, 16:37
Примерно так же (дьявол в мелочах) делаю и я. После приращения координат мячика смотрим, не приехал ли он в клетку, где уже есть кирпич. Если да, приходится ответвляться, используя терминологию Фангорна, и разбираться.

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

Просто у меня еще не все заоптимизировано. Например, стирание мячика и рисование его в новом месте происходит всегда, независимо от того, перебрался он в новый узел кирпичной сетки (8х16) или нет. Далее, все отрисовки (стирание выбитого кирпича, стирание-рисование мячика) производятся прямо где нужда застигла. Хотя правильнее было бы ставить отрисовки в очередь и обрабатывать ее первым делом после синхронизации по лучу.

NEO SPECTRUMAN
14.04.2019, 17:56
почитал тему и...:v2_dizzy_facepalm:


Что было хорошо для Тетриса, уже мало подходит для Арканоида с необходимостью ловли коллизий нескольких спрайтов, причем по возможности на пиксельном уровне.
что вы хотите сталкивать на пиксельном уровне
и главное зачем?.:v2_dizzy_facepalm:

не сдержался
сильно все на никаком уровне...

svofski
14.04.2019, 18:18
Разница в том, что кирпичи не встречаются в нижней половине экрана, и мячик не тратит время на ощупывание воздуха вокруг.

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

Кроме того:
* мячика может быть три
* есть уровни, где кирпичи заходят ужасающе далеко вниз, например третий
* летающие шапки залетают даже под ракетку, а с ними коллизии тоже нужны

tnt23
14.04.2019, 18:32
svofski, я примерно это тоже понимаю про ненужную оптимизацию. Уберу со временем.

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

NEO SPECTRUMAN
14.04.2019, 18:50
а как щас происходит детекция касания мячиком чего либо?

tnt23
14.04.2019, 18:53
а как щас происходит детекция касания мячиком чего либо?

В коде же все написано :) пока только столкновения с кирпичами.

NEO SPECTRUMAN
14.04.2019, 19:01
В коде же все написано
не знаю де код
там отсылка к тетрису

да и 8080 мнемоники не читаемые
изза чего по моему все так плохо и получается

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


Отключаем ПЗУ для доступа к экранному ОЗУ
Включаем ПЗУ обратно

из этого вопрос по океану
что происходит при подключении экранного озу
что нужно выключать его потом обратно
(во львове, например, это обусловлено отпаданием 16К памяти)

tnt23
14.04.2019, 19:15
что вы хотите сталкивать на пиксельном уровне
и главное зачем?.:v2_dizzy_facepalm:


Например: мячик круглый, кирпичи угловатые. Есть траектории, в которых мячик проходит опасно близко к острому кирпичному углу, но это не коллизия.

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



из этого вопрос по океану
что происходит при подключении экранного озу
что нужно выключать его потом обратно
(во львове, например, это обусловлено отпаданием 16К памяти)

Сорцы тут - https://github.com/timtashpulatov/ok240/blob/master/ark.asm

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

NEO SPECTRUMAN
14.04.2019, 19:22
Например: мячик круглый, кирпичи угловатые. Есть траектории, в которых мячик проходит опасно близко к острому кирпичному углу, но это не коллизия.
и этим вы неимоверно усложняете движок и замедляете его
мячик можно описать 4-мя 6-ю точками
проще сделать кирпич строго прямоугольным
закруглением в один пиксель принебречь

кирпичи не распологаются попиксельно
а обычно по сетки 8х8
из чего можно неимоверно все упростить и оптимизировать
и проверять столкновение с кирпичами простым
cp (hl)
jp nz,collision
на каждый шаг шарика

и сразу при этом читать номер кирпича
(250 кирпичей(больше низя) на экране с головой хватит)

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


ПЗУ обратно включается, чтобы пользоваться штатной процедурой опроса клавиатуры.
забудтье про ПЗУ навсегда
пишите свою процедуру опроса

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


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

svofski
14.04.2019, 19:24
Есть траектории, в которых мячик проходит опасно близко к острому кирпичному углу, но это не коллизия.
Можно держать вспомогательный битмап небитых кирпичей (по биту или два на кирпич) и битмап мячика, по биту на мячик. Первичный тест будет очень быстрый.

NEO SPECTRUMAN
14.04.2019, 21:33
Можно держать вспомогательный битмап небитых кирпичей
какой нафик битмап
нужно 32х32 байта памяти
и подсказка
нормальные люди для большей скорости разместят их так
(адреса условно с А000 чисто для прммера)

A000 A001 A002... ...A01Е A01F
A100 A101 A102... ...A11Е A11F
................................................
BE00 BE01 BE02... ...BE1Е BE1F
BF00 BF01 BF02... ...BF1Е BF1F

и все будет летать

можно конечно с экономить памяти
и разместить все линейно
но потерять в скорости...

можно ложить рядом с этим буфером (A020...A0FF A120...A1FF итд)
другие данные
например графику
или карты уровней


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


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

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

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

условный пример содержания буфера



11111111111111111111111111111
20000000000000000000000000003
20000000000000000000000000003
20044556677889900000000000003
2000AABBCCDDEEFF0000000000003
20000000000000000000000000003
20000000000000000000000000003
20000000000000000000000000003
(так же можно упростить детекцию потери шарика
нарисовав в буфере дно как стену со своим номером
(в качестве бонуса
ставящего отбивалку можно быстро пририсовать вместо дна вызывающего проигрыш
дно вызывающее отбивание))

далее нам нужна
проверка по табличке
с чем же мы столкнулись
(табличка генерируется в начале уровня
(то есть каждому блоку присваивается его тип))

напомню что 250 блоков это
16х15 широких кирпичей
256х120 пикселей сплошных рядов кирпичей

в принципе не сложно расширить набор почти до 64К
но зачем?

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

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

на всякий случай напомню что деление на 8 делается 3-мя rra
а то мало чего еще нагородят...

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

В принципе не обязательно присваивать каждому блоку свой номер
это не сильно рационально
нужно только отделить соседние друг от друга

11111111111111111111111111111
20000000000000000000000000003
20000000000000000000000000003
20044554455445544554455440003
20006677667766776677667700003
20088998899889988998899880003
2000AABBAABBAABBAABBAABB00003
200CCDDCCDDCCDDCCDDCCDDCC0003
20000000000000000000000000003
20000000000000000000000000003
20000000000000000000000000003
2FFFFFFFFFFFFFFFFFFFFFFFFFFF3

а определять что стирать в видео памяти
на основе адреса в буфере

tnt23
15.04.2019, 00:16
NEO SPECTRUMAN, ну вы сорцы-то гляньте, вдруг там кое-какие жемчужины кодинга уже реализованы.

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


Получается, что мяч отъедает процентов 60 всего времени?

http://sensi.org/~tnt23/ok240/ticks.png
78774

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

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

Тощая зеленая прокладка - отрисовка двух бонусов.

main_loop() выглядит примерно так:


call SyncToRetrace
call ProcessBall ; белая полоса
call ProcessBatty ; красная полоса
call ProcessBonusList ; зеленая полоса
jmp Begin

svofski
15.04.2019, 01:55
Ниже идет слой красных кирпичей, это перерисовка ракетки. Фиг знает, почему так жруче, там вообще никаких тяжелых проверок и рендера нет.
Особо не вчитывался, но выглядит так, как будто PaintHorizontalBitmap и PaintBitmap слишком универсальные и могут быть специализированы для рисования ракетки побыстрее. Очень много push, pop, call, все это красиво и высокоуровнево, но отъедает много времени.

NEO SPECTRUMAN
15.04.2019, 08:17
ну вы сорцы-то гляньте, вдруг там кое-какие жемчужины кодинга уже реализованы.
потом как нить набросаю арканоид для львова
более слабой машины
но с таким же тяжеловесным экраном 256х256 4 цвета
с более неудобной адресацией
+нет прерываний

для сравнения

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

так понимаю на океане
пиксели тоже прямоугольные?
с каким примерно соотношением сторон?

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

В океане всего 8 палитр?

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


ну вы сорцы-то гляньте, вдруг там кое-какие жемчужины кодинга уже реализованы.
жумчужина...
mvi a, 0






SyncToRetrace
; подождем наступления ретрейса
in 41h
ani 2
jz SyncToRetrace
ret

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

ГС ГК - это гашение кадровое гашение строчное?
по ходу у вашего океана неимоверные нериализованные возможности...
то есть среди советских компов на 8080
девайс можно было бы поставить за вектором
при правильном подходе...
и экран у вас рационально организованный
(лишь слегка хуже чем на векторе, орионе, специалисте)

тоесть синхронизируемcя с ГК
потом с ГС
запускаем таймер на нужной частоте
и все
по rst4 можем рисовать палитровые мультиколоры из коробки
(тоесть больше чем 4 цвета на экране)
без особых усилий...

можно одновременно даже играть музыку звуки
выполняя при этом код
повесив пищалку на прерывания порядка 10Кц
на узкоимпульсном биперном движке можно даже 5Кц
чтоб меньше сьедать процесорного времени

вангую что этот океан эмулируется на уровне "ниже плинтуса"

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

Шото мне аж самому запонравился ваш компутер
Но я не потяну ищо одно "тянение за уши" еще одной платформы...
я не справляюсь со своими...
...опять же которая еще и не эмулируется...

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


Например: мячик круглый, кирпичи угловатые. Есть траектории, в которых мячик проходит опасно близко к острому кирпичному углу, но это не коллизия.
к примеру
всякие collision model-и из GTA
сферы скорей всего просто описаются кодом а не полигонами
и скорей всего служат до уточнения куда именно пришлось(фары двери капоты) столкновения с простой квадратной моделью
которые под ними
https://cs1.gtaall.net/screenshots/d9802/2013-09/original/ac36e5dac3f538c1e0fbd4e1481311236a8c5920/124697-CollEditor1.1beta-1.jpg
http://real.gta-bg.com/info/tutorials/colls/pics/3.gif

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

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


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

ivagor
15.04.2019, 10:59
tnt23, ты был прав, надо было сразу на форуме обсуждать, чтобы несколько раз об одном и том же не говорить.

tnt23
15.04.2019, 11:31
tnt23, ты был прав, надо было сразу на форуме обсуждать, чтобы несколько раз об одном и том же не говорить.

Необратима только смерть, из всего остального можно даже извлечь пользу :)

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


Особо не вчитывался, но выглядит так, как будто PaintHorizontalBitmap и PaintBitmap слишком универсальные и могут быть специализированы для рисования ракетки побыстрее. Очень много push, pop, call, все это красиво и высокоуровнево, но отъедает много времени.

Это задел на будущее, когда наступит тактовое голодание и можно будет с наслаждением отгрызать корочки.

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


жумчужина...
mvi a, 0

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

Denn
15.04.2019, 11:55
Подскажите другой способ поместить в аккумулятор ноль, не трогая флаги.

MOV A,x

Как правило, в каком-нибудь регистре всегда ноль болтается, всякие счётчики циклов в финале обнуляются... достаточно чутка отмотать назад и посмотреть ;)

tnt23
15.04.2019, 11:57
MOV A,x
Как правило, в каком-нибудь регистре всегда ноль болтается, всякие счётчики циклов в финале обнуляются... достаточно чутка отмотать назад и посмотреть ;)

Очень, очень удобно!

Denn
15.04.2019, 11:59
Очень, очень удобно!

Бонусом получаем доп. расход нервных клеток у дизассемблирующих :)

ivagor
15.04.2019, 12:25
другой способ поместить в аккумулятор ноль, не трогая флаги.
Например

push psw
xthl
mvi h,0
xthl
pop psw
Понимаю, что простовато, но можно постараться и развить эту идею (добавить xchg и т.п.).

tnt23
15.04.2019, 12:27
Например

push psw
xthl
mvi h,0
xthl
pop psw
Понимаю, что простовато, но можно постараться и развить эту идею (добавить xchg и т.п.).

На mvi h,0 можно сэкономить, если ноль уже есть в каком-нибудь другом регистре.

svofski
15.04.2019, 12:28
ivagor, главное, что в отличие от mvi a,0 глаз не режет. +10 очков за применение ftagn\\\\\xthl.

ivagor
15.04.2019, 12:51
если ноль уже есть в каком-нибудь другом регистре
Мы не будем ждать ноля у программиста, создать его - наша задача.

push psw
ora a
sbb a
xthl
xchg
mov d,a
xchg
xthl
pop psw
Все еще слишком прозрачно для понимания, надо самомодифицирующегося кода добавить. Ладно, извините, больше не буду оффтопить :)

tnt23
15.04.2019, 12:59
Ниже идет слой красных кирпичей, это перерисовка ракетки. Фиг знает, почему так жруче, там вообще никаких тяжелых проверок и рендера нет.

Зато есть сперва тупое стирание ракетки без анализа необходимости (ок, для монотонности пусть будет) - 3392 такта, а потом тупое рисование ее же за те же 3392 такта. Есть простор для оптимизаций (потом, после мячечных и кирпичечных оптимизаций)

NEO SPECTRUMAN
15.04.2019, 13:27
посмотрел сорец на свежую голову
...и смотрю что какой то херни я наплел...
...

вот те мой вариант этой чистилки буфера

RenderBackground
lxi hl, NOBATTY+1
lxi de, BALLBUF
mvi b, 32
call Copy_B_Bytes_From_HL_To_DE
ret



например



RenderBackground
lxi hl, NOBATTY+1
lxi de, BALLBUF
mvi b, 32

RenderBackground_1
mov a, m
stax de
inc l
inc e
dcr b
jnz RenderBackground_1

ret
только нужно позабодтится чтобы буфера не пересекали границу 256 байт


я бы написал вообще так
только не говорите что вам жалко 128 байт для этого


RenderBackground
lxi hl, NOBATTY+1
lxi de, BALLBUF


dup 31 ;повторить 4 строки ниже 31 раз
mov a, m
stax de
inc l
inc e
edup
mov a, m
stax de

ret

посчитайте по тактам разницу

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

Помоему у вас сильно много оптимизации по памяти
каждый пол пчиха
у вас call туда call сюда
а там по 2 команді и jp еще куда то...

в итоге вместо полезного кода
выполняются одни call-ы и jp-ы...

ivagor
15.04.2019, 13:29
Вот опять мы с tnt23 разворачивание циклов и использование стека (с которым будет быстрее и короче) обсуждали за кадром. Оптимизация отдельных критичных фрагментов - это хорошо, но сначала в целом бы получить хороший рабочий вариант.

NEO SPECTRUMAN
15.04.2019, 13:33
Оптимизация отдельных критичных фрагментов - это хорошо, но сначала в целом бы получить хороший рабочий вариант.
лучше сразу пытаться писать с оптимизацией
потом этот рабочий вариант на всегда и остаенется...

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

svofski
15.04.2019, 14:32
В конкретном случае ракетки, может быть просто сделать ее пошире с черными полями так, чтобы он сама свои края при перемещении затирала? А то как-то много чести целиком экран под ней стирать каждый кадр. Надо только учесть, насколько широкие должны быть поля с учетом максимальной скорости. Или ты уже это пробовал, но получается, что быстрее стереть целиком?

Кстати о разворачивании, прекрасм поддерживает синтаксис в стиле:


ldax d \ mov m, a \ inx d \ inx h ; ftagn!

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

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

btw, строго говоря, "push hl", "dad bc" -- это чуток девиантно для 8080, надо "push h", "dad d", etc. Прекрасм это терпит, но лучше писать правильно.

tnt23
15.04.2019, 14:35
В конкретном случае ракетки, может быть просто сделать ее пошире с черными полями так, чтобы он сама свои края при перемещении затирала? А то как-то много чести целиком экран под ней стирать каждый кадр. Надо только учесть, насколько широкие должны быть поля с учетом максимальной скорости. Или ты уже это пробовал, но получается, что быстрее стереть целиком?

Нет, такое мне в голову не приходило. Загрузился и думаю.

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


btw, строго говоря, "push hl", "dad bc" -- это чуток девиантно для 8080, надо "push h", "dad d", etc. Прекрасм это терпит, но лучше писать правильно.

Пишу так скорее для себя, чтобы глазом видеть, где работа с регистровой парой идет. Буду исправляться.

Denn
15.04.2019, 14:39
Все еще слишком прозрачно для понимания, надо самомодифицирующегося кода добавить.



SHLD $+12
PUSH PSW
LXI H,0
DAD SP
MVI M,0
POP PSW
LXI H,0

ivagor
15.04.2019, 14:48
Denn, хороший вариант, но насколько помню, флаги - младший байт psw, A - старший. Если я не ошибся, то после push psw нужно lxi h,1

tnt23
15.04.2019, 15:11
только нужно позабодтится чтобы буфера не пересекали границу 256 байт

Мысль проредить буферы хорошая, можно будет ее потом обдумать, когда/если действительно не будет хватать тактов, с одной стороны, и будет избыток памяти с другой.

NEO SPECTRUMAN
15.04.2019, 15:21
btw, строго говоря, "push hl", "dad bc" -- это чуток девиантно для 8080, надо "push h", "dad d", etc. Прекрасм это терпит, но лучше писать правильно.
абсолюютно правильный подход
push h это скорей всего дебилизм разработчиков мнемоник 8080
аf вообще обозвали psw...
потом они исправились...

что примечательно в ARM-е вообще не заморачивались
и SP и PC лежат среди обычных регистров под именами r13, r15

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


Мысль проредить буферы хорошая, можно будет ее потом обдумать, когда/если действительно не будет хватать тактов, с одной стороны, и будет избыток памяти с другой.
просто положи org-ом оно в конец памяти и все
да и можно ложить несколько маленьких таблиц\буферов друг за другом
имея один общих старший адрес если мало памяти

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

svofski
15.04.2019, 15:43
push h это скорей всего дебилизм разработчиков мнемоник 8080
С этим даже я, фанат 8080 и хулитель Z80, соглашусь. Но это вопрос совместимости. Не любой ассемблер поймет такие мнемоники.

NEO SPECTRUMAN
15.04.2019, 15:48
Не любой ассемблер поймет такие мнемоники.
А так часто одни ассемблері понимают сорці других ассемблеров?
(выделываются даже разные версии...)

при необходимости все можно будет подправить автозаменой...


просто в сорце нужно указовать чем компилить
...
я вообще ложу компилятор вместе с сорцами
чтоб компилилось из коробки и без плясок с бубном

ivagor
15.04.2019, 15:55
Оффтоп про мнемоники.
Пусть меня поправят, но что касается выделения отдельных мнемоник для stax, sta и т.п. вместо mov, то это скорее всего немного упрощает транслятор ассемблера. Сейчас про это смешно говорить, но тогда (в 70-х) это могло иметь значение.
А насчет всяких забавных ana l, ora l, хитрого xthl думаю что автор(ы) мнемоник просто прикалывался.

NEO SPECTRUMAN
15.04.2019, 15:56
tnt23, а как ты собираешь исполняемый файл?

tnt23
15.04.2019, 16:02
tnt23, а как ты собираешь исполняемый файл?

https://svofski.github.io/pretty-8080-assembler/?https://raw.githubusercontent.com/timtashpulatov/ok240/master/ark.asm

Denn
15.04.2019, 16:03
Denn, хороший вариант, но насколько помню, флаги - младший байт psw, A - старший. Если я не ошибся, то после push psw нужно lxi h,1

Я вот почему-то тоже думал, что нужно инкрементировать SP, но не поленился заглянуть в доку, а там:

F5 PUSH PSW [[SP]-1]←[A], [[SP]-2]←[F], [SP]←[SP]-2

В итоге с великим сожалением пришлось убирать INX SP...

П.С. стэк растёт в обратную сторону, и там всё задом-наперёд..

NEO SPECTRUMAN
15.04.2019, 16:08
что касается выделения отдельных мнемоник для stax, sta и т.п. вместо mov, то это скорее всего немного упрощает транслятор ассемблера.
мне кажется они вообще расчитывали на компиляцию при помощи ручек...
а там бы лучше прокатил z80 подход
для него таблица соответствий мнемоник и опкодов будет удобней

хотя до если читать сорец с перфоленты
я соглашусь что 8080 мнемоники более оптимальные
но щас они морально устаревшие
и есть мнемоники Z80


в IDA для z80 есть набор нечитаемых мнемоник в стиле 8080....
...
кстате для x86 тоже есть разные варианты написания

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


https://svofski.github.io/pretty-808...master/ark.asm
умя эта тулза не отзывается

имею ввиду некий файл с заголовком, начальным адресом, числом байтов контрольной суммой
который можно загрузить на реальном железе
на океане вообще там какието cp/m-ы
(подробностей не знаю)

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

tnt23
15.04.2019, 16:12
умя эта тулза не отзывается

имею ввиду файл с начальным адресом числом байтов коннтрольной суммой
который можно загрузить на реальном железе
на океане вообще там какието cp/m-ы
(подробностей не знаю)

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

По ссылке живет Прекрасный Ассемблер имени svofski, которым (ассемблером) я в браузере прямо и пользуюсь. В нем же компилирую, там есть несколько вариантов выгрузки: в бинарный файл, в HEX-файл (пригодный для загрузки в "Океан" по команде L через RS-232), и WAV.

ivagor
15.04.2019, 16:14
F5 PUSH PSW [[SP]-1]←[A], [[SP]-2]←[F], [SP]←[SP]-2
Значит точно нужно lxi h,1 после push psw

tnt23
15.04.2019, 16:18
В конкретном случае ракетки, может быть просто сделать ее пошире с черными полями так, чтобы он сама свои края при перемещении затирала? А то как-то много чести целиком экран под ней стирать каждый кадр.

Спасибо за инсайт. Ракетка сейчас перемещается попиксельно; даже если когда-нибудь мы доживем до перемещения ее скачками по два и более пикселей зараз - да хоть до восьми пикселей, для быстрых разумом Невтонов, - действительно нет смысла стирать ее всю, достаточно только подтереть хвост шириной в 8 пикселей.

NEO SPECTRUMAN
15.04.2019, 16:20
ладно
а как загружаешь в емулятор?
в каком формате хранят океановскую софтварь?

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


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

Denn
15.04.2019, 16:20
Значит точно нужно lxi h,1 после push psw

Чёрт, точно! Я думал про регистр флагов, и уже смотрел на него, а не на причинный :)

tnt23
15.04.2019, 16:24
ладно
а как загружаешь в емулятор?
в каком формате хранят океановскую софтварь?


В эмулятор (emu) гружу через евонный отладчик, там есть возможность вдуть бинарь по произвольному адресу.
У "Океана" нет какого-то особенного формата, исполняемые CP/M файлы с 100h, как обычно.

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



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

NEO SPECTRUMAN
15.04.2019, 16:30
(легкомысленно) ну вот потом и подумаю
в принципе там или буфер для ракетки

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

tnt23
16.04.2019, 14:22
Не удержусь и (снова) процитирую Дениса Грачева про "лдпуш" из замечательной статьи "Мультиколор будет побежден" (http://hype.retroscene.org/blog/dev/768.html):


А дальше нужно было ускорить вывод пикселей с сохранением возможностью их лёгкого скролинга. После всех экспериментов я остановился на оптимальном размере игровой область в 24*16 знакомест. Отрисовка пикселей это достаточно затратно, поэтому я решил взять самый быстрый метод вывода изображения из буфера в простонародье известный как «лдпуш» он основан на постоянном повторении комбинации команд ld и push. Мы отводим огромный кусок памяти в который генерируем такой код

;у нас будет 320 линий
dup 320
;код для вывода одной линии
ld sp,адрес конца линии экрана
dup 12: ld de,2 байта данных: push de : edup
edup
Это и будет наш пиксельный экран, он статичен. Он просто выводит данные на экран которые в нём же и хранятся. Причем выводит он их задом наперёд, т.к. команда push уменьшает указатель стека, который в нашем случае является адресом куда мы кидаем данные. Таким образом, вместо того чтобы рисовать напрямую в экран мы, будем рисовать прямо в код! Т.е. нам нужно будет каким то образом преобразовывать реальные игровые координаты в адрес нужного нам байта в этом куске кода. К тому же нужно учитывать, что всё будет зеркально, т.к. рисуется задом наперёд и вдобавок ко всему, чтобы двигать горизонтально плавно спрайты шириной 16 пикселей по экрану нам необходимо перерисовывать 3знакоместа в ширину, а значит вычисление соседнего знакоместе будет совсем не тривиальным. Не стоит забывать, что под спрайтами ещё нужно сохранять и восстанавливать фон. К тому же нужно как-то скролить это всё прыгая на нужную строчку кода и выпрыгивать с неё и ещё обновлять адреса линий куда всё будет выводится.


Ну и так далее. Сделаю буфер, куда рендерится мячик/ракетка/бонусы, по такому же принципу кода вперемешку с данными и посмотрим, кто кого.

svofski
16.04.2019, 16:07
В Рива Рейде у меня все спрайты так выводятся, они все суть код. Сам код сгенерен заранее (https://github.com/svofski/incursiondelrio/blob/master/makesprites.py). Не обязательно замыкаться на push, иногда быстрей mov m, r. А что именно ты собрался делать у себя таким образом? Спрайты, или тут куда-то еще глубже дело пошло? Процитированный текст слишком поэтичен.

tnt23
16.04.2019, 16:22
В Рива Рейде у меня все спрайты так выводятся, они все суть код. Сам код сгенерен заранее.

Подозревал я что-то такое, но стеснялся спросить/посмотреть.


Не обязательно замыкаться на push, иногда быстрей mov m, r.

Разве что в параллельных вселенных, где стек живет в отдельной медленной памяти. Так-то два mov m, r = 14 тактов, а один push = 11. Крохоборствовать так уж крохоборствовать.

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

ivagor
16.04.2019, 16:35
1. pop + mov + inr + mov + inr - 34 такта на пересылку двух байт. Плюсы: 1) пересылаемые данные идут подряд, 2) не обязательно разворачивать до упора, т.е. размер процедур пересылки может быть умеренным.
2. pop + shld - 26 тактов на пересылку двух байт. Плюс: пересылаемые данные идут подряд, 2) быстрее п.1. Минусы - 1) обязательно разворачивать до упора, 2) фиксированное место назвначения.
3. lxi + push - 21 такт на пересылку двух байт. Плюс: быстрее п.1 и 2. Минусы - 1) обязательно разворачивать до упора, 2) пересылаемые данные идут не подряд.
Третий вариант может быть еще быстрее. Если выводим фиксированные (не меняющиеся) тайлы с регулярным узором, то там есть много повторов и не обязательно каждому push должен предшествовать lxi, т.е. получается еще быстрее.
В зависимости от потребностей использовал все три варианта.
Если не изменяет память, то в спековском арканоиде 2 фон (вроде фон) выводится ld rp,(память) + push + push + ...

svofski
16.04.2019, 17:00
mov m,r не всегда нужны парами а у пуша есть оверхед с сохранением sp итд. На этом можно выгадать в мелочах. Как раз тут крохоборство настоящее :)

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

(Не упущу случая поворчать о том, что самолюбие не обязано страдать от того, что спрайты не вычисляются в рантайме эпическим кодом, а подготавливаются заранее внешней колченогой тулзой, которую проще подгонять и оптимизировать. Баланс езды и шашечек, getting shit done, etc..)

tnt23
16.04.2019, 17:12
(Не упущу случая поворчать о том, что самолюбие не обязано страдать от того, что спрайты не вычисляются в рантайме эпическим кодом, а подготавливаются заранее внешней колченогой тулзой, которую проще подгонять и оптимизировать. Баланс езды и шашечек, getting shit done, etc..)

Ты прав, но питон... (деликатно сморкается в занавеску)

svofski
16.04.2019, 17:30
tnt23, выбор языков не ограничен ассемблером для 8080 и питоном.

tnt23
16.04.2019, 17:53
ivagor, я пока сделаю самый простой вариант варианта 3. Все рисуемые объекты так или иначе кратны цветному квадратику 8х8 пикселей (см. PaintBitmap). То есть выводить нужно либо два столбика по 8 байт (бонус), либо четыре столбика (мячик и кирпичи), либо восемь столбиков (ракетка).

ivagor
16.04.2019, 18:08
либо два столбика по 8 байт (бонус), либо четыре столбика (мячик и кирпичи)
Тут нет ошибки/опечатки? Не широковат ли мячик и в арканоидах, которые я видел, бонус обычно равнялся по ширине кирпичу.

svofski
16.04.2019, 18:24
Понимаю, что затыкаю преждевременно спровоцированный допаминовый фонтан, но есть один неприятный момент. Мячик часто пролетает в опасной близости от стен, кирпичей, бонусов, шапок итд, их не задевая. Поэтому его придется отрисовывать честно с маской и наложением, иначе он будет затирать собой соседние кирпичи, стены, бонусы и шапки. Удачно, что мячик такой маленький, да и все равно надо определять коллизии (хотя с этим еще вроде нет однозначности), так что это будет не слишком сильным ударом по общему времени цикла.

tnt23
16.04.2019, 18:42
Тут нет ошибки/опечатки? Не широковат ли мячик и в арканоидах, которые я видел, бонус обычно равнялся по ширине кирпичу.

Мячик сам по себе вписан в квадрат 8x8, но семь его фаз дают в результате прямоугольник 8x16.
Бонус сейчас для простоты тоже 8 пикселей в ширину. Можно сделать его шириной в кирпич.

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


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

А как лдпуш мешает отрисовывать мячик честно с маской и наложением (которых пока нет, но будут же когда-нибудь)? Разве что несколько геморройно.

svofski
16.04.2019, 19:03
А как лдпуш мешает отрисовывать мячик честно с маской и наложением (которых пока нет, но будут же когда-нибудь)? Разве что несколько геморройно.
Он по-прежнему помогает, но выгода от метода заметно уменьшается.

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


Не широковат ли мячик
Я видел Арканоиды, где мячики были суперпробойными, где их могло быть тьма как много, но вот никогда не видел, чтобы вдруг мячик превращался в нормальное такое ядро размером 2х4 кирпича. Это был бы зачетный бонус ;)

ivagor
16.04.2019, 19:11
чтобы вдруг мячик превращался
Да я забыл, что у tnt23 все цветное, поэтому удивился ширине мячика.

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

tnt23, вопрос общего характера. У тебя есть некий целевой FPS?

tnt23
16.04.2019, 19:31
У меня в планах много бонусов - в виде падающих и прилипающих к ракетке якорей, например, или примерзающего к кирпичам мячика.

FPS целевого нет, есть желание сделать быстро и с переливающимися врагами.

svofski
16.04.2019, 19:37
К слову о FPS, древний CGA-Арканоид, в который я рубился на Поиске, имел весьма переменный FPS. Может быть этого не было заметно на нормальной писишке, но на Поиске это ощущалось очень хорошо и даже помогло мне пройти его до конца. Я вообще тормоз и будь он сильно быстрее я б не справился.

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

(или это раскидайчик? чего-то у меня все смешалось)

tnt23
16.04.2019, 20:51
К слову о FPS, древний CGA-Арканоид, в который я рубился на Поиске, имел весьма переменный FPS. Может быть этого не было заметно на нормальной писишке, но на Поиске это ощущалось очень хорошо и даже помогло мне пройти его до конца. Я вообще тормоз и будь он сильно быстрее я б не справился.

О, а можно мячик-расстегайчик на веревочке? А то задалбывает ловить его снизу ракеткой.

(или это раскидайчик? чего-то у меня все смешалось)

Мячик-расстегайчик - это мячик-раскидайчик моего детства после аутопсии.

В приличных арканоидах есть некое подобие, временное примерзание к ракетке. Но можно и на веревочке, если освоить-таки Брезенхема.

А под FPS вы, наверное, имеете в виду "постоянную скорость геймплея независимо от количества движущихся объектов"?

ivagor
16.04.2019, 21:48
"постоянную скорость геймплея независимо от количества движущихся объектов"?
Примерно да. Например целевой FPS 50. Надо посчитать, сколько спрайтов уместится в кадр. Если дизайн позволит иметь больше спрайтов, чем уместится в кадр, то произойдет замедление в два раза (а если намного больше, то и в три и больше).

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

В идеале надо еще и изменения тайлов учитывать, например выбивание кирпичей, но это одномоментные события, если на них чуть тормознет - это не критично, т.к. практически незаметно.

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

На всякий случай уточню, что я про случай с ожиданиями ГК после каждого цикла обновления, или с прерываниями, привязанными к ГК.

tnt23
16.04.2019, 21:59
Надо посчитать, сколько спрайтов уместится в кадр

"лдпушной" вариант вывода цветного битмапа 8x8 занимает 270 тактов:

BumpBitmap8x8
; преамбула
di
mvi a, ENROM
out BANKING
; сохранить SP в HL
lxi hl, 0
dad sp
xchg ; теперь старый указатель стека в DE
lxi hl, SCREEN+8
; выводим первый столбик, снизу вверх
;lxi sp, SCREEN+8
sphl
lxi bc, 0102h
push bc
lxi bc, 0304h
push bc
lxi bc, 0506h
push bc
lxi bc, 0708h
push bc
; выводим второй столбик
;lxi sp, SCREEN+8+256
inr h
sphl
lxi bc, 090ah
push bc
lxi bc, 0b0ch
push bc
lxi bc, 0d0eh
push bc
lxi bc, 0f00h
push bc
; восстановить SP
xchg
sphl
; постамбула
xra a
out BANKING
ret

Вспоминая ранее сделанные выкладки про ~157 тактов на растровую строку, получим 256*157/270=148 (примерно) спрайтов 8x8 за видимую часть кадра.

svofski
16.04.2019, 22:11
Мячик-расстегайчик - это мячик-раскидайчик моего детства после аутопсии.
Точно, все они плохо кончали.

Временное примерзение это бонус [C]atch. Неотъемлемая часть Арканоида, хотя принадлежит к категории бесящих меня из-за того, что нарушает ритм и у таких неуклюжих слонопотамов, как я, неминуемо приводит к потере мячика. Как и [L]aser.

Кстати о ширине ракетки, ты подумал о [E], Vaus enlargement pill?

Целевой FPS 50 это было бы очень круто.

tnt23
16.04.2019, 22:23
Кстати о ширине ракетки, ты подумал о [E], Vaus enlargement pill?

Это как раз просто. Для нетребовательных пользователей "Океана" можно наплевать на изящное попиксельное разбухание рабочего органа и сразу ХЫХ! удлинить его на 8 пикселей.

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

(А прямо сейчас практически задарма реализован бонус [F]loor на постоянной основе)

ivagor
17.04.2019, 06:13
148 (примерно) спрайтов 8x8 за видимую часть кадра
На мой взгляд это очень-очень-очень оптимистичная оценка, разве что у тебя получится выводить все спрайты без маски и без восстановления фона. И еще не понял, почему считаешь за видимую часть кадра - речь о выводе равномерно распределенных по Y спрайтов отсортированных по этой координате (впереди луча или за лучом)?

tnt23
17.04.2019, 09:03
На мой взгляд это очень-очень-очень оптимистичная оценка, разве что у тебя получится выводить все спрайты без маски и без восстановления фона. И еще не понял, почему считаешь за видимую часть кадра - речь о выводе равномерно распределенных по Y спрайтов отсортированных по этой координате (впереди луча или за лучом)?

Да, оценка слишком оптимистичная. Можно ее уменьшить в 10 раз, 14 мелких спрайтов тоже будет неплохо. Про видимую часть кадра это я думал о чем-то отвлеченном.

svofski
17.04.2019, 11:54
Мячик - 4 спрайтоместа повышенной сложности x3
Бумкающий кирпич - 2 спрайтоместа x 6 (например, анимация буквально два кадра и мячик не успеет выбить много, но мячиков 3)
Бонус - 2 спрайтоместа x 1
Летающая шапка - 4 спрайтоместа среднего уровня сложности (могут быть поверх друг друга) x 4 (например)

= 12 + 12 + 2 + 16 = 42 спрайтоместа для полноценной игры в которой постоянно все колбасится, вертится, бумбумы, эх и улюлюканье. Надо постараться уменьшить оптимизм не в 10, а в 3 раза.

ivagor
17.04.2019, 12:08
Бумкающий кирпич
Что это такое?


Бонус - 2 спрайтоместа x 1
В арканоидах иногда падает несколько бонусов одновременно и если шарик выбил их сверху то они пролетают над кирпичами. Несколько бонусов одновременно можно и не поддерживать, но пролет над кирпичами надо предусмотреть, т.е. это спрайты с наложением.

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

svofski
17.04.2019, 13:31
Бумкающий кирпич

Что это такое?
Кирпичи без анимации исчезают? Ну может быть тогда этого не надо. Мне казалось, что они чуть-чуть рассеиваются в пыль. Наверное и правда это слишком.



В арканоидах иногда падает несколько бонусов одновременно
Ах-ха, а вот и нет, это только в новоделах. Известное правило: для максимизации счета не ловить тройной шарик, или тут же сливать два лишних, потому что три шарика выбивают три кирпича сразу, а бонус может падать за раз только один, а каждый бонус - это +1000. Из фиксированного числа кирпичей одним шариком вышибается больше бонусов.

Это конечно классический Арканоид и совсем необязательно делать именно так.

ivagor
17.04.2019, 14:10
Кирпичи без анимации исчезают?
Скорее всего зависит от конкретного порта. На спеке цвет меняют (очень быстро) перед тем как исчезнуть.


Ах-ха, а вот и нет, это только в новоделах.
Интересно, значит это я по какому-то клону арканоида запомнил. Ну тем лучше (проще).

svofski
17.04.2019, 14:51
В Попкорне три паверапа за раз.

tnt23
17.04.2019, 16:15
На спеке цвет меняют (очень быстро) перед тем как исчезнуть.

Возможно, это следствие небыстрого стирания кирпичей конкретно на спеке (сначала гасят атрибуты, потом стирают пиксели)

ivagor
17.04.2019, 16:26
Возможно, это следствие небыстрого стирания кирпичей конкретно на спеке (сначала гасят атрибуты, потом стирают пиксели)
Все относительно, но спек быстрее любого советского компа на 8080, т.ч. вряд ли. И там несколько цветов меняются перед стиранием кирпича, т.е. он как бы переливается. Не уверен, что невооруженным взглядом рассмотрел бы, смотрел в отладчике по циклам.
А "рассыпание" кирпичей есть, например, в векторовском арканоиде. Но там от арканоида одно название, только ракетка, мячик и кирпичи. Я бы за пару дней такую штуку сделал, кроме графики, которая там вроде частично из попкорна. На векторе есть практически нормальный арканоид (с бонусами) - кираш, но там мне графика не нравится.

tnt23
17.04.2019, 16:34
Предсмертную анимацию кирпичей я бы тоже сделал (если хватит ресурсов). Лопающиеся шапки (ну и арго у нас тут), по идее, это та же предсмертная анимация.

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


В Попкорне три паверапа за раз.

В Batty, если правильно помню, поливание из пулемета приводит к массовому бонусопаду.

svofski
17.04.2019, 17:24
То есть случается бонос. Ну и арго у нас тут.

tnt23
17.04.2019, 17:47
То есть случается бонос. Ну и арго у нас тут.

Да, аргонавты мы.

svofski
17.04.2019, 17:59
Зазырил Батты на ютубе. Наворотов там вагон, конечно. Хотя по крайней мере на ютубе обычные кирпичи исчезают сразу. Но вот те, что не вышибаются сразу, дразнятся с анимацией. Я про них подзабыл.

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

ivagor
18.04.2019, 07:14
Вопрос к ветеранам и знатокам арканоида. Правильно ли я понял, что шарики/мячики друг с другом не взаимодействуют (не отскакивают друг от друга)?

NEO SPECTRUMAN
18.04.2019, 08:06
Вопрос к ветеранам и знатокам арканоида. Правильно ли я понял, что шарики/мячики друг с другом не взаимодействуют (не отскакивают друг от друга)?
как по мне
такое впервые увидел наверное только на ПЦ-шних magic ball-ах
https://bigfishgames-a.akamaihd.net/en_magicball2magichea/screen2.jpg

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

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

Да и правильно обработать столкновение 2-х мячиков сложнее чем столкновение со стенкой...

tnt23
18.04.2019, 08:07
Вопрос к ветеранам и знатокам арканоида. Правильно ли я понял, что шарики/мячики друг с другом не взаимодействуют (не отскакивают друг от друга)?

Вроде мячики отскакивают только от кирпичей, стен, и злецов (aka enemies, aka foes).

ivagor
18.04.2019, 08:46
Да и правильно обработать столкновение 2-х мячиков сложнее чем столкновение со стенкой...
Меня это и напрягло немного, тем более столкнуться могли бы и 3 мячика, но, к счастью, авторы классики не стали заморачиваться. А от злеца мячик отскочит и злец сдохнет, все просто.

tnt23
18.04.2019, 09:22
Новостей спрайтостроения особых нет, кроме разве что переделал список бонусов в собственно список: теперь бонусные слоты состоят из небольшого заголовка и лдпушной смеси. Внял совету NEO SPECTRUMAN и (скрепя сердце) отвел на слот по 256 байт, это с хорошим запасом на вырост, когда бонус станет в ширину как кирпич. Зато перебирать их стало легко и приятно.

http://sensi.org/~tnt23/ok240/bonuslist.png
78775

Розовое - заголовок слота (тип бонуса, "скорость" и проч.), желтое - экранный адрес для вывода, зеленое - собственно пиксели.

ivagor
18.04.2019, 09:43
Бонусы будут выводиться без маски? Интересует пролет над еще не выбитыми кирпичами.

tnt23
18.04.2019, 09:55
Бонусы будут выводиться без маски? Интересует пролет над еще не выбитыми кирпичами.

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

https://sensi.org/~tnt23/ok240/bonusfall.png

ivagor
18.04.2019, 10:10
Хорошо, что прет, но рациональность такого подхода (если маски все же будут) по сложности и даже по быстродействию под вопросом. Уже упоминал, что в спековском арканоиде (вроде для фона) используется lhld+push. При пересылке двух байт проигрыш 6 тактов, зато картинки сплошные и отдельно от кода. Сам бы я спортивный экстрим для арканоида вряд ли стал использовать.

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

Сообразил, что если бонусы прямоугольные и шириной с кирпич, то маска не нужна.

tnt23
18.04.2019, 10:24
Хорошо, что прет, но рациональность такого подхода (если маски все же будут) по сложности и даже по быстродействию под вопросом. Уже упоминал, что в спековском арканоиде (вроде для фона) используется lhld+push. При пересылке двух байт проигрыш 6 тактов, зато картинки сплошные и отдельно от кода. Сам бы я спортивный экстрим для арканоида вряд ли стал использовать.

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

Сообразил, что если бонусы прямоугольные и шириной с кирпич, то маска не нужна.

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

svofski
18.04.2019, 12:19
В старинных точно мячики друг с другом не сталкивались. Я даже опешил от вопроса, потому что вот прям в голову не могло прийти такое (как земля таких носит?!). Хотя было бы забавно.

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

Скриншоты боноса и прочие артефакты разработки очень радуют.

tnt23
18.04.2019, 12:40
Если бонус шириной уже в кирпич, то маска нужна только в паре строк сверху и снизу, где он закруглен.

Вот мне (вкусовщина) закругленный кирпич не нравится.

svofski
18.04.2019, 13:20
Если бонусы будут квадратные, то им и вообще никакой маски не нужно, выходит. Значит только проще.



| |
| # # # [][][] # # # [][][] |
| [][][] # # # [][][] # # # |
| |
| |
| o |
| |
| |
| (@@@@) |
|

tnt23
18.04.2019, 15:33
Если бонусы будут квадратные, то им и вообще никакой маски не нужно, выходит. Значит только проще.



| |
| # # # [][][] # # # [][][] |
| [][][] # # # [][][] # # # |
| |
| |
| o |
| |
| |
| (@@@@) |
|


Больше похоже на Питона для Радио-86РК.

Меж тем простенький рендер, распыляющий цветной битмап 8x8 в бонусный пуш-ап буфер, кушает 423 такта.

NEO SPECTRUMAN
18.04.2019, 16:25
Бонусы будут выводиться без маски? Интересует пролет над еще не выбитыми кирпичами.
если нормально выровнять кирпичи по границам байтов
то бонусы можно сделать чисто квадратными
и не нужно будет никакой маски для вывода

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

АХАХА до меня это уже написали :)

ivagor
18.04.2019, 16:49
АХАХА до меня это уже написали
Причем аж два раза

tnt23
18.04.2019, 23:35
Меж тем простенький рендер, распыляющий цветной битмап 8x8 в бонусный пуш-ап буфер, кушает 423 такта.

Попробовал сделать оптимизированный вариант а ля patch, стало 506 тактов. Правильный из этого вывод такой - перестать маяться дурью и заняться более важными вещами: нормальной отрисовкой ракетки, и отрисовкой мячика. И то и другое на фоне уже отрисованного в отдельный буфер игрового поля.

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


"лдпушной" вариант вывода цветного битмапа 8x8 занимает 270 тактов:

А для цветного битмапа 8x16 - 453 такта.

ivagor
20.04.2019, 08:56
Еще один кусок бездумья. Но в отличие от sprite1/2 тут быстро и 4 шарика/мячика. Можно было на полный экран, на скорость это не повлияло бы. Можно было больше шариков, тогда скорость бы уменьшилась.

tnt23
20.04.2019, 09:54
ivagor, быстро, факт.

Я тут подумал (наконец), что попиксельное перемещение мячика и отрисовка каждый кадр позволит ему пересекать экран примерно за 5 секунд. То есть даже при мгновенной отрисовке и умопомрачительной оптимизации кода все равно это будет унылый дрейф. Значит, нужно перемещаться скачками, соответственно отрисовываться не каждый кадр и получить больше времени на процессинг.

Пока овладеваю рисованием мячика в буфер по AND+OR:

http://sensi.org/~tnt23/ok240/andor.png

svofski
20.04.2019, 10:03
Перемещение больше чем на пиксель, конечно да. Но почему это означает отрисовку не каждый кадр и больше времени на процессинг? Туплю..

ivagor
20.04.2019, 11:02
Двигать больше чем на пиксель за кадр можно как минимум двумя организационными способами.
1. Обновлять картинку несколько раз за кадр.
2. Изменять координату более чем на пиксель за кадр.
Первый способ при возможности синхронизации с разверткой не имеет смысла (в sprite6 примерно 115 FPS, но только потому, что в emu для океана нет возможности синхронизироваться с разверткой). В оригинальном арканоиде большую (даже бОльшую) часть времени мячик шарик скачет на несколько точек за каждый цикл обновления.

tnt23
20.04.2019, 11:37
Перемещение больше чем на пиксель, конечно да. Но почему это означает отрисовку не каждый кадр и больше времени на процессинг? Туплю..

Больше времени на процессинг, потому что нет этой спешки "ааа не успеваем рендерить, премьера через тысячу тактов". Отрисовывать можно и каждый кадр (восстановить намятые другими спрайтами бока), а рендерить не торопясь несколько кадров.

svofski
20.04.2019, 12:25
Я думал мы разжевали скорость мячика и приращения несколько страниц назад в мельчайших деталях. Он перемещается больше, чем на 1 пиксель за кадр (иначе в пределе 50 пикселей в секунду), движется всегда скачкообразно, вычислять это можно ворохом способов, которые отличаются в деталях, но эквивалентны друг другу.

Отрисовывать v рендерить, чем отличается? Ладно, по-моему тут какие-то дебри языкознания и на деле все понятней, чем кажется от прочтения форумных постов.

tnt23
20.04.2019, 12:33
Я думал мы разжевали скорость мячика и приращения несколько страниц назад в мельчайших деталях.

Да, ту ценную кашицу я оставил до времени ферментироваться. Про скорость в 1 пиксель/кадр как-то не удержалось в голове, виноват.


Отрисовывать v рендерить, чем отличается?

У нас, казахов, рендерить = нарисовать в неэкранный буфер. Отрисовать = переместить из буфера в экранную память.

HardWareMan
20.04.2019, 13:26
У нас, казахов, рендерить = нарисовать в неэкранный буфер. Отрисовать = переместить из буфера в экранную память.
Ты не имеешь права так говорить.

svofski
20.04.2019, 14:20
То есть ты рендеришь в оффскрин битмап, который потом собираешься отрисовать на экран. Прикольно. А не жирно на Океане такое делать, слайдшоу не получится?

tnt23
20.04.2019, 14:37
То есть ты рендеришь в оффскрин битмап, который потом собираешься отрисовать на экран. Прикольно. А не жирно на Океане такое делать, слайдшоу не получится?

Ну сейчас так медленно, но работает. Где-то много сообщений тому назад хвастался, что мячик отрисовывается сперва в свой буфер слоями (снизу фон, потом тайлы, сверху сам мячик).
Причем работает медленно не в последнюю очередь из-за необходимости каждый раз рендерить несколько разных частей соседних кирпичей.

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


Ты не имеешь права так говорить.

Почему?

HardWareMan
20.04.2019, 14:59
Почему?
Ты тожероссиянин.

svofski
20.04.2019, 15:32
tnt23, да, я тоже подзабыл, что у тебя замах очень, просто океанически, глубокий. Виноват. Наверное столько слоев и правда проще не сделаешь.

tnt23
20.04.2019, 19:30
tnt23, да, я тоже подзабыл, что у тебя замах очень, просто океанически, глубокий. Виноват. Наверное столько слоев и правда проще не сделаешь.
Я бы рад без фона, но есть категория граждан, для которых арканоид без фона все равно что тетрис с настоящим RNG :)

ivagor
20.04.2019, 19:35
Если будет голосование, то я готов отдать голос за безфона, на спеке первый арканоид без фона и норм. Но мячики все равно придется с маской выводить.

svofski
20.04.2019, 20:32
Для меня вообще все наоборот. И так не разберешь, что там мельтешит. А на рябящем фоне, когда пытаешься увидеть, что происходит, просто глаза лопаются. Это наверное непростительное упрощение, но у глазного нерва и зрительной коры ограниченная пропускная способность. Типа предельного битрейта у видеокодека. И вот когда приходится вычленять полезную информацию из шума, у меня перегруз видимо наступает быстрее, чем у среднего потребителя видеоигр (которого я представляю совсем лягушкой, у которой темпоральная фильтрация случается чуть ли не прямо в сетчатке). Немаловажно еще то, какой контраст между фоном и объектами можно создать при тех цветах, что доступны Океану. Арканоиды с фоном обычно начинаются там же, где появляется более-менее свободный выбор цветов. Хотелось бы посмотреть на макет уровня.

NEO SPECTRUMAN
20.04.2019, 21:05
можно залить монотонным цветом
http://speccy.info/w/images/5/5f/Arkanoid_Game.gif
https://viva-games.ru/wp-content/uploads/zx-spectrum/screens/in-game/A/Arkanoid.gif-384x288.png
уже будет не так скучно
при смене уровней

+не влияет на скорость отрисовки
просто нужно будет слегка модифицировать спрайты каждый уровень

tnt23
20.04.2019, 23:15
Если будет голосование, то я готов отдать голос за безфона, на спеке первый арканоид без фона и норм. Но мячики все равно придется с маской выводить.

Я тоже за черную бездну вместо фона, мне она как-то эстетически ближе. Мячики (в количестве 1 штуки) уже выводятся с маской.

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


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

Добавил в список неотложных фич кнопку PAUSE, чтобы можно было поразглядывать пиксельфарт в самые драматические моменты. Но я полностью согласен, фон в Batty, к примеру, меня просто убивал.

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


можно залить монотонным цветом

У Океана с фоном довольно фигово, и пригодных палитр мало, чтобы можно было и в мультиколоре использовать, и мячик чтобы оставался одного цвета (зеленого).

NEO SPECTRUMAN
20.04.2019, 23:33
У Океана с фоном довольно фигово, и пригодных палитр мало, чтобы можно было и в мультиколоре использовать, и мячик чтобы оставался одного цвета (зеленого).
так вам шашечки или ехать?
вон на скриншотах выше ракетка вполне принимает цвет фона и ниче
пускай и шарик будет другого цвета
главное чтоб из светлых цветов белый желтый голубой
на темном фоне черный синий красный
чтоб шарик всегда контрастировал

и я имею в виду не просто смену палитры
а перерисовку спрайтов перед каждым уровнем под новую палитру

да я понел что палитр в океане мало

ivagor
21.04.2019, 08:23
Для кода одноцветный (любого цвета) фон хорош тем, что восстанавливать его можно не просто лдпушем, а лдпушпуш..пушем.
С эстетической точки зрения нечерный одноцветный фон дает возможность показать черную тень, но лично я легко переживу отсутствие тени.
Радикальный черный фон (когда он 0й) еще удобен тем, что можно быстрее выводить одноцветные спрайты (только в четные или нечетные колонки). Кроме того, спрайты в таком случае можно выводить и без маски, просто по OR или XOR. Желательно, чтобы они при этом были сплошные, но это не обязательно.

tnt23
21.04.2019, 12:26
Коротенькая анимация про отрисовку мячика поверх фона и тайлов (GIMP рулит). Процедура PaintBall занимает 6500 тактов. Из них 4819 тактов на рендер и 1681 на вывод.

https://sensi.org/~tnt23/ok240/flightoverbricknest.gif

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


так вам шашечки или ехать?
вон на скриншотах выше ракетка вполне принимает цвет фона и ниче

Ну давайте еще спектрумовский клэшинг атрибутов принимать за норму. Не, мне и ехать, и шашечки :)

ivagor
21.04.2019, 12:50
tnt23, вопрос по поводу степени близости к оригинальному арканоиду. Посмотрел бегло размеры игрового поля. У msx, спека, ибм и нес ширина 11 кирпичей. У аркады 13. Высота поля у msx и спека - 23 тайла (по 8 точек), у других не считал. Ты будешь конверсить уровни (если да, то откуда?) или делать свои по образу и подобию?

svofski
21.04.2019, 13:16
Сколько тактов на кадр всего? По Векторовским меркам хорошо выходит, можно примерно 9 мячиков за кадр отрисовать.

tnt23
21.04.2019, 13:54
tnt23, вопрос по поводу степени близости к оригинальному арканоиду. Посмотрел бегло размеры игрового поля. У msx, спека, ибм и нес ширина 11 кирпичей. У аркады 13. Высота поля у msx и спека - 23 тайла (по 8 точек), у других не считал. Ты будешь конверсить уровни (если да, то откуда?) или делать свои по образу и подобию?

Поле для простоты 16 на 16 кирпичей, можно вниз расширить до 24 (хорошее компромиссное значение, но чуть сложнее вычисления) или до 32. Слева и справа неиспользуемые колонки по 2 кирпича каждая, итого полезных кирпичей в ширину 12.

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

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


Сколько тактов на кадр всего? По Векторовским меркам хорошо выходит, можно примерно 9 мячиков за кадр отрисовать.

~157 тактов на строку (62 мкс вроде), в кадре 312 строк, получается ~49,000 тактов. Это еще PaintBall использует небыструю процедуру PaintBitmap два раза. А если его упихать в лдпушбуфер, должно стать пободрее.

tnt23
21.04.2019, 20:17
Бонусы теперь парят поверх кирпичей. Сделать это оказалось не очень сложно: бонус смещается всегда на одну строку вниз, поэтому и восстанавливать надо лишь верхнюю затертую строку.

https://www.youtube.com/watch?v=jlzzGvhcSJ0

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

http://sensi.org/~tnt23/ok240/bonusfly.png

Ну и бонус рисуется без маски, что, конечно, заметно снижает его ценность.

svofski
21.04.2019, 23:17
Очень красиво. Есть странная дерготня и мячик рвет лучем, но я так понимаю, что это какие-то проблемы с эмуляцией.

Почему нельзя сделать бонус четной высоты, и его углы квадратными (раз ты все равно так хотел), чтобы 1) лишить окантовки 2) сделать незаметной его безмасочность? Хотя я лично предпочитаю бонусы в виде кусков мыла.

tnt23
21.04.2019, 23:53
Бонус и так четной высоты. Просто рисуется он через push (4 пуша на 8 строк), и дополнительный push добавляет еще две строки. Ну в одну я пишу верхний байт, а во вторую ленюсь и скаредничаю, отчего она остается нулем и видна в виде черной полоски.

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

svofski
22.04.2019, 00:30
Ну тогда сделать его нечетной высоты?

ivagor
22.04.2019, 05:53
Есть еще вариант. Печатаем верхний push первым, после него inx sp. Соответственно откорректировать адрес модификации lxi этого push (я так понимаю, что тут модифицируемый код).

Upd: для океана не подходит, на что указал далее tnt23

tnt23
22.04.2019, 09:17
Есть еще вариант. Печатаем верхний push первым, после него inx sp. Соответственно откорректировать адрес модификации lxi этого push (я так понимаю, что тут модифицируемый код).

Код модифицируемый, выглядит так:


lxi hl, SCREEN+8
; выводим первый столбик, снизу вверх
sphl
lxi bc, 0fc1eh
push bc
lxi bc, 4723h
push bc
lxi bc, 4321h
push bc
lxi bc, 42fch
push bc
; это бонусный битмап, он ползет сверху вниз, а выводится снизу вверх
; что весьма удобно для затирания следа сверху
lxi bc, 0000h ; только учтем, что выводятся две строчки
push bc


Последним идет push, затирающий след (в него впечатывается восстанавливаемый байт экрана). Вариант печатать верхний push первым не вариант, потому что lxi h/sphl выполняется один раз в начале для самой нижней строчки выводимого битмапа, и рисование идет снизу вверх.

ivagor
22.04.2019, 09:38
Точно, для океана мое предложение не подходит, только для вектора.

tnt23
01.06.2019, 12:14
Небольшое обновление по океаноиду. Наконец переделал выбивание кирпичей "нормально", анализом четырех квадрантов окрестности мячика, где кирпичи могут оказаться.

Технически результатом я доволен, эстетически нет, потому что процедура обхода квадранта всегда одна и та же (проверили кирпич NW, если там пусто - NE, потом SW и SE) без учета стороны, с которой подлетел мячик. To do later.

Также наконец добавил отскок от дубины, пока без изменения угла отражения в зависимости от. To do later.

И еще скопипастил из тетриса простейшие звучки.

ivagor
01.06.2019, 16:10
tnt23, радует, что ты продолжаешь пилить океаноид.
У меня в целом по игропригодности океана основной вопрос к клавиатуре, о чем я уже писал. Пошаговый арканоид (смотрел прошлую версию) - это оригинально, но это слишком оригинально. Для реала планируешь корркетировать работу клавы?

tnt23
01.06.2019, 17:29
tnt23, радует, что ты продолжаешь пилить океаноид.
У меня в целом по игропригодности океана основной вопрос к клавиатуре, о чем я уже писал. Пошаговый арканоид (смотрел прошлую версию) - это оригинально, но это слишком оригинально. Для реала планируешь корркетировать работу клавы?

Пошаговость скорее следствие включенного режима отладки (кнопка D).

Работу клавиатуры думаю переделать исходя из того, что у меня есть по факту - PS/2 клавиатура с автоповтором. Кратковременное нажатие одной из стрелок приведет ракетку в движение. Ракетка пройдет некоторое расстояние (небольшое, подберу экспериментально) и остановится. Если продолжать удерживать кнопку, автоповтор приведет к "подпиныванию" ракетки и она будет ехать как ни в чем не бывало (нивелируя тем самым паузу перед автоповтором).

ivagor
01.06.2019, 17:33
Пошаговость скорее следствие включенного режима отладки (кнопка D).
О, не знал, попробую, когда доберусь до бинарника.

tnt23
27.06.2019, 20:32
Перерисовал цифры из второго спектрумовского арканоида, приделываю счет(чики). Команда DAA рулит.

http://sensi.org/~tnt23/ok240/score_xx.png

svofski
27.06.2019, 20:45
DAA-то даа...

ivagor
27.06.2019, 20:46
tnt23, несколько провокационный вопрос - после прохождения всех уровней будет зацикливание или какая-нибудь картинка или что-то еще?

tnt23
27.06.2019, 20:50
ivagor, так далеко я не заглядывал. В классическом арканоиде на последнем уровне игрока встречает голова с острова Рапа-Нуи. Можно будет вместо головы нарисовать что-нибудь эстетически более простое, вроде параллелепипеда из "Космической одиссеи".

Black Cat / Era CG
27.06.2019, 20:56
голова с острова Рапа-Нуи
Это Doh, он каноничен!

ivagor
27.06.2019, 21:02
нарисовать
Как насчет позаимствовать/украсть картинку?

tnt23
27.06.2019, 21:17
Как насчет позаимствовать/украсть картинку?

Можно, перерисовав ее под океанскую палитру.

svofski
27.06.2019, 21:55
А вот дажа есть така эможа:

тьфу как обычно, форум сглатывает. https://emojipedia.org/moyai/

tnt23
28.06.2019, 09:33
А вот дажа есть така эможа:

тьфу как обычно, форум сглатывает. https://emojipedia.org/moyai/

Я художник, я так вижу:

69403

Black Cat / Era CG
28.06.2019, 11:19
Вот из первой части на Денди
https://www.spriters-resource.com/resources/sheets/58/61589.png
Денди и вторая часть
https://www.spriters-resource.com/resources/sheets/114/116682.png
https://www.spriters-resource.com/resources/sheets/68/71111.png
https://www.spriters-resource.com/resources/sheets/47/50419.png
PC
https://www.spriters-resource.com/resources/sheets/71/74505.png
Можно перерисовать вариант какой-то ж.

tnt23
28.06.2019, 12:10
Black Cat / Era CG, а вытащи битмапы из обоих спектрумовских арканоидов?

Black Cat / Era CG
28.06.2019, 12:26
А я не вытаскивал, я в сети нарыл. Но можно попробовать, если Doh там есть.

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

Так вот по-быстрому мне его найти там не удалось.

ivagor
28.06.2019, 12:39
Есть еще вариант (сам собирался, но запал прошел) c msx. Берем meisei (https://www.zophar.net/msx/meisei.html), запускаем в нем arkanoid (http://www.msxabandonware.com/en/gameitems/arkanoid/290). Во время игры (после заставки) смотрим окошки Tile Viewer и Sprite Viewer - там практически вся нужная графика, в т.ч. и голова. Можно сохранить в бинарник или в png.

tnt23
28.06.2019, 13:52
ivagor, это вариант для MSX или аркадной версии. Мне же хотелось бы именно спектрумовской графики. Ну это так, не особо принципиально уже.

goodboy
28.06.2019, 13:54
битмапы из обоих спектрумовских арканоидов?
а что именно нужно ?

Black Cat / Era CG
28.06.2019, 15:03
а что именно нужно ?
Спрайт босса, по имени Doh. Что-то я его в них не нашел.

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

Но я не особо тщательно искал.

tnt23
28.06.2019, 15:35
goodboy, да все, что есть. Но главным образом интересуют



заставки
спрайты врагов
графика окантовки игрового поля
спрайты боссов
графика надписей

ivagor
28.06.2019, 16:01
Рекомендую EmuZWin (http://zxspectrum.online/emulyatory/) (или можно погуглить другие места для скачивания). Загружаем arkanoid (http://www.worldofspectrum.org/infoseekid.cgi?id=0000255), Tools>Sprite Finder. В старших адресах можно увидеть: буквы и цифры (при width 1), спрайты врагов и шарик (при width 2), ракетки и надписи (при width 6), голову (при width 7). Может что пропустил, смотрел очень бегло. Должен признать, что в спековской версии спрайты врагов круче.

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

Упустил надпись ARKANOID (width 20)

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

Еще забыл космический корабль, или как там его (width 19)

Black Cat / Era CG
28.06.2019, 16:07
А. Да. Вот башка, по адресу DA10 (забыл я кое-что).

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


Еще забыл космический корабль, или как там его (width 19)
E12D вроде.

goodboy
28.06.2019, 16:13
заставки
так сойдёт ?
https://yadi.sk/i/Qb2XtTXH5zxlhA
https://yadi.sk/i/o46HmplzJFsZFA

ivagor
28.06.2019, 16:13
Не упомянул "окантовки игрового поля" - они ожидаемо видны при width 1 и идут за фирменными буквами. Вот "окантовки" мне больше в msxной версии нравятся.

tnt23
28.06.2019, 16:25
Не упомянул "окантовки игрового поля" - они ожидаемо видны при width 1 и идут за фирменными буквами. Вот "окантовки" мне больше в msxной версии нравятся.

Можно будет сделать специальную версию под тебя.

ivagor
28.06.2019, 16:37
:)
Пригляделся и понял, что с окантовками дело не только в форме, но и в наличии двух оттенков белого/серого (или трех, если считать черный) в одном знакоместе, в спеке такое невозможно. И раньше я как-то не обращал внимания, что в msxном похоже маленько урезали неигровую графику, чтобы арканоид влез в картридж 32 Кб. Вот арканоид 2 для msx 2 крутой, но там графику не так просто искать и она слишком цветная для океана.

svofski
28.06.2019, 18:15
А варианты скриншот/png -> волшебныйскрипт.py -> beautifulpicture.asm не рассматриваются? Это по-моему добавляет гибкости в выборе материалов для переработки, а особенности Океана можно учитывать процедурально. А в случае медленных картинок можно даже добавлять распаковку на ходу итд.

ivagor
28.06.2019, 18:20
скриншот/png -> волшебныйскрипт.py -> beautifulpicture.asm
Если речь про спек, то первый элемент цепочки можно (как вариант) заменить на бинарник, выгруженный из эмулятора с работающей программой.
А c msx я почти так делал для пары-тройки игрушек: брал png из meisei, потом программка на дельфи, потом бинарник для компоновки с исходником.

goodboy
28.06.2019, 18:57
на спеке например для логотипа игры аттрибуты задаются одинаковыми для каждой строки (высотой 8pix)
сначала печатается ч/б картинка, а потом программно красятся строки.

tnt23
28.06.2019, 19:28
Вариант со скриптом питоньим тоже можно. Я пока наслаждаюсь процедурой рисования в редакторе graf, последующей выгрузкой результата в какой-нибудь bitmap.bin, и его паковкой в base64 для копипасты в сорец по db64.

NEO SPECTRUMAN
29.06.2019, 06:44
Это Doh, он каноничен!
настолько
что у него даже есть собственный клешинг
https://jpegshare.net/images/47/42/47421ed8d65f8822789c57e7c848d7e4.png

ivagor
29.06.2019, 07:12
В спековском арканоиде 2 "окантовки" получше, чем в первом.

tnt23
29.06.2019, 08:30
В спековском арканоиде 2 "окантовки" получше, чем в первом.

Во втором и цифры попригожее.

svofski
02.07.2019, 01:40
В надежде ускорить разработку шедевров я написал утилиту для преобразования png в то, что мне показалось пригодным для использования в Океане:

https://github.com/svofski/ocean-240/tree/master/pngconvert

На входе требуется png удобоваримого размера, использующий приблизительно те цвета, что ожидается увидеть в целевой палитре. Точно целиться не надо. Какой именно пиксель-формат значения не имеет, потому что внутри все работает в труъколоре. Если запустить с опцией -stub, сгенерится .asm, который рисует картинку при запуске (хинт: .ok-файл можно указать emu.exe в командной строке, или даже настроить emu как кастомный вьювер для .ok файлов в фаре).

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

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

P.S. Ну а чо
https://i.imgur.com/Z8nT134.png

tnt23
02.07.2019, 11:33
svofski, очень даже нуачо!

goodboy
02.07.2019, 12:10
для примера дёрнул спрайты первых врагов
https://3.downloader.disk.yandex.ru/preview/ce72d6cd2735310988ff370e688976a2940426ef9f4c0c8ea4 c4da9c456f6f07/5d1b59db/_htkkkx4q2DoTw4Tx5cy4M_LdgTdBzxgBkLSr2kGsw85qpcb2c S_zaURVe2hWuXYmssPqjQfympOc6DcUIJoAg%3D%3D?uid=0&filename=ark3.png&disposition=inline&hash=&limit=0&content_type=image%2Fpng&tknv=v2&size=1263x911

svofski
02.07.2019, 12:21
А вот меняя палитру от уровня к уровню можно здорово разнообразить игру. Хорошо бы иметь пару фиксированных цветов-анкеров, чтобы не казалось, что это просто мельтешня. Например, черный для фона и, хотел предложить красный для Васи, но вспомнил, что Вася цветной. Так что надо придется похожие.

NEO SPECTRUMAN
02.07.2019, 12:59
В спековском арканоиде 2 "окантовки" получше, чем в первом.
если про узорчек фона
то я на этом узорчике
ничего не вижу
мячик с ним прекрасно сливается...
так что это плохой пример

tnt23
02.07.2019, 13:40
А вот меняя палитру от уровня к уровню можно здорово разнообразить игру. Хорошо бы иметь пару фиксированных цветов-анкеров, чтобы не казалось, что это просто мельтешня. Например, черный для фона и, хотел предложить красный для Васи, но вспомнил, что Вася цветной. Так что надо придется похожие.

Еще мячик зеленый. В принципе можно и мяч перекрашивать, конечно.

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


В надежде ускорить разработку шедевров я написал утилиту для преобразования png в то, что мне показалось пригодным для использования в Океане:

https://github.com/svofski/ocean-240/tree/master/pngconvert



С примеров из папки inputs я хохотался весь. По-моему, прекрасная заготовка для короткого мультиколорного интро.

tnt23
08.07.2019, 23:56
По мелочи: cкопипастил первый уровень спектрумовского арканоида, сделал распаковку уровней в игровое поле, добавил вывод уровня.

http://sensi.org/~tnt23/ok240/score_and_level.png

tnt23
09.07.2019, 18:24
Добавил ловлю бонусов ракеткой (50 очков/бонус)

svofski
09.07.2019, 19:28
А справа это подсказка, какая будет следующая ракетка?

tnt23
09.07.2019, 20:35
А справа это подсказка, какая будет следующая ракетка?

Справа Склад Ракеток, пока нефункциональный.

(этот пользователь хотел сказать "спасибо" за ценное сообщение)

tnt23
10.07.2019, 14:44
Перетащил немного графики из спектрумовского оригинала.

http://sensi.org/~tnt23/ok240/frame.png

ivagor
10.07.2019, 14:54
Плюсую окантовку из второго

NEO SPECTRUMAN
11.07.2019, 22:03
По мелочи: cкопипастил первый уровень спектрумовского арканоида, сделал распаковку уровней в игровое поле, добавил вывод уровня.

http://sensi.org/~tnt23/ok240/score_and_level.png
и еще немного моего недовольства

смотрю как на "советских компьютерах с 4-мя цветами на точку" пытаются получить больше цветов...
а результат всегда один

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

а то что яркость изображения с шахматкой просела в 2 раза никто не учитывает...
в итоге чистые RGB цвета просто святятся на фоне других...
...а потом при билинейном масштабировании у шахматки дополнительно еще проседает яркость...


притемнил
https://jpegshare.net/images/52/5a/525a5497eae031f4849772817bc1890d.png

больше цветов
но такой вариант получился плохо различимым
нужно наверно каждый отдельный цвет кирпича рисовать своим узором
https://jpegshare.net/images/4f/87/4f87e375952e3eea25357a3cc90f4749.png

svofski
11.07.2019, 22:45
Идея выравнивать чистые цвета по-моему здравая. Сплошную заливку можно приберечь для противоударных и невышибаемых кирпичей.

А полосатые как-то вычурно смотрятся. Прям глазу больно.

NEO SPECTRUMAN
12.07.2019, 01:14
А полосатые как-то вычурно смотрятся. Прям глазу больно.
мне нравятся зеленные
а остальные режут глаз...

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

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


Сплошную заливку
наверно можно подсвечивать так кирпичи с которыми столкновение

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

кстате без софтварного масштабирования(а значит и на ламповом телевизоре) оно смотриться получше...
https://jpegshare.net/images/3e/e8/3ee8a09affb63fe252fce4eb2a95c9c6.png

tnt23
12.07.2019, 13:20
Кирпичи в косую полосочку мне нравятся, попробую.
Ядовитые чистые цвета сперва хотелось оставить для (будущего) мультиколорного варианта.

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

Пригашенные кирпичи там есть, см. в верхнем ряду NN8, 9 и 10.

svofski
12.07.2019, 13:32
Интересно было бы посмотреть на разные паттерны RGB на студийном™ ЭЛТ-мониторе. Насколько можно вообще приблизиться к белому, хотя бы с расстояния в пять шагов?

tnt23
12.07.2019, 14:26
Интересно было бы посмотреть на разные паттерны RGB на студийном™ ЭЛТ-мониторе. Насколько можно вообще приблизиться к белому, хотя бы с расстояния в пять шагов?

Заходи (с фотоаппаратом), посмотрим вместе. С трех метров все уже расплывается в красивые пятна Роршаха.

ivagor
12.07.2019, 14:49
Совсем оффтоп, извините. Добавили бы авторы третий режим - 256x256, 16 цветов для блока 8x1, и не было бы проблем.

tnt23
12.07.2019, 15:40
Совсем оффтоп, извините. Добавили бы авторы третий режим - 256x256, 16 цветов для блока 8x1, и не было бы проблем.

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

NEO SPECTRUMAN
12.07.2019, 16:06
Наверняка это несложно сделать, напаяв сверху полдюжины корпусов мелкой логики.
только это уже поздно делать...
тк будет никому ненужный новодельный видео режим которого ни у кого нет...
учитывая чот океана и без нового видео режима ни у кого нет...

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


Интересно было бы посмотреть на разные паттерны RGB на студийном™ ЭЛТ-мониторе. Насколько можно вообще приблизиться к белому,

зачем студийный?
хватит телевизора

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

при RGB патерне общая яркость белого всего 85 (если у белого 255)

как вариант можно получить цвет ярче если смешать
синий+желтый
красный+голубой
фиолетовый+зеленый
белый+черный :)

тогда яркость белого уже 128

но в конечном итоге самих цветов мало



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

тогда получается яркость целых 170
но к сожалению
например во львове такой палитры нет
в океане наверно тоже...
из минусов у такого CMYB плохая цвето передача
больше подходящая для фотографий
чем для "кодерских цветов"

https://jpegshare.net/images/09/52/0952c32f1184a90be4e592318780046f.png


еще на восприятие цвета
иногда сильно влияет контур\обводка

svofski
12.07.2019, 16:20
А вот например в игровых консолях частое было дело приперчить картридж кучей памяти, а то и целым чипом для графики. Можно сделать Арканоид картриджем. Учитывая количество Океанов, тиражировать его будет несложно.

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


зачем студийный?
хватит телевизора
Ну где ж его взять.

NEO SPECTRUMAN
12.07.2019, 16:22
А вот например в игровых консолях частое было дело приперчить картридж кучей памяти, а то и целым чипом для графики. Можно сделать Арканоид картриджем. Учитывая количество Океанов, тиражировать его будет несложно.
тоесть мало того что ни у кого нет океана
так еще ни у кого не будет и картриджа
тоесть совсем не вариант...



еще на восприятие цвета
иногда сильно влияет контур\обводка
собственно пример
https://jpegshare.net/images/5e/6d/5e6d13ac26a1d4bbbfd67d3495c28812.png

zx_
12.07.2019, 16:26
NEO SPECTRUMAN, не, ща время творца
вот сделай и люди к тебе потянутся

NEO SPECTRUMAN
12.07.2019, 16:29
основная проблема в жестком проседании яркости
А еще у меня есть подозрение
что после пал кодера (если кто то такой ткнет)
такие "белые" цвета тоже просядут в яркости...

tnt23
13.07.2019, 12:34
Графика кирпичей (два столбика левого полукирпича + два столбика правого полукирпича, всего 32 байта) лежит в сорцах открытая любому хищному взору. Берите, экспериментируйте :)


GREENBRICK
db 0,0,0,0,0,0,0,0
db 255, 255, 255, 255, 255, 255, 255, 0
db 0,0,0,0,0,0,0,0
db 127, 127, 127, 127, 127, 127, 127, 0

svofski
13.07.2019, 14:54
Не совсем по теме, потому что не знаю, откуда вообще в теме взялся PAL.

Прогнал картинки NEO SPECTRUMAN-а через свой симулятор композита. Это очень-очень приблизительно, потому что размеры картинки и тайминги не совпадают. Фантазийный PAL-Okeah-Arkanoid может выглядеть так.
http://sensi.org/~svo/b/arkanoid/crt-arkanoid1.png


Почему я говорю, что тайминги и совсем неточно. Вот псевдо-чб паттерны, пропущенные через ту же фаршеделку:
http://sensi.org/~svo/b/arkanoid/crt-arkanoid2.png


Ну и масштабируя его можно получать все возможные разновидности migraine art.

(Проклятье, сделать нормальный скриншот с экрана в винде с масштабом 1.5 похоже просто невозможно).

NEO SPECTRUMAN
13.07.2019, 15:13
Не совсем по теме, потому что не знаю, откуда вообще в теме взялся PAL.
я думаю что все сильно красиво чтобы быть правдой

смотрим на переход между красным и синим
и между зеленым и фиолетовы
https://upload.wikimedia.org/wikipedia/commons/f/f4/Burnt-in_timecode.jpg
а тут будут такие переходы каждый пиксель...

думаю что такие сочетания должны будут быть с ВНЕЗАПНО заниженной яркостью
мну проверить некак

svofski
13.07.2019, 15:36
Может быть. В MAME я с этим же шейдером, но с другими параметрами, играл в Shamus на Атари при исходном разрешении в половину от этого и расплывалось все очень романтично. Но это все не объективно, подогнано на глаз, чтобы смотрелось.

Лучший источник, который я могу придумать сейчас, это RPi3 настроенная в PAL Progressive, а лучший приемник -- LCD монитор Samsung 215TW, хотя еще есть упоротый TV-тюнер. Оба очень условно труъ, хоть и держатся в рамках стандартов более-менее. Но настройка всего этого оторвет меня от дивана на слишком большое время, а в контексте разработки Арканоида совершенно ничего не даст. Поэтому калибровку шейдеров я пока отложу, хоть это и очень интересная тема.