22.09.2019 09:18
[#1]
Gry wektorowe - silnik sposób działania
Na Amigę powstało wiele gier wektorowych. Zastanawia mnie czy te silniki działały budując sceny z trójkątów (nie licząc linii, punktów) czy może były jakieś inne metody budowy oraz rysowania świata i obiektów.
Czy do wypełniania wielokątów był wykorzystywany blitter ? Mam wrażenie że nie bo często te same gry działały szybciej na ST gdzie jest szybszy procesor. Czy powodem braku prędkości była słaba optymalizacja ?
Przykładowe gry:
Ostatnia aktualizacja: 22.09.2019 09:26:08 przez Sventevith
Czy do wypełniania wielokątów był wykorzystywany blitter ? Mam wrażenie że nie bo często te same gry działały szybciej na ST gdzie jest szybszy procesor. Czy powodem braku prędkości była słaba optymalizacja ?
Przykładowe gry:
Ostatnia aktualizacja: 22.09.2019 09:26:08 przez Sventevith
23.09.2019 13:05
[#7]
Re: Gry wektorowe - silnik sposób działania
@_arti, post #6
Nazywa się to Turbo Mode
Po pierwsze wersja WHDLoad ma tą łatkę, więc wystarczy zainstalować Stunt Car Racer pod WHDLoad i uruchomić z parametrem CUSTOM2=1 lub wcisnąć F2 w czasie gry (włącza/wyłącza Turbo Mode).
Po drugie istnieje wersja dyskowa nazwana Stunt Car Racer: Turbo. Można ją znaleźć choćby na Grandisie.
Po pierwsze wersja WHDLoad ma tą łatkę, więc wystarczy zainstalować Stunt Car Racer pod WHDLoad i uruchomić z parametrem CUSTOM2=1 lub wcisnąć F2 w czasie gry (włącza/wyłącza Turbo Mode).
Po drugie istnieje wersja dyskowa nazwana Stunt Car Racer: Turbo. Można ją znaleźć choćby na Grandisie.
23.09.2019 16:45
[#9]
Re: Gry wektorowe - silnik sposób działania
@Sventevith, post #1
Atari ST wyswietlalo 16 kolorow Amiga dwa razy wiecej ...
Atari mialo mniejsza rowniez rozdzielczosc 320x200 a nie 320x256
Stad wrazenie we ST jest szybsze w Grach 3D opartych na wektorach
Co do dzialania zobacz sobie
Desert Wolf polski symulator lub F29 retaliator
Jedna gra virtual carting budowala grafike wektorowa nie zamiast C2P tylko wlasnie bitplanowa na blliterze byla bardzo szybka
Ostatnia aktualizacja: 23.09.2019 16:49:13 przez HOŁDYS
Atari mialo mniejsza rowniez rozdzielczosc 320x200 a nie 320x256
Stad wrazenie we ST jest szybsze w Grach 3D opartych na wektorach
Co do dzialania zobacz sobie
Desert Wolf polski symulator lub F29 retaliator
Jedna gra virtual carting budowala grafike wektorowa nie zamiast C2P tylko wlasnie bitplanowa na blliterze byla bardzo szybka
Ostatnia aktualizacja: 23.09.2019 16:49:13 przez HOŁDYS
Tam nic się nie dzieje! Przez 90% czasu latasz nad płaszczyzną z ewentualnymi "drogami". 23.09.2019 21:57
[#13]
Re: Gry wektorowe - silnik sposób działania
@Sventevith, post #1
Mnie też zawsze irytowała prędkość gier z grafiką wektorową na Amigę. Często były to kiepskie konwersje z innych platform.
Bardzo lubiłem grać w symulatory samochodowe i szkoda mi było, że takie "Stunts" czy "Hard Drivin" dosyć średnio działały na Amidze. To jednak były w tamtych czasach najbardziej symulacyjne samochodówki (Lotus czy nawet Test Drive 1, 2 były fajne ale symulatorami bym ich nie nazwał). Na 030/50 było mizernie z prędkością ale gdy już dorobiłem się trochę szybszych dopałek (najpierw 040/40, potem 060/50) to procesor nadrobił niedostatki tych kiepskich konwersji i dało się całkiem fajnie grać. Jednak pamiętam, że w sali informatyki na polibudzie "Stunts" działał bardzo płynnie na 386/33, czyli u nas też powinien na 030/50.
"Desert Wolf" był płynny nawet na słabych Amigach ale w tej grze praktycznie nic nie było.
Tam nie miało co mulić. AMOS 3D dałby radę.
Mam wrażenie, że gry pisane specjalnie dla Amigi działały lepiej. Weźmy takiego "Gunship 2000". Ładnie śmigał nawet na słabszych maszynach (020 czy 030 z fastem). Albo "Koala" - też chodziła super jeżeli tylko miała trochę Fast RAM. A skubana miała fajny panel 3D.
Bardzo lubiłem grać w symulatory samochodowe i szkoda mi było, że takie "Stunts" czy "Hard Drivin" dosyć średnio działały na Amidze. To jednak były w tamtych czasach najbardziej symulacyjne samochodówki (Lotus czy nawet Test Drive 1, 2 były fajne ale symulatorami bym ich nie nazwał). Na 030/50 było mizernie z prędkością ale gdy już dorobiłem się trochę szybszych dopałek (najpierw 040/40, potem 060/50) to procesor nadrobił niedostatki tych kiepskich konwersji i dało się całkiem fajnie grać. Jednak pamiętam, że w sali informatyki na polibudzie "Stunts" działał bardzo płynnie na 386/33, czyli u nas też powinien na 030/50.
"Desert Wolf" był płynny nawet na słabych Amigach ale w tej grze praktycznie nic nie było.
Tam nie miało co mulić. AMOS 3D dałby radę. Mam wrażenie, że gry pisane specjalnie dla Amigi działały lepiej. Weźmy takiego "Gunship 2000". Ładnie śmigał nawet na słabszych maszynach (020 czy 030 z fastem). Albo "Koala" - też chodziła super jeżeli tylko miała trochę Fast RAM. A skubana miała fajny panel 3D.
23.09.2019 23:28
[#15]
Re: Gry wektorowe - silnik sposób działania
@Sventevith, post #14
Czy widziałeś program Fantavision? Tam jest ładnie pokazane jak to działa. Ten program pozwala na tworzenie wektorowych animacji.
Amigowy Blitter potrafi rysować linie proste oraz wypełniać obszary, więc dobrze nadaje się do wektorów. Wektory w 3D to kwestia odpowiedniego rzutu współrzędnych (x,y,z) na płaszczyznę, więc też się da.
Ostatnia aktualizacja: 23.09.2019 23:29:27 przez Hexmage960
Amigowy Blitter potrafi rysować linie proste oraz wypełniać obszary, więc dobrze nadaje się do wektorów. Wektory w 3D to kwestia odpowiedniego rzutu współrzędnych (x,y,z) na płaszczyznę, więc też się da.
Ostatnia aktualizacja: 23.09.2019 23:29:27 przez Hexmage960
24.09.2019 06:48
[#16]
Re: Gry wektorowe - silnik sposób działania
@Sventevith, post #1
To może odpowiem jak to działało od strony programistycznej (na tyle ile pamiętam).
Ogólnie grafikę dzieliło się na 2 zasadnicze rodzaje "wypukłą" i "niewypukłą". W tej drugiej jedna ściana obiektu mogła CZĘŚCIOWO przesłaniać drugą ścianę obiektu.
W pierwszym przypadku rysowało się zarysy ścian (mogły to być supełnie dowolne wielokąty, byle na siebie nie zachodziły) i potem blitter je wypełniał. A wypełniał je linia po linii poziomo przy użyciu trybu (jeśli się nie mylę) XOR filling. Tak więc wystarczyło narysować krawędzie obiektu (też w specjalnym trybie = XOR + jeden piksel kreski na linię poziomą), a potem zlecić blitterowi wypełnienie - raz na jedną klatkę animacji.
Jednak grafika "niewypukła" - z częściowym przesłanianiem była już dużo bardziej wymagająca. Rysowało się każdą ze ścian w obszarze roboczym i potem kopiowało na ekran - wszystko to w kolejności od najdalszej do najbliższej. Czyli dużo więcej roboty dla blittera: rysowanie linii, wypełnianie, kopiowanie na ekran (dla każdej ze ścian obiektu - niekoniecznie trójkąta). Triangulacja tutaj była niepotrzebnym obciążeniem, bo więcej trzeba było sortować, rysować, kopiować.
Oczywiście istniał szereg optymalizacji - np. rysować osobno obiekty "wypukłe" i je sortować i kopiować. Oczywiście każde z zadań mogło być potencjalnie realizowane przez CPU, ale w standardowej konfiguracji blitter dawał sobie radę najlepiej jak mógł, a robotę obliczeniową i tak musiało zrobić CPU.
Dlatego też, tak często zmniejszano efektywny obszar na którym była wyświetlana grafika 3D. Obliczenia nie były tak bolesne, jak samo rysowanie. :)
Tyle w temacie grafiki bitplanowej. W grafice w trybie chunky sprawa była dużo prostsza, znacznie łatwiej się optymalizowało wypełnianie, ale to już nie moje czasy :)
Ogólnie grafikę dzieliło się na 2 zasadnicze rodzaje "wypukłą" i "niewypukłą". W tej drugiej jedna ściana obiektu mogła CZĘŚCIOWO przesłaniać drugą ścianę obiektu.
W pierwszym przypadku rysowało się zarysy ścian (mogły to być supełnie dowolne wielokąty, byle na siebie nie zachodziły) i potem blitter je wypełniał. A wypełniał je linia po linii poziomo przy użyciu trybu (jeśli się nie mylę) XOR filling. Tak więc wystarczyło narysować krawędzie obiektu (też w specjalnym trybie = XOR + jeden piksel kreski na linię poziomą), a potem zlecić blitterowi wypełnienie - raz na jedną klatkę animacji.
Jednak grafika "niewypukła" - z częściowym przesłanianiem była już dużo bardziej wymagająca. Rysowało się każdą ze ścian w obszarze roboczym i potem kopiowało na ekran - wszystko to w kolejności od najdalszej do najbliższej. Czyli dużo więcej roboty dla blittera: rysowanie linii, wypełnianie, kopiowanie na ekran (dla każdej ze ścian obiektu - niekoniecznie trójkąta). Triangulacja tutaj była niepotrzebnym obciążeniem, bo więcej trzeba było sortować, rysować, kopiować.
Oczywiście istniał szereg optymalizacji - np. rysować osobno obiekty "wypukłe" i je sortować i kopiować. Oczywiście każde z zadań mogło być potencjalnie realizowane przez CPU, ale w standardowej konfiguracji blitter dawał sobie radę najlepiej jak mógł, a robotę obliczeniową i tak musiało zrobić CPU.
Dlatego też, tak często zmniejszano efektywny obszar na którym była wyświetlana grafika 3D. Obliczenia nie były tak bolesne, jak samo rysowanie. :)
Tyle w temacie grafiki bitplanowej. W grafice w trybie chunky sprawa była dużo prostsza, znacznie łatwiej się optymalizowało wypełnianie, ale to już nie moje czasy :)
24.09.2019 09:08
[#17]
Re: Gry wektorowe - silnik sposób działania
@drsky, post #16
Dzięki za wyjaśnienie. Jakiś czas temu zastanawiałem się właśnie, czy trzeba robić tak jak opisałeś, czy jest może jakiś trick. A tu wychodzi, że nie ma. Żeby coś chodziło sensownie np. Another World, to wyciskało się siódme poty z Amigi, bo choć Blitter jest szybki, to jak mamy rysować w obszarze roboczym trójkąty, później je nakładać na scenę (ekran), to mamy prawie 2x więcej operacji. Rysowanie trójkąta na boku, a później nakładanie na ekran.
Troszkę deprecjonujecie działanie Desert Wolf, tam też się wyciska wszystko z maszyny. A500 to nie jest demon prędkości.
Troszkę deprecjonujecie działanie Desert Wolf, tam też się wyciska wszystko z maszyny. A500 to nie jest demon prędkości.
24.09.2019 09:53
[#18]
Re: Gry wektorowe - silnik sposób działania
@Hexmage960, post #15
Fantavision jak na swoje czasy było bardzo fajne i fajnie działało. Ale to była płaska wektorówka. Takie 2D nie wymagało liczenia perspektywy, jakiegoś bufora głębokości. Poziom złożoności obliczeń praktycznie żaden w porównaniu z liczeniem wierzchołków i rysowaniem brył w 3D. No ale takie było założenie Fantavision i sprawdziło się bardzo dobrze.
Gdyby format Fantavision ubrać w standard, opisać, zrobić player to mielibyśmy swojego Flasha.
Ostatnia aktualizacja: 24.09.2019 09:54:38 przez MDW
Gdyby format Fantavision ubrać w standard, opisać, zrobić player to mielibyśmy swojego Flasha.
Ostatnia aktualizacja: 24.09.2019 09:54:38 przez MDW
24.09.2019 10:27
[#19]
Re: Gry wektorowe - silnik sposób działania
@MDW, post #18
Oficjalnym formatem 2d wektorowym na Amidze był IFF DR2D
https://wiki.amigaos.net/wiki/DR2D_IFF_2-D_Objects
https://wiki.amigaos.net/wiki/DR2D_IFF_2-D_Objects
24.09.2019 10:29
[#20]
Re: Gry wektorowe - silnik sposób działania
@drsky, post #16
Dzięki za wyjaśnienie. Muszę to przetrawić. Wiem jak się rysuje 3d w trybie chunky.
Czyli rozumiem, że te gry były rysowane blitterem i dobrze zoptymalizowane ?
Czemu na ST bez blitera działa to działa szybciej ? 1 Mhz by taką różnicę robił ? Tam są potrzebne cykle CPU na rysowanie w Amidze nie skoro blitter to rysuje. Zresztą wtedy gry by nie działały szybciej na kartach turbo.
Kwestia Another World faktycznie to tylko 2d jednak działo płynnie na A500. Dziwi mnie że nikt inny nie próbował w ten sposób robić gier 2d na Ami.
Nadal zastanawia mnie czemu 4d boxing działał na A500 tak wolno dużo do rysowania tam nie ma. Wydaje się to winą słabego portu z PC.
Czyli rozumiem, że te gry były rysowane blitterem i dobrze zoptymalizowane ?
Czemu na ST bez blitera działa to działa szybciej ? 1 Mhz by taką różnicę robił ? Tam są potrzebne cykle CPU na rysowanie w Amidze nie skoro blitter to rysuje. Zresztą wtedy gry by nie działały szybciej na kartach turbo.
Kwestia Another World faktycznie to tylko 2d jednak działo płynnie na A500. Dziwi mnie że nikt inny nie próbował w ten sposób robić gier 2d na Ami.
Nadal zastanawia mnie czemu 4d boxing działał na A500 tak wolno dużo do rysowania tam nie ma. Wydaje się to winą słabego portu z PC.
24.09.2019 10:31
[#21]
Re: Gry wektorowe - silnik sposób działania
@drsky, post #16
@Drsky
Panie Adamie, chętnie wracam do pańskiej książki, w której opisuje Pan m.in. grafikę wektorową na Amidze (Asembler dla początkujących).
Jeśli chodzi o rysowanie na Amidze, to trzeba wyważyć proporcje. Ja jestem zwolennikiem podejścia, by CPU liczyło i nie zajmowało się grafiką. CPU może liczyć współrzędne i zlecać zadania Blitterowi. Zaś Blitter może zajmować się całą ciężką pracą przy grafice odnośnie właściwego kopiowania, przesuwania i wypełniania bitplanów w pamięci graficznej.
Pamięć graficzna Amigi ma tę zaletę, że wszystko to co się w niej znajduje może zostać wyświetlone w każdej chwili. Dlatego najlepszą strategią jest trzymać w niej wszystkie niezbędne dane graficzne, a nie w pamięci FAST, ponieważ przełączanie buforów nie obciąża procesora ani koprocesorów graficznych.
Jeżeli chcemy w szybki sposób animować ekran, warto też blitować tylko w te bitplany, co potrzeba. Np. do wyznaczenia figury geometrycznej wystarczy blitować tylko w jeden bitplan - nie potrzeba w kilka! Po prostu rysujemy figurę za pomocą trybu liniowego po czym używamy gotowej figury do wypełnienia interesujących nas bitplanów.
W stosunku do chunky przyrost mocy jest spory, bo w Amidze zaledwie jednym zapisem planarnym zmodyfikujemy 16 lub 32 piksele w bitplanie lub w masce!
Chunky przydaje się do manipulacji kolorami i mapowania tekstur. Tu rzeczywiście CPU wspomaga rysowanie, aczkolwiek w Amidze pamięć graficzna jest w ten sposób zorganizowana, by zoptymalizować właśnie wypełnianie (co pisał sam Jay Miner). Przy odpowiednim wykorzystaniu bitplanów, masek można osiągnąć w przypadku grafiki planarnej naprawdę szybką animację na Amidze, od 4 do 32 razy szybszą niż analogicznym PC, który musi spacerować po pikselach.
Wyświetlanie filmów i losowych kolorów wypada gorzej, ale i tak PC wymaga sporo więcej mocy by swobodnie ustawiać piksele ekranowe.
Ja jestem zdania, że przy 320x256 warto bardziej bawić się w grafikę rysowaną, a nie jakieś tekstury, bo po prostu grafika rysowana może wyglądać bajecznie (wszystko zależy od talentu i wyobraźni osoby rysującej), zaś skalowane tekstury - bez wygładzania - troszkę gorzej.
Panie Adamie, chętnie wracam do pańskiej książki, w której opisuje Pan m.in. grafikę wektorową na Amidze (Asembler dla początkujących).
Jeśli chodzi o rysowanie na Amidze, to trzeba wyważyć proporcje. Ja jestem zwolennikiem podejścia, by CPU liczyło i nie zajmowało się grafiką. CPU może liczyć współrzędne i zlecać zadania Blitterowi. Zaś Blitter może zajmować się całą ciężką pracą przy grafice odnośnie właściwego kopiowania, przesuwania i wypełniania bitplanów w pamięci graficznej.
Pamięć graficzna Amigi ma tę zaletę, że wszystko to co się w niej znajduje może zostać wyświetlone w każdej chwili. Dlatego najlepszą strategią jest trzymać w niej wszystkie niezbędne dane graficzne, a nie w pamięci FAST, ponieważ przełączanie buforów nie obciąża procesora ani koprocesorów graficznych.
Jeżeli chcemy w szybki sposób animować ekran, warto też blitować tylko w te bitplany, co potrzeba. Np. do wyznaczenia figury geometrycznej wystarczy blitować tylko w jeden bitplan - nie potrzeba w kilka! Po prostu rysujemy figurę za pomocą trybu liniowego po czym używamy gotowej figury do wypełnienia interesujących nas bitplanów.
W stosunku do chunky przyrost mocy jest spory, bo w Amidze zaledwie jednym zapisem planarnym zmodyfikujemy 16 lub 32 piksele w bitplanie lub w masce!
Chunky przydaje się do manipulacji kolorami i mapowania tekstur. Tu rzeczywiście CPU wspomaga rysowanie, aczkolwiek w Amidze pamięć graficzna jest w ten sposób zorganizowana, by zoptymalizować właśnie wypełnianie (co pisał sam Jay Miner). Przy odpowiednim wykorzystaniu bitplanów, masek można osiągnąć w przypadku grafiki planarnej naprawdę szybką animację na Amidze, od 4 do 32 razy szybszą niż analogicznym PC, który musi spacerować po pikselach.
Wyświetlanie filmów i losowych kolorów wypada gorzej, ale i tak PC wymaga sporo więcej mocy by swobodnie ustawiać piksele ekranowe.
Ja jestem zdania, że przy 320x256 warto bardziej bawić się w grafikę rysowaną, a nie jakieś tekstury, bo po prostu grafika rysowana może wyglądać bajecznie (wszystko zależy od talentu i wyobraźni osoby rysującej), zaś skalowane tekstury - bez wygładzania - troszkę gorzej.
24.09.2019 11:06
[#22]
Re: Gry wektorowe - silnik sposób działania
@Hexmage960, post #21
Tylko bez "Panie Adamie". Smarkacz byłem jak książkę pisałem (miałem 14 lat), tak więc trudno mi za tamten okres "Panować" :)
Odnośnie samej grafiki - na pewno da się zoptymalizować wypełnianie przy użyciu szybszych procków, tablicowania i wykorzystania pamięci FAST. Ciekawie sobie radzili też na innych platformach (np. Atari ST). Z jednej strony obecność Blittera nieźle nam (koderom) pomagała, z drugiej rozleniwiała - i zapominaliśmy, że pewne rzeczy można było zrobić znacznie szybciej przy użyciu CPU (nawet na niedopalonej A500).
Odnośnie samej grafiki - na pewno da się zoptymalizować wypełnianie przy użyciu szybszych procków, tablicowania i wykorzystania pamięci FAST. Ciekawie sobie radzili też na innych platformach (np. Atari ST). Z jednej strony obecność Blittera nieźle nam (koderom) pomagała, z drugiej rozleniwiała - i zapominaliśmy, że pewne rzeczy można było zrobić znacznie szybciej przy użyciu CPU (nawet na niedopalonej A500).
24.09.2019 12:01
[#23]
Re: Gry wektorowe - silnik sposób działania
@Hexmage960, post #21
Przy odpowiednim wykorzystaniu bitplanów, masek można osiągnąć w przypadku grafiki planarnej naprawdę szybką animację na Amidze, od 4 do 32 razy szybszą niż analogicznym PC, który musi spacerować po pikselach.
Kwestia tego co w danej chwili jest potrzebne. Co prawda amiga moze 32 piksele na raz postawic w przypadku dwukolorowego trybu (albo w 8 krokach postawic na raz 32 piksele w trybie 8bpp), ale jezeli chcialbys zmodyfikowac tylko jeden pixel sprawa sie bardzo komplikuje:
1. Odczytaj bajt/slowo/dlugie slowo z bitmapy
2. Zamaskuj niemodyfikowane pixele a pomoca AND
3. Namaluj piksel za pomoca OR
4. Zapisz bajt/slowo/dlugie slowo do bitmapy
5. Powtorz dla kazdego bitplanu (czyli do 8 razy)
w przypadku trybu chunky 8bpp sprawa sprowadza sie do zapisania jednego bajtu do pamieci.
Wyświetlanie filmów i losowych kolorów wypada gorzej, ale i tak PC wymaga sporo więcej mocy by swobodnie ustawiać piksele ekranowe.
Sporo wiecej mocy? Jeden zapis do RAM to od jeden albo kilka pikseli w zaleznosci od dlugosci zapisywanego slowa. Jeden pixel = Jeden zapis = jedna instrukcja CPU.
24.09.2019 12:15
[#24]
Re: Gry wektorowe - silnik sposób działania
@mschulz, post #23
Z tego co czytałem np. Doom na PC korzysta z Mode X(mode Y ?) który jest trybem planarnym. Natomiast np. F-29 Retaliator który działa szybko nawet na PC 286, wykorzystuje tryb VGA 0dh który również jest trybem planarnym a nie chunky.
https://scalibq.wordpress.com/2011/12/21/just-keeping-it-real-part-4-6/
A więc chyba podobnie jak na Amidze ? Tylko tam planar jest szybszy niż chunky ?
Ostatnia aktualizacja: 24.09.2019 12:16:23 przez zyga64
https://scalibq.wordpress.com/2011/12/21/just-keeping-it-real-part-4-6/
A więc chyba podobnie jak na Amidze ? Tylko tam planar jest szybszy niż chunky ?
Ostatnia aktualizacja: 24.09.2019 12:16:23 przez zyga64
24.09.2019 12:30
[#25]
Re: Gry wektorowe - silnik sposób działania
@mschulz, post #23
w przypadku trybu chunky 8bpp sprawa sprowadza sie do zapisania jednego bajtu do pamieci.
Zgadza się - w chunky jeden zapis to jeden piksel, więc grafika chunky jest zoptymalizowana pod kątem wklejania pojedynczych 8-bitowych pikseli (musimy sprawdzać czy dany piksel bierzemy z obiektu lub tła).
Jednakże w planar grafika jest zoptymalizowana pod kątem wklejania dużej grupy pikseli. Więc jeżeli mamy te 32 piksele przygotowane, zapis tych 32 pikseli to od 1 do 8 operacji (w zależności od liczby bitplanów). Do rozgraniczenia obiektu i tła stosujemy 1-bitplanową maskę.
Sporo wiecej mocy? Jeden zapis do RAM to od jeden albo kilka pikseli w zaleznosci od dlugosci zapisywanego slowa. Jeden pixel = Jeden zapis = jedna instrukcja CPU.
Chodzi o to, że wklejanie pojedyńczych, losowych pikseli jest bardziej kosztowne (zgodnie z powyższym), więc PC musi mieć szybszy procesor by osiągnąć podobny rezultat - losową animację wszystkich pikseli na ekranie (np. film).
24.09.2019 13:01
[#26]
Re: Gry wektorowe - silnik sposób działania
@mschulz, post #23
Do tego trzeba pamietać, że blitter operuje na prostokątnych obszarach. Rysowanie wielokątów marnuje cykle. Tyczy się to wypełniania i potem kopiowania. Przy rysowaniu procesorem (nawet bez c2p, prosto po bitplanach) nie ma straty. Idealnym przypadkiem pewnie byłoby używanie tego i tego przy odrobienie pamięci fast.
24.09.2019 14:10
[#27]
Re: Gry wektorowe - silnik sposób działania
@Hexmage960, post #25
Chodzi o to, że wklejanie pojedyńczych, losowych pikseli jest bardziej kosztowne (zgodnie z powyższym), więc PC musi mieć szybszy procesor by osiągnąć podobny rezultat - losową animację wszystkich pikseli na ekranie (np. film).
Czyli postawienie losowo pixela na PC w trybie chunky jest wolniejsze niz na Amidze w trybie planar? Chyba zartujesz...
24.09.2019 16:31
[#28]
Re: Gry wektorowe - silnik sposób działania
@docent, post #27
Czyli postawienie losowo pixela na PC w trybie chunky jest wolniejsze niz na Amidze w trybie planar? Chyba zartujesz...
Nie, nie o to mi chodziło. Po prostu CPU PC musi się więcej napocić by postawić te 32 piksele chunky (32 operacje), niż Amiga postawić 32 piksele w planar (1-8 operacji).
Oczywiście korzyści z chunky są takie, że CPU może sobie z wartością piksela robić co chce - w szczególności zmapować, gdzie Amiga musi sobie najpierw te bitplany poskładać. Ale nadal chunky ma większe zapotrzebowanie na moc procesora.
Zresztą można by wyliczyć, ale podejrzewam że koszt zamortyzowany mapowania w chunky i planar będzie podobny, tzn. w obu trybach jakaś operacja będzie kosztowniejsza ale inna tańsza - i suma tych kosztów będzie podobna.
24.09.2019 16:54
[#30]
Re: Gry wektorowe - silnik sposób działania
@makarsky, post #29
Dla Amigi 32 losowe pixele w 8bpl to 32 * 8 operacji ....
Nie o to mi chodziło w tym "PC wymaga szybszego procesora bo wklejanie pikseli pojedynczo w chunky jest kosztowniejsze niż wklejanie grup po 32 piksele planar", ale OK - 32 losowe piksele będą kosztowne dla Amigi, ale akurat mniej niż 32 * 8.
Tak jak napisałem, koszt można wyliczyć i zamortyzowany wypada podobnie.
Przykład dla planar-2-chunky.
Złożenie 32 pikseli: 2 bitplanów to 2 operacje na 64 bitach. Złożenie 4 bitplanów to 4 operacje na 128 bitach. Złożenie 8 bitplanów to 8 operacji na 256 bitach. Jak widać stosunek (rozmiar danych/czas) pozostaje identyczny i wynosi 32 piksele (bity) na operację.
Podobnie jest z chunky-2-planar, ale trzeba by dokładnie wyliczyć. Chyba się nie pomyliłem.
Ostatnia aktualizacja: 24.09.2019 17:01:27 przez Hexmage960