Skocz do zawartości

Ilość koloru na ekranie


Rekomendowane odpowiedzi

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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%.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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ą.

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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 :)

Odnośnik do komentarza
Udostępnij na innych stronach

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

ddd.png

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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 :)

Odnośnik do komentarza
Udostępnij na innych stronach

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)

untitled89607.png

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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)

Odnośnik do komentarza
Udostępnij na innych stronach

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!

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...