Komentowana treść: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
01.07.2024 18:41
[#61]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@koczis, post #59
Nie widzę dużej różnicy między oskarżeniem a błędnym założeniem. Ale zostawmy to na boku, tak czy inaczej, problem nie polega na tym, że nie byłbym w stanie zrobić wersji AGA, lecz na tym, że jedyne systemy, które potrzebowałyby wersji AGA, już teraz działają trochę wolno w trybach Chunky, a na AGA byłoby jeszcze wolniej.
01.07.2024 18:55
[#63]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@Don_Adan, post #60
Gorky17 nie jest napisane w ASM, tylko w wysokopoziomowym C++, już wersja na PC. Czynnikiem ograniczającym wydajność jest przepustowość pamięci - gra działa w rozdzielczości 640x480 16-bit, używając obiektów przechowywanych w skompresowanym formacie. Wyraźnie widać, że dopóki główny ekran nie jest przesuwany, nawet na 060 prędkość jest dobra (na przykład ekrany walki), ale jak tylko pojawia się pełnoekranowe przewijanie, ilość danych jest zbyt duża. Całkowita reimplementacja od podstaw nie jest naprawdę opcją - zwłaszcza, że w tym czasie mogłyby zostać wydane 2-3 gry na Vampire, PiStorm i OS4, i wszystkie w dobrej prędkości. Także zakładam, że zanim osiągnęłoby się coś, co działałoby szybciej na 060 - jeśli w ogóle by się to udało - więcej ludzi przeniesie się na PiStorm i Vampire, co uczyniłoby to wszystko jeszcze większą stratą czasu. Optymalizacje robiłem tam, gdzie miało to sens (na przykład użycie AMMX ASM dla wersji Vampire, gdzie miało to sens - niestety nie wszędzie, ponieważ sprite'y w tej grze mają tendencję do małych szerokości i nie są potęgami liczby 2, i zwłaszcza całkowita wymiana całego systemu dźwiękowego, który był (w wersji PC i OS4) zrobiony w sposób nieoptymalny wydajnościowo na OS 3.x i dlatego został złomowany i zaimplementowany od nowa, również wiele w ogólnej funkcjonalności odświeżania wideo i funkcjonalności ładowania zostało zoptymalizowane). Dużym problemem Amigi teraz są różnice w wydajności. Czy wiedziałeś, że PiStorm 2,2 GHz jest 12x szybszy od Vampire V4? A x5000 jest 2,5x szybszy od PiStorm 2,2 GHz? Przy wyborze gry do portowania na AmigaOS trzeba dokładnie sprawdzić, na których platformach Amiga to może działać (miejmy nadzieję, że na więcej niż jednej lub dwóch). Zdecydowanie mam nadzieję mieć coś w zanadrzu również dla słabszych systemów w przyszłości (ale nie Heretic 2, który zdecydowanie będzie wymagał minimum PiStorm).
01.07.2024 19:16
[#64]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@MagicSN, post #63
więcej ludzi przeniesie się na PiStorm i Vampire
V4 jest na rynku w zasadzie 5 lat, Pistorm jakoś 2. Jak na razie, nie widzę tłumów do tych przenosin. A 060 tylko drożeją.
Proszę nie kreować argumentów pod użytek bieżącej retoryki.
W istocie, nie ma możliwości dokładnego przewidzenia jaki będzie udział tych platform za 2-4 lata. No może poza tym, że ludzie stopniowo odchodzą od klasycznych setupów (ECS) na rzecz "dopalonych" Amig.
01.07.2024 20:09
[#65]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@MagicSN, post #51
1) Może po prostu warto uruchomić mos2wos pod MorphOSem jeśli masz odpowiednią maszynę (to troche abberacja, że najsensowniejsze SDK dla WarpOSa jest pod MorphOSem ale co poradzić 
)
2) Co do prędkości 060 to czy wrzucenie większość wymaganych danych do VRAMu dla kart z dużą ilością pamięci (Voodoo3, Radeon9200 pod Mediatorem) i blitowanie z VRAMu nie pomogłoby z prędkością przesuwania (ewentualnie otworzenie ekranu wiekszego niż tryb wyswietlania 640x480 ale tu pewnie ograniczeniem będzie CGX/P96)
)2) Co do prędkości 060 to czy wrzucenie większość wymaganych danych do VRAMu dla kart z dużą ilością pamięci (Voodoo3, Radeon9200 pod Mediatorem) i blitowanie z VRAMu nie pomogłoby z prędkością przesuwania (ewentualnie otworzenie ekranu wiekszego niż tryb wyswietlania 640x480 ale tu pewnie ograniczeniem będzie CGX/P96)
01.07.2024 20:49
[#66]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@_DiskDoctor_, post #64
więcej ludzi przeniesie się na PiStorm i Vampire
V4 jest na rynku w zasadzie 5 lat, Pistorm jakoś 2. Jak na razie, nie widzę tłumów do tych przenosin. A 060 tylko drożeją.
Proszę nie kreować argumentów pod użytek bieżącej retoryki.
W istocie, nie ma możliwości dokładnego przewidzenia jaki będzie udział tych platform za 2-4 lata. No może poza tym, że ludzie stopniowo odchodzą od klasycznych setupów (ECS) na rzecz "dopalonych" Amig
Nowe oprogramowanie wymusi trend przesiadki.
02.07.2024 06:39
[#68]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@koczis, post #66
Nowe oprogramowanie wymusi trend przesiadki.
Prawdopodobnie nowy hardware związany z rozwojem komputerów jedno płytkowych również. W miarę pojawienia się nowych wersji Raspberry Pi moc będzie rosła. Będzie to najtańsza opcja Amigi z emulowanym 68K. Dodatkowo będzie można wyjąć Raspberry Pi z karty turbo i zastosować do zupełnie innych celów, jeśli będzie taka potrzeba. Ten typ rozwoju jest nieunikniony, czy komuś się to podoba czy nie. Osobiście jeśli potrzebuje więcej mocy wolę opcję PPC.
02.07.2024 08:33
[#69]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@nowy80, post #68
(To jest właściwie odpowiedź na kilka wcześniejszych komentarzy.)
Zgadzam się z wieloma rzeczami, które zostały tu powiedziane. Nowe oprogramowanie, jak i nowe rozwinięcia na froncie sprzętowym, wpłyną na to, dokąd pójdzie rynek. To, co powiedziałem o ludziach przechodzących na nowe rozwinięcia - Pistorm i Vampire - było szczególnie wpłynięte przez spotkanie Amigi dwa dni temu. Odniosłem wrażenie, że wiele osób tam obecnych (większość to wciąż użytkownicy 030+) po raz pierwszy widziało Pistorm "w akcji". Zadano mi wiele pytań na ten temat (i myślę, że niektórzy inni użytkownicy Pistorm również otrzymali takie pytania). Kilka razy słyszałem rzeczy w stylu "Myślę o zdobyciu jednej z tych nowych rzeczy, albo Pistorm, albo Vampire". I tak, nie wiemy dokładnie, w jakim kierunku to pójdzie, ale zasadniczo mamy Pistorm, 68080 i PPC - jeśli nie uwzględniamy emulacji na razie. Tam właśnie zmierzają rzeczy. Staram się wspierać wszystkie trzy ścieżki (i emulację) wszędzie, gdzie to możliwe. Nie portuję tylko na jedną z nich, mimo że mam swoje osobiste preferencje (które są najpierw OS4, potem Pistorm), ale rynek Amigi jest zbyt mały, aby wspierać tylko jedną, zwłaszcza jeśli stosunkowo łatwo jest wspierać kilka. Niektóre (WarpOS, A1222) mogą być trudniejsze do zrobienia z powodu sytuacji z kompilatorami, ale również spróbuję w przyszłości.
Ostatnia aktualizacja: 02.07.2024 08:34:54 przez MagicSN
Zgadzam się z wieloma rzeczami, które zostały tu powiedziane. Nowe oprogramowanie, jak i nowe rozwinięcia na froncie sprzętowym, wpłyną na to, dokąd pójdzie rynek. To, co powiedziałem o ludziach przechodzących na nowe rozwinięcia - Pistorm i Vampire - było szczególnie wpłynięte przez spotkanie Amigi dwa dni temu. Odniosłem wrażenie, że wiele osób tam obecnych (większość to wciąż użytkownicy 030+) po raz pierwszy widziało Pistorm "w akcji". Zadano mi wiele pytań na ten temat (i myślę, że niektórzy inni użytkownicy Pistorm również otrzymali takie pytania). Kilka razy słyszałem rzeczy w stylu "Myślę o zdobyciu jednej z tych nowych rzeczy, albo Pistorm, albo Vampire". I tak, nie wiemy dokładnie, w jakim kierunku to pójdzie, ale zasadniczo mamy Pistorm, 68080 i PPC - jeśli nie uwzględniamy emulacji na razie. Tam właśnie zmierzają rzeczy. Staram się wspierać wszystkie trzy ścieżki (i emulację) wszędzie, gdzie to możliwe. Nie portuję tylko na jedną z nich, mimo że mam swoje osobiste preferencje (które są najpierw OS4, potem Pistorm), ale rynek Amigi jest zbyt mały, aby wspierać tylko jedną, zwłaszcza jeśli stosunkowo łatwo jest wspierać kilka. Niektóre (WarpOS, A1222) mogą być trudniejsze do zrobienia z powodu sytuacji z kompilatorami, ale również spróbuję w przyszłości.
Ostatnia aktualizacja: 02.07.2024 08:34:54 przez MagicSN
02.07.2024 08:45
[#70]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@MagicSN, post #63
Nie wiedzialem tego, ze PiStorm jest 12x szybszy od Vampire 4.
Z tego co zrozumialem to 68060 jest zbyt wolne tylko dla scrollowania, gdzie wystepuja obiekty spakowane.
Wiec jest kilka bardzo prostych metod optymalizacji mozliwych do przeprowadzenia w tej grze:
1. Zoptymalizowac oryginalna procedure depakujaca, bo jest za wolna.
2. Podczas instalacji gry z CD, zdepakowac wszystkie lub tylko niezbedne spakowane obiekty.
I uzywac ich podczas scrollowania.
Warp ma 240MB fast RAM, a TF4060 256MB fast RAM, powinno wystarczyc.
3. Jesli dane obiektow musza byc przechowywane w formie spakowanej to je przepakowac i dolaczyc na USB instalacyjnym.
Uzyc nalezy ZX0 lub Arj7, ktore bardzo dobrze pakuja i maja bardzo szybkie procedury depakujace.
Z tego co zrozumialem to 68060 jest zbyt wolne tylko dla scrollowania, gdzie wystepuja obiekty spakowane.
Wiec jest kilka bardzo prostych metod optymalizacji mozliwych do przeprowadzenia w tej grze:
1. Zoptymalizowac oryginalna procedure depakujaca, bo jest za wolna.
2. Podczas instalacji gry z CD, zdepakowac wszystkie lub tylko niezbedne spakowane obiekty.
I uzywac ich podczas scrollowania.
Warp ma 240MB fast RAM, a TF4060 256MB fast RAM, powinno wystarczyc.
3. Jesli dane obiektow musza byc przechowywane w formie spakowanej to je przepakowac i dolaczyc na USB instalacyjnym.
Uzyc nalezy ZX0 lub Arj7, ktore bardzo dobrze pakuja i maja bardzo szybkie procedury depakujace.
02.07.2024 09:00
[#71]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@michal_zukowski, post #65
Wiem. Próbowałem uruchomić mos2wos za pomocą środowiska cygwin - którego zazwyczaj używam do kompilacji. Jakoś to nie działało. Skrypt z Wiki wydawał się przestarzały, kilka rzeczy w archiwum mos2wos zmieniło nazwy. Udało mi się naprawić tę część, ale potem pojawił się błąd podczas próby kompilacji binutils. Błąd, co do którego nie byłem pewien, w czym tkwi problem. Nie zainstaluję MorphOS na mojej Amidze, to się nie wydarzy. Ale mam faktycznie ofertę pożyczonego MacMini, więc jeśli nic innego się nie uda, to właśnie to zrobię. MacMini ma obecnie pewne problemy sprzętowe, więc prawdopodobnie potrzeba kilku tygodni, aby go naprawić (był długo nieużywany). Mam ludzi, którzy mogą testować pod Classic WarpOS, Sonnet i MOS, więc jak tylko zdobędę działający kompilator, rzeczy powinny być łatwiejsze. Nadal, jeśli ktoś bardziej zna się na mos2wos i może stworzyć kompilator dla cygwin, OS4, OS3 lub Linux-x86, to uprościłoby sprawy (preferowana jest możliwość uruchamiania na cygwin lub os4/os3 niż Linux, ponieważ Linux mógłbym uruchomić tylko na VM, nie mam maszyny z Linuxem).
I tak, to dziwne, że MOS jest najłatwiejszy do tworzenia aplikacji WOS. Prawdopodobnie wynika to z faktu, że MOS ma warstwę emulacji WOS, a większość ludzi po czerwonej stronie porzuciła WOS i przeszła na OS4.
(2) Już zrobione)
I tak, to dziwne, że MOS jest najłatwiejszy do tworzenia aplikacji WOS. Prawdopodobnie wynika to z faktu, że MOS ma warstwę emulacji WOS, a większość ludzi po czerwonej stronie porzuciła WOS i przeszła na OS4.
(2) Już zrobione)
02.07.2024 09:13
[#72]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@Don_Adan, post #70
Mało kto o tym wie. I myślę, że zespół Pistorm nie robi zbyt wiele reklam, podczas gdy Apollo wykonuje fantastyczną pracę (to nie jest krytyka, robią to absolutnie prawidłowo!) w ich reklamie, tożsamości produktu i innych rzeczach. Jeśli nie robisz reklamy, nic dziwnego, że ludzie mniej wiedzą o twoim produkcie. Podstawą tego stwierdzenia jest timedemo na Heretic2 (proszę zauważyć, że to stwierdzenie opiera się na Cm4 2,2 GHz, które jest niejako najwyższej klasy, oczywiście różnica w prędkości jest mniejsza w porównaniu z Pi3 1,5 GHz, może wtedy tylko 4x lub 5x). Podstawą tego stwierdzenia jest to, że H2 działa z prędkością 25 fps w rozdzielczości 640x480 na Pistorm Cm4 2,2 GHz. Na Vampire jest to około 8 fps w 320x240 (czyli 4x mniejsza rozdzielczość, 3x niższa prędkość przy niższej rozdzielczości). To nawet nie jest walka o to, kto jest szybszy (z drugiej strony, z tego co słyszałem, Vampire jest bardziej kompatybilny z starymi grami Amiga). Przepisanie algorytmów pakowania nie jest takie łatwe, podczas gdy mogę prowadzić rozmowę po polsku za pomocą ChatGPT, analiza kodu źródłowego z nazwami zmiennych/funkcji/komentarzami w języku polskim jest trudna. Więc ograniczyłem optymalizację tam, gdzie jest to potrzebne. Dla Pistorm prędkość ładowania jest optymalna, a dla Vampire nadal dobra. Niższa prędkość przewijania na dużych ekranach (jak ekran wprowadzający z nadpływającą łodzią) na 060 nie jest związana z depakowaniem (depakowanie zostało już całkowicie zakończone, zanim ekran zareaguje), ale z przepustowością pamięci. Pamiętaj, że mówimy o 640x480x16Bit. Prawdopodobnie sposób (tutaj przeprowadziłem dogłębną analizę mimo polskiego języka) w jaki zrobiony jest system sprite'ów jest z tym związany. Ale bez całkowitej implementacji od zera to by nie pomogło. I znowu - wszystkie nazwy zmiennych/funkcji/komentarze są w języku polskim, a nie ma wystarczająco dużo systemów 060 100 MHz, aby ten ogromny wysiłek był opłacalny. Na Pistorm i Vampire gra działa dobrze.
02.07.2024 09:21
[#73]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@Don_Adan, post #70
Przed pisaniem abstrakcyjnych postów zobacz:
((640*480*2 [16bit])*20 [fps] )/(1024 [kb] *1024 [MB]) = 11 MB/s
Wynika z tego że do względnie dynamicznego blitowania z fastu (depackowanie pomijam) potrzeba ~11 MB/s (o ile dane nie mogą siedzieć w ram). To większa prędkość niż ma Fast w A4000. Szybciej niż Zorro2, na granicy możliwości kart z Zorro3, łapie się BVisionPPC, szybsze karty w Mediatorze i współczesne implementacje fpga.
Ostatnia aktualizacja: 02.07.2024 09:22:13 przez michal_zukowski
((640*480*2 [16bit])*20 [fps] )/(1024 [kb] *1024 [MB]) = 11 MB/s
Wynika z tego że do względnie dynamicznego blitowania z fastu (depackowanie pomijam) potrzeba ~11 MB/s (o ile dane nie mogą siedzieć w ram). To większa prędkość niż ma Fast w A4000. Szybciej niż Zorro2, na granicy możliwości kart z Zorro3, łapie się BVisionPPC, szybsze karty w Mediatorze i współczesne implementacje fpga.
Ostatnia aktualizacja: 02.07.2024 09:22:13 przez michal_zukowski
02.07.2024 10:16
[#74]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@michal_zukowski, post #73
Dokładnie. Bardzo dobrze to ująłeś, właśnie to jest problem. Właściwie próbowałem, czy można renderować grafikę do niższej rozdzielczości, ale powiedzmy - nie rozmawiajmy o wynikach tego. Proszę zauważyć, że ponownie oceniłem moje stwierdzenie '12x szybciej niż Vampire', ponownie przetestowałem w rozdzielczości 320x240 na obu systemach dla pełnej sprawiedliwości. W rzeczywistości wersja na Vampire była trochę wolniejsza niż pamiętałem - 6.8 fps, a nie 8 fps, 8 fps było na 100 MHz 060, jak teraz pamiętam, z jakiegoś powodu na H2 działało szybciej na 060, podczas gdy dla G17 jest szybciej na Vampire (nawet w wersji przed wprowadzeniem AMMX) - 320x240 na H2 na 2.2 GHz Pistorm to około 45 fps (więc między 6x a 7x prędkości Vampire V4), na Pi3 to 19 fps (najnowsza wersja prawdopodobnie trochę szybciej, tamta wersja nadal robiła pewne rzeczy w softfloat, na moim Cm4 najnowsza wersja jest o 7% szybsza), na Pi4 32 fps (znów stara wersja), więc 4x prędkość Vampire V4. Dla pełności zrobiłem również (tylko na Pi Cm4) test w rozdzielczości 800x600, uzyskałem 19.5 fps i nadal jest to grywalne! (choć faktycznie wybór 640x480 z aktywowanym bifiltrem może być opcją, jeśli nie chcesz absolutnie wysokich fps, bifiltr niestety jest bardzo obciążający procesor i na niczym poniżej Cm4 nie sądzę, że jest to realne - można go wybrać w ustawieniach gry). Może być interesujące, że Claude powiedział, że prędkość emulacji 68k na Pistorm nie osiągnęła jeszcze swojego limitu.
02.07.2024 10:58
[#75]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@MagicSN, post #71
Message from grelbfarlk (eab):
Basically the way we've built all the stuff for WarpOS was from Hedeon's wonderful this:
http://aminet.net/package/dev/gcc/gcc-mos2wos
It's using MorphOS to run GCC, it's great and you get all of the nice IDE stuff from MorphOS, but that doesn't help if you're trying to run GCC on AmigaOS 4.1 under really super old WarpOS includes.
The other option being building under 2.95.3 on 68K, pretty much worked, Exult I built that way and some other stuff like Hyperion Quake 2 mods. But I ran it under WinUAE with tons of memory..
02.07.2024 20:55
[#78]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@Don_Adan, post #77
Ponownie - rozpakowywanie nie jest problemem, gra rozpakowuje się przed rozpoczęciem przewijania, nie wykonuje rozpakowywania na bieżąco. Czas ładowania jest w porządku. Z mojego wrażenia, pomimo barier językowych, to sprzęt jest problemem, a nie algorytm. Gra działa w ten sposób, że najpierw rozpakowuje wszystko dla danego poziomu do RAM, a dopiero potem rozpoczyna przewijanie.
I ponownie - dla Pistorm i Vampire prędkość przewijania jest absolutnie w porządku. Dla wolniejszego sprzętu wysiłek, aby uzyskać jakiekolwiek przyspieszenia, byłby niezwykle duży i niepewny, czy nawet wtedy efekt byłby na tyle znaczący, aby był wart tego wysiłku.
Ostatnia aktualizacja: 02.07.2024 20:57:20 przez MagicSN
I ponownie - dla Pistorm i Vampire prędkość przewijania jest absolutnie w porządku. Dla wolniejszego sprzętu wysiłek, aby uzyskać jakiekolwiek przyspieszenia, byłby niezwykle duży i niepewny, czy nawet wtedy efekt byłby na tyle znaczący, aby był wart tego wysiłku.
Ostatnia aktualizacja: 02.07.2024 20:57:20 przez MagicSN
02.07.2024 21:00
[#79]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@BULI, post #75
Includy nie są problemem. Wersja 2.95.3 z Aminetu zawiesza się podczas linkowania na OS4.1 (wewnątrz emulacji 68k w OS4). mos2wos próbowałem, ale nie na OS4.1, próbowałem to pod cygwinem i pojawiły się błędy podczas budowania binutils (z komunikatami o błędach, których nie rozumiałem).
02.07.2024 23:12
[#80]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@MagicSN, post #63
Ale jakie sprajty? Jakie potęgi liczby 2? Rzuciłem okiem na gameplay i widzę, że tła to faktycznie izometryczne obrazki 2D, ale postaci to bardzo proste obiekty 3D z teksturami. Prosty akcelerator typu BVision3D albo Voodoo3 zrobiłby z tego 30 fps w każdym momencie. 
Assembler tutaj nic nie zmieni, to nie A500 1MB i nie tego typu optymalizacji tutaj trzeba.
Masz rację, że grafiki tutaj jest sporo (pewnie dlatego zdecydowano się na 16-bit) i więcej pamięci graficznej by się przydało żeby nie przewalać jej za dużo w locie z RAM do VRAM. Nie wydaje mi się żeby te obrazki były dekompresowane w locie. Nawet na przeciętnym pececie z dnia premiery gry nie byłoby to możliwe (ani potrzebne).
Ostatnia aktualizacja: 02.07.2024 23:13:44 przez MDW
Assembler tutaj nic nie zmieni, to nie A500 1MB i nie tego typu optymalizacji tutaj trzeba. Masz rację, że grafiki tutaj jest sporo (pewnie dlatego zdecydowano się na 16-bit) i więcej pamięci graficznej by się przydało żeby nie przewalać jej za dużo w locie z RAM do VRAM. Nie wydaje mi się żeby te obrazki były dekompresowane w locie. Nawet na przeciętnym pececie z dnia premiery gry nie byłoby to możliwe (ani potrzebne).
Ostatnia aktualizacja: 02.07.2024 23:13:44 przez MDW
03.07.2024 16:03
[#81]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@MDW, post #80
Gra wewnętrznie używa terminu 'sprite' bardzo luźno dla poruszających się obiektów, takich jak stworzenia 3D i podobne, i te wykorzystują wiele operacji kopiowania, które w sposób, w jaki są wykonywane (małe operacje kopiowania), w optymalizacji nie przyniosą dużo dodatkowej prędkości - przynajmniej tak długo, jak nie zrezygnujesz z całej koncepcji i nie zaimplementujesz jej od nowa. Ale jak już mówiłem - gra działa dobrze na Vampire i PiStorm. I tak, gra nie rozpakowuje się na bieżąco. Ładuje wszystko na początku, a potem zaczyna wyświetlać. Na systemie PiStorm cały poziom ładuje się w około 15 sekund, co jest idealne. Nawet na Vampire czas ładowania wynoszący 45 sekund uważam za akceptowalny.
04.07.2024 16:04
[#85]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@BULI, post #84
To nie do końca prawda. Heretic2 68k zawiera renderer MiniGL, problem polega tylko na tym, że do tej pory nie istnieje żaden sterownik sprzętowy 3D dla PiStorm lub V4. Trwają prace nad sterownikiem dla PiStorm - początkowo tylko dla Pi3 - i jak tylko ten zacznie działać, Heretic2 będzie go obsługiwać, nie będzie potrzebna żadna aktualizacja gry. Jeśli chodzi o V4, jest obecnie zbyt wolny, aby uruchomić Heretic2, zarówno sprzętowo, jak i programowo. Osiągasz około 25 klatek na sekundę w rozdzielczości 640x480 na PiStorm Cm4 o częstotliwości 2,2 GHz (albo 20 klatek na sekundę w rozdzielczości 800x600), około 16 klatek na sekundę na Pi3 w rozdzielczości 480x270 (znacznie lepsze wyniki, jeśli podkręcisz go do 1,8 GHz) i około 8 klatek na sekundę na V4 w rozdzielczości 320x240. Niestety, Maggie brakuje funkcji, aby być pomocna dla Heretic2 i prawdopodobnie nawet jeśli by obsługiwała wszystko, co potrzebne, potrzebna byłaby specjalna wersja MiniGL z AMMX, aby gra działała wystarczająco szybko na V4. Heretic2 był testowany z Warp3D.library Paraj - który używa pewnych sztuczek z shaderami, ale nie jest prawdziwym sterownikiem 3D, działa już szybciej niż Wazp3D, ale wciąż wolniej niż rendering programowy. Osobiście uważam, że ostatecznie pojawi się sterownik 3D HW dla PiStorm. Jeśli chodzi o V4, wiem, że autor Wazp3D pracuje nad mieszanym sterownikiem Wazp3D Software z pewnym wykorzystaniem Maggie, ale nie nad pełnym sterownikiem opartym na Maggie - co nie jest możliwe ze względu na brakujące funkcje, takie jak tryby mieszania i TexEnv - nie wiem, jaką prędkość zyska to mieszane podejście, musimy poczekać i zobaczyć. Tak czy inaczej, w kodzie gry zarówno Heretic2, jak i moja nowa wersja Quake 2 mają wsparcie dla 3D HW - Sin 68k jeszcze tego nie ma, ale Sin 68k jest wciąż na bardzo wczesnym etapie.
Renderowanie programowe w H2 również obsługuje opcjonalne filtrowanie bilinearne, które wygląda prawie tak dobrze, jak renderowanie sprzętowe 3D. Jednak znacznie obniża wydajność, więc większość osób prawdopodobnie będzie grać bez filtrowania bilinealnego. Uważam, że filtrowanie bilinearne jest warte uwagi tylko na Cm4.
Ostatnia aktualizacja: 04.07.2024 16:06:51 przez MagicSN
Renderowanie programowe w H2 również obsługuje opcjonalne filtrowanie bilinearne, które wygląda prawie tak dobrze, jak renderowanie sprzętowe 3D. Jednak znacznie obniża wydajność, więc większość osób prawdopodobnie będzie grać bez filtrowania bilinealnego. Uważam, że filtrowanie bilinearne jest warte uwagi tylko na Cm4.
Ostatnia aktualizacja: 04.07.2024 16:06:51 przez MagicSN
04.07.2024 17:11
[#86]
Re: Gorky 17 - AmigaOS 3.x (68k) + AmigaOS 4 (PPC)
@MagicSN, post #85
Renderowanie programowe w H2 również obsługuje opcjonalne filtrowanie bilinearne, które wygląda prawie tak dobrze, jak renderowanie sprzętowe 3D. Jednak znacznie obniża wydajność
Mnie to wcale nie dziwi. Wygładzanie bez sprzętowego wsparcia zarżnęłoby chyba każdą platformę i byłoby odczuwalne nawet na dzisiejszych procesorach.
