Prezentujemy Wam prace scenowego grafika - Louie:
Dodano: 2015-10-22 21:34, Autor: st, Kategoria: Scena, Liczba wyświetleń: 12101
Louie - grafiki
Zobacz podobne newsy:
-
Discord (online: ) «»
-
Online: 11
Adam_M
AmiKit
Cizar
Heng
IMPBot
juen
Laubzega
m...
Marek_B
Patu
spazma
-
parallax
Czytelnik
-
komentarz #1 wysłany: 2015-10-25 16:32
A gdzie podpisy "No scan" i "No copy"?
-
swinkamor12
Marian Nowicki
Czytelnik
-
komentarz #2 wysłany: 2015-10-25 16:50 w odpowiedzi na komentarz #1
I to jest to!!!
A kogo to obchodzi scan czy nie scan.
Ważne że wyciągnął z AGA wszystko co się dało.
Grafik wiedział co to jest HAM i nawet na klasyku potrafił zrobić coś co nawet po tylu latach wygląda bardzo ładnie.
Te grafiki mają po osiemnaście i więcej lat, ale wyglądają super.
-
parallax
Czytelnik
-
komentarz #3 wysłany: 2015-10-25 17:35 w odpowiedzi na komentarz #2
To fakt, grafy w HAM8 dzisiaj prezentują się równie dobrze
-
A.K.
Czytelnik
-
komentarz #4 wysłany: 2015-10-25 22:39
No o dziwo chyba pamiętam te graficzki. Z płyty Scene Xplorer chyba. Z perspektywy czasu (i własnych doświadczeń z grafiką) podejrzewam, że te bardziej fotorealistyczne powstały ongiś na PC i zostały dobrze przekonwertowane, ale po tylu latach dawno przestało to już mieć emocjonalne znaczenie
-
Hextreme
Czytelnik
-
komentarz #5 wysłany: 2015-10-26 08:58 w odpowiedzi na komentarz #2
A kogo to obchodzi scan czy nie scan.
Jeśli to skany to jego grafika nie jest wiele warta. Akurat tego aniołka widziałem całkiem niedawno w Magazynie Amiga jak wertowałem swoje archiwa. Przyznam, że ładnie się tam prezentował i przypomniał mi o scenie komputerowej i jej cudowności.
Ja nigdy nie byłem scenowcem i zapewne będę dopiero, jak wyzdrowieję. Dlatego mam takie pozytywne podejście do sceny. Jest to moje największe marzenie zostać członkiem grupy. Fajnie, że scena jest cały czas żywa i Amiga zajmuje honorowe miejsce.
Zawsze zastanawiałem się, skąd ludzie biorą takie fajne nicki. Skąd takie fajowe nazwy grup jak Scoopex.
Ważne że wyciągnął z AGA wszystko co się dało.
No to mamy odmienne podejście do takich spraw, drogi Marianie. Dla mnie ważne jest, by jakiś margines możliwości zostawić. Jestem bardzo wstrzemięźliwy jeśli chodzi o wykorzystanie zasobów. AGA nie powiedziała swego ostatniego słowa. Przygotowuję artykuł o AGA do Amigazynu i pokażę ją w dobrym świetle.
Przykładowo jakby Amiga miała tylko chunky, to niemożliwe stałoby się m.in. płynne sprzętowe skrolowanie w pionie i poziomie w 8 planach (256 kolorach). A tak można tworzyć bajecznie kolorowe gry z płynną i szybką animacją.
Blitter jest dostosowany do pracy na danych planar. Gdyby CPU zajmowało się wszystkim (w tym i kopiowaniem danych graficznych), to komputer Amiga nigdy nie byłby taką super konstrukcją. A tak grafika, dźwięk, duszki są sterowane niezależnie.
W przypadku 3D - konwersja chunky2planar nie jest aż tak kosztowna, jeśli ktoś naprawdę potrzebuje chunky. Ale należy to robić z głową, często jest tak, że chunky nie jest potrzebne. Format planarny z powodzeniem może być wykorzystywany do większości zadań.
Blittera można użyć na bazie przerwań (funkcje QBlit oraz QBSBlit) dzięki czemu może być on wykorzystany w bardzo efektywny sposób.
Te i inne rzeczy dużo bardziej rozwinięte wkrótce w artykule.
-
swinkamor12
Marian Nowicki
Czytelnik
-
komentarz #6 wysłany: 2015-10-26 17:11 w odpowiedzi na komentarz #5
PPA na Ciebie drogi Robercie źle wpływa.
C64 drogi Robercie ma obraz w formacie chunky pixel i płynne skrolowanie jest na nim jak najbardziej możliwe.
Blitter byłby fajny gdyby go Commodore ulepszało przez te wszystkie lata, a tak, nawet 020 w a1200 lepsze.
Chunky pixel jak było wielokrotnie omawiane, bardzo by Amidze pomogło.
-
parallax
Czytelnik
-
komentarz #7 wysłany: 2015-10-26 18:58 w odpowiedzi na komentarz #6
Amidze pomagały karty graficzne, a jak ktoś chciał tylko w 2D sobie gry popykać, to spokojnie
takie golasy wystarczały
A, że było nie wiele gier obsługujących karty GFX, to już inna sprawa
Właśnie do "czegoś więcej" powstawały rozszerzenia, a jak ktoś nie potrzebował tego czegoś więcej i nie chciał przepłacać, to standardowa Amiga wystarczała - kminisz, czy mam to namalować?
-
swinkamor12
Marian Nowicki
Czytelnik
-
komentarz #8 wysłany: 2015-10-26 19:15 w odpowiedzi na komentarz #7
na drzewo
-
A.K.
Czytelnik
-
komentarz #9 wysłany: 2015-10-26 22:06
Garść sprostowań...
Na klasycznych Amigach z potężniejszymi procesorami niestety bardzo opłacało się zastępować nimi Blittera (np. łatka FBlit). Stary Blitter w AGA był wielkim błędem, ale może po prostu nie dało się inaczej z powodu ograniczeń sprzętowych. A może i bardziej finansowych...
C64/Atari XL/XE nie mają trybu chunky piksel. Ten tryb jest praktycznie poza zasięgiem komputerów ośmiobitowych. Tu piksele standardowo (pomijając różne tryby i wyjątki) tworzą pary bitów.
-
swinkamor12
Marian Nowicki
Czytelnik
-
komentarz #10 wysłany: 2015-10-26 22:12 w odpowiedzi na komentarz #9
C64 nie ma trybu chunky pixel 256 kolorów (8 bit). Ale ma chunky pixel 4 kolory (2 bity).
Nie ma jak na Amidze dwu bitplanów, tylko info o kolorze jest w dwu bitach obok siebie.
A skrolowanie jest i jak na rok produkcji całkiem fajne.
-
A.K.
Czytelnik
-
komentarz #11 wysłany: 2015-10-26 22:40 w odpowiedzi na komentarz #10
Toż o tym pisałem W ośmiobitowcach nie ma oczywiście klasycznych amigowych bitplanów ani pecetowych "bajtopikseli", ale chcąc wstawić pojedynczy piksel dalej masz masz "paskudne" operacje na bitach. A i dostępne rozkazy mikroprocesorów na wiele nie pozwalają. Chcąc np. używać programowych duszków także musisz korzystać z masek bitowych i operacji AND i OR.
-
swinkamor12
Marian Nowicki
Czytelnik
-
komentarz #12 wysłany: 2015-10-27 00:24 w odpowiedzi na komentarz #11
Aha. Ale jak widać bez bitplanów też da się zrobić całkiem fajny skroling.
-
Hextreme
Czytelnik
-
komentarz #13 wysłany: 2015-10-27 08:23 w odpowiedzi na komentarz #9
AGA nie ma starego Blittera. Już kości ECS wprowadziły ogromne zmiany w temacie Blittera. Rozmiar operacji w przypadku OCS to 1024 razy 1024 pikseli. W przypadku ECS/AGA ten rozmiar to 32768 razy 32768 pikseli. Chyba widać dużą różnicę.
Blitter użyty na bazie przerwania Blittera tak jak wspominałem może być bardzo efektywny.
FBlit to tragedia jest i niezrozumienie pewnych rzeczy związane z systemem Amigi. System Amiga OS nie bez przyczyny domyślnie otwiera się w 4 kolorach i rozdzielczości 640x256, bo jest to optymalna rozdzielczość. Funkcje graficzne systemu (szczególnie okienka typu Smart) są dosyć powolne dla wielu kolorów. Przyczyna leży w software, a nie hardware.
Co do skrolowania - AGA umożliwia skrolowanie nawet w rozdzielczości SuperHires (przypominam, że SuperHires to 1280 pikseli w poziomie).
Przesuw niezależnych bitplanów jest realizowany o wiele efektywniej. Koprocesor Amigi - Playfield pobiera kolejne słowa danych z wielu bitplanów równocześnie i przesuwa je bitowo w poziomie uzyskując efekt płynnego przesuwu (można przesuwać o 16 pikseli na ramkę).
Skrolowanie w Chunky tak efektywne jak w przypadku budowy planarnej jest praktycznie niemożliwe i chyba jest wiadome dlaczego. Nie można przesuwać bitowo danych Chunky, bo to nie ma sensu.
Ale minusem budowy planarnej jest to, że trudno stawiać pojedyncze lub grupy pikseli. Wtedy przydaje się budowa Chunky.
Zatem coś za coś.
-
swinkamor12
Marian Nowicki
Czytelnik
-
komentarz #14 wysłany: 2015-10-27 17:36 w odpowiedzi na komentarz #13
Ależ skądże drogi Robercie. W AGA blitter jest ten sam i jest tak samo szybki jak w roku 1983 gdy Amiga miała być kolejnym Atari.
-
Radov
Redaktor
-
komentarz #15 wysłany: 2015-10-27 20:56 w odpowiedzi na komentarz #13
W przypadku ECS/AGA ten rozmiar to 32768 razy 32768 pikseli. Chyba widać dużą różnicę.
Nie, nie widać. Robercie, proszę wyjaśnij: jak w maszynie z 2MB pamięci chciałbyś zrealizować blit 32768x32768 pikseli? Przecież to się po prostu nie mieści w... CHIPie... ale to brzydko brzmi
Poza rozmiarem blitu, Blitter w AGA, ECS i OCS działa na tych samych zasadach i z taką samą maksymalną wydajnością teoretyczną: 3.5 MB/s. Jedyna różnica, to taka że blitter w ECS/OCS traci 0.24MB/s na każdy włączony bitplane obrazu. Efektywny wzrost rzeczywistej wydajności o 0.97MB/s miedzy rokiem 1983, a 1992 jest naprawdę - zupełnie nie imponujący.
Blitter użyty na bazie przerwania Blittera tak jak wspominałem może być bardzo efektywny.
Jakbyś efektywnie go nie wykorzystywał - nie będzie to więcej niż 3.5 MB/s. Przecież wszyscy to wiemy. Możesz wreszcie rozwinąć na co konkretnie ta efektywność pozwala w rzeczywistych zastosowaniach? Jakieś przykłady? Coś czego nie wiemy?
System Amiga OS nie bez przyczyny domyślnie otwiera się w 4 kolorach i rozdzielczości 640x256, bo jest to optymalna rozdzielczość.
Bardzo eufemistyczne określenie na: "Amigowy chipset jest za wolny na więcej"...
Funkcje graficzne systemu (szczególnie okienka typu Smart) są dosyć powolne dla wielu kolorów. Przyczyna leży w software, a nie hardware.
Przyczyna leży w hardware. Konkretnie: w utrzymaniu założonych jeszcze w 1983 roku parametrów pracy chipsetu Amigi - aż do samego końca życia Commodore.
Koprocesor Amigi - Playfield...
Taki koprocesor nie istnieje Robercie...
pobiera kolejne słowa danych z wielu bitplanów równocześnie i przesuwa je bitowo w poziomie uzyskując efekt płynnego przesuwu (można przesuwać o 16 pikseli na ramkę).
Nie. nie robi tego i nic nie jest przesuwane bitowo. Skrolling poziomy jest w Amidze sztuczką analogową. Polega na tym, że chipset wczytuje dane obrazu o 1 słowo obrazu więcej, przesuwa całość ekranu i jedynie wygasza pierwsze - do 16tu pikseli. Dając w efekcie ZŁUDZENIE skrollu.
Swoją drogą, ma to miejsce na tym etapie, gdy chipset Amigi wewnętrznie już przekonwertował sobie dane do postaci szeregowej: a więc CHUNKY. Nie ma więcej powodu, dla którego skroll w Amidze nie miałby zadziałać tak samo płynnie dla danych, które od razu są zapisane w Chunky.
Skrolowanie w Chunky tak efektywne jak w przypadku budowy planarnej jest praktycznie niemożliwe i chyba jest wiadome dlaczego.
Nie. Pierwsze słyszę dlaczego skrolowanie w Chunky miałoby być praktycznie niemożliwe, ani tak efektywne jak w Planar. Zupełnie nie jest mi wiadome dlaczego. Mógłbyś konkretnie wyjaśnić?
-
Radov
Redaktor
-
komentarz #16 wysłany: 2015-10-27 21:53 w odpowiedzi na komentarz #15
Skrolling poziomy jest w Amidze sztuczką analogową
To moje stwierdzenie nie dawało mi spokoju, więc postanowiłem je zweryfikować i odkopać wątek gdzie Toni Willen opisywał działanie BPLCON1. Jednak trochę przesadziłem / źle zapamiętałem. Nie jest to "sztuczka analogowa", ale wciąż nie jest to algorytm o jakim myśli Robert....
-
Hextreme
Czytelnik
-
komentarz #17 wysłany: 2015-10-27 22:33 w odpowiedzi na komentarz #15
Przyczyna leży w hardware. Konkretnie: w utrzymaniu założonych jeszcze w 1983 roku parametrów pracy chipsetu Amigi - aż do samego końca życia Commodore.
Oczywiście, że w Software. Myślisz, że algorytmy użyte w Amiga OS są najlepszymi do realizacji wyznaczonych im zadań? Prawda jest taka, że sporo kodu Amiga OS 3 zawiera jeszcze stare procedury, m.in. nie wszystkie bitmapy są "zaprzyjaźnione". Parę rzeczy można by zrobić efektywniej. Pole manewru dla programistów ogromne.
Taki koprocesor nie istnieje Robercie...
Wiem, że taki koprocesor istnieje, tak samo jak Copper i Blitter są koprocesorami. Zgodnie z nazwą pracują one równocześnie.
Nie. Pierwsze słyszę dlaczego skrolowanie w Chunky miałoby być praktycznie niemożliwe, ani tak efektywne jak w Planar. Zupełnie nie jest mi wiadome dlaczego. Mógłbyś konkretnie wyjaśnić?
Wszystko rozchodzi się o wewnętrzną reprezentację danych. Jest to bardzo, ale to bardzo niski poziom - chodzi o realizację elektroniczną takich rzeczy jak rejestry procesora, rejestry sprzętowe.
Jak mniemam w Amidze dane planarne (kolejne 16-bitowe słowa, które reprezentują 16 pikseli) trafiają do obróbki do rejestru przesuwnego. Ten może w błyskawiczny sposób przesunąć dane w jednym z kierunków (lewo lub prawo). Dzięki temu skrolowanie jest realizowane w sposób błyskawiczny i nie obciążający procesor. W przypadku danych chunky taki rejestr istnieć nie może bo musiałby mieć z 128 bitów - tyle potrzeba by pomieścić 16 pikseli typu chunky. Dlatego w przypadku chunky niezbędne staje się kopiowanie 8-bitowych słów, żaden rejestr przesuwny tu nie zadziała.
Proszę nie brać tego za opis pełny, jest to moje domniemanie i może różnić się ze stanem faktycznym.
Mam nadzieję Konradzie, że używałeś Amigi więcej niż PC. Dla amigowca walory Amigi są czymś naturalnym, ale oczywiście można podyskutować.
-
A.K.
Czytelnik
-
komentarz #18 wysłany: 2015-10-27 22:54 w odpowiedzi na komentarz #12
Akurat C64 i Atari XL/XE mają scrolling wspomagany sprzętowo, zaś małe Atari to o dziwo przodek Amigi, czego pewnie wciąż wiele osób nie wie (albo i nie zechce uwierzyć :] ). ZX Spectrum i Amstrad czegoś takiego nie posiadają, ale w jakoś poradzono tam sobie z tym. Co do innych modeli 8bit nie wiem, nie chcę tu się bawić w eksperta od ośmiobitowców. Następca C64 czyli... Atari ST też ma o dziwo problemy z przewijaniem grafiki, też nawet zaskakująco sobie z tym poradzono - ale to już nie to forum
-
Radov
Redaktor
-
komentarz #19 wysłany: 2015-10-28 00:12 w odpowiedzi na komentarz #17
Oczywiście, że w Software. Myślisz, że algorytmy użyte w Amiga OS są najlepszymi do realizacji wyznaczonych im zadań? Prawda jest taka, że sporo kodu Amiga OS 3 zawiera jeszcze stare procedury, m.in. nie wszystkie bitmapy są "zaprzyjaźnione". Parę rzeczy można by zrobić efektywniej. Pole manewru dla programistów ogromne.
Robercie, algorytmy które piszesz były już miliony razy rozkładane na czynniki pierwsze. Ich działanie i miejsca optymalizacji sa powszechnie znane. Zrozum, że jakby nawet założyć 100% efektywnośc algorytmów to wciąż będą one wykonywane przez maszynę, której procesor potrafi wykonać około 700.000 operacji na sekundę (Amiga 500), a chipset jest kontrolowany przez zegar 3.5MHZ. Jakbyś nie kombinował, to optymalizacja algorytmu da ci najwyżej kilkadziesiąt % przyspieszenia. Aktualizacja założeń architektury Amigi z poziomu roku 1983 na poziom roku 1992 da przyspieszenie rzędu co najmniej 10cio krotnego.
Czy jesteś w stanie przyspieszyć AmigaOS na Amidze co najmniej 10 krotnie samą optymalizacją algorytmów? Nie jesteś.
Zrozum: problemem jest hardware, a nie software. Hardware Amigi OCS/ECS/AGA grzęźnie przez wolną wewnętrzną 16 bitową szynę chipsetu o taktowaniu 3.5 MHz. Jakikolwiek algorytm nie będzie działał szybciej, niż będzie wynikać z tych parametrów.
Wiem, że taki koprocesor istnieje, tak samo jak Copper i Blitter są koprocesorami.
No właśnie nie tak jak Blitter i Copper Blitter i Copper są koprocesorami, koprocesora "Playfield" nie ma. Obsługa Playfield jest zawarta w układzie Denise / Alice, ale nie jest to (ko)procesor.
Wszystko rozchodzi się o wewnętrzną reprezentację danych. Jest to bardzo, ale to bardzo niski poziom - chodzi o realizację elektroniczną takich rzeczy jak rejestry procesora, rejestry sprzętowe.
Robercie, nie załapałeś ironii - doskonale wiem, że rozbijasz się o realizację elektroniczną. Ironia miała na cel naprowadzić cię na myśl, że twoje założenia odnośnie trudności realizacji płynnego skrolowania dla trybu Chunky sa błędne.
Napiszę więc wyraźnie: mylisz się. Realizacja skrolowania dla chuky nie jest jakimkolwiek problemem.
w Amidze dane planarne (kolejne 16-bitowe słowa, które reprezentują 16 pikseli) trafiają do obróbki do rejestru przesuwnego. Ten może w błyskawiczny sposób przesunąć dane w jednym z kierunków (lewo lub prawo). Dzięki temu skrolowanie jest realizowane w sposób błyskawiczny i nie obciążający procesor. W przypadku danych chunky taki rejestr istnieć nie może bo musiałby mieć z 128 bitów - tyle potrzeba by pomieścić 16 pikseli typu chunky. Dlatego w przypadku chunky niezbędne staje się kopiowanie 8-bitowych słów, żaden rejestr przesuwny tu nie zadziała.
Robert, litości:
a) Nie ma najmniejszego problemu ze stworzeniem 128 bitowego rejestru przesuwnego.
b) Nie ma najmniejszej potrzeby żebyś dla skrolowania w trybie chunky w ogóle potrzebował buforu 128bit.
d) W trybie chunky, przy takiej realizacji buforów jak jest w Amidze OCS/ECS, wystarczy 1 bufor 16 bitowy - niezależnie od głębi koloru ekranu. Zamiast 6ciu buforów 16bitowych jak dla trybu Planar.
e) W trybie chunky, blitter kopiując dane z uwzględnieniem maski, miałby przepustowość większą o 25% względem obecnej realizacji dla trybu Planar.
Mam nadzieję Konradzie, że używałeś Amigi więcej niż PC. Dla amigowca walory Amigi są czymś naturalnym, ale oczywiście można podyskutować
Ja za to mam nadzieję Robercie, że w końcu zaczniesz merytorycznie interesowac się Amigą i zarzucisz "domniemania", bo na razie nie ma za bardzo o czym z tobą dyskutować.
-
swinkamor12
Marian Nowicki
Czytelnik
-
komentarz #20 wysłany: 2015-10-29 08:52
W płynnych skrolach nie ma nic szczególnego - prosty trick polegający na zmianie adresu od którego jest wyświetlany obraz.
Po prostu ruch w górę zaczynamy wyświetlać od adresu w pamięci o jedną linię mniej niż poprzednią ramkę,
ruch w dół zaczynamy wyświetlać od adresu w pamięci o jedną linię więcej niż poprzednią ramkę,
W lewo o parę bajtów mniej, w prawo o parę bajtów więcej.
Działa bez związku z tym czy obraz jest w bitplanach czy nie.
Trick stosowany wszędzie nawet w EGA na pc.
Na amidze jest o tyle lepiej że układy zostały podwojone i mamy dwa playfieldy - co daje piękne efekty jak się ktoś postara.
-
A.K.
Czytelnik
-
komentarz #21 wysłany: 2015-10-31 22:30 w odpowiedzi na komentarz #20
W płynnych poziomych scrollach na kompach z grafiką gdzie piksele to bity lub grupy bitów sama zmiana adresu danych do wyświetlenia nie da odpowiedniego efektu. Bo będziesz miał z przyczyn oczywistych przeskok tylko co bajt (pomijając inne problemy), czyli w większości wypadków 4-8 pikseli.
W kompach ze sprzętowym wspomaganiem poziomego przewijania i grafiką opartą na bitach są rejestry, których odpowiednie zmiany wyświetlają odpowiednio przesunięty obraz. Inaczej się w tym wypadku nie da.
- Discord
-
Online: 11
- Menu
- Baza wiedzy
- Najpopularniejsze
