23.02.2023 21:39
[#61]
Re: Quake w HAM6 na A500
@mateusz_s, post #59
1280x256 wydaje mi się że ta rozdzielczość jest po to żeby ukryć wszelkie niedogodności ham8(rampy i takie cuda) i działa to w miarę szybko.
Przypuszczam że na OCS w 320x200 należy użyć jakiegoś specjalnego HAM'skiego ditheringu aby gra działała w 1x1 i tu potrzebny jest ExtraPower, bo nie da się na OCS wyświetlić Ham6 w innych rozdzielczościach niż Lowres i Laced- zresztą koledzy przede mną już o tym wspominali. Sam filmik wygląda świetnie... i ktoś kto zaimplementował ten Ham6 zrobił fajną robotę.
Ale sobie gdybam jako dyletant.
Przypuszczam że na OCS w 320x200 należy użyć jakiegoś specjalnego HAM'skiego ditheringu aby gra działała w 1x1 i tu potrzebny jest ExtraPower, bo nie da się na OCS wyświetlić Ham6 w innych rozdzielczościach niż Lowres i Laced- zresztą koledzy przede mną już o tym wspominali. Sam filmik wygląda świetnie... i ktoś kto zaimplementował ten Ham6 zrobił fajną robotę.
Ale sobie gdybam jako dyletant.
23.02.2023 22:59
[#64]
Re: Quake w HAM6 na A500
@mateusz_s, post #62
HAM8 ma dużą zaletę w postaci palety 64-kolorowej, które możemy precyzyjnie ustalić i nie podlegają trybowi Hold-And-Modify (w HAM6 jest 16 takich kolorów).
Pozostałe 64*3 kolory są używane do kodowania jednej z wartości RGB. Każdy piksel może ustawić jedną składową. Pozostałe dwie składowe są dziedziczone z lewego sąsiada.
W trybie HAM8 można wykorzystać te 64 stałych kolorów kiedy potrzebujemy zastąpić jakiś kolor piksela RGB jego odpowiednikiem nie podlegającym trybowi HAM, by nie mieć rampy.
Przykład wykorzystania: Dla obiektów możemy narysować dowolny stały kolor z prawej strony obiektu.
Ale dla tła, na który nanosimy obiekt, tego koloru nie możemy określić, bo nie wiadomo w którym miejscu łączy się z obiektem. Dlatego możemy wyszukać lub zaalokować kolor z 64-kolorowej palety.
Zauważmy, że HAM8 może stanowić uzupełnienie trybu 64-kolorowego o piksele HAM. Nie ma przymusu korzystać z pikseli Hold-And-Modify. Podobnie HAM6 może stanowić uzupełnienie trybu 16-kolorowego.
Ale oczywiście narzut się zwiększa, bo tryb jest bardziej wymagający, ale danych graficznych jest dokładnie tyle samo co 64 kolory lub 16 kolorów.
Ostatnia aktualizacja: 23.02.2023 23:03:52 przez Hexmage960
Pozostałe 64*3 kolory są używane do kodowania jednej z wartości RGB. Każdy piksel może ustawić jedną składową. Pozostałe dwie składowe są dziedziczone z lewego sąsiada.
W trybie HAM8 można wykorzystać te 64 stałych kolorów kiedy potrzebujemy zastąpić jakiś kolor piksela RGB jego odpowiednikiem nie podlegającym trybowi HAM, by nie mieć rampy.
Przykład wykorzystania: Dla obiektów możemy narysować dowolny stały kolor z prawej strony obiektu.
Ale dla tła, na który nanosimy obiekt, tego koloru nie możemy określić, bo nie wiadomo w którym miejscu łączy się z obiektem. Dlatego możemy wyszukać lub zaalokować kolor z 64-kolorowej palety.
Zauważmy, że HAM8 może stanowić uzupełnienie trybu 64-kolorowego o piksele HAM. Nie ma przymusu korzystać z pikseli Hold-And-Modify. Podobnie HAM6 może stanowić uzupełnienie trybu 16-kolorowego.
Ale oczywiście narzut się zwiększa, bo tryb jest bardziej wymagający, ale danych graficznych jest dokładnie tyle samo co 64 kolory lub 16 kolorów.
Ostatnia aktualizacja: 23.02.2023 23:03:52 przez Hexmage960
24.02.2023 10:09
[#65]
Re: Quake w HAM6 na A500
@Hexmage960, post #64
Ale oczywiście narzut się zwiększa, bo tryb jest bardziej wymagający, ale danych graficznych jest dokładnie tyle samo co 64 kolory lub 16 kolorów.
Nie jest tyle samo. Do 64 kolorów potrzeba sześciu bitplanów a do HAM8 ośmiu bitplanów. Do 16 kolorów potrzeba czterech bitplanów a do HAM6 sześciu bitplanów. Nawet jeśli nie używasz pikseli HAM czyli dwóch najstarszych bitplanów to i tak są z nich pobierane dane (zera) i te bitplany obciążają DMA.
Tak na marginesie. Oba tryby można rozszerzyć przez dynamiczną zmianę podstawowej palety (16/64) w trakcie wyświetlania obrazu. Dzięki temu w HAM 6 można mieć paletę podstawowych 16 kolorów inną w każdej linii obrazu.
Ostatnia aktualizacja: 24.02.2023 10:10:29 przez Kefir_Union
24.02.2023 16:05
[#66]
Re: Quake w HAM6 na A500
@selur, post #56
miales Warpa w 98 roku ?
A ty masz rzeczywiście coś z głową? Pokaż no gdzie ja pisałem powyższe?
Gwoli wyjaśnienia, przeczytaj post #52. Najlepiej ze trzy razy dla zapamiętania.
I co? Tabletek nie wziąłeś czy okularów zapomniałeś?
Gwoli wyjaśnienia. miałem Blizzard PPC.
Ostatnia aktualizacja: 24.02.2023 16:24:22 przez Solo Kazuki
24.02.2023 18:58
[#69]
Re: Quake w HAM6 na A500
@Kefir_Union, post #65
Tak na marginesie. Oba tryby można rozszerzyć przez dynamiczną zmianę podstawowej palety (16/64) w trakcie wyświetlania obrazu. Dzięki temu w HAM 6 można mieć paletę podstawowych 16 kolorów inną w każdej linii obrazu.
Czy jest coś więcej do poczytania na ten temat? Czyli jak to się robi, jakie są ograniczenia, czy można gdzieś zobaczyć efekt tej procedury, itp. ?
24.02.2023 20:29
[#70]
Re: Quake w HAM6 na A500
@Kefir_Union, post #65
Dla klarowności:
- Pisząc, że narzut się zwiększa miałem właśnie na myśli to, że HAM6 w stosunku do trybu 16-kolorowego oraz HAM8 w stosunku do trybu 64-kolorowego ma większy narzut.
- Pisząc, że jest tyle samo danych graficznych miałem również właśnie na myśli to, że 64 kolory zajmują 6 bitplanów również w HAM8. Wystarczy kopiować 6 bitplanów oczywiście przy założeniu, że bitplany nr 6 i 7 są wyzerowane - co oznacza, że kolor jest interpretowany jako indeks w palecie, a nie wartość składowej RGB.
Ostatnia aktualizacja: 24.02.2023 20:30:17 przez Hexmage960
- Pisząc, że narzut się zwiększa miałem właśnie na myśli to, że HAM6 w stosunku do trybu 16-kolorowego oraz HAM8 w stosunku do trybu 64-kolorowego ma większy narzut.
- Pisząc, że jest tyle samo danych graficznych miałem również właśnie na myśli to, że 64 kolory zajmują 6 bitplanów również w HAM8. Wystarczy kopiować 6 bitplanów oczywiście przy założeniu, że bitplany nr 6 i 7 są wyzerowane - co oznacza, że kolor jest interpretowany jako indeks w palecie, a nie wartość składowej RGB.
Ostatnia aktualizacja: 24.02.2023 20:30:17 przez Hexmage960
08.03.2023 20:37
[#71]
Re: Quake w HAM6 na A500
@Hexmage960, post #70
Wracam jeszcze do tematu funkcji c20 kalmsa.
Interesują mnie te 4 warianty cp2_4rgb888_
Ale chciałbym wiedzieć czym one się różnią i ewentualnie która jest bardziej/mniej wydajna.
_3rgb555
_3rgb666
_4rgb555
_4rgb666
555 i 666 to chyba docelowa ilość bitów na kanał.
Pewnie i tak będę musiał wszystkie sprawdzić,
Ale może coś podpowiecie.
https://github.com/Kalmalyzer/kalms-c2p/tree/main/ham8
Ostatnia aktualizacja: 08.03.2023 20:37:28 przez mateusz_s
Interesują mnie te 4 warianty cp2_4rgb888_
Ale chciałbym wiedzieć czym one się różnią i ewentualnie która jest bardziej/mniej wydajna.
_3rgb555
_3rgb666
_4rgb555
_4rgb666
555 i 666 to chyba docelowa ilość bitów na kanał.
Pewnie i tak będę musiał wszystkie sprawdzić,
Ale może coś podpowiecie.
https://github.com/Kalmalyzer/kalms-c2p/tree/main/ham8
Ostatnia aktualizacja: 08.03.2023 20:37:28 przez mateusz_s
09.03.2023 10:48
[#73]
Re: Quake w HAM6 na A500
@Kefir_Union, post #72
https://streamable.com/e/ie1fqc
Nowy test na szybko - silnik robi ramkę 320x200 a ekran WB jest 1280x256
nie mogę wyjść z podziwu jak to popierdziela - RTG z 93 roku :)
fakt że V1200 robi swoje szybko ale obraz leci przecież przez AGA i CHIP RAM.
natomiast sam silnik działa bardzo sprawnie już na zwykłym 060 55Mhz.
co prawda to jest HAM8 nie HAM6,
na razie testowałem wersje 4rgb_666, jakość wygląda dobrze,
ale to bardzo ubogi level bez lightmap i textur wiec testy innych rozdzielczosci i algorytmów
trzeba porobić na bardziej dopracowanym poziomie
w porównaniu z poprzdnim testem, tam był dynamiczny distance shading i robiły się takie artefakty przy konwersji HAM8, natomiast w nowym silniku wywaliłem distance shading bo i tam mam light mapy, wiec tylko przeszkadał, ale może to polepszyć jakość i zniwelość te artefakty z poprzedniej wersji..
ps.
Może Ktoś wie jak pozbyć się tej białej ramki? w senie ustawić ją na czarną.
czy to jest kwestia koloru w rejestrze 0 lub 1?
Ostatnia aktualizacja: 09.03.2023 10:48:34 przez mateusz_s
Nowy test na szybko - silnik robi ramkę 320x200 a ekran WB jest 1280x256
nie mogę wyjść z podziwu jak to popierdziela - RTG z 93 roku :)
fakt że V1200 robi swoje szybko ale obraz leci przecież przez AGA i CHIP RAM.
natomiast sam silnik działa bardzo sprawnie już na zwykłym 060 55Mhz.
co prawda to jest HAM8 nie HAM6,
na razie testowałem wersje 4rgb_666, jakość wygląda dobrze,
ale to bardzo ubogi level bez lightmap i textur wiec testy innych rozdzielczosci i algorytmów
trzeba porobić na bardziej dopracowanym poziomie
w porównaniu z poprzdnim testem, tam był dynamiczny distance shading i robiły się takie artefakty przy konwersji HAM8, natomiast w nowym silniku wywaliłem distance shading bo i tam mam light mapy, wiec tylko przeszkadał, ale może to polepszyć jakość i zniwelość te artefakty z poprzedniej wersji..
ps.
Może Ktoś wie jak pozbyć się tej białej ramki? w senie ustawić ją na czarną.
czy to jest kwestia koloru w rejestrze 0 lub 1?
Ostatnia aktualizacja: 09.03.2023 10:48:34 przez mateusz_s
10.03.2023 00:27
[#80]
Re: Quake w HAM6 na A500
@Phibrizzo, post #79
Mam jeszcze taką zagwozdkę..
Jeśli mój źródłowy bufor 32bit ma 320x256
to jesli otworzę to w oknie WB 1280x256
to wszytko jest tak jak należy.
Czyli szerokość wielkość okna WB musi być 4x wieksza..
Jednak, kiedy moim żródłowym buforem jest 160x256
i otworzę okno WB 640x256 to niestety obraz jest rozciągnięty.
Coś robię, źle czy po prostu się nie da?
Czy może te funkcje Kalmsa tak już działają?
Pytam, bo gdy tak zrobiłem, czyli
przeniosłem zrodlowy bufor 160x256 do okna HAM8 640x256
To była pięknie przyzwoita prędkość ~30fps totalnie płynnie grywalna
przy nienajgorszej jakości,
no i trochę szkoda..
Jeśli mój źródłowy bufor 32bit ma 320x256
to jesli otworzę to w oknie WB 1280x256
to wszytko jest tak jak należy.
Czyli szerokość wielkość okna WB musi być 4x wieksza..
Jednak, kiedy moim żródłowym buforem jest 160x256
i otworzę okno WB 640x256 to niestety obraz jest rozciągnięty.
Coś robię, źle czy po prostu się nie da?
Czy może te funkcje Kalmsa tak już działają?
Pytam, bo gdy tak zrobiłem, czyli
przeniosłem zrodlowy bufor 160x256 do okna HAM8 640x256
To była pięknie przyzwoita prędkość ~30fps totalnie płynnie grywalna
przy nienajgorszej jakości,
no i trochę szkoda..
10.03.2023 08:58
[#81]
Re: Quake w HAM6 na A500
@KM_Ender, post #78
Dla mnie takie męczenie A500 przypomina jazdę autem na oleju bez wymiany.
Porównanie zupełnie nietrafne, to bardziej Mercedes W123 "beczka" z silnikiem V10. Olej oczywiście świeży, a że maszyna solidna, to i reszta wytrzymuje
Ostatnia aktualizacja: 10.03.2023 08:59:11 przez Jacques
12.03.2023 15:20
[#82]
Re: Quake w HAM6 na A500
@mateusz_s, post #80
Podbijam jeszcze raz pytanie.
Czy orientujecie się jakie okno WB zostało użyte w tym prz6kladzie Quake HAM6? Na pewno nie 1280x256.
Jak wspomniałem podobna prędkość miałem w okienku 640x256 gdzie źródłowy 32bit bufor był 160x256. Czyli tak samo na 1 pixel 32bit przypadały 4 pixele w ham8.
Jednak obraz był troche rozciągnięty. A w tym quake ham6 widzę że jest ok czyli jednak się da jakoś.
Czy orientujecie się jakie okno WB zostało użyte w tym prz6kladzie Quake HAM6? Na pewno nie 1280x256.
Jak wspomniałem podobna prędkość miałem w okienku 640x256 gdzie źródłowy 32bit bufor był 160x256. Czyli tak samo na 1 pixel 32bit przypadały 4 pixele w ham8.
Jednak obraz był troche rozciągnięty. A w tym quake ham6 widzę że jest ok czyli jednak się da jakoś.
12.03.2023 18:24
[#83]
Re: Quake w HAM6 na A500
@mateusz_s, post #82
https://streamable.com/e9oz5x
Wersja 160x256 na screenie ham8 640x256 z double buffer, 25fps
genaralnie wszystko super, wszsytko sie miesci na ekranie, tylko jakby spłaszczone wszsytko
mysle ze moze tak zostać tobedzie pierwsza opcja - a druga na full 1280x256, jak kto snie ma rtg a ma lepszy cpu to przynajmniej sobie odpali
Ostatnia aktualizacja: 12.03.2023 18:30:09 przez mateusz_s
Wersja 160x256 na screenie ham8 640x256 z double buffer, 25fps
genaralnie wszystko super, wszsytko sie miesci na ekranie, tylko jakby spłaszczone wszsytko
mysle ze moze tak zostać tobedzie pierwsza opcja - a druga na full 1280x256, jak kto snie ma rtg a ma lepszy cpu to przynajmniej sobie odpali
Ostatnia aktualizacja: 12.03.2023 18:30:09 przez mateusz_s
12.03.2023 19:06
[#85]
Re: Quake w HAM6 na A500
@Mir3k, post #84
tak, ten biały prostokąt w rogu xDD
w tym przykąłdzie pokazuja stałe 25fps - bo jest double buffer + waitTOF
bez wait TOF jest ok 30fps
w przypadku wersji 320x256 na ekranie 1280x256 to jest coś ok 12-15 fps (nie wiem dokladnie bo literki za małe)..
spróboję go może póżniej gdzieś złapać,
tymczasem gdy go wpisałem w ggole to wyskoszył mi nowy filmik BSziliego (tego od szybkiego portu Blooda itp)
i niby Blood pod HAM, zapytam jego bo mam z nim kontakt na eab.
Ostatnia aktualizacja: 12.03.2023 19:18:34 przez mateusz_s
w tym przykąłdzie pokazuja stałe 25fps - bo jest double buffer + waitTOF
bez wait TOF jest ok 30fps
w przypadku wersji 320x256 na ekranie 1280x256 to jest coś ok 12-15 fps (nie wiem dokladnie bo literki za małe)..
spróboję go może póżniej gdzieś złapać,
tymczasem gdy go wpisałem w ggole to wyskoszył mi nowy filmik BSziliego (tego od szybkiego portu Blooda itp)
i niby Blood pod HAM, zapytam jego bo mam z nim kontakt na eab.
Ostatnia aktualizacja: 12.03.2023 19:18:34 przez mateusz_s
12.03.2023 23:04
[#86]
Re: Quake w HAM6 na A500
@mateusz_s, post #85
Bszili mówi że tu jest konwersja 256 kolorów do ham,
Więc jest to szybsze. I dziala inaczej niz z 32bit do ham. I racja, przecież i quake i doom to 8 bit.
Co do mojego przypadku z tym rozciągnięciem to chyba jedynym rozwiązaniem by było żeby oryginał był węższy tj. Np. Co drugi pixel w poziomie wywalić żeby po konwersji do ham był w dobrych proporcjach.
A zostawię Tak jak jest narazie tez jest spoko.
Więc jest to szybsze. I dziala inaczej niz z 32bit do ham. I racja, przecież i quake i doom to 8 bit.
Co do mojego przypadku z tym rozciągnięciem to chyba jedynym rozwiązaniem by było żeby oryginał był węższy tj. Np. Co drugi pixel w poziomie wywalić żeby po konwersji do ham był w dobrych proporcjach.
A zostawię Tak jak jest narazie tez jest spoko.
13.03.2023 10:32
[#87]
Re: Quake w HAM6 na A500
@mateusz_s, post #83
"tylko jakby spłaszczone wszsytko"
Nie ma absolutnie żadnego powodu żeby było spłaszczone. Na pewno nie robi tego konwersja c2p która różni się tylko ilością pikseli na linię. Weź pod uwagę to, że 160x256 ma inny aspekt niż 320x256. Może nie bierzesz tego pod uwagę po prostu podczas rysowania. Musisz uwzględnić to, że obraz będzie "rozciągnięty" w poziomie podczas wyświetlania.
Nie ma absolutnie żadnego powodu żeby było spłaszczone. Na pewno nie robi tego konwersja c2p która różni się tylko ilością pikseli na linię. Weź pod uwagę to, że 160x256 ma inny aspekt niż 320x256. Może nie bierzesz tego pod uwagę po prostu podczas rysowania. Musisz uwzględnić to, że obraz będzie "rozciągnięty" w poziomie podczas wyświetlania.