08.12.2017 07:31
[#33]
Re: W temacie mojej procedury konwersji c2p
@nogorg, post #32
Udało mi się dopracować procedurę w ten sposób, że zapisuje dane wyjściowe do pamięci graficznej, jak również napisałem program testujący.
Procedura zapisuje skonwertowaną grafikę bezpośrednio do bitmapy typu interleaved w formacie systemowym o dowolnym rozmiarze. Oznacza, to że jest bardzo uniwersalna i wygodna w użyciu.
Tutaj możecie przeczytać kod źródłowy procedury:
http://coreprogramming.pl/c2p/fastc2p.txt
Tutaj możecie pobrać program testujący. Można podać parametry, jakimi są: szerokość i wysokość bitmapy. Program w razie czego poprawi podaną szerokość, by była podzielna przez 16. Domyślnie bitmapa to 160x128, czyli 1/4 ekranu Lores. Nie można podawać wartości wyższych niż 320x256.
http://coreprogramming.pl/c2p/testc2p
Program wykonuje obecnie 50 konwersji ekranu, a następnie wyświetla średni wynik jednokrotnej konwersji ekranu w milisekundach i częściach sekundy.
A teraz wyniki przykładowe: procedura okazuje się naprawdę dobra. Na 68020/14MHz tylko z CHIP RAM cały ekran 320x256 konwertuje w mniej niż 200ms, czyli 1/5 sekundy. Jestem bardzo zadowolony z tego wyniku, bo jest bardzo dobry.
Z kolei na 68030/50MHz z FAST RAM cały ekran 320x256 konwertuje w ok. 60ms, czyli 0,06 sekundy.
Uwzględniając uniwersalność procedury oraz zapis 16-bitowy to jest bardzo fajny rezultat. W prosty sposób można zrobić zapis 32-bitowy z buforem w pamięci FAST, żeby jeszcze polepszyć wynik.
Odpalcie program testc2p na swoich maszynach i podajcie wyniki.
Ostatnia aktualizacja: 08.12.2017 07:41:25 przez Hexmage960
Procedura zapisuje skonwertowaną grafikę bezpośrednio do bitmapy typu interleaved w formacie systemowym o dowolnym rozmiarze. Oznacza, to że jest bardzo uniwersalna i wygodna w użyciu.
Tutaj możecie przeczytać kod źródłowy procedury:
http://coreprogramming.pl/c2p/fastc2p.txt
Tutaj możecie pobrać program testujący. Można podać parametry, jakimi są: szerokość i wysokość bitmapy. Program w razie czego poprawi podaną szerokość, by była podzielna przez 16. Domyślnie bitmapa to 160x128, czyli 1/4 ekranu Lores. Nie można podawać wartości wyższych niż 320x256.
http://coreprogramming.pl/c2p/testc2p
Program wykonuje obecnie 50 konwersji ekranu, a następnie wyświetla średni wynik jednokrotnej konwersji ekranu w milisekundach i częściach sekundy.
A teraz wyniki przykładowe: procedura okazuje się naprawdę dobra. Na 68020/14MHz tylko z CHIP RAM cały ekran 320x256 konwertuje w mniej niż 200ms, czyli 1/5 sekundy. Jestem bardzo zadowolony z tego wyniku, bo jest bardzo dobry.
Z kolei na 68030/50MHz z FAST RAM cały ekran 320x256 konwertuje w ok. 60ms, czyli 0,06 sekundy.
Uwzględniając uniwersalność procedury oraz zapis 16-bitowy to jest bardzo fajny rezultat. W prosty sposób można zrobić zapis 32-bitowy z buforem w pamięci FAST, żeby jeszcze polepszyć wynik.
Odpalcie program testc2p na swoich maszynach i podajcie wyniki.
Ostatnia aktualizacja: 08.12.2017 07:41:25 przez Hexmage960
08.12.2017 13:30
[#45]
Re: W temacie mojej procedury konwersji c2p
@skipp, post #41
@Skipp
Dziękuję za sprawdzenie mojej procedury na karcie turbo Vampire. Wynik robi wrażenie.
@Reszta
Moja procedura, tak jak napisałem, zapisuje 16-bitowe słowa w pamięci CHIP. Jak dorobię zapis 32-bit, co nie jest trudne (wystarczy zapisać dane tymczasowo na stosie i powtórzyć operację konwersji), prędkość może być nawet 2x.
Uważam, że wynik dla 68020/14MHz jest bardzo dobry. Pamiętajmy, że procesor konwertuje 81920 pikseli w detalach 1x1.
Wynik dla 68030/50MHz mógłby być lepszy.
Przypominam, że procedura zapisuje do bitmapy o zupełnie dowolnym rozmiarze.
Docelowo można zrobić tak, żeby Blitter nanosił skonwertowane piksele w dowolne miejsce ekranu. Ponieważ Blitter pracuje asynchronicznie od CPU, mógłby to robić, gdy CPU jest zajęty konwersją.
Teraz myślę, że warto zrobić praktyczny użytek z tej procedury. Dużą jej zaletą jest możliwość wygodnego stosowania. Przyjmuje dwa parametry - bufor pikseli chunky i bitmapę docelową, resztę wylicza sama. Dzięki temu napisanie efektu graficznego z jej wykorzystaniem jest prostsze.
Jeśli chodzi o Napalm czy Gloom, to myślę, że przepisywanie procedury pod te gry mija się z celem, ponieważ założeniem stworzenia tej procedury było jej wygodne stosowanie we własnym zakresie i żeby w wygodny sposób zapisywała do bitmapy. Adaptując tą procedurę pod te gry, straci ona na tej cesze i oznacza pisanie tak naprawdę na nowo.
Ostatnia aktualizacja: 08.12.2017 13:46:02 przez Hexmage960
Dziękuję za sprawdzenie mojej procedury na karcie turbo Vampire.
Wynik robi wrażenie.@Reszta
Moja procedura, tak jak napisałem, zapisuje 16-bitowe słowa w pamięci CHIP. Jak dorobię zapis 32-bit, co nie jest trudne (wystarczy zapisać dane tymczasowo na stosie i powtórzyć operację konwersji), prędkość może być nawet 2x.
Uważam, że wynik dla 68020/14MHz jest bardzo dobry. Pamiętajmy, że procesor konwertuje 81920 pikseli w detalach 1x1.
Wynik dla 68030/50MHz mógłby być lepszy.
Przypominam, że procedura zapisuje do bitmapy o zupełnie dowolnym rozmiarze.
Docelowo można zrobić tak, żeby Blitter nanosił skonwertowane piksele w dowolne miejsce ekranu. Ponieważ Blitter pracuje asynchronicznie od CPU, mógłby to robić, gdy CPU jest zajęty konwersją.
Teraz myślę, że warto zrobić praktyczny użytek z tej procedury. Dużą jej zaletą jest możliwość wygodnego stosowania. Przyjmuje dwa parametry - bufor pikseli chunky i bitmapę docelową, resztę wylicza sama. Dzięki temu napisanie efektu graficznego z jej wykorzystaniem jest prostsze.
Jeśli chodzi o Napalm czy Gloom, to myślę, że przepisywanie procedury pod te gry mija się z celem, ponieważ założeniem stworzenia tej procedury było jej wygodne stosowanie we własnym zakresie i żeby w wygodny sposób zapisywała do bitmapy. Adaptując tą procedurę pod te gry, straci ona na tej cesze i oznacza pisanie tak naprawdę na nowo.
Ostatnia aktualizacja: 08.12.2017 13:46:02 przez Hexmage960
08.12.2017 14:27
[#46]
Re: W temacie mojej procedury konwersji c2p
@jarokuczi, post #39
@Jarokuczi
Procesor pobiera dane graficzne w formacie chunky i zapisuje w bitmapie docelowej (czyli np. na ekran) grafikę w formacie planarnym.
Nie robi natomiast efektów.
Ostatnia aktualizacja: 08.12.2017 14:29:06 przez Hexmage960
A procesor poza konwersją C2P coś robi w twojej procedurze?
Procesor pobiera dane graficzne w formacie chunky i zapisuje w bitmapie docelowej (czyli np. na ekran) grafikę w formacie planarnym.
Nie robi natomiast efektów.
Ostatnia aktualizacja: 08.12.2017 14:29:06 przez Hexmage960
08.12.2017 15:23
[#50]
Re: W temacie mojej procedury konwersji c2p
@snajper, post #49
Sorki, procedura jest robiona pod AGA i 8 bitplanów. Ale dorobię komunikaty o błędach. U Ciebie program po prostu nic nie wyświetla?
Na odpowiednim sprzęcie/systemie powinien otworzyć ekran, narysować gustowny biały prostokąt (złożony z pikseli o tym samym kolorze) jako rezultat konwersji i wyświetlić wynik w okienku Shella.
Zamiast białego prostokąta będzie oczywiście jakaś tekstura w praktycznych zastosowaniach.
Zaś co do poprawności konwersji, to testowałem procedurę i konwertuje poprawnie.
Na odpowiednim sprzęcie/systemie powinien otworzyć ekran, narysować gustowny biały prostokąt (złożony z pikseli o tym samym kolorze) jako rezultat konwersji i wyświetlić wynik w okienku Shella.
Zamiast białego prostokąta będzie oczywiście jakaś tekstura w praktycznych zastosowaniach.
Zaś co do poprawności konwersji, to testowałem procedurę i konwertuje poprawnie.
08.12.2017 17:45
[#54]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #52
Yyy... Ale Ty tej bitmapy nie wyświetlasz, więc AGA czy nie, bitmapę 8bpp powinien sobie w ramie móc założyć i ją skonwertować, nie? Może wersja kicka mu tu przeszkadza?
BTW. 100x efektowniejsze będzie trzymanie tej bitmapy chunky 8 lub nawet 4bpp, założenie viewporta, obrócenie jej kopii co klatkę o kąt (obczaj sobie w ACE'ową funkcję utils/chunky.c/chunkyRotate() ) i skonwertowanie do planara na bufor. Na wyjściu w konsoli czasy tak jak podawane do tej pory. Może być precalc obrotów jak nie chcesz zaburzać wyników ;)
Ostatnia aktualizacja: 08.12.2017 17:50:26 przez teh_KaiN
BTW. 100x efektowniejsze będzie trzymanie tej bitmapy chunky 8 lub nawet 4bpp, założenie viewporta, obrócenie jej kopii co klatkę o kąt (obczaj sobie w ACE'ową funkcję utils/chunky.c/chunkyRotate() ) i skonwertowanie do planara na bufor. Na wyjściu w konsoli czasy tak jak podawane do tej pory. Może być precalc obrotów jak nie chcesz zaburzać wyników ;)
Ostatnia aktualizacja: 08.12.2017 17:50:26 przez teh_KaiN
09.12.2017 11:55
[#56]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #55
Wpadłem na pomysł napisania programu typu "Slide show" (do oglądania obrazków) z graficznymi efektami chunky celem wykorzystania mojej procedury w praktyce i zademonstrowaniu jej działania.
Ponieważ obrazki mogą mieć różne palety 256-kolorów, pierwsze co zrobiłem to opracowanie jednolitej palety barw, coś jak "True Color". Poniżej wklejam wynik opracowania tej palety. 243 barwy prezentują całe spektrum barw. Pozostaje 13 barw niewykorzystanych.
Teraz pozostaje ładowanie obrazków, konwersja do postaci chunky i remapowanie do tej palety. Myślę, że wynik remapowania będzie OK.
Następnie właściwy "Slide show", w którym obrazki będą płynnie przechodzić. Myślałem o płynnej zamianie pikseli z jednego obrazka w drugi oraz jakieś inne efekty jak przesuw bitmapy.
Ostatnia aktualizacja: 09.12.2017 12:13:12 przez Hexmage960
Ponieważ obrazki mogą mieć różne palety 256-kolorów, pierwsze co zrobiłem to opracowanie jednolitej palety barw, coś jak "True Color". Poniżej wklejam wynik opracowania tej palety. 243 barwy prezentują całe spektrum barw. Pozostaje 13 barw niewykorzystanych.
Teraz pozostaje ładowanie obrazków, konwersja do postaci chunky i remapowanie do tej palety. Myślę, że wynik remapowania będzie OK.
Następnie właściwy "Slide show", w którym obrazki będą płynnie przechodzić. Myślałem o płynnej zamianie pikseli z jednego obrazka w drugi oraz jakieś inne efekty jak przesuw bitmapy.
Ostatnia aktualizacja: 09.12.2017 12:13:12 przez Hexmage960
09.12.2017 13:22
[#58]
Re: W temacie mojej procedury konwersji c2p
@pisklak, post #57
To jest też bardzo dobry pomysł.
Ja w w moim programie myślałem, żeby ładować obrazki za pomocą datatypów, które remapują automatycznie, a następnie robić efekty chunky "na żywo".
Ale BMP od razu ma dane chunky, więc będzie prościej!
Dzięki kolego za świetny pomysł.
Ostatnia aktualizacja: 09.12.2017 13:30:24 przez Hexmage960
Ja w w moim programie myślałem, żeby ładować obrazki za pomocą datatypów, które remapują automatycznie, a następnie robić efekty chunky "na żywo".
Ale BMP od razu ma dane chunky, więc będzie prościej!
Dzięki kolego za świetny pomysł.
Ostatnia aktualizacja: 09.12.2017 13:30:24 przez Hexmage960
11.12.2017 19:49
[#59]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #58
Zoptymalizowałem moją sympatyczną procedurę. A jakże!
Włożyłem maski do rejestrów, a pola bm_BytesPerRow i bm_Rows z nich wyjąłem, gdyż korzystam z nich rzadziej.
Rezultat: na 68020/14MHz z CHIP przyrost prędkości +25%.
Jeśli chodzi o 68030/50MHz z FAST, przyrost prędkości +17%.
Oczywiście test jest przy pełnej wielozadaniowości systemu Amigi (niezmieniony priorytet 0). Można odpalać inne programy.
Sprawdzałem też poprzednią wersję na 68060/50MHz (teraz mam włożoną 68030) i z tego co pamiętam tam mieściłem się w ramce przy pełnym ekranie.
Nie posiadam karty (ani Amigi) z 040 i jeżeli ktoś może przeprowadzić mały test, byłbym wdzięczny.
Należy też pamiętać, że mogę zrobić wersję 2x1 procedury o obniżonych detalach. A tak, trzeba użyć mniejszego okienka by rozkoszować się np. 30 FPS. A to na 030/50MHz można łatwo osiągnąć.
Pomimo, że ta procedura tylko konwertuje, oczywiście obrazuje ile pikseli można przerabiać w tym czasie. Bo czy wykonamy jedną, czy dwie operacje na pikselu to nie czyni dużej różnicy, bo koszt nadal jest liniowy. Dopiero jak wykonamy n operacji na każdym z n pikseli, różnica jest, bo wówczas koszt jest kwadratowy na przykład.
Oczywiście na Amidze CD32 problem z konwersją odchodzi, bo tam jest sprzętowy, ale chciałbym by Amiga 1200 też mogła korzystać z dobrodziejstw tej techniki.
Przepraszam, że jeszcze nie opublikowałem programu demonstracyjnego, ale takowy zrobię.
Format BMP jest całkiem prosty, nawet mam źródła datatypa do BMP, ale jednak trzeba nad tym trochę popracować. Myślałem też by zrobić program testujący z prostym GUI, dla umilenia procesu testowania.
Niestety nie mam w ogóle doświadczenia w mapowaniu tekstur i innych technikach (nawet 2D), więc takich efektów szybko nie zrobię.
Myślałem, żeby później wykorzystać kod w mojej grze. W każdym razie trochę to potrwa, ale już teraz warsztat pracy jest coraz lepszy.
Troszkę zastanawiam się również nad zaadaptowaniem procedury do Glooma, bo być może nie będzie to takie trudne.
Tymczasem oto linki do:
Pozdrawiam i niech Amiga będzie z Wami.
Ostatnia aktualizacja: 11.12.2017 19:51:45 przez Hexmage960
Włożyłem maski do rejestrów, a pola bm_BytesPerRow i bm_Rows z nich wyjąłem, gdyż korzystam z nich rzadziej.
Rezultat: na 68020/14MHz z CHIP przyrost prędkości +25%.
- Cały ekran 320x256 konwertuje w 150ms, czyli 0,15 sekundy (6,6 FPS).
- Ekran 160x100 konwertuje w mniej niż 30ms, czyli 0,03 sekundy (30 FPS).
Jeśli chodzi o 68030/50MHz z FAST, przyrost prędkości +17%.
- Cały ekran konwertuje w 53ms, czyli 0,053 sekundy (18,8 FPS).
- Ekran 192x245 konwertuje w 30,2ms, czyli 0,0302 sekundy (30 FPS)!
- Ekran 160x175 konwertuje w 18,5ms, czyli 0,0185 sekundy (54 FPS).
Oczywiście test jest przy pełnej wielozadaniowości systemu Amigi (niezmieniony priorytet 0). Można odpalać inne programy.
Sprawdzałem też poprzednią wersję na 68060/50MHz (teraz mam włożoną 68030) i z tego co pamiętam tam mieściłem się w ramce przy pełnym ekranie.
Nie posiadam karty (ani Amigi) z 040 i jeżeli ktoś może przeprowadzić mały test, byłbym wdzięczny.
Należy też pamiętać, że mogę zrobić wersję 2x1 procedury o obniżonych detalach. A tak, trzeba użyć mniejszego okienka by rozkoszować się np. 30 FPS. A to na 030/50MHz można łatwo osiągnąć.
Pomimo, że ta procedura tylko konwertuje, oczywiście obrazuje ile pikseli można przerabiać w tym czasie. Bo czy wykonamy jedną, czy dwie operacje na pikselu to nie czyni dużej różnicy, bo koszt nadal jest liniowy. Dopiero jak wykonamy n operacji na każdym z n pikseli, różnica jest, bo wówczas koszt jest kwadratowy na przykład.
Oczywiście na Amidze CD32 problem z konwersją odchodzi, bo tam jest sprzętowy, ale chciałbym by Amiga 1200 też mogła korzystać z dobrodziejstw tej techniki.
Przepraszam, że jeszcze nie opublikowałem programu demonstracyjnego, ale takowy zrobię.
Format BMP jest całkiem prosty, nawet mam źródła datatypa do BMP, ale jednak trzeba nad tym trochę popracować. Myślałem też by zrobić program testujący z prostym GUI, dla umilenia procesu testowania.
Niestety nie mam w ogóle doświadczenia w mapowaniu tekstur i innych technikach (nawet 2D), więc takich efektów szybko nie zrobię.
Myślałem, żeby później wykorzystać kod w mojej grze. W każdym razie trochę to potrwa, ale już teraz warsztat pracy jest coraz lepszy.
Troszkę zastanawiam się również nad zaadaptowaniem procedury do Glooma, bo być może nie będzie to takie trudne.
Tymczasem oto linki do:
Pozdrawiam i niech Amiga będzie z Wami.
Ostatnia aktualizacja: 11.12.2017 19:51:45 przez Hexmage960
11.12.2017 21:19
[#60]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #59
Panowie, zatem moja procedura konwertuje połowę ekranu w pełnych detalach (320x100 lub 160x200) w 50 FPS na Amidze 1200 z Blizzardem 1230-IV/50MHz. Czyż nie wspaniale? 
A mam nawet pomysł jak zrobić zapis 32-bitowy bez żadnych kosztów (choć jest to zbyteczne). 
Ostatnia aktualizacja: 11.12.2017 21:20:31 przez Hexmage960
Czyż nie wspaniale? A mam nawet pomysł jak zrobić zapis 32-bitowy bez żadnych kosztów (choć jest to zbyteczne). Ostatnia aktualizacja: 11.12.2017 21:20:31 przez Hexmage960