Aktualności Forum Graffiti Publicystyka Teleport
[#31] Re: W temacie mojej procedury konwersji c2p

@nogorg, post #30

Robi się, komandorze.
[#32] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #31

OK
[#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
[#34] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #33

Oczekiwałbym jakiegoś zestawienia z istniejącymi już procedurami. Bo mnie, nieprogramiście, to za wiele nie mówi. Samą procedurę testującą chyba też wypadałoby przedstawić. Może koledzy koderzy rozłożą ją na jakieś czynniki.
[#35] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #33

przerób ją żeby działała z rtgmaster to sprawdze na napalmie
[#36] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #33

Czyli 5 ekranów/sek. na 020/14 tylko chip
i 17ekranow/sek na 030/50 fast
ekran 320x256.
Dobrze liczę ?
5 i 17 klatek/sek ?
[#37] Re: W temacie mojej procedury konwersji c2p

@Norbert, post #36

Tak.
[#38] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #37

No to tyłka nie urywa
[#39] Re: W temacie mojej procedury konwersji c2p

@xray, post #38

A procesor poza konwersją C2P coś robi w twojej procedurze?
[#40] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #33

Btw. z tego co kojarze to najlepsze procedury pod 030 działają w okolo 30ms, więc twoja procedura jest wolna w stosunku do innych akcelerowanych pod 030.

http://eab.abime.net/showthread.php?t=74008

Ostatnia aktualizacja: 08.12.2017 12:07:06 przez michal_zukowski
[#41] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #33

Odpalcie program testc2p na swoich maszynach i podajcie wyniki.


V600/GOLD3beta
[#42] Re: W temacie mojej procedury konwersji c2p

@skipp, post #41

emulatory sie nie liczą :P
[#43] Re: W temacie mojej procedury konwersji c2p

@michal_zukowski, post #42

Sam jesteś emulator ;)
[#44] Re: W temacie mojej procedury konwersji c2p

@skipp, post #43

Emulator procesora, przeciez to było sprawdzane.
[#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
[#46] Re: W temacie mojej procedury konwersji c2p

@jarokuczi, post #39

@Jarokuczi
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
[#47] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #33

Odpalcie program testc2p na swoich maszynach i podajcie wyniki.


a u mnie nie podaje żadnego wyniku. D: W ogóle nic nie podaje.
[#48] Re: W temacie mojej procedury konwersji c2p

@snajper, post #47

A jaki masz komputer i system? Program wymaga systemu 3.0+ i AGA. Prawdopodobnie też procesora 68020.
[#49] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #48

aaa, jak AGA, to nie zabangla... Odpalałem na pięćsetce z ACA1232.
[#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.
[#51] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #50

Czyli co, konwertuje w tym momencie biały prostokąt w dwóch kolorach a nie texture? W takim wypadku ma się to nijak do innych procedur c2p w sensie porównań.
[#52] Re: W temacie mojej procedury konwersji c2p

@Stoopi, post #51

Konwertuje dowolny 256-kolorowy obrazek/teksturę.
Tylko na razie w ramach testu konwertuje teksturę składającą się z samych pikseli o numerze 2. Ale każdy piksel obrazka może być w jednej z 256 barw.

Ostatnia aktualizacja: 08.12.2017 15:43:33 przez Hexmage960
[#53] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #50

tak, nie wyświetla nic.
[#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
[#55] Re: W temacie mojej procedury konwersji c2p

@teh_KaiN, post #54

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?

Bitmapę wyświetlam. Otwieram ekran 8-bitplanowy.

Co do efektu graficznego to go przygotuję.
[#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
[#57] Re: W temacie mojej procedury konwersji c2p

@Hexmage960, post #56

A może tak na szybko prosty viewer plików BMP ? Format prosty i dane w chunky... I te C2P się przyda szeroki uśmiech

Ostatnia aktualizacja: 09.12.2017 13:00:32 przez pisklak
[#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
[#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%.
  • 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
[#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
Na stronie SCENA.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem