18.12.2022 21:17
[#212]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #209
"Nie, użyliśmy wstępnie obliczonych kątów dla każdego piksela na kuli (nie na stole), a następnie wykonaliśmy bitowe AND z tłem i wzięliśmy średni kąt dotkniętych pikseli."
trza by zapytac Majstra Si Pli Pli (Kain)) jak on to rozumie ale tu chyba chodzi nie tyle o sama kolizje ze sciana a o ustawianie konta pod jakim ma sie odbic pilka po uderzeniu w jej okreslony obszar, dobrze mowie ?
trza by zapytac Majstra Si Pli Pli (Kain)) jak on to rozumie ale tu chyba chodzi nie tyle o sama kolizje ze sciana a o ustawianie konta pod jakim ma sie odbic pilka po uderzeniu w jej okreslony obszar, dobrze mowie ?
18.12.2022 21:43
[#213]
Re: Powstawanie nowej gry w Blitz 2
@selur, post #212
Ja to rozumiem tak (oczywiście musi być obrazek):
Dla każdego szarego piksela na moim obrazku (krawędź kulki) jest ustalony kąt pod jakim piłka ma się odbić jak uderzy z tej konkretnej strony. Oczywiście punktów styku będzie często więcej niż jeden, więc wtedy bierzemy średnią z kątow w miejscach styku.
Z kolei te kąty per piksel krawędzi kuli to najpewniej idą jakoś tak:
więc jak uderza z lewej (pomarańcz) to odbija w prawo. Jak zahaczy jakiś dolny piksel to uśredniona strzałka czy tam kąt pójdzie w górę trochę.
Ostatnia aktualizacja: 18.12.2022 21:46:12 przez teh_KaiN
Dla każdego szarego piksela na moim obrazku (krawędź kulki) jest ustalony kąt pod jakim piłka ma się odbić jak uderzy z tej konkretnej strony. Oczywiście punktów styku będzie często więcej niż jeden, więc wtedy bierzemy średnią z kątow w miejscach styku.
Z kolei te kąty per piksel krawędzi kuli to najpewniej idą jakoś tak:
więc jak uderza z lewej (pomarańcz) to odbija w prawo. Jak zahaczy jakiś dolny piksel to uśredniona strzałka czy tam kąt pójdzie w górę trochę.
Ostatnia aktualizacja: 18.12.2022 21:46:12 przez teh_KaiN
18.12.2022 22:37
[#219]
Re: Powstawanie nowej gry w Blitz 2
@selur, post #218
Obraca się. To jest właśnie wektor. Na zdjęci Kaina widać właśnie że niby piłka opada w lewy dolny róg, ale to jest inaczej. Piłka ma swoje x, y, szybkość i wektor. Chciałem tego uniknąć, ale nie da się tego estetycznie zrobić.
Piłka zawsze leci do przodu. Lecąc w lewo tak naprawdę leci do przodu, ale jest obrócona o 90 stopni. Dzięki takiemu rozumowaniu można stosować łukowate ruchy piłki, przy kolizji obracać ją aby ładnie się przemieszczała. Ale zmianę kąta i szybkości też trzeba z głową dostosować. Mam już przeliczanie z wektora i szybkości wartości do nowych x,y. Sam obmyśliłem jak wyliczyć punkty na krawędzi piłki do kolizji. Musiałem narysować na kartce koło, środek i sobie przypomnieć sinusy i cosiusy. Zrozumiałem dlaczego dla wyliczania x piłki stosuje się sinus, a dla y piłki cosinus.
Od razu dla ciekawskich wspomnę, że na klatkę to tylko 3x Point. Przód i 2x na ukos. Tyłu nie sprawdzam bo piłka w tył nie poleci. Zawsze do przodu.
Mam napisane tylko wybijanie i opadanie piłki. Wstępnie pierwszy łuk mam ale wymaga dopracowania. Ogólnie jest zbyt szybko i trudno jest zwolnić piłkę. Grawitacja jest najtrudniejsza bo piłka lecąc do góry czyli pod kątem 0 stopni nagle musi opadać bez skręcania. Trzeba wtedy wektor obrócić o 180 stopni. Przy odbijaniu od ziemii to samo. Gdy piłka leci pod kątem, to wtedy trzeba systematycznie sterować szybkością i wektorem aby to wyglądało jak w oryginale.
Nie obiecuję że sobie z tym poradzę, bo to trudniejszy sposób na fizykę niż poprzedni, ale bardziej dokładny i efektowny. Mam nadzieję że mi się to uda chociaż w 80%. Gdybym chociaż znał mniej więcej na jakich wartościach działały te prawdziwe pinballe w Amidze czy PC to byłoby łatwiej. Tutaj muszę kombinować. Przy kolizji ręcznie dodaję lub odejmuję kąty albo szybkość piłki. Naprawdę żeby to dograć to potrzebuję czasu.
Piłka zawsze leci do przodu. Lecąc w lewo tak naprawdę leci do przodu, ale jest obrócona o 90 stopni. Dzięki takiemu rozumowaniu można stosować łukowate ruchy piłki, przy kolizji obracać ją aby ładnie się przemieszczała. Ale zmianę kąta i szybkości też trzeba z głową dostosować. Mam już przeliczanie z wektora i szybkości wartości do nowych x,y. Sam obmyśliłem jak wyliczyć punkty na krawędzi piłki do kolizji. Musiałem narysować na kartce koło, środek i sobie przypomnieć sinusy i cosiusy. Zrozumiałem dlaczego dla wyliczania x piłki stosuje się sinus, a dla y piłki cosinus.
Od razu dla ciekawskich wspomnę, że na klatkę to tylko 3x Point. Przód i 2x na ukos. Tyłu nie sprawdzam bo piłka w tył nie poleci. Zawsze do przodu.
Mam napisane tylko wybijanie i opadanie piłki. Wstępnie pierwszy łuk mam ale wymaga dopracowania. Ogólnie jest zbyt szybko i trudno jest zwolnić piłkę. Grawitacja jest najtrudniejsza bo piłka lecąc do góry czyli pod kątem 0 stopni nagle musi opadać bez skręcania. Trzeba wtedy wektor obrócić o 180 stopni. Przy odbijaniu od ziemii to samo. Gdy piłka leci pod kątem, to wtedy trzeba systematycznie sterować szybkością i wektorem aby to wyglądało jak w oryginale.
Nie obiecuję że sobie z tym poradzę, bo to trudniejszy sposób na fizykę niż poprzedni, ale bardziej dokładny i efektowny. Mam nadzieję że mi się to uda chociaż w 80%. Gdybym chociaż znał mniej więcej na jakich wartościach działały te prawdziwe pinballe w Amidze czy PC to byłoby łatwiej. Tutaj muszę kombinować. Przy kolizji ręcznie dodaję lub odejmuję kąty albo szybkość piłki. Naprawdę żeby to dograć to potrzebuję czasu.
18.12.2022 23:04
[#223]
Re: Powstawanie nowej gry w Blitz 2
@iC-e_Jay, post #222
Już myślałem że coś nie tak że tak wolno 
F1 jest by podejrzeć bitmapę z kolizjami. Fizyka piłki będzie zupełnie pisana od nowa. Będzie dokładniej o ile to się uda. Aż sam się dziwię że mam tyle cierpliwości. Chwilę dzisiaj pograłem w wersję pc i powiem że bardzo dużo brakuje mi do niej.
F1 jest by podejrzeć bitmapę z kolizjami. Fizyka piłki będzie zupełnie pisana od nowa. Będzie dokładniej o ile to się uda. Aż sam się dziwię że mam tyle cierpliwości. Chwilę dzisiaj pograłem w wersję pc i powiem że bardzo dużo brakuje mi do niej.
19.12.2022 06:53
[#225]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #68
Nie poradzę sobie z kanałem alfa i z maskami w Blitzu.
Nigdy nie robiłem nic w Basicach i programista ze mnie żaden, ale tak z nurtującej ciekawości ściągnąłem sobie tego BB2 i zacząłem kombinować biorąc plik jakiś tutoriala z Githuba, jako bazę do modyfikacji krok po kroku. Po całym dniu walki z tym językiem, krążenia w ślepej uliczce i z niejasną dokumentacją, udało mi się zrobić taki przykład z przeźroczystym spritem (nie mylić z półprzeźroczystym, ale na GH jest przykład z półprzeźroczystością, Earok na GH ma taki przykład jakby kogoś interesowało). Jakbym miał to robić, to wybrałbym C, tutaj z niejasnego powodu, aby zaktualizować grafikę sprite, trzeba ponownie zdefiniować shape i zainicjalizować sprite, tak jakby BB sobie gdzieś go kopiował, byś nie miał do niego dostępu (albo za mało się znam), zajęło chyba ze 3 godziny dojście dlaczego blitowanie na bitmapę stołu działa, a sprite pozostaje niezmieniony. Robienie kanału alfa też okazało się jak na ironię proste z pomocą BlitMode EraseMode, podobno stencil, showstencil i sblit służą do robienia głębi z przysłanianymi obiektami, ale z tego co znalazłem w dokumentacji i niedziałających przykładów nie udało mi się użyć tych metod, ani dowiedzieć dokładnie jak działają, a to właśnie na nich się skupiłem niepotrzebnie.
Przy okazji z tego co wyczytałem, to przy FMODE3 jak masz więcej niż jeden sprite, to musisz zjechać ekranem do 256 pikseli szerokości (nie wiem, czy to ograniczenie blitza), a także grafika dla BLOCK powinna mieć szerokość będącą podzielną przez 16 (cykl blittera).
Ja Block użyłem tylko do kopiowania kulki, a łapki normalnie blitowane przez wolniejszy BBlit. Wycinanie precyzyjnych kształtów w PP mnie dobiło, a skoro zaspokoiłem swoją ciekawość, to już dalej nie brnąłem. Nawet nie ma podwójnego buforowania.
Może komuś taka metoda się przyda, albo posłuży za jakiś materiał edukacyjny (nic tu nie działa prócz przesuwania kulki joystickiem w celu zademonstrowania efektu złudzenia zasłaniania kulki).
projekt blitz
Ostatnia aktualizacja: 19.12.2022 07:03:06 przez san_u
19.12.2022 07:46
[#226]
Re: Powstawanie nowej gry w Blitz 2
@san_u, post #225
Co do sprajtów to tak. BB2 ma tylko miejsce na 8 grafik sprajtów. Jeśli chcesz więcej grafik to musisz skopiować z banku shape'ów poprzez GetaSprite.
SBlit i Stencil nie używałem nigdy, ale to tylko wklejanie grafiki.
Co do Block to ja używam go do wklejania łapek na bitmapie roboczej gdzie mam 320 pix szerokości, ale tam nie mam FMODE3. FMODE3 mam na copliście głównej na która jest widoczna. Block jest najszybszą metodą wklejania oraz z tego co zauważyłem jako jedyna metoda do wklejania grafiki razem z kolorem 0.
Nie sprawdzałem Twojego przykładu, bo piszę z telefonu, ale jestem ciekaw czy użyłeś ekranu na Slice czy na Display, bo wiele przykładów w Blitzu opartych jest na Slice, ale ja używam Display.
I tak podziwiam Cię że przebrnąłeś tyle przez jeden dzień. Podwójne buforowanie to 4 krótkie linijki kodu więcej.
SBlit i Stencil nie używałem nigdy, ale to tylko wklejanie grafiki.
Co do Block to ja używam go do wklejania łapek na bitmapie roboczej gdzie mam 320 pix szerokości, ale tam nie mam FMODE3. FMODE3 mam na copliście głównej na która jest widoczna. Block jest najszybszą metodą wklejania oraz z tego co zauważyłem jako jedyna metoda do wklejania grafiki razem z kolorem 0.
Nie sprawdzałem Twojego przykładu, bo piszę z telefonu, ale jestem ciekaw czy użyłeś ekranu na Slice czy na Display, bo wiele przykładów w Blitzu opartych jest na Slice, ale ja używam Display.
I tak podziwiam Cię że przebrnąłeś tyle przez jeden dzień. Podwójne buforowanie to 4 krótkie linijki kodu więcej.
19.12.2022 08:36
[#227]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #226
Ja podałem sposób na przyśpieszenie rysowania, który polega na tym, że w bitmapie wyznaczasz maksymalne kolory dla obszarów.
Jeżeli maksymalny kolor to np. 7, wówczas rysowanie wymaga modyfikacji 3 bitplanów, jeśli taki kolor to 15 - wymaga modyfikacji 4 bitplanów itd.
Teraz umieszczasz najczęściej używane kolory na początku palety.
Jeżeli łapki w Pinballu wykorzystują np. 15 pierwszych kolorów, możesz w ten sposób zoptymalizować ich rysowanie.
Piłeczka jednakże musi zawierać maksymalny kolor obszaru, na którym może się pojawić.
Co do tego FMODE, o którym wiele razy się mówi, to przeznaczenie tego rejestru jest bardzo jasne. AGA może pobierać 32 bity na raz (FMODE 2x) dzięki czemu wyświetli Hires 32 do 256 kolorów oraz 64 bity na raz (FMODE 4x), dzięki czemu wyświetli Super Hires 32 do 256 kolorów.
W przypadku Lores nawet do 256 kolorów wystarczy FMODE 1x i nie potrzeba więcej.
Co do stylu programowania pod AGA, to od tego chipsetu bardziej preferuje się systemowe biblioteki zarówno do pobierania bazy danych o trybach graficznych, jak i rysowania, kontroli obrazu wideo itp.
Jeżeli masz procesor MC68030 w Amidze albo masz Amigę CD32, to jest możliwe stosowanie szybkiego chunky do rysowania.
Blitz Basic troszkę łamie tę konwencję, bo nadal modyfikuje bezpośrednio rejestry.
Pod system programuje się bardzo wygodnie, mimo że funkcje nie należą do najszybszych.
Gratuluję obecnych rezultatów pracy! Serdecznie życzę powodzenia w poskramianiu Blitz Basica. Namawiam jednak do zajrzenia również do systemu, bo to upraszcza pracę.
Ostatnia aktualizacja: 19.12.2022 08:40:18 przez Hexmage960
Jeżeli maksymalny kolor to np. 7, wówczas rysowanie wymaga modyfikacji 3 bitplanów, jeśli taki kolor to 15 - wymaga modyfikacji 4 bitplanów itd.
Teraz umieszczasz najczęściej używane kolory na początku palety.
Jeżeli łapki w Pinballu wykorzystują np. 15 pierwszych kolorów, możesz w ten sposób zoptymalizować ich rysowanie.
Piłeczka jednakże musi zawierać maksymalny kolor obszaru, na którym może się pojawić.
Co do tego FMODE, o którym wiele razy się mówi, to przeznaczenie tego rejestru jest bardzo jasne. AGA może pobierać 32 bity na raz (FMODE 2x) dzięki czemu wyświetli Hires 32 do 256 kolorów oraz 64 bity na raz (FMODE 4x), dzięki czemu wyświetli Super Hires 32 do 256 kolorów.
W przypadku Lores nawet do 256 kolorów wystarczy FMODE 1x i nie potrzeba więcej.
Co do stylu programowania pod AGA, to od tego chipsetu bardziej preferuje się systemowe biblioteki zarówno do pobierania bazy danych o trybach graficznych, jak i rysowania, kontroli obrazu wideo itp.
Jeżeli masz procesor MC68030 w Amidze albo masz Amigę CD32, to jest możliwe stosowanie szybkiego chunky do rysowania.
Blitz Basic troszkę łamie tę konwencję, bo nadal modyfikuje bezpośrednio rejestry.
Pod system programuje się bardzo wygodnie, mimo że funkcje nie należą do najszybszych.
Gratuluję obecnych rezultatów pracy! Serdecznie życzę powodzenia w poskramianiu Blitz Basica. Namawiam jednak do zajrzenia również do systemu, bo to upraszcza pracę.
Ostatnia aktualizacja: 19.12.2022 08:40:18 przez Hexmage960
19.12.2022 08:43
[#228]
Re: Powstawanie nowej gry w Blitz 2
@Hexmage960, post #227
Jeszcze nie używałem Intuition w Blitzu tak na poważnie. Nie wiem jakby to było ze scrollem, ale narazie wyświetlanie mam dopracowane. Fizykę piłki będę pisać do lutego chyba zanim to dopracuję. Do tej fizyki muszę zmienić bitmapę roboczą. Tu nie potrzebuję aż tylu kolorów. Wydaje mi się że 4 czy 5 kolorków to będzie max co potrzebuję.
19.12.2022 10:01
[#230]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #219
Może wcale nie potrzebujesz tzymać kąta i wystarczy Ci dx,dy jako delty do dodawania do pozycji co klatkę? Tym razem ładniejsze obrazki:
To Ci rozwiązuje problem grawitacji. U Ciebie wartości by musiały być dużo mniejsze, ale generalnie co klatkę do pozycji px,py dodajesz dx,dy i na dy nakładasz grawitację g aż do jakiegoś dolnego limitu (nie za dużego bo będziesz przeskakiwał piłką przez przeszkody). Tak samo zderzenia:
- dla każdego miejsca na okręgu masz zapamiętane jednostkowe dx,dy, nazwijmy to kx,ky
- przy zderzeniu ze stołem sprawdzasz w którym miejscu piłka ma kolizję i wyciągasz jednostkowy wektor kx,ky
- obliczasz obecną długość wektora dx,dy (M = sqrt(dx*dx + dy*dy))
- nowe dx,dy = kx*M*alfa,ky*M*alfa
alfa to tłumienie przy zderzeniach. Jak chcesz żeby piłka nie traciła prędkości to alfa = 1, jak chcesz żeby traciła trochę to 0.8, a jak chcesz żeby przyspieszała to 1.2 ;)
To już raczej nie na intach trzeba liczyć tylko na fixed pointach. No i pewnie dy powinien mieć wartości ujemne w górę a dodatnie w dół, wtedy grawitacja byłaby dodatnia. ;)
Ostatnia aktualizacja: 19.12.2022 10:03:54 przez teh_KaiN
To Ci rozwiązuje problem grawitacji. U Ciebie wartości by musiały być dużo mniejsze, ale generalnie co klatkę do pozycji px,py dodajesz dx,dy i na dy nakładasz grawitację g aż do jakiegoś dolnego limitu (nie za dużego bo będziesz przeskakiwał piłką przez przeszkody). Tak samo zderzenia:
- dla każdego miejsca na okręgu masz zapamiętane jednostkowe dx,dy, nazwijmy to kx,ky
- przy zderzeniu ze stołem sprawdzasz w którym miejscu piłka ma kolizję i wyciągasz jednostkowy wektor kx,ky
- obliczasz obecną długość wektora dx,dy (M = sqrt(dx*dx + dy*dy))
- nowe dx,dy = kx*M*alfa,ky*M*alfa
alfa to tłumienie przy zderzeniach. Jak chcesz żeby piłka nie traciła prędkości to alfa = 1, jak chcesz żeby traciła trochę to 0.8, a jak chcesz żeby przyspieszała to 1.2 ;)
To już raczej nie na intach trzeba liczyć tylko na fixed pointach. No i pewnie dy powinien mieć wartości ujemne w górę a dodatnie w dół, wtedy grawitacja byłaby dodatnia. ;)
Ostatnia aktualizacja: 19.12.2022 10:03:54 przez teh_KaiN
19.12.2022 11:14
[#231]
Re: Powstawanie nowej gry w Blitz 2
@teh_KaiN, post #230
Ja miałem prościej w tamtym rozwiązaniu. Miałem xs i ys jako prędkość pionowa i pozioma. Łatwo się sterowało grawitacją, ale za to łuki wychodziły okropnie.
Samo x i y piłki mam jako word. Prędkość mam jako Q i kąt jako word. Nie mam kiedy usiąść do komputera i pisać, a każdy aspekt fizyki lepiej jak przemyślę zanim napiszę, bo strzelać w ciemno też nie ma sensu.
Samo x i y piłki mam jako word. Prędkość mam jako Q i kąt jako word. Nie mam kiedy usiąść do komputera i pisać, a każdy aspekt fizyki lepiej jak przemyślę zanim napiszę, bo strzelać w ciemno też nie ma sensu.
19.12.2022 11:36
[#232]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #231
Łuki wychodziłyby lepiej jakbyś miał ułamki w prędkościach i pozycji, oraz do rysowania używał pomocniczych wartości pozycji z uciętymu miejscami po przecinku. Do tego Ci właśnie potrzebne fixed- albo floating-pointy. Z tego co widzę fixed pointy w BB to typ Quick. Spróbuj z tym.
Ostatnia aktualizacja: 19.12.2022 11:37:39 przez teh_KaiN
Ostatnia aktualizacja: 19.12.2022 11:37:39 przez teh_KaiN
19.12.2022 12:16
[#234]
Re: Powstawanie nowej gry w Blitz 2
@teh_KaiN, post #232
typ Quick mam dla speed. Oto mój NEWTYPE:
@Selur: smacznego ja też idę jeść i do roboty. Napisałem sobie warunek dla piłki, gdy ball\speed>7, żeby piłka za szybko nie leciała, a żeby zachować pęd, bo tak to bardzo szybko mi opadała. Teraz jest ładnie.
Bitmapę roboczą muszę ukrócić o kolory, bo nie ma sensu używać aż 16. Będzie kolor od odbicia, łuku, łapki oraz tych trójkątów i grzybków, co wybijają piłkę na ukos. Dojdzie jeszcze pewnie wymuszony tor piłki oraz łapanie miejsc bonusów.
Ostatnia aktualizacja: 19.12.2022 12:19:25 przez tukinem
NEWTYPE .TBall x.w; wartosc i tak bedzie zaokraglona y.w; to samo vector.w; kat obrotu pilki (0-359 w stopniach) speed.q; predkosc w pikselach/klatke End NEWTYPE DEFTYPE.Tball ball; zdefiniowanie zmiennej pilki
@Selur: smacznego
ja też idę jeść i do roboty. Napisałem sobie warunek dla piłki, gdy ball\speed>7, żeby piłka za szybko nie leciała, a żeby zachować pęd, bo tak to bardzo szybko mi opadała. Teraz jest ładnie.Bitmapę roboczą muszę ukrócić o kolory, bo nie ma sensu używać aż 16. Będzie kolor od odbicia, łuku, łapki oraz tych trójkątów i grzybków, co wybijają piłkę na ukos. Dojdzie jeszcze pewnie wymuszony tor piłki oraz łapanie miejsc bonusów.
Ostatnia aktualizacja: 19.12.2022 12:19:25 przez tukinem
19.12.2022 13:17
[#235]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #234
Ja tak jak Selur niewiele rozumiem, bo za stary juz jestem. Ale z tego co jak gralem w normalne flippery, to poczatkowa szybkosc kulki nadawalo sie lapkami, zgdonie z jakims tam prawem, ze sila razy ramie to cos tam. Czyli najwieksza predkosc poczatkowa pilki, uzyskiwalo sie jak pilka byla na samym koncu lapki oraz wybijajac pilke na starcie sprezyna, nie wiem czy to uwzgledniles, ale mozesz jesli nie uwzgledniles.
19.12.2022 13:50
[#236]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #226
Tam chyba, żadnych sliceów nie ma, do wyświetlenie stołu jest używane DisplayBitmap, a do sprite, DisplaySprite. Z tym nic nie robiłem, bo już było w przykładzie z GitHuba Earoka (samolocik leciał i strzelał po wciśnięciu fire), działało, a odkrywanie innych sposobów na pewno zajęłoby sporo więcej czasu, więc skupiłem się na maksymalnym minimum (pokazać bitmapę, pokazać sprite, zmodyfikować sprite co klatkę).
To zachowanie z sprite jest przynajmniej dziwne, bo jeśli przy inicjalizacji sprote blitz kopiuje sobie jego grafikę gdzieś do lokalnego bufora, to marnuje zasoby jeśli nie masz do tego bufora dostępu, a chciałbyś zmienić jego zawartość bezpośrednio jak przy blitowaniu na stół.
Ja Ciebie podziwiam za upór w opanowywaniu tego języka przy takiej średniej dokumentacji i garstki przykładów, chyba, że masz jakąś dobrą książkę.
To zachowanie z sprite jest przynajmniej dziwne, bo jeśli przy inicjalizacji sprote blitz kopiuje sobie jego grafikę gdzieś do lokalnego bufora, to marnuje zasoby jeśli nie masz do tego bufora dostępu, a chciałbyś zmienić jego zawartość bezpośrednio jak przy blitowaniu na stół.
Ja Ciebie podziwiam za upór w opanowywaniu tego języka przy takiej średniej dokumentacji i garstki przykładów, chyba, że masz jakąś dobrą książkę.
22.12.2022 12:55
[#240]
Re: Powstawanie nowej gry w Blitz 2
@teh_KaiN, post #232
Poddaję się z tą fizyką to nie dla mnie takie strzelanie liczb 
od jutra będę kontynuować tamtą fizykę.
Będzie na pewno poprawiony scroll, będzie dobrze wycięta piłka (bo shape piłki powinien mieć 15x15 pix a nie jak tu 14x14), będzie również usunięty błąd który powodował guru po kilku uruchomieniach gry bez restartu.
to nie dla mnie takie strzelanie liczb od jutra będę kontynuować tamtą fizykę. Będzie na pewno poprawiony scroll, będzie dobrze wycięta piłka (bo shape piłki powinien mieć 15x15 pix a nie jak tu 14x14), będzie również usunięty błąd który powodował guru po kilku uruchomieniach gry bez restartu.