"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.

Ostatnio edytowany przez drac030 (2014-09-22 00:33:20)

... 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

Ostatnio edytowany przez drac030 (2014-09-23 00:23:40)

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

Ostatnio edytowany przez pasiu (2014-09-24 06:34:04)

@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.

Ostatnio edytowany przez drac030 (2014-09-24 22:44:09)

@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 ;)