27.11.2022 11:47
[#1]
automaty skończone
Ostatnio kręcę się wokół tego tematu (finite state machine) i jestem ciekawy czy ktoś pod Amigę korzysta z tego .
27.11.2022 13:07
[wyróżniony]
[#2]
Re: automaty skończone
@asman, post #1
ACE ma maszyny stanu i sugeruje ich użycie do zarządzania głównymi stanami gry (menu, gra, creditsy itd). Każdy stan jako struct callbacków wołanych jak:
- wchodzisz do stanu
- wychodzisz z niego
- w pętli jak w nim jesteś - tu wsadzasz logikę stanu
dodatkowo możliwość założenia stosu stanów bez usuwania poprzedniego jak wchodzisz w następny. Są datkowe dwa callbacki pozwalające zrobić coś jak obecny stan jest pauzowany bo nowy wszedł na stos albo jest przywracany bo zdjęto inny ze stosu. Dokumentacja tu, kod źródłowy .h (z dokumentacją) i .c. Maszyny stanu w tym wydaniu można zagnieżdżać.
Z mniejszych maszyn stanu to na przykład openfire, germz i aminer ma tak rozwiązany HUD - nie wszystko w jednej klatce, tylko każdy element rozrzucony na klatki, każdy ma osobny stan. W praktyce to po prostu zapętlony duży switch po enumie.
Można jeszcze coś kombinować w C++20 z korutynami, które obsługuje kompilator Bartmana, ale tego jeszcze nie robiłem.
Ostatnia aktualizacja: 27.11.2022 13:14:06 przez teh_KaiN
- wchodzisz do stanu
- wychodzisz z niego
- w pętli jak w nim jesteś - tu wsadzasz logikę stanu
dodatkowo możliwość założenia stosu stanów bez usuwania poprzedniego jak wchodzisz w następny. Są datkowe dwa callbacki pozwalające zrobić coś jak obecny stan jest pauzowany bo nowy wszedł na stos albo jest przywracany bo zdjęto inny ze stosu. Dokumentacja tu, kod źródłowy .h (z dokumentacją) i .c. Maszyny stanu w tym wydaniu można zagnieżdżać.
Z mniejszych maszyn stanu to na przykład openfire, germz i aminer ma tak rozwiązany HUD - nie wszystko w jednej klatce, tylko każdy element rozrzucony na klatki, każdy ma osobny stan. W praktyce to po prostu zapętlony duży switch po enumie.
Można jeszcze coś kombinować w C++20 z korutynami, które obsługuje kompilator Bartmana, ale tego jeszcze nie robiłem.
Ostatnia aktualizacja: 27.11.2022 13:14:06 przez teh_KaiN
28.11.2022 23:48
[#4]
Re: automaty skończone
@asman, post #1
Ja ostatnio kręcę się wokół tematu kompilatorów. Mam taki przedmiot na studiach. O ile teraz nie korzystam z automatów skończonych jawnie, ten temat pojawia się na tym przedmiocie.
Pewnego typu automat skończony użyłem w pierwszym projekcie, którym jest skaner - pobiera jednostki leksykalne z wejścia (tokeny). Drugim projektem jest parser, który sprawdza zgodność z gramatyką - czeka mnie wkrótce.
Co do Amigi, to z powodzeniem mógłbym użyć jej, bo ten przedmiot jest z wykorzystaniem ANSI C, biblioteki standardowej. No ale pracuję na PC.
Ostatnia aktualizacja: 28.11.2022 23:48:58 przez Hexmage960
Pewnego typu automat skończony użyłem w pierwszym projekcie, którym jest skaner - pobiera jednostki leksykalne z wejścia (tokeny). Drugim projektem jest parser, który sprawdza zgodność z gramatyką - czeka mnie wkrótce.
Co do Amigi, to z powodzeniem mógłbym użyć jej, bo ten przedmiot jest z wykorzystaniem ANSI C, biblioteki standardowej. No ale pracuję na PC.
Ostatnia aktualizacja: 28.11.2022 23:48:58 przez Hexmage960
29.11.2022 09:49
[#5]
Re: automaty skończone
@teh_KaiN, post #2
@Krashan, Hexmage960
Dzięki za odpowiedzi. Bardziej mi chodzi o gamedev :)
@teh_KaiN
Dzięki, przejrzałem sobie źródła. I jak zwykle mam zbyt wysokie oczekiwania co do kodu i jakoś to dla mnie zbyt skomplikowane, I ten switch, na kilka ekranów, to jednak nie dla mnie. Dochodzę do wniosku że wystarczą mi dwa: przy zmianie stanu i gdy stan jest wykonywany. A w niektórych sytuacjach to jeden jest wystarczający. Ale oczywiście rozumiem, że czasami mogą się przydać pozostałe stany. I jak dobrze rozumiem ze źródeł ACE, stos tu jest realizowany jako sprytna lista jednokierunkowa.
Dzięki za odpowiedzi. Bardziej mi chodzi o gamedev :)
@teh_KaiN
Dzięki, przejrzałem sobie źródła. I jak zwykle mam zbyt wysokie oczekiwania co do kodu i jakoś to dla mnie zbyt skomplikowane, I ten switch, na kilka ekranów, to jednak nie dla mnie. Dochodzę do wniosku że wystarczą mi dwa: przy zmianie stanu i gdy stan jest wykonywany. A w niektórych sytuacjach to jeden jest wystarczający. Ale oczywiście rozumiem, że czasami mogą się przydać pozostałe stany. I jak dobrze rozumiem ze źródeł ACE, stos tu jest realizowany jako sprytna lista jednokierunkowa.
29.11.2022 10:27
[#6]
Re: automaty skończone
@asman, post #5
tak no, ten switch to abominacja jest, ale jak chcesz szybko to często przez to jest brudno. Można by każdego case'a trzymać w osobnej funkcji ale ciężej się to wg mnie czyta. Generalnie te switche powstały tak, że najpierw wszystko napisałem ciurem żeby się robiło naraz w klatce, a potem pomierzyłem i okazało się że muszę to rozbić na etapy. No to dodałem enum, podzieliłem na bloczki i w każdym bloczku tego enuma inkrementuję, szlus.
Co do maszyny stanu z callbackami - mamy ich tyle bo właśnie jak masz maszynę od całych elementów gry to w create/destroy wrzucisz sobie alokację i zwalnianie zasobów, w loop to co wykonuje się "co klatkę". I tak, jest to lista "w tył" i używana jest tylko jak robisz push/pop stanów na sobie. Przy "zwykłym" przerzucaniu stanów, które najbardziej rekomenduję, wystarczy Ci ptr na aktualny stan żeby wiedzieć którego stanu wołać callback co klatkę. ;)
Ostatnia aktualizacja: 29.11.2022 10:28:36 przez teh_KaiN
Co do maszyny stanu z callbackami - mamy ich tyle bo właśnie jak masz maszynę od całych elementów gry to w create/destroy wrzucisz sobie alokację i zwalnianie zasobów, w loop to co wykonuje się "co klatkę". I tak, jest to lista "w tył" i używana jest tylko jak robisz push/pop stanów na sobie. Przy "zwykłym" przerzucaniu stanów, które najbardziej rekomenduję, wystarczy Ci ptr na aktualny stan żeby wiedzieć którego stanu wołać callback co klatkę. ;)
Ostatnia aktualizacja: 29.11.2022 10:28:36 przez teh_KaiN
29.11.2022 12:32
[#7]
Re: automaty skończone
@teh_KaiN, post #6
W sumie jeśli mówimy o "zwykłym" przerzucaniu stanów to ja wymyśliłem taki minimalny.
Chociaż nie powiem, ten ze stosem (czyli z historią poprzednich stanów) też się przydaje.
A tak z innej beczki ale w sumie też kwestia stanów się pojawi. Wydaje mnie się że ACE to tak dla mnie trochę za ciężki jest, ale po prawdzie musiałbym zrobić w nim coś choćby małego. Trudne to do ogarnięcia ?
Nie myślałeś o jakiejś wersji light tego ACE ? (ehh, no i gdzie ta kwestia stanów - ano nima, mógłby wtedy taki minimalny state w nim być :) )
Ostatnia aktualizacja: 29.11.2022 12:34:07 przez asman
typedef void(*PVF)(void);
PVF state;
/*--------------------------------------------------------------------------*/
void MinStateChange(PVF execute)
{
state = execute;
}
/*--------------------------------------------------------------------------*/
void MinStateExecute(void)
{
state();
}
/*--------------------------------------------------------------------------*/Chociaż nie powiem, ten ze stosem (czyli z historią poprzednich stanów) też się przydaje.
A tak z innej beczki ale w sumie też kwestia stanów się pojawi. Wydaje mnie się że ACE to tak dla mnie trochę za ciężki jest, ale po prawdzie musiałbym zrobić w nim coś choćby małego. Trudne to do ogarnięcia ?
Nie myślałeś o jakiejś wersji light tego ACE ? (ehh, no i gdzie ta kwestia stanów - ano nima, mógłby wtedy taki minimalny state w nim być :) )
Ostatnia aktualizacja: 29.11.2022 12:34:07 przez asman
29.11.2022 16:26
[#8]
Re: automaty skończone
@asman, post #7
Wersja light ACE'a? Proszę bardzo:
- systemCreate() i systemDestroy() do inicjalizacji gadania z OSem (managers/system.c/.h), systemUse() i systemUnuse() do jego włączania i wyłączania
- memCreate() i memDestroy() i pokrewne funkcje (managers/memory.c/.h) dla menedżera pamięci
- logCreate() i logDestroy() i pokrewne (managers/log.c/.h) do zarządzania logami. Reszta Twoja.
Chcesz więcej? Dorzuć sobie ACE'owy menedżer stanów (managers/state.c/.h). Jeszcze więcej? menedżer blittera (managers/blitter.h). Chcesz wygodnie zarządzać copperlistą i na niej zrobić swój ekran? menedżer coppera (managers/copper.c/.h). Chcesz pominąć ręczne zabawy i prosto założyć ekran? To masz utils/extview.h który ma abstrakcję ekranów prawie jak w graphics.library korzystającą z copper managera. Input tylko ten który sobie zainkludujesz. Funkcje filesystemu i inputa też opcjonalne. To już jest mega modularne (niektóre menedżery mogą być ze sobą powiązane ale tnę to najbardziej jak mogę, utile nie mają zależności jako takich), tylko wszyscy to mają w nosie. :(
Ostatnia aktualizacja: 29.11.2022 16:31:20 przez teh_KaiN
- systemCreate() i systemDestroy() do inicjalizacji gadania z OSem (managers/system.c/.h), systemUse() i systemUnuse() do jego włączania i wyłączania
- memCreate() i memDestroy() i pokrewne funkcje (managers/memory.c/.h) dla menedżera pamięci
- logCreate() i logDestroy() i pokrewne (managers/log.c/.h) do zarządzania logami. Reszta Twoja.
Chcesz więcej? Dorzuć sobie ACE'owy menedżer stanów (managers/state.c/.h). Jeszcze więcej? menedżer blittera (managers/blitter.h). Chcesz wygodnie zarządzać copperlistą i na niej zrobić swój ekran? menedżer coppera (managers/copper.c/.h). Chcesz pominąć ręczne zabawy i prosto założyć ekran? To masz utils/extview.h który ma abstrakcję ekranów prawie jak w graphics.library korzystającą z copper managera. Input tylko ten który sobie zainkludujesz. Funkcje filesystemu i inputa też opcjonalne. To już jest mega modularne (niektóre menedżery mogą być ze sobą powiązane ale tnę to najbardziej jak mogę, utile nie mają zależności jako takich), tylko wszyscy to mają w nosie. :(
Ostatnia aktualizacja: 29.11.2022 16:31:20 przez teh_KaiN
29.11.2022 16:31
[#9]
Re: automaty skończone
@teh_KaiN, post #8
To nie tak. Kain chyba był by ci potrzebny jakiś vlog czy coś ala toturial aby pokazać co potrafi ACE. Lucek mi opowiadał jak tworzył grę w ACE... to brzmi świetnie... Tylko np. ja jestem totalnym lamerem no i moim targetem są bardziej rozbudowane konfigi i dema. Ale wierz mi ludzie się temu przyglądają od dawna.
Ostatnia aktualizacja: 29.11.2022 16:32:45 przez jimiche
Ostatnia aktualizacja: 29.11.2022 16:32:45 przez jimiche
29.11.2022 19:16
[#10]
Re: automaty skończone
@jimiche, post #9
Trochę racja z tym tutorialem...Nie chcę zostać źle zrozumiany, ale z własnego doświadczenia wiem jedno - w Amosie po kliknięciu na ikonke i otwarciu środowiska wystarczy wklepać (cytuję z pamięci, nie włączyłem Amosa ponad 2 lata) "Screen open 0 : curs off : flash off : Bar 0,0,320,200,1" i po uruchomieniu programu mamy otwarty ekran z narysowanym prostokątem, jedna linia, 15 sekund pisania.
Tak samo Quad dawno temu wytłumaczył mi jak poruszać kwadratem z Joya w Amosie, zajęło to minutę.
W ACE niestety albo stety trzeba tych linijek wklepać kilka-kilkanaście więcej żeby zacząć z tym kwadratem, a wcześniej przygotować środowisko i wiem, że ten próg wejścia może być na pierwszy rzut oka dla Amosowego wyjadacza trochę odpychający, no i przejście na C, pilnowanie klamerek i średników, wiem, byłem tam (nadal tam jestem ;) ).
Ale nadal będę robić reklamę bo uważam, że warto :)
Ostatnia aktualizacja: 29.11.2022 19:22:46 przez Lucus
Tak samo Quad dawno temu wytłumaczył mi jak poruszać kwadratem z Joya w Amosie, zajęło to minutę.
W ACE niestety albo stety trzeba tych linijek wklepać kilka-kilkanaście więcej żeby zacząć z tym kwadratem, a wcześniej przygotować środowisko i wiem, że ten próg wejścia może być na pierwszy rzut oka dla Amosowego wyjadacza trochę odpychający, no i przejście na C, pilnowanie klamerek i średników, wiem, byłem tam (nadal tam jestem ;) ).
Ale nadal będę robić reklamę bo uważam, że warto :)
Ostatnia aktualizacja: 29.11.2022 19:22:46 przez Lucus
29.11.2022 19:35
[#11]
Re: automaty skończone
@Lucus, post #10
No na miły buk !!!
Zeby programowac w C trzeba miec juz spore pojecie o Basicu... normalna sciezka powinna wygladac tak
start -> schemat blokowy -> BASIC -> PASCAL -> inne jezyki wysokiego poziomu... -> C++ -> C -> .... a na koncu, tylko dla orlow Assembler -> "End of Line"
Jak ktos zaczyna przygode z rajdami od WRC chociaz rowerem za bardzo nie ogarnia, to konczy w rowie na pierwszym zakrecie...
i tak jest wlasnie z ludzmi z PPA co zaczynaja programowanie w C i to jeszcze na Amidze... gdzie kazda pojedyncza instrukcja ma wplyw na powolnosc dzialania.
...no co za uparte posły
Zeby programowac w C trzeba miec juz spore pojecie o Basicu... normalna sciezka powinna wygladac tak
start -> schemat blokowy -> BASIC -> PASCAL -> inne jezyki wysokiego poziomu... -> C++ -> C -> .... a na koncu, tylko dla orlow Assembler -> "End of Line"
Jak ktos zaczyna przygode z rajdami od WRC chociaz rowerem za bardzo nie ogarnia, to konczy w rowie na pierwszym zakrecie...
i tak jest wlasnie z ludzmi z PPA co zaczynaja programowanie w C i to jeszcze na Amidze... gdzie kazda pojedyncza instrukcja ma wplyw na powolnosc dzialania.
...no co za uparte posły
29.11.2022 20:32
[#12]
Re: automaty skończone
@selur, post #11
w basicu po raz pierwszy pisałem jakieś 5 lat temu. Zaczynałem od pascala, potem C i tak mi zostało. Nie trzeba zaczynać od aż takiej podłogi. ;)
ale tak, zdecydowanie łatwiej jest uczyć się programowania na czymś szybszym i potem się downgrade'ować jak się nabierze wprawy, co by nabrać pokory do swojego fachu i swoich umiejętności.
Ostatnia aktualizacja: 29.11.2022 20:33:32 przez teh_KaiN
ale tak, zdecydowanie łatwiej jest uczyć się programowania na czymś szybszym i potem się downgrade'ować jak się nabierze wprawy, co by nabrać pokory do swojego fachu i swoich umiejętności.
Ostatnia aktualizacja: 29.11.2022 20:33:32 przez teh_KaiN
29.11.2022 20:39
[#13]
Re: automaty skończone
@selur, post #11
W dawnych czasach ludzie często zaczynali od kodu maszynowego nawet nie od asemblera. I walili prosto po rejestrach.
Ja zaczynałem od Basica na C64, ale szybko było widać, że prędkość nie taka i uczyłem się asemblera. A później na Amidze zacząłem od asemblera (nauczenie się go i arch Amigi nie jest łatwe, ale zrobienie czegoś sensownego jest bardzo trudne), a dopiero na PC na studiach C++ (Cpp nie jest łatwy, C jest o niebo łatwiejszy). I w tedy na pierwszym roku trzeba było ogarniać wszystkie rzeczy z C++98, żeby zaliczyć rok (50% studentów na początku odpadało z maty, a później z tych co przetrwali do końca roku 30% na programowaniu).
Dzisiaj żeby się nauczyć C, jest pełno kursów, tutoriali, youtubów, jest naprawdę prosto. Ale żeby przejść na Amigę, to trzeba wiedzieć, że będzie pod górkę, bo trzeba znaleźć informacje o systemie i wywołaniach, albo walić po rejestrach.
C z pomocą kogoś ogarniętego można na spokojnie ogarnąć w 7 dni po 3h dziennie.
Reszta na Amidze, będzie o wiele trudniejsza.
Ostatnia aktualizacja: 29.11.2022 20:48:38 przez flops
Ja zaczynałem od Basica na C64, ale szybko było widać, że prędkość nie taka i uczyłem się asemblera. A później na Amidze zacząłem od asemblera (nauczenie się go i arch Amigi nie jest łatwe, ale zrobienie czegoś sensownego jest bardzo trudne), a dopiero na PC na studiach C++ (Cpp nie jest łatwy, C jest o niebo łatwiejszy). I w tedy na pierwszym roku trzeba było ogarniać wszystkie rzeczy z C++98, żeby zaliczyć rok (50% studentów na początku odpadało z maty, a później z tych co przetrwali do końca roku 30% na programowaniu).
Dzisiaj żeby się nauczyć C, jest pełno kursów, tutoriali, youtubów, jest naprawdę prosto. Ale żeby przejść na Amigę, to trzeba wiedzieć, że będzie pod górkę, bo trzeba znaleźć informacje o systemie i wywołaniach, albo walić po rejestrach.
C z pomocą kogoś ogarniętego można na spokojnie ogarnąć w 7 dni po 3h dziennie.
Reszta na Amidze, będzie o wiele trudniejsza.
Ostatnia aktualizacja: 29.11.2022 20:48:38 przez flops
29.11.2022 20:47
[#14]
Re: automaty skończone
@teh_KaiN, post #12
Jak ktos jest naprawde dobry w te klocki, to moze zaczynac odrazu od C++... ale to moze jest z 10% wszystkich programistow.
Natomiast przytlaczajaca wiekszosc powinna zaczynac od "plaskiej Ziemi" a pozniej konstruowac latawce z kartonu przed tym, zanim wyleca na misje kosmiczne.
A tutaj jak zawsze, astronauci PPA leca na hipernowoczesnych drzwiach od stodly na Marsa... misja skolonizowania czerwonej planety, na pewno sie uda
a jesli klamie (nie daj buk) albo oczerniam kogos, to niechaj ktorys rzuci mnie jakims extra-softem w łep, ktory powstal w ostatnie 10 lat, bo albo slepy i gluchy jestem albo wszyscy imprezuja za moimi plecami
Natomiast przytlaczajaca wiekszosc powinna zaczynac od "plaskiej Ziemi" a pozniej konstruowac latawce z kartonu przed tym, zanim wyleca na misje kosmiczne.
A tutaj jak zawsze, astronauci PPA leca na hipernowoczesnych drzwiach od stodly na Marsa... misja skolonizowania czerwonej planety, na pewno sie uda
a jesli klamie (nie daj buk) albo oczerniam kogos, to niechaj ktorys rzuci mnie jakims extra-softem w łep, ktory powstal w ostatnie 10 lat, bo albo slepy i gluchy jestem albo wszyscy imprezuja za moimi plecami
29.11.2022 20:55
[#15]
Re: automaty skończone
@flops, post #13
W dawnych czasach ludzie często zaczynali od kodu maszynowego nawet nie od asemblera. I walili prosto po rejestrach
To tylko Mit !
Wpisywanie poke'ow do gier, nie mialo nic wspolnego z nauka assemblera. Np. wsrod moich znajomych z kilkudziesieciu osob zaden nie zaczynal od assemblera, ba assembler to byla czarna magia.
C z pomocą kogoś ogarniętego można na spokojnie ogarnąć w 7 dni po 3h dziennie.
Sorry, Majster ale ty nie masz zielonego pojecia o czym piszesz... 7 dni i nocy to taka gra byla
29.11.2022 21:00
[#16]
Re: automaty skończone
@selur, post #15
Samo C jako język jest bardzo proste - naście słów kluczowych w języku, parę zasad i konceptów na krzyż... Najtrudniejsze jest przestawienie mózgu tak żeby umieć coś z tego ulepić i co rusz nie strzelać sobie w stopę. A tu niestety trzeba przebrnąć przez nudne programy w konsoli zanim zacznie się biegać i nie crashować komputera na każdym kroku. ;)
29.11.2022 21:20
[#18]
Re: automaty skończone
@selur, post #11
Nie jestem pewien jak Ci odpisać przez wzgląd na szacun jaki masz u mnie za wszelką pomoc przy Amosie, ale spróbuję - jimiche ma o Amosie dużo pojęcia, ma opór przed wdepnięciem w C (ACE). Zasadniczo moim zdaniem jeśli dobrze zasetupować podstawy, to są pewne analogie, bo co za różnica podać parametry do Bar czy do blitRect()... (i nie chodzi mi o technikalia, tylko o sam sposób użycia).
I wydaje mi się, że fajnie gdyby choćby spróbował.
A to co trzeba, kto jak zaczyna to już inna sprawa. Nadal jestem noobem w programowanie, ale jakbym nie przeszedł na C to bym nie miał swojego krapa, a tak to chociaż go mam, taki uparty posioł.
Ostatnia aktualizacja: 29.11.2022 21:23:17 przez Lucus
I wydaje mi się, że fajnie gdyby choćby spróbował.
A to co trzeba, kto jak zaczyna to już inna sprawa. Nadal jestem noobem w programowanie, ale jakbym nie przeszedł na C to bym nie miał swojego krapa, a tak to chociaż go mam, taki uparty posioł.
Ostatnia aktualizacja: 29.11.2022 21:23:17 przez Lucus
29.11.2022 21:20
[#19]
Re: automaty skończone
@selur, post #15
To nie jest mit, zanim powstał assembler (nazwy instrukcji istniały wcześniej) ludzie musieli jakoś pisać programy, ludzie z ery C64, którzy w latach dzieciństwa próbowali zgłębić tajemnice komputera też często zaczynali od kombinowania bezpośrednio na pamięci za pomocą jakiegoś monitora kodu maszynowego, Dekompozytor zrobił jakiś zalążek gry w ten sposób w czasach swojego dzieciństwa. Widziałem też metodę na używanie kodu maszynowego razem z Basiciem na C64, tylko nie pamiętam w którym filmie to było (kanał 8-bit Show And Tell). Były nawet książki dotyczące pisania w języku maszynowym jak "Machine Language" Jima Butterfielda. Każdy większy programik do przepisywania z gazetek w postaci listingu, to tak naprawdę kod maszynowy, który mieścił się w dużych sekcjach zaczynających się od DATA, Basic tylko wpisywał te wartości do pamięci i robił skok na początek programu (SYS XXXXX).
29.11.2022 21:25
[#20]
Re: automaty skończone
@selur, post #17
Powiedzmy że samo C może i nie jest skomplikowane. Skomplikowane jest pisanie w nim sensownych programów, czy to bezpośrednio po rejestrach, czy to używając systemu. Takie najprostsze załadowanie i wyświetlenie najprostszego obrazka IFF w takim AMOsie to może ze 2-3 linijki czytelnego kodu jest. No to nawet jakby korzystać z gotowej biblioteki dekodującej IFFy to kodu będzie wiecej, i to mniej czytelnego. Dlatego wszelkie odmiany Basica są dobre do nauki jak generalnie programowanie działa. Poźniej można się coraz bardziej wgryzać w szczegóły i zmieniać jezyki, aż do assemblera.
Ostatnia aktualizacja: 29.11.2022 21:27:45 przez pisklak
Ostatnia aktualizacja: 29.11.2022 21:27:45 przez pisklak
29.11.2022 21:32
[#21]
Re: automaty skończone
@selur, post #17
No dla ludzi ktorzy siedza w tym od czasow Wielkiego Wybuchu, to wrecz banalnie proste, niewatpie
Ja w tym nie siedzę i jak tknę to raz na rok, to jest dużo i mogę potwierdzić te słowa, że sam język nie jest trudny, ale w przeciwieństwie do języków, które robią większość za ciebie pojawia się problem, bo dostajesz garstkę narzędzi i sam musisz sobie wszystko zbudować. Tu nie wydajesz rozkazu, by została narysowana głowa, tylko musisz opisać jak ona ma być narysowana albo zrobić funkcję, która będzie to robić. Większość z problemów nie wynika z zrozumienia samego języka, tylko jak z poruszania się po sprzęcie i tak, kodu doświadczonego programisty na bank nie zrozumiesz, ale swoje dzieło to inna sprawa.
Czy w ogóle próbowałeś C, czy tylko rzuciłeś na niego okiem i wydałeś wyrok?
Ostatnia aktualizacja: 29.11.2022 21:33:02 przez san_u
29.11.2022 21:54
[#22]
Re: automaty skończone
@Lucus, post #18
bo co za różnica podać parametry do Bar czy do blitRect()...
Podać parametry nie, choć jest to troszkę bardziej zawiłe, ale jeśli chcesz pisać grę, to musisz sobie taką funkcję jeżdżącą po rejestrach sam napisać, bo te systemowe, to nadają się z swoją wydajnością jedynie do programów użytkowych.
ACE jest dość zaawansowanym środowiskiem, laicy tacy jak ja używający C od święta mają problem z poruszaniem się po nim. W C potrzebna jest także jakaś wiedza o rejestrach chipsetu, zwłaszcza blittera, znacznie ułatwia zrozumienie, co dany kod tak naprawdę robi.
Kiedyś czytałem, że autorzy gry Verge Worlds używali fragmentów ACE.
Tak, przydałby się samouczek do ACE, ale ktoś musiałby zapłacić za to autorowi, przygotowanie odpowiednich materiałów edukacyjnych, to nie jest kwestia jednego wieczoru. Może autor kiedyś napisze książkę o swoim środowisku XD. Poza tym, ACE, to narzędzie, z którego trzeba umieć korzystać, nie musisz go używać, tak naprawdę polecam na początek pobawienie się językiem i stworzenie czegokolwiek, co rysuje i manipuluje grafiką na ekranie, by oswoić się ze sprzętem, a gwarantuję, że już przy samym konfigurowaniu ekranu po ubiciu systemu, będziesz się drapał w głowę i głośno zadawał pytania "dlaczego", to nie jest sprawka języka C, tylko specyfikacja sprzętu - przechodzisz z autopilota na sterowanie ręczne. Będziesz się musiał zaznajomić z bitplanami i jak nimi się posługiwać, narysowanie jednego piksela nie będzie już takie proste, dużo trzeba myśleć o optymalizacji, np. podglądać też wyniki kompilatora w asemblerze. To nowy świat, nie żebym odradzał, po prostu nie od razu na głęboką wodę, bo szukanie bugów potrafi się odbić na psychice :)
Ostatnia aktualizacja: 29.11.2022 21:56:27 przez san_u
29.11.2022 22:06
[#24]
Re: automaty skończone
@san_u, post #22
Może funkcje systemowe do demonów prędkości nie należą, ale sam AOS jest na tyle elastyczny że można chyba dość dobrze pogodzić swoje funkcje (w C lub ASM tam gdzie jest potrzebna maksymalna szybkość) z systemem, tak żeby nic nie wybuchło. No ale większość ludzi ogarniającą już lepiej chipset amigowy i tak chyba po prostu freezuje system. Da się napisać szybki i systemowo dobrze działający kod - czego dowodzą nieliczne dema 
29.11.2022 22:44
[#27]
Re: automaty skończone
@pisklak, post #24
Na mocnych Amigach oczywiście, ale na OCS/ECS to jest już prawdziwe wyzwanie i te gry, które działają pod systemem, raczej do dynamicznych nie należą, no ale do takich gier jak Simcity czy Magazyn :) to ok.
Zastanawiam się, czy gry na CD32 działają cały czas pod systemem, czy wracają do niego tylko podczas ładowania i na krótką chwilę, by włączyć jakąś ścieżkę audio.
Zastanawiam się, czy gry na CD32 działają cały czas pod systemem, czy wracają do niego tylko podczas ładowania i na krótką chwilę, by włączyć jakąś ścieżkę audio.
29.11.2022 22:59
[#29]
Re: automaty skończone
@selur, post #26
Trochę przesada z tymi wojownikami 
, nikt tu akurat o wyższości jednego koloru nad drugim nie rozmawia "kulturalnie", Cahir jeszcze programuje w C, na którymś Amiparty bodajże opisywał jakieś triki optymalizacyjne w C i zrobił mini intro przy publiczności, kiedyś jeszcze strim się udzielał.
Ostatnia aktualizacja: 29.11.2022 23:00:11 przez san_u
, nikt tu akurat o wyższości jednego koloru nad drugim nie rozmawia "kulturalnie", Cahir jeszcze programuje w C, na którymś Amiparty bodajże opisywał jakieś triki optymalizacyjne w C i zrobił mini intro przy publiczności, kiedyś jeszcze strim się udzielał.Ostatnia aktualizacja: 29.11.2022 23:00:11 przez san_u
29.11.2022 23:51
[#30]
Re: automaty skończone
@san_u, post #29
Chodzi mi raczej o te zawojowanie ami-gamedevu a nie o wojny tubylcze ( takie jak notorycznie czerwoni vs niebiescy o skore po padnietym, schorowanym niedzwiedziu).
Zastanawia mnie to, dlaczego u nas jest ciagle tak, ze ci co znaja dobrze np. wlasnie te C/++ (no a przesz jest tu troche tego ludu) nie korzystaja wlasnie z tego Kainowego ACzE (wybielacza nad wybielacze
) tylko dopiero co zmobilizowani poborowi, chwytaja za bron..
No i ogolnie wszystko u nas jest na odwrot i amigowy gamedev rozwija sie i rozwinac nie moze... (oczywiscie nie mowie tu o KukluxKlanie (KK) czy nabiale (Kefir), ktorzy godnie walcza i dobre imie klasyka).
Zastanawia mnie to, dlaczego u nas jest ciagle tak, ze ci co znaja dobrze np. wlasnie te C/++ (no a przesz jest tu troche tego ludu) nie korzystaja wlasnie z tego Kainowego ACzE (wybielacza nad wybielacze
) tylko dopiero co zmobilizowani poborowi, chwytaja za bron.. No i ogolnie wszystko u nas jest na odwrot i amigowy gamedev rozwija sie i rozwinac nie moze... (oczywiscie nie mowie tu o KukluxKlanie (KK) czy nabiale (Kefir), ktorzy godnie walcza i dobre imie klasyka).