"Pewien uczen zapytał mistrza: - Jak długo trzeba oczekiwac zmian? - Jesli chcesz ich OCZEKIWAC, to długo" :)

Parę osób w Głazach widziało już na Rapidusie u Pasia, jak to określił mazi, "patriotyczne demo": rotozoomer z motywem o widocznym charakterze państwowotwórczym.

Dodam, że pierwotnie ten a nie inny motyw został wybrany dlatego, że z kilkunastu różnych bitmap wyglądał najlepiej po redukcji do 2 kolorów. Ale szybko doszedłem do wniosku, że taki motyw jest równie dobry jak każdy inny, zwłaszcza że było akurat w okolicach 13 grudnia :)

Dzisiaj program postanowiłem doprowadzić do kultury tak, żeby się już nadawał do publicznej prezentacji. Oto on:

http://drac030.krap.pl/r3b.arc

Wymagania:

1) Atari

2) 65C816 (im szybciej taktowany, tym lepiej, powiedzmy, że 10 MHz i więcej jest zalecane)

3) 48k pamięci podstawowej + 64k "liniowej"

Opcjonalnie: VBXE

Program zawiera w sobie 256-kolorową bitmapę. Jeśli zostanie wykryte VBXE, włączany jest tryb low-res o rozdzielczości 128x96 i dalej wiadomo. Jeśli nie ma VBXE, program robi redukcję kolorów do 2 i prezentuje (dokładnie ten sam) efekt na ekranie 128x96 w dwóch kolorach (GR.6). Można wymusić pominięcie inicjowania VBXE przytrzymując klawisz Shift podczas startu r3.exe.

Dodatkowa featura polega na tym, że pod DOS XL, Real.DOS, SpartaDOS, SpartaDOS X programowi można w linii poleceń podać nazwę pliku BMP do rotowania (i zoomowania). Obrazek musi spełniać wymagania:

1) typ Windows bitmap (BMP)

2) rozmiar 256x256 pikseli

3) 8 bitów na piksel

4) brak kompresji

(jakby co: konwersje z np. IrfanView do 256x256x8bpp i zapisane jako BMP spełniają te warunki).

Powierzoną bitmapę program traktuje jak swoją, to znaczy, jeśli nie ma VBXE, dokonuje na niej brutalnej redukcji liczby kolorów do B/W. Jak wiadomo, nie zawsze to wychodzi, wiele zależy od obrazka. W każdym razie na bitmapie "domyślnej" algorytm działa dobrze, a wcale nie jest pod nią w żaden sposób rasowany. W archiwum jest przykładowy plik BMP, który też jako tako po tym wygląda (acz niewykluczone, że trzeba najpierw obejrzeć wersję full color, żeby widzieć, co to jest).

Dane techniczne:

1) rotowana bitmapa: 256x256 pikseli, 256 kolorów

2) okienko: 128x96, B/W lub 256 kolorów, zależnie od sprzętu

3) szybkość renderingu przy 20 MHz:

* b/w: ok. 2 ramek na klatkę

* 256 kolorów: ok. 2,5 ramek na klatkę

Zważywszy że w tym drugim wypadku pamięć obrazu jest 8x większa, a w obu jej szybkość wynosi 1,77 MHz, może nie jest to taki zły wynik.

Nie wątpię też, że da się to zrobić lepiej, zważywszy dema z ostatniego Forewera. Ja po prostu wygóglałem jakiś amigowski algorytm i zaaplikowałem go do 816.

EDIT: program działa też na Altirze, System->CPU Options->65C816 20 MHz (klik), System->Memory size->High Memory->4 MB (klik), System->Video->VBXE (klik)

EDIT 2: aktualizacja linku.

... czyli muszę rozpakować Atari po ostatnim party ;) ... ehhh :D

Altirra też tu daje radę, ale jakby co to dla leniwych filmik został już nagrany.
Draco, mam nadzieję, że nie masz nic przeciwko: http://youtu.be/Ef0_L0EnrG0

Na filmie jakoś bardzo widać, że program nie robi dwubuforowania :] Na monitorze to cokolwiek lepiej wygląda. Może to też zależy od obrazka. Osobiście polecałbym beau.bmp z drugiej paczki (acz to pewnie za ciemne).

EDIT: nie zgadzały mi się obliczenia z wynikami, więc pomierzyłem czasy drugi raz i dokładniej. Renderowanie 1 klatki:

a) bez VBXE: 1,68 ramki

b) z VBXE: 2,13 ramki

W tej chwili pałeczka nie jest po mojej stronie.

@Pasiu - podeślij mi tę bitmapę z YT

@Laoo - do postaci pojedynczego *.xex'a to można takie menu napisać nawet w TBXL, minusem jest tylko ewentualnie rozmiar, czyli kod + 10kB biblioteki zlinkowanej ;)-

@pasiu - uff ;)

@Pin - We flaszu jest kupę miejsca. Nada się dowolny program potrafiący wołać zewnętrzne procedury w asemblerze. Oczywiście idealnie byłoby aby to był kod 816 działający w jakimś wysokim banku korzystający w minimalnym stopniu z pamięci podstawowej, ale jeżeli pogodzimy się ze zniszczeniem zawartości pamięci Atari po uruchomieniu konfiguratora, to praktycznie nie ma żadnych ograniczeń.

@pin: u mnie działa :)

@laoo: ale z jakiego powodu "nie działało"? Może wrzuć to do repozytorium, a nuż da się coś łatwo poprawić? Bo robienie drugi raz tej samej roboty jest faktycznie trochę bez sensu, natomiast doprowadzenie do kultury czegoś istniejącego może się okazać dużo łatwiejsze.

@drac030: Fajny orzełek wyszedł - jak na złotówce :)
Ech jak będę miał Rapidusa, to wreszcie będzie można podziałać z DraOSem.

no to dogadajcie się moi Mili, bo czas (nie kut*as), a dobre rozszerzenie czeka ;)