По суті, як виводяться двовимірні растрові карти?

Припустимо, у нас є 64-розрядний комп'ютер, адресований словом, і ми хочемо запрограмувати його для виведення символу 5х7, який зберігається у вигляді бітового зображення бінарного зображення (такого, як показано нижче) на відображенні на карті пам'яті.

Оскільки у нас 5 х 7 = 35 пікселів на символ, ми можемо зберігати символ, використовуючи 35 біт в одному слові. З найменш значущим бітом, що починається з лівого боку слова, і кожен піксель у зображенні представлений n- м бітом, як показано вище, число "3" вище зберігатиметься в пам'яті як: 01110100010000100110000011000101110, а потім 29 невикористаних біти встановлені на 0.

Це, як персонажі / зберігаються у старих / сучасних комп'ютерах? Або вони замість цього використовують один байт / слово на піксель?

Якщо вони зберігаються таким чином, який би порядок збирання / машинного коду (використовуючи не що інше, як елементарні вказівки, такі як побитові, арифметичні та операції з транспортування даних з архітектури набору комп'ютерів), використовуваний для перетворення цих даних у зображення як виглядає дисплей? Це було б щось на зразок:

1. Збережіть координату дисплея x і y для поточного пікселя, який потрібно оновити, у певному регістрі.
2. Збережіть два обраних значення RGB (у даному випадку 0,255,0 для зеленого та 0,0,0 для чорного) у двох інших окремих регістрах.
3. Запропонуйте два наступні регістри як лічильники, ініціалізовані до 5 та 7, щоб відслідковувати поточний рядок та стовпець зображення, що відображається.
4. Перевірте, чи регістр стовпців не дорівнює 0. Якщо це не так, перевірте, чи значення LSB растрової карти встановлено на 1, то І реєструйте відповідне значення RGB з регістром координат x та y залежно від результату, тоді MOV цей результат до реєстру виводу дисплея.
5. Зменшіть реєстр лічильників рядків на 1, перевіріть, чи він дорівнює 0. Якщо він є, то встановіть його назад на 5 і збільште координату y на 1, а зменшіть лічильник стовпців на 1.
6. Зсуньте регістр, що містить растрову карту 1 біт, ліворуч.
7. JMP до інструкції 4.

Чи є простіший чи ефективніший спосіб зробити це? Здається, що навіть щось таке просте, як надання єдиного невеликого текстового символу, займає досить велику кількість операцій і займає близько 200 циклів процесора.

Нарешті, чи є якісь хороші книги чи ресурси на машинному рівні для відображення зображень з нуля, тому що я не зміг знайти жодного, оскільки вони або замальовують цю конкретну тему, або код написаний мовою високого рівня або Асемблер, що використовує макроси, всі вони "обманюють" і не пояснюють, що принципово відбувається на найнижчому рівні.

Ви повинні розрізняти текстовий та графічний режими роботи графічної дошки вашої машини.

За старих часів переважно підтримувався текстовий режим. У цьому режимі плата подбала про збереження визначення растрових зображень символів та відображення їх у поточному положенні курсору. Все, що вам потрібно було зробити, - це надати ASCII код символу (один байт на символ) у невеликому текстовому буфері.

На сьогоднішній день надається растровий буфер високої роздільної здатності, який доступний у пікселях і до якого ви пишете кольорову інформацію в деякому підтримуваному форматі (у режимі "найвищий", 3 байти (RGB) на піксель, мегапіксель або більше).

Спочатку були використані прості (упаковані) бінарні растрові зображення різного розміру та " прошиті " до растрової пам'яті через запит до драйвера пристрою з можливим перекладом формату.

В даний час символи в основному визначаються як векторні малюнки , які є незалежним від роздільної здатності описом контурів, і їм потрібно пройти складний процес візуалізації, який включає антиаліазію для отримання рівних результатів.

Відображений вихід може бути кешований для швидкого відображення, знову ж таки, блимаючи.

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

Коротка відповідь "ТАК", ви не можете уникнути маніпуляцій, якщо ваш формат цього потребує.

Малювання растрової карти в основному означає копіювання пікселя з джерела до пункту призначення, і ви повинні зробити все, що потрібно для цього. (Цитуючи очевидного капітана)

Більш довга відповідь полягає в тому, що якщо ви пишете програмний растризатор, ви можете створити алгоритм і хитрість, щоб заощадити ваш процесорний час (знаючи, яку частину НЕ ТРЕБУЄТЬСЯ ДРУГАТИ (оптимізація прозорості), маючи той самий формат пікселів джерела як місце призначення (безпосередньо або у формі кешу), оптимально виконайте мемокопію тощо. В основному розгляньте цикл малювання вашого растерізатора і подивіться, як ви можете їх реструктурувати, щоб заощадити час процесора. (наприклад: ви могли б генерувати під час виконання a фрагмент коду асемблера саме для того, щоб надрукувати букву A або мати мета до вихідної інформації про растрове зображення, щоб повідомити про те, як пропустити прозору область тощо. У кожному випадку використання може бути різне рішення на основі набору інструкцій CPU, формату буфера, алгоритм вашої візуалізації примітивним (обертовий? розтягування растрових зображень? що таке фільтрація? тощо ...), реєстрація процесора та кеш тощо.

Так що так у будь-якому випадку, ВИНАГО багато циклу процесора, щоб записати один піксель за старих часів, коли дивна кодування та мала пам'ять були нормою. :-) Але це не заборонило 16/32-бітним машинам із 8 МГц процесором робити такі речі: https://www.youtube.com/watch?v=GWwPJU6pp30 (І також використовувався великий шматок процесора для музики)

У випадку візуалізації HW HW здійснить перетворення з вихідного формату в формат призначення, і хоча він не буде використовувати багато прийомів, доступних для SW-растерізатора, його загальна реалізація в HW, швидше за все, обіграє більшість реалізації SW.