24.03.2015 02:08
[#67]
Re: AMOS w sprawnych dłoniach
@pong777, post #65
Na sprajtach chyba nie bardzo, bo bedzie potrzeba od 5 do 50 obiektow a sprajtow ma max. 8, wiec lepiej uzyc bobow, z tym ze jak najmniejszych (przy wycinaniu bobow nalezy pamietac, zeby wycinac je z ekranu o takiej samej liczbie kolorow jak liczba kolorow w ekranie na ktorym beda wyswietlane, czyli jak gra bedzie korzystac z ekranu 16 kolorow, to boby powinny byc wyciete z ekranu 16 kolorowego).
27.03.2015 00:07
[#70]
Re: AMOS w sprawnych dłoniach
@odyseja_lkc, post #49
Jeszcze a propo prędkości, w "Brain Degenerator #6" jest artek o pewnym rozszerzeniu do AMOSa o nazwie "CRAFT II", przyśpieszającym polecenia graficzne i dodającym całkiem nowe.
W BD6 jest zaznaczone że wg autora rozszerzenia, przyśpieszenie wynosi od 1.5x do 6x :)
Jakaś okrojona wersja umieszczona była na CoverDisc #88 CU AMIGA.
W BD6 jest zaznaczone że wg autora rozszerzenia, przyśpieszenie wynosi od 1.5x do 6x :)
Jakaś okrojona wersja umieszczona była na CoverDisc #88 CU AMIGA.
27.03.2015 17:21
[#71]
Re: AMOS w sprawnych dłoniach
@mastaszek, post #1
Screen Open 0,320,256,4,Lowres Erase All Palette $0,$0,$F00,$F00,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$FFF,$F00 Curs Off Hide Bar 0,0 To 15,15 Get Sprite 1,0,0 To 16,16 Cls 0 For I=0 To 240 Sprite 1,I+128,I+42,1 Rem Wait Vbl Next I Wait Key
Powyżej program w AMOSie o którym wspominałem wcześniej. Można sobie wpisać i odpalić.
Proszę o zrobienie odpowiedników w Assemblerze/C/E/C++/Pascalu/Blitz Basicu/M$ Basicu etc. Porównamy ile kodu więcej trzeba będzie napisać oraz czy kwadracik będzie szybciej na samym dole.
Aby zsynchronizować z monitorem można usunąć słowo "REM". Wtedy powinno być idealnie 50 FPS ale za to szybkość animacji nie powinna być większa na lepszych konfiguracjach sprzętowych.
Ostatnia aktualizacja: 27.03.2015 17:24:35 przez pong777
27.03.2015 23:10
[#72]
Re: AMOS w sprawnych dłoniach
@pong777, post #71
Przykład w asemblerze.
Zamieściłem za pomocą pastebin, z tego co się zorientowałem to będzie leżało tam jeszcze 29 dni.
SetSprite.s
Można sobie przekopiować i skompilować za pomocą Asm-One. Nie testowałem na OCS/ECS i na pewno dla takich maszyn należy usunąć jedną linię w copperliście. Kod wynikowy to 648 bajtów (trochę zjadła tablica relokacji, można by cały kod umieścić w CHIP wtedy zająłby mniej). Przykład nie przejmuje całkowicie systemu, nie ubijane są przerwanie, multitasking wciąż działa, blitter nie został przejęty.
Odkomentowanie bloku kodu za lokalną etykietą .loop pozwoli cieszyć oko dłużej (synchronizacja z ramką).
Przejdźmy do minusów:
- kod ciężko utrzymać i rozwijać
- łatwo o błąd
- napisanie go zajmuje sporo czasu w porównaniu do Amosa na przykład, mnie zajęło to ze dwie godziny i to posiłkując się podobnymi rzeczami, które to mam na dysku.
A plusy:
- jest szybko
- kod wynikowy jest krótki
Przykładzik Amosowy skompilował mnie się do 9kb a ze squash do 7kb z kawałem.
Zamieściłem za pomocą pastebin, z tego co się zorientowałem to będzie leżało tam jeszcze 29 dni.
SetSprite.s
Można sobie przekopiować i skompilować za pomocą Asm-One. Nie testowałem na OCS/ECS i na pewno dla takich maszyn należy usunąć jedną linię w copperliście. Kod wynikowy to 648 bajtów (trochę zjadła tablica relokacji, można by cały kod umieścić w CHIP wtedy zająłby mniej). Przykład nie przejmuje całkowicie systemu, nie ubijane są przerwanie, multitasking wciąż działa, blitter nie został przejęty.
Odkomentowanie bloku kodu za lokalną etykietą .loop pozwoli cieszyć oko dłużej (synchronizacja z ramką).
Przejdźmy do minusów:
- kod ciężko utrzymać i rozwijać
- łatwo o błąd
- napisanie go zajmuje sporo czasu w porównaniu do Amosa na przykład, mnie zajęło to ze dwie godziny i to posiłkując się podobnymi rzeczami, które to mam na dysku.
A plusy:
- jest szybko
- kod wynikowy jest krótki
Przykładzik Amosowy skompilował mnie się do 9kb a ze squash do 7kb z kawałem.
28.03.2015 01:07
[#73]
Re: AMOS w sprawnych dłoniach
@asman, post #72
Witaj!
Zainspirowany Twoją pracą postanowiłem napisać taki przykład w języku C. Również wrzuciłem na pastebin.com:
SpriteTest.c
Mój przykład korzysta z systemowych funkcji do alokacji duszka oraz korzysta z przerwania wygaszania pionowego celem synchronizacji animacji. Animacja duszka jest płynna i bezproblemowa, zresztą zobaczcie sami - skompilujcie kod. Ja korzystałem z kompilatora DICE.
Generalnie mój przykład pokazuje jak można zrobić to w wielozadaniowości i systemowo w C bez choćby najmniejszej straty prędkości działania. Można suwać ekrany, ruszać myszą, a duszek ani na chwilę nie przystanie. Priorytet mojej obsługi wygaszania pionowego ustawiłem na 20, co zupełnie wystarczy.
Pozdrawiam.
Zainspirowany Twoją pracą postanowiłem napisać taki przykład w języku C. Również wrzuciłem na pastebin.com:
SpriteTest.c
Mój przykład korzysta z systemowych funkcji do alokacji duszka oraz korzysta z przerwania wygaszania pionowego celem synchronizacji animacji. Animacja duszka jest płynna i bezproblemowa, zresztą zobaczcie sami - skompilujcie kod. Ja korzystałem z kompilatora DICE.
Generalnie mój przykład pokazuje jak można zrobić to w wielozadaniowości i systemowo w C bez choćby najmniejszej straty prędkości działania. Można suwać ekrany, ruszać myszą, a duszek ani na chwilę nie przystanie. Priorytet mojej obsługi wygaszania pionowego ustawiłem na 20, co zupełnie wystarczy.
Pozdrawiam.
28.03.2015 12:50
[#74]
Re: AMOS w sprawnych dłoniach
@Hexmage960, post #73
W tym przypadku pewnie kod w C będzie najwolniejszy (czytelny) przy korzystaniu z systemowych funkcji, czy Amos korzysta z systemowych funkcji?
Czy DICE produkuje lepszy kod niż VBCC?
Powinieneś stworzyć parametr, który wyłącza synchronizację i przesuwa duszka jak najszybciej potrafi. Jak widać w kodzie AMOSA, tam jest wstawione zwykłe oczekiwanie na VBLANK, więc jak już pokazałeś jak to się robi w elegancki sposób, zrób tak jak się robi w AMOSIE, czyli oczekiwanie na VBLANK po wyświetleniu duszka lub bez oczekiwania po zakomentowaniu jednej linijki lub podaniu parametru. To jest test na szybkość, a nie na systemowość.
Musze cię pochwalić jako laik, że twój kod jest dość czytelny, a przynajmniej bardziej mi pasuje niż basic Amosa, mimo, że tam składnia jest prostsza.
Ostatnia aktualizacja: 28.03.2015 13:04:26 przez sanjyuubi
Czy DICE produkuje lepszy kod niż VBCC?
Powinieneś stworzyć parametr, który wyłącza synchronizację i przesuwa duszka jak najszybciej potrafi. Jak widać w kodzie AMOSA, tam jest wstawione zwykłe oczekiwanie na VBLANK, więc jak już pokazałeś jak to się robi w elegancki sposób, zrób tak jak się robi w AMOSIE, czyli oczekiwanie na VBLANK po wyświetleniu duszka lub bez oczekiwania po zakomentowaniu jednej linijki lub podaniu parametru. To jest test na szybkość, a nie na systemowość.
Musze cię pochwalić jako laik, że twój kod jest dość czytelny, a przynajmniej bardziej mi pasuje niż basic Amosa, mimo, że tam składnia jest prostsza.
Ostatnia aktualizacja: 28.03.2015 13:04:26 przez sanjyuubi
28.03.2015 13:49
[#75]
Re: AMOS w sprawnych dłoniach
@pong777, post #71
Jeśli ktoś nie ma AMOSa lub czasu zamieszczam 4 pliki wykonywalne gotowe do odpalenia na dowolnej Amidze -
GraphAmosTest
GraphAmosTest.info - ikonka
oraz wersję z synchronizacją monitora
GraphAmosTestSync
GraphAmosTestSync.info - ikonka
A dla całkowicie leniwych - Youtube
HyperCam niestety średnio płynnie obraz przechwycił...
Ostatnia aktualizacja: 28.03.2015 13:59:49 przez pong777
GraphAmosTest
GraphAmosTest.info - ikonka
oraz wersję z synchronizacją monitora
GraphAmosTestSync
GraphAmosTestSync.info - ikonka
A dla całkowicie leniwych - Youtube
HyperCam niestety średnio płynnie obraz przechwycił...
Ostatnia aktualizacja: 28.03.2015 13:59:49 przez pong777
28.03.2015 19:42
[#76]
Re: AMOS w sprawnych dłoniach
@sanjyuubi, post #74
W tym przypadku pewnie kod w C będzie najwolniejszy (czytelny) przy korzystaniu z systemowych funkcji, czy Amos korzysta z systemowych funkcji?
AMOS wyświetla sprajty i inne elementy na pewno sprzętowo (pomijam, że AMOS ma możliwość wywoływania funkcji bibliotecznych).
Czy DICE produkuje lepszy kod niż VBCC?
Prawdopodobnie VBCC produkuje lepszy kod, ale DICE szybciej kompiluje.
Powinieneś stworzyć parametr, który wyłącza synchronizację i przesuwa duszka jak najszybciej potrafi. Jak widać w kodzie AMOSA, tam jest wstawione zwykłe oczekiwanie na VBLANK, więc jak już pokazałeś jak to się robi w elegancki sposób, zrób tak jak się robi w AMOSIE, czyli oczekiwanie na VBLANK po wyświetleniu duszka lub bez oczekiwania po zakomentowaniu jednej linijki lub podaniu parametru. To jest test na szybkość, a nie na systemowość.
Można to zrobić (wyjąć procedurę ruchu sprajta z przerwania), ale tzw. "busy loop" nie jest najlepszym rozwiązaniem w przypadku programu, który ma działać w wielozadaniowości, nawet jak pętla trwa krótko.
Generalnie procedury graphics.library dot. duszków w C mogą być wolniejsze na dłuższą metę w stosunku do AMOSa, bądź własnej copperlisty. Ale są przyjazne systemowo, można je wyświetlić na systemowym ekranie, nie ma kolizji z innymi programami korzystającymi z duszków itp.
System Amigi ma parę wad odnośnie graphics.library i prędkości rysowania, ale rekompensuje to całkowicie elastyczność tego systemu i ogromne możliwości rozbudowy, jakie zostawili w tym systemie jego autorzy.
28.03.2015 20:35
[#77]
Re: AMOS w sprawnych dłoniach
@pong777, post #71
Kod w BlitzBasic2:
; AMOS vs BlitzBasic2 sprite test #1
VWait 100 ; !?
BLITZ ; blitz mode ON
Slice 0,44,320,256,$fff8,2,8,32,320,320
Use Slice 0
BitMap 0,320,256,2
Use BitMap 0
Show 0
Boxf 0,0,16,16,2
GetaShape 0,0,0,16,16
GetaSprite 0,0
RGB 18,15,0,0 ; kolor dla sprite'a
Cls 0
For i=0 To 240
ShowSprite 0,0+i,0+i,0
VWait ; mozna skasowac...
Next
MouseWait
Free BitMap 0
FreeSlices
AMIGA ; blitz mode OFF
End 
29.03.2015 17:33
[#82]
Re: AMOS w sprawnych dłoniach
@selur, post #78
Ogarniasz dobrze BlitzBasic 2?
Program zaproponowany przez @pong777 jest na tyle prosty że napisałem go bez żadnej znajomości Blitza...
Następny będzie w AmigaBASIC o ile ktoś mnie nie uprzedzi :)
Moglbys poprowadzic jakis kurs w artykule lub np. w dziale prywatnym.
Kursów programowania jest mnóstwo, po co kolejny? ;)
29.03.2015 17:43
[#83]
Re: AMOS w sprawnych dłoniach
@forge, post #82
No akurat nie do amigowego Blitza, to nie AMOS gdzie walaja sie tony materialow.
Cudem jest w ogole fakt, ze ktos napisal do niego angielska instrukcje. Kilka lat temu bylem pierwsza osoba, ktora zapytala o angielskie tlumaczenie manuala na forum blitza i okazalo sie, ze nikt nie wiedzial o takim tlumaczeniu, do czasu kiedy sam autor tlumaczenia sie nie zglosil. Ale ogolnie ta instrukcja jest kiepska sama w sobie. Ciezko zrozumiec obsluge obiektow i ekranow a o jakichs zaawansowanych metodach wykorzystywania grafiki juz nie wspomne. Kazda wiedza na temat BB jest na wage zlota.
p.s.
Jak potrafisz pisac programy nie znajac skladni i funkcji to powinienes zapisac sie do polskiego "Mam Talent"
Cudem jest w ogole fakt, ze ktos napisal do niego angielska instrukcje. Kilka lat temu bylem pierwsza osoba, ktora zapytala o angielskie tlumaczenie manuala na forum blitza i okazalo sie, ze nikt nie wiedzial o takim tlumaczeniu, do czasu kiedy sam autor tlumaczenia sie nie zglosil. Ale ogolnie ta instrukcja jest kiepska sama w sobie. Ciezko zrozumiec obsluge obiektow i ekranow a o jakichs zaawansowanych metodach wykorzystywania grafiki juz nie wspomne. Kazda wiedza na temat BB jest na wage zlota.
p.s.
Jak potrafisz pisac programy nie znajac skladni i funkcji to powinienes zapisac sie do polskiego "Mam Talent"
30.03.2015 20:32
[#87]
Re: AMOS w sprawnych dłoniach
@selur, post #86
A moze po prostu amos + asembler? Wiem, purystom asemblerowym takie coś nie przejdzie nawet przez myśl ale amos jako coś w rodzaju język skryptowy lub "glue code" jest idealny. Nie trzeba męczyć się z klepaniem wszystkiego co nie wymaga prędkości (wczytywanie danych, otwieranie ekranów, obsługa myszy/klawiatury/joysticka, dźwięki, logika gry) w asemblerze a wywołanie asemblerowego kodu z amosa jest banalne. Tak więc to co tutaj widać równie dobrze może być uruchomione na a500 lub czymś innym podobnie wolnym.
30.03.2015 20:59
[#88]
Re: AMOS w sprawnych dłoniach
@kiero, post #87
To jest dobry pomysl i ktos juz tak wczesniej zrobil. Tak ponoc zostala napisana jedna z lepszych gier w Amosie Genesia ale trudno powiedziec co bylo AMOSem a co wstawkami asemblera (brak kodow zrodlowych niestety wiec sie nie dowiemy) ale warto nad tym pomyslec.
Jak na gola A500, to ten pseudo "Doom" dosc szybko chodzi.
Jak na gola A500, to ten pseudo "Doom" dosc szybko chodzi.
01.04.2015 01:12
[#89]
Re: AMOS w sprawnych dłoniach
@kiero, post #87
Pokazaliście mi, że amos nie wydaje się w sumie taki lamerski i można zlepić w nim coś lepszego niż w bekbounie (z którego głownie gnioty wychodzą). Obecnie amos wciągnął mnie totalnie i pełen natchnienia spowodowanego pokazanymi przykładami, zasiadam do pisania quake'a na a500 ocs. To będzie hit. Potrzebuję tylko machinę czasu, by tę grę sprzedać w 1992.
Dzięki wszystkim za odzew, kłaniam się i do zobaczenia na jakim party!
mastaszek
Dzięki wszystkim za odzew, kłaniam się i do zobaczenia na jakim party!
mastaszek
01.04.2015 01:29
[#90]
Re: AMOS w sprawnych dłoniach
@mastaszek, post #89
Jeszcze raz podlinkuję tytuł na YT Wonderland platformowej gry zrobionej w Amosie wykorzystującej scroll, sprite, boby, dźwięk.