Gra Puzzle

[gregory]

Witam
Postanowiłem sobie dla treningu napisać grę puzzle, właściwie to bardziej taka układanka. Póki co wygląda to tak http://img46.imageshack.us/i/vvvt.png/
Jak widać na załączonym screenie, gra będzie polegać na złożeniu obrazka z części. W tym oknie jest komponent typu Panel, a na nim cztery komponenty Image, przy czym każdy we właściwości Picture zawiera jedną z części obrazka. Niestety nie mam pomysłu jakbym mógł przesuwać lub przeciągać w pionie bądź poziomie poszczególne kawałki obrazka by je zamieniać miejscami, aż do poprawnego ułożenia ilustracji. W dodatku przydała by się wskazówka jak sprawdzić czy obrazek jest ułożony poprawnie. Póki co mam na myśli to aby sprawdzać położenie Left i Top komponentów Image. Proszę o pomoc.

[Cyfrowy Baron]

Twój problem polega na tym, że poza pomysłem nie masz nic, w czym można by Tobie pomóc. Nie wiem, czy znajdzie się ktoś, kto będzie chciał napisać za Ciebie ten program.

Na początek powinieneś od czegoś zacząć, czyli stworzyć jakiś kod, który coś robi i jeżeli natkniesz się na problem wtedy dopiero na forum i konkretne pytanie.

Tej gry nie da się napisać opierając się tylko na obiektach typu TImage, w zasadzie to wystarczy jeden Image, który posłuży za powierzchnię do rysowania. Ja zacząłbym od stworzenia klasy, która sterowałaby pojedynczym elementem - klockiem, wtedy w oparciu o taką klasę można by stworzyć wiele klocków, które zapamiętywałby swój układ i położenie. Poza tym sugerowałbym napisać to w GDI+, a jeszcze lepiej w DirectDraw. Przy czterech klockach standardowe GDI się sprawdzi, ale jeżeli będziesz chciał stworzyć puzzle zawierające kilkadziesiąt klocków to może być problem.

[polymorphism]

Przy czterech klockach standardowe GDI się sprawdzi, ale jeżeli będziesz chciał stworzyć puzzle zawierające kilkadziesiąt klocków to może być problem.

No nie żartuj GDI spokojnie sobie poradzi, nawet przy kilkudziesięciu klockach.

[Cyfrowy Baron]

No nie żartuj GDI spokojnie sobie poradzi, nawet przy kilkudziesięciu klockach.

A ja uważam, że nie. Klocki mają być przesuwane po planszy, więc jest to animacja, jeżeli plansza będzie duża to pojawi się problem z płynnym przesuwaniem klocka po planszy, ponieważ konieczne będzie płynne odświeżanie tejże planszy.

Swego czasu próbowałem zrobić sobie taką grę, w której animowany pies biegał po planszy w miejsce wskazane myszą. Gra się strasznie cięła na planszy o wymiarach 1280x1024, wykorzystałem więc DirecDraw i uzyskałem płynną animację.

W przypadku GDI trudno uzyskać płynne przewijanie grafiki o dużych wymiarach (testowane 962x1600) przy przewijaniu jej po ScrollBox'ie, więc uzyskać płynne przesuwanie klocka pod dużej planszy będzie stanowiło jeszcze większy problem.

Niestety nie mam pomysłu jakbym mógł przesuwać lub przeciągać w pionie bądź poziomie poszczególne kawałki obrazka by je zamieniać miejscami

Niezależnie od tego, czy plansza będzie składała się z pojedynczej planszy z odrysowanymi wieloma klockami, czy będzie to po prostu powierzchnia na której umieści się wiele obiektów typu TImage, to przy dużej powierzchni program będzie miał problem z szybkim odświeżaniem grafiki i to nie tylko przy przesuwaniu klocka, ale również wtedy, gdy okno zejdzie na dalszy plan, a potem zostanie przywołane, GDI będzie musiało to wszystko ponownie odrysować. Dlatego nie tylko GDI nie poradzi sobie z tym, ale nawet GDI+ i jedynym rozsądnym wyjściem jest DirectDraw. Niewiele zresztą widziałem gier opartych na GDI - ostatnio żadnej.

Z mała planszą rzędu 800x600 GDI poradzi sobie, ale chcąc stworzyć puzzle z prawdziwego zdarzenia, trzeba posłużyć się dużą planszą.

Poza tym sugerowałbym napisać to w GDI+, a jeszcze lepiej w DirectDraw. Przy czterech klockach standardowe GDI się sprawdzi, ale jeżeli będziesz chciał stworzyć puzzle zawierające kilkadziesiąt klocków to może być problem.

Nie napisałem, że nie da się tego zrobić z GDI, ale nie zgodzę się z twierdzeniem, że GDI spokojnie poradzi sobie z tym problemem przy dużej planszy. Dużej planszy, gdyż kilkudziesięciu klocków na małej nie da się umieścić. Kilkudziesięciu oznacza co najmniej dwadzieścia.

[polymorphism]

jeżeli plansza będzie duża to pojawi się problem z płynnym przesuwaniem klocka po planszy

Przecież mowa o puzzlach, a nie o shooterze, gdzie każda klatka się liczy.

Swego czasu próbowałem zrobić sobie taką grę, w której animowany pies biegał po planszy w miejsce wskazane myszą.

A w czym był ten animowany pies?

Nie napisałem, że nie da się tego zrobić z GDI (...)

A ja nigdzie nie napisałem, że tak twierdzisz.

(...) ale nie zgodzę się z twierdzeniem, że GDI spokojnie poradzi sobie z tym problemem przy dużej planszy.

Także nigdzie nie pisałem o dużej planszy. Dwadzieścia klocków nie musi od razu oznaczać dużej planszy.

Przypominam, że GDI ma wsparcie sprzętowe, więc wszelkie blittery, rasteryzery i clippery są realizowane po stronie karty graficznej (dlatego preferowane są bitmapy DDB). Oczywiście nie chcę powiedzieć, że DirectX jest gorszy, bo nie jest. Po prostu do pewnych rzeczy nie warto angażować bibliotek, które tylko skomplikują zadanie (przypominam, mowa o puzzlach 4x4).

[Cyfrowy Baron]

Przecież mowa o puzzlach, a nie o shooterze, gdzie każda klatka się liczy.

Każda klatka rzeczywiście się nie liczy, ale przesuwanie po dużej powierzchni Canvas obiektów wywołuje efekt zamazywania, powstają białe kontury, obiekt się "rozwarstwia", więc to już nie jest kwestia klatek.

A w czym był ten animowany pies?

Sześć bitmap animowanych Timer'em. W GDI był nie tyle problem z animowanym obiektem ile z tłem na którym ten obiekt był animowany, gdyż konieczne było odświeżanie całego tła. W DirectDraw ten problem rozwiązuje bufor ekranu, co znacznie przyspiesza odświeżanie. Podwójne buforowanie w GDI nie może się z tym równać.

Po prostu do pewnych rzeczy nie warto angażować bibliotek, które tylko skomplikują zadanie (przypominam, mowa o puzzlach 4x4).

Na początek może takie puzzle wystarczą. To zależy też od tego, czy to ma być projekt na szybko, czy też będzie rozwijane. Jeżeli w przyszłości ma to być gra z prawdziwego zdarzenia, to można oczywiście poćwiczyć na GDI, ale właściwą grę trzeba by zrobić ze wsparciem DirectX.

Przypominam, że GDI ma wsparcie sprzętowe, więc wszelkie blittery, rasteryzery i clippery są realizowane po stronie karty graficznej (dlatego preferowane są bitmapy DDB).

Znacznie prościej i szybciej da się to zrobić w GDI+.

Poza tym ja tylko sugerowałem kierunek rozwoju tego programu. Jeżeli zacznie go tworzyć w GDI, a potem będzie chciał go rozwinąć, to tylko przysporzy sobie pracy, dlatego lepiej jest od razu zacząć z wykorzystaniem technologii dającej lepsze wyniki.

[polymorphism]

(...) ale przesuwanie po dużej powierzchni Canvas obiektów wywołuje efekt zamazywania, powstają białe kontury, obiekt się "rozwarstwia", więc to już nie jest kwestia klatek.

Nie wiem, czym są te "rozwarstwienia" i "białe kontury". Nie sądzę, żeby to miało związek z GDI, raczej z błędami w kodzie.

W GDI był nie tyle problem z animowanym obiektem ile z tłem na którym ten obiekt był animowany, gdyż konieczne było odświeżanie całego tła.

A czym było to tło?

Znacznie prościej i szybciej da się to zrobić w GDI+.

Nie wiem jak to dzisiaj wygląda, ale wczesne wersje GDI+ nie miały wsparcia sprzętowego, zatem użycie tej biblioteki może i usprawni pisanie, ale nie koniecznie musi dać pożądaną wydajność.

---

Tu taka mała ciekawostka: jedno z dem biblioteki AGG. Wszystko, rasteryzacja, clipping i inne, realizowane jest software'owo link. U mnie na pełnym ekranie (1152x864) animuje prawie płynnie. To co dopiero mówić o kopiowaniu paru bitmap przy pomocy hardware'owych blitterów?

[Cyfrowy Baron]

Nie wiem, czym są te "rozwarstwienia" i "białe kontury". Nie sądzę, żeby to miało związek z GDI, raczej z błędami w kodzie.

Nie potrzeba żadnego kodu. Umieść na obiekcie ScrollBox duży obiekt Image i przewijaj grafikę za zobaczysz to "rozwarstwiania" lub może raczej powielanie pikseli.

A czym było to tło?

A czym mogło być - bitmapą.

Nie wiem jak to dzisiaj wygląda, ale wczesne wersje GDI+ nie miały wsparcia sprzętowego, zatem użycie tej biblioteki może i usprawni pisanie, ale nie koniecznie musi dać pożądaną wydajność.

Już to chyba kiedyś wyjaśniałem, GDI+ ma wsparcie sprzętowe. Dziś już chyba niemal wszystkie programu graficzne korzystają z GDI+, a najlepszym przykładem jest Adobe Photoshop.

[polymorphism]

Umieść na obiekcie ScrollBox duży obiekt Image i przewijaj grafikę za zobaczysz to "rozwarstwiania" lub może raczej powielanie pikseli.

No to wina kodu. Zresztą takich rzeczy nie robi się na komponentach. Pamiętam, że też miałem problemy z VCL-ową obsługą odmalowywania okien, dlatego pisząc kontrolki zawsze przechwytywałem komunikat WM_PAINT. Dopiero wtedy wszystko chodziło jak należy.

A czym mogło być - bitmapą.

Przy każdym odmalowaniu ładowana z pliku?

Już to chyba kiedyś wyjaśniałem, GDI+ ma wsparcie sprzętowe.

Hmm, na WinXP też? Masz jakieś linki do oficjalnych informacji na ten temat? Bo ja ilekroć spotykałem się z tematami o GDI+, to zawsze była mowa o braku sprzętowego wsparcia.

Dziś już chyba niemal wszystkie programu graficzne korzystają z GDI+ (...)

To, że korzystają, nie musi oznaczać, że ma wsparcie sprzętowe, ponieważ do generowania statycznej grafiki akceleracji nie trzeba, w tym przypadku mała wydajność nie jest problemem.
___
p.s. z ciekawości sprawdziłem, ile czasu zajmuje skopiowanie (w wx'ach) bitmapy o rozmiarach 2000x2000. Średnio wyszło ~10ms, czyli nie tak źle.

[Cyfrowy Baron]

No to wina kodu. [...] dlatego pisząc kontrolki zawsze przechwytywałem komunikat WM_PAINT

W opisanej sytuacji brak jakiegokolwiek kodu. Umieszczam obiekt Image na ScrollBox, a w Image dużą bitmapę. Podczas przewijania ScrollBox i co za tym idzie Image powstają artefakty, czyli opóźnienie w odświeżaniu obiektu Image. Nie wiem co miałby zmienić komunikat WM_PAINT skoro TImage obsługuje zdarzenie OnPaint więc zawiera już obsługę WM_PAINT.

---

Przy każdym odmalowaniu ładowana z pliku?

Nie z pliku lecz z bufora.

---

Hmm, na WinXP też? Masz jakieś linki do oficjalnych informacji na ten temat? Bo ja ilekroć spotykałem się z tematami o GDI+, to zawsze była mowa o braku sprzętowego wsparcia.

Tutaj akurat masz rację. W Windows XP brak wsparcia sprzętowego dla GDI+ więc jest mniej wydajne od standardowego GDI. Co do nowszych systemów - nie wiem.

---

Tu taka mała ciekawostka: jedno z dem biblioteki AGG [...]

To akurat nie dotyczy tego problemu, gdyż w przykładowej aplikacji mamy jednolite białe tło, na którym rysowane są inne obiekty. Ja rozważam sytuację w której tłem jest bitmapa, a rysowane obiekty muszą obsługiwać przeźroczystość. Być może dałoby się osiągnąć lepszą wydajność, gdyby zamiast standardowego usuwania przeźroczystości posłużyć się bitmapami 32-bitowymi z kanałem Alfa, ale nie wiem czy standardowe GDI to obsługuje.

[polymorphism]

W opisanej sytuacji brak jakiegokolwiek kodu.

Kod jest, tyle że nie Twój. Problem leży w VCL-u...

Nie wiem co miałby zmienić komunikat WM_PAINT skoro TImage obsługuje zdarzenie OnPaint więc zawiera już obsługę WM_PAINT.

Ja musiałem, żeby nie mieć wspomnianych problemów.

To akurat nie dotyczy tego problemu, gdyż w przykładowej aplikacji mamy jednolite białe tło, na którym rysowane są inne obiekty.

To nic, rasteryzacja grafiki wektorowej¹⁾ z antialiasingiem jest bardziej skomplikowanym procesem niż przekopiowanie bitmapy z kanałami alfa. Ta biblioteka wszystko implementuje po swojemu, żadnego GDI (poza oczywiście wyrzuceniem gotowej bitmapy na okno). Wbij sobie na stronę tej biblioteki, będziesz miał tam przykłady z alfablendingiem.

^{1) to, co masz w tym demie to grafika wektorowa, żadnych bitmap.}

(...) gdyby zamiast standardowego usuwania przeźroczystości posłużyć się bitmapami 32-bitowymi z kanałem Alfa, ale nie wiem czy standardowe GDI to obsługuje.

Z tego co wiem, GDI nie obsługuje bitmap RGBA.

[Cyfrowy Baron]

Kod jest, tyle że nie Twój.

Jak pisałem zero kodu - dwa obiekty jeden na drugim.

Problem leży w VCL-u...

Obiekt typu TImage to tylko zbiór narzędzi, podobnie jak TCanvas, czyli takie rozbudowane TCanvas wzbogacone o klasę TPaint. Obiekt typu TImage nie posiada własnej powierzchni, lecz korzysta powierzchni obiektów zbudowanych miedzy innymi o klasę TWinControl.

Ja musiałem, żeby nie mieć wspomnianych problemów.

Pokaż w jaki sposób użycie WM_PAINT może cokolwiek zmienić w obsłudze TImage.

1) to, co masz w tym demie to grafika wektorowa, żadnych bitmap.

O grafice wektorowej wiem bardzo niewiele. Jeżeli to grafika wektorowa to jest zbudowana z polygonów jak sądzę lub czegoś podobnego. GDI wektorów nie obsługuje, a w środowisku C++Builder brak bibliotek do obsługi grafiki wektorowej.

Z tego co wiem, GDI nie obsługuje bitmap RGBA.

GDI+ chyba obsługuje.

[polymorphism]

Jak pisałem zero kodu - dwa obiekty jeden na drugim.

To, że nie widzisz kodu, nie znaczy, że go nie ma.

Obiekt typu TImage to tylko zbiór narzędzi (...)

Nie, TImage to klasa, która posiada bitmapę z przypisanym do niej kontekstem pamięciowym. Dodatkowo obiekt tej klasy jest podpięty pod obsługę WM_PAINT okna, do którego należy.

Pokaż w jaki sposób użycie WM_PAINT może cokolwiek zmienić w obsłudze TImage.

A gdzie ja pisałem o TImage? Pisałem, że takich rzeczy, czyli gier lub specyficznych kontrolek, nie robi się na komponentach¹⁾... w każdym razie ja nigdy nie robiłem.

GDI wektorów nie obsługuje, a w środowisku C++Builder brak bibliotek do obsługi grafiki wektorowej.

A linii, okręgów, wielokątów, krzywych rysować nie możesz? Mylisz się, GDI posiada obsługę grafiki wektorowej. Odsyłam chociażby do działu "Paths" z niezawodnego PSDK.

GDI+ chyba obsługuje.

Obsługuje.

____
^{1) w rozumieniu rzeczy wyklikanych z palety BCB.}