29.05.2023 19:25
[#31]
Re: Zapowiedzi nowych gier
@selur, post #30
14 Pointów jest co ramkę. To nie wina Pointów, bo mogę i 60 sprawdzać i to nic nie zmieni. To jest szybka komenda, nie ta z Amosa.
Co do tego, co robi pętla główna, to naprawdę dużo pisania. Nie na dzisiaj już. Ogólnie wygląda tak:
- wczytywanie stanów wejścia (klawiatura/joy)
- przeliczenia (zmiana bitmapy aktualnej bitmapy i bufora, numeru ramki)
- 14 Pointów, o których pisałem
- ogromne przeliczanie obiektów w komnacie, gdzie każdy praktycznie jest inny (inna animacja, inne rozmiary kolizji z Tonym, inne zachowanie podczas kolizji itd, a nietoperze latające poziomo latają też na ukos, co jest sterowane IF-ami niestety, ale przy tym też nie zwalnia bo to też wyłączałem)
- drugie ogromne przeglądanie IFów i Select/Case'ów dla Tonego, gdzie też jest różna animacja
- wyświetlanie na bitmapie bobów
- wyświetlenie bitmapy
Ogólnie, to racją jest, że im więcej obiektów na ekranie, tym wolniej, ale porównując wersję PAL do NTSC, to w PAL można sobie na 2-3 obiekty więcej pozwolić bez straty płynności, ale wyłączenie sterowania Tonym naprawdę przyspiesza o te kolejne 2 obiekty w NTSC.
Co do tego, co robi pętla główna, to naprawdę dużo pisania. Nie na dzisiaj już. Ogólnie wygląda tak:
- wczytywanie stanów wejścia (klawiatura/joy)
- przeliczenia (zmiana bitmapy aktualnej bitmapy i bufora, numeru ramki)
- 14 Pointów, o których pisałem
- ogromne przeliczanie obiektów w komnacie, gdzie każdy praktycznie jest inny (inna animacja, inne rozmiary kolizji z Tonym, inne zachowanie podczas kolizji itd, a nietoperze latające poziomo latają też na ukos, co jest sterowane IF-ami niestety, ale przy tym też nie zwalnia bo to też wyłączałem)
- drugie ogromne przeglądanie IFów i Select/Case'ów dla Tonego, gdzie też jest różna animacja
- wyświetlanie na bitmapie bobów
- wyświetlenie bitmapy
Ogólnie, to racją jest, że im więcej obiektów na ekranie, tym wolniej, ale porównując wersję PAL do NTSC, to w PAL można sobie na 2-3 obiekty więcej pozwolić bez straty płynności, ale wyłączenie sterowania Tonym naprawdę przyspiesza o te kolejne 2 obiekty w NTSC.
29.05.2023 20:11
[#33]
Re: Zapowiedzi nowych gier
@tukinem, post #31
Dzięki, mniej więcej widzę o co kaman, nie musisz pisać więcej. Pytania które mi się nasuwają
1. Musisz przeliczać te 14 pointów ?
2. To ogromne przeliczanie obiektów musi być takie ogromne ?
3. To samo dla Tonego, czy jesteś pewien że musi to być takie ogromne ?
4. Czy wszystkie obiekty muszą być bobami ?
Sprajty są szybsze o ile dobrze podejdziesz do sprawy. Czyli jak masz Tonego to są dwa sprajty * ilość wszystkich klatek animacji. Wtedy zostaje ci konwersja pozycji na strukturę sprajta i ustawienie pointerów w copperliście (8 wordów do zapisania). W asemblerze spokojnie zmieścić się poniżej 500 cykli (nie chcę pisać 250 cykli żeby nie było przypału).
Teraz z grubsza policzmy co musisz zrobić żeby postawić Tonego(32x32x2) jako boba.
0. Przeliczenie pozycji Tonego na dane dla blitera. Koszt to obliczenia + ustawienie 12 rejestrów blitera. Dochodzi do tego oczywiście czekanie na blitera. Myślę że lekko 200 cykli
1. Oddać stare tło pod Tonym. Kopiowanie (48x32x2 = 192 wordy do skopiowania). Nie wiem ile to cykli przy bliterze ale możemy oszacować jak procesor to robi. Optymistycznie to będzię 192*12 cykli = 2304. To weżmy 2000 cykli
2. Zapamiętać tło pod Tonym. Kopiowanie tak samo jak powyżej czyli 192 wordy do skopiowania. To samo około 2000 cykli
4. Narzucenie Tonego na ekran. Tu już mam ciężej bo to nie jest operacja kopiowania. Dajmy tak ze 3000 cykli.
Razem wychodzi około 7000 cykli, optymistycznie weźmy 5000 cykli. To i tak wychodzi że 10 razy szybciej jest zrobić to sprajtami. I wciąż masz 6 sprajtów wolnych, które możesz dowolnie wykorzystać.
Mam nadzieje że zrozumiałem z tego mojego pseudo wywodu że sprajty są lepsze o ile dobrze się podejdzie do tematu i spełniają wymogi gry.
1. Musisz przeliczać te 14 pointów ?
2. To ogromne przeliczanie obiektów musi być takie ogromne ?
3. To samo dla Tonego, czy jesteś pewien że musi to być takie ogromne ?
4. Czy wszystkie obiekty muszą być bobami ?
Sprajty są szybsze o ile dobrze podejdziesz do sprawy. Czyli jak masz Tonego to są dwa sprajty * ilość wszystkich klatek animacji. Wtedy zostaje ci konwersja pozycji na strukturę sprajta i ustawienie pointerów w copperliście (8 wordów do zapisania). W asemblerze spokojnie zmieścić się poniżej 500 cykli (nie chcę pisać 250 cykli żeby nie było przypału).
Teraz z grubsza policzmy co musisz zrobić żeby postawić Tonego(32x32x2) jako boba.
0. Przeliczenie pozycji Tonego na dane dla blitera. Koszt to obliczenia + ustawienie 12 rejestrów blitera. Dochodzi do tego oczywiście czekanie na blitera. Myślę że lekko 200 cykli
1. Oddać stare tło pod Tonym. Kopiowanie (48x32x2 = 192 wordy do skopiowania). Nie wiem ile to cykli przy bliterze ale możemy oszacować jak procesor to robi. Optymistycznie to będzię 192*12 cykli = 2304. To weżmy 2000 cykli
2. Zapamiętać tło pod Tonym. Kopiowanie tak samo jak powyżej czyli 192 wordy do skopiowania. To samo około 2000 cykli
4. Narzucenie Tonego na ekran. Tu już mam ciężej bo to nie jest operacja kopiowania. Dajmy tak ze 3000 cykli.
Razem wychodzi około 7000 cykli, optymistycznie weźmy 5000 cykli. To i tak wychodzi że 10 razy szybciej jest zrobić to sprajtami. I wciąż masz 6 sprajtów wolnych, które możesz dowolnie wykorzystać.
Mam nadzieje że zrozumiałem z tego mojego pseudo wywodu że sprajty są lepsze o ile dobrze się podejdzie do tematu i spełniają wymogi gry.
29.05.2023 20:29
[#35]
Re: Zapowiedzi nowych gier
@asman, post #33
jasne, ze sprajty beda duzo szybsze ale jestem zdania, ze taka ilosc Bob'ow na ekranie (maksymalnie chyba z 8) o rozmiarze 16*16 w 4 kolorach nie powinna az tak drastycznie wplywac na predkosc dzialania gry.
Mysle, ze blok 'obslugi postaci' sprawdza zbyt duzo niepotrzebnych rzeczy, stad ta powolnosc.
Tam by trzeba szukac lepszego rozwiazania.
Mysle, ze blok 'obslugi postaci' sprawdza zbyt duzo niepotrzebnych rzeczy, stad ta powolnosc.
Tam by trzeba szukac lepszego rozwiazania.
29.05.2023 20:40
[#36]
Re: Zapowiedzi nowych gier
@asman, post #33
Na chwilę obecną muszą być takie duże. Może faktycznie jeszcze gdzieś popełniłem błąd w sterowaniu Tonym i dlatego jest jak jest. Nie mam na obecną chwilę czasu tego sprawdzać, ale wiem że tam tkwi problem.
Nie wiem, czy pisałem o tym, ale pochodnie na ekranie próbowałem zamienić na sprajty 2-bitplanowe. Miałem dzięki temu 6 sprajtów zamiast bobów, co zupełnie nic nie zmieniło. Poza tym że ograniczyło mi kompletnie ilość pochodni w komnacie. Więcej sprajtów nie można wyświetlić.
Ogólna zasada to tak:
Tony ma w swoim typie G\j od skakania, G\k od kierunku w jakim stoi, G\b od biegu, G\c od kucania, G\d od chodzenia po drabince, G\a od numeru grafiki wyświetlania, G\x i G\y to wordy współrzędnych. Całe zachowanie Tonego to sterowanie tymi wszystkimi zmiennymi, sprawdzanie ich, sprawdzanie joya/klawiatury/ sprawdzanie tablocy kolizji. Jest tego dużo. Osobno od biegania, stania w miejscu, kucania, skakania, drabiny i umierania.
Co do kolizji z obiektami. Te nieanimowane nie są bobami, a wklejane w bitmapę. Nieważne, bo jak dam 10 drzwi na komnatę to też będzie wolniej, pomimo że to nie są boby
kolizje z obiektami są w bloku obiektów a nie sterowania Tonym. Każda kolizja ma swoje współrzędne. To nie jest BobCol z Amosa, tylko działa na zasadzie prostokątów. Bardzo szybka funkcja podobno działająca na asemblerze. Jak wspominałem wyłączałem cały blok obiektów i też było wolniej więc to nie to.
Moim zdaniem tu nie ma co dyskutować. Wszystko na pewno składa się w jakiś stopniu do do tego, że muszę ograniczać ilość obiektów. Każdy ma swoje dane, które kod musi przetrawić i nic na to nie poradzę. Zarówno RectsHit, jak i Point to bardzo szybkie funkcje i tu nie ma porównania do Amosa. Ilość przeliczania w tablicach i zmiennych sprawia że NTSC ze slow ramem nie da rady.
Nie wiem, czy pisałem o tym, ale pochodnie na ekranie próbowałem zamienić na sprajty 2-bitplanowe. Miałem dzięki temu 6 sprajtów zamiast bobów, co zupełnie nic nie zmieniło. Poza tym że ograniczyło mi kompletnie ilość pochodni w komnacie. Więcej sprajtów nie można wyświetlić.
Ogólna zasada to tak:
Tony ma w swoim typie G\j od skakania, G\k od kierunku w jakim stoi, G\b od biegu, G\c od kucania, G\d od chodzenia po drabince, G\a od numeru grafiki wyświetlania, G\x i G\y to wordy współrzędnych. Całe zachowanie Tonego to sterowanie tymi wszystkimi zmiennymi, sprawdzanie ich, sprawdzanie joya/klawiatury/ sprawdzanie tablocy kolizji. Jest tego dużo. Osobno od biegania, stania w miejscu, kucania, skakania, drabiny i umierania.
Co do kolizji z obiektami. Te nieanimowane nie są bobami, a wklejane w bitmapę. Nieważne, bo jak dam 10 drzwi na komnatę to też będzie wolniej, pomimo że to nie są boby
kolizje z obiektami są w bloku obiektów a nie sterowania Tonym. Każda kolizja ma swoje współrzędne. To nie jest BobCol z Amosa, tylko działa na zasadzie prostokątów. Bardzo szybka funkcja podobno działająca na asemblerze. Jak wspominałem wyłączałem cały blok obiektów i też było wolniej więc to nie to.Moim zdaniem tu nie ma co dyskutować. Wszystko na pewno składa się w jakiś stopniu do do tego, że muszę ograniczać ilość obiektów. Każdy ma swoje dane, które kod musi przetrawić i nic na to nie poradzę. Zarówno RectsHit, jak i Point to bardzo szybkie funkcje i tu nie ma porównania do Amosa. Ilość przeliczania w tablicach i zmiennych sprawia że NTSC ze slow ramem nie da rady.
30.05.2023 07:55
[#40]
Re: Zapowiedzi nowych gier
@pisklak, post #39
BB ma swój wbudowany debugger. Całkiem niezły wg mnie.
Nie wiem tylko czy się przyda bo jak czytam to co pisze Tukinem to mam wrażenie, że te kolizje są jakoś przekombinowane. Po co 14 punktów kolizji? Skoro można by mieć raptem kilka odczytów położenia na mapie i na tej podstawie decydować czy jest kolizja czy nie.
Nie chcę się wymądrzać, ani pouczać, ale ja tak bym do tego podszedł.
No i sprajty... tutaj aż się prosi aby je wykorzystać.
Nie wiem tylko czy się przyda bo jak czytam to co pisze Tukinem to mam wrażenie, że te kolizje są jakoś przekombinowane. Po co 14 punktów kolizji? Skoro można by mieć raptem kilka odczytów położenia na mapie i na tej podstawie decydować czy jest kolizja czy nie.
Nie chcę się wymądrzać, ani pouczać, ale ja tak bym do tego podszedł.
No i sprajty... tutaj aż się prosi aby je wykorzystać.
30.05.2023 09:25
[#41]
Re: Zapowiedzi nowych gier
@asman, post #37
Znalazłem demo Tony w adf. Po rozpakowaniu exe i zrobieniu szybkiego resourca, przeszukałem pod kątem mnożenia i dzielenia. Oto wyniki
mulu: 867 wystąpienia
muls: 80 wystąpień
divu: 103
divs: 101
znalazłem jeszcze sporo instrukcji trap, bo aż 2309.
Posiłkując się stroną 68k instruction timings to mamy takie zużycie cykli:
mulu / muls : do 70 cykli
divu: do 140 cykli
divs: do 158 cykli
trap: 38 cykli
Do wszystkich tych cykli trzeba dodać dodatkowo cykle obliczenia adresu efektywnego.
To oczywiście tylko statystyka, wciąż nie wiem ile mnożeń/dzieleń występuje w pętli gry i jak często dane funkcje są wołane. Też nie wiadomo ile z tego kodu to martwy kod (nieużywany), bo jak pamiętam czasy gdy miałem blitz zainstalowany to właśnie to mnie najbardziej wkurzało, bez wnikania dowalał martwy kod. Na przykład był kod odczytu joysticka w porcie 1 i był prawie taki sam kod odczytu joysticka w porcie 0.
mulu: 867 wystąpienia
muls: 80 wystąpień
divu: 103
divs: 101
znalazłem jeszcze sporo instrukcji trap, bo aż 2309.
Posiłkując się stroną 68k instruction timings to mamy takie zużycie cykli:
mulu / muls : do 70 cykli
divu: do 140 cykli
divs: do 158 cykli
trap: 38 cykli
Do wszystkich tych cykli trzeba dodać dodatkowo cykle obliczenia adresu efektywnego.
To oczywiście tylko statystyka, wciąż nie wiem ile mnożeń/dzieleń występuje w pętli gry i jak często dane funkcje są wołane. Też nie wiadomo ile z tego kodu to martwy kod (nieużywany), bo jak pamiętam czasy gdy miałem blitz zainstalowany to właśnie to mnie najbardziej wkurzało, bez wnikania dowalał martwy kod. Na przykład był kod odczytu joysticka w porcie 1 i był prawie taki sam kod odczytu joysticka w porcie 0.
30.05.2023 09:42
[#42]
Re: Zapowiedzi nowych gier
@asman, post #41
Jesli tam jest tyle mnozen i dzielen to nie dziwne, ze moze zwalniac. Najlepiej jest uzywac przesuniec bitow w lewo zamiast mnozenia i w prawo zamiast dzielenia, ale to zwykle trzeba dane przerobic na wielokrotnosci 2, przynajmniej te najczesciej uzywane. No i kompilator musi to ogarniac. Bo sam pamietam stary kod z jakiegos kompilatora C lub basica, gdzie bylo mnozenie x2, a to przeciez wystarczy uzyc dodawania, lub przesuniecia w lewo o 1 bit.
30.05.2023 09:49
[#43]
Re: Zapowiedzi nowych gier
@Don_Adan, post #42
i w tym zakresie BB bardzo ładnie to wspiera. Można assembler wplatać w zasadzie dowolnie
W moich programach w BB, o których już kilka razy pisałem robiłem tak że:
poza tym nigdy nie używałem funkcji i procedur Blitza (robiły masę jak dla mnie niepotrzebnych dodatkowych rzeczy) tylko"
co do wyliczeń asmana to wszystko zgoda, ale wydaje mi się, że jest to nie do przeskoczenia jeśli używa się po prostu tylko BB. Tukinem napisał że asm dopiero poznaje.
ja bym szukał sposobów przyspieszenia w optymalniejszych algorytmach no i w sprajtach :)
W moich programach w BB, o których już kilka razy pisałem robiłem tak że:
a = b LSR 1 // dzielenie przez 2 albo a = b ASL 2 // mnożenie przez 4
poza tym nigdy nie używałem funkcji i procedur Blitza (robiły masę jak dla mnie niepotrzebnych dodatkowych rzeczy) tylko"
JSR etykieta etykieta: RTS
co do wyliczeń asmana to wszystko zgoda, ale wydaje mi się, że jest to nie do przeskoczenia jeśli używa się po prostu tylko BB. Tukinem napisał że asm dopiero poznaje.
ja bym szukał sposobów przyspieszenia w optymalniejszych algorytmach no i w sprajtach :)
30.05.2023 12:46
[#46]
Re: Zapowiedzi nowych gier
@asman, post #45
Nie rozumiem dlaczego się tak bardzo tej prędkości uczepiliście. Dla mnie to działa całkiem sprawnie. Wygląda też ok (jak na założony styl dwukolorowy).
Tukinem - dokończ to i wydajcie. Najwyżej później zrobicie wersje 2.0 lub reboot działający szybciej (jeżeli ktoś twierdzi, że jest wolno). Jest wiele nowych crapów, które nie powinny się nawet pojawić i to ich autorzy powinni wziąć sobie uwagi naszych kolegów do serca, a u Ciebie naprawdę nie ma tragedii. Zapowiada się na bardzo fajną, przyjemną gierkę.
Tukinem - dokończ to i wydajcie. Najwyżej później zrobicie wersje 2.0 lub reboot działający szybciej (jeżeli ktoś twierdzi, że jest wolno). Jest wiele nowych crapów, które nie powinny się nawet pojawić i to ich autorzy powinni wziąć sobie uwagi naszych kolegów do serca, a u Ciebie naprawdę nie ma tragedii. Zapowiada się na bardzo fajną, przyjemną gierkę.
30.05.2023 16:09
[#50]
Re: Zapowiedzi nowych gier
@asman, post #41
Nie bierz całego kodu do liczenia, bo sporo dzielenia i mnożenia jest podczas rysowania mapy z kafli 8x8 pix, cracktro z gry też jest kodzie głównym. Nie będę liczyć dzielenia i mnożenia z pętli głównej, bo mi się nie chce :P ale obiecuję że zajrzę jeszcze do samej obsługi Tonego i przejrzę co można przyspieszyć, bo to też było pisane na szybko i niewiele stamtąd później zoptymalizowałem. Moim zdaniem najbardziej spowalnia taki zapis:
If jedno AND drugie AND trzecie AND czwarte AND piąte
___;kod
Endif
Tego tam jest najwięcej. W samej obsłudze Tonego dzielenie i mnożenie znajduje się podczas zaczynania chodzenia po drabince i to jest tylko jedna ramka, żeby wyrównać Tonego na środek drabinki, więc bez przesady. No i kilka razy jest MODULO, czyli reszta z dzielenia, ale to nie ma nic do rzeczy, bo to jest stablicowane, czyli co klatkę wykonuje się kilka różnych MODULO i wpisuje do tablicy, a animacja już sobie z tablicy sprawdza ile wynoszą wartości. Wyłączenie przeliczania tego nie wpływa w żadnym stopniu.
Zawsze wersje NTSC są tak wymagające? :D
If jedno AND drugie AND trzecie AND czwarte AND piąte
___;kod
Endif
Tego tam jest najwięcej. W samej obsłudze Tonego dzielenie i mnożenie znajduje się podczas zaczynania chodzenia po drabince i to jest tylko jedna ramka, żeby wyrównać Tonego na środek drabinki, więc bez przesady. No i kilka razy jest MODULO, czyli reszta z dzielenia, ale to nie ma nic do rzeczy, bo to jest stablicowane, czyli co klatkę wykonuje się kilka różnych MODULO i wpisuje do tablicy, a animacja już sobie z tablicy sprawdza ile wynoszą wartości. Wyłączenie przeliczania tego nie wpływa w żadnym stopniu.
Zawsze wersje NTSC są tak wymagające? :D
30.05.2023 19:47
[#55]
Re: Zapowiedzi nowych gier
@tukinem, post #54
mysle, ze najbardziej brakuje nam wymarzonego srodowiska programowania, szybkiego i przyjaznego zarazem a tymczasem mamy:
AMOS - wybitnie przyjazny uzytkownikowi i wybitnie wolny.
BLITZ - srednio przyjazny i srednio wolny.
C - wybitnie napakowany blibliotekami i toporny w ich uzywaniu ale calkiem szybki.
asembler - wybitnie nieprzyjazny i wybitnie szybki.
AMOS - wybitnie przyjazny uzytkownikowi i wybitnie wolny.
BLITZ - srednio przyjazny i srednio wolny.
C - wybitnie napakowany blibliotekami i toporny w ich uzywaniu ale calkiem szybki.
asembler - wybitnie nieprzyjazny i wybitnie szybki.
30.05.2023 20:00
[#56]
Re: Zapowiedzi nowych gier
@selur, post #55
Jak pisałem, tutaj spowolnienia wydaje mi się, że spowodowane są szybkością slow ramu przy wersji NTSC. Sporo odczytu ze zmiennych i tablic.
Co do porównania C i asemblera, asembler wydaje mi się bardziej przyjazny. Może dlatego, że używam go w Blitzu i mam kompilator pod ręką wraz z debuggerem. Sam fakt, że w C nie umiem napisać kompletnie nic sam od siebie, a w asemblerze to się udaje, chociaż to proste działania i proste odpowiedniki pętli. Może się nabierze z czasem większej wprawy.
Co do porównania C i asemblera, asembler wydaje mi się bardziej przyjazny. Może dlatego, że używam go w Blitzu i mam kompilator pod ręką wraz z debuggerem. Sam fakt, że w C nie umiem napisać kompletnie nic sam od siebie, a w asemblerze to się udaje, chociaż to proste działania i proste odpowiedniki pętli. Może się nabierze z czasem większej wprawy.
30.05.2023 20:39
[#57]
Re: Zapowiedzi nowych gier
@tukinem, post #54
Czego nam programistom/koderom brakowało do napisania wymarzonej gry? Dobrego pomysłu na grę. Ile można grać w Dooma? 30 lat to już chyba wystarczy żeby zrobić sobie od niego przerwę
Dobry pomysł na gre to fajna sprawa tylko trzeba go najpierw mieć
Ostatnia aktualizacja: 30.05.2023 20:40:14 przez Azakiel
30.05.2023 20:53
[#59]
Re: Zapowiedzi nowych gier
@selur, post #55
AMOS - wybitnie przyjazny uzytkownikowi i wybitnie wolny.
zanim robilismy "limes inferior" na amige (który powstawał głównie w C) wczesniej bawilismy sie w różne projekty w Amosie - jednym z nich była gra w stylu Arkanoid, na dole paletka z animowanymi silnikami odrzutowymi, na górze klocki , oraz dużo róznych bonusów (np harpun, laser, poszerzenie paletki, bomba, itp) mielismy zrobioną duzą ilosc leveli i jednego bossa który miał swój ekran początkowy zrobiony w Realu 3D (po kazdym świecie był boss do pokonania) boss strzelał i latał po planszy a my walilismy w niego piłką. Pamietam ze gra chyba była w sumie zrobiona praktycznie cała z wyjątkiem bossów ale nie chodziła zadowalająco dobrze (jakos tam od biedy chodziła ale chcielismy dołozyć troche wiecej bajerów zeby to nie był zwykły klon arkanoida ale na to juz Amos nie pozwalał pod kątem prędkosci) i projekt został zarzucony .
30.05.2023 21:04
[#60]
Re: Zapowiedzi nowych gier
@Azakiel, post #59
....ale na to juz Amos nie pozwalał pod kątem prędkosci i projekt został zarzucony
i tak wlasnie konczylo zywot 90% amosowych projektow gier.
Gdyby AMOS byl stosunkowo szybki, to powstalo by w nim nie 100 a kilka tysiecy gier ... no ale wiadomo, gdyby BABCIA miala 'wonsa', to by byla soltysem