Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorKaz
   • CommentTime9 Sep 2021 11:09 zmieniony

    
   Demo gry naszego kolegi K.K., pokazywane na tegorocznym Silly Venture. Tu grane na prawdziwym sprzęcie i komentarz wideoblogera:
   
   

   TPau65:

   Running the demo version 1905 of the new shooter "DREAD" on my Atari 1040 STE with 4MB. Of course not that fast than on the Falcon 030, but without it's bugs. ;-) Ok, I had several crashes on my STE, too. But not that many than on the Falcon!

   
   
   
2. • 2:
      
     CommentAuthorDracon
   • CommentTime9 Sep 2021 11:09

    
   Fajne, robi wrażenie ale żeby nie skończyło się jak inna gra KK dla A8 (samo demo i tyle).
3. • 3: CommentAuthorurborg
   • CommentTime9 Sep 2021 12:09 zmieniony

    
   To nie shooter tylko FPS. Spodziewałem się coś w stylu R-type a tu mamy coś pomiędzy Doomem a Wolfensteinem. Poziomy są nieco bardziej rozbudowane niż w Wolfensteinie nie ma się aż tak bardzo wrażenia klockowatości pomieszczeń, choć oczywiście dużo prostsze niż w Doomie. Ładnie to działa. Co prawda to dopiero demo więc pewnie wiele się jeszcze zmieni, ale w demie razi to że przeciwnicy są typu "bullet sponge" chyba trzeba ich ze 7 czy 8 razy trafić zanim padną. Niemniej dobrze to wygląda i rokuje. Gratulacje
   
   A tak z innej beczki wersja 1905? To jest liczone od 1 czy może od 2000 ale w dół? Czy może jeszcze jakąś inną metodą?
4. • 4:
      
     CommentAuthorjhusak
   • CommentTime9 Sep 2021 12:09

    
   O genialności programisty niech świadczy fakt, że w latach 90 Tomek Grygo bawił się tymi algorytmami robiąc swojego Wolfenstaina 3D na PC AT 286 12MHz, z kartą VGA czyli 1 bajt na pixel. W asemblerze. I to mu "śmigało" jakieś 3-6 fps bez żadnych tekstur jeszcze i bez przeciwników. A tu mamy prawie 2 x wolniejszy procesor, a gra jest niemal gotowa - tzn jeden level (z tego co pamiętam). Ponadto do tej pory to A1200 miała zaledwie Glooma, który był grywalny zaledwie i to na małym ekraniku. Sam kiedyś w Dooma grałem na 386/25 MHz i niestety, ale to na rozdzielczości 320x240 nie dało się grać za bardzo.
   
   A tu masz proszę bardzo - ca 20 FPS, a pewnie więcej na Amidze. To jest kilkunastokrotny przyrost prędkości do tego co było. To jest WIELKIE, co KK zrobił w ostatnie 2 lata od pamiętnego dema, które pokazywało silnik dla wolfa3d.
   
   Nie przenośmy też dzisiejszych realiów na stare komputery. One nie dawały rady obsłużyć tabuna przeciwników, więc aby było szybko, to jest ich 4-5 na pokój i strzelaj do nich, aż zabijesz. Oni są "na sterydach", jak kiedyś nasi wojownicy, którzy jak jeże ponabijani strzałami jeszcze wroga siekli póki nie padli:).
5. • 5: CommentAuthorPecet
   • CommentTime9 Sep 2021 12:09

    
   Gloom ma jednak teksturowane sufity i podłogi. To 'trochę' zmienia postać rzeczy.
   Swoją drogą to ciekawe, że na amidze jest szybciej. Do tej pory np. wszelkie klony wolfa były szybsze na atarynach.
6. • 6: CommentAuthordhor
   • CommentTime9 Sep 2021 12:09

    
   No właśnie dziwne... Ste nie dotrzymuje kroku Amidze? Nawet render dłoni jest totalnie okrojony na STE (st?).
   
   Anyway, to kapitalna rzecz widzieć takie rzeczy na sprzęcie, który zanikł w pomroce dziejów z racji tego, że PC potrafiły Wolfsteina...
7. • 7:
      
     CommentAuthorPeri Noid
   • CommentTime9 Sep 2021 12:09

    
   Dłoń jest uproszczona bo na Ami jest na sprite'ach a na ST jest malowana.
8. • 8: CommentAuthorPecet
   • CommentTime9 Sep 2021 13:09

    
   "Anyway, to kapitalna rzecz widzieć takie rzeczy na sprzęcie, który zanikł w pomroce dziejów z racji tego, że PC potrafiły Wolfsteina..."
   
   A jednocześnie trochę smutne, skoro jednak się dało. Pytanie, czy na dłuższą metę, to by cokolwiek zmieniło.
9. • 9:
      
     CommentAuthorCyprian
   • CommentTime9 Sep 2021 13:09 zmieniony

    

   dhor:

   No właśnie dziwne... Ste nie dotrzymuje kroku Amidze? Nawet render dłoni jest totalnie okrojony na STE (st?).

   
   KK - autor gry jest amigowcem, dla którego jest to pierwszy kontakt z ST. Tak więc, siłą rzeczy gra jest zoptymalizowana (i to nieźle) pod Amigę i jeszcze nie wykorzystuje możliwości ST czy STe.
   
   Gra jest w wersji beta, więc wszystko się może zmienić.
10. • 10:
       
      CommentAuthorhospes
    • CommentTime9 Sep 2021 14:09

     
    Rozmawiałem z KK na zlocie, bezpośrednio po prezentacji gry. Z tego co mówił wywnioskowałem, że to chyba wczesny kod gry przystosowany do bardziej do ST. Obsługa blittera na bardzo wczesnym prostym poziomie, czyli wolno ;)
    Czekam na paczki kodu blittera, który jest wykorzystywany w AGT.
    Walczę też, żeby w intrze była jednak muzyka na module :D
11. • 11:
       
      CommentAuthorCyprian
    • CommentTime9 Sep 2021 14:09

     
    @hospes czy dobrze rozumiem że wspomagasz KK w wersji dla ST?
12. • 12:
       
      CommentAuthorKaz
    • CommentTime9 Sep 2021 14:09

     
    O, właśnie miałem napisać, że rozmawiałem z KK na zlocie, żeby pojawił się u nas na zoomie i opowiedział trochę o technikaliach gry. Ma być :)
    
    A Hospesa namawiałem, żeby ewangelizował KK w zakresie najnowszych technik obsługi blittera i możliwości STE - jest pomysł, żeby zrobić tu wątek z materiałami zawierającymi ciekawe procedury właśnie wykorzystujące potencjał STE.
13. • 13:
       
      CommentAuthorjhusak
    • CommentTime9 Sep 2021 14:09

     
    Z tego co wiem blitter jest używany przy konwersji chunky to planar, a że blitter na Amidze działa ROWNOLEGLE z procesorem (przynajmniej w tej grze, zależne jest to od ilości kolorów i rozdzielczości) a na STE WYŁĄCZNIE (tzn cpu albo blitter) to już wiadomo, że tu będzie cienko. Poza tym sprajty rzeczywiście robią robotę, bo dłoni z bronią nie trzeba dorysowywać.
14. • 14:
       
      CommentAuthorCyprian
    • CommentTime9 Sep 2021 15:09 zmieniony

     
    @jhusak
    
    i tak i nie :)
    
    BLiTTER w ST również może działać równolegle z procesorem ale w specyficznych warunkach. Po moich uwagach zostało to zaimplementowane w emulatorach STeem / Hatari
    
    
    Generalnie blitter w Atari jest szybszy. Kopiowanie / wypełnianie / kasowanie - 4MB/s przy włączonym ekranie, gdy w Amidze kopiowanie 3.5MB/s, kasowanie połowę tej wartości i to przy wyłączonym ekranie i procesorze w przypadku kopiowania.
    Przewagą blittera w Amidze jest elastyczność źródeł danych - 3 źródła danych w pamięci (sprajt, tło i maska) - czyli funkcja pod sprajty.
    W Atari na trzy źródła danych pierwsze jest w pamięci RAM, drugie w pamięci podręcznej BLiTTERa (32 bajty), trzecie w RAM ale sklejone z celem. Oczywiście w Amidze jeszcze jest fajna opcja rysowania linii i wypełnianie ekranu (typu flip-flop).
    
    
    Główna różnica jest w koncepcji która przyświecała autorom. W Amidze - podejście konsolowe - dopalenie sprajtów. W Atari sprzętowa realizacja funkcji systemu operacyjnego - "Line A".
    
    Każda z tych koncepcji nich ma swoje zalety, kwestia jest taka by w inteligenty sposób użyć mocnych stron danego blittera.
15. • 15:
       
      CommentAuthorjhusak
    • CommentTime9 Sep 2021 15:09

     
    Czy cpu + blitter jest szybszy w ami czy może w ste? Przy 16 kolorach 320x240? Pytam, bo mam sprzeczne informacje.
16. • 16: CommentAuthorPecet
    • CommentTime9 Sep 2021 16:09

     
    Atari nie ma trybu chunky? Potrzebuje konwersji tak jak Amiga?
17. • 17:
       
      CommentAuthorjhusak
    • CommentTime9 Sep 2021 16:09

     
    Amiga ma bitplany jeden po drugim (albo interleaved - zmieniane co linia, co pozwala jedną operacją blittera skopiować prostokąt ektanu) a ST ma bajt pierwszego, bajt drugiego, bajt trzeciego i bajt czwartego. Dlatego ST ma stałą pamięć 32 kB, a Amiga dowolną.
18. • 18:
       
      CommentAuthorCyprian
    • CommentTime9 Sep 2021 17:09 zmieniony

     

    Pecet:

    Atari nie ma trybu chunky? Potrzebuje konwersji tak jak Amiga?

    
    Atari Falcon/Jaguar/Lynx/7800 i XL/XE mają chunky.
    Atari ST/TT mają przeplatane bitplany - np.: dwa bajty (słowo) pierwszy bitplan, dwa bajty drugi, dwa trzeci, dwa czwarty i od początku.
    
    Zaletą przeplatanych bitplanów było to że C2P na Atari (sam CPU) było szybsze niż na Amidze (CPU plus blitter).
    
    

    jhusak:

    Dlatego ST ma stałą pamięć 32 kB, a Amiga dowolną.

    
    to zależy, domyślnie 32kB ale po otwarciu wszystkich ramek może być np. 57kB
    
    
    

    jhusak:

    Czy cpu + blitter jest szybszy w ami czy może w ste? Przy 16 kolorach 320x240? Pytam, bo mam sprzeczne informacje.

    
    to zależy w czym.
    
    W ST niezależnie od ilości kolorów procesor jest zawsze szybszy. Blitter w operacjach kopiowania, wypełniania i czyszczenia również jest szybszy.
    Ale za to w operacjach na duszkach czyli "Cookie Cut" blitter Amigi jest szybszy, bo tak jak wspomniałem ma trzy źródła w pamięci RAM (kanały A B C). Więc duszki robi w jednym przebiegu (4 cykle na słowo) a Atari w dwóch (6 cykli na słowo).
    
    Aczkolwiek Anima (ten od Daimakaimura/Ghouls 'N Ghosts i Cho Ren Sha 68k Atari ) zrobił procedurę do duszków która prześciga Amigę:
    
    

    
    
    Tutaj przykład tej procedury w grze "Metal Slug"
    
    

    
    
    KK w "Dread" wykorzystał zaletę (trzy źródła w pamięci RAM ) blittera w Amidze do zrobienia szybkiego C2P. W sumie to ciekawy jestem porównania wydajności z innymi C2P z Amigi.
19. • 19:
       
      CommentAuthorjhusak
    • CommentTime9 Sep 2021 21:09 zmieniony

     
    Nie chodzi mi o wyścigi, kto zrobi szybciej, tylko o prostą rzecz: ile cykli na ramkę dostaje procek i jednocześnie ile pamięci może przepisać czy skasować blitter przy 16 kolorach i 320x240.
    
    Filmiki fajne, też kibicuję metal slugowi na ST. Ostatnio jak oglądałem demko, były glicze szczególnie na bosie. Ale pewnie już to jest poprawione.
20. • 20:
       
      CommentAuthorCyprian
    • CommentTime9 Sep 2021 21:09

     
    W ST jest tak samo jak w C64 (co za zbieg okoliczności ;) ), dostęp do pamięci jest podzielony na cykle parzyste dla układu graficznego i nieparzyste dla procesora. W ST BLiTTER działa wyłącznie na cyklach procesora (dzięki czemu ma 24bit adresowania i dostęp do całej pamięci plus rejestry sprzętowe). Na jedną ramkę PAL CPU/BLiTTER mają dla siebie 160256 cykli (8MHz), to jest 40064 cykli pamięci. Naraz tylko jeden z nich ma dostęp do szyny danych.
    Z tym że tak jak wspomniałem, jest możliwe w specyficznych warunkach uruchomić równolegle procesor i blitter.
21. • 21:
       
      CommentAuthorCyprian
    • CommentTime10 Sep 2021 14:09 zmieniony

     
    ile pamięci może przepisać czy skasować blitter przy 16 kolorach i 320x240.

    
    
    Kasowanie lub wypełnianie wzorcem z pamięci BLiTTERa - 80kB na ramkę.
    
    Przepisywanie - 40kB na ramkę (czyli 40kB odczyt plus 40kB zapis). W tym czasie 'za darmo' może dokonywać przesuwania bitowego, operacje logiczne/maskowanie względem pamięci BLiTTERa.
22. • 22:
       
      CommentAuthorjhusak
    • CommentTime10 Sep 2021 14:09 zmieniony

     
    Dzięki za odpowiedź.
    Jakie to są specyficzne warunki, kiedy blitter i cpu działają współbieżnie z pełną prędkością?
    
    Amigowy blitter przesyła pewnie trochę wolniej, cpu pracuje trochę wolniej, ale za to ZUPEŁNIE nie ogranicza procesora (przy podanych założeniach), co skutkuje prawie 2 x większą "przepustowością". Czy się mylę?
    
    Tu jest amigowa wersja, też 23 kulki w tej samej konfiguracji.
    
23. • 23:
       
      CommentAuthorPeri Noid
    • CommentTime10 Sep 2021 15:09

     
    Ogranicza o tyle, że współdzielą szynę danych i jak chipset (blitter) pracuje to procek może korzystać co najwyżej z fastu. Aczkolwiek ja tylko teoretyk jestem.
24. • 24:
       
      CommentAuthorjhusak
    • CommentTime10 Sep 2021 21:09 zmieniony

     
    @Peri Noid, tak jest w ST, a w Amidze nie. Pamiętam, jak pisałem grę StarBall na Amigę (niestety szlag ją trafił), to używałem do kopiowania kafelków (podczas animacji) blittera, a po jego uruchomieniu używałem procesora do kopiowania pozostałych. Działało to mniej więcej 2x szybciej. Ale żeby działało, to aktualizowało tylko widoczny fragment planszy oraz animowało co czwartą kolumnę w jednej ramce, czyli jakieś 5 kolumn po 10 kafelków na jedno przerwanie ramki, kafelki 16x16.
    
    Z ciekawostek. JKZ kiedyś odkupił ode mnie amigę 1200, a teraz mi ją odsprzedał z powrotem :) I mam! Moją Amigę z 9x' lat!
25. • 25:
       
      CommentAuthorPeri Noid
    • CommentTime10 Sep 2021 21:09

     
    Ponieważ pamięć jest jednoportowa i taktowana z prędkością CPU, to dostęp musi być dzielony w obu przypadkach. Chodziło mi o to, że w Ami CPU ma dostęp do pamięci "co drugi cykl" bo pozostałe są do dyspozycji chipsetu. A ponieważ operacje CPU zajmują więcej czasu niż 1 cykl to najwyraźniej przeplot jest efektywny.
26. • 26:
       
      CommentAuthorCyprian
    • CommentTime11 Sep 2021 00:09 zmieniony

     

    Peri Noid:

    Ponieważ pamięć jest jednoportowa i taktowana z prędkością CPU

    
    w ST i A500 pamięć "taktowana" jest z połową prędkości CPU ale procesor ma dostęp co 4 cykl. W A1200 z 1/4 prędkości ale procesor ma dostęp co 8 cykl. Czyli z punktu widzenia procesora wszystkie (A3000 i A4000 też) Amigi mają CHIP "taktowany" 1,77MHz.
    
    
    
    

    jhusak:

    Ale żeby działało, to aktualizowało tylko widoczny fragment planszy oraz animowało co czwartą kolumnę w jednej ramce, czyli jakieś 5 kolumn po 10 kafelków na jedno przerwanie ramki, kafelki 16x16.
    

    
    
    Czy dobrze rozumiem że maksymalnie udało się przekopiować się 50 kafelków 16x16 na ramkę? A w ilu bitplanach były te kafelki?
    
    W przypadku ST, na jedną ramkę PAL BLiTTER ma dostępne 40 064 slotów pamięci (każdy slot to 16bitowe słowo). Czyli teoretycznie może na ramkę przekopiować 40kB w jednej ramce.
    Gdzieś czytałem że na ramkę Amiga może kopiuje 35kB w jednej ramce.
    
    
    

    jhusak:

    Jakie to są specyficzne warunki, kiedy blitter i cpu działają współbieżnie z pełną prędkością?

    
    
    Fajną cechą Amigi jest to że blitter i procesor mogą pracować na przemian.
    W ST niestety nie jest to tak elastyczne. Normalnie na raz pracuje albo procesor albo BLiTTER. Z tym że, ze względu na prefetch 68000 można wykonać jedną dodatkową instrukcję zaraz po uruchomieniu BLiTTERa.
    No i teraz sedno tematu - albo uruchamiamy BLiTTER w trybie innym niż HOG (to jest odpowiednik Nasty w Amidze) i wtedy BLiTTER sam co 65 cykli przełacza się na CPU i z powrotem, albo ręcznie wielokrotnie restartujemy BLiTTER (Tak są zrobione sprajty z youtuba który wrzuciłem wcześniej). Każdy restart czy uruchomienie BLiTTERa pozwala nam "wcisnąc" dodatkową instrukcję. Może być to przydatne przy długich instrukcjach typu mnożenie, dzielenie, rotacja bitowa itp.
    
    

    jhusak:

    Amigowy blitter przesyła pewnie trochę wolniej, cpu pracuje trochę wolniej, ale za to ZUPEŁNIE nie ogranicza procesora (przy podanych założeniach), co skutkuje prawie 2 x większą "przepustowością". Czy się mylę?

    
    
    Czysto teoretycznie nie dwa razy ale około 1.7 i tylko gdy wyłączysz wszystkie DMA czyli też ekran. Tylko po co coś blittować gdy ekran jest wyłączony. :)
    W praktyce jest parę czynników ograniczających wydajność, typu cykle refresh/DMA (spriteów/fdd/obrazu), długi pipeline blittera, czy dodatkowe cykle "IDLE" blittera gdy DMA obrazu jest aktywne.
    
    Efekt jest taki jak widać na tych filmach że pomimo większej przepustowości Amigi, i Amiga i ST z BLiTTERem mają podobną wydajność dla sprajtów.
27. • 27:
       
      CommentAuthorPeri Noid
    • CommentTime11 Sep 2021 01:09

     
    Dzięki.
28. • 28:
       
      CommentAuthorjhusak
    • CommentTime11 Sep 2021 07:09 zmieniony

     
    @cyprian, dzięki za wyczerpującą odpowiedź.
    Kafelki były 3 bitplanowe, bo paralaksa. Czyli 48 wordów na kafelek, czyli do 5 KB na ramkę. Kopiowane były tylko elementy animujące się.
    
    W sumie ten artykuł wiele wyjaśnia: ->link<-
    
    W artykule tym autor pisze, że da się przyspieszyć/zrównoleglić na Amidze 1200, ale na Amidze 500 nie (tzn zrównoleglic się da, ale nie będzie szybciej)
    
    Być może w mojej grze robiło robotę to, że po prostu przepisywałem pamięć, a nie robiłem operacji przesuwania czy logicznych. Niestety, nie pamiętam już, czy jakoś to testowałem, chyba nie, bo update wszystkich kafelków mroziło procesor na kilka ramek, a po przesunięciu cykli odświeżania na co czwartą kolumnę już nic się nie zatykało.
    
    Ciekawostką jest to, że na Atari8 nie było z tym żadnych problemów mimo, że pisałem Starball w Action! Robotę tu robi tryb tekstowy.
29. • 29:
       
      CommentAuthorCyprian
    • CommentTime12 Sep 2021 12:09

     

    jhusak:

    Ciekawostką jest to, że na Atari8 nie było z tym żadnych problemów mimo, że pisałem Starball w Action! Robotę tu robi tryb tekstowy.

    
    
    pograłem trochę w StarBall,
    tytułowa muzyka jest świetna, swobodnie by lecieć w czasie rozgrywki.
    sama gra też jest zacna, ciutkę dla mnie za trudna :)
    
    
    Ile czasu zajmuje odświeżenie całej planszy? 1, 2 ramki?
30. • 30:
       
      CommentAuthorjhusak
    • CommentTime13 Sep 2021 15:09 zmieniony

     
    Co ramkę. Operacji tam dużo nie jest. Wszelkie animacje odbywają się na generatorach znaków.
    Gra jest trudna na początku, ale jak się złapie ten dryg, to idzie całą przejść bez utraty życia.
    
    Swoją drogą dziwi mnie to 23 kulki, tam jest 4*32*3=12*32=384 albo 512 (16 kolorów) bajtów na kulkę do przepisania. To by wyglądało, że na Ami blitter może przepisać 23*0.5 kB na ramkę (no, narysować z przesunięciami, nandem i orem), czyli 11.5kB.
31. • 31: CommentAuthorTrachu
    • CommentTime14 Sep 2021 10:09 zmieniony

     
    Witam
    
    Mysle ze warto rozwinac ten temat bo jak widze dalej funkcjonuje mnostwo mitow na ten temat.
    Amiga 500 posiada 312 linii rastra w kazdej mogac wykonac 227,5 cykla dostepu do pamieci. Mnozac to przez siebie wychodzi nam 3.55MHz (w STE tych cykli przychodzacych na linie jest oczywiscie wiecej takze pamiec pracuje na 4MHz), czyli jest dokladnie tak jak Cyprian mowi - pamiec pracuje z polowa czestotliwosci procesora, jednak tutaj tez nalezy sie uwaga.
    Kazdy z tych cykli pamieci moze byc albo odczytem albo zapisem i o dostep do niego konkuruja ze soba chipset z CPU. Kazda jednostka ma swoj priorytet gdzie display ma najwyzszy, a cpu najnizszy.
    Otoz ze swojej natury procesor 68000 moze wykonywac odczyt lub zapis nie szybciej niz co drugi cykl pamieci. Wykorzystano to tworczo w ten sposob ze chipset obsluguje te niewykorzystane przez cpu cykle nie spowalniajac CPU w ogole. Tyle teoria, w praktyce to spowolnienie wystepuje tym bardziej im damy wiecej bitplanow niz 4 i im wiecej wykorzystamy blittera ktory ma wyzszy priorytet niz CPU.
    
    Blitter to w uproszczeniu szybka kopiarka blokow pamieci. Jego przewaga nad CPU polega na tym ze potrafi odczytywac i zapisywac konkretne dane w sposob ciagly wykorzystujac kazdy kolejny cykl pamieci.
    Tak wiec chcac przekopiowac 16bitow z pamieci do pamieci kosztuje to cykl odczytu i cykl zapisu, jednak duzo wiecej czasu (kilkadziesiat cykli CPU) stanowi zaprogramowanie przez CPU blittera by wiedzial co ma robic, stad najwieksze roznice in plus sa w przypadku kopiowania duzych blokow pamieci, natomiast w przypadku malych danych blitter moze byc nawet wolniejszy.
    
    Aby CPU wykonal tak prosta operacje jak przekopiowanie 16bitow z miejsca na miejsce CPU musi wykorzystac
    2 cykle na odczyt rozkazu
    2 cykle na odczyt adresu pamieci gdzie znajduje sie dana
    2 cykle na odczyt samej danej
    2 cykle na odczyt adresu pamieci gdzie ma zapisac dana
    2 cykle na zapis samej danej
    To co wyzej napisalem to jest mocno uproszczone bo nie pamietam dokladnie ile cykli trwa wykonywanie prostego rozkazu MOV, niemniej jednak chodzi oto aby zobrazowac wam roznice.
    
    Aby jak najefektywniej wykorzystac blittera nalezy zminimalizowac liczbe przeprogramowan ktore kosztuja nas najwiecej czasu. W tym demku 23 kulek wykorzystano trick zwany interleaved bitplanes, ktory polega na umieszczeniu bitplanow jeden po drugim (tak jak to naturalnie jest w ST), celem rysowania pojedynczych wielokolorowych obiektow przy pomocy tylko jednego blitu. Wada tego rozwiazania jest to ze maska do operacji cookiecut musi miec tyle samo bitplanow co sam obiekt. (dla laikow wyjasniam ze jezeli dany obiekt/sprite zajmuje X pamieci to dla blittera musimy miec jeszcze jego maske zajmujaca rowniez X pamieci, co powoduje znaczace uszczuplenie zasobow cennej pamieci chip) W trybie normalnym za maske moze sluzyc tylko 1/4 X pamieci.
    
    Blitter Amigi ma dwa tryby dostepu do pamieci CHIP. Tryb NAsty gdzie zabiera wszystkie cykle i CPU wtedy stoi i tryb zwykly gdzie po 3 cyklach pamieci daje jeden cykl CPU.
    
    Cyprian popraw mnie jesli sie myle, ale z tego co napisales to w STE jest wylacznie tryb NASTY blokujacy calkowicie CPU? Ok jesli tak jest to w jaki sposob mozna dokonac resetowania Blittera skoro CPU stoi? Nie rozumiem tego.
    Byc moze miales na mysli to ze blitter po skonczeniu pracy i oddaniu cykli dla CPU szybciej jest zresetowac i zaprogramowac od nowa niz reprogramowac rejestry po ostatniej pracy????
    
    Na sam koniec wracajac do DREADa to w Amidze celem zaoszczedzenia czasu na C2P kolejne linie sa powielane przez coppera, czyli c2p efektywnie dziala na 320x100, natomiast w przypadku ST C2P musi obrobic 320x200 stad efekt finalny jest troche wolniejszy.
32. • 32:
       
      CommentAuthorjhusak
    • CommentTime14 Sep 2021 11:09 zmieniony

     
    Czyli @Trachu prawdą jest, że na Amidze procek i _chipset_ idą ramię w ramię nie wchodząc sobie w paradę, o ile jest do 4 bitplanów i ekran szerokości 320 piksli.
    
    Natomiast chipset= DMA obrazu, dyskietek, blittera.
    
    I ten chipset bez blittera przy 4 bitplanach nie przeszkadza procesorowi. Natomiast blitter w trybie przyjaznym łaskawie daje procesorowi cykl zapisu czy odczytu raz na 4 cykle pamięci (czyli po 3 cyklach, tu jeszcze jest niejasność, czy tylko, jak procek chce, czy zawsze), poza tym wypełniając wszystkie dostępne mu cykle (i parzyste i nieparzyste). A ponieważ CPU nie samymi cyklami odczytu i zapisu żyje, (a w >=68020 jest jeszcze cache), to rzeczywiście zrównoleglenie jest i działa i to tym lepiej, co procek rzadziej się do pamięci odnosi. Więc trzeba się zastanowić wspomagając blitter w przepisywaniu pamięci, bo to jest ten pesymistyczny przypadek. Optymistyczny by był, gdybyśmy mnożyli czy dzielili na potęgę lub używali operacji na rejestrach, a blitter by kopiował jednocześnie.
    
    To chyba tyle.
33. • 33: CommentAuthorTrachu
    • CommentTime14 Sep 2021 11:09 zmieniony

     
    Masz racje ze CPU nie samymi cyklami dostepu do pamieci zyje, totez po 3 cyklach dostepu blittera nastepuje sprawdzenie czy CPU czasem nie chce miec dostepu do pamieci.
    Gdyby jednak potrzebowal tego dostepu to je dostanie, gdy nie to blitter bedzie dzialal dalej. Nalezy jednak pamietac ze z powodu tego ze cpu dziala co drugi cykl, a blitter w kazdym wypadku wymusi wypadniecie co najmniej jednego cyklu (ze wzgledu na 3 cykle pracy) to w OCSie blitter zawsze troszke spowolni CPU.
    Stad proby rownoleglego uzywania CPU i blittera daja tak marne rezultaty.
    
    Jak uzywasz blittera zawsze spowalniasz CPU nawet uzywajac 4 bitplanow. Jesli uzywasz 5 czy 6 bitplanow to dodatkowo one ci spowolnia CPU.
    Jesli zas chodzi o coppera wszystko zalezy w ktorym miejscu ekranu go uruchomisz. Jesli w srodku ekranu to spowolni on i cpu i blittera, jesli w ramce to jest szansa ze uzyje cykle nieuzywane przez CPU. Szansa bo jest jeszcze sprite i dzwiek i blitter. Najbezpieczniej jest uruchamiac go w prawej ramce.
    
    
    W przypadku chipsetu AGA dostep jest 32bitowy ale blitter dalej jest 16bitowy, tak wiec tam jakies tam wolne cykle dostepu pamieci zostaja nawet jesli blitter dziala na fulla. Sam procesor jest 32bitowy i ma cache co tez pomaga. Jest to fajnie wyjasnione w tym artykule.
    
    Odnoszac sie do twoich historii programowania to moge sie domyslac ze po prostu twoje procedury obslugi blittera nie dzialaly w sposob optymalnie dostrojony do architektury Amigii stad takie a nie inne rezultaty.
    
    Ponizej jest mapa cykli jednej klatki dla DREADa. Kolor seledynowy to blitter. Bordo i taki lekkofiloteowy to CPU. Roz to sprity, Zolty to copper, niebieski to bitplany, czarny to PUSTY/WOLNY slot

    • dma4.png
      
      
      
      
34. • 34:
       
      CommentAuthorjhusak
    • CommentTime14 Sep 2021 22:09

     
    Fajna mapka. Blitter napieprzaaaaa! Ale jeszcze z 1 procent jest marnowane...
    
    Nie, no szacun z wykorzystaniem wszystkiego.
35. • 35:
       
      CommentAuthorlaoo
    • CommentTime15 Sep 2021 09:09

     
    @Trachu Blitter w STe może zabrać wszystkie cykle, albo dzielić się w paczkach po 64 (64 blitter, 64 cpu). Wówczas można restartowąć go w pętli - robi się to, żeby zachować możliwość obsługi przerwań.
36. • 36: CommentAuthordhor
    • CommentTime15 Sep 2021 13:09

     
    Cholera, panowie... Ja tylko zapytałem, dlaczego dłoń na ST jest 'słaba' w porównaniu do Amigi :) Wiem, duszki. Ale teraz to w ogóle mam mózgoodjazd :)
37. • 37: CommentAuthortebe
    • CommentTime15 Sep 2021 14:09

     
    ale tak ogólnie to będzie wersja na Rapidusa i VBXE ? :)
38. • 38:
       
      CommentAuthorPeri Noid
    • CommentTime15 Sep 2021 15:09

     
    Jak się uwzględni niższą rozdzielczość i zegar 20MHz a do tego 16MB RAM to potencjał jest! :-D
    
    A serio - to byłby czad. Szkoda, że tak bardzo niszowa platforma więc szanse zerowe.
39. • 39:
       
      CommentAuthorlaoo
    • CommentTime16 Sep 2021 23:09

     
    Port Dooma na SNESa wykorzystuje SuperFX2 czyli 65816@22 MHz i chodzi całkiem płynnie, aczkolwiek przy mniejszej rozdzielczości. Więc to powinno być całkiem wykonalne.
40. • 40:
       
      CommentAuthorPeri Noid
    • CommentTime17 Sep 2021 00:09

     
    VBXE ma blitter.
41. • 41:
       
      CommentAuthorlaoo
    • CommentTime17 Sep 2021 12:09

     
    Gdyby to tylko był taki blitter jak w Lynksie to byśmy robili nie takie cuda, a same kopiowanie prostokątów akurat w Doomie dużo nie pomoże (może poza narysowaniem tej ręki).
42. • 42:
       
      CommentAuthorKaz
    • CommentTime13 Dec 2021 12:12 zmieniony

     
    Wracając do tematu. Filmik z "Dread" przygotował też Paweł (i jak tam, wyspałeś się w naszym śmieszkującym towarzystwie? :D ) :
    
    

    
    
    Tu nasz krótki filmik, a na nim dzieło Pitera, Jesionena i moje czyli obrotowy baner reklamowy :D
    
    
43. • 43: CommentAuthornowy80
    • CommentTime13 Dec 2021 13:12 zmieniony

     
    Było bardzo sympatycznie i wesoło Kaz. Szkoda było tracić czas na sen, dospałem za to w drodze powrotnej. Apartament pierwsza klasa no i śniadanie rewelacyjne :)Polecam się na przyszłość. Sporo materiału nagrałem niestety z ręki, nie miałem miejsca na zabranie statywu czy gimbala do lustrzanki. Jest też sporo zdjęć robionych na kilku obiektywach. Mogę podesłać do Organizatora, jeśli chciałby skorzystać. Zmontuje dodatkowo materiał z instalacji CT60 w Falkonie czy ogólny materiał z imprezy.
44. • 44: CommentAuthorOjczyznianin
    • CommentTime5 Jan 2022 17:01

     
    NO inspiracja Doomem 2d niezaprzeczalna i ladni wyszlo - jednak dzwięki dosc... nieprzyjemne
45. • 45:
       
      CommentAuthorJacques
    • CommentTime12 Oct 2023 11:10 zmieniony

     
    Nowe grywalne demo Grinda:
    
    ->link<-
46. • 46:
       
      CommentAuthorCyprian
    • CommentTime12 Oct 2023 12:10

     
    czy da się gdzieś to pobrać bez płacenia Patreonowi?
47. • 47:
       
      CommentAuthorJacques
    • CommentTime12 Oct 2023 12:10

     
    Niestety nie, a cena za demko zaporowa (47.50 PLN + VAT) biorąc wsparcie na miesiąc i wycofując ;-)
48. • 48:
       
      CommentAuthorCyprian
    • CommentTime12 Oct 2023 13:10

     
    orientujesz się czy udostępniono też pliki Atari?
49. • 49:
       
      CommentAuthorzbylu
    • CommentTime12 Oct 2023 14:10 zmieniony

     
    Tak, na Atari ST też został udostępniony plik z tą samą mapą (oraz muzyką w tle). Niestety autorzy w licencji piszą o niepublikowaniu screenów oraz nagrań z tej mapy na ST.
50. • 50: CommentAuthorpiter
    • CommentTime14 Oct 2023 10:10

     
    kurczę drogo faktycznie, chętnie bym zobaczył. Ktoś ściągnął? Nie chcę pliku tylko opinię ;)