NEO SPECTRUMAN
03.04.2017, 17:13
Аппаратный горизонтальный скролл в Радио 86РК
АХТУНХ
Текст ниже скорей всего памятка самому себе
Лучше и надежней использовать скролл с использованием перемещаемого "конца строки"
чем то что ниже
или как сделать горизонтальный скролл
на любом компьютере с изменяемым начальным адресом старта экрана с точностью до байта (хотя не обязательно)
и линейным строением экрана
я много говорил про аппаратный скролл у РК
который у него из коробки НО
Если вертикальный скролл очевидно как реализовать
то с горизонтальным нужно уже немножко подумать (мну думал минуты 2...)
(не имею малейшего понятия как его делал vinxru)
НИКАКОГО ГОТОВОГО КОДА В ПЕРВОМ ПОСТЕ НЕТ!
Суть алгоритма такова (см интуитивно понятный картинко ниже)
Может для кого то это и очевидно
но не для меня
да и готового софта со скроллом я не вижу...
Для наглядности возьмем размер экрана 3х2 знакоместа
Вся карта в виде столбцов 1,2,3,4,5,6,7... (на картинках не указаны!!!)
Комментарии написаны для каждой строки (номер строки на картинке не указан!!!)
http://zx-pk.ru/attachment.php?attachmentid=60463&d=1491227810
1. Исходное положение на экране столбцы 1,2,3
2. Сдвигаем видео память на +1 в результате чего на экране столбцы 2,3 в последнем столбце появляется фиг знает что
3. Дорисовываем последний столбец
по смещению -1 от текущего начала видео памяти
для того чтобы в будущем вернуть видео память в исходное положение (ну не можем же мы ее сдвигать бесконечно)
отрисовываем одно знакоместо из изображения, которое появится намного позже
которое будет находиться текущее_положение + количество_видео_памяти
в нашем случае 1 + 6
рисуем одно знакоместо из 7-го столбца 1-й строки
дальше по смещению + ширина_экрана (выделенное под это количество видео памяти, а не настройки вг75) от текущего положения рисуем знакоместо из 4-го столбца
прибавляя ширину_экрана переходим к следующей строке дорисовываем 4-й столбец
4. см пункт 2. (на экране столбцы 3,4,*)
5. см пункт 3. (только по смещение -1 рисуем знакоместо из 8-го столба 1-й строки)
6. см пункт 2. (на экране столбцы 4,5,*)
7. см пункт 3. (только по смещение -1 рисуем знакоместо из 9-го столба 1-й строки)
8. см пункт 2. (на экране столбцы 5,6,*)
9. см пункт 3. (только по смещение -1 рисуем знакоместо из 7-го столба 2-й строки)
10. см пункт 2. (на экране столбцы 6,7,*)
11. см пункт 3. (только по смещение -1 рисуем знакоместо из 8-го столба 2-й строки)
12. и теперь самое интересно
мы возвращаем начальный адрес видео памяти в исходное положение
а у нас там уже почти готово новое изображение и всего лишь одно последнее знакоместо неправильное
(на экране столбцы 7,8 и большая часть 9)
13. дорисовываем последнее знакоместо
и можно переходить к пункту 2
Что в конечном итоге это нам дает
нам не нужно перерисовывать все 3К чтобы сдвинуть все изображение
достаточно перерисовать один столбец + еще 1 байт итого каких то 40 байт
но за скорость нужно платить
требуется дополнительное место, куда будет перемещаться окно
в итоге под видео память придется отдать еще столько же - 1
этот вариант для быстрого фреймового обновления
с не большим количеством спрайтов на экране
тк тут сразу после перерисовки экрана
начинается гонка с лучом (а в нашем случае с DMA)
нужно немедленно обновлять сдвигать спрайты (при том даже те которые статичные на экране!!!)
пока их необновленное положение не успело попасть в буфер вг75
иначе будут мигать спрайты (в данном случае дрыгаться и рваться)
из оптимизаций
если спрайт движется со скоростью экрана в ту же сторону
то его можно не перерисовывать
для не фреймовых скроллов
где спрайтов много и они большие
уже придется выделить памяти в 4 раза больше чем экранная область!!!!
подход тот же
но отрисовывать придется теперь по 2 столбца + 2 байта
и менять каждый раз буфер
так же теперь ширина экрана должна быть кратная 2-м
вот начало работы алгоритма
http://zx-pk.ru/attachment.php?attachmentid=60464&d=1491227825 http://zx-pk.ru/attachment.php?attachmentid=60466&d=1491233772
1. Исходное положение
В отличие от предыдущего тут используется 2-й экранный буфер
который при старте уже должен быть заполнен изображением проскролленым на одно знакоместо!!!
...хотя проще будет нарисовать смещение тем же кодом и держать при старте просто 2 одинаковых экрана (правая картинка)...
2. выбираем 2-й экранный буфер
3. в первом буфере дорисовываем все изменения (включая спрайты и прочую белиберду)
4. выбираем 1-й экранный буфер
итд
в итоге мы получаем такую же быструю двигалку экрана
из минусов
в 4 раза больше видеопамяти!!!!
спрайты теперь нужно рисовать в 2 разных буфера
и хранить информацию для восстановления фона или прочие подобные вещи
в количестве 2 раза большем!!!!
изображение теперь идет с задержкой
но нам на это пофиг ибо везде так и мы это не замечаем даже...
так же можно реализовать скролл в обе стороны
но для этого нужно за раннее заполнить вторую часть видео памяти тем, что будет выведено на экран при движении назад
с таким же успехом усложнив код можно делать скролл с разным шагом
...в принципе можно запилить скролл во всех 4-х направлениях...
но памяти это займет... (размер видео памяти * 2 * 2 * количество буферов)
...разве что сделать маленькое окошко слева сверху как у zx81 )))))
при всем этом можно пользоваться средствами экономии видео памяти (конец строки стоп ПДП)
и скорей всего даже нужно (правда тогда придется больше перерисовывать изображение)
с атрибутами же придется сложнее
самый оптимальный вариант режим видимых атрибутов
тогда больших проблем не возникнет
или вариант атрибут на каждый байт видео памяти (при режиме невидимых атрибутов)
каждый второй байт заполнить "штриховкой"
а изменять только сами атрибуты при перерисовке (каждый второй байт)
в итоге получим большие цветные чанки со скроллом...
В атаче в архиве непожатиые изображения
на которые и рекомендуется смотреть
АХТУНХ
Текст ниже скорей всего памятка самому себе
Лучше и надежней использовать скролл с использованием перемещаемого "конца строки"
чем то что ниже
или как сделать горизонтальный скролл
на любом компьютере с изменяемым начальным адресом старта экрана с точностью до байта (хотя не обязательно)
и линейным строением экрана
я много говорил про аппаратный скролл у РК
который у него из коробки НО
Если вертикальный скролл очевидно как реализовать
то с горизонтальным нужно уже немножко подумать (мну думал минуты 2...)
(не имею малейшего понятия как его делал vinxru)
НИКАКОГО ГОТОВОГО КОДА В ПЕРВОМ ПОСТЕ НЕТ!
Суть алгоритма такова (см интуитивно понятный картинко ниже)
Может для кого то это и очевидно
но не для меня
да и готового софта со скроллом я не вижу...
Для наглядности возьмем размер экрана 3х2 знакоместа
Вся карта в виде столбцов 1,2,3,4,5,6,7... (на картинках не указаны!!!)
Комментарии написаны для каждой строки (номер строки на картинке не указан!!!)
http://zx-pk.ru/attachment.php?attachmentid=60463&d=1491227810
1. Исходное положение на экране столбцы 1,2,3
2. Сдвигаем видео память на +1 в результате чего на экране столбцы 2,3 в последнем столбце появляется фиг знает что
3. Дорисовываем последний столбец
по смещению -1 от текущего начала видео памяти
для того чтобы в будущем вернуть видео память в исходное положение (ну не можем же мы ее сдвигать бесконечно)
отрисовываем одно знакоместо из изображения, которое появится намного позже
которое будет находиться текущее_положение + количество_видео_памяти
в нашем случае 1 + 6
рисуем одно знакоместо из 7-го столбца 1-й строки
дальше по смещению + ширина_экрана (выделенное под это количество видео памяти, а не настройки вг75) от текущего положения рисуем знакоместо из 4-го столбца
прибавляя ширину_экрана переходим к следующей строке дорисовываем 4-й столбец
4. см пункт 2. (на экране столбцы 3,4,*)
5. см пункт 3. (только по смещение -1 рисуем знакоместо из 8-го столба 1-й строки)
6. см пункт 2. (на экране столбцы 4,5,*)
7. см пункт 3. (только по смещение -1 рисуем знакоместо из 9-го столба 1-й строки)
8. см пункт 2. (на экране столбцы 5,6,*)
9. см пункт 3. (только по смещение -1 рисуем знакоместо из 7-го столба 2-й строки)
10. см пункт 2. (на экране столбцы 6,7,*)
11. см пункт 3. (только по смещение -1 рисуем знакоместо из 8-го столба 2-й строки)
12. и теперь самое интересно
мы возвращаем начальный адрес видео памяти в исходное положение
а у нас там уже почти готово новое изображение и всего лишь одно последнее знакоместо неправильное
(на экране столбцы 7,8 и большая часть 9)
13. дорисовываем последнее знакоместо
и можно переходить к пункту 2
Что в конечном итоге это нам дает
нам не нужно перерисовывать все 3К чтобы сдвинуть все изображение
достаточно перерисовать один столбец + еще 1 байт итого каких то 40 байт
но за скорость нужно платить
требуется дополнительное место, куда будет перемещаться окно
в итоге под видео память придется отдать еще столько же - 1
этот вариант для быстрого фреймового обновления
с не большим количеством спрайтов на экране
тк тут сразу после перерисовки экрана
начинается гонка с лучом (а в нашем случае с DMA)
нужно немедленно обновлять сдвигать спрайты (при том даже те которые статичные на экране!!!)
пока их необновленное положение не успело попасть в буфер вг75
иначе будут мигать спрайты (в данном случае дрыгаться и рваться)
из оптимизаций
если спрайт движется со скоростью экрана в ту же сторону
то его можно не перерисовывать
для не фреймовых скроллов
где спрайтов много и они большие
уже придется выделить памяти в 4 раза больше чем экранная область!!!!
подход тот же
но отрисовывать придется теперь по 2 столбца + 2 байта
и менять каждый раз буфер
так же теперь ширина экрана должна быть кратная 2-м
вот начало работы алгоритма
http://zx-pk.ru/attachment.php?attachmentid=60464&d=1491227825 http://zx-pk.ru/attachment.php?attachmentid=60466&d=1491233772
1. Исходное положение
В отличие от предыдущего тут используется 2-й экранный буфер
который при старте уже должен быть заполнен изображением проскролленым на одно знакоместо!!!
...хотя проще будет нарисовать смещение тем же кодом и держать при старте просто 2 одинаковых экрана (правая картинка)...
2. выбираем 2-й экранный буфер
3. в первом буфере дорисовываем все изменения (включая спрайты и прочую белиберду)
4. выбираем 1-й экранный буфер
итд
в итоге мы получаем такую же быструю двигалку экрана
из минусов
в 4 раза больше видеопамяти!!!!
спрайты теперь нужно рисовать в 2 разных буфера
и хранить информацию для восстановления фона или прочие подобные вещи
в количестве 2 раза большем!!!!
изображение теперь идет с задержкой
но нам на это пофиг ибо везде так и мы это не замечаем даже...
так же можно реализовать скролл в обе стороны
но для этого нужно за раннее заполнить вторую часть видео памяти тем, что будет выведено на экран при движении назад
с таким же успехом усложнив код можно делать скролл с разным шагом
...в принципе можно запилить скролл во всех 4-х направлениях...
но памяти это займет... (размер видео памяти * 2 * 2 * количество буферов)
...разве что сделать маленькое окошко слева сверху как у zx81 )))))
при всем этом можно пользоваться средствами экономии видео памяти (конец строки стоп ПДП)
и скорей всего даже нужно (правда тогда придется больше перерисовывать изображение)
с атрибутами же придется сложнее
самый оптимальный вариант режим видимых атрибутов
тогда больших проблем не возникнет
или вариант атрибут на каждый байт видео памяти (при режиме невидимых атрибутов)
каждый второй байт заполнить "штриховкой"
а изменять только сами атрибуты при перерисовке (каждый второй байт)
в итоге получим большие цветные чанки со скроллом...
В атаче в архиве непожатиые изображения
на которые и рекомендуется смотреть