Zasadniczo, w jaki sposób renderowane są bitmapy 2D?

Załóżmy, że mamy 64-bitowy adresowalny komputer i chcemy go zaprogramować, aby wyświetlał znak 5 x 7 zapisany jako bitmapa obrazu binarnego (takiego jak ten poniżej) na wyświetlaczu odwzorowanym w pamięci.

Ponieważ mamy 5 x 7 = 35 pikseli na znak, moglibyśmy zapisać znak przy użyciu 35 bitów w jednym słowie. Z najmniej znaczącym bitem rozpoczynającym się po lewej stronie słowa, a każdy piksel na obrazie jest reprezentowany przez n- ty bit, jak pokazano powyżej, liczba „3” powyżej byłaby przechowywana w pamięci jako: 01110100010000100110000011000101110, a następnie 29 nieużywane bity ustawione na 0.

Czy w ten sposób postacie były / są przechowywane na starych / nowoczesnych komputerach? A może zamiast tego używają jednego bajtu / słowa na piksel?

Jeśli są one przechowywane w ten sposób, to co zastosowałaby procedura w asemblerze / kodzie maszynowym (wykorzystując jedynie elementarne instrukcje, takie jak operacje bitowe, arytmetyczne i transport danych z architektury zestawu instrukcji komputera) użyte do konwersji tych danych w obraz na wyświetlacz wygląda? Czy byłoby to coś takiego:

1. Zachowaj współrzędne wyświetlania xiy dla bieżącego piksela, który ma zostać zaktualizowany, w pewnym rejestrze.
2. Przechowuj dwie wybrane wartości RGB (w tym przypadku 0,255,0 dla zieleni i 0,0,0 dla czerni) w dwóch innych osobnych rejestrach.
3. Niech dwa kolejne rejestry działają jak liczniki zainicjowane na 5 i 7, aby śledzić bieżący wiersz i kolumnę renderowanego obrazu.
4. Sprawdź, czy rejestr kolumny nie jest 0. Jeśli nie, sprawdź, czy LSB mapy bitowej jest ustawiony na 1, a następnie ORAZ odpowiedni rejestr wartości RGB z rejestrem współrzędnych xiy w zależności od wyniku, a następnie MOV ten wynik do rejestru wyjściowego wyświetlacza.
5. Zmniejsz rejestr licznika wierszy o 1, sprawdź, czy wynosi 0. Jeśli tak, ustaw go z powrotem na 5 i zwiększ współrzędną y o 1 i zmniejsz licznik kolumn o 1.
6. Przesuń rejestr trzymając bitmapę 1 bit w lewo.
7. JMP do instrukcji 4.

Czy istnieje prostszy lub bardziej wydajny sposób na zrobienie tego? Wydaje się, że nawet coś tak prostego jak renderowanie pojedynczego małego tekstu wymaga dość dużej liczby operacji i zająłoby około 200 cykli procesora.

Na koniec, czy są jakieś dobre książki lub zasoby na temat kodu na poziomie maszyny do wyświetlania obrazów od zera, ponieważ nie byłem w stanie ich znaleźć, ponieważ albo mówią o tym konkretnym temacie, albo kod jest napisany w języku wysokiego poziomu lub asembler używający makr, z których wszystkie „oszukują” i nie wyjaśniają, co się zasadniczo dzieje na najniższym poziomie.

Musisz rozróżnić tryby tekstowy i graficzny karty graficznej urządzenia.

W dawnych czasach obsługiwany był głównie tryb tekstowy. W tym trybie tablica zadbała o przechowywanie definicji bitmapowej znaków i wyświetlanie ich w bieżącej pozycji kursora. Wystarczyło podać kod ASCII znaku (jeden bajt na znak) w małym buforze tekstowym.

Obecnie dostępny jest bufor rastrowy o wysokiej rozdzielczości, który jest dostępny w pikselach i do którego zapisujesz informacje o kolorze w jakimś obsługiwanym formacie (w trybie „najwyższego”, 3 bajty (RGB) na piksel, dla megapikseli lub więcej).

Pierwotnie używane były proste (spakowane) binarne mapy bitowe o różnych rozmiarach i „ wstawiane ” do pamięci rastrowej poprzez żądanie do sterownika urządzenia, z możliwym tłumaczeniem formatu.

W dzisiejszych czasach znaki są definiowane głównie jako rysunki wektorowe , które są niezależnym od rozdzielczości opisem konturów i muszą zostać poddane złożonemu procesowi renderowania, który obejmuje wygładzanie krawędzi w celu uzyskania płynnych wyników.

Renderowane dane wyjściowe mogą być buforowane w celu szybkiego wyświetlenia, ponownie przez blitting.

Cały proces jest złożony, może być przyspieszany sprzętowo i jest obsługiwany przez system operacyjny (zarządzanie GUI) w przejrzysty sposób, wraz z innymi graficznymi operacjami rysowania pierwotnego.

Krótka odpowiedź brzmi TAK, nie można uniknąć wielu manipulacji bitami, jeśli format tego wymaga.

Rysowanie bitmapy oznacza po prostu skopiowanie piksela ze źródła do miejsca docelowego i musisz zrobić wszystko, co trzeba. (Cytując kapitana oczywistego)

Dłuższą odpowiedzią jest to, że jeśli napiszesz programowy rasterizer, możesz mieć jakiś algorytm i sztuczkę, aby zaoszczędzić czas procesora (wiedząc, której części NIE POTRZEBUJESZ (optymalizacja przezroczystości), mając taki sam format pikselowy źródła jako miejsce docelowe (bezpośrednio lub w formie pamięci podręcznej), optymalnie wykonaj memcopy itp. Zasadniczo rozważ pętlę rysowania swojego rasterizera i zobacz, jak możesz je zrestrukturyzować, aby zaoszczędzić czas procesora. (np .: możesz wygenerować w czasie wykonywania fragment kodu asemblera, aby wydrukować literę A lub mieć meta do informacji źródłowej mapy bitowej, aby powiedzieć, jak pominąć przezroczysty obszar itp.) Każdy przypadek użycia może mieć inne rozwiązanie w zależności od zestawu instrukcji procesora, formatu bufora, algorytm twojego prymitywnego renderowania (obracanie? rozciąganie bitmap? jaki rodzaj filtrowania? itd.), rejestr procesora i pamięć podręczna itp ...

Tak więc i tak, ZNACZNIE dużo cykli procesora do pisania pojedynczego piksela w dawnych czasach, gdy dziwne kodowanie i mała pamięć były normą. :-) Ale nie zabraniało 16/32-bitowym maszynom z procesorem 8 MHZ robienia takich rzeczy: https://www.youtube.com/watch?v=GWwPJU6pp30 (I wykorzystano również dużą część procesora dla muzyki)

W przypadku renderowania HW, HW przeprowadzi konwersję z formatu źródłowego do formatu docelowego i chociaż nie użyje wielu sztuczek dostępnych dla rasterizera SW, jego ogólna implementacja w HW najprawdopodobniej pobije większość implementacji SW.