GameNoname

[parallelno]

jerri, то есть первый буфер который 768 байт содержит байт в котором запакованы данные об индексе тайла во втором буфере и признак действия с тайлом (стереть, нарисовать). Индекс от 0 до 31.
А в момент отрисовки ты по всему первому буферу в 768 байт пробегаешь или как то хитрее например пропускаешь пустые строки?

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

BlaireCas, подход интересный, но требует очень много памяти. Нужно подумать

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

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

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

Если найти быстрый способ определения задевает ли спрайт кого-то ещё или нет, то можно скрестить этот метод с тайловым выводом. То есть рисовать спрайт сразу на экране если он не задевает никого, и рисовать спрайт тайловым методом если задевает.

[BlaireCas]

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

[jerri]

jerri, то есть первый буфер который 768 байт содержит байт в котором запакованы данные об индексе тайла во втором буфере и признак действия с тайлом (стереть, нарисовать). Индекс от 0 до 31.

в первом буфере номера тайлов фона
во втором буфере номер модифицированного тайла 2-255 либо ничего либо 1 команда восстановления фона

А в момент отрисовки ты по всему первому буферу в 768 байт пробегаешь или как то хитрее например пропускаешь пустые строки?

по всему

drop_screen0		
	or	(hl)
	call	nz,drop_tile
	inc	l
	jp	nz,drop_screen0
	inc	h
	ret

[Stl75]

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

Привет всем...

Подумал про обработку буферных областей...
Например...

11111BBB2222

В таком варианте - для буферных областей есть такие варианты -
1. Персонаж из области 1 выходит в B - 1-B,
2. Персонаж в B - B,
3. Персонаж из B - переходит в область 2 - B-2...

Случай 1 - обрабатываем совместно с областью 1,
когда область 1 - обновляем...
Случай 3 - совместно с областью 2...
Если персонажи в 1 и 3 пересекаются с буферными -
обновляем эти буферные персонажи...
Случай 2 - оставшиеся буферные персонажи обновляем отдельно...

???

[BlaireCas]

Подумал про обработку буферных областей...

Персонажи когда рисуются в буфер - типа ставишь 2 например
000000
002200
000000

Рисуешь на экран:
проходишь по массиву, всё что больше 0 {
буфер -> экран
все что больше 1 надо после отрисовки на экран восстановить буфер тем тайлом который там есть
уменьшить на 1
}

Персонаж пошел вправо:
000000
001220
000000
Отрисовались на экран все 1,2, восстановились в буфере те где 2, ну и уменьшаем на 1

Персонаж остановился
000000
000220
000000

Персонаж телепортировался влево (внезапно) - тут восстановит экран там где он был до этого
000000
220110
000000

А еще вообще если без буфера - то можно сделать ведь чтобы персонажи не пересекались друг с другом. Ну мол скелеты чтобы не наезжали на другие скелеты и на игрока. Глядишь и буферизация не нужна станет.

[parallelno]

Попробовал писать таловый рендер, на пол пути бросил изза того что получался чудовишный оверхед на обработку такого рендера. В итоге сделал back buffer на квазидиске.
Пусть пока нет скелеликов, но проделана тонна работы. Персонаж теперь стирается и рисуется в квазидиске. Затем переносится на основной экран. Прерывания не запрещаются. Перенос части библиотеки спрайтов на квазидиск было увлекальным занятием. Функции спрайтов теперь обрабатываются как библиотека с внешними метками. Это буквально дополнительный проект, который компилируется, архивируется, потом линкуется с основной программой. Потом библиотека разархивируется рантайм и копируется на квази-диск. Все функции вызываются оттуда. Это дает допольнительных 8K и будет очень полезно в дальейшем когда настанет время разворачивать циклы. Часть из них уже развернута, но все еще есть что анролить.

[Advertiser]

[svofski]

Размах использования кваза впечатляет. Интересно будет увидеть как это работает с полом и скелетиками.

[b2m]

Пусть пока нет скелеликов

Скелёлики

[svofski]

Скелёлики

Лёлики?

[BlaireCas]

но проделана тонна работы

Ну.. никто никуда не спешит. Люди год пишут игрушки и недописывают (я например и не только). Но вообще с музыкой смотрится очень даже весело. Но постойте? Это что - так ВИ53 может звучать?