[#361] Re: Zapowiedzi nowych gier

@ede, post #360

no to szykuje sie nielada gratka dla Morphos'a
[#362] Re: Zapowiedzi nowych gier

@ede, post #360

Sorki z tą paletą.

Paleta jest ładowana przez SetRGB32CM(), a następnie przez MakeScreen()/RethinkDisplay(), a nie przez SetRGB32() lub LoadRGB32().

Tak zrobiłem bo było mi najwygodniej (SetRGB32CM() jest też dużo szybszy, niż SetRGB32())!

Wygląda na to, że RTG/MorphOS nie wspiera ładowania kolorów przez ColorMap.

@Teh_Kain

Świetna porada, dziękuję. Chciałbym tylko zachować względną zwięzłość nazewnictwa stałych.

Czy mógłbyś napisać co rozumiesz przez RODZAJ i WARTOŚĆ? Chodzi o stałe liczbowe, łańcuchowe, makra?

--
Dzisiaj pracowałem nad logicznym aspektem mapy i ożywiłem ją wprowadzając budynki. Budynki posiadają już podstawowe cechy jak indeks, typ, położenie, status, punkty wytrzymałości oraz statystyki jak nazwę, koszt budowy itp.

Struktura mapy jest złożona z pól. Każde pole przechowuje trzy informacje - rodzaj kafelka, klasę obiektu i indeks obiektu. Budynek jest jedną z klas.

No i opracowałem funkcje alokacji mapy, tworzenia budynku i umieszczania budynku na mapie.

Na razie wyświetlana jest informacja tekstowa. To działanie to wstęp do wprowadzenia mapy rozgrywki i dynamicznych aspektów gry.

@Selur

Byłoby fajnie docelowo zachować kompatybilność z RTG, ale nie mogę tego obiecać. Celuję w Amigę 1200 i na pewno zastosuję różne techniki optymalizacyjne.

Ostatnia aktualizacja: 23.03.2017 22:15:29 przez Hexmage960
[#363] Re: Zapowiedzi nowych gier

@Hexmage960, post #355

Na Retro GameDev Compo w takiej formie się nie kwalifikuje, bo jest obowiązek regulaminowy, oryginalej oprawy graficznej i muzycznej. Znajdz grafika, ktory narysuje ci oryginalna grafike, to nie bedzie problemu.
[#364] Re: Zapowiedzi nowych gier

@twardy, post #363

Dziękuję za odpowiedź.

Rozumiem. Nie wiem, czy znajdę grafika, który przygotuje mi grafikę do RTSa, ale jeśli rzeczywiście ktoś czuje się na siłach mi pomóc to będę wdzięczny. Może kolega Leon mi pomoże.

Do kolegi Leona mam prywatną sprawę: sorki, że jeszcze nie odpisałem Ci na prywatną wiadomość z 13 marca. Miałem PC w serwisie od zeszłego czwartku do wtorku, wszystko sobie powoli układam.

Sam nie dam rady dorobić grafiki.

EDIT:

@Leon
Już Ci odpisałem.

Ostatnia aktualizacja: 23.03.2017 22:30:23 przez Hexmage960
[#365] Re: Zapowiedzi nowych gier

@twardy, post #363

Moglibyscie zrobic wyjatek dla Minniata.
Niech pokaze gre z oryginalna grafika a po Compo sie podmieni na autorska, bo tak zawsze bedzie latwiej skonczyc. ok, racja
[#366] Re: Zapowiedzi nowych gier

@selur, post #365

Spoko, jak się znajdzie grafik to wszystko będzie w porządku. Nawet łatwiej będzie mi napisać taką grę, aniżeli robić Dune 2 AGA. Wystarczy mi parę elementów: teren, parę rodzajów budowli i jednostek, wybuchy i tyle.
[#367] Re: Zapowiedzi nowych gier

@ede, post #360

Specjalnie dla kolegi Ede wersja demka z LoadRGB32(). Paleta powinna być poprawna w MorphOS.

Archiwum zawiera zaktualizowany kod źródłowy ze stałymi symbolicznymi.
[#368] Re: Zapowiedzi nowych gier

@Hexmage960, post #367

Potwierdzam. Działa jak powinno (tzn. żadnych przekłamań kolorów, wciskanie przycisków działa).
[#369] Re: Zapowiedzi nowych gier

@recedent, post #368

No i super. OK
[#370] Re: Zapowiedzi nowych gier

@Hexmage960, post #362

Stałe. Mam sobie np. plik vehicle.h, w którym mam takie oto stałe:
#define VEHICLE_TYPE_COUNT 4
#define VEHICLE_TYPE_TANK 0
#define VEHICLE_TYPE_CHOPPER 1
#define VEHICLE_TYPE_ASV 2
#define VEHICLE_TYPE_JEEP 3

#define VEHICLE_BODY_WIDTH 32
#define VEHICLE_BODY_HEIGHT 32
#define VEHICLE_BODY_ANGLE_COUNT 64
#define VEHICLE_TURRET_WIDTH 32
#define VEHICLE_TURRET_HEIGHT 32

/// Vehicle-specific constants
#define VEHICLE_TANK_COOLDOWN 25

Pierwszy człon idzie z nazwy pliku, drugi to "kto lub co", trzeci precyzuje drugi. Stałe VEHICLE_TYPE_* idą do pola ubType struktury tVehicle. Może lepszy przykład będzie z bunker.c:
// Bunker gamestate modes
#define BUNKER_MODE_INVALID 0
#define BUNKER_MODE_CHOICE 1
#define BUNKER_MODE_ELEVATOR_TO_VEHICLE 2
#define BUNKER_MODE_VEHICLE_TO_ELEVATOR 3
#define BUNKER_MODE_ELEVATOR_TO_SURFACE 4
#define BUNKER_MODE_MAP 5

#define BUNKER_ANIM_FRAMES 100
#define BUNKER_FADE_FRAMES 16

#define BUNKER_MAP_TILE_SIZE 4

O ile ostatnie 3 to stałe do pierdółek, to BUNKER_MODE odnoszą się do dozwolonych wartości zmiennej globalnej s_ubMode. I jak łatwo się domyślić w pliku vehicle jest wszystko o pojazdach, a w bunker wszystko o bunkrze. ;)
[#371] Re: Zapowiedzi nowych gier

@teh_KaiN, post #370

@Teh_Kain: Dzięki, już wiem o co się rozchodzi.

--
Czy mógłby podpowiedzieć mi ktoś czego najlepiej użyć do pakowania danych (grafiki). Grafiki będzie sporo i warto ją czymś spakować. Czy polecacie PowerPacker, XPK czy może coś innego? Ja wstępnie skłaniam się ku PowerPackerowi.

Druga sprawa. Procedury będą optymalizowane, ale wewnątrz. Oznacza to, że będzie istnieć odpowiednie API, np WczytajObrazek(), ale w środku to może być nawet kod w asemblerze. Generalnie chodzi o to, by API było w C, żeby kod był przejrzysty i czytelny, ale implementacja procedur wymagających szybkości będzie nawet w asemblerze.

Tym sposobem uda mi się osiągnąć odpowiednią szybkość na Amidze oraz działanie na urządzeniach RTG.

Projekt posuwam do przodu. Następnym celem po poprzednim demku jest ekran główny gry z podglądem mapy.
[#372] Re: Zapowiedzi nowych gier

@Hexmage960, post #371

Optymalizacje zostaw na koniec. Teraz niech i nawet gigabajt na dysku gra zajmuje i niech się włącza w rozsądnym czasie, czyli bez kompresji. Jak wszystko będziesz miał skończone, to wtedy się baw w optymalizacje, bo te zawsze idą kosztem czegoś.

Jak będziesz miał wszystko skończone, to będziesz widział gdzie i jak możesz kroić, by przyniosło to dobry efekt. Z drugiej strony pewne rzeczy warto robić od razu, ale to są rzeczy, które do głowy przychodzą w sposób oczywisty i nie wymagają dłuższego zastanowienia.

Z tym optymalizowaniem "wewnątrz" to jest to bardzo dobry pomysł, tylko warto się zastanowić gdzie się to "wewnątrz" zaczyna. Bo funkcja wywołuje funkcje, one kolejne funkcje... Lepiej chyba wszystko pisać w C, bo zabawę na rejestrach OCSa i tak tam możesz robić, a przejrzyściej do debugowania przy okazji będzie, i właśnie dopiero ostatnim rzutem po wyeliminowaniu wszystkich bugów kroić na szybkość.
[#373] Re: Zapowiedzi nowych gier

@teh_KaiN, post #372

Już myślę o kompresji nieco do przodu, bo nigdy jej nie używałem (prócz prostej kompresji plików ILBM i 8SVX). Chciałbym nauczyć się jej używać. Zarówno PowerPacker jak i XPK udostępnia wygodne funkcje w formie bibliotek operujące na skompresowanych plikach.

Chciałbym poznać i poćwiczyć dekompresję.

Poza tym jak nagromadzi się plików do czytania (już w poprzednim demku jest kilka plików IFF do czytania), to wówczas warto dane skompresować by mniej zajmowały miejsca i szybciej się wczytywały z dysku.

Myślę też by zastąpić Datatypy przez szybkie funkcje czytające obrazki i dźwięki, bo Datatypy najbardziej przydatne są w programach użytkowych. Tutaj będzie prosto, bo zamierzam grafikę i dźwięki trzymać w IFF.

No i właśnie na potrzeby tej gry piszę własne API, które przysłania implementację. Chodzi o takie funkcje jak obsługa obrazu wideo, rysowanie, czytanie danych, dekompresja, reakcja na klawiaturę i mysz. Te rzeczy wymagają szybkości.

Większość tych funkcji niskopoziomowych będzie w asemblerze, zaś spoiwo będzie robione w C.

Zatem w asemblerze będą pisane funkcje proste, nieskomplikowane, nie wymagające skomplikowanych obliczeń i operacji. Głównie rysowanie za pomocą Blittera oraz obsługa przerwań i odczyt stanu myszy i klawiatury. Te rzeczy naprawdę warto zrobić w asemblerze.

Z kolei w C będę korzystał z takich funkcji napisanych w asemblerze by stworzyć bardziej złożone konstrukcje, jak np. rysowanie panelu dowodzenia, szukanie ścieżki dla jednostek, czy obsługa budowy budynku, robienie listy obiektów do narysowania itp.

Także plan jest dosyć jasny.

Dzięki własnemu API będę mógł testować kilka rozwiązań, no i moja gra może zadziałać na systemach NG. Generalnie chcę korzystać z dobrodziejstw systemu tam, gdzie można. No i moja gra będzie przyjazna systemowi - będzie alokować kanały dźwiękowe, alokować pamięć, korzystać z View oraz instalować własne serwery przerwań. Bez "uderzania" w sprzęt, czyli rejestry inne niż Blittera.

Ostatnia aktualizacja: 25.03.2017 20:29:18 przez Hexmage960
[#374] Re: Zapowiedzi nowych gier

@Hexmage960, post #373

Zarówno PowerPacker jak i XPK udostępnia wygodne funkcje w formie bibliotek operujące na skompresowanych plikach.
XPK jest lepsze bo pozwala na dobranie algorytmu do rodzaju kompresowanych danych, bez zmiany kodu ładującego. Z kolei pewną jego wadą jest to, że odpowiednie packery (moduły) muszą być wcześniej zainstalowane, albo dostarczone z grą.

Zatem w asemblerze będą pisane funkcje proste, nieskomplikowane, nie wymagające skomplikowanych obliczeń i operacji. Głównie rysowanie za pomocą Blittera oraz obsługa przerwań i odczyt stanu myszy i klawiatury. Te rzeczy naprawdę warto zrobić w asemblerze.
Nie warto, może z wyjątkiem obsługi przerwań. Rysowanie za pomocą blittera sprowadza się do odpowiedniego wypełnienia jego rejestrów i wystartowania go. Asembler nic tu nie przyspieszy. Podobnie obsługa myszy i klawiatury, sprowadza się do odczytania rejestrów.
[#375] Re: Zapowiedzi nowych gier

@Hexmage960, post #364

Robert, pracuj nad silnikiem, jak bedziesz mial dzialajacy engine to grafik sie znajdzie. Najwyzej na szybko ktos ci skleci grafike tymczasową.
[#376] Re: Zapowiedzi nowych gier

@Hexmage960, post #373

No okej, rób jak chcesz, tylko wiedz, że jak napiszesz sobie teraz jakąś turbo wyspecjalizowaną funkcję, a potem stwierdzisz, że jednak chcesz coś w niej zmienić bo czegoś nie przewidziałeś, to możliwe, że będziesz potrzebował napisać ją jeszcze raz w zupełnie inny sposób. Nie wiem jak Tobie, ale mi takie reimplementacje robi się znacznie łatwiej w C niż asm. Chyba Cahir w swojej riverwashowej pogadance wspominał o tym, że asemblerem i cyklówką można walczyć jeśli w wysokopoziomowym masz te 70-90% wymaganej wydajności, bo o większe oszczędności szybkości kodu raczej ciężko.

Ja wolę pisać z ogółu do szczegółu - zrobić kod działający z grubsza, a potem tylko go szlifować tam, gdzie tego wymaga. No ale każdy do pewnych spraw podchodzi inaczej. ;)
[#377] Re: Zapowiedzi nowych gier

@Krashan, post #374

@Krashan
Jeśli chodzi o Blitter to kod powinien być jak najbardziej zwarty. Należy pamiętać, że nawet proste ustawianie Blittera wymaga kilku obliczeń, m.in. pozycji, modulo, offsetu itp.

Warto zastosować asembler również i w tym przypadku, a szczególnie w funkcjach wywoływanych przez QBlit() i QBSBlit(), które ustawiają procedury rysowania w kolejce.

Gdybym użył C to nie jestem pewien jak kompilator przetłumaczy program. Oczywiście można stosować zmienne rejestrowe (register), ale nadal nie ma gwarancji.

Zamiast gimnastykować się niepotrzebnie z C i jego "humorami" oraz po to, żeby mieć 100% pewność, że kod będzie wyglądać jak chcę warto zrobić prostą procedurę w asemblerze do ustawiania Blittera.

W C często piszę np.:
custom.bltcon0 = ((x&0xf)<<12)|(0x09f0);

Nie mam gwarancji, czy kompilator ładnie to przetłumaczy - czy umieści "custom" w rejestrze adresowym, zaś wyrażenie zapisze najefektywniej używając jak najmniejszych rozmiarów operacji i właściwych instrukcji.

Zaś w asemblerze mam pełną kontrolę.

To tyle, jeśli chodzi o moje zdanie w temacie asemblera oraz C w połączeniu z rejestrami sprzętowymi. Najlepiej w tego typu zagadnieniach sięgnąć po asembler, są to krótkie i nieskomplikowane procedury, ale czas wykonania jest bardzo ważny.

Podobnie obsługa myszy i klawiatury, sprowadza się do odczytania rejestrów.
Czy chodzi Ci o rejestry sprzętowe? Aż tak low-level nie zamierzam stosować, po prostu handler input.device o wysokim priorytecie. Ale i tu warto zastosować asembler, bo input.device dość mocno zajmuje czas procesora.

Generalnie nie można nie doceniać asemblera. Z mojej praktyki, a pisałem wiele silników w asemblerze, gry w asemblerze są szybsze od tych w języku C. W praktyce liczy się każda instrukcja procesora.

Oczywiście w bardziej skomplikowanej grze warto, a nawet trzeba zastosować C lub inny język wyższego poziomu, ale i tu trzeba zachować rozsądek.

Co do PowerPackera i XPK to dzięki, przyjrzę się im nieco bliżej czytając dokumentację.
[#378] [post oznaczony jako OT] wyświetl Re: Zapowiedzi nowych gier
[#379] [post oznaczony jako OT] wyświetl Re: Zapowiedzi nowych gier
[#380] Re: Zapowiedzi nowych gier

@Hexmage960, post #377

Spoko. Jak się bawisz rejestrami blittera to możesz się pobawić moją funkcją i przy okazji powiedzieć mi, co robię nie tak, że kopiowanie z dużego bufora na mały (np. 32 pikseli wszerz) się wali, zwłaszcza gdy źródłowe x,y nie są równymi wielokrotnościami 16. Inni też się mogą wypowiadać. Przesiedziałem nad tą funkcją sporo roboczogodzin i chętnie posłucham uwag, bo mam jej dość. ;)

Co do samego macania blittera, to zdajesz sobie sprawę, że wtedy już odcinasz się od OSu i kod nie ruszy wprost na sprzęcie nowej generacji (chyba że ruszy, bo mają szczątkową emulację custom chipów?)? Tak czy inaczej jest na to rada taka, że później na ifdefie skorzystasz z funkcji systemowych dla szybszych platform, a dla A1200 skorzystasz z własnych rozwiązań.

Ostatnia aktualizacja: 27.03.2017 07:23:40 przez teh_KaiN
[#381] Re: Zapowiedzi nowych gier

@teh_KaiN, post #380

Co do samego macania blittera, to zdajesz sobie sprawę, że wtedy już odcinasz się od OSu i kod nie ruszy wprost na sprzęcie nowej generacji (chyba że ruszy, bo mają szczątkową emulację custom chipów?)?

Zdaję sobie sprawę, dlatego robię odpowiedni interfejs w języku C. Tak, by przesłonić realizację paru spraw wymagających szybkości i związanych z wyświetlaniem, a zarazem uczynić kod czytelnym i przyjemnym w rozwijaniu.

Przecież jak mam własną funkcję "Narysuj", która rysuje wybrany element na ekranie, to w środku może być albo sekwencja kilku instrukcji asemblera uruchamiających Blitter, bądź wywołanie odpowiedniej funkcji z graphics.library w przypadku RTG. W obu przypadkach interfejs jest ten sam i czytelny. Zaś na prędkości nie tracę. I taki efekt chcę uzyskać.

Funkcje będą odpowiednio przygotowywane w zależności od grafiki AGA/RTG, najpewniej będą wskaźniki do funkcji, które będą odpowiednio ustawiane w zależności od architektury graficznej (podczas pracy programu nie trzeba będzie tego wówczas sprawdzać).

Funkcje będą w asemblerze jeśli całość ich wykonania wymaga szybkości.

Choć "czarna robota" z asemblerem mi nie straszna, ulokuję w nim to co najbardziej potrzebne. Bo jak program będzie cały w języku C, nie ma bata, będzie wolno, szczególnie na Amidze bez turbo.

Jak się bawisz rejestrami blittera to możesz się pobawić moją funkcją i przy okazji powiedzieć mi, co robię nie tak, że kopiowanie z dużego bufora na mały (np. 32 pikseli wszerz) się wali, zwłaszcza gdy źródłowe x,y nie są równymi wielokrotnościami 16.

Przyjrzę się temu troszkę później.

Ostatnia aktualizacja: 27.03.2017 08:07:31 przez Hexmage960
[#382] [post oznaczony jako OT] wyświetl Re: Zapowiedzi nowych gier
[#383] Re: Zapowiedzi nowych gier

@Hexmage960, post #381

Przysiadłem dziś wieczorem nad kodem, zrobiłem już zarys API (wyświetlania) i przygotowałem program testowy.

Program testowy powinien zadziałać poprawnie zarówno na OCS, AGA, jak i RTG.

Program wyświetla niewielkie GUI gadtools, gdzie można wybrać architekturę (OCS/AGA lub RTG).

Po wybraniu RTG i naciśnięciu przycisku Start powinno wyświetlić się okno wyboru trybu wyświetlania. Po zatwierdzeniu wyboru naszym oczom powinien ukazać się ekran (na razie cały szary).

Po wybraniu OCS/AGA od razu otworzy się własne view (póki co całe czarne).

Uwaga: program w tej wersji wymaga Amiga OS3.0+. AGA jednak nie jest wymagana. Program wykryje kości AGA i jeśli są - otworzy ekran w 256 kolorach (8 bitach). Jeśli nie wykryje, to w 32 kolorach (5 bitów).

Tryb RTG wymaga biblioteki asl.library do wyboru trybu wyświetlania.

Celem tego programu jest przetestowanie działania mojego API. Dzięki temu mam jasność, czy technika, którą wybrałem jest właściwa.

Program do pobrania jest tutaj. Jeśli ktoś ma MOS, AOS4 lub inny system na RTG, bądź OCS i OS3.0+ to proszę w miarę możliwości o przetestowanie. Program działa kilka sekund, po czym zamyka się.

Całkiem fajnie się prezentuje kod - szczególnie użycie wskaźników do funkcji.

Np. fragment kodu głównego wygląda tak:

api = &aga;         /* Wybranie architektury AGA (analogicznie api = &rtg) */
api->otworzEkran(); /* Wywołanie funkcji poprzez wskaźnik */

A tutaj jak powinno wyglądać okienko konfiguracji:

Pozdrawiam.

[#384] Re: Zapowiedzi nowych gier

@Hexmage960, post #383

Wprowadziłem trzy istotne usprawnienia kodu w języku C:

1. Program jest podzielony na mniejsze kawałki, każdy odpowiedzialny za co innego.
2. Funkcje API są teraz statyczne, czyli widoczne tylko w obrębie plików źródłowych, w których się znajdują. Wyeksportowane są za to wskaźniki do tych funkcji. Zrobiłem tak dla czytelności i niezawodności kodu.
3. Zasoby są alokowane dynamicznie, zatem jeśli korzystamy np. z AGA, to zmienne dot. RTG nie zajmują miejsca w pamięci i na odwrót.

Pozbyłem się też części zmiennych globalnych, dzięki czemu łatwiej zadbać o porządek.

API dla AGA i RTG pozostaje identyczne. Funkcje mają nawet te same nazwy (jest to legalne w C dla funkcji statycznych). Dzięki temu kod zyskał na przejrzystości.

Jeśli chciałbym zrobić w tym momencie odrębne pliki wykonywalne dla AGA i RTG nie sprawiłoby to też żadnego problemu. Ale na razie kompilacja jest wspólna dla obu architektur.

Dalej praca będzie mi iść dużo sprawniej, bo kod jest dobrze uporządkowany.

Ostatnia aktualizacja: 28.03.2017 16:49:03 przez Hexmage960
[#385] Re: Zapowiedzi nowych gier

@Hexmage960, post #384

Witaj

Czy są jakieś postępy w grze Dune ?
[#386] Re: Zapowiedzi nowych gier

@Hubez, post #385

Piszę obecnie, oprócz jednego projektu na studia, który będę zdawał we wrześniu, grę na konkurs RetroKomp GameDev Compo.

Nie jest to jednak Dune, a inna gra o roboczym tytule Komandosi. Prosta w swoim założeniu, ale powinna być grywalna.

Projekt rokuje dobrze, ze względu na ciągły postęp w zdrowieniu.

Proszę mnie zrozumieć. Wszystko zależy od zdrowia. Biorę stale lekarstwa, które mnie leczą. Odzyskuję powoli swobodę działania, lepiej też widzę. No takież cholerstwo mnie dopadło, cóż poradzić.

Nawet psychiatrzy mieli problem ze zdiagnozowaniem tej choroby, więc nie oczekuję tego od bywalców forum amigowego.

Mogę tylko Was zapewnić, że postęp jest cały czas i jest naprawdę duży. Biorę obecnie lekarstwa, które są najskuteczniejsze i leczą mnie z objawów mojej choroby.

Grę obecnie piszę ze zintegrowanym edytorem plansz. Wczoraj sporo kodowałem przy edytorze. Można już sterować kursorem za pomocą klawiszy i wklejać oraz kasować kafelki. Jest pomoc on-line dostępna za pomocą klawisza HELP.
[#387] Re: Zapowiedzi nowych gier

@Hexmage960, post #386

Wrócisz do Dune czy całkowicie odpuszczasz? Nieźle się zapowiadało.
[#388] Re: Zapowiedzi nowych gier

@Schizo_, post #387

Nie odpuszczam. Sporo materiałów opracowałem, wiem jak zakodować taką grę. Potrzebuję jeszcze czasu.
[#389] Re: Zapowiedzi nowych gier

@Hexmage960, post #388

Zostaw juz ta nieszczesna DUNE 2, do tego trzeba z 20 osob.
Zajmij sie prostymi grami a giganty zostaw profesorom z PPA, moze oni cos napisza (procz setek postow)

Moze za pare lat, jak bedzie wieksza mobilizacja ludzi na tym forum to powstanie jakis RTS ale poki co nie ma na to zadnych szans.
[#390] Re: Zapowiedzi nowych gier

@selur, post #389

Zgoda, do RetroKomp i wydania prostej, ukończonej gry na pewno będę trzymał się takiego planu.

Dopiero jak taka gra stanie się faktem, będę mógł coś zrobić z silnikiem RTSa. Użyję "placeholderów", czyli grafiki zastępczej, zresztą tak samo, jak robię teraz z Komandosami.

Silnik RTS typu Dune 2 jest złożony, ale jeden programista może sobie z czymś takim poradzić. Grafikę jednak powinno projektować co najmniej 2 grafików.
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem