В общем-то про линию

[Lethargeek]

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

то есть "менее дёрганное" *****

нет под рукой примера...

это что, вопрос или утверждение? и какого именно нет примера?

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

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

изображение было вполне узнаваемым

хе, тут уже сама формулировка нам говорит, что нужно знать заранее, на что смотришь))

[NEO SPECTRUMAN]

то есть "менее дёрганное" *****

Значет эффект на любителя
меня устраивает
во многих демках встречается...
...тоже не могу щас перечислить

[Destr]

ЧТО "во фрейм"? сколько и каких объектов, куда рисуем? в теневой экран или в буфер каких размеров?

Никаких буферов, никаких теневых экранов, всё напрямую в видео-память, щёлкаем только #7FFD ну и черезстрочно (нафига рисовать одно и то-же постоянно, если 90% времени картинка статична, хоть пользователю и кажется что он бежит с нехилой скоростью по коридору, отстреливая монстров?)
Кстати дешевле (быстрей) получается отрисовать весь кадр снова, но только RES n,(HL) (с теми-же входными данными, которые помним предпросчитаны, чем чистить всякими там POP HL:LD (HL),A)

когда можно просто в b декрементить счётчик от 8 до 0 или инкрементить от f8 до 0
потом ниже тоже, может быть, получится сократить

В октантах 1 и 2 так и было сделано, но стало почему-то ещё медленней

ЧТО "во фрейм"? сколько и каких объектов, куда рисуем? в теневой экран или в буфер каких размеров?
между прочим, одна только лишь очистка неактивного экрана сожрёт полфрейма

256х192 (фулскрин спека, атрибуты к чёрту, только битовая матрица)

[Lethargeek]

никаких теневых экранов ... щёлкаем только #7FFD

взаимоисключающие параграфы

(нафига рисовать одно и то-же постоянно, если 90% времени картинка статична,

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

Кстати дешевле (быстрей) получается отрисовать весь кадр снова, но только RES n,(HL) (с теми-же входными данными, которые помним предпросчитаны,

"дешевле (быстрей) получается" это СКОЛЬКО? как ты СЧИТАЛ?

чем чистить всякими там POP HL:LD (HL),A)

шташташта? чистят буфер просто цепочкой push (6 кб - за ~34 тысячи тактов)
за то же время отрисовкой ты сотрёшь (оптимистично) около 600 пикселей
что всего-то навсего приблизительно один кораблик вблизи в элите

В октантах 1 и 2 так и было сделано, но стало почему-то ещё медленней

даже не могу представить, как, УБРАВ несколько команд, сделать медленней
и при чём тут, спрашивается, октанты, когда нужен просто счётчик сканлайнов
для которого без разницы, где считать

[Destr]

взаимоисключающие параграфы

Та не, под теневым экраном я понимаю фрагмент ОЗУ который выбрасывается (вручную) в видеопамять, систему 128кб для простоты называю экран 5 и 7, ну это уже аппаратный финт и конечно отношение к нему другое, простите мой французкий (всё-таки настоящего образования у меня нет, вот и пришлось выработать собственную терминологию, чтоб хоть как-то структуризировать собственные представления)

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

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

"дешевле (быстрей) получается" это СКОЛЬКО? как ты СЧИТАЛ?

Полного протокола не могу дать, ибо потратил очень много времени, бумаги и электричества, для простоты скажу - мог-бы управится и в ТРИ раза быстрей (ну примерно за год, против потраченых 3.4) но не было бы полной уверенности (перепроверял себя несколько раз, пробовал разные варианты - в подсчёте опирался на систему контроля эмуля, Unreal, он пишет сколько тактов съедается в цикле, для проверки пересчитывал вручную, по справочной системе И.Рощина, HelpZ80)

шташташта? чистят буфер просто цепочкой push (6 кб - за ~34 тысячи тактов)
за то же время отрисовкой ты сотрёшь (оптимистично) около 600 пикселей
что всего-то навсего приблизительно один кораблик вблизи в элите

Потому и подумалось - а начерта что-то вообще чистить, если надо снова отрисовать почти то-же самое?
Ну повернулся кораблик чуток, блин, всё что-ли снова, очищаем экран, выводим?
Уж больно затратно, это всё мелькнёт на 1/50 секунды всего-то...

даже не могу представить, как, УБРАВ несколько команд, сделать медленней
и при чём тут, спрашивается, октанты, когда нужен просто счётчик сканлайнов
для которого без разницы, где считать

В процессе экспериментов было установлено что даже УБРАВ команду и вроде-бы СОКРАТИВ процесс - можно вдруг обнаружить что стало медленней. Например jp с,nnnn хорошо ветвляет в 0 и 3 октантах, и очень отвратительно в 1 и 2, убрав его из ветвлений можно ускорить отрисовку по тем самым ret, а вот вертикально не даёт разрядная сетка и сегментация скрина...
Процедура из спектрумэксперта работает шустрей, хоть и занимает объёмы больше, а средний такт на пиксель почти такой-же (58 против 60)

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

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

[Lethargeek]

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

какой "шустренько"? это тебе только так кажется, потому что такты не желаешь считать нормально

Полного протокола не могу дать, ибо потратил очень много времени, бумаги и электричества, для простоты скажу - мог-бы управится и в ТРИ раза быстрей (ну примерно за год, против потраченых 3.4) но не было бы полной уверенности (перепроверял себя несколько раз, пробовал разные варианты - в подсчёте опирался на систему контроля эмуля, Unreal, он пишет сколько тактов съедается в цикле, для проверки пересчитывал вручную, по справочной системе И.Рощина, HelpZ80)

ты придуриваешься? вопрос был про время отрисовки/очистки кадра

Потому и подумалось - а начерта что-то вообще чистить, если надо снова отрисовать почти то-же самое?

начерта тогда вообще рисовать трыдэ, да и вообще рисовать? пиши тексты, "будоража воображение"

Ну повернулся кораблик чуток, блин, всё что-ли снова, очищаем экран, выводим?

нет, блин, лучше, когда кораблик повернулся в одну сторону, а смещаться будет в другую!
и как радостно прицеливаться в такое!

Уж больно затратно, это всё мелькнёт на 1/50 секунды всего-то...

не мелькнёт, потому что никаких 50 fps, конечно же, не получится
вытяни хотя бы 12 минимум (у элиты на заставке - от 4)

В процессе экспериментов было установлено что даже УБРАВ команду и вроде-бы СОКРАТИВ процесс - можно вдруг обнаружить что стало медленней. Например jp с,nnnn хорошо ветвляет в 0 и 3 октантах, и очень отвратительно в 1 и 2, убрав его из ветвлений можно ускорить отрисовку по тем самым ret, а вот вертикально не даёт разрядная сетка и сегментация скрина...

бред какой-то, я тебе выделил лишние команды в конкретном коде, без "например"
и да, на плоскости - "квадранты", а не "октанты"

Процедура из спектрумэксперта работает шустрей, хоть и занимает объёмы больше, а средний такт на пиксель почти такой-же (58 против 60)

это потому что в спектрум-эксперте лишь набросок в качестве иллюстрации
для доведённой до ума, по тому же принципу развёрнутой процедуры - меньше 40 тактов
пример был в одном из тредов по ссылке выше

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

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

[shurik-ua]

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

[Shiny]

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

спасибо кэп! осталось достичь 50фпс

[NEO SPECTRUMAN]

спасибо кэп! осталось достичь 50фпс

без подавания 56МГц на клок процессора не обойтись

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

спасибо кэп! осталось достичь 50фпс

та запросто
все голишъ надо отрендерить 100 петабайт картинок со всеми положениями камеры в тридемаксе
запилить картридж метр на 2 на полотора (физические размеры)
и выводить на экран прямо с него
предварительно сконвертив все картинке в последовательность ld hl,1234 push hl...

[Destr]

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