05.10.2016 00:06
[#122]
Re: Zapowiedzi nowych gier
@DiskDoctor, post #121
No i zacząłem rok "zmagań akademickich". Zaczęło się dość dobrze, ale straci na tym odrobinę moja praca przy projekcie. Myślę o nim cały czas i przez ostatnie dni porządkowałem sobie katalogi na mojej Amidze 1200, tak by kontynuować pracę w wygodniejszych warunkach.
Będę działać co dzień na zasadzie projektuję - piszę - dokumentuję. I to w tej kolejności. Mam nadzieję, że uporządkuje to moją pracę i kolejne niezbędne elementy, jak diagram klas oraz wreszcie kod programu powstanie szybciej.
Pamiętajcie, zgodnie z założeniem na początku listopada opublikuję bieżący rezultat pracy i mam nadzieję, że będzie to grywalne preview. Szykują się 4 pracowite weekendy...
Ostatnia aktualizacja: 05.10.2016 00:10:31 przez Hexmage960
Będę działać co dzień na zasadzie projektuję - piszę - dokumentuję. I to w tej kolejności. Mam nadzieję, że uporządkuje to moją pracę i kolejne niezbędne elementy, jak diagram klas oraz wreszcie kod programu powstanie szybciej.
Pamiętajcie, zgodnie z założeniem na początku listopada opublikuję bieżący rezultat pracy i mam nadzieję, że będzie to grywalne preview. Szykują się 4 pracowite weekendy...
Ostatnia aktualizacja: 05.10.2016 00:10:31 przez Hexmage960
10.10.2016 11:14
[#124]
Re: Zapowiedzi nowych gier
@snajper, post #123
Pierwsze linijki kodu już zostały postawione.
Zająłem się funkcjami systemowymi do ładowania obrazków IFF, oraz do wyświetlania własnego obrazu.
Używam iffparse.library oraz graphics.library. Obraz jest tworzony za pomocą systemowych View z graphics.library. Uznałem, że tak gra będzie działać szybciej niż za pomocą ekranu systemowego z intuition.library.
Obecnie program działa tak:
Z systemowych rzeczy zostało: przejęcie sygnałów z myszy i klawiatury za pomocą input.device, obsługa przerwań i timer.device (dźwięki i muzyka będzie dodana za pomocą audio.device nieco później).
Następnie zabiorę się za stworzenie prostego interfejsu użytkownika. Obszar ekranu będzie podzielony na pola (np. 20x20) i każdemu polu będzie mógł być przypisany przycisk. W ten sposób łatwo sprawdzać, nad którym przyciskiem lub polem mapy znajduje się wskaźnik myszy.
Do tego system komunikatów. Jak to ukończę pozostanie kodowanie podstaw logiki gry i wydanie grywalnego preview.
Mimo, że piszę pod system, ze względu na użyte biblioteki i rozwiązania gra będzie działać na Amidze 1200/4000/CD32 i systemie w wersji 3.0. Inne systemy nie są uwzględniane. Do rozważenia tylko działanie na Amidze 500/600 i pozostałych. Użytkownicy AmigaOS4, czy MorphOS i tak mają dużo portów różnych gier, więc myślę, że nie poczują się zawiedzeni. Na Amigę "classic" brakuje nowych gier RTS.
Ostatnia aktualizacja: 10.10.2016 11:15:54 przez Hexmage960
Zająłem się funkcjami systemowymi do ładowania obrazków IFF, oraz do wyświetlania własnego obrazu.
Używam iffparse.library oraz graphics.library. Obraz jest tworzony za pomocą systemowych View z graphics.library. Uznałem, że tak gra będzie działać szybciej niż za pomocą ekranu systemowego z intuition.library.
Obecnie program działa tak:
- Czytany jest obrazek z pliku IFF
- Alokowana jest bitmapa ekranu
- Obrazek jest kopiowany na tą bitmapę
- Alokowana jest mapa kolorów
- Ładowana jest paleta obrazka do tej mapy kolorów
- Własny obraz jest wyświetlany przedstawiając pierwszy obrazek
Z systemowych rzeczy zostało: przejęcie sygnałów z myszy i klawiatury za pomocą input.device, obsługa przerwań i timer.device (dźwięki i muzyka będzie dodana za pomocą audio.device nieco później).
Następnie zabiorę się za stworzenie prostego interfejsu użytkownika. Obszar ekranu będzie podzielony na pola (np. 20x20) i każdemu polu będzie mógł być przypisany przycisk. W ten sposób łatwo sprawdzać, nad którym przyciskiem lub polem mapy znajduje się wskaźnik myszy.
Do tego system komunikatów. Jak to ukończę pozostanie kodowanie podstaw logiki gry i wydanie grywalnego preview.
Mimo, że piszę pod system, ze względu na użyte biblioteki i rozwiązania gra będzie działać na Amidze 1200/4000/CD32 i systemie w wersji 3.0. Inne systemy nie są uwzględniane. Do rozważenia tylko działanie na Amidze 500/600 i pozostałych. Użytkownicy AmigaOS4, czy MorphOS i tak mają dużo portów różnych gier, więc myślę, że nie poczują się zawiedzeni. Na Amigę "classic" brakuje nowych gier RTS.
Ostatnia aktualizacja: 10.10.2016 11:15:54 przez Hexmage960
10.10.2016 13:48
[#126]
Re: Zapowiedzi nowych gier
@Hexmage960, post #124
To jako że nikt jeszcze nie narzeka to ja ponarzekam i będę pierwszy.
Pisze się "tę bitmapę". Zawsze w parze ogonki idą. ;)
A teraz na poważnie, pola 20x20. Nie chcesz mieć przycisków obok siebie bez martwych stref między nimi, bo to prowadzi w prostej linii do złych kliknięć i frustracji. Także pola 20x20 na HUDzie może i tak, ale ich wewnętrzne aktywne pole zrób np. 16x16.
Co do OSu to widzę że się nie rozdrabniasz i w sumie dobrze, szybciej uzyskasz jakiekolwiek rezultaty niż ja, hyhy. Zawsze kompatybilność wstecz będziesz mógł dorobić później.
Obrazek jest kopiowany na tą bitmapę
Pisze się "tę bitmapę". Zawsze w parze ogonki idą. ;)
A teraz na poważnie, pola 20x20. Nie chcesz mieć przycisków obok siebie bez martwych stref między nimi, bo to prowadzi w prostej linii do złych kliknięć i frustracji. Także pola 20x20 na HUDzie może i tak, ale ich wewnętrzne aktywne pole zrób np. 16x16.
Co do OSu to widzę że się nie rozdrabniasz i w sumie dobrze, szybciej uzyskasz jakiekolwiek rezultaty niż ja, hyhy. Zawsze kompatybilność wstecz będziesz mógł dorobić później.
10.10.2016 15:29
[#127]
Re: Zapowiedzi nowych gier
@teh_KaiN, post #126
A teraz na poważnie, pola 20x20. Nie chcesz mieć przycisków obok siebie bez martwych stref między nimi, bo to prowadzi w prostej linii do złych kliknięć i frustracji. Także pola 20x20 na HUDzie może i tak, ale ich wewnętrzne aktywne pole zrób np. 16x16.
Słusznie.
Napisałem 20x20, bo takie rozmiary mają kafelki składowe mapy w grafice z gry Hard Vacuum. Więc obszar mapy będzie podzielony na takie pola.
Zaś w panelu dowodzenia jak najbardziej przerwy pomiędzy przyciskami muszą być. Zresztą w tej paczce z grafiką są gotowe guziki przycisków oraz HUD (nie liczyłem jeszcze ich rozmiaru).
Co do OSu to widzę że się nie rozdrabniasz i w sumie dobrze, szybciej uzyskasz jakiekolwiek rezultaty niż ja, hyhy. Zawsze kompatybilność wstecz będziesz mógł dorobić później.
Jest szereg funkcji, do których działania nie potrzeba szybkości. Zazwyczaj są to takie funkcje, które wymagają z kolei dużej funkcjonalności. Żeby nie tracić na funkcjonalności korzystam z rozwiązań, które zapewnią mi łatwiejszą realizację skomplikowanych rzeczy, takich jak np. wyświetlanie obrazu.
Przecież do czytania IFFów mógłbym użyć własnych procedur. Ale używam iffparse.library, bo ten w znakomity sposób upraszcza to zadanie.
Systemowe View są najniższym interfejsem systemowym do obrazu i na A1200 sprawuje się bardzo dobrze, więc podejrzewam, że na A500/600 nie byłoby dużej straty.
Ustawianie samodzielne Coppera da się robić ale ja jestem już przyzwyczajony korzystać z dobrodziejstw OSu od samego początku mojego kodowania na Amidze.
Do timingu użyję własnych serwerów przerwań CPU i timer.device, więc o prędkość wykonywania zadań w odpowiednim czasie nie będę się zamartwiał. Również tak samo gra zadziała na A500 jak i A1200.
Oczywiście same serwery przerwań piszę w asemblerze. I to nie tylko dlatego, by były krótkie i szybkie, ale też dlatego, że standard języka C nie zapewnia odpowiedniego ustawienia znaczników procesora.
Zalet korzystania w niektórych miejscach z OSu jest naprawdę wiele. Jeśli chcesz postawić tylko na rozwiązania sprzętowe, musisz być zdeterminowany.
Pamiętaj też, że OS nie korzysta aż tak bardzo z czasu procesora, ani z chipsetu, po przejęciu View i input.device masz warunki niemal zbliżone do tego jakby systemu w ogóle nie było. A możesz w każdej chwili przełączać między OS i swoją grą i multitasking cały czas działa.
Na koniec uważam, że taki styl programowania, przyjazny OS i przyjazny użytkownikowi jest po prostu fajny.
Życzę Ci powodzenia również w Twoim projekcie i mam nadzieję, że ujrzysz efekt swojej pracy jak najszybciej.
22.10.2016 08:26
[#129]
Re: Zapowiedzi nowych gier
@Hexmage960, post #127
Minniat, masz tu poniżej ciekawy film - jak tylko MDW wrzucił go na swojego wall'a natychmiat pomyślałem o Tobie.
Gość pisze kod gry 3d, na bieżąco wyświetla efekty swojej pracy i to komentuje.
Może Ci się na coś przyda?
tworzenie engine gry w czasie rzeczywistym
Gość pisze kod gry 3d, na bieżąco wyświetla efekty swojej pracy i to komentuje.
Może Ci się na coś przyda?
tworzenie engine gry w czasie rzeczywistym
22.10.2016 13:11
[#130]
Re: Zapowiedzi nowych gier
@michalmarek77, post #129
Dzięki za link do tego materiału - bardzo interesujący.
Ja powoli wygrywam walkę z chorobą (a raczej leki wygrywają).
Dzisiaj minęła bardzo przykra dolegliwość.
Nad Fortecą powoli pracuję. Dzisiaj napisałem konfigurowalne wideo, co oznacza, że będzie program konfiguracyjny, w którym będzie się wybierało sposób wyświetlania - ekran systemowy lub View systemowe.
Zatem użytkownicy Amig 1200 będą mogli sobie wybrać View systemowe ze względu na prędkość działania, a użytkownicy kart graficznych będą mogli wybrać ekran systemowy.
Adekwatnie do sposobu wyświetlania obrazu wideo obsługiwana jest klawiatura i mysz - albo za pomocą systemowego okienka typu backdrop w przypadku ekranu systemowego, albo za pomocą input.device w przypadku View.
Ładnie to działa.
Oczywiście rendering będzie również konfigurowalny - albo za pomocą Blittera i CPU, albo za pomocą funkcji systemowych.
Zatem program będzie nowocześnie napisany i powinien ładnie chodzić pod różnymi konfiguracjami.
Moje zdrowie się poprawia w ostatnie dni bardzo szybko. Jakość pracy jest podyktowana przez to zdrowie. Przecież ja wszystko kasowałem co napisałem, dlatego nic nie mogłem posuwać do przodu.
To nie był ani słomiany zapał ani znudzenie projektem, tylko choroba, która powodowała, że nic nie mogłem porządnie zacząć, a co dopiero skończyć.
Obiecałem w zeszły weekend, że pokażę menu. Postaram się w ten weekend go zrobić. To plan minimum.
Chciałbym przypomnieć, że Wasze wsparcie się obok zdrowia również bardzo liczy. Dziękuję Wam serdecznie za dotychczasowy doping.
Ostatnia aktualizacja: 22.10.2016 13:12:50 przez Hexmage960
Ja powoli wygrywam walkę z chorobą (a raczej leki wygrywają).
Dzisiaj minęła bardzo przykra dolegliwość.Nad Fortecą powoli pracuję. Dzisiaj napisałem konfigurowalne wideo, co oznacza, że będzie program konfiguracyjny, w którym będzie się wybierało sposób wyświetlania - ekran systemowy lub View systemowe.
Zatem użytkownicy Amig 1200 będą mogli sobie wybrać View systemowe ze względu na prędkość działania, a użytkownicy kart graficznych będą mogli wybrać ekran systemowy.
Adekwatnie do sposobu wyświetlania obrazu wideo obsługiwana jest klawiatura i mysz - albo za pomocą systemowego okienka typu backdrop w przypadku ekranu systemowego, albo za pomocą input.device w przypadku View.
Ładnie to działa.
Oczywiście rendering będzie również konfigurowalny - albo za pomocą Blittera i CPU, albo za pomocą funkcji systemowych.
Zatem program będzie nowocześnie napisany i powinien ładnie chodzić pod różnymi konfiguracjami.
Moje zdrowie się poprawia w ostatnie dni bardzo szybko. Jakość pracy jest podyktowana przez to zdrowie. Przecież ja wszystko kasowałem co napisałem, dlatego nic nie mogłem posuwać do przodu.
To nie był ani słomiany zapał ani znudzenie projektem, tylko choroba, która powodowała, że nic nie mogłem porządnie zacząć, a co dopiero skończyć.
Obiecałem w zeszły weekend, że pokażę menu. Postaram się w ten weekend go zrobić. To plan minimum.
Chciałbym przypomnieć, że Wasze wsparcie się obok zdrowia również bardzo liczy. Dziękuję Wam serdecznie za dotychczasowy doping.
Ostatnia aktualizacja: 22.10.2016 13:12:50 przez Hexmage960
22.10.2016 15:08
[#132]
Re: Zapowiedzi nowych gier
@Hexmage960, post #130
"Pospiech jest wskazany przy lapaniu pchel" ,wiec nie spiesz sie.Powoli ale mozliwie konsekwentnie posuwaj kod do przodu.Co do kasowania to sam to nagminnie robie z rzeczami z ktorych nie jestem zadowolony.I nie szkoda mi wywalac do kosza bo co sie przy tym nauczylem to moje
23.10.2016 09:46
[#133]
Re: Zapowiedzi nowych gier
@Hexmage960, post #130
Jak na view przechwytujesz input.device'em i w tle masz odpaloną konsolę, to nie reaguje ona na wciski klawiatury? Tak samo mysz - rzeczy 'za' viewem nie reagują na kliki?
Miałem taki przypadek jak korzystałem z intuition - poradziłem sobie ostatecznie tworząc screena na cały ekran, na nim okno na cały ekran i to ono przechwytywało kliknięcia i przyciski. Rozwiązanie beznadziejne, ale działało.
Jeśli wszystko u Ciebie ok to chyba sam przejdę na input.device i wywalę kod intuition, bo mnie wkurza. ;)
Miałem taki przypadek jak korzystałem z intuition - poradziłem sobie ostatecznie tworząc screena na cały ekran, na nim okno na cały ekran i to ono przechwytywało kliknięcia i przyciski. Rozwiązanie beznadziejne, ale działało.
Jeśli wszystko u Ciebie ok to chyba sam przejdę na input.device i wywalę kod intuition, bo mnie wkurza. ;)
23.10.2016 11:11
[#134]
Re: Zapowiedzi nowych gier
@teh_KaiN, post #133
Jak na view przechwytujesz input.device'em i w tle masz odpaloną konsolę, to nie reaguje ona na wciski klawiatury? Tak samo mysz - rzeczy 'za' viewem nie reagują na kliki?
Instalujesz handler input.device z wysokim priorytetem, zaś swój handler piszesz tak, by zwracał wartość NULL. Wtedy niższe handlery (w tym intuition) nie są wykonywane.
23.10.2016 11:32
[#135]
Re: Zapowiedzi nowych gier
@teh_KaiN, post #133
poradziłem sobie ostatecznie tworząc screena na cały ekran, na nim okno na cały ekran i to ono przechwytywało kliknięcia i przyciski. Rozwiązanie beznadziejne, ale działało.
Czemu to rozwiązanie beznadziejne ?
A propos input.device handlera, to raczej będziesz musiał napisać go w asemblerze. Przykład link
23.10.2016 12:06
[#136]
Re: Zapowiedzi nowych gier
@asman, post #135
VBCC ma specjalne atrybuty do handlerów przerwań amigowych, więc pewnie do device handlera też.
A beznadziejne, bo ma w sobie nutkę hackfixu no i i tak otwieram swoje viewy, więc po co mi dodatkowy systemy view, który tworzy się razem ze screenem i nie jest wyświetlany, tylko niepotrzebnie miejsce zajmuje jego bitmapa. Co prawda ograniczam footprint w RAMie do minimum tworząc go na 1bpp, ale i tak sporo RAMu idzie na nic.
A wykorzystanie viewa z systemowego screena odpada, bo mam totalnie swoje niesystemowe viewy, a nawet jak bym nie miał to workflow w kodzie mam taki, że na potrzeby każdego stanu gry tworzony i niszczony jest oddzielny view.
A beznadziejne, bo ma w sobie nutkę hackfixu no i i tak otwieram swoje viewy, więc po co mi dodatkowy systemy view, który tworzy się razem ze screenem i nie jest wyświetlany, tylko niepotrzebnie miejsce zajmuje jego bitmapa. Co prawda ograniczam footprint w RAMie do minimum tworząc go na 1bpp, ale i tak sporo RAMu idzie na nic.
A wykorzystanie viewa z systemowego screena odpada, bo mam totalnie swoje niesystemowe viewy, a nawet jak bym nie miał to workflow w kodzie mam taki, że na potrzeby każdego stanu gry tworzony i niszczony jest oddzielny view.
23.10.2016 14:06
[#137]
Re: Zapowiedzi nowych gier
@asman, post #135
Handler do input.device można napisać w C, ale zalecany jest asembler, bo ta procedura powinna być krótka i szybka.
Handler input.device to nie jest jak obsługa przerwania. Można więc też alokować w nim pamięć. Ja w swoim alokuję pamięć i robię PutMsg(), dla każdej interesującej mnie wiadomości. Następnie pobieram te wiadomości i zwalniam pamięć w moim programie głównym.
W przypadku obsługi przerwania ważne jest by zapalić lub gasić znacznik Z procesora przy wychodzeniu, więc asembler jest już konieczny (chyba, że standard kompilatora C to zapewnia).
Handler input.device to nie jest jak obsługa przerwania. Można więc też alokować w nim pamięć. Ja w swoim alokuję pamięć i robię PutMsg(), dla każdej interesującej mnie wiadomości. Następnie pobieram te wiadomości i zwalniam pamięć w moim programie głównym.
W przypadku obsługi przerwania ważne jest by zapalić lub gasić znacznik Z procesora przy wychodzeniu, więc asembler jest już konieczny (chyba, że standard kompilatora C to zapewnia).
23.10.2016 17:33
[#138]
Re: Zapowiedzi nowych gier
@twardy, post #131
Dość interesujący pomysł z tym udostępnianiem kodu. Wrzuciłem zatem efekt dwudniowej pracy na serwer w formie listingu asemblera. A ze swojej strony internetowej nie mam zwyczaju niczego kasować (muszę tylko pamiętać o odnowieniu abonamentu).
Tutaj link do tego kodu: INIT.S
Co robi ten kawałek kodu?
- Przejmuje wyświetlanie obrazu za pomocą funkcji z graphics.library (tzw. własne View),
- Przejmuje kontrolę nad myszą i klawiaturą za pomocą input.device i informuje program o ich statusie (przesyła wiadomości).
Wszystko działa elegancko.
Brakuje tylko jednej drobnostki, która nie jest niezbędna, ale ułatwi życie, mianowicie stałych symbolicznych reprezentujących budowę wiadomości przesyłanej z handlera input.device do programu głównego. A powinno to wyglądać tak:
Zresztą z handlera łatwo to wywnioskować.
Ten kod pisałem wczoraj wieczorem (View) i dzisiaj w południe (input.device). Jest naprawdę staranny i dopracowany. Jeśli ktoś zechce wykorzystać go we własnej produkcji, może to śmiało zrobić. Prosiłbym tylko o skontaktowanie się ze mną w takim przypadku, bym o tym wiedział.
Zatem jadę dalej. Jeszcze sporo pracy przede mną.
Ostatnia aktualizacja: 23.10.2016 17:34:54 przez Hexmage960
Tutaj link do tego kodu: INIT.S
Co robi ten kawałek kodu?
- Przejmuje wyświetlanie obrazu za pomocą funkcji z graphics.library (tzw. własne View),
- Przejmuje kontrolę nad myszą i klawiaturą za pomocą input.device i informuje program o ich statusie (przesyła wiadomości).
Wszystko działa elegancko.
Brakuje tylko jednej drobnostki, która nie jest niezbędna, ale ułatwi życie, mianowicie stałych symbolicznych reprezentujących budowę wiadomości przesyłanej z handlera input.device do programu głównego. A powinno to wyglądać tak:
- ie_Class (byte)
- ie_SubClass (byte)
- ie_Code (word)
- ie_Qualifier (word)
- ie_X (word)
- ie_Y (word)
- rozmiar: 10 bajtów
Zresztą z handlera łatwo to wywnioskować.
Ten kod pisałem wczoraj wieczorem (View) i dzisiaj w południe (input.device). Jest naprawdę staranny i dopracowany. Jeśli ktoś zechce wykorzystać go we własnej produkcji, może to śmiało zrobić. Prosiłbym tylko o skontaktowanie się ze mną w takim przypadku, bym o tym wiedział.
Zatem jadę dalej. Jeszcze sporo pracy przede mną.
Ostatnia aktualizacja: 23.10.2016 17:34:54 przez Hexmage960
23.10.2016 18:19
[#140]
Re: Zapowiedzi nowych gier
@Hexmage960, post #138
@Krashan
Używam dwóch WaitTOF() ponieważ z tego co się orientuję copperlista systemowa jest podwójnie buforowana i jej zamiana zajmuje dwie ramki.
@Wątek
Już wiem, co zrobię w kolejności - mianowicie dodam kolorowy (15 kolorów) wskaźnik myszy, za pomocą funkcji z graphics.library, sprawię że będzie się ruszał wraz z myszą i dodam warstwy do wyświetlanej bitmapy za pomocą biblioteki layers.library.
Taki plan jest jak najbardziej realny do zrobienia w jeden lub góra dwa dni.
Po co warstwy? Otóż przyda się to do przycinania grafiki. Jeśli coś wystaje poza warstwę będzie automatycznie przycinane.
No i może przyda się do jakichś menusów wewnątrz gry.
Generalnie do rysowania będę używał biblioteki graphics (oraz SetWriteMask() celem optymalizacji), w paru miejscach może pokuszę się o własne, szybkie rozwiązania.
Grę piszę w asemblerze.
Używam dwóch WaitTOF() ponieważ z tego co się orientuję copperlista systemowa jest podwójnie buforowana i jej zamiana zajmuje dwie ramki.
@Wątek
Już wiem, co zrobię w kolejności - mianowicie dodam kolorowy (15 kolorów) wskaźnik myszy, za pomocą funkcji z graphics.library, sprawię że będzie się ruszał wraz z myszą i dodam warstwy do wyświetlanej bitmapy za pomocą biblioteki layers.library.
Taki plan jest jak najbardziej realny do zrobienia w jeden lub góra dwa dni.
Po co warstwy? Otóż przyda się to do przycinania grafiki. Jeśli coś wystaje poza warstwę będzie automatycznie przycinane.
No i może przyda się do jakichś menusów wewnątrz gry.
Generalnie do rysowania będę używał biblioteki graphics (oraz SetWriteMask() celem optymalizacji), w paru miejscach może pokuszę się o własne, szybkie rozwiązania.
Grę piszę w asemblerze.
23.10.2016 19:17
[#142]
Re: Zapowiedzi nowych gier
@juen, post #141
Z tym podwójnym buforowaniem copperlisty to dobrze zapamiętałem: Tutaj notka o tym
Ale rzeczywiście wystarczy jeden WaitTOF(). Coś mi się pomyliło. Poprawię to.
Ale rzeczywiście wystarczy jeden WaitTOF(). Coś mi się pomyliło. Poprawię to.
23.10.2016 20:10
[#143]
Re: Zapowiedzi nowych gier
@Hexmage960, post #142
a jednak powinienes uzyc dwoch, tak jak pisalem wyzej odnalazlem teraz jeszcze w pierwszym lepszym tutku:
WaitTOF is called twice in case the system display uses interlaced mode. In interlaced mode the system has two copper lists (odd and even frame) so it might take up to 2 screen draws until our copper list is properly loaded.
WaitTOF is called twice in case the system display uses interlaced mode. In interlaced mode the system has two copper lists (odd and even frame) so it might take up to 2 screen draws until our copper list is properly loaded.
24.10.2016 15:02
[#147]
Re: Zapowiedzi nowych gier
@asman, post #146
Nasz handler zwraca adres eventów do przetworzenia przez handlery o niższym priorytecie. Możemy pobraną listę eventów dowolnie modyfikować, w tym zmieniać zawartość oraz odłączać wybrane eventy z listy.
Możemy też tworzyć zupełnie nowe eventy i dołączać do listy (wtedy trzeba zadbać o zapamiętanie adresów, by później zwolnić pamięć).
Żeby usunąć event (w sensie by nie był przetwarzany przez niższe handlery) wystarczy odłączyć go od listy eventów zwracanej przez nasz handler.
Opieram tą wiedzę na tym rozdziale.
Czy odpowiedziałem na Twoje pytanie?
Ostatnia aktualizacja: 24.10.2016 15:03:28 przez Hexmage960
Możemy też tworzyć zupełnie nowe eventy i dołączać do listy (wtedy trzeba zadbać o zapamiętanie adresów, by później zwolnić pamięć).
Żeby usunąć event (w sensie by nie był przetwarzany przez niższe handlery) wystarczy odłączyć go od listy eventów zwracanej przez nasz handler.
Opieram tą wiedzę na tym rozdziale.
Czy odpowiedziałem na Twoje pytanie?
Ostatnia aktualizacja: 24.10.2016 15:03:28 przez Hexmage960