atarionline.pl game engine #1 - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorxxl
    • CommentTime26 Jan 2017 zmieniony
     
    przykladowy max uproszczony: plansza, potworki, fanty (interkacja z tlem lub skarby), bohater:

    1. generowanie planszy (grafika i atrybuty) w buforze1,
    2. kopiowanie bufora1 do bufora2
    3. aktualizacja stanu potworkow
    4. aktualizacja stanu bohatera
    5. rysowanie bohatera w buforze2
    6. rysowanie potworkow w buforze2
    7. aktualizacja stanu fantow
    8. rysowanie fantow w buforze2
    9. aktualizacja planszy (grafika i atrybuty) w buforze1
    10. kopiowanie bufora2 na ekran
    11. goto 2

    wyjasnienie atrybutow: kolizje z tlem oraz fantami odbywa sie na podstawie zapisow w pamieci atrybutow.

    jakie sa Wasze algorytmy. jak sprawdzacie kolizje, jaka organizacja ekranu (znakowy/graficzny) itp. wady/zalety...
    • 2:
       
      CommentAuthorTheFender
    • CommentTime26 Jan 2017 zmieniony
     
    xxl podałeś uproszczony algorytm samej wizualizacji gry. Pytasz o konkretną realizację sprawdzania kolizji z tłem i potworkami na A8 czy ogólnie o algorytm platformera, który na maluchu działałby sensownie?
    ---- ---- - -
    P.S. warunkowe 9.goto 1 : wprowadzi możliwość modyfikacji realitme planszy :) (otwarcie/zamknięcie obszaru, zapadnięcie obszaru itd).
    • 3: CommentAuthorxxl
    • CommentTime26 Jan 2017 zmieniony
     
    uaktualniono o interakcje z tlem :-)

    tak, pytam o badanie kolizji z tlem/przeszkadzajkami/skarbami...


    ---
    mozna nawet zrobic szablon pod game makera :D
    • 4:
       
      CommentAuthorshanti77
    • CommentTime26 Jan 2017
     
    U mnie w uproszczeniu:

    1. Czyszczenie ekran1
    2. Przesunięcie planszy zależnie od stanu joysticka (zmiana aktualnej pozycji)
    3. Rysowanie planszy na ekran1
    4. Aktualizacja stanu obiektów + kolizje + rysowanie wszystkiego co jest obecnie widoczne na ekran1
    5. przełączenie obrazu na ekran1
    6. Czyszczenie ekran2
    7. Przesunięcie planszy zależnie od stanu joysticka (zmiana aktualnej pozycji)
    8. Rysowanie planszy na ekran2
    9. Aktualizacja stanu obiektów + kolizje + rysowanie wszystkiego co jest obecnie widoczne na ekran2
    10. przełączenie obrazu na ekran2
    11. goto 1

    Kolizje to coś takiego:
    for i=5 to 0
    for ii=3 to 0
    if (abs(i[x]-ii[x])<= ZAKRESX) && (abs(i[y]-ii[y])<=ZAKRESY) then ...

    gdzie "i" to np. indeks przeciwników a "ii' to indeks strzałów
    • 5:
       
      CommentAuthormaly_swd
    • CommentTime26 Jan 2017
     
    Kolizje najpierw w dużych obszarach z dokładnością do znaku (8x8, 4x8). A jak zachodzi kolizja na znaku to dopiero pixel do pixela.

    Nie wiem czy o to Ci chodziło:)
    • 6:
       
      CommentAuthorTheFender
    • CommentTime26 Jan 2017 zmieniony
     
    xxl robisz sobie mapę poziomu w tablicy dwuwymiarowej, gdzie np 0 to powietrze, 1 ziemia/murek, 2 drzwi.
    Sprawdzasz na ktorym kwadracie jest postać i ktory kierunek jest przyciśnięty. Sprawdzasz odpowiednią kolizję, w sensie np jeśli w prawo to sprawdzasz czy nie ma ściany/ziemi z prawej. Czyli sprawdzasz, czy pod daną x,y nie istnieje przeszkoda uniemożliwiająca ruch.
    Grawitacja (bo przecież można spaść) - gdzie podczas lotu sprawdzasz x,y pod graczem.

    To tak baaardzo ogólnie i z grubsza i w ogóle, na sieci jest trochę stuffu zwanego "platform game engine", dla Ciebie nie powinno to być nic trudnego zaimplementować i każdy post podobny mojemu to jest marnowanie miejsca i czasu Twojego na czytanie ;)

    A co do implementacji w A8 asm nie wypowiadam się, bo się nie znam kompletnie.
    • 7: CommentAuthorKonop
    • CommentTime26 Jan 2017
     
    renderFrame() // w offscreen buforze.
    {
    clearSprites();
    processObjects(); // aktualizacja stanu/pozycji/animacji
    collisionDetection(); // aktualizacja stanu/animacji
    renderSprites();
    swapBuffers(); // offscreen <-> visible
    }

    W Ryśku - jak wiesz - mam detekcję kolizji opartą na wykrywaniu części wspólnej pomiędzy prostokątami otaczającymi obiekty. Nie ma potrzeby realizowania tego dokładniej. Zabiło by to wydajność, gdyby chcieć to zrobić "pixel-perfect".

    Detekcja kolizji z tłem (murki, platformy) jest w niektórych przypadkach upierdliwa. Gdy prędkość spadania/skoku przekracza wysokość platformy (8 pikseli) w celu wykrycia kolizji należałoby dokonać testu przecięcia dwóch linii. Przy założeniu, że prędkość nie będzie większa niż 8, można to uprościć. Możemy mieć jednoczesny ruch w poziomie i pionie...

    Organizacja ekranu - poprzeplatane wiersze 2 zestawów znaków na zmianę. Liniowy bufor obrazu. Kody znaków nieuszeregowane liniowo w buforze, a umieszczone na podstawie definicji z mapy.
    • 8:
       
      CommentAuthorTheFender
    • CommentTime26 Jan 2017 zmieniony
     
    Procedura skoku/spadania dała mi w kość swego czasu.
    Ponieważ animacja skoku posiada opóźnienie i przyspieszenie zaczynają się pojawiać wartości niebędące popularnymi krotnościami :) I teraz mamy test na walnięcie głową w sufit(przy wznoszeniu) a potem, przy opadaniu test noga-gleba. To dwie procedury do jednego skoku, wywoływane w zależności od stanu (czy postać się wznosi, czy też opada). Wiele razy postać utknęła mi głową w suficie albo kolanami w platformie. No więc tutaj zacząłem skrupulatnie badać przed kolejną wizualizacją pozycji gdzie współrzędne wypadną. Jeśli wypadały w suficie/w glebie zaokrąglałem do najbliższej wartości która dawała bezpieczną pozycję. A potem wizualizacja. Możliwe, że da się to zrobić prościej a ja zagmatwałem. Niemniej było to skutecznie i podczas działania postać podczas skoku waliła głową w sufit (limit górny) i nie leciała dalej, a podczas opadania zawsze stawała na glebie tak jak trzeba (limit dolny). Oczywiście można zmieniać wektor ruchu podczas skoku i opadania, co generuje kolejne "nietypowe" wartości x,y z którymi trzeba sobie poradzić.
    • 9: CommentAuthorxxl
    • CommentTime26 Jan 2017
     
    @TheFender; @Konop: mam podobne zdanie co do pamieci atrybutow - dobry pomysl, ma swoje ograniczenia ale tez ma tyle zalet ze jest po prostu nieodzowny. kolizje z tlem i fantami najszybciej realizowac taka metoda, to sa najczesciej nieruchome obiekty, grafika nie musi wypelniac calej "powierzchni" jaka zajmuje atrybut.

    @shanti77: kolizje na wspolrzednych. indeksy tez powinny moim zdaniem miec zakresy - przyklad: w tablicy pociskow masz zapisan pociski przeciwnikow i swoje - czy pociski przeciwnikow powinny wywolywac kolizje z innymi przeciwnikami a pociski twoje z bohaterem? - ogolnie taka metode zaobserwowalem chociazby w asteroids - jest szybka.
    obraz dwu buforowy to jest genialne (bardzo szybkie) przy pewnych zalozeniach - ograniczeniam jest np. obraz gry nie mozna dowolnie mapowac na ekran... ale ogolnie swietny pomysl - na razie nie aktualizuje bo musze sprawdzic :D
    • 10:
       
      CommentAuthorTheFender
    • CommentTime27 Jan 2017
     
    @xxl: zamieścisz jakiś filmik albo screenshoty? :)
    • 11: CommentAuthorxxl
    • CommentTime28 Jan 2017
     
    jeszcze nie teraz. nie przetestowane kolizje no i dwubuforowanie a to moze sporo zmienic... to trwa ale na pewno ten watek bedzie mial ciag dalszy. chce zaprojektowac "szablon" na ktorym moznaby w miare szybko pisac gierki :)
    • 12:
       
      CommentAuthorTheFender
    • CommentTime28 Jan 2017
     
    Chciałoby się rzecz "dlaczego dopiero teraz? ..."
    .
    .
    .
    .
    Ale tak nie powiem :) Trzymam kciuki xxl :)
    • 13: CommentAuthorxxl
    • CommentTime10 Feb 2017
     
    - pamiec atrybutow jest zupelnie niezalezna od grafiki, tak, ze jeden kafelek moze miec zupelnie rozne atrybuty w zaleznosi od kontekstu.
    - 256 kafelkow rozmiaru 8x8
    - kolizje na atrybutach uzaleznione od klatki animacji (o wiele dokladniejsze - zdawac by sie moglo, do 2pikseli)
    - brakuje tu jeszcze wieluuu elementow, ale beda demonstrowane przetestowane i prawidlowo dzialajace.


    • 14: CommentAuthorKonop
    • CommentTime10 Feb 2017
     
    Pomyśl o drugiej warstwie tileset'ów, z makroblokami MxN (np. 2x2, 4x4) nad zestawem 8x8/4x8. Taki sposób kodowania znacznie oszczędza pamięć na definicję mapy. W Rick'u dzięki takiemu zabiegowi oszczędzamy 50% pamięci przy makroblokach 4x4.
  1.  
    ale zajebiste:) !! toż to jakieś cudeńko powstaje..:) dziękoova!
    • 16: CommentAuthorGonzo
    • CommentTime11 Feb 2017
     
    xxl - a dało by się żeby ludzik zaper... w prawo?

    ...pozdrawiam wszystkich opornych i topornych polskich "koderów" i ide pograc ATARIBLAST!
  2.  
    :)media markt nie dla...;) albo uderz w stół . za "moich czasów" mało by się znalazło atarowców, którzy by wzięli cię jakimś cudem za kodera.Więc wyluzuj :) napisz coś konkretnego i nie sraj żarem...przepraszam za wyrażenie..nie słowa a czyny a najlepiej jakies XeX'y albo AtR'y ..XXl jest koderem i to dobrym ,niestety nie chce demka zrobić, trudno :)Atari Blast rulez!!
    • 18: CommentAuthorxxl
    • CommentTime11 Feb 2017
     
    @Gonzo: da sie, ale idea gry to napinanie w lewo i konsumpcja fantow, zgodnie z haslem "dobra zmiana" ;-)
    • 19:
       
      CommentAuthorTheFender
    • CommentTime11 Feb 2017
     
    wow! xxl dałeś czadu :) No i to jakże piękne założenie "przeszedłem mario w lewo" róls.

    To, że xxl jest dobrym koderem wszyscy wiemy nie od dzisiaj. Fajnie, że się wziął za konkretną i dosyć ambitną rzecz.
    A robienie demek zostawmy całej reszcie ;)
    --------- ------ ---- --- - -
    Efekt, kiedy giniesz jest bezcenny :D Na game over będzie noga z fusitu?
    • 20: CommentAuthorxxl
    • CommentTime11 Feb 2017
     
    @Konop: w tym momencie skarby sa oddzielna wartstwa tilesow (no ale tez rozmiar 8x8) zastanawiam sie nad wprowadzeniem warstwy tilesow z najwyzszym priorytetem - moglyby zaslaniac np. bohatera - oczywiscie wastwa z interakcja - na filmiku tego nie ma do skarbu typu "klucz" moznaby podpiac program modyfikujacy wastwe tilesow oraz atrybutow - to by bylo ciekawe.
    • 21: CommentAuthortbxx
    • CommentTime13 Feb 2017
     
    "The Best Game" i nawet scrolla nie ma :/
    • 22: CommentAuthorxxl
    • CommentTime13 Feb 2017
     
    celna uwaga, ale zapytam jaki scroll?

    scroll gdzie pole gry jest rowne szerokosci ekranu?

    scroll gdzie cala mapa gry znajduje sie w pamieci a okno scrolowane jest nad jej zawartoscia?

    scroll gdzie mapa gry jest wieksza od okna wyswietlania o 1 kafelek?
    • 23: CommentAuthornosty
    • CommentTime13 Feb 2017
     
    @XXL, bardzo to zgrabne, jako fan runnerów kibicuję całym sercem. Ale mnie też ciekawi czemu w lewo? :)
    Wiesz, fakt że 99% gier jednokierunkowych ma zwrot akcji w prawo to nie przypadek tylko efekt naszej psychiki i cywilizacji. Podobno większość ludzi intuicyjnie wiąże upływ czasu, a więc i postęp akcji z takim kierunkiem. Dla runnerów to ma szczególne znaczenie.
    Czyli jeśli nie ma to jakiegoś sensownego zakotwiczenia w fabule, to ryzykujesz, że gracze będą czuli niepokój czy mieli podświadome poczucie, że "coś tu nie gra".
    Innymi słowy: ryzykujesz, że gra dostanie niższe noty niż dostałaby taka sama gra, ale ze zwrotem w prawo.
    Dlatego jestem ciekaw skąd taki zabieg?
    • 24: CommentAuthorxxl
    • CommentTime13 Feb 2017 zmieniony
     
    jesli ruch w prawo wiekszosc ludzi wiaze z uplywem czasu to ruch w lewo beda wiazac z powrot do czasow dziecinstwa a wiec gra bedzie wywolywac nostalgie.

    a jesli chodzi o niepokoj... to gracz go odczuje na bardzo krotko, juz po kilku sekundach bedzie to zupelnie inne odczucie - nie bez powodu masz do dyspozycji 1 milion zyc.
    • 25: CommentAuthormav
    • CommentTime13 Feb 2017
     
    Cofanie do początku jednakowoż faktycznie może szybko wywołać frustrację :)
    • 26:
       
      CommentAuthorTheFender
    • CommentTime13 Feb 2017
     
    ad a) gdzie pole gry jest większe o 1 kafelek.
    ad b) wykresy w szkole podstawowej są rysowane w prawo
    nawet domyślnie rzędne i odcięte rysuje się jako osie dodatnie
    w cywilizacjach europejskich pisze się z lewej do prawej
    prawe oko uważa się za dominujące (błąd) i nawet przy celowaniu celuje się prawym okiem
    menu start jest po lewej i wszystko co się dzieje na pulpicie dzieje się na prawo od niego
    po angielsku right znaczy właściwie
    po polsku prawy znaczy nieskazitelnie dobry
    prawo i sprawiedliwość
    • 27:
       
      CommentAuthorIRATA4
    • CommentTime13 Feb 2017
     
    Kto oglądał Midnight Express ten wie czemu w drugą strone;)
    • 28:
       
      CommentAuthorIRATA4
    • CommentTime13 Feb 2017
     
    Tak patrze i patrzę a tu prawie Mytch powstaje :). Na pewno bede w to grał.
    • 29: CommentAuthorxxl
    • CommentTime13 Feb 2017
     
    @mav: cofanie bedzie do tej samej planszy.

    @TheFender: a scrollowany obraz szerokosci sprzetowego obrazu?
    • 30: CommentAuthortbxx
    • CommentTime13 Feb 2017
     
    @xxl - faktycznie nie wyraziłem się zbyt precyzyjnie, się tam na technikaliach nie znam, ale chodzi o taki scroll jak Mario idzie w prawo tylko że w lewo ;)

    @nosty - najwyraźniej xxl celuje w rynki dalekowschodnie - tam np. czytanie od prawej do lewej jest normalne ;)
    • 31:
       
      CommentAuthorTheFender
    • CommentTime13 Feb 2017
     
    @irata4: raczej Mych (pogromca kotów) ;)
    • 32: CommentAuthorilmenit
    • CommentTime14 Feb 2017
     
    Kilka pytań:
    - czy jest to na znakach ze zmianą fontów, czy to czysty tryb graficzny?
    - jako wygląda możliwość przeniesienia na inną rozdzielczość (kolorową)?
    - ile to by mogło obsłużyć ruchomych obiektów? Mam na myśli potworki + pociski?
    - jak wygląda kwestia kolizji? Czy można mieć na nią wpływ? Standardowo zmniejsza się rozmiar kolizji z przeszkadzajkami a zwiększa z dobrymi przedmiotami jak na przykład monety.
    - czy engine może wspierać scroll / plansze większe niż 1 ekran?
    • 33: CommentAuthorxxl
    • CommentTime14 Feb 2017
     
    1. w tym momencie tryb graficzny co pozwala zrobic pixel mono 1x2, kolor 2x1 itd. nie ma zadnego probblemu zeby w buforze funkcjonowal tryb graficzny kopiowany na fonty i tak wyswietlane.
    co wiecej, nasz bufor moze byc szerokosci 32 bajty a ekran 40. ja wybralem technike obrazu dwubuforowego dlatego zdecydowalem sie na tryb graficzny.

    2. zaden problem - zmiana trybu antica

    3. to "zalezy" ;-) od wielkosci ekranu, jaka metode umieszczania spritow - eor, z maska and/ora, kasowania spritow (niektorzy zachowuja tlo sprita i pozniej go przywracaja a niektorzy kopiuja caly bufor z obrazem tla na ktory nakladaja obiekty).
    obecnie 5-16x16 i 8-8x8 ale to bylo przy kopiownaiu buforow, przy obrazie dwubuforowym nie wiem, ale musialem robic synchronizacje z VBI bo zdazalo sie ze wyswietlany bufor byl zamazwany (czyli silnik dziala szybciej niz 1xramke). wedlug mnie akceptowana szybkosc to 2 ramki.

    4. tak. kolizje z fantami realizowane sa na atrybutach i faktycznie sa malo rygorystyczne :-)
    to samo zrobilem z kolizjami tla - kolizje analizowalem na podstawie JSW - na szczescie napisalem inne gdzie brana jest pod uwage rowniez faza ruchu. proponuje porownac to co jest w JSW a tu. kolizje z potworkami na wspolrzednych lub pixel perfect (kopiujesz potworka i jak cos przykrywa to kolizja) - ograniczenie takie ze musisz miec typy potworkow ktore sa rysowane na odpowiednim tle ;-) dlatego wole wspolrzedne.

    5. tu mam zagwozdke. wczesniej juz pisalem - jaki scroll?
    mozna miec scroll w okienku (niektore gry na zx spectrum tak maja) albo caly obraz z wycieta kolumna po prawej i lewej (soft scroll) albo sprzetowy z ekranem wiekszym o 1 kafelek lub cala mapa w pamieci. mam co prawda juz dwie wersje scrolla HV - z kafelkiem 8x8 oraz 16x16 jednak nie testowane :/ moze wcale nie dziala :D
    • 34:
       
      CommentAuthortdc
    • CommentTime14 Feb 2017
     
    Piękne!
    • 35:
       
      CommentAuthortdc
    • CommentTime15 Feb 2017 zmieniony
     
    Ja bym proponował skorzystać, z triku który eliminuje potrzebę wykorzystywania podwójnego buforowania (opisał to kiedyś w swoim artykule Fox w jednym z pierwszych numerów Atarynki):

    Wyeliminowanie podwójnego buforowania oszczędza pamięć oraz bardzo przyspiesza bo np. kopiowanie bufora itp. jest bardzo czasochłonne (coś wiedzą o tym Commodore'owcy ;)

    Czyli z tego:

    xxl:

    1. generowanie planszy (grafika i atrybuty) w buforze1,
    2. kopiowanie bufora1 do bufora2
    3. aktualizacja stanu potworkow
    4. aktualizacja stanu bohatera
    5. rysowanie bohatera w buforze2
    6. rysowanie potworkow w buforze2
    7. aktualizacja stanu fantow
    8. rysowanie fantow w buforze2
    9. aktualizacja planszy (grafika i atrybuty) w buforze1
    10. kopiowanie bufora2 na ekran
    11. goto 2

    ...usuwamy niepotrzebne punkty i mamy:
    1. generowanie planszy (grafika i atrybuty) w buforze1,
    2. aktualizacja stanu potworkow
    3. aktualizacja stanu bohatera
    4. aktualizacja stanu fantow
    5. goto 2

    W Twoim przykładzie gry na YT trik ten wyjątkowo fajnie i łatwo można zastosować, bo np. Fox w żadnym demie (czy grze) nie miał tak dużej swobody jak Ty w tej grze.

    Zyski są proste:
    - uproszczenie całego algorytmu
    - przyspieszenie przez wyeliminowanie np. odrysowywania obiektów na obu buforach (bo mogą pozostać śmieci)
    - przyspieszenie poprzez wyeliminowanie kopiowania buforów , co jest tak bardzo czasochłonne jak duży jest bufor (najczęściej na cały ekran!) (czyli zmora Commodore'a :P)
    - oszczędność pamięci - co jest szczególnie cenne na 8-bit

    Link do artykułu w sieci.

    Ja ten trik wykorzystuję we wszystkich grach (również tych, które napisałem w latach 80. np. w Matematyce (Mirage), Moontek, Bomb Jack itp.). Ostatnio zacząłem wykorzystywać podwójne buforowanie w moich strzelankach (ale to z innej przyczyny; wzrost wydajności osiągam w inny sposób) np. w At Arion Line II (jeszcze nie ukończona gra, ale można ją zobaczyć na wykładzie p.t Nowe tryby graficzne Atari na YT).
    • 36: CommentAuthorxxl
    • CommentTime15 Feb 2017
     
    :-) gdybym mial wystarczajaco czasu procesora :-)
    • 37:
       
      CommentAuthormaly_swd
    • CommentTime15 Feb 2017
     
    A czy nie można połączyć zalet podwójnego bufora z brakiem przepisywania bufora?

    Tzn modyfikując DL (adres obrazu)?
    Czyli rysujesz na niewidocznym, przełączasz DL i rysujesz znowu na niewidocznym.
    • 38: CommentAuthorxxl
    • CommentTime15 Feb 2017
     
    Na tym polega obraz dwubuforowy i dokladnie tak to sie odbywa w best game. Jakiekolwiek operacje zapisu wykonywane sa na czesci niewyswietlanej.
    • 39:
       
      CommentAuthormaly_swd
    • CommentTime15 Feb 2017
     
    2. kopiowanie bufora1 do bufora2 - sugerowałem się tym wpisem. Czy on coś innego oznacza?
    • 40: CommentAuthorxxl
    • CommentTime15 Feb 2017
     
    jesli odnosisz sie do pierwszego posta to dobrze myslisz. pierwszy post nie zostal zaktualizowany o realizacje obrazu dwubuforowego - rowniez filmik to wersja silnika bez obrazu dwubuforowego. przy kolejnym filmiku obejmujacy wszystkie opisywane zmiany zaktualizuje pierwszy post.
    • 41:
       
      CommentAuthormaly_swd
    • CommentTime15 Feb 2017
     
    Tdc mnie zmylił postem 35. Już teraz wszystko jasne.

    ps. Kawał dobrej roboty robisz.
    • 42:
       
      CommentAuthortdc
    • CommentTime15 Feb 2017 zmieniony
     
    Ok.

    @maly_swd, kopiowanie jest potrzebne w podwójnym buforowaniu o ile wymaga to dana gra. Rozwiązania:
    Przykładowo wszystkie potrzebne zmiany można robić wraz z odrysowaniem wszystkich postaci/obiektów w grze tzn. mogą oni rysować więcej niż same postacie. Co prawda samo w sobie jest to już optymalizacją wyświetlania/animowania, jednak wymaga odrysowywania wszystkich postaci na każdy bufor.
    Innym przypadkiem jest gdy trzeba odrysować całość lub sporą część tła, np. podczas scrollingu, czyli przepisujemy całość wraz z przesunięciem (tak jak w scrollu na C=).

    U XXLa nie ma scorlla, więc tu można jedynie narysować całość podczas wejścia do danej lokalizacji. Sprawę psują poruszające się postacie, które muszą odrysować to co zasłaniały, jednak nie jest to tak kłopotliwe w tym przypadku (na razie) bo tu nie ma postaci które by się poruszały z prędkością kilku znaków. Poruszanie z prędkością kilku znaków powodowałoby potrzebę odrysowania tła za postacią w adekwatnej wielkości i to na wszystkich buforach.
    • 43: CommentAuthorxxl
    • CommentTime15 Feb 2017
     
    na szczescie u xxl nie ma odrysowywania tego co obiekty zaslanialy
    • 44:
       
      CommentAuthortdc
    • CommentTime15 Feb 2017
     
    czary;)
    • 45:
       
      CommentAuthorTheFender
    • CommentTime15 Feb 2017
     
    xczary ;)