Chciałem podzielić się kilkoma technikami programistycznymi, które wykorzystuję w Amiga OS.

--
1. Pierwsza technika polega na bardzo efektywnym sposobie rysowania i animacji. Działa zarówno na całym ekranie, jak i okienkach (przy czym cały ekran można rozumieć jako okno wypełniające ekran).

Otóż wystarczy przygotować jedną funkcję rysującą, która rysuje wszystko, tzn. np. rysuje najpierw całe tło okna a później nanosi wszystkie obiekty animowane.

Następnie wywołanie funkcji rysującej poprzedzamy zainstalowaniem regionu przycinania (Clip Region) i obieramy obszar, który chcemy by został odrysowany (np. tylko miejsca z animowanymi obiektami).

I gotowe! Dzięki temu jest jedna funkcja rysująca całą zawartość a optymalizacja działa. Upraszcza to pisanie funkcji rysującej.

Dodatkowo możemy pobrać ramy zmienionego obszaru za pomocą poniższej funkcji i ewentualnie uwzględniać to przy rysowaniu (choć nie jest to konieczne):

GetRPAttrs(rp, RPTAG_DrawBounds, &rect, TAG_DONE);

Podczas rysowania możemy korzystać z maski zapisu (WriteMask) lub maksymalnego ołówka (MaxPen), żeby dodatkowo przyśpieszyć rysowanie. Dla ekranu 256-kolorowego możemy np. obrać 16-kolorowy blok w palecie i zapisywać 2 razy mniej danych.

Ważne by powiązać maskę zapisu/maksymalny ołówek z konkretnym miejscem w okienku/warstwie i stosować konsekwentnie w tym miejscu.

SetRPAttrs(rp, RPTAG_WriteMask, 0xff, TAG_DONE);

Powyższa technika jest naturalnie dostępna w Amiga OS, bo mamy funkcję InstallClipRegion() z biblioteki layers.library, która instaluje ten region przycinania. Ponadto jest region "wbudowany" o nazwie DamageList, który zawiera odsłonięte obszary okna. Możemy do niego dodawać własne obszary i wykorzystywać w funkcji BeginUpdate()/EndUpdate().

Sama technika pojawia się też np. w systemie Windows, gdzie okno dostaje komunikat o odrysowaniu. W Amiga OS 2.0+ są też klasy obrazków i gadżetów BOOPSI z metodami IM_DRAW i GM_RENDER, które działają w podobny sposób.

Serdecznie polecam.

--
2. Druga technika to wydajny sposób na podwójne buforowanie. Instalujemy przerwanie Coppera za pomocą:

AddIntServer(INTB_COPER, &is);

Przerwanie Coppera wysyła sygnał do naszego tasku.

Teraz również dodajemy copperlistę użytkownika do naszego ekranu za pomocą makr w następujący sposób:

ucl = AllocMem(sizeof(*ucl), MEMF_PUBLIC|MEMF_CLEAR);

CINIT(ucl, 3);
CWAIT(ucl, 0, 0);
CMOVE(ucl, custom.intreq, INTF_SETCLR|INTF_COPER);
CEND(ucl);

Forbid();
vp->UCopIns = ucl;
Permit();

RethinkDisplay();

Po wykonaniu powyższych czynności będziemy dostawali sygnał, kiedy wiązka obrazu będzie w pozycji 0, 0. Teraz tworzymy dwie bitmapy oraz strukturę DBufInfo:

dbi = AllocDBufInfo();

Alokujemy jeden port komunikacyjny i podpinamy go do tej struktury:

dbi->dbi_SafeMessage.mn_ReplyPort = mp;

Trzeba jeszcze zadeklarować jedną zmienną typu BOOL, która będzie przechowywać status.

BOOL safeToDraw = TRUE;

Teraz wystarczy czekać na sygnały za pomocą funkcji Wait(), a następnie obsłużyć je w taki sposób, że jeżeli dostaniemy wiadomość SafeMessage na port, to pobieramy wiadomość za pomocą GetMsg() (samo Wait() nie pobiera wiadomości).

if (!safeToDraw) { 
    while (!GetMsg(mp)) 
        WaitPort(mp); 
    safeToDraw = TRUE;
}

Jeżeli natomiast otrzymaliśmy sygnał z przerwania Coppera piszemy tak:

if (safeToDraw) {
    ChangeVPBitMap(vp, bitmaps[frame], dbi);
    frame ^= 1;
    safeToDraw = FALSE;
}

Dzięki tej technice mamy gwarantowaną płynną animację. Wymaga ona OS 3.0.

Mam nadzieję, że te informacje się przydadzą. W razie pytań, proszę śmiało zadawać. Pozdrawiam.

• Odpowiedz

@Hexmage960, post #1

a prosciej tego nie mozna?

• Odpowiedz

@selur, post #2

• Odpowiedz

@Hexmage960, post #3

• Odpowiedz

@Norbert, post #4

• Odpowiedz

@Hexmage960, post #1

• Odpowiedz

@Hexmage960, post #1

hip, hip - hura!
hip, hip - hura!
hip, hip - hura! hura! hura!
Niech nam żyje Kura Programming Digital Software Gears Unlimited Inkurporated!

• Odpowiedz

@witekkk, post #5

@Norbert, @Witekkk, @Jimiche

Dzięki za zainteresowanie. Podam parę przykładów, które ilustrują omawiane zagadnienia. Jeżeli chodzi o moją stronę internetową to ją utrzymuję od kilku lat i mam plany co do rozbudowy. Materiały z mojej strony też nie znikną. Ale mogę wrzucić artykuł na PPA, jeśli redakcja wyrazi zgodę.

Postaram się też zamieścić w artykule parę ilustracji.

Ja po prostu promuję programowanie systemowe w Amiga OS. Commodore też promowało taki styl.

@Snajper

Wiem, że nazewnictwo się zmieniało ale to tylko forma. Treść pozostaje w gruncie rzeczy podobna.

Ostatnia aktualizacja: 02.05.2023 17:27:58 przez Hexmage960

• Odpowiedz

@Hexmage960, post #8

• Odpowiedz

@Norbert, post #9

• Odpowiedz

@Hellena, post #10

• Odpowiedz

@Norbert, post #11

• Odpowiedz

@amikoksu, post #12

• Odpowiedz

@Norbert, post #13

• Odpowiedz

@Hexmage960, post #1

3.

Hej. Wczoraj wpadłem na jeszcze jedną technikę (i ją zrealizowałem). W zasadzie jest ona rozszerzeniem mojej wcześniejszej techniki. Służy do rysowania dowolnego fragmentu większej mapy/planszy w okienku. Możemy przesuwać mapę co do piksela! Rysowanie odbywa się za jednym zamachem, nie trzeba nic dorysowywać!

Ponadto rysowana mapa ma zdefiniowaną przez nas ramkę, która jest używana do przesłonięcia wchodzącego obszaru - dzięki temu rysujemy tylko raz.

Poniższa ilustracja pochodzi z działającego silnika: Obszar między ramkami jest rysowany na bieżąco.



Otóż wykorzystujemy koprocesor graficzny Blitter w następujący sposób (przykład w języku C):

a) Obieramy jako operację AB+aC, czyli "Cookie-cut" (wartość 0xCA).

b) Włączamy tylko kanał źródłowy B oraz przeznaczenie (SRCB | DEST). Zatem w BLTCON0 wpisujemy:

custom.bltcon0 = 0xca | SRCB | DEST;

c) Obieramy przesunięcie 0-15 w BLTCON1 (na podstawie najmłodszych 4 bitów współrzędnej X źródłowej bitmapy). Ponieważ Blitter przesuwa w zwykłym trybie w prawo, musimy odjąć tę wartość od liczby 16, jeżeli jest większa od zera. Uwaga: Jeżeli przesuwamy, musimy dodać 2 bajty do adresu źródłowego, co robimy poniżej przy ładowaniu adresu kanału B.

custom.bltcon1 = ((srcX & 0xf) ? 16 - (srcX & 0xf) : 0) << BSHIFTSHIFT;

d) Do kanału A ładujemy stałą wartość 0xfffff.

e) Do kanału C ładujemy stałą wartość - dowolne 16 pikseli ramki.

f) Do kanału B ładujemy adres bitplanu z mapą/planszą:

custom.bltbpt = srcPlanes[p] + srcY * srcBytesPerRow + ((srcX >> 4) << 1) + ((srcX & 0xf) ? 2 : 0);

g) Podobnie do kanału D ładujemy adres bitmapy docelowej:

custom.bltdpt = dstPlanes[p] + dstY * dstBytesPerRow + ((dstX >> 4) << 1);

h) Ustawiamy pierwsze i ostatnie słowo kanału A na zero:

custom.bltafwm = 0;
custom.bltalwm = 0;

i) Ustawiamy wartości modulo oraz rozmiaru operacji. Najpierw liczymy szerokość i wysokość na podstawie struktury Rectangle opisującej obszar docelowy:

wordWidth = (bounds.MaxX - bounds.MinX + 16) >> 4;
lineHeight = bounds.MaxY - bounds.MinY + 1;

j) Teraz liczymy modulo i je ustawiamy:

custom.bltbmod = srcBytesPerRow - (wordWidth << 1);
custom.bltdmod = dstBytesPerRow - (wordWidth << 1);

k) Rozpoczynamy operację ustawiając jej wysokość i szerokość:

custom.bltsizv = lineHeight;
custom.bltsizh = wordWidth;

Uwaga: Powyższe ustawianie rozmiaru wymaga przynajmniej chipsetu ECS. W przypadku chipsetu OCS ustawiamy tak:

custom.bltsize = (lineHeight << HSIZEBITS) | wordWidth;

l) Należy pamiętać, że użyte symbole pochodzą z pliku <hardware/custom.h> oraz <hardware/blit.h>, które należy załączyć:

#include <hardware/custom.h>
#include <hardware/blit.h>

m) Oraz zadeklarować zewnętrzną strukturę Custom:

__far extern struct Custom custom;

Zdaję sobie sprawę, że informacje są bardzo skondensowane i nie wszystko jest wyjaśnione. Postaram się przygotować artykuły o jakich była mowa (jak będę miał troszkę więcej czasu).

Technika może znaleźć zastosowanie w wielu gatunkach gier z dużą mapą/planszą. Być może zrealizuję przy jej pomocy odświeżony klon Robbo lub nową wersję Magazynu, bądź Blastera. Ogólnie jest to mechanizm, o jakim marzyłem - i chciałbym przenieść w to przyjazne środowisko moje gry. Mam nadzieję, że moja praca przyniesie owoce.

Oczywiście można tu robić różne typy gier - wyścigówki 2D, strategiczne z dużą mapą itp.

Kod silnika wykorzystujący te techniki zamieszczę na GitHub i/lub Aminecie.

Pozdrawiam.

Ostatnia aktualizacja: 13.05.2023 11:41:40 przez Hexmage960

• Odpowiedz

@Hexmage960, post #15

Chciałbym zaznaczyć, że to jest sucha technika, ale ma przełożenie na realne zastosowania. Po prostu pokazuję "placeholdery" w miejscu gdzie powinna się znaleźć właściwa grafika.

Normalnie bym pokazywał mapę, którą można przesuwać. Ale to dopiero jak przygotuję grafiki, czyli w następnej kolejności. Planowałem na pierwszy ogień zrobić prostą (ale atrakcyjną) grę typu Robbo, czy Boulder Dash, mimo że silnik może być wykorzystany do złożonych gier.

Taki odświeżony Robbo byłby zdecydowanie atrakcyjniejszy w stosunku do mojego dawnego klonu.

Niedawno udało mi się zrobić silnik gry planszowej Młynek z zarysem gry komputera.

Pozdro.

Ostatnia aktualizacja: 13.05.2023 15:03:28 przez Hexmage960

• Odpowiedz

@Hexmage960, post #16

• Odpowiedz

@Norbert, post #17

• Odpowiedz

@Hexmage960, post #15

• Odpowiedz

@Aniol, post #18

• Odpowiedz

@Norbert, post #17

• Odpowiedz

@Norbert, post #17

Chyba rozumiem już dlaczego napisałeś o "moim punkcie widzenia na te sprawy".

Otóż ja promuję wykorzystanie naturalnych własności Amigi i jej OS:

Stosuję wielozadaniowość Amigi, ekrany systemowe, współdzielone zasoby: koprocesory graficzne, kanały dźwiękowe, ekrany publiczne oraz biblioteki i urządzenia (jak również semafory i porty komunikacyjne).

Widzę, że najbardziej popularnym podejściem jest kodowanie sprzętowe Amigi 500. Od chipsetu AGA jednak architektura Amigi jest na tyle złożona, że lepiej według mnie korzystać z systemu.

Zresztą Amiga 500 też ma system OS 1.3 lub nowszy.

Ostatnia aktualizacja: 14.05.2023 07:16:13 przez Hexmage960

• Odpowiedz

@Hexmage960, post #22

• Odpowiedz

@Pinto, post #23

Myślę że mimo wszystko ten sposób programowania jest zgodny z systemem. Projektanci AOS na szczęście przewidzieli takie sytuacje i umożliwili pisanie własnych procedur korzystających bezpośrednio z HW (nie całe oczywiście) bez potrzeby ubijania systemu. WaitBlitt i OwnBlitter i można "zgarnąć blittera". Tak samo usercoplist do używania Coppera (szkoda że taka bardziej statyczna ta lista jest, da się ją oczywiście zmieniać ale nie jest to tak wydajne jak obsługa wlasnej).
Jednak pozostaje pytanie jak w ten sposób napisany kod będzie działał na AOS4/MOS/AROS. A i na szybszych procesorach użycie CPU zamiast blittera może być szybsze (to ostatnie w pewnym stopniu chyba załatwia FBlitt).

Ja osobiście jako hobbysta-lamerzysta lubię odkrywać AOS, a samo pisanie pod system jest dla mnie łatwiejsze niż ogarnianie HW samemu

• Odpowiedz

@pisklak, post #24

• Odpowiedz

@pisklak, post #24

• Odpowiedz

@asman, post #25

No sposób nr 1 jest najlepszy
A takie patchowanie funkcji systemowych to też niekoniecznie na zdrowie dla stabilności systemu może wyjść. No chyba już lepiej po prostu napisać własny odpowiednik danej funkcji. Oczywiście w miarę możliwości tak żeby nie bruździł systemowi w czymś (w czym own/disown blitter pomaga ale nie musi bo np. po wykryciu szybszego procesora lepiej daną operację właśnie nim zrobić a nie blitterem)

Ostatnia aktualizacja: 15.05.2023 09:54:11 przez pisklak

• Odpowiedz

@Pinto, post #23

• Odpowiedz

@Hexmage960, post #28

• Odpowiedz

@asman, post #29

Zawsze jest możliwe, trzeba tylko ruszyć głową trochę... Przecież zawsze możesz wywołać starą (nie spaczowaną) funkcję.

OK, można zrobić kilka przypadków i obsłużyć wybrane, ale nie wyklucza to pisania własnych funkcji rysujących.

Jest nawet specjalna funkcja do tego celu: DoHookClipRects(), która wywołuje naszą funkcję rysującą typu Call Back Hook dla prostokątów tworzących okienka z odświeżaniem Simple Refresh / Smart Refresh / Super BitMap.

Blokuje ona warstwę za pomocą LockLayer() tylko raz. Można też spacerować ręcznie po ClipRectach.

Czasami łatanie funkcji systemowych jest bardzo trudne, ze względu na niejawność niektórych struktur oraz duże skomplikowanie. Czasami chcemy też zmienić sposób rysowania. Przykładowo robiłem własną funkcję do przemieszczania okien typu Simple Refresh i nawet poradziłem sobie z tym, że ClipRectów nie wolno zwalniać, bo są trzymane na jakiejś liście.

Ale w praktyce działają dobrze pewne sztuczki typu: otwórz okienko w nowym miejscu, co rozwiązuje problem. Albo - otwórz duże okno i rysuj w jego fragmenty.

Istnieje wiele dróg a walka o wydajność powinna być na samym końcu, bo co Ci z tego że nawaliłeś super kodu jak produkt nie jest skończony.

Co do walki o wydajność, to pełna zgoda. Warto tak projektować program, by korzystać z istniejących funkcji. I dopiero je optymalizować.

Tutaj podaję kilka praktycznych technik, z których korzystam. Niektóre są wydajne (technika nr 2 i 3), niektóre prezentują sposób podejścia zapożyczony z innych systemów (technika nr 1), choć w Amiga OS istnieje obsługa IDCMP_REFRESHWINDOW i region DamageList, który możemy dowolnie ustalać.

Wczoraj wymyśliłem kolejną technikę, ale nie sprawdzałem jej jeszcze w praktyce. Jest to synchronizacja rysowania w pojedynczym buforowaniu, by nie było widać procesu rysowania z pomocą Coppera. Pomysł jest taki, że przerwanie notyfikuje położenie wiązki obrazu za pomocą VBeamPos() a następnie sygnalizuje task, który rysuje prostokąt od ostatniego wywołania do tego VBeamPos().

Choć najlepiej rysować w podwójnym buforowaniu, jeśli to możliwe.

Niedawno sprawdzałem technikę "rysowania częściowego", tzn. że wywołuję rysowanie wszystkich elementów na ekranie, ale duże obiekty rysuję częściowo, tak by mieć płynność 50 FPS dla każdego elementu. Przyznam, że działało to bardzo dobrze i płynnie, nawet z oryginalną funkcją WriteChunkyPixels().

To są jednak troszkę eksperymentalne techniki, więc jeszcze ich nie opisywałem.

Istnieje wiele dróg a walka o wydajność powinna być na samym końcu, bo co Ci z tego że nawaliłeś super kodu jak produkt nie jest skończony.

Ja podaję sporo pomysłów, chciałem je jakoś usystematyzować i udostępnić innym programistom. Te techniki są sprawdzone w praktyce, kompletne i działające. Wiadomo, nie ma z tego gotowej gry. Nad tym jeszcze pracuję.

Ostatnia aktualizacja: 16.05.2023 08:01:10 przez Hexmage960

• Odpowiedz