Ilość koloru na ekranie

[LionX Dagger]

Witam

czy istnieje sposób na sprawdzenie np. procentowo ile danego koloru znajduje się na ekranie?

[MaxGaming]

Jedyne co mi przychodzi do głowy to "get_pixel", ale to drastycznie nie optymalne, tym bardziej jeżeli sprawdzamy cały ekran gry.

[baca]

To już lepiej zrobić screena i policzyć ręcznie, tylko nie wiem w jakim formacie zwraca, jak to jest bmp to dość prosto da się zrobić. Ale to też nie jest zbyt szybkie.

 

 

e:

może shaderem też da się to obliczyć

[Shockah]

...albo ręcznie sobie robić tablicę kolorów i obliczać.

[LionX Dagger]

Tablica miał by daj my na to 640 na 480 co to całkiem spora tablica :P fajnie było by gdyby właśnie zrobić zrzut ekranu do sprite za pomocą funkcji sprite_add_from_screen() i w nim sprawdzić ilość danego koloru ale nie wydaje mi się by istniał do tego jakaś funkcja

 

Może jakoś za pomocą surfaców by się dało ale też nie mam pojęcia jak

[Shockah]

Jakkolwiek by tego nie zrobił tablicą, będzie ZDECYDOWANIE SZYBCIEJ niż sprawdzać pixele.

[LionX Dagger]

Może i prawda jednak to dalej bardzo dużo jak nie tyle samo obliczeń plus zużyje więcej pamięci

 

No nic spróbuje obu metod ale żadna nie wydaje się specjalnie szybka

[Jaklub]

tak właściwie sprawdzanie ilości koloru na ekranie brzmi ciut dziwacznie i jeśli chcesz tym rozwiązać jakiś konkretny problem, to wydaje mi się, że zabierasz się do tego troszkę od dupy strony

 

na przykład sprawdzanie ile jest instancji danego obiektu na danym obszarze byłoby dużo szybsze niż zeskrobywanie kolorów z ekranu, a sprawdzanie, czy jakaś instancja weszła w konkretną strefę byłoby jeszcze szybsze

[Shockah]

Były takie gry multiplayer, że malowało się ekran na swój kolor, a po X czasu podliczało ile % się wypełniło.

Właściwie to i całe gry, i minigierki np. w Mario Party (chyba 9) na Wii.

[ereg]

wazne jest uzycie liczenia koloru.

 

dlatego doteraz niebylo co pisac :)

 

Shockah podal 1. przyklad uzycia.

w tym przypadku mozna by zapisiwac kazdy rysowany kolor do ds_grid.

mozna by uzyc naprz funkcji ds_grid_get_sum

 

innych przykladow niema, to niema co spelukowac :) bo mozliwosci uzycia zaduzo a czasu zamalo

 

BTW: sam bylem ciekawy czy mozna jakos uzyc shaderow, ale narazie nikt fundowany nic nepowiedzal

[PsichiX]

nope, shadery służą do zrównoleglania tych samych operacji na każdym docelowym pixelu ekranu, to znaczy że dla każdego pixela wyjściowego wykonywany jest ten sam zestaw instrukcji, a więc nie da się w nim wyliczyć ilości wszystkich pixeli danego koloru, gdyż dla każdego pixela wykonywać by trzeba samplowanie tekstur w liczbie SZEROKOSC*WYSOKOSC ekranu, a to wysoce nieoptymalne i wiele kart ma ograniczona ilosc samplowania na fragment.

znaczy się, mam pomysły dwa na to, by to uzyskac bez samplowania wszystkich pixeli na raz, ale to nadal jest bezcelowe i nie nadaje sie do zrobienia w real-time.

[Jaklub]

Były takie gry multiplayer, że malowało się ekran na swój kolor, a po X czasu podliczało ile % się wypełniło.

Właściwie to i całe gry, i minigierki np. w Mario Party (chyba 9) na Wii.

często przy grach w "malowanie ekranu" stosuje się podłogę w kafle. przypadków, gdzie maluje się bitmapę, jest mniej (na myśl w tym momencie przychodzi mi tylko jeden), i to jest jedyne miejsce, gdzie takie liczenie w sumie mogłoby się przydać, a i tak jeśli nie potrzebna jest idealna precyzja co do piksela, to można po prostu zrobić sobie mniejszą siatkę i na jej podstawie obliczać co trzeba. wychodzi wtedy na to, że kafle są, ale ich po prostu nie widać - różnica dla gracza marginalna, jeśli jakaś, ale dla sprzętu już może być zauważalna.

 

jeżeli jednak naprawdę konieczne jest liczenie kolorów ze stuprocentową precyzją, to nie znając lepszych sztuczek niż get_pixel, rozbiłbym chociaż takie liczenie na więcej klatek, aby zapobiec chrupnięciom framerate'a.

[ereg]

tak naprawde niewiemy jesli ma byc realtime :)

jesli tak, to bez sztuczek sie to nieodbedzie

 

YXE: dzieki za wytlumaczenie

[I am Lord]

Można liczyć już w trakcie malowania te kilka pixeli ale nadal nie wiem czy by frame rate nie spadł.

[Threef]

Jaklub podaje najlepsze rozwiązanie. Trzeba przechowywać to jako tablicę, i nawet przechowywanie każdego pixela w komórce będzie zabierało niewiele więcej pamięci od surface. O pobieraniu pixela z surface trzeba zapomnieć.

 

Najlepiej od razu operować na tablicy (ds_grid) i dopiero rysować wszystko na ekranie. Jeżeli nie potrzeba dokładności per pixel to można przechowywać w komórce tabeli 4 pixele (2x2) albo więcej, wtedy rozmiar tablicy robi się o wiele mniejszy, a dokładność danych może spadnie o 1%.

[PsichiX]

pragne zobaczyc, jak Waszym zdaniem mialoby wygladac to super zapisywanie pixeli do grida i sumowanie filtrowanych wartosci :)

nie chce psuc humoru, ale to nie zda egzaminu. pokazcie mi, ze sie myle.

[ereg]

ja mialem na mysli cos w tym rodzaju

 

pisane raczej szybko, niedoskonale i niekomentowalem kodu :)

 

- grid jest jak screen 800x600

- rozmiary so sterowane sheel up/down

- aqua kwadrat jest sterowany mouse

- jest tez z startu 1 black quadrat nisterowany, a bardzo maly. tez zmienia swo wielkosc

- RMB dodaje 1 black kwadrat na pozycje myszy

- MMB dodaj kazdy cykl(room_speed) 1 black kwadrat

- up/down ustawia szybkosc kazdego black kwadrata

- R resetuje demo

- nierobilem rysowanie z ds_grid na screen, bo chodzilo wylocnie o zapisiywanie do ds_grid a liczenie kolorow

(teraz tylko z black kwadratow + aqua kwadratu. Aqua kw. jest defakto black, ale kirowany myszo)

 

na gorze ekranu jest licznik obarwionych cell z ds_grid, zatem latwo polyczycz sibie ile jest % obarwione z screenu.

 

w sumie przyklad robi swe prosto i zsybko, bo nietrzeba robic z calym room, ale tylko z czescioma kdze so objekty rysujoce.

tak jak juz z Jaklub pisalismy

[PsichiX]

nadal nie aplikuje sie do sytuacji, gdzie rysujemy scene, jednoczesnie zapisujac dane do kontenera - tego nie da sie zrobic, aby bylo choc odrobine szybkie.

mam pomysl jak zrobic to wydajnie, ale potrzebuje wiedziec, czy autor robi te gre na windowsa, bo moge zrobic DLL, ktory bedzie operowal bezposrednio na buforze okna, co przyspieszy filtrowanie, a jak zrobie to na watku to nawet nie bedzie blokowal gry na tych kilka milisekund.

[Jaklub]

przechowywanie KAŻDEGO piksela w tablicy gdy mamy ich jakieś 480000 lub więcej to trochę słaby pomysł (zwróć uwagę na słowo "mniejszą" w moim poście), ale można przechowywać np. reprezentacje zbitek 16x16 pikseli, a później, malując po surfejsie, odpowiednio ustawiać wybrane komórki. jak najbardziej można też walnąć sobie do tych barwnych wygibasów dll, w zależności od potrzeb (bo np. jeśli mamy liczyć absolutnie wszystko na ekranie, to zabawa z gridem nie zda egzaminu). mówimy przy tym cały czas o liczeniu tych kolorków w czasie rzeczywistym, bo jeśli nie, to wiadomo, że lepiej parę razy pobawić się get_pixelem niż przybliżać (ew. znowu dll jeśli za wolno) - chodzi o to, by nie zabijać muchy armatą.

[LionX Dagger]

nadal nie aplikuje sie do sytuacji, gdzie rysujemy scene, jednoczesnie zapisujac dane do kontenera - tego nie da sie zrobic, aby bylo choc odrobine szybkie.

mam pomysl jak zrobic to wydajnie, ale potrzebuje wiedziec, czy autor robi te gre na windowsa, bo moge zrobic DLL, ktory bedzie operowal bezposrednio na buforze okna, co przyspieszy filtrowanie, a jak zrobie to na watku to nawet nie bedzie blokowal gry na tych kilka milisekund.

Nie to będzie gra na androida

ogólnie po przeczytaniu Jakluba zrobiłem masę małych instaców 8x8 które robią za pixele sposób nie idealny i średnio dokładny ale na pc działa i jak na razie chyba najszybsza :P

 

w czasie rzeczywistym, bo jeśli nie, to wiadomo, że lepiej parę razy pobawić się get_pixelem niż przybliżać (ew. znowu dll jeśli za wolno) - chodzi o to, by nie zabijać muchy armatą.

Obliczane ma być po levelu ale get pixel w ekranie 800x600 dwiema funkcjami "for" zwiesza gre na ponad minute

[Jaklub]

dlatego trzeba byłoby rozbić to na dużo więcej klatek albo jeszcze inaczej się pobawić (dlle odpadają bo android, chyba że są jakieś rozszerzenia to nie wiem)

 

poza tym, lepiej zrób na gridach niż na instancjach

[ereg]

nadal nie aplikuje sie do sytuacji, gdzie rysujemy scene, jednoczesnie zapisujac dane do kontenera - tego nie da sie zrobic, aby bylo choc odrobine szybkie.

...

moze niecalkiem cie zrozumialem, ale wystarczylo dodac rysowanie instancji do surface 800x600 i sprawdzic wyniki.

na mym starym PC byly:

dla 1x1pix draw_rectangle, grid zapis 1x1, 1400 instancji rysujocych = zawse>30fps

dla sprite 32x32 , grid zapis 32x32 , 1400 instancji = zawsze>30fps

taki sobie sredni PC chyba :)

 

ale w sumie to teraz juz niewazne, bo LionX Dagger juz zdecydowal jak woli to robic :)

[LionX Dagger]

Zdecydować nie zdecydowałem, zrobiłem jak umiałem nie znaczy że dobrze pytanie tylko jak ten sposób sprawdzi się na znacznie słabszym androidzie

Muszę jeszcze spróbować tą metodę z gridem choć szczerze nie za bardzo wiem jak się za to zabrać zwłaszcza że tak to nazwę obszar zakrycia jest nieregularny

[Threef]

O to chodziło abyś pokazał jak to się u Ciebie 'maluje'. Teraz mam dwa pytanka: Czy zmieszanie dwóch kolorów tworzy nowy? Potrzebujesz procentowej liczby koloru?

Jeżeli na oba odpowiedziałeś nie, to jest bardzo wydajny sposób na sprawdzenie tego, o ile wystarczy sama informacja którego koloru jest więcej. Wystarczy że będziesz sprawdzał odległości i depth obiektów i na ich podstawie dokonywał wyboru.

[ereg]

jesli chodzi o twary niezmieniajoce sie( plynaca barwa), mozna je przy stworzeniu gry/instance zapisac do ds_grid

- nietrzeba ani get_pixel, ale moglo by starczyc ustawienie maski i collision_point + zapisanie kazdego kolizijnego pixela do ds_grid

- tak masz w ds_grid maske ktoro da sie szybko przenosic do innych ds_grid dzeiki ds_grid_..._region

- maske robisz tylko raz dla kazdego kszaltu

- nierozwazalem tymczasowo mixowanie kolorow, ale chyba cos bedzie mozliwe. decydujo zasady mixowania a ty nieznam.

 

moge sie mylic, ale dawac duzo surface na androida niejest najlepszy pomysl :(

wnioskuje z netbokow a na tabletach/fonach chyba duzo lepiej niebedzie, dlatego ted przyklad ktory podalem wyzej moze niebyc najlepszy do przerobki na androida.

ALE surface w nim uzywany jest wylocnie do rysowania objektow, z ds_grid wiecej niema spolnego.

ogolnie mozna rysowac swym sposobem a ds_grid uzyc tylko do liczenia kolorow :)

[LionX Dagger]

O to chodziło abyś pokazał jak to się u Ciebie 'maluje'. Teraz mam dwa pytanka: Czy zmieszanie dwóch kolorów tworzy nowy? Potrzebujesz procentowej liczby koloru?

Jeżeli na oba odpowiedziałeś nie, to jest bardzo wydajny sposób na sprawdzenie tego, o ile wystarczy sama informacja którego koloru jest więcej. Wystarczy że będziesz sprawdzał odległości i depth obiektów i na ich podstawie dokonywał wyboru.

Interesuje mnie jedynie ilość nie zakrytego tła

 

Na razie liczę to w taki mało dokładny i mało optymalny sposób za pomocą niewidzialnych instansów (Tu widzialne to te białe kwadraciki które przy kolizji z kolorem są kasowane)

[ereg]

Interesuje mnie jedynie ilość nie zakrytego tła

...

to napewno sproboj dorobic ds_grid a przenosic maske przez ds_grid_..._region

by z kazdym objektem zmieniac ds_grid_800x600.

suma pol(cells) ds_grid_800x600 pokazuje miare zakrycia z dokladnosco co do 1 pixela

[PsichiX]

yup, teraz motyw z gridem ma sens. i będzie to zdecydowanie szybsze niż instancje :)

[Amaterasu]

Nie mam możliwości sprawdzenia tego w tej chwili na moim sprzęcie, ale może dałoby się malować czarne kopie kleksa na surface A o wymiarach Width*Height, zeskalować surface A do surface B o wymiarach 1*1 (czyli piksel) i sprawdzić wartość tego piksela? Mam mgliste przeczucie, że mogłoby to działać, o ile włączona jest interpolacja między pikselami (w ustawieniach albo jedną z funkcji)

[PsichiX]

fuck. amateratsu, jestes geniuszem :D dobrze kminisz, ale jeszcze prosciej jest renderowac od razu do surface 1x1, gdzie trzeba bedzie mapowac widok ze sceny na surface (najszybciej w vertex shaderku). tylko jest jedna wada rozwiazania: bardzo slaba dokladnosc (256 wartosci w reprezentacji procentowej kazdego kanalu). mimo wszystko gratki za swietny pomysl!