kategoria: ANSI C
[#31] Re: pisanie GRY w C pod A500

@teh_KaiN, post #30

W grze Benefactor woda jest zrealizowana właśnie zmianą palety kolorów na przeciągu jednej linii. Teraz właśnie doszedłem do wniosku, że trudno Ci będzie zmienić paletę tak intensywnie, bo prawdopodobnie nie zdążysz zmienić palety między sąsiadującymi linijkami.

Rozwiązanie może być takie, że zmieniasz tylko część palety kolorów (np. kilka kolorów) między sąsiadującymi linijkami w bezpiecznej pozycji wiązki Coppera (podczas wygaszania poziomego). Musiałbym zajrzeć do dokumentacji by Ci powiedzieć bardziej szczegółowo jak to zrealizować. Póki co możesz sam zajrzeć do ROM Kernel Reference Manual: Hardware, rozdział zatytułowany Copper (coprocessor).

Jak przeczytasz ten rozdział to uświadomisz sobie, że CBump nie jest komendą Coppera, tylko funkcją graphics.library, która inkrementuje bieżący wskaźnik na Copperlistę użytkownika. Oznacza to, że nie wprowadza komendy do listy jak CMove, albo CWait. Co do przykładu: ja myślę, że jest tam błąd, bo komend jest dwukrotnie więcej.
[#32] Re: pisanie GRY w C pod A500

@teh_KaiN, post #30

Pierwszy akapit. Yep.

Rozdzielczość pozioma de facto wynosi 113 (najmłodszy bit jest ignorowany). Przekłada się to do 4 punktów lowres. Przypuszczalnie struktura view przechowuje offsety hardwaru, ale nie wnikałem. Musisz poczytać jak hardware wyświetla obraz i wszystko stanie się jasne. Jeśli chcesz zmienić kolory z lewej strony przed wyświetleniem obrazu to czasu starczy na 7 takich zmian w linii. Musisz też przeliczyć ile cykli zostanie po odliczeniu video dma i spritów dla coppera (hardware manual).
[#33] Re: pisanie GRY w C pod A500

@cholok, post #32

Ale wtedy 113*4 = 452 pikseli, co daje przy lowresie 132 pikseli na offscreen poziomy, czyli po 66 pikseli na każdą stronę. Nie za dużo?

@Hextreme-Attic: tak też planowałem, generować sobie programowo copperlisty, które zakładają zmianę palety tylko o te kolory, które są potrzebne dla nowej linii, a nie ma ich w obecnej palecie. Dodatkowy czas też mi doda to, że oryginał gry wykorzystuje pole ekranu 240x200, także mam dodatkowe 80 pikseli ekranowych na zmianę palety.
[#34] Re: pisanie GRY w C pod A500

@teh_KaiN, post #33

Nie za dużo?


Nie, bo rozdzielczość sprzętowa obejmuje całość generowania obrazu, a więc też elementy, kiedy promień elektronów nie wyświetla obrazu. Zauważ, że nawet pełny overscan nie wykorzystuje pełnej rozdzielczości sprzętowej.
[#35] Re: pisanie GRY w C pod A500

@teh_KaiN, post #33

Teraz pytanie z innej beczki... Blitter!

Albo mi się śniło, albo gdzieś widziałem takie cudo, które pozwala blitować np. bitmapy 2bpp na bitmapy 5bpp z ustaleniem, który bitplane ze źródła ma polecieć na dany bitplane docelowy. Ale oczywiście jak jest mi to potrzebne, to nie mogę tego znaleźć :)

Docelowo potrzebuję przeblitować fragment 8x16 bitmapy 2bpp na bitmapę 5bpp tak, by źródłowe bitplane'y 0 i 1 wylądowały na docelowych bitplane'ach 2 i 3. Wydaje mi się, że rozwiązanie było bardziej eleganckie niż parę BltTemplate i polegało na tym, że w bajcie jakiegoś parametru funkcji ustawiało się bity określające relacje między bitplane'ami. Ktoś pomoże?
[#36] Re: pisanie GRY w C pod A500

@teh_KaiN, post #35

DrawImage z Intution.library jak dobrze kojarze a tutaj opis struktury Image
[#37] Re: pisanie GRY w C pod A500

@asman, post #36

Tak, to chyba to co widziałem. Tylko teraz jak to się ma do rysowania po ViewPortach, które mają RasterInfo, a te z kolei BitMap? Chyba nijak, bo funkcja wymaga RastPortów, a to jest chyba tylko do rysowania po okienkach?

Na spacerze wykoncypowałem sobie, że po prostu zadeklaruję nową, pośrednią strukturę BitMap i zrobię tak (pseudokod):

...
BitMap src,dest,tmp;
src.Depth = 2;
dest.Depth = 5;
tmp.Depth = 2;

tmp.Planes[0] = dest.Planes[2];
tmp.Planes[1] = dest.Planes[3];

BltBitMap(src,tmp);
...


I to mi napisze bitplane'y ze źródła tam gdzie chcę w docelowym. Pytanie, czy można jakoś ładniej/szybciej?
[#38] Re: pisanie GRY w C pod A500

@teh_KaiN, post #37

Hej, wystarczy mieć strukturę RastPort, znicijować ją funkcją InitRastPort() i podpiąć BitMapę w ten sposób:

InitRastPort( &rport );
rport.BitMap = &bitmap;

Dzięki temu będziesz mógł rysować w swoją BitMapę za pomocą właśnie funkcji podanej przez Asmana: DrawImage() oraz wszystkich tych, które potrzebują RastPortu.
[#39] Re: pisanie GRY w C pod A500

@Hextreme-Attic, post #38

aaa... dobre :)

Cały czas mam wbite w głowę, że rysowanie grafiki odbywa się na Ami dwojako:
  • systemowo po okienkach, a co za tym idzie samym procesorem i wolno (ścieżka Window->RastPort)
  • bezpośrednio po ekranie, z pomocą 68k, blittera i coppera (ścieżka View->ViewPort->RasterInfo)
nie jest tak?

Tak właściwie to patrzę na strukturę RastPort i widzę tam pełno pierdół typu pisaki, LinePtrn, pozycja pisaka, definicje tekstu, itd. Zastanawiam się, czy warto się w ogóle w tego typu strukturę bawić jeśli póki co potrzebuję tylko tej jednej operacji, która by mogła jej wymagać. Myślicie, że moje rozwiązanie z tymczasową bitmapą byłoby przekombinowaniem?

Ostatnia aktualizacja: 17.06.2013 17:57:14 przez teh_KaiN
[#40] Re: pisanie GRY w C pod A500

@teh_KaiN, post #39

Bezpośrednio po ekranie to ja rozumiem tak: przewalasz bajty na bitplan, czyli na przykład bajt 0xFF do komórki o adresie 0x70000, gdzie 0x70000 jest na przykład pierwszym bitplanem. A systemowo to ja rozumiem tak: używając funkcji z bilioteki na przykład graphics.library. Nie interesuje mnie wtedy gdzie ten ekran jest i jak jest ułożony, jedyne co jest ważne to między innymi jak dane które chcę narysować są wymagane przez funkcję, dzięki temu nie muszę się martwić czy ktoś ma Amigę na kościach AGA czy posiada kartę graficzną.

Myślicie, że moje rozwiązanie z tymczasową bitmapą byłoby przekombinowaniem?
Nie jestem ekspertem od spraw związanych z rysowaniem w zgodzie z OS, ale widzę, że funkcja BltBitMap ma parametr Mask, może wystarczy tą wartość ustalić na 0x06. I być może wtedy nie trzeba będzie używać tymczasowej bitmapy. Daj znak czy pomogło.
[#41] Re: pisanie GRY w C pod A500

@asman, post #40

Chyba pudło, o parametrze mask:
The mask argument, normally set to 0xff, specifies which bitplanes will be involved in the
blit operation and which will be ignored. If a bit is set in the mask byte, the corresponding bitplane is included.

Czyli po prostu jedynka przy bitplanie, który ma być uwzględniony przy blitowaniu, bez miszmaszów.

Źle to ująłem, oczywiście że jeżdżenie po sprzęcie odbywa się po adresach. Bardziej chodzi mi o to, że wydawało mi się że ścieżka Window->RastPort obarczona jest całą warstwą abstrakcji systemu operacyjnego, w sensie OS przemiela każdy rozkaz 50 razy żeby właściwie ogarnął co ma zrobić, a ścieżka View->ViewPort->RasterInfo i funkcje z nią związane to właśnie tylko cieniutka warstwa abstrakcji, która pozwala na bardziej pisanie pod sprzęt, ale też wymaga brania pod uwagę timingów sprzętu itd. Mylę się?
[wyróżniony] [#42] Re: pisanie GRY w C pod A500

@teh_KaiN, post #41

RastPort w istocie jest obarczony pewną nieznaczną warstwą abstrakcji, operacje na nim używają współdzielonego Blittera przez co mogą być troszkę za wolne dla dynamicznej gry, ale umożliwia naprawdę szereg ciekawych operacji na bitmapie:

  • rysowanie linii, prostokątów itp.
  • rysowanie wypełnionych wielokątów, elips bądź stref z możliwością wyboru tapety
  • rysowanie i animacja BOBów, wirtualnych duszków (VSprites), obiektów animowanych (AnimObs)
  • wpisywanie tekstu
  • przycinanie operacji graficznych (clipping)

Niektóre z tych możliwości wymagają ręcznego rozszerzania struktury RastPort (opisane w dokumentacji). RastPortu można stosować po prostu dla wygody, gdy chcesz np. narysować kreskę w jakimś kolorze na swojej BitMapie, w miejscach gdzie potrzebna jest szybkość stosuj np. operacje Blittera, którego przejmujesz na własną wyłączność tj,. OwnBlitter(), następnie operacje na rejestrach Blittera, a następnie DisownBlitter().

RastPort to może być część okienka na Workbenchu, dlatego może budzić skojarzenia, że operacje na nim są powolne. RastPort może być tylko interfejsem na BitMapę, który umożliwia operacje w zgodzie z systemem. Mała uwaga: RasInfo nie jest strukturą do rysowania - odpowiada ona za usytuowanie BitMapy w ViewPorcie (kiedy BitMapa jest większa niż ViewPort).

Nie wiem dokładnie jak chcesz pogodzić takie rzeczy jak zmiany palety wewnątrz copperlisty użytkownika oraz operacje na BitMapie (przecież kolory w Twojej grze ulegają zmianie, więc rysowane obiekty mogą mieć niewłaściwe kolory). Ja na Twoim miejscu troszkę uprościłbym sobie zadanie jeśli jest to Twoja pierwsza gra na Amigę. Ale decyzja rzecz jasna należy do Ciebie.

Parametr Mask funkcji BltBitMap() to powinno być to, co Cię interesuje: odpowiada on za to jakie bitplany w docelowej bitmapie mają być zmienione przez tę operację graficzną.
[#43] Re: pisanie GRY w C pod A500

@Hextreme-Attic, post #42

Dzięki za odpowiedzi, bez Was by mi wszystko szło znacznie wolniej. :)

Póki co próbuję robić cały input za pomocą intuition - klawę i mysz też mam opanowaną dzięki temu. Ale ja nie o tym. Chciałbym zrobić sterowanie kursorem na modłę street roda, czyli steruje się kursorem za pomocą klawy, myszki i joysticka naraz, czym wygodniej. I tu pytanie - jak najlepiej zmieniać pozycję kursora na konkretne x,y? Nie byłem w stanie się dokopać nigdzie do funkcji, która by to umiała. Gdzieś te rzeczy można zmieniać pod jakimś adresem czy coś?

Chciałbym też zrobić animację kursora po najechaniu na wskazane miejsce. Myślałem o SetPointer, ale zastanawiam się czy nie będzie szybciej jakoś dobrać się bezpośrednio do pierwszego sprajta? Jak tak, to jak można się dobrać do obecnej struktury pierwszego sprajta? Bo trzeba go będzie przecież przywrócić na samym końcu. Chyba że przez jakieś magiczne wywołanie SetPointer, które przywróci domyślny kursor?
[#44] Re: pisanie GRY w C pod A500

@teh_KaiN, post #43

Póki co próbuję robić cały input za pomocą intuition - klawę i mysz też mam opanowaną dzięki temu.

Jak dobrze rozumiem masz ekran i dzięki IMDCP odbierasz stosowne zdarzenia o myszce i klawiaturze ? Jeśli odpowiedź jest na tak to pozycję myszki możesz pobrać dobierając się do odpowiednich pól w strukturze Window (MouseX i MouseY) a w przypadku okna typu GimmeZeroZero są to pola GZMouseX i GZMouseY.

Jeśli chodzi o animacje pointera myszki to w zgodzie z OS używaj SetPointer i ClearPointer, jest przykład do tego The Pointer.
[#45] Re: pisanie GRY w C pod A500

@asman, post #44

zrobiłem tak, że w tle za moim viewem jest rozciągnięte okno na cały screen i ono zgarnia wszystkie zdarzenia.

Bardziej mi chodzi o to, żeby pozycję ustawić, tzn. kursor przestawić w inne miejsce ekranu gdy np. wcisnę klawisz strzałki. Pobranie klawisza to nie kłopot, tylko jak zmienić pozycję kursora?
[wyróżniony] [#46] Re: pisanie GRY w C pod A500

@teh_KaiN, post #45

Z tego co wiem trzeba użyć input.device. Przykładzik tutaj Set Mouse
[#47] Re: pisanie GRY w C pod A500

@asman, post #46

Podziałało. Dzisiaj się jeszcze pobawię animacją kursora.

Przy okazji kolejne pytanie, kategoria bobsy. Załóżmy, że moja postać ma animację chodzenia z lewej na prawo, jest jakiś sprzętowy sposób na obrócenie lustrzane boba? Czy trzeba bawić się w ręczne obracanie wordów?
[#48] Re: pisanie GRY w C pod A500

@teh_KaiN, post #47

Z tego co wiem to nie ma sprzętowego obracania.

Ja tam znam dwa szybkie sposoby:
1 - obróć postać w programie graficznym i problem z głowy. Minus taki że więcej pamięci potrzeba i dane graficzne zajmują więcej
2 - obrócenie postaci programowo, przeważnie na początku. Minus taki, żę więcej pamięci potrzeba ale dane graficzne na dysku zajmują mniej.
[#49] Re: pisanie GRY w C pod A500

@teh_KaiN, post #47

Blitter potrafi przesuwac bity i wykonywac operacje logiczne. Nie ma mozliwosci obrocenia bitow za pomoca jednej operacji. Najlepiej uzyc sposobu 2 zaproponowanego przez asmana.

Gdyby jednak brakowalo pamieci na animacje postaci, mozna robic to w locie, wtedy najlepiej uzyc tablic...
[#50] Re: pisanie GRY w C pod A500

@asman, post #48

Przepraszam że się podepnę ale czy macie może tytuły literatury, które pomogłyby w programowaniu/tworzeniu gier dla klasycznej AMI?

Moim marzeniem było zawsze stworzyć jakąś grę... choćby to nawet trwało latami.

Kiedyś stworzyłem ponga na 286/CGA ale to były dawne czasy.


Czy takie coś:
http://allegro.pl/jezyk-c-nowoczesne-programowanie-wyprzedaz-50-i3319603673.html
będzie przydatne?

Ostatnia aktualizacja: 23.06.2013 13:31:40 przez BomberMAX
[#51] Re: pisanie GRY w C pod A500

@BomberMAX, post #50

Przewertuj ten temat, źródła wiedzy były podane :)

Wprowadzenie do Ami u mnie szło według tego tutoriala, przy okazji masz tam omówione podstawy języka C. Wtedy załapiesz mniej więcej jak działa intuition. Potem lądujesz tu i dużo dużo czytasz, jednocześnie patrząc na przykłady z tego tematu. Jak nie wiesz jak coś zrobić to zawracasz d..głowę ludziom na forum tak jak ja, póki co działa ;)

Co do samego czystego C to bardzo polecam Dark cult of c++, co prawda z tej strony uczyłem się winApi, ale sam język C tutaj też jest ładnie opisany razem z niuansami cpp.

@gx: myślałem żeby trzymać klatki animacji jedną pod drugą i wtedy swapować całe kolumny za pomocą jakiegoś BltBitMap czy cuś. Jeszcze nie wiem jak by to wydajnościowo wyglądało, ale chyba znacznie lepiej niż bym miał swapować za pomocą m68k kolejne wordy.
[#52] Re: pisanie GRY w C pod A500

@teh_KaiN, post #51

myślałem żeby trzymać klatki animacji jedną pod drugą i wtedy swapować całe kolumny za pomocą jakiegoś BltBitMap czy cuś...ale chyba znacznie lepiej niż bym miał swapować za pomocą m68k kolejne wordy


oczywiscie tak byloby najszybciej, bralem pod uwage tylko przypadek kiedy brakuje pamieci na umieszczenie calej zawartosci, przed zmiana kierunku poruszania odbicie lustrzane bitmap klatki/klatek animacji za pomoca 68k... i dalej blitbitmap. Wszystko zalezy od tego, ile zajmuja pamieci animacje bohaterow, jak malo, to nie ma sensu robic tego w locie, tylko zastosowac metode nr. 2 asmana.

Z innej beczki, co daje takie odbicie, jezeli np: facet trzyma giwere w prawej rece i go w ten sposob odbijesz, to nagle giwera przemiesci mu sie do lewej reki i dziwnie to bedzie wygladac, nie uwazasz ?
[#53] Re: pisanie GRY w C pod A500

@gx, post #52

W tej grze, w miejscach gdzie postaci się obraca, broni przeważnie nie ma, a jak już jest jakieś coś w łapach, to symetryczne :)

Ile miejsca zajmują klatki? Myślę, że będzie z tego coś koło 50-80KB (w jednym kierunku) tego co by musiało być zawsze w RAMie, także myślę że optymalizacja pod pamięć jest wskazana.

W tym tygodniu pobawię się różnymi metodami i na pewno napiszę co wybrałem.

Ostatnia aktualizacja: 23.06.2013 23:34:55 przez teh_KaiN
[#54] Re: pisanie GRY w C pod A500

@teh_KaiN, post #53

Bobsami się jeszcze nie zająłem, bo coś mnie tknęło żeby sprawdzić jak gra zachowuje się na KS1.3 na UAE a potem żywym hw i... schody :)

Wydaje mi się, że gcc mi linkuje jakieś badziewie typu ixemul.library, co mnie bardzo nie urządza, bo z tego co widzę to to głównie do portowania linuksowych/posixowych appów jest, a po co mój program ma mieć w sobie taki szmelc jak piszę tylko pod Amigę. Chyba że jest inne wytłumaczenie na to, że tuż po otwarciu main() program mi crashuje? Nawet nie chce zapisać prostego pliku tekstowego, mimo że to pierwsze instrukcje main. Raczej nie wina tego, że siedzę na WB3.1 a odpalałem na 1.3? Nadmienię, że nie korzystam z żadnej funkcji KS2+.

Skorzystałem z sugestii z tego tematu i przerzuciłem się na DICE. Przełożyłem cały folder ADE/os-include do dinclude:, skonfigurowałem sobie vmake i niby działa. Niby, bo linker ma z czymś problem i nie mam pomysłów z czym. Tutaj znajduje się log. Jakieś pomysły czego szukać? _custom mi podpowiada że może chodzić o hardware/custom.h, którego używam. Nadmienię, że ten sam kod kompiluje się bezbłędnie pod gcc.
[#55] Re: pisanie GRY w C pod A500

@teh_KaiN, post #54

Nie znam się na tym, ale czy może gdzieś ustawia się tam jakiego typu skoków ma używać linker? Bo wygląda że linker ustawiony jest na krótkie skoki, a tutaj potrzebny jest długi.
W razie czego możecie mnie zbluzgać
[wyróżniony] [#56] Re: pisanie GRY w C pod A500

@teh_KaiN, post #54

zeby gcc nie uzywalo ixemul.library przy kompilacji i linkowaniu trzeba dodac opcje -noixemul
[wyróżniony] [#57] Re: pisanie GRY w C pod A500

@teh_KaiN, post #54

Jeśli chodzi o DICE to przed extern struct Custom custom; dodaj atrybut
__far
[#58] Re: pisanie GRY w C pod A500

@Hextreme-Attic, post #57

Zapewne chodziło o to, bo pamiętam że gcc tego nie lubił i mu to usuwałem. Na śmierć zapomniałem.

@kiero: dzięki za podpowiedź, ale raczej nie skorzystam, bo podoba mi się jak szybko DICE leci z kompilacją w porównaniu z gcc.

Niby to by rozwiązało sprawę, ale oczywiście musiałem przekombinować i w międzyczasie na czysto zainstalowałem DICE według tego guide'a

Teraz mam problem taki, że nie widzi mi includów mimo ustawienia w user-startup odpowiedniego set (zmiana na setenv też nic nie daje). Snoopdos wykazuje, że kompilator w ogóle nie patrzy w katalog dinclude:amiga39.

Jeśli w ustawieniach vmake każę mu patrzeć w ten konkretny folder, to inkludy znajduje, ale potem wali błędem:
DC1: "cursor.c" L:19 C:60 F:99 Base variable (SysBase) for pragma is undefined

Zaznaczam, że kompiluję przez vmake. Może tu jest przyczyna?

I jeszcze jedno szybkie pytanie - czy dmake z dice 3.16 różni się dużo składniowo od gnu make? Bo zmieniłem nazwę makefile na dmakefile, "gcc" na "dcc" i mi nie działa, a makefile jest całkiem prosty:
OBJS=obj/main.o obj/text.o obj/joy.o obj/cursor.o obj/gameloop.o

out: $(OBJS)
	gcc $(OBJS) -o $@
	
obj/main.o: main.c
	gcc -c $< -o $@

obj/text.o: text.c
	gcc -c $< -o $@
	
obj/joy.o: joy.c
	gcc -c $< -o $@
	
obj/cursor.o: cursor.c
	gcc -c $< -o $@
	
obj/gameloop.o: gameloop.c
	gcc -c $< -o $@
[wyróżniony] [#59] Re: pisanie GRY w C pod A500

@teh_KaiN, post #58

Inkludy do amigowych bibliotek masz załączane razem z archiwum z DICE. Polecam użyć ich, wtedy problem powinien zniknąć.

DMAKE, jak przeczytasz instrukcję, różni się nieco od standardowego MAKE.

Polecam napisać swój DMAKEFILE w ten sposób:
SRCS = main.c text.c joy.c cursor.c gameloop.c
OBJS = $(SRCS:*.c:obj/%1.o)
out: $(OBJS)
dcc $(OBJS) -o out
$(OBJS): $(SRCS)
dcc %(right) -c -o %(left)
[#60] Re: pisanie GRY w C pod A500

@teh_KaiN, post #58

@ixemul

Spoko, po prostu dla potomności. GCC ma taką zaletę, że można używać jako cross. A jak już chcesz natywny kompilator to polecam sas/c. Sporo nowszy niż dice i pod uae kompiluje bardzo szybko + ma świetny debugger. Taka luźna dygresja;)

@make

Obstawiam, że składnia jest inna (w sas/c jest inna). No ale dlaczego po prostu ciągle nie używać make z pakietu gnu jak jesteś przyzwyczajony.
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem