17.12.2022 23:05
[#181]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #180
Miszczuniu wez wywal ta instrukcje point(), to jest bardzo czasochlonna instrukcja (szczegolnie dla wielu bitplanow).
Zastap wszystko tablica 160*256 elementow czyli ekran podzielony przez dwa. To tylko 40kb danych we Fascie.
Odczyt pilki bedzie wygladal : px=pilka_x/2, py=pilka_y/2, adres=py*160+px , wartosc_pola=peek(adres).
Aby jeszcze bardziej przyspieszyc dzialanie, dzielenie przez dwa zastepujesz rotacja bitow zmiennej w prawo a dla mnozenia *160 robisz tablice (LUT) z 256 elementow po 4 bajty, dla kazdego Y z podanym adresem.
Zastap wszystko tablica 160*256 elementow czyli ekran podzielony przez dwa. To tylko 40kb danych we Fascie.
Odczyt pilki bedzie wygladal : px=pilka_x/2, py=pilka_y/2, adres=py*160+px , wartosc_pola=peek(adres).
Aby jeszcze bardziej przyspieszyc dzialanie, dzielenie przez dwa zastepujesz rotacja bitow zmiennej w prawo a dla mnozenia *160 robisz tablice (LUT) z 256 elementow po 4 bajty, dla kazdego Y z podanym adresem.
17.12.2022 23:13
[#182]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #180
Jeśli ten Point(,) jest taki wolny jak amosowy, to może warto się zastanowić nad innym rozwiązaniem? Zamiast bitmapy, można stworzyć obszar w pamięci (tablicę z elementami 1-bajtowymi) z wartościami kolorów i czytać peek'iem z pamięci zamiast Point'em z bitmapy.
Poza tym czy ja dobrze rozumiem, że używasz w kodzie dzielenia (lub mnożenia?). Tego trzeba unikać gdzie się da, bo to wolne jest. Dzielenie przez 2 (lub 4,8,16 itd) można zrobić poprzez rotację bitów. W amosie się to robi za pomocą Ror.b (dla bajtów) i Ror.w (dla word'ów). Nie wiem jak się to robi w BlitzBasicu, to już ktoś kompetentny by się musiał wypowiedzieć.
PS O widzę, że Selur mnie uprzedził. Wszelkie mnożenia/dzielenia lepiej sobie poprzeliczać do tablic i odczytywać, niż wykonywać te działania na żywca w pętli głównej.
Ostatnia aktualizacja: 17.12.2022 23:16:17 przez mastaszek
Poza tym czy ja dobrze rozumiem, że używasz w kodzie dzielenia (lub mnożenia?). Tego trzeba unikać gdzie się da, bo to wolne jest. Dzielenie przez 2 (lub 4,8,16 itd) można zrobić poprzez rotację bitów. W amosie się to robi za pomocą Ror.b (dla bajtów) i Ror.w (dla word'ów). Nie wiem jak się to robi w BlitzBasicu, to już ktoś kompetentny by się musiał wypowiedzieć.
PS O widzę, że Selur mnie uprzedził. Wszelkie mnożenia/dzielenia lepiej sobie poprzeliczać do tablic i odczytywać, niż wykonywać te działania na żywca w pętli głównej.
Ostatnia aktualizacja: 17.12.2022 23:16:17 przez mastaszek
18.12.2022 02:37
[#187]
Re: Powstawanie nowej gry w Blitz 2
@selur, post #183
Skoro w sumie już zjechałeś z tym stołem do 32 kolorów - tą rampą bym się nie przejmował, dithering można poprawić - to może spróbowałbyś o ile by ci się chciało, zrobić przynajmniej jakieś upośledzone demko w Amosie na szybko, bo zaraz się okaże, że to może normalnie śmigać na ECS.
Ostatnia aktualizacja: 18.12.2022 02:37:52 przez san_u
Ostatnia aktualizacja: 18.12.2022 02:37:52 przez san_u
18.12.2022 02:51
[#188]
Re: Powstawanie nowej gry w Blitz 2
@san_u, post #187
Moge jedynie dokonczyc przerabianie tego obrazka ze stolem, ale nie podejmuje sie tworzenia pinibala nawet dla celow testowych (zreszta to kompletnie nie moj typ gier), aczkolwiek na forum jest przynajmniej kilka osob, ktore wladaja AMOS'em i moze one stworzylyby jakas namiastke. 
Trzeba dac ogloszenie i cos na zachete. Moze obeitnica, ze jak to zrobia ta konwersje, to przez tydzien dostana moderatora na PPA i zarcie w KFC za darmo
Trzeba dac ogloszenie i cos na zachete. Moze obeitnica, ze jak to zrobia ta konwersje, to przez tydzien dostana moderatora na PPA i zarcie w KFC za darmo
18.12.2022 05:07
[#192]
Re: Powstawanie nowej gry w Blitz 2
@selur, post #191
Ja u siebie pobieram z 4 bitplanów. Dajmy spokój. Pisałem że to blitowanie wyświetlacza elektronicznego spowalniało. Na potrzeby dopisania fizyki gry do końca zostawię go jeszcze "aktywnego" co 8 klatek, ale później będzie ręcznie sterowany, czyli wtedy gdy się zdobędzie punkt. On jest w pojedynczym buforowaniu więc niech sobie blituje całość w jednej klatce. Nie będę tego rozbijać bo procedura od niego jest skończona.
Jeśli Ci się nudzi to możesz użyć swego talentu i usunąć z głową te łapki z bitmapy?
ja się tego nie podejmę
Jeśli Ci się nudzi to możesz użyć swego talentu i usunąć z głową te łapki z bitmapy?
ja się tego nie podejmę 18.12.2022 07:09
[#196]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #189
Tablice za zwykle duzo szybsze niz mnozenie i dzielenie na 68k (oprocz 68060 i 68080), dlatego sie ich uzywa. Wiec albo to jest specyficzny lub dziwny kod, albo po prostu nie ma prawidlowej emulacji szybkosci 68020 w WinUAE. Testy najlepiej dokonac na prawdziwej 68020, a jesli w WinUAE to wybrac 68000.
18.12.2022 10:12
[#198]
Re: Powstawanie nowej gry w Blitz 2
@mastaszek, post #182
Tego trzeba unikać gdzie się da, bo to wolne jest. Dzielenie przez 2 (lub 4,8,16 itd) można zrobić poprzez rotację bitów. W amosie się to robi za pomocą Ror.b (dla bajtów) i Ror.w (dla word'ów). Nie wiem jak się to robi w BlitzBasicu, to już ktoś kompetentny by się musiał wypowiedzieć
chyba nie rotacje bitów a logiczne przesunięcia (Logical Shift). drobna różnica, bez uszczypliwości ;)
W BB można zastosować w wyrażeniu po prostu komendy assemblera więc dzielenie przez dwa będzie wyglądało tak:
px=pilka_x LSR 1
mnożenie przez 160 można faktycznie ztablicować ale nie robił bym tego w tabliczach Dim. Te, jak mam wrażenie też nie są za szybkie. Ja używałem po prostu "assemblerowaego" deklarowania przestrzeni pamięci przez Dc.b, Dc.w.
Można też zrobić rozdzielność mnożenie względem dodawania (podstawówka ;) ) go 160 = 128+32 i to by była suma przesunięć x LSL 7 + x LSL 5
No i najlepsza chyba rzecz w BB to to, że można w dowolnym miejsu pisać w assemblerze oraz podejrzeć we wbudowanym debugerze kod asm jaki się generuje.
Ostatnia aktualizacja: 18.12.2022 10:12:39 przez c64portal
18.12.2022 11:18
[#199]
Re: Powstawanie nowej gry w Blitz 2
@selur, post #197
Dobra napisałem swój tester na Amidze bezpośrednio.
Oto mój kod napisany na prawdziwej Amidze.
Przy ustawieniu bitmapy na 8 bitplanów, wypluwa wyniki:
POINT: 600
TAB: 314
Przy 7 bitpmanach:
POINT: 550
TAB: 314
Przy 4 bitplanach (jak w Pinballu):
POINT: 462
TAB: 313 (takie odchylenie odczytu bym olał)
Więc reasumując 313, a 462 to różnica raczej nie kolosalna prawda?
Do kodu chyba nikt nie ma zastrzeżeń?
Ostatnia aktualizacja: 18.12.2022 11:28:07 przez tukinem
Oto mój kod napisany na prawdziwej Amidze.
Przy ustawieniu bitmapy na 8 bitplanów, wypluwa wyniki:
POINT: 600
TAB: 314
Przy 7 bitpmanach:
POINT: 550
TAB: 314
Przy 4 bitplanach (jak w Pinballu):
POINT: 462
TAB: 313 (takie odchylenie odczytu bym olał)
Więc reasumując 313, a 462 to różnica raczej nie kolosalna prawda?
Do kodu chyba nikt nie ma zastrzeżeń?
Ostatnia aktualizacja: 18.12.2022 11:28:07 przez tukinem
18.12.2022 12:50
[#201]
Re: Powstawanie nowej gry w Blitz 2
@tukinem, post #199
Roznica nie jest duza, ale chyba najszybsza bylaby wersja wspomniana wyzej przez "c64portal". Czyli czysty asembler skoro sie da dolaczyc do BB. Czyli np. tak:
lsl.l #5,D0 ; *32
move.l D0,D1 ; *32
lsl.l #2,D1 ; * 128
add.l D1,D0 ; * 160
Input D0, output D0
temp D1
Mozna tez uzyc innych rejestrow i dostosowac do kodu BB.
lsl.l #5,D0 ; *32
move.l D0,D1 ; *32
lsl.l #2,D1 ; * 128
add.l D1,D0 ; * 160
Input D0, output D0
temp D1
Mozna tez uzyc innych rejestrow i dostosowac do kodu BB.
18.12.2022 15:31
[#205]
Re: Powstawanie nowej gry w Blitz 2
@AmiClassic, post #204
Dzięki za przetestowanie :) Cieszę się, że się podoba. U mnie działa z podobną płynnością.
@Mastaszek: często używam Point, a nawet za często bo chyba ze 30 razy w klatce, ale to nie robi znaczenia, bo testy, które robiłem tu programem to były testy 320x512 razy, więc to jest pikuś.
Próbuję bardziej profesjonalnie podejść do rzeczy i całą fizykę napisać w takim stylu, w jakim są oryginały napisane.
@Mastaszek: często używam Point, a nawet za często bo chyba ze 30 razy w klatce, ale to nie robi znaczenia, bo testy, które robiłem tu programem to były testy 320x512 razy, więc to jest pikuś.
Próbuję bardziej profesjonalnie podejść do rzeczy i całą fizykę napisać w takim stylu, w jakim są oryginały napisane.
18.12.2022 17:54
[#207]
Re: Powstawanie nowej gry w Blitz 2
@juen, post #206
320 * 512 odczytów dało 200 kilka milisekund, czy jak to nazwać
30 odczytów da kolosalną różnicę?
Zresztą ja fizykę będę pisać od nowa.
Mam zastosowany wektor. Na klatkę są sprawdzane 3 punkty piłki (przód zgodny z kierunkiem ruchu oraz 2 na ukos). Więc 3 odczyty Point na klatkę to już będzie chyba idealnie prawda?
Ostatnia aktualizacja: 18.12.2022 17:56:46 przez tukinem
30 odczytów da kolosalną różnicę?
Zresztą ja fizykę będę pisać od nowa.
Mam zastosowany wektor. Na klatkę są sprawdzane 3 punkty piłki (przód zgodny z kierunkiem ruchu oraz 2 na ukos). Więc 3 odczyty Point na klatkę to już będzie chyba idealnie prawda?
Ostatnia aktualizacja: 18.12.2022 17:56:46 przez tukinem
18.12.2022 20:32
[#209]
Re: Powstawanie nowej gry w Blitz 2
@michal_zukowski, post #208
Mógłby dać jakieś skromne przeliczenia
Zanim dogram teraz fizykę piłki od nowa to miną ze 2 tygodnie, ale wiem że jestem na dobrej drodze i że w oryginale również stosowano wektor kierunku piłki i prędkość.
Dziwi mnie że autor pisze o wykrywaniu kolizji na każdym pikselu piłki, skoro piłka zawsze uderza przodem lub bocznym rogiem o przeszkodę przy tej fizyce.
Zanim dogram teraz fizykę piłki od nowa to miną ze 2 tygodnie, ale wiem że jestem na dobrej drodze i że w oryginale również stosowano wektor kierunku piłki i prędkość.
Dziwi mnie że autor pisze o wykrywaniu kolizji na każdym pikselu piłki, skoro piłka zawsze uderza przodem lub bocznym rogiem o przeszkodę przy tej fizyce.