21.03 22:49
[#91]
Re: Gry na Amigę. Dołącz!
@x01, post #90
Ja akurat nie sprzedałem swoich Amig ale leżały w kartonach. Problemem były koszmarnie drogie rozszerzenia. Przypadkiem dowiedziałem się o Pistormie. Tanie rozszerzenie o potężnych możliwościach. To spowodowało, że wróciłem do zabawy z Amigą. Jakoś na PC nie chciało mi się grać ale na Ami z przyjemnością gram w porty, które kiedyś były poza moim zasięgiem. To taka miła odskocznia.
22.03 11:14
[#93]
Re: Gry na Amigę. Dołącz!
@amikoksu, post #70
Zanosi sie, ze cos ma byc pokazane dotyczace Metro Siege
link
Ale to moze bedzie jeden level wiecej lub ta ukryta postac.
W kazdym razie wyglada mi to na projekt wieloletni, moze dozyje jego konca.
Tak samo jak Grind.
Jedynie Engine 9000 jest robione sprawnie i szybko, ale to dla programistow/koderow.
link
Ale to moze bedzie jeden level wiecej lub ta ukryta postac.
W kazdym razie wyglada mi to na projekt wieloletni, moze dozyje jego konca.
Tak samo jak Grind.
Jedynie Engine 9000 jest robione sprawnie i szybko, ale to dla programistow/koderow.
23.03 15:39
[#95]
Re: Gry na Amigę. Dołącz!
@tukinem, post #89
W sprawie SFX'ów pożerających pamięć. To ja dodam że jeśli jest bardzo krucho to schodzimy w dół z 22050 na 11025. Na pewno warto też rozważyć kilka sztuczek oprócz schodzenia z jakości.
1. Kalkulacja jakie sample będę użyte w i wczytywanie tylko nich.
2. Pakowanie sampli i depakowanie w locie - nie weim czy jakaś gra, która tego używa, może Don Adan coś więcej wie.
3. Dzielenie sampli na mniejsze kawałki, szczególnie gdy mamy 'mówione' sample. Na przykład tak jest w Project X. Inny przykład. zamiast sampli typu "go left", "go right", masz trzy sample "go", "left", "right" .
Korzyść - odpadło jedno "go", sumarycznie te 3 sample powinny zająć mniej miejsca niż poprzednie dwa.
4. Używanie tego sample ale z innym periodem. Szczególnie gdy zbieramy podobne itemy i chcemy wywołać wrażenie że tych sample jest więcej.
5. Podobnie jak w 4 ale tu bawimy się długością i startem sampla.
A jeśli chodzi o dużo bogatych animacji to dużo też zależy od umiejetności i podejścia.
1. Jeśli zrezygnujemy z bobów typu interleaved to mamy dużą oszczędność na maskach takich bobów. Kosztem jest prędkość, szczególnie przy krótkich blitach.
2. Jeśli używamy llustrzanych odbić, mowa o flip x, to możemy; tracąc na prędkości; liczyć je w locie.
3. Jak dobrze kojarzę to flip y można zrobić za pomocą blitera.
4. Nie przechowujemy bobów i mask razem z dodatkowym słowem (używam do tego celu maskowania bltafwm i bltalwm). Jak mamy boba szerokości 16 pikseli to nie przechowujemy go jako boba 32 pikseli (w jakieś grze to widziałem, chyba w Bagitmenie od Bignonii).
Jak znacie jeszcze sztuczki to śmiało.
1. Kalkulacja jakie sample będę użyte w i wczytywanie tylko nich.
2. Pakowanie sampli i depakowanie w locie - nie weim czy jakaś gra, która tego używa, może Don Adan coś więcej wie.
3. Dzielenie sampli na mniejsze kawałki, szczególnie gdy mamy 'mówione' sample. Na przykład tak jest w Project X. Inny przykład. zamiast sampli typu "go left", "go right", masz trzy sample "go", "left", "right" .
Korzyść - odpadło jedno "go", sumarycznie te 3 sample powinny zająć mniej miejsca niż poprzednie dwa.
4. Używanie tego sample ale z innym periodem. Szczególnie gdy zbieramy podobne itemy i chcemy wywołać wrażenie że tych sample jest więcej.
5. Podobnie jak w 4 ale tu bawimy się długością i startem sampla.
A jeśli chodzi o dużo bogatych animacji to dużo też zależy od umiejetności i podejścia.
1. Jeśli zrezygnujemy z bobów typu interleaved to mamy dużą oszczędność na maskach takich bobów. Kosztem jest prędkość, szczególnie przy krótkich blitach.
2. Jeśli używamy llustrzanych odbić, mowa o flip x, to możemy; tracąc na prędkości; liczyć je w locie.
3. Jak dobrze kojarzę to flip y można zrobić za pomocą blitera.
4. Nie przechowujemy bobów i mask razem z dodatkowym słowem (używam do tego celu maskowania bltafwm i bltalwm). Jak mamy boba szerokości 16 pikseli to nie przechowujemy go jako boba 32 pikseli (w jakieś grze to widziałem, chyba w Bagitmenie od Bignonii).
Jak znacie jeszcze sztuczki to śmiało.
23.03 17:11
[#96]
Re: Gry na Amigę. Dołącz!
@asman, post #95
W Escape V3locity był taki myk, że boby przeciwników były rysowane 14x14px z przeźroczystą ramką ze wszytkich stron. Dzięki temu jakoś. oszczedzeło się blity z zastrzeżeniem, że nie mogą na siebie nachodzić, bo robiła się kaszana. sandruzzo coś mi tłumaczył ale niewiele rozumiałem ;) Może rozjaśnisz?
https://youtu.be/hOGpaAhXn4Q?si=efQeivoRXCOKL4Be
https://youtu.be/hOGpaAhXn4Q?si=efQeivoRXCOKL4Be
23.03 20:27
[#97]
Re: Gry na Amigę. Dołącz!
@ppill, post #96
@ppill
Zapomniałeś powiedzieć o jeszcze jednej bardzo ważnej sprawie w przypadku gdy mamy boba 14x14 z ramką. Chodzi o ruch. By to działało musi się przesuwać z prędkością 1 piksel. Są jeszcze inne obostrzenia ale one zależa od sposobu w jaki zajmujemy się bobami.
Weźmy najszybszy sposób stawiania bobów (bez skojarzeń - dzięki Carrion - teraz to już za późno :)). Czyli dual playfield. Pierwszy 8 kolorowy ekran to tło (background) a drugi też 8 kolorowy służy dla bobów. Wtedy wygląda to tak:
1. Czyścimy tło pod bobem (mowa o drugim ekranie) (blitter - channel D)
2. Narzucamy boba (blitter - A + B'C -> D, channels A,B,C,D)
Super, nie mamy zapamiętywania tła pod bobem, czyli odpada kopiowanie A->D i odpada dodatkowy bufor na te dane.
Zauważmy od razu jedną prostą rzecz, czy aby na pewno musimy pierwszego boba narzucać za pomocą cookie cut ? Nie, możemy go zwyczajnie skopiować, co jest szybsze (kopiowanie A->D).
Kolejny wniosek, możemy to zrobić z dowolną ilością bobów o ile nie nachodzą na siebie (dla boba 16x16 wtedy rozważamy bloki 32x16).
Przypuśćmy że boby nie nachodzą na siebie (na przykłąd mamy 5 bobów i każdy ma Y oddalony od poprzedniego 20 pikseli). Jeśli boby stoią w miejscu to czy musimy wykonywać jakikolwiek z kroków 1,2 ? Otóż musimy na pewno wykonać tylko krok 2. Tu wystarczy by przed pętlą gry je narzucić (postawić :)) i już.
A jeśli mamy teraz boba 14x14 z ramką i poruszamy się ze stałą prędkością 1 piksela. To czy krok 1. jest konieczny ? Nie jest. gdyż rozmiar boba (jego ramka) powoduje że gdy zmieniamy x na x + 1, to ramka czyści to co tam było. W ten sposób możemy mieć wiele bobów poruszających się i jest to wydajniejsze od cookie cut bo robimy tylko kopiownie A->D.
Tu można iść dalej i dać boba 12x12, wtedy możemy mieć dwie prędkości o 1 piksel i 2 piksele. By mózg nie wybuchł nie rozważamy ruchu o pół piksela albo o 1/4 piksela, wtedy można jeszcze zwiększyć ilość bobów (sprytnie ustawiając pozycje X tak by przy ruchu o pół piksela, ruszała się tylko połowa obiektów o tej prędkości, i itd)
Taka jest idea boba 14x14 z ramką. Ale czy w przypadku gdy nie używamy dual playfield to jesteśmy w zadzie i musimy robić aż trzy kroki by mieć boba (odtworzenie A->D, zapamiętanie A->D, narzucenie A+B'C->D) ?
1. Jeśli mamy 3 bufory to krok zapamiętanie A->D odpada, mamy wtedy dwa. W przypadku boba z ramką możemy wywalić odtworzenie. Narzucenie robimy w ten sposób że źródło ekranu (channel C) bierzemy z trzeciego bufora i już.
2. Mamy dwa bufory bądź jeden - tu chyba nie ma takiej możliwości by coś zaoszczędzić, jeśli się mylę to poprawcie mnie. Dużo zależy od tła po którym mają poruszać się boby. Na pewno można coś ugrać.
W sumie niezły artek mógłby z tego powstać, bo jest sporo tricków. Tylko pytanie czy ktoś by to czytał ?
Zapomniałeś powiedzieć o jeszcze jednej bardzo ważnej sprawie w przypadku gdy mamy boba 14x14 z ramką. Chodzi o ruch. By to działało musi się przesuwać z prędkością 1 piksel. Są jeszcze inne obostrzenia ale one zależa od sposobu w jaki zajmujemy się bobami.
Weźmy najszybszy sposób stawiania bobów (bez skojarzeń - dzięki Carrion - teraz to już za późno :)). Czyli dual playfield. Pierwszy 8 kolorowy ekran to tło (background) a drugi też 8 kolorowy służy dla bobów. Wtedy wygląda to tak:
1. Czyścimy tło pod bobem (mowa o drugim ekranie) (blitter - channel D)
2. Narzucamy boba (blitter - A + B'C -> D, channels A,B,C,D)
Super, nie mamy zapamiętywania tła pod bobem, czyli odpada kopiowanie A->D i odpada dodatkowy bufor na te dane.
Zauważmy od razu jedną prostą rzecz, czy aby na pewno musimy pierwszego boba narzucać za pomocą cookie cut ? Nie, możemy go zwyczajnie skopiować, co jest szybsze (kopiowanie A->D).
Kolejny wniosek, możemy to zrobić z dowolną ilością bobów o ile nie nachodzą na siebie (dla boba 16x16 wtedy rozważamy bloki 32x16).
Przypuśćmy że boby nie nachodzą na siebie (na przykłąd mamy 5 bobów i każdy ma Y oddalony od poprzedniego 20 pikseli). Jeśli boby stoią w miejscu to czy musimy wykonywać jakikolwiek z kroków 1,2 ? Otóż musimy na pewno wykonać tylko krok 2. Tu wystarczy by przed pętlą gry je narzucić (postawić :)) i już.
A jeśli mamy teraz boba 14x14 z ramką i poruszamy się ze stałą prędkością 1 piksela. To czy krok 1. jest konieczny ? Nie jest. gdyż rozmiar boba (jego ramka) powoduje że gdy zmieniamy x na x + 1, to ramka czyści to co tam było. W ten sposób możemy mieć wiele bobów poruszających się i jest to wydajniejsze od cookie cut bo robimy tylko kopiownie A->D.
Tu można iść dalej i dać boba 12x12, wtedy możemy mieć dwie prędkości o 1 piksel i 2 piksele. By mózg nie wybuchł nie rozważamy ruchu o pół piksela albo o 1/4 piksela, wtedy można jeszcze zwiększyć ilość bobów (sprytnie ustawiając pozycje X tak by przy ruchu o pół piksela, ruszała się tylko połowa obiektów o tej prędkości, i itd)
Taka jest idea boba 14x14 z ramką. Ale czy w przypadku gdy nie używamy dual playfield to jesteśmy w zadzie i musimy robić aż trzy kroki by mieć boba (odtworzenie A->D, zapamiętanie A->D, narzucenie A+B'C->D) ?
1. Jeśli mamy 3 bufory to krok zapamiętanie A->D odpada, mamy wtedy dwa. W przypadku boba z ramką możemy wywalić odtworzenie. Narzucenie robimy w ten sposób że źródło ekranu (channel C) bierzemy z trzeciego bufora i już.
2. Mamy dwa bufory bądź jeden - tu chyba nie ma takiej możliwości by coś zaoszczędzić, jeśli się mylę to poprawcie mnie. Dużo zależy od tła po którym mają poruszać się boby. Na pewno można coś ugrać.
W sumie niezły artek mógłby z tego powstać, bo jest sporo tricków. Tylko pytanie czy ktoś by to czytał ?
23.03 20:51
[#98]
Re: Gry na Amigę. Dołącz!
@asman, post #97
Dzięki :)
Na pewno nie Dual, bo było w 32 kolorach a raczej potrójny bufor ekranu. Sporo też rzeczy było narysowane w pierwszych 8 kolorach i tylko te bitplany były odnawiane (chyba). Jeszcze fajny trick z żonglowaniem wskaźnikami do sprite'ów by uzyskać efekt scrolla dla tła.
Na pewno nie Dual, bo było w 32 kolorach a raczej potrójny bufor ekranu. Sporo też rzeczy było narysowane w pierwszych 8 kolorach i tylko te bitplany były odnawiane (chyba). Jeszcze fajny trick z żonglowaniem wskaźnikami do sprite'ów by uzyskać efekt scrolla dla tła.
23.03 21:14
[#99]
Re: Gry na Amigę. Dołącz!
@asman, post #97
Jeśli chodzi o Boby bez zapamiętywania tła, oraz uwzględniająca nieaktywne Boby, to ja stosuję taką metodę, że dzielę sobie obraz na klocki. Następnie:
1. Przygotowanie do rysowania. Przechodzę przez listę aktywnych (animowanych lub poruszajacych się) Bobów i oznaczam flagą klocki pod ich starą pozycją, o ile nie zostały już oznaczone. Jeżeli są oznaczane po raz pierwszy, rysuję te klocki tła. Oznaczam też nową pozycję w specjalny sposób.
2. Boby nieaktywne. Przechodzę przez listę nieaktywnych Bobów i sprawdzam, czy któryś nie został zamazany, sprawdzając oznaczenie pod klockami na których się znajduje. Dodaję do listy Bobów do odrysowania.
3. Rysowanie. Rysuję wszystkie Boby aktywne, oraz te nieaktywne dodane do odrysowania. Usuwam wszystkie oznaczenia z klocków.
Zalety:
- Nie trzeba zapamiętywać tła,
- Tło obiektów na jednym klocku jest odrysowywane tylko raz,
- Obsługa bobów nieaktywnych, oszczędzających czas Blittera,
- Wybrana kolejność rysowania nawet dla bobów nieaktywnych.
Jeżeli chcemy animować klocki tła tą metodą, przy zachowaniu kosztu przejścia listy, dodajemy klocek jako Bob "bez grafiki", który stymuluje tło do odrysowania.
Ostatnia aktualizacja: 23.03.2026 21:31:41 przez Hexmage960
1. Przygotowanie do rysowania. Przechodzę przez listę aktywnych (animowanych lub poruszajacych się) Bobów i oznaczam flagą klocki pod ich starą pozycją, o ile nie zostały już oznaczone. Jeżeli są oznaczane po raz pierwszy, rysuję te klocki tła. Oznaczam też nową pozycję w specjalny sposób.
2. Boby nieaktywne. Przechodzę przez listę nieaktywnych Bobów i sprawdzam, czy któryś nie został zamazany, sprawdzając oznaczenie pod klockami na których się znajduje. Dodaję do listy Bobów do odrysowania.
3. Rysowanie. Rysuję wszystkie Boby aktywne, oraz te nieaktywne dodane do odrysowania. Usuwam wszystkie oznaczenia z klocków.
Zalety:
- Nie trzeba zapamiętywać tła,
- Tło obiektów na jednym klocku jest odrysowywane tylko raz,
- Obsługa bobów nieaktywnych, oszczędzających czas Blittera,
- Wybrana kolejność rysowania nawet dla bobów nieaktywnych.
Jeżeli chcemy animować klocki tła tą metodą, przy zachowaniu kosztu przejścia listy, dodajemy klocek jako Bob "bez grafiki", który stymuluje tło do odrysowania.
Ostatnia aktualizacja: 23.03.2026 21:31:41 przez Hexmage960
24.03 11:19
[#100]
Re: Gry na Amigę. Dołącz!
@Hexmage960, post #99
Dzięki za opisanie tej metody. Jak dobrze zrozumiałem kosztem dodatkowych obliczeń rezygnujesz z zapamiętywania tła. Jeśli koszt jest mniejszy niż zapamiętanie to jest korzyść. Chociaż muszę przyznać że brzmi to skomplikowanie, niejasne dla mnie jest skąd wiesz które klocki oznaczyć i jak poradzić sobie w sytuacjach gdy boby nachodzą na siebie i stoją na przecięciu klocków. Na przykład klocki są 16x16 a boby są 32x32.
24.03 12:20
[#101]
Re: Gry na Amigę. Dołącz!
@asman, post #100
niejasne dla mnie jest skąd wiesz które klocki oznaczyć i jak poradzić sobie w sytuacjach gdy boby nachodzą na siebie i stoją na przecięciu klocków. Na przykład klocki są 16x16 a boby są 32x32.
Klocki do oznaczenia i odrysowania ustalam taką pętlą:
Na wejściu mam współrzędne lewego górnego i prawego dolnego rogu Boba (wystarczy lewy górny róg i rozmiar Boba by to ustalić).
#define WIDTH 4 /* Przesunięcie bitowe */
#define HEIGHT 4
WORD x0, y0, x1, y1; /* Współrzędne lewego górnego i prawego dolnego rogu Boba */
const WORD width = 1 << WIDTH, height = 1 << HEIGHT; /* Rozmiary klocka */
for( y = y0; y <= y1; y += height )
{
for( x = x0; x <= x1; x += width )
{
Block *block = blocks[ y >> HEIGHT ][ x >> WIDTH ];
/* Oznaczamy/rysujemy klocek */
}
}Ostatnia aktualizacja: 24.03.2026 12:38:35 przez Hexmage960
24.03 12:41
[#102]
Re: Gry na Amigę. Dołącz!
@Hexmage960, post #101
Przepraszam, zrobiłem błąd. Poniżej jest poprawnie:
#define WIDTH 4 /* Przesunięcie bitowe */
#define HEIGHT 4
WORD x0, y0, x1, y1; /* Współrzędne lewego górnego i prawego dolnego rogu Boba */
x0 >>= WIDTH;
x1 >>= WIDTH;
y0 >>= HEIGHT;
y1 >>= HEIGHT;
for( y = y0; y <= y1; y++ )
{
for( x = x0; x <= x1; x++)
{
Block *block = blocks[ y ][ x ];
/* Oznaczamy/rysujemy klocek */
}
} 24.03 12:46
[#103]
Re: Gry na Amigę. Dołącz!
@Commodore128D, post #1
Ugryzę temat ale trochę przewrotnie. Może sam znajdziesz odpowiedź ;)
Masz w mojej sygnaturce link do względnie nowych gier na Amigę, działają w większości na byle pięćsecie i są do wzięcia nawet za darmo. Załóżmy na chwilę, że skoro napisałeś że nie powstają dobre gry, to one nie są dobre. Daj znać czemu.
Chyba że chodzi Ci tylko o to że na komodorca ostatnio były 4 dobre gry a na Amigę mniej. No to odpowiedź jest taka że nie ma komu ich robić. Albo o nich nie słyszałeś. Albo kryteria masz za wysokie.
Masz w mojej sygnaturce link do względnie nowych gier na Amigę, działają w większości na byle pięćsecie i są do wzięcia nawet za darmo. Załóżmy na chwilę, że skoro napisałeś że nie powstają dobre gry, to one nie są dobre. Daj znać czemu.
Chyba że chodzi Ci tylko o to że na komodorca ostatnio były 4 dobre gry a na Amigę mniej. No to odpowiedź jest taka że nie ma komu ich robić. Albo o nich nie słyszałeś. Albo kryteria masz za wysokie.
24.03 18:21
[#104]
Re: Gry na Amigę. Dołącz!
@asman, post #95
Co do sampli, to nigdy nie kombinowałem z nimi zbytnio. Nie rozumiem tylko, jak można zmienić częstotliwość sampli z 22kHz na 11kHz, skoro wtedy będzie inna wysokość dźwięku. Ja konwertując dźwięki z wav na 8svx zawsze konwertuję do częstotliwości 16574 mono 8bit. Wtedy mam prawidłową wysokość dźwięku przy odgrywaniu. Pewnie można jakoś obniżyć częstotliwość i odegrać z ustawieniem innego perioda. Kwestia kombinowania i odpowiedniego doboru.
Jeśli chodzi o grafiki, to nigdy nie używałem rawblitu, chociaż napisałem sobie ich obsługę i wyświetlanie w Blitz Basic.
X Flip użyłem w Tonym na grafikach nietoperzy i tych obracających się węży. Nie było aż tak wolne, ale to tylko 16x16 pikseli w 2 bitplanach. Wersja kolorowa w sumie też sobie dobrze z tym radzi na 4 bitplanach. Y Flip na pewno da się blitować sprzętowo. Pewnie to tylko kwestia ustawienia pointera grafiki i maski na ostatnią linię i ustawienie ujemnego BLTxMOD dla źródła i maski. Co do bobów z dodatkowym słowem, to Blitz Basic właśnie przechowuje bez niego, a blitowanie odbywa się z użyciem tych dwóch rejestrów BLTAFWM i BLTALWM.
Ze sztuczek, to raczej wszystko zależy od danej gry. Ja przykładowo piszę silnik teraz do zupełnie innego rodzaju gry. Mam tam dual playfield i strasznie nakombinowaną copperlistę, ale to akurat nie ma znaczenia. Silnik działa w dual playfieldzie i na przednim planie mamy niekiedy 2 duże boby (71x51 pikseli). Straciło płynność oczywiście, bo tam jest też bardzo dużo obliczania, ale odzyskałem ją, gdy grafiki bobów zmieniłem z 3-bitplanowych na 2-bitplanowe, ponieważ one i tak są tylko w 3 kolorach. Nie tyle pamięciowo zyskałem, co szybkościowo, a to w tym typie gry bardzo się liczy
@teh_KaiN: moim zdaniem już nigdy nie wyjdzie "dobra" gra na Amigę. Dlaczego? Bo w naszym wieku szybko zapominamy to, co się dzisiaj urodzi. Pamiętamy natomiast bardzo dobrze gry z czasów naszego dzieciństwa/młodości kiedy to człowiek łykał wszystko jak pelikan. Ty robisz świetne gry, znasz bardzo dobrze sprzęt, umiesz programować, tylko jedno 'ale' - zbyt mało ich, chociaż rozumiem że postawiłeś na jakość a nie na ilość, no i pewnie z czasem wolnym też jest jak jest
Ostatnia aktualizacja: 24.03.2026 18:27:41 przez tukinem
Jeśli chodzi o grafiki, to nigdy nie używałem rawblitu, chociaż napisałem sobie ich obsługę i wyświetlanie w Blitz Basic.
X Flip użyłem w Tonym na grafikach nietoperzy i tych obracających się węży. Nie było aż tak wolne, ale to tylko 16x16 pikseli w 2 bitplanach. Wersja kolorowa w sumie też sobie dobrze z tym radzi na 4 bitplanach. Y Flip na pewno da się blitować sprzętowo. Pewnie to tylko kwestia ustawienia pointera grafiki i maski na ostatnią linię i ustawienie ujemnego BLTxMOD dla źródła i maski. Co do bobów z dodatkowym słowem, to Blitz Basic właśnie przechowuje bez niego, a blitowanie odbywa się z użyciem tych dwóch rejestrów BLTAFWM i BLTALWM.
Ze sztuczek, to raczej wszystko zależy od danej gry. Ja przykładowo piszę silnik teraz do zupełnie innego rodzaju gry. Mam tam dual playfield i strasznie nakombinowaną copperlistę, ale to akurat nie ma znaczenia. Silnik działa w dual playfieldzie i na przednim planie mamy niekiedy 2 duże boby (71x51 pikseli). Straciło płynność oczywiście, bo tam jest też bardzo dużo obliczania, ale odzyskałem ją, gdy grafiki bobów zmieniłem z 3-bitplanowych na 2-bitplanowe, ponieważ one i tak są tylko w 3 kolorach. Nie tyle pamięciowo zyskałem, co szybkościowo, a to w tym typie gry bardzo się liczy
@teh_KaiN: moim zdaniem już nigdy nie wyjdzie "dobra" gra na Amigę. Dlaczego? Bo w naszym wieku szybko zapominamy to, co się dzisiaj urodzi. Pamiętamy natomiast bardzo dobrze gry z czasów naszego dzieciństwa/młodości kiedy to człowiek łykał wszystko jak pelikan. Ty robisz świetne gry, znasz bardzo dobrze sprzęt, umiesz programować, tylko jedno 'ale' - zbyt mało ich, chociaż rozumiem że postawiłeś na jakość a nie na ilość, no i pewnie z czasem wolnym też jest jak jest
Ostatnia aktualizacja: 24.03.2026 18:27:41 przez tukinem
24.03 18:53
[#105]
Re: Gry na Amigę. Dołącz!
@tukinem, post #104
Gdzies na PPA juz taka prosta metode opisalem, ze 2 razy kiedys.
Dla sampla 22kHz dodajesz 2 kolejne bajty (rozszerzone do slowa ext.w) i dzielisz przez 2 (przesuniecie o 1 bit).
A period odtwarzania mnozysz x2, czyli dodajesz ten sam period do starego perioda
Wtedy masz perfekcyjny sampel 11kHz, ktory zajmuje o polowe mniej miejsca w pamieci Amigi.
Oczywiscie zrodlowy sampel wcale nie musi byc 22kHz, moze byc o dowolnej czestotliwosci,
po prostu 2 bajty zrodlowe sa konwertowane w 1 bajt docelowy.
Wiec w inicie cos takiego da sie zrobic dosc prosto.
Sprobuj na jakims dluzszym samplu z muzyka np 500KB, i skonwertuj do 250KB.
Dla sampla 22kHz dodajesz 2 kolejne bajty (rozszerzone do slowa ext.w) i dzielisz przez 2 (przesuniecie o 1 bit).
A period odtwarzania mnozysz x2, czyli dodajesz ten sam period do starego perioda
Wtedy masz perfekcyjny sampel 11kHz, ktory zajmuje o polowe mniej miejsca w pamieci Amigi.
Oczywiscie zrodlowy sampel wcale nie musi byc 22kHz, moze byc o dowolnej czestotliwosci,
po prostu 2 bajty zrodlowe sa konwertowane w 1 bajt docelowy.
Wiec w inicie cos takiego da sie zrobic dosc prosto.
Sprobuj na jakims dluzszym samplu z muzyka np 500KB, i skonwertuj do 250KB.
24.03 20:54
[#106]
Re: Gry na Amigę. Dołącz!
@Don_Adan, post #105
Akurat przy ładowaniu sampla BB sam ustawia mu period, jeśli ładujemy go funkcją LoadSound i wtedy period w strukturze dźwięku trzeba zaktualizować. Jeśli używamy zwykłego ładowania przez BLoad, to wtedy trzeba już zawsze ręcznie podać period, jeśli chcemy odtworzyć dźwięk.
Ciekawe czy zrobi różnicę odtwarzanie sampla między PAL a NTSC. Każdy z nich ma lekko inną częstotliwość próbkowania.
Ciekawe czy zrobi różnicę odtwarzanie sampla między PAL a NTSC. Każdy z nich ma lekko inną częstotliwość próbkowania.
24.03 21:43
[#107]
Re: Gry na Amigę. Dołącz!
@tukinem, post #106
Ja opisuje tylko przypadek dla sampla RAW, gdzie samemu podajesz period, i mozesz go ustawic na taki jaki chcesz.
Jesli chodzi o PAL i NTSC to odtwarzanie sampla z takim samym periodem jest w zasadzie niezauwazalne dla przecietnego uzytkownika Amigi, choc im dluzszy jest odgrywany sampel tym latwiej wychwycic roznice po jego czasie odtwarzania.
Byc moze jak ktos ma bardzo dobry sluch to moze to zauwazyc.
A do testow sluchu to wystarczy odegrac jakis MOD na Amidze NTSC.
Ja tam nigdy nie bylem w stanie zauwazyc roznicy, choc bodaj byly nawet jakies specjalne wersje trackerow, ktore mialy tabele okresow NTSC a nie PAL.
Jesli chodzi o PAL i NTSC to odtwarzanie sampla z takim samym periodem jest w zasadzie niezauwazalne dla przecietnego uzytkownika Amigi, choc im dluzszy jest odgrywany sampel tym latwiej wychwycic roznice po jego czasie odtwarzania.
Byc moze jak ktos ma bardzo dobry sluch to moze to zauwazyc.
A do testow sluchu to wystarczy odegrac jakis MOD na Amidze NTSC.
Ja tam nigdy nie bylem w stanie zauwazyc roznicy, choc bodaj byly nawet jakies specjalne wersje trackerow, ktore mialy tabele okresow NTSC a nie PAL.
24.03 23:20
[#108]
Re: Gry na Amigę. Dołącz!
@Don_Adan, post #107
Trzeba też jasno powiedzieć że wykorzystać prawie całe 512KB to też wyczyn.
Natomiast 512 kB slow RAM to bardzo dużo.
Szok i niedowierzanie. Dwóch programistów asemblera dochodzi do wniosku, że 512kB pamięci to całkiem duża ilość
.W sumie niezły artek mógłby z tego powstać, bo jest sporo tricków. Tylko pytanie czy ktoś by to czytał?
Oczywiście że tak. Jeśli pojawiłyby się również działające przykłady w asemblerze, które pokazywałyby różnice optymalizacyjne a kod można byłoby odpalić na dowolnej Amidze, to byłoby super
. 25.03 02:59
[#109]
Re: Gry na Amigę. Dołącz!
@Takuro, post #108
Bo to jest duzo, o ile nie zapycha sie pamieci kazdym bajtem niepotrzebnego lub slabego kodu oraz nie wczytuje sie wszystkich danych graficznych i dzwiekowych na raz do pamieci.
Taki Turrican 3 wymaga tylko 0,5 MB chip, a ma i muzyke i SFX.
Tylko, ze kiedys to byly wymagania wydawnicze, a teraz to jest "wolna amerykanka" .
Jedynie dema na A500 trzymaja poziom i nieliczne gry.
Taki Turrican 3 wymaga tylko 0,5 MB chip, a ma i muzyke i SFX.
Tylko, ze kiedys to byly wymagania wydawnicze, a teraz to jest "wolna amerykanka" .
Jedynie dema na A500 trzymaja poziom i nieliczne gry.