Forum AmigaOne Zone

Forum użytkowników Amigi i nie tylko
Teraz jest czwartek, 18 kwi 2024, 14:10

Strefa czasowa: UTC + 1




Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 10 ] 
Autor Wiadomość
PostNapisane: sobota, 19 paź 2013, 19:28 
Offline
Elitarny forumowicz
Elitarny forumowicz
Avatar użytkownika

Dołączył(a): piątek, 20 sty 2012, 05:09
Posty: 564
Lokalizacja: Warszawa
Czy ktoś obeznany z językiem C mógłby powiedzieć czy taki podział na funkcje jest w miarę poprawny? To co chciałem osiągnąć to jak najmniejsze funkcje oraz stała kontrola poprawności wyników. Jeśli chodzi o korzystanie z iffparse.library to napotykam się na różnego rodzaju rozwiązania, ale jakoś żadne nie przypadło mi do gustu - jedne korzystają z nieeleganckiego "goto", a inne są troszkę zbyt dużych rozmiarów.

Kod:
/* makeshape: program to create shapes: IFF loading part. */

#include <stdio.h>
#include <dos/dos.h>
#include <libraries/iffparse.h>
#include <exec/memory.h>
#include <datatypes/pictureclass.h>
#include <clib/dos_protos.h>
#include <clib/iffparse_protos.h>
#include <clib/exec_protos.h>
#include <clib/graphics_protos.h>

#include "IFFload.h"

/*======================================================================*
 *  depackbuffer: depack buffer into BitMap within ILBMInfo.
 *  Inputs: pointer to ILBMInfo, pointer to buffer
 *  Output: result
 *======================================================================*/
int depackbuffer(struct ILBMInfo *ii, BYTE *buffer)
{
   int result=-1;
   WORD row, plane, bpr;
   PLANEPTR planes[8];
   BYTE c, n;

   if (ii->bitmap = AllocBitMap(ii->width, ii->height, ii->depth, 0, NULL)) {
      for (plane = 0; plane < ii->depth; plane++)
         planes[plane] = ii->bitmap->Planes[plane];
      for (row = 0; row < ii->height; row++) {
         for (plane = 0; plane < ii->depth; plane++) {
            bpr = ii->bpr;
            if (ii->compression == cmpNone) {
               CopyMem(buffer, planes[plane], bpr);
               buffer += bpr;
               planes[plane] += bpr;
            }
            else if (ii->compression == cmpByteRun1) {
               while (bpr > 0) {
                  if ((c = *buffer++) >= 0) {
                     c++;
                     bpr -= c;
                     while (c-- > 0)
                        *planes[plane]++ = *buffer++;
                  }
                  else if (c != -128) {
                     c = -c + 1;
                     bpr -= c;
                     n = *buffer++;
                     while (c-- > 0)
                        *planes[plane]++ = n;
                  }
               }
            }
         }     
      }   
      result = 0;
   }
   return result;
}

/*======================================================================*
 *  readbody: alloc buffer then depack ILBM BODY into it.
 *  Inputs: pointer to ILBMInfo, pointer to IFFHandle.
 *  Output: result
 *======================================================================*/
int readbody(struct ILBMInfo *ii, struct IFFHandle *iff)
{
   struct ContextNode *cn;
   BYTE *buffer;
   int result=-1;
   
   if (cn = CurrentChunk(iff)) {
      if (buffer = AllocMem(cn->cn_Size, MEMF_PUBLIC)) {
         if (ReadChunkBytes(iff, buffer, cn->cn_Size) == cn->cn_Size) {
            result = depackbuffer(ii, buffer);
         }
         FreeMem(buffer, cn->cn_Size);   
      }
   }   
   return result;
}

/*======================================================================*
 *  storebmhd: copy contents of BMHD chunk into ILMBInfo.
 *  Inputs: pointer to ILBMInfo, pointer to BitMapHeader
 *  Output: none
 *======================================================================*/
void storebmhd(struct ILBMInfo *ii, struct BitMapHeader *bmhd)
{
   ii->width       = bmhd->bmh_Width;
   ii->height      = bmhd->bmh_Height;
   ii->depth       = bmhd->bmh_Depth;
   ii->bpr         = ROWBYTES(ii->width);
   ii->compression = bmhd->bmh_Compression;
}

/*======================================================================*
 *  storecmap: copy contents of CMAP chunk into ILBMInfo.
 *  Inputs: pointer to ILBMInfo, pointer to CMAP, size of CMAP chunk
 *  Output: result
 *======================================================================*/
int storecmap(struct ILBMInfo *ii, UBYTE *cmap, ULONG size)
{
   if (ii->cmap = AllocMem(size, MEMF_PUBLIC)) {
      CopyMem(cmap, ii->cmap, size);
      return 0;
   }
   return -1;
}

/*======================================================================*
 *  readilbm: store data from IFF ILBM file into ILBMInfo.
 *  Inputs: pointer to ILBMInfo, pointer to IFFHandle
 *  Output: result
 *======================================================================*/
int readilbm(struct ILBMInfo *ii, struct IFFHandle *iff)
{
   struct StoredProperty *sp;
   int result=-1;
   
   if (sp = FindProp(iff, ID_ILBM, ID_BMHD)) {
      storebmhd(ii, (struct BitMapHeader *)sp->sp_Data);
      if (sp = FindProp(iff, ID_ILBM, ID_CMAP)) {
         storecmap(ii, sp->sp_Data, sp->sp_Size);
      }
      result = readbody(ii, iff);
   }
   return result;
}

/*======================================================================*
 *  parseilbm: parse IFF ILBM file.
 *  Inputs: pointer to ILBMInfo, pointer to IFFHandle
 *  Output: result
 *======================================================================*/
int parseilbm(struct ILBMInfo *ii, struct IFFHandle *iff)
{
   int result;

   result  = PropChunk(iff, ID_ILBM, ID_BMHD);
   result |= PropChunk(iff, ID_ILBM, ID_CMAP);
   result |= StopChunk(iff, ID_ILBM, ID_BODY);
   if (result == 0 && ParseIFF(iff, IFFPARSE_SCAN) == 0) {
      result = readilbm(ii, iff);
   }
   return result;
}

/*======================================================================*
 *  openiff: begin transaction with IFF file and begin parsing.
 *  Inputs: pointer to ILBMInfo, pointer to IFFHandle
 *  Output: result
 *======================================================================*/
int openiff(struct ILBMInfo *ii, struct IFFHandle *iff)
{
   int result=-1;

   if (OpenIFF(iff, IFFF_READ) == 0) {
      result = parseilbm(ii, iff);
      CloseIFF(iff);
   }
   return result;
}

/*======================================================================*
 *  openilbm: open IFF file and store contents into ILBMInfo.
 *  Inputs: pointer to ILBMInfo, pointer to IFFHandle, name
 *  Output: result
 *======================================================================*/
int openilbm(struct ILBMInfo *ii, struct IFFHandle *iff, char *name)
{
   int result=-1;

   if (iff->iff_Stream = Open(name, MODE_OLDFILE)) {
      InitIFFasDOS(iff);
      result = openiff(ii, iff);
      Close(iff->iff_Stream);
   }
   return result;
}

/*======================================================================*
 *  fillilbminfo: fill ILBMInfo structure with data from IFF file.
 *  Inputs: pointer to ILBMInfo, name
 *  Output: result
 *======================================================================*/
int fillilbminfo(struct ILBMInfo *ii, char *name)
{
   struct IFFHandle *iff;
   int result=-1;

   if (iff = AllocIFF()) {
      result = openilbm(ii, iff, name);
      FreeIFF(iff);
   }   
   return result;
}

/*======================================================================*
 *  loadilbm: load IFF ILBM named name.
 *  Inputs: name
 *  Output: pointer to ILBMInfo
 *======================================================================*/
struct ILBMInfo *loadilbm(char *name)
{
   struct ILBMInfo *ii;
   
   if (ii = AllocMem(sizeof(struct ILBMInfo), MEMF_PUBLIC|MEMF_CLEAR)) {
      if (fillilbminfo(ii, name) == 0) {
         return ii;
      }
      FreeMem(ii, sizeof(struct ILBMInfo));
   }
   return NULL;
}     


_________________
Robert "Hextreme" Szacki - Gear Works software


Udostępnij dla FacebookUdostępnij dla Twitter
Góra
 Zobacz profil  
Cytuj  
PostNapisane: niedziela, 20 paź 2013, 08:54 
Offline
Regularny forumowicz
Regularny forumowicz

Dołączył(a): poniedziałek, 23 sty 2012, 08:17
Posty: 59
Hextreme napisał(a):
Czy ktoś obeznany z językiem C mógłby powiedzieć czy taki podział na funkcje jest w miarę poprawny?
Czy nie prościej byłoby po prostu załadować obrazek datatypami?


Góra
 Zobacz profil  
Cytuj  
PostNapisane: niedziela, 20 paź 2013, 10:40 
Offline
Doborowy forumowicz
Doborowy forumowicz

Dołączył(a): wtorek, 17 sty 2012, 17:21
Posty: 935
Hextreme napisał(a):
Czy ktoś obeznany z językiem C mógłby powiedzieć czy taki podział na funkcje jest w miarę poprawny? To co chciałem osiągnąć to jak najmniejsze funkcje oraz stała kontrola poprawności wyników.


A czy to musi być iff?
Szczerze mówiąc to był fajny format w czasach A500 ale później już nie za bardzo.
Jak jest od 256 kolorów w górę bitplany, to złe rozwiązanie.
Chunky pixel jest o wiele lepsze.
Jak kupiłem A1200 to dostałem razem z nią PPainta.
Fajny soft.
Miał wbudowaną obsługę .bmp i pnm.
Zwłaszcza to .bmp było fajne.
A że w Bajtku 11/92 rozpisali format .bmp to już w ogóle było łatwiej robić zapis/odczyt obrazów na amidze w .bmp.
Do dzisiaj pamiętam że nagłówek .bmp bez kompresji ma 54 bajty.
Dalej w liczbach LE:
10 - odległość od początku pliku do danych graficznych
18 - szerokość obrazka
22 - wysokość obrazka
Jak po nagłówku idą od razu dane graficzne to obrazek 24 bit (bajty b,g,r).
Jak nie to obrazek 256 kol. i po nagłówku idą dane o kolorach (256*4) format b,g,r,a.
kolejność linii w pliku odwrócona - najpierw idą te z dołu.
Na amidze mnie to nie obchodziło, najwyżej obracałem obrazek w PPaincie.
Wczytywanie do rastportu robiłem poprzez WritePixelArray8 a odczyt poprzez ReadPixelArray8.
Łatwiej było też jeśli chodzi o .bmp obrabiać obrazki w pliku, bez ich wyświetlania.
Ach dawne czasy.
Dwadzieścia lat minęło.
Wesołego kodowania.


Góra
 Zobacz profil  
Cytuj  
PostNapisane: niedziela, 20 paź 2013, 11:50 
Offline
Elitarny forumowicz
Elitarny forumowicz
Avatar użytkownika

Dołączył(a): piątek, 20 sty 2012, 05:09
Posty: 564
Lokalizacja: Warszawa
Chcę planarne IFF, dla prędkości odczytu, a później blitowania pod AGA. Dlatego też nie chcę datatypów, mimo że z nimi ładowanie to pestka. Wiem, że robię to kosztem zgodności z RTG, ale muszę ponieść te koszta.

@Swinkamor12
Interesujące to info o BMP, ja znam z grubsza format PNG. Tyle, że zastosowanie do którego chcę przeznaczyć mój kod to gra bitmapowa, tutaj format planar jest wygodniejszy.

To, że projekt jest retro-grą uważam za wystarczające wyjaśnienie, dlaczego sięgam po technologię 20-letnią...

Mam pytanie? Piszesz, że dwadzieścia lat temu czytałeś obrazki formatu BMP? Zatem czym zajmujesz się dzisiaj, w 2013 roku? Piszesz programy pod Windows, czy też AmigaOS 4.1?

Odczuwam też, że separacja portali poświęconych programowaniu na Amidze Classic jak i Amidze One jest nieunikniona. Oba komputery programuje się inaczej - Amiga Classic oprogramowuje się jak Atari czy C64, to nie jest hardware do portowania SDL-owych programów. Chyba, że działa się na WinUAE: tylko po co komu wtedy Amiga?

_________________
Robert "Hextreme" Szacki - Gear Works software


Góra
 Zobacz profil  
Cytuj  
PostNapisane: niedziela, 20 paź 2013, 12:57 
Offline
Administrator
Administrator
Avatar użytkownika

Dołączył(a): poniedziałek, 16 sty 2012, 15:14
Posty: 4667
Hextreme napisał(a):
. Wiem, że robię to kosztem zgodności z RTG, ale muszę ponieść te koszta.



Czyli chcesz cos napisac wbrew wytycznym firmy Commodore, a w dodatku jeszcze ukarac wiekszosc aktywnych jeszcze posiadaczy klasyka, ktorzy wyposazyli swe maszyny w karty graficzne. Chyba nie tedy droga.

Cytuj:
Odczuwam też, że separacja portali poświęconych programowaniu na Amidze Classic jak i Amidze One jest nieunikniona. Oba komputery programuje się inaczej


Tylko w wypadku olewania wytycznych Commodore. Ja tam nie jestem zadnym programista, ot wrzucilem na OS4Depot dwie gierki zrobione w Hollywood, ale gdybym chcial te dwie gierki zrobic na Amige 68k z karta graficzna w zasadzie w kodzie nie musialbym zmieniac ani linijki.


Góra
 Zobacz profil  
Cytuj  
PostNapisane: niedziela, 20 paź 2013, 14:36 
Offline
Regularny forumowicz
Regularny forumowicz

Dołączył(a): poniedziałek, 23 sty 2012, 08:17
Posty: 59
Hextreme napisał(a):
Chcę planarne IFF, dla prędkości odczytu, a później blitowania pod AGA. Dlatego też nie chcę datatypów
Standardowo datatype dostarcza Ci dane obrazka jako planarne bitmapy, które można bezpośrednio blitować pod AGA, czy to którąś z funkcji graphics.library, czy nawet niskopoziomowo, bezpośrednio programując rejestry blittera. Zgodność z RTG nie ma tu nic do rzeczy. Zamiast tracić czas na pisanie i debugowanie procedur ręcznego ładowania IFF ILBM, mógłbyś przejść do zasadniczych procedur gry...


Góra
 Zobacz profil  
Cytuj  
PostNapisane: niedziela, 20 paź 2013, 17:04 
Offline
Doborowy forumowicz
Doborowy forumowicz

Dołączył(a): wtorek, 17 sty 2012, 17:21
Posty: 935
Hextreme napisał(a):
Chcę planarne IFF, dla prędkości odczytu, a później blitowania pod AGA.


Tylko czy to jest dobry pomysł?

Bliter w Amidze jest szybszy tylko od 68000. Jest wolniejszy i adresuje mniej pamięci już od 68020.
Pamięć CHIP w Amidze też za szybka nie jest.
Jeśli zakładasz np minimum 68030 może szybciej będzie robienie wszystkiego w FAST a potem tylko przenoszenie na ekran?

Że nie wspomnę o 68060 gdzie robienie wszystkiego w chunky pixel w FAST, a potem wrzucanie na ekran przy WritePixelArray8 przy zainstalowanym Blazewcp będzie o wiele szybsze.

Cytuj:
Dlatego też nie chcę datatypów, mimo że z nimi ładowanie to pestka. Wiem, że robię to kosztem zgodności z RTG, ale muszę ponieść te koszta.


To zależy czy naprawdę jesteś w stanie wycisnąć z układów Amigi wszystko co się da.
Śmiem wątpić.
Ogólnie patrząc na gierki zgłaszane na badziewny retrokomp, to ja tam nie widzę wyrafinowanych sztuczek programistycznych, magii z układami graficznymi które tłumaczyłby brak systemu.

Cytuj:
Tyle, że zastosowanie do którego chcę przeznaczyć mój kod to gra bitmapowa, tutaj format planar jest wygodniejszy.


Np. format chunky na dysku, ładujesz do rastportu do którego alokujesz bitmapę, tam będziesz miał planar.

Cytuj:
Mam pytanie? Piszesz, że dwadzieścia lat temu czytałeś obrazki formatu BMP?


To była po prostu dobra rada.
Na AMIDZE już dwadzieścia lat temu było wygodniej używać BMP niż IFF.
Co nie zmieniło się do tej pory.
Mniej kodu, mniej czasu spędzonego na pisaniu i debugowaniu kodu, same plusy.

Cytuj:
Zatem czym zajmujesz się dzisiaj, w 2013 roku? Piszesz programy pod Windows, czy też AmigaOS 4.1?


Pod oba te systemy plus linux plus inne.

Cytuj:
Odczuwam też, że separacja portali poświęconych programowaniu na Amidze Classic jak i Amidze One jest nieunikniona. Oba komputery programuje się inaczej - Amiga Classic oprogramowuje się jak Atari czy C64


Znaczy się kodowanie w stylu piencety to nie to samo co programowanie AMIGI.
Kodowanie w stylu piencety byłoby może na miejscu gdyby Amiga skończyła się na piencecie.
Niestety nawet na 68k to działało niespecjalnie.

Cytuj:
to nie jest hardware do portowania SDL-owych programów. Chyba, że działa się na WinUAE: tylko po co komu wtedy Amiga?


WinUAE po to by wygodnie używać systemu Amigi na tanim sprzęcie.
Te wyprodukowane przez Commodore, to szczerze mówiąc po nic.
Nowsze Amigi w dalszym ciągu są szybsze od WinUAE.


Góra
 Zobacz profil  
Cytuj  
PostNapisane: środa, 23 paź 2013, 16:10 
Offline
Elitarny forumowicz
Elitarny forumowicz
Avatar użytkownika

Dołączył(a): piątek, 20 sty 2012, 05:09
Posty: 564
Lokalizacja: Warszawa
Dziękuję Wam za odpowiedzi.

swinkamor12 napisał(a):
Mniej kodu, mniej czasu spędzonego na pisaniu i debugowaniu kodu, same plusy.

Ładowanie z datatypów to zaledwie kilka linijek, ale ma to swój minus - w środku są różnego rodzaju haczyki, które obciążają komputer. Oczywiście jest to Amiga OS dla Motoroli 680x0 - więc tych haczyków jest niewiele, kod wewnątrz jest wyjątkowo lekki i żwawy. Obsłuży wszystkie formaty, od IFF przez BMP aż po PNG i JPG. Uniwersalność nie idzie jednakże w parze z pożądaną prędkością działania.

Nie zgodzę się, że na Amidze IFFy wymarły już na etapie Amigi 500. Przecież do kolejnych modeli z systemem 2.xx dodawali już iffparse.library, bibliotekę specjalistyczną służącą do pełnej obsługi plików IFF. Postanowiłem tę bibliotekę wykorzystać.

Już sobie poradziłem z procedurami wykorzystującymi iffparse.library! Udało mi się zrobić krótki, zwarty kod. Za jakiś czas postaram się stworzyć stronę internetową i to zagadnienie wziąłbym jako pierwsze. Tymczasem mogę kontynuować pracę nad swoim projektem.

Cytuj:
Bliter w Amidze jest szybszy tylko od 68000. Jest wolniejszy i adresuje mniej pamięci już od 68020.

To dlatego na AGA, kiedy to na rynku zaistniały komputery z 68030 i 68040 (Amigi 4000) powstawały nowe gry wykorzystujące stale Blitter? Wiem, że jesteś (Świnkamor12) antyfanem Amig z AGA, ale powiem Ci, że gry które korzystają niby z kart graficznych jakoś nie udało mi się zaprząc do wygodnej pracy z kartą graficzną BVision (którą obecnie posiadam). Mówię o grach Napalm i Genetic Species, oraz Gloom. Przypomniało mi się: jedynie Boulder Dash od Guido Mersmanna działa fajnie w 256 kolorach na karcie graficznej, ale ten program jest naprawdę przyzwoity (słowo to oddaje w niewielkiej części, jak porządnie napisał swoją grę).

Jestem ogromnym fanem Amig z AGA, fanem Amiga Computer Studio, czasopisma wydawanego na właściwie martwy rynek Amigi. Cieszyła mnie recenzja każdej, choćby najdrobniejszej nowej gry na Amigę.

_________________
Robert "Hextreme" Szacki - Gear Works software


Góra
 Zobacz profil  
Cytuj  
PostNapisane: sobota, 26 paź 2013, 11:28 
Offline
Doborowy forumowicz
Doborowy forumowicz

Dołączył(a): wtorek, 17 sty 2012, 17:21
Posty: 935
Hextreme napisał(a):
Ładowanie z datatypów to zaledwie kilka linijek, ale ma to swój minus - w środku są różnego rodzaju haczyki, które obciążają komputer.
Uniwersalność nie idzie jednakże w parze z pożądaną prędkością działania.

Dlatego proponuję bmp. Bardzo prosty format, szeroko rozpowszechniony, łatwy w użyciu.

Cytuj:
To dlatego na AGA, kiedy to na rynku zaistniały komputery z 68030 i 68040 (Amigi 4000) powstawały nowe gry wykorzystujące stale Blitter?

Były takie?
Po 1992 gry na Amigę to było niestety dziadostwo.
Pewno ktoś coś nie dopracował.

Cytuj:
Wiem, że jesteś (Świnkamor12) antyfanem Amig z AGA
, ale powiem Ci, że gry które korzystają niby z kart graficznych jakoś nie udało mi się zaprząc do wygodnej pracy z kartą graficzną BVision (którą obecnie posiadam). Mówię o grach Napalm i Genetic Species, oraz Gloom.

Genetic Species chodzi bez problemu na klasyku na karcie graficznej.
Potrzebna jest tylko wersja z obsługą kart graf.
Na aminecie jest pełna wersja gry, działająca z kartami graf.
Polecam.

A co do klasyka na cóż.
W zasadzie jest on mi zbędny. Soft z Amigi 68k chodzi lepiej na PC.
Z przykrością muszę stwierdzić że swoje też dokładają użytkownicy klasyka.
99,99% zajmuje się odezwami, manifestami, nawracaniem na ścierwo wyprodukowane przez Commodore, i obrabianiem ludzi którzy coś robią i którym coś wychodzi.
Pewno bym miał lepsze zdanie o klasyku i klasykowcach, gdyby był jakiś nowy soft albo hardware.
Niestety w temacie klasyka hardware stanął w miejscu w roku 2000, a software jeszcze wcześniej.
Szkoda miejsca w domu na klasyka, lepiej używać softu z klasyka na PC.
Soft z klasyka działa na PC szybciej i jest wygodniejszy w użyciu niż na klasyku.


Góra
 Zobacz profil  
Cytuj  
PostNapisane: niedziela, 27 paź 2013, 12:41 
Offline
Administrator
Administrator
Avatar użytkownika

Dołączył(a): poniedziałek, 16 sty 2012, 15:14
Posty: 4667
swinkamor12 napisał(a):
Genetic Species chodzi bez problemu na klasyku na karcie graficznej.
Potrzebna jest tylko wersja z obsługą kart graf.
Na aminecie jest pełna wersja gry, działająca z kartami graf.
Polecam.


Gloom i Napalm też chodzi bez problemu na karcie graficznej, jako wieloletni użytkownik BVision wiem co mówię.

Cytuj:
Z przykrością muszę stwierdzić że swoje też dokładają użytkownicy klasyka.
99,99% zajmuje się odezwami, manifestami, nawracaniem na ścierwo wyprodukowane przez Commodore, i obrabianiem ludzi którzy coś robią i którym coś wychodzi.


Niestety stwierdzam że im kto głośniej bredzi na temat nowych Amig a dodatkowo puszcza fucki względem innych produkcji na stare Amigi vide Selur tym gorszą antyreklamę wystawia Amidze klasycznej własnymi gierkami. Key Master był ewidentnie najgorszym crapem wystawionym na RetroKomp i nie było to tylko moje odczucie, ale i dwóch innych amigowców stojących obok. Jestem w szoku że produkt ten zajął aż przedostatnie miejsce. Gdyby autor chociaż 5% energii którą poświęca na głoszenie manifestów że "bankructwo A-Eonu byłoby zbawieniam dla Amigi" :lol: poświęciłby na dopracowywanie własnej gry to może i wizerunek klasyka byłby lepszy i Amiga nie byłaby na composach ośmieszana przez produkcje z ZX Spectrum.


Góra
 Zobacz profil  
Cytuj  
Wyświetl posty nie starsze niż:  Sortuj wg  
Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 10 ] 

Strefa czasowa: UTC + 1


Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 3 gości


Nie możesz rozpoczynać nowych wątków
Nie możesz odpowiadać w wątkach
Nie możesz edytować swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Skocz do:  
cron
Powered by phpBB® Forum Software © phpBB Group
Przyjazne użytkownikom polskie wsparcie phpBB3 - phpBB3.PL
phpBB SEO