ТЕМА:

slonok пишет: ...пример визуализации как раз текстового режима
...как я понял речь идет о псевдографике и аски таблице на плис серии cyclone

Да. Вопрос в том, чтобы расширить возможности текстового режима. Что пришло в голову:
1) использовать несколько текстовых слоев, с возможностью произвольного(с шагом в 1 пиксель) смещения относительно друг друга.
2) каждый текстовый слой состоит из достаточного числа маленьких прямоугольных областей, также с возможностью произвольного(с шагом в 1 пиксель) смещения относительно друг друга, при этом не допускается наложение знакомест с ненулевым кодом. Это позволит плавно перемещать изображения в разных областях экрана. Например, текст в неперекрывающихся окнах (для перекрывающихся окон/спрайтов использовать разные слои).

Leka пишет:

slonok пишет: ...пример визуализации как раз текстового режима
...как я понял речь идет о псевдографике и аски таблице на плис серии cyclone

Да. Вопрос в том, чтобы расширить возможности текстового режима. Что пришло в голову:
1) использовать несколько текстовых слоев, с возможностью произвольного(с шагом в 1 пиксель) смещения относительно друг друга.
2) каждый текстовый слой состоит из достаточного числа маленьких прямоугольных областей, также с возможностью произвольного(с шагом в 1 пиксель) смещения относительно друг друга, при этом не допускается наложение знакомест с ненулевым кодом. Это позволит плавно перемещать изображения в разных областях экрана. Например, текст в неперекрывающихся окнах (для перекрывающихся окон/спрайтов использовать разные слои).

Смещающиеся текстовые слои, подключаемые к постоянным или изменяемым знакогенераторам, в том числе допускающим цветные символы - это же Денди, ну т.е. NES от Nintendo. Если сделать пункт 2 и убрать в нем запрет на перекрытие, то зачем пункт 1? Ну или наоборот - в первом пункте вместо "несколько текстовых слоев" сказать "достаточно текстовых слоев" и добавить настройку их размера, чтобы их можно было делать спрайтами.

P.S.
осталось добавить детектор столкновений :)

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

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

Внешнюю память из принципиальных соображений не хочу использовать, а внутренней памяти мало. У Марсохода2, например, ~~46КБайт. А экран желательно от 1280*720. Так что изобретаю "минималистичную графику"...

Ynicky пишет: векторный сопроцессор

Какой минимальный буфер ему нужен?
Может ли он построчно строить изображения?
Или, например, по 4-м строкам?
Например, ~1Kпикселей*4строки*8бит.цвет=~4КБайт буфер, 4К пиксельных тактов на построение. Пока один буфер заполняется, другой выводится, всего ~8КБайт буферной видеопамяти. Получится?

Векторному сопроцессору понадобится векторный дисплей - habrahabr.ru/post/161767/

Какой минимальный буфер ему нужен?

Разрядность памяти зависит от разрядности векторного сопроцессора.
А глубина буфера может быть любой, в зависимости от задачи, но не менее
одной ячейки на разрядность векторного сопроцессора.
Например, у меня в MPEG кодеке, размер буфера - макроблок 16х16 эл.из.
Разрядность - 128 бит (обработка одновременно 8 бит х16 / 16 бит х8 /
32 бита х4 / 64 бита х2 / 128 бит х1). И того, при 24 битах на эл.из. - 48 ячеек.

Николай.

Leka пишет: Внешнюю память из принципиальных соображений не хочу использовать, а внутренней памяти мало. У Марсохода2, например, ~~46КБайт. А экран желательно от 1280*720. Так что изобретаю "минималистичную графику"...

А какой размер тайла или знакоместа Вы хотите? Легко подсчитать, что 1280*720 при знакоместе 8*8 и 256 одноцветных символах в знакогенераторе это
(1280 / 8 ) * (720 / 8 ) + 8*256 = 160*90 + 2048 = 16448. Плохая, некруглая цифра - чуть больше, чем 16384. Но если отказаться от 256 символов, например, то становится лучше.
Но Вы видели размер таких букв при 160 символах в строке? Это же неудобно. В упомянутом здесь терминале шрифт был не квадратный, но непрямоугольные знакогенераторы неудобнее для псевдографики и тайловой графики.
Какой размер знакоместа считаете минимально пригодной для "красивого" шрифта?

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

Но надо понимать, что если весь экран плотно занят уникальной текстовой информацией, то никакой волшебной экономии не придумать. Слои хороши тоже когда в изображении есть области. Тайловая графика хороша для игр. Для бродилок и платформеров. Нарисовал тайлы для воды, для суши, для леса, береговой линии, гор, домиков - вот тебе целая волшебная страна :)

Chaosorg пишет: А какой размер тайла или знакоместа Вы хотите?

Ширина 8 пикселей, высота любая, одинаковая в окне, задается в атрибутах окна. У меня так пока вырисовывается: экран 2048*1024, 1024 слоя плавающих окон(решеток) произвольного размера.

Надо учитывать архитектуру блочной памяти в ПЛИС(М9К). Для 2х-портовой памяти разрядность адреса не м/б меньше 8 бит (режим 256*36). Поэтому видеобуфер на одну строку пикселей (не символов, тк плавающие решетки) будет не меньше ширины 256 символов. Получаем: 256символов/строка*8пикселей/символ=2048 пикселей/строка. Если экран меньшего размера, часть памяти будет пустовать. По-другому не получается, поэтому видеобуфер минимальный - только на одну строку пикселей.