Komentowana treść: Dokumentacja chipsetu AAA
30.04.2023 19:10
[#124]
Re: Dokumentacja chipsetu AAA
@Hexmage960, post #113
"Ja widziałem gry z 1996 roku. Przykładowo "Z""
Ja też widziałem gry z 1996, ot taki quake 1 chociażby który na dzień dobry pozwala na wybranie nawet 1280x1024 z menu opcji graficznych ( mówię o .exe z 1996 a nie dzisiejszych sourceportach)
Widziałem też duke nukem 3d ) który pozwala na ustawienie nawet 1600x1200 ( mówię o .exe z 1996 a nie dzisiejszych sourceportach)
Widziałem też descent 2 (800x600 z opcji graficznych) i nawet 1280x1024 po dopisaniu komendy -superhires w linii poleceń do exe
I to nie są wszystkie gry z 1996 które pozwalają mieć więcej niż 640x480
Ja też widziałem gry z 1996, ot taki quake 1 chociażby który na dzień dobry pozwala na wybranie nawet 1280x1024 z menu opcji graficznych ( mówię o .exe z 1996 a nie dzisiejszych sourceportach)
Widziałem też duke nukem 3d ) który pozwala na ustawienie nawet 1600x1200 ( mówię o .exe z 1996 a nie dzisiejszych sourceportach)
Widziałem też descent 2 (800x600 z opcji graficznych) i nawet 1280x1024 po dopisaniu komendy -superhires w linii poleceń do exe
I to nie są wszystkie gry z 1996 które pozwalają mieć więcej niż 640x480
30.04.2023 20:03
[#125]
Re: Dokumentacja chipsetu AAA
@ligant, post #124
Ja też widziałem gry z 1996, ot taki quake 1 chociażby który na dzień dobry pozwala na wybranie nawet 1280x1024 z menu opcji graficznych ( mówię o .exe z 1996 a nie dzisiejszych sourceportach)
Jesteś pewien, że w 1996 miałeś to w tej rozdzielczości? Musiałeś mieć OpenGL. Na słabym PC chodziło to w software. Dopiero Quake 2 później dostał obsługę OpenGL, żeby mieć 24-bitowe tekstury i wysoką rozdzielczość.
1600x1200 też? Ja pracuję w tej chwili (2023 rok) na monitorze co wyświetla 1280x1024 w 24-bitach (bo nie mam panoramicznego).
@AmiClassic
To musiało być więcej wersji. Ja uruchamiałem z tego co pamiętam z ikonki Windows a nie z Norton Commandera. Ale nie grałem w "Z" u siebie tylko na komputerze kogoś z rodziny.
Ostatnia aktualizacja: 30.04.2023 20:06:14 przez Hexmage960
30.04.2023 20:21
[#126]
Re: Dokumentacja chipsetu AAA
@Hexmage960, post #125
co mnie obchodzi jak to działało... Pozwala na wybranie więcej niż 640x480 czy nie? Czy mam robić screeny z menu?
A monitory crt potrafiące wyświetlić 1600x1200 to były możliwe do kupienia na długo przed 1996 rokiem. To że były drogie nie ma znaczenia w tej dyskusji.
A monitory crt potrafiące wyświetlić 1600x1200 to były możliwe do kupienia na długo przed 1996 rokiem. To że były drogie nie ma znaczenia w tej dyskusji.
30.04.2023 21:22
[#127]
Re: Dokumentacja chipsetu AAA
@Phibrizzo, post #74
Właśnie, w latach 90 tych na początku jak wyszedł DOOM na PC największym problemem Amigi było stawiania pixeli pojedynczo przez procesor. Gry 3D praktycznie bez akceleratora sprzętowego liczą każdy pixel z osobna i każdy pixel osobno jest zapalany na ekranie i wtedy samo postawienia pixela trwało ~2 cykle zegara, jedno MOV al,ds:[ebx]. natomiast na Amidze był problem bo trzeba było wykonać zapis do pamięci tyle razy ile bitplanów było i do tego dochodziło maskowanie bo każdy bajt bitplanu przedstawiał 8 pixeli....
Dlatego tak opornie wychodziło robienie teksturowanych gier 3D na Amidze, a na PC problemem było tylko ogarnięcie szybkiego algorytmu 3D.... później dopiero wychodziły "blitery" na PC co liczyły wektory i takie tam ... :)
Dlatego tak opornie wychodziło robienie teksturowanych gier 3D na Amidze, a na PC problemem było tylko ogarnięcie szybkiego algorytmu 3D.... później dopiero wychodziły "blitery" na PC co liczyły wektory i takie tam ... :)
30.04.2023 21:42
[#129]
Re: Dokumentacja chipsetu AAA
@xbary, post #127
Ale ja sie z Toba absolutnie zgadzam i nikt nie moze zaprzeczyc ze tak nie bylo (a nawet jest).
Tyle tylko ze gdyby tylko c2p byl robiony przez Akiko drogami DMA z pelnym dostepem do pamieci
CHIP i to bez udzialu procesora to pal licho juz brak trybow chunky. I pewnie DOOM by chodzil znosnie na 020.
A tak to jednynie co jest to to ze jest.
Obecnie koderzy znajac ograniczenia sami obeszli ten problem stosujac programowe c2p ktore az tak nie "boli".
A jak wykazaly testy (podobno) to na 030 Akiko juz nie spelnia swojej roli.
Ostatnia aktualizacja: 30.04.2023 21:42:52 przez Phibrizzo
Tyle tylko ze gdyby tylko c2p byl robiony przez Akiko drogami DMA z pelnym dostepem do pamieci
CHIP i to bez udzialu procesora to pal licho juz brak trybow chunky. I pewnie DOOM by chodzil znosnie na 020.
A tak to jednynie co jest to to ze jest.
Obecnie koderzy znajac ograniczenia sami obeszli ten problem stosujac programowe c2p ktore az tak nie "boli".
A jak wykazaly testy (podobno) to na 030 Akiko juz nie spelnia swojej roli.
Ostatnia aktualizacja: 30.04.2023 21:42:52 przez Phibrizzo
30.04.2023 21:52
[#130]
Re: Dokumentacja chipsetu AAA
@SzaryWilk, post #128
Gdyby , no właśnie gdyby do AGA dodali jeszcze jedną funkcjonalność i DOOM też by powstał na Amidze. Myślę że dodatkowa funkcjonalność DMA by załatwiła sprawę, bym to tak zrobił:
- w pamięci FAST w formie bajt=indeks koloru procesor by stawiał pixele
- następnie uruchamiało by się przez DMA i odpowiednio skonfigurowane rejestry że przerzucone by były pixele bajtowe do pamięci chip na formę bitplanową...
- podczas tej konwersji sprzętowej procesor mógłby szykować kolejną klatkę obrazu gry
Myślę że by to znacznie przyspieszyło generowanie obrazu 3D teksturowanego, o jeśli chodzi o algorytmy to my Amigowcy już wiemy jak wycisnąć z motorolki ostatnie poty :)
- w pamięci FAST w formie bajt=indeks koloru procesor by stawiał pixele
- następnie uruchamiało by się przez DMA i odpowiednio skonfigurowane rejestry że przerzucone by były pixele bajtowe do pamięci chip na formę bitplanową...
- podczas tej konwersji sprzętowej procesor mógłby szykować kolejną klatkę obrazu gry
Myślę że by to znacznie przyspieszyło generowanie obrazu 3D teksturowanego, o jeśli chodzi o algorytmy to my Amigowcy już wiemy jak wycisnąć z motorolki ostatnie poty :)
30.04.2023 22:29
[#131]
Re: Dokumentacja chipsetu AAA
@abcdef, post #107
Nie wiem, ale się wypowiem: akceleracja taka jak na Amidze nie była potrzebna w grach DOS jak miałeś albo b. szybką pamięć w buforze ramki (jak w kartach Tseng Labs, które to nie były do jakiegoś momentu akceleratorami, tylko samymi buforami ramki, zresztą b. szybkimi buforami ramki); albo jak już poszedłeś w VLB/PCI (wtedy to już były kółeczka wokół AGA - wielokrotnie szybszy transfer DMA BUS Mastering w 32-bitowym slocie z 64-bitowym chipem i 64-bitowym dostępem do pamięci DRAM EDO/FPM albo VRAM, do tego niespowalniającym procesor jak w AGAcie, a jak karta miała miejsce, to mogłeś jeszcze przyspieszyć pamięć dokupując kostki z szybszym czasem dostępu). A po '95 to i tak wszystko szło w akcelerowane okienka (Win 95 z WinG i DirectX), a tu już był full wypas, nie licząc już nawet Pentiumów, MMX-ów etc. Do tego rozszerzenia VESA rzeczywiście normalnie nie wspierały (a raczej do 1996. roku, jak już nikogo to) akceleracji pod DOS (a pod Win to już inna bajka, patrz wyżej), ale to zależało raczej od danej implementacji standardu przez producenta karty co i jak to było pod spodem liczone, zresztą jak karta była popularna (S3), to dobry programista zawsze mógł sam jeździć bezpośrednio po rejestrach karty i sobie taką akcelerację zrobić (oczywiście jak taka karta obsługiwała akcelerację albo była koprocesorem). Patrz: zupełnie jak z amigowym Copperem - mało kto używał, a szkoda.
Amigowy Blitter to też nie był taki cud malina - na A1200 w trybie 256 kolorów full screen i w rozdziałce ~PC-towe SVGA to można zapomnieć o słynnych, amigowych 50fps, a mówimy tu o platformówkach i chipsecie do czterech razy szybszym od ECS (nie licząc A3000). W grę wchodzą tylko statyczne obrazki albo małe okienka. Zresztą Theme Park, Syndicate, Sim City i Sim City 2000, Harpoon chodzą na Ami w lo-res i wolno, a na PC DOS w hi-res. I co tu porównywać do konsol 32. bitowych, które odtwarzały filmy w 32. tys. kolorów bez przystawki MPEG, i robiły niezłe 3D samym tylko procesorem (3DO). Jaguar ze swoimi skromnymi możliwościami 3D renderował sprawnie DOOMa, a Rayman z dziesiątkami tysięcy kolorów wyglądał ostrzej i miał więcej detali, niż jakakolwiek wersja, licząc tą z PSX, ale to taki off top.
Co do AAA, IMHO pewnie to też żadna rewelacja, i Commodore przyoszczędziło - mówimy tu o firmie, która nie dała nawet prawdziwego, buforowanego portu Serial i Parallel, gęstej stację dyskietek (dopiero w A3000) i która sprzedawała A1200 i CD32 bez nawet 128. kilobajtowego Fastu, czyli obcinała z automatu już i tak skromną moc komputera/konsoli o połowę.
Ostatnia aktualizacja: 30.04.2023 22:47:25 przez freak_outXP
Amigowy Blitter to też nie był taki cud malina - na A1200 w trybie 256 kolorów full screen i w rozdziałce ~PC-towe SVGA to można zapomnieć o słynnych, amigowych 50fps, a mówimy tu o platformówkach i chipsecie do czterech razy szybszym od ECS (nie licząc A3000). W grę wchodzą tylko statyczne obrazki albo małe okienka. Zresztą Theme Park, Syndicate, Sim City i Sim City 2000, Harpoon chodzą na Ami w lo-res i wolno, a na PC DOS w hi-res. I co tu porównywać do konsol 32. bitowych, które odtwarzały filmy w 32. tys. kolorów bez przystawki MPEG, i robiły niezłe 3D samym tylko procesorem (3DO). Jaguar ze swoimi skromnymi możliwościami 3D renderował sprawnie DOOMa, a Rayman z dziesiątkami tysięcy kolorów wyglądał ostrzej i miał więcej detali, niż jakakolwiek wersja, licząc tą z PSX, ale to taki off top.
Co do AAA, IMHO pewnie to też żadna rewelacja, i Commodore przyoszczędziło - mówimy tu o firmie, która nie dała nawet prawdziwego, buforowanego portu Serial i Parallel, gęstej stację dyskietek (dopiero w A3000) i która sprzedawała A1200 i CD32 bez nawet 128. kilobajtowego Fastu, czyli obcinała z automatu już i tak skromną moc komputera/konsoli o połowę.
Ostatnia aktualizacja: 30.04.2023 22:47:25 przez freak_outXP
30.04.2023 23:13
[#133]
Re: Dokumentacja chipsetu AAA
@freak_outXP, post #131
Commodore przyoszczędziło - (...) sprzedawała A1200 i CD32 bez nawet 128. kilobajtowego Fastu, czyli obcinała z automatu już i tak skromną moc komputera/konsoli o połowę.
Gdyby chociaż dali na płycie slot pod standardowego 72 pin SIMMa... A tak Amigowcom 4mb FAST sprzedawano 4x drożej niż kosztowały kosci SIMM dla PC.
01.05.2023 08:18
[#139]
Re: Dokumentacja chipsetu AAA
@amikoksu, post #138
93 to prawie tak samo w połowie jak A1200. Prawie robi różnicę. Doom w skrojonej wersji został wydany nawet na SNESa. A na Amigę nie zdążył, w żadnej. Są tylko porty na uwolnionych źródłach. I nie, wcale nie chodzi by robić programistyczną ekwilibrystykę żeby tylko działało. A wydawanie na A4000 gry to byłaby największa głupota... totalna nisza, bo A4000 użytkowników było mało. Dużo to było Amigowców ogółem, ale znacząca większość miała... A500
01.05.2023 10:53
[#143]
Re: Dokumentacja chipsetu AAA
@freak_outXP, post #131
Błędem było zastosowanie zamkniętej architektury i budowanie Amigi jak konsoli, synchronizacja i później nawet dołożenie czegoś szybszego - procka, nie dawała tyle ile mogłaby. Mnie ciekawi jak do MMX ma się taki DSP 96000, czy pomogłoby w 3D?
Dlaczego Vampir nie ma DSP 96000 skoro to koszerne Motoroli tylko AMMX. A Altivec byłby bardziej nasz.
Dlaczego Vampir nie ma DSP 96000 skoro to koszerne Motoroli tylko AMMX. A Altivec byłby bardziej nasz.
01.05.2023 11:25
[#144]
Re: Dokumentacja chipsetu AAA
@amikoksu, post #137
Na 286 nie pójdzie, a wg. Mobygames potrzeba minimum Amigi 1200 z 4MB, czyli 2MB Fastu, i twardy dysk, czyli na wstępie masz 2 razy szybszą Amigę 1200, zapewne IMO twardy też coś daje (nie musisz dbać np. o dekompresję danych z dyskietki FD, bo masz wszystko na HDD). Zresztą tam i tak nie masz 50fps w 256 kolorach fullscreen - pamiętam, że na podobnej konfiguracji po paru godzinach gry jest ona niegrywalna, przynajmniej bez patcha.
Blitter - na moją logikę, bez wchodzenia w technikalia - nie może tak samo szybko (wolno) działać jak w Ax00, nawet jak jest dokładnie taki sam, ponieważ masz w AGA dwa razy szybszą pamięć Chip (nawet dla dostępu 16. bitowego takiego jak w starych Ami), czyli IMO coś tam przyspiesza, nawet jeżeli to nie jest x2 i x4. Ale zara pewnie ktoś zacznie liczyć cykle procesora i sloty DMA, i to obali ;) Może ktoś z szanownych Amigowiczów uruchomi Desert Strike na Amidze 600, potem 1200 bez Fastu i z Fastem (najlepiej NTSC) i sprawdzi, czy w grze są charakterystyczne spowolnienia na każdej z nich (na SMD i SNES wszystko działa cacy cały czas).
Apropo - to tylko potwierdza moje słowa, że nie wszystko było w Amidze "przezroczyste" i "automatycznie używalne" (Copper!) - programista gry Cytadela w wywiadzie dla PPA coś tam wspominał, że intro dla każdej z Amig (tj. dla prawie każdego modelu + chyba jedna czy dwie najpopularniejsze rozszerzenia) trzeba było synchronizować oddzielnie, i nie zawsze wynik był identyczny. IMO dlatego właśnie Amiga jako system komputerowy ze sobą w jakiś sposób kompatybilny, a nie konsolowy, w którym każda nowa iteracja raczej nie jest kompatybilna z poprzednią, nie mógł przetrwać, nawet jakby w A1200 były bebechy od Jaguara i 3do jednocześnie - za dużo jebania się, bo kodowanie (nie - programowanie!) polegało na perfekcyjnej znajomości sprzętu, najlepiej czterech konfiguracji jednocześnie (A ECS 1MB kik 1.3, A1200 bez Fastu, z Fastem, CD32) oraz sztuczkach, króczkach, optymalizacjach, albo efekty były takie se (gry Sierry). IMO to było nawet, nawet jak miałeś proste gierki, to wtedy jeden programista (+grafik +muzyk) ogarniał wszystko, ale dla kilku... grzebanie w tak konstruowanym kodzie programu to była podatna na błędy mordęga. Inna rzecz to brak ochrony pamięci...
Tak czy siak AAA niewiele by zmieniło z w.w. powodów...
Ostatnia aktualizacja: 01.05.2023 11:31:48 przez freak_outXP
Blitter - na moją logikę, bez wchodzenia w technikalia - nie może tak samo szybko (wolno) działać jak w Ax00, nawet jak jest dokładnie taki sam, ponieważ masz w AGA dwa razy szybszą pamięć Chip (nawet dla dostępu 16. bitowego takiego jak w starych Ami), czyli IMO coś tam przyspiesza, nawet jeżeli to nie jest x2 i x4. Ale zara pewnie ktoś zacznie liczyć cykle procesora i sloty DMA, i to obali ;) Może ktoś z szanownych Amigowiczów uruchomi Desert Strike na Amidze 600, potem 1200 bez Fastu i z Fastem (najlepiej NTSC) i sprawdzi, czy w grze są charakterystyczne spowolnienia na każdej z nich (na SMD i SNES wszystko działa cacy cały czas).
Apropo - to tylko potwierdza moje słowa, że nie wszystko było w Amidze "przezroczyste" i "automatycznie używalne" (Copper!) - programista gry Cytadela w wywiadzie dla PPA coś tam wspominał, że intro dla każdej z Amig (tj. dla prawie każdego modelu + chyba jedna czy dwie najpopularniejsze rozszerzenia) trzeba było synchronizować oddzielnie, i nie zawsze wynik był identyczny. IMO dlatego właśnie Amiga jako system komputerowy ze sobą w jakiś sposób kompatybilny, a nie konsolowy, w którym każda nowa iteracja raczej nie jest kompatybilna z poprzednią, nie mógł przetrwać, nawet jakby w A1200 były bebechy od Jaguara i 3do jednocześnie - za dużo jebania się, bo kodowanie (nie - programowanie!) polegało na perfekcyjnej znajomości sprzętu, najlepiej czterech konfiguracji jednocześnie (A ECS 1MB kik 1.3, A1200 bez Fastu, z Fastem, CD32) oraz sztuczkach, króczkach, optymalizacjach, albo efekty były takie se (gry Sierry). IMO to było nawet, nawet jak miałeś proste gierki, to wtedy jeden programista (+grafik +muzyk) ogarniał wszystko, ale dla kilku... grzebanie w tak konstruowanym kodzie programu to była podatna na błędy mordęga. Inna rzecz to brak ochrony pamięci...
Tak czy siak AAA niewiele by zmieniło z w.w. powodów...
Ostatnia aktualizacja: 01.05.2023 11:31:48 przez freak_outXP
01.05.2023 12:01
[#146]
Re: Dokumentacja chipsetu AAA
@teh_KaiN, post #145
Jeśli chodzi o FMODE, to on jest domyślnie włączany tylko gdy jest wyższa rozdzielczość i głębia barw i o tej sytuacji tu mówię. Blitter wtedy musi przesłać więcej danych.
Workbench w 640x256 w 4 kolorach na A1200 działa szybciej od analogicznego WB na Amidze CDTV. Z Workbenchem 640x256 w 16 kolorach jest podobnie.
Poza tym gry w 320x256 w 256 kolorach potrzebują szybszego Blittera, żeby działać tak samo szybko jak gry w 32 kolorach na A500/CDTV.
FMODE 2x jest potrzebny dopiero przy 640x256 dla 5-8 bitplanów. A wtedy Blitter musi przekopiować do 2x więcej danych.
FMODE 4x jest potrzebny dopiero przy 1280x256 dla 5-8 bitplanów. A wtedy Blitter musi przekopiować do 4x więcej danych.
Innymi słowy FMODE gwarantuje możliwość wyświetlenia tych rozdzielczości, które są bardziej wymagające włączając odpowiedni tryb pobierania danych.
Są gry tylko dla AGA bazujące na Blitterze takie jak Worms: The Director's Cut, All New World of Lemmings, Whizz, Slam Tilt.
Podobnie programy tylko dla AGA jak Photogenics, czy Deluxe Paint V. A programy typu Organiser, DataStore, WordWorth działają lepiej.
Sam programując własne gry widzę, że Blitter w AGA działa szybciej. A nic nie zmieniam w FMODE.
AGA to nie tylko 4x szersza szyna danych. To też paleta 24-bit, 256 kolorów, HAM8, lepszy procesor, lepsza pamięć CHIP i większe możliwości rozbudowy.
@AmiClassic
Dziękuję za informację. Sam mało korzystałem z MS-DOS i Windows 95, bo jednak byłem fanem Amigi. Ale zapoznałem się z "konkurencją" i nigdy nie odrzucałem innych rozwiązań. Dla przykładu Goblins 1 na PC był świetny.
Ostatnia aktualizacja: 01.05.2023 12:17:17 przez Hexmage960
Workbench w 640x256 w 4 kolorach na A1200 działa szybciej od analogicznego WB na Amidze CDTV. Z Workbenchem 640x256 w 16 kolorach jest podobnie.
Poza tym gry w 320x256 w 256 kolorach potrzebują szybszego Blittera, żeby działać tak samo szybko jak gry w 32 kolorach na A500/CDTV.
FMODE 2x jest potrzebny dopiero przy 640x256 dla 5-8 bitplanów. A wtedy Blitter musi przekopiować do 2x więcej danych.
FMODE 4x jest potrzebny dopiero przy 1280x256 dla 5-8 bitplanów. A wtedy Blitter musi przekopiować do 4x więcej danych.
Innymi słowy FMODE gwarantuje możliwość wyświetlenia tych rozdzielczości, które są bardziej wymagające włączając odpowiedni tryb pobierania danych.
Są gry tylko dla AGA bazujące na Blitterze takie jak Worms: The Director's Cut, All New World of Lemmings, Whizz, Slam Tilt.
Podobnie programy tylko dla AGA jak Photogenics, czy Deluxe Paint V. A programy typu Organiser, DataStore, WordWorth działają lepiej.
Sam programując własne gry widzę, że Blitter w AGA działa szybciej. A nic nie zmieniam w FMODE.
AGA to nie tylko 4x szersza szyna danych. To też paleta 24-bit, 256 kolorów, HAM8, lepszy procesor, lepsza pamięć CHIP i większe możliwości rozbudowy.
@AmiClassic
Dziękuję za informację. Sam mało korzystałem z MS-DOS i Windows 95, bo jednak byłem fanem Amigi. Ale zapoznałem się z "konkurencją" i nigdy nie odrzucałem innych rozwiązań. Dla przykładu Goblins 1 na PC był świetny.
Ostatnia aktualizacja: 01.05.2023 12:17:17 przez Hexmage960
01.05.2023 15:05
[#149]
Re: Dokumentacja chipsetu AAA
@teh_KaiN, post #148
Ciekawa sprawa, ponieważ copperlista systemowa ustawia FMODE na wartość 0x0003. Sprawdziłem na ekranie 320x256, 640x256 w 4, 16 i 256 kolorach. Jednakże zmiana FMODE na 0x0000 w copperliście powoduje błędne wyświetlanie obrazu (również w 320x256).
Druga sprawa to, że zgodnie z oczekiwaniem ekran 640x256 w 5-8 bitplanach wymaga dosunięcia bitmap do 32-bit. Niższe rozdzielczości zadowolą się dosunięciem do 16-bit.
Myślałem, że konsekwencją wyższego poboru jest to, że są większe restrykcje co do dosunięcia bitmap.
Póki co wygląda to tak, że lepiej zostawić systemowi te ustawienia, dla lepszej kompatybilności.
Ostatnia aktualizacja: 01.05.2023 15:07:49 przez Hexmage960
Druga sprawa to, że zgodnie z oczekiwaniem ekran 640x256 w 5-8 bitplanach wymaga dosunięcia bitmap do 32-bit. Niższe rozdzielczości zadowolą się dosunięciem do 16-bit.
Myślałem, że konsekwencją wyższego poboru jest to, że są większe restrykcje co do dosunięcia bitmap.
Póki co wygląda to tak, że lepiej zostawić systemowi te ustawienia, dla lepszej kompatybilności.
Ostatnia aktualizacja: 01.05.2023 15:07:49 przez Hexmage960