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.
polymorphizm napisał(a):No nie żartuj GDI spokojnie sobie poradzi, nawet przy kilkudziesięciu klockach.
gregory napisał(a):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
Cyfrowy Baron napisał(a):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.
jeżeli plansza będzie duża to pojawi się problem z płynnym przesuwaniem klocka po planszy
Swego czasu próbowałem zrobić sobie taką grę, w której animowany pies biegał po planszy w miejsce wskazane myszą.
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.
Przecież mowa o puzzlach, a nie o shooterze, gdzie każda klatka się liczy.
A w czym był ten animowany pies?
Po prostu do pewnych rzeczy nie warto angażować bibliotek, które tylko skomplikują zadanie (przypominam, mowa o puzzlach 4x4).
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).
(...) 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 czym było to tło?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.
Znacznie prościej i szybciej da się to zrobić w GDI+.
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.
A czym było to tło?
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ść.
Umieść na obiekcie ScrollBox duży obiekt Image i przewijaj grafikę za zobaczysz to "rozwarstwiania" lub może raczej powielanie pikseli.
A czym mogło być - bitmapą.
Już to chyba kiedyś wyjaśniałem, GDI+ ma wsparcie sprzętowe.
Dziś już chyba niemal wszystkie programu graficzne korzystają z GDI+ (...)
No to wina kodu. [...] dlatego pisząc kontrolki zawsze przechwytywałem komunikat WM_PAINT
Przy każdym odmalowaniu ładowana z pliku?
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.
Tu taka mała ciekawostka: jedno z dem biblioteki AGG [...]
W opisanej sytuacji brak jakiegokolwiek kodu.
Nie wiem co miałby zmienić komunikat WM_PAINT skoro TImage obsługuje zdarzenie OnPaint więc zawiera już obsługę WM_PAINT.
To akurat nie dotyczy tego problemu, gdyż w przykładowej aplikacji mamy jednolite białe tło, na którym rysowane są inne obiekty.
(...) 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.
Kod jest, tyle że nie Twój.
Problem leży w VCL-u...
Ja musiałem, żeby nie mieć wspomnianych problemów.
1) to, co masz w tym demie to grafika wektorowa, żadnych bitmap.
Z tego co wiem, GDI nie obsługuje bitmap RGBA.
Jak pisałem zero kodu - dwa obiekty jeden na drugim.
Obiekt typu TImage to tylko zbiór narzędzi (...)
Pokaż w jaki sposób użycie WM_PAINT może cokolwiek zmienić w obsłudze TImage.
GDI wektorów nie obsługuje, a w środowisku C++Builder brak bibliotek do obsługi grafiki wektorowej.
GDI+ chyba obsługuje.
Użytkownicy przeglądający ten dział: Brak zalogowanych użytkowników i 1 gość