Jak sprawili, że ekran poruszał się w Dangerous Dave?

Jako dziecko tworzyłem gry w języku BASIC i byłem ciekawy, jak grafika została wykonana w wersji Dangerous Dave z 1988 roku wykonanej w C ++; tym bardziej, że w tamtych czasach nie mieli żadnych wartościowych pakietów graficznych. Pamiętasz, jak kiedy Dave dotarł do krawędzi ekranu, cała grafika ekranowa poruszała się w lewo, wykonując gwałtowny ruch? Pamiętam, że czytałem, że Romero użył do tego specjalnej techniki. Chciałem stworzyć coś takiego jak Dave i zastanawiałem się

1. jakiego pakietu graficznego / metody użyli dla Dave'a?
2. i jak sprawić, by cała grafika ekranu poruszała się tak jak oni?

Moja wersja Dangerous Dave z 1988 roku była wersją Apple II. Przewijanie wykonano poprzez przesunięcie wszystkich bajtów ekranu, a następnie narysowanie nowego kafelka na krawędzi ekranu - powtórz 20 razy, aby przejść do pełnego ekranu. Wersja Apple II została napisana w języku asemblera 6502.

Na PC w wersji 1990 napisałem kod graficzny w asemblerze 80x86 dla wszystkich trybów wideo w tym czasie: CGA, EGA, VGA. Dangerous Dave PC to jedyna znana mi gra, która ma wszystkie 3 tryby wideo i można ją w dowolnym momencie przełączać (F2), nawet w środku skoku!

Aby szybko przewinąć ekran, wszystko było w języku asemblera i użyłem podobnej techniki, jak w wersji Apple II - szybko przenieś bajty w pamięci wideo i narysuj kafelek po prawej stronie. W EGA było to trudniejsze, ponieważ szybkie zrobienie czegokolwiek w trybie EGA wymagało użycia trybu zatrzasku do przenoszenia pamięci. Pamiętam, jak uczyłem Todda Replogle, jak to zrobić, aby Duke Nukem 1 był zabawną grą (powolny Duke Nukem nie byłby fajny).

Kod gry Dangerous Dave PC został napisany w C, w Borland C 3.0 IDE. Większość debugowania została wykonana w Turbo Debugger na 12-calowym bursztynowym monitorze podłączonym do karty Hercules.

Ach, pamiętam te techniki z moich czasów DOS. Przenoszenie pamięci RAM wideo i blitting w celu wykonania przewijania spowodowałoby gwałtowne przewijanie. EGA wprowadziła pionowe i poziome rejestry panoramowania pikseli, które mogą być użyte do ustawienia początku ekranu (gdzie w pamięci wideo karta wideo zaczęła wyświetlać dane). Ponieważ kopiowanie pamięci nie trwa, jest to prawie natychmiastowe i może być używane do bardzo płynnego i szybkiego przewijania pikseli po pikselach w EGA i VGA, jeśli masz bezpośredni dostęp do rejestrów sprzętowych. Większość scrollerów w systemie DOS użyłoby tego, a ta część kodu zostałaby prawdopodobnie napisana w języku asemblera, aby uzyskać bezpośredni dostęp do rejestrów sprzętowych. Te metody nie są już jednak poprawne. Aby teraz osiągnąć podobny efekt, Myślę, że na nowoczesnym sprzęcie graficznym można to zrobić wystarczająco szybko, przerysowując cały ekran w każdej klatce. Inną metodą, o której mogę myśleć, jest użycie OpenGL lub DirectX i renderowanie tekstury do kwadratu dwa razy większej niż szerokość ekranu i przesuwanie tego. Jakoś to nie wydaje się tak zabawne jak manipulowanie rejestrami sprzętowymi :)

Edycja: Oto link do artykułu dr. Dobbsa, który omawia przewijanie w bok. Może to być metoda zastosowana do tego efektu.

http://www.drdobbs.com/184408045

Trudno dokładnie ocenić, jak to się stało, ale należy wziąć pod uwagę, że ta gra została napisana dla bardzo specyficznej specyfikacji sprzętowej - DOS z kartą graficzną EGA (640 x 480 pikseli). Kod prawdopodobnie wykonuje dość niskie manipulacje pamięcią wideo, aby przewijanie przebiegało płynnie.

Oto strona internetowa, która mówi o programowaniu grafiki DOS, która może dać ci wyobrażenie o tym, jak by to było ...

http://www.phatcode.net/res/224/files/html/index.html

Metagun (gra opracowana przez Markusa, znanego również jako Facet z MineCraft) ma takie same wyczucie przewijania, jakiego szukasz.

Gra jest Open-Source i napisana w Javie.

• Gra: http://www.mojang.com/compo/metagun/
• Źródło: http://www.mojang.com/compo/metagun/metagun-source.zip

Mam nadzieję, że nauczysz się patrząc na kod.

Mogę wymyślić dwa sposoby, aby to zrobić:

1. Brute force: po prostu narysuj scenę
2. Rejestry trybu X i panoramowania. Narysuj bit, który chcesz przewinąć, i dostosuj rejestry panoramowania, aby przewinąć scenę. Trzeba będzie przerysować górny obszar wyświetlania każdej klatki, ale jest to mniej pracy niż rysowanie głównego obszaru odtwarzania. Nie trzeba przerysowywać dolnego obszaru, ponieważ w sprzęcie znajdował się rejestr, który powodowałby, że przetworniki DAC odczytują z adresu 0 w danej linii skanowania (więc dolny obszar znajdowałby się pod adresem 0 w ramce wideo i na górze zacznie się po dolnym obszarze) ^* .

Prawdopodobnie wybrałbym 1), ponieważ graficznie niewiele się dzieje, może być trochę wygenerowanego przez siebie kodu do łączenia i przycinania obrazów na krawędziach. Jedną z możliwych technik, nad którymi wówczas pracował mój kolega, były samokreślące się duszki, to znaczy dane duszka nie były danymi, tylko kodem. Oznaczało to, że nie było sprawdzania przezroczystości, a odczyt danych blit był faktycznie wolny (to było na 386, gdzie każda instrukcja została odczytana, a następnie zdekodowana, więc zamiast czytać kod-> czytać dane-> zapisywać dane, po prostu czytał kod- > zapis danych). Działa niesamowicie dobrze - mamy wiele ogromnych duszków na wielu warstwach paralaksy działających z prędkością 25 klatek na sekundę +.

Ale mówimy tutaj o Romero i prawdopodobnie jest trochę przesady w sprawie technik.

• Zrobiłem to właściwie w mojej pierwszej dużej grze DOS, aw niektórych urządzeniach występuje błąd, w wyniku którego resetowanie adresu nastąpiło zbyt wcześnie, aby uzyskać piksel o połowie wysokości między dwiema sekcjami.