Brodaci siwi dziadkowie przynależący do kasty milenialsów często pamietają jeszcze jak komputery PC były na węgiel i miały procesory taktowane zawrotnymi szybkosciami kilku do kilkunastu megaherców. Często sklecenie na nich gierki która nie doprowadzała tych blaszanych klatek na podzespoły do zadyszki wymagało cudów ekwilibrystyki w zakresie optymalizacji. Jedną z najbardziej porąbanych moim prywatnym zdaniem technik było pisanie tzw. kompilatorów sprajtów/spritów które grafike bitmapową zamieniały w... kod maszynowy "rysujacy" grafikę od razu w pamięci karty graficznej. Wspierała tą technikę m.in. popularna kiedyś w Polsce, w tym na tym forum, biblioteka Allegro. Oczywiście najlepiej dla prędkości działania by kod rysujący nie wykorzystywał pętli. Przy czym często ograniczało to wymiary grafiki z powodu limitów pamieci. Kompilacja w latach 80tych była w zasadzie jedyną sensowną metodą uzyskania przezroczystości na PC. Bardziej egzotyczne mutacje tej techniki obejmowały dynamiczną modyfikację kodu rysowania takich elementów celem ściśniecia danych w skromnych ilościach pamięci operacyjnej - tak uzyskiwano np. skalowanie bez konieczności trzymania w pamieci wielu wariantów tej samej grafiki. Oszczędzało to pamięć, ale mogło wprowadzać dodatkowe opóźnienia związane z koniecznością odwoływania się co jakiś czas do pamięci operacyjnej by pobrać nową wersję kodu do cache procesora. O ile twój procesor w ogóle posiadał cache xD. Ładowanie dynamicznie z dysku często nie wchodziło w grę bo zmieniałoby to rozgrywkę w pokaz slajdów z powodu koszmarnie długiego czasu ładowania. A tutaj video ilustrujące w praniu jak bardzo przyśpieszała taka kompilacja rysowanie grafiki, acz tutaj wersja bez skalowania
We work through the process of creating a sprite engine on the IBM PC. The PC 5150 doesn't have any sprite hardware, so we have to resort to some sophisticat...
https://www.youtube.com/watch?v=q1S23G3S7IA
CloudPro@Spine: dopieściłeś projekt :)