07.02.2020 17:02
[#514]
Re: Magazyn - informacje nt. nowopowstającej gry
@Hexmage960, post #509
Heja. Dwa pytania:
1. Jak byś procentowo określił na jakim etapie ukończenia tego projektu jesteś?
2. Czy bierzesz pod uwagę zwrócenia się o czyjąkolwiek pomoc tutaj poza dźwiękami? Optymalizacja kodu? Poprawienie sprite’ow etc.
A tak to fajnie że się nie zrarzasz, i nie przejmuj się złośliwościami tutaj.
1. Jak byś procentowo określił na jakim etapie ukończenia tego projektu jesteś?
2. Czy bierzesz pod uwagę zwrócenia się o czyjąkolwiek pomoc tutaj poza dźwiękami? Optymalizacja kodu? Poprawienie sprite’ow etc.
A tak to fajnie że się nie zrarzasz, i nie przejmuj się złośliwościami tutaj.
07.02.2020 18:09
[#515]
Re: Magazyn - informacje nt. nowopowstającej gry
@Ralpheeck, post #514
1. A czy aktualny silnik, zaprezentowany w demie, + 30 etapów + poprawki kwalifikowałby się do pełnej gry? Myślę, że prawie.
Napiszę może jaki jest stopień ukończenia poszczególnych elementów gry + komentarz. Mam nadzieję, że objąłem wszystkie ważne zagadnienia.
- Rodzaje kafelków oraz grafika kafelków - 90%.
Nie planuję wprowadzać więcej rodzajów kafelków. Planuję dwie scenerie, z inną grafiką, ale analogiczną funkcją kafli. W zasadzie mogę tę drugą scenerię wydać jako Data Disk.
- Mechanika - 80%.
To będzie troszkę usprawnione, wspomniane 4 kierunki bohatera oraz dwie warstwy podłogi. Nie planuję płynnego przejścia między kafelkami, ale może lekką animację.
- Dodatkowe elementy gry - 50%.
Obejmuje to punktację, tryby gry, intro itp. Generalnie jest teraz jeden tryb gry, ale postaram się by był jak najatrakcyjniejszy.
- Silnik - 90%
Pomijając kwestię mechaniki - zagadnienia silnika, czyli interaktywności elementów zostały dobrze dopracowane - co mam nadzieję widać w demie.
- Pozostała grafika - 80%.
Wykorzystam zapewne wcześniej narysowaną grafikę do panelu. Ale do narysowania jest jeszcze plansza tytułowa oraz ładniejsze przerywniki.
- Etapy - 20%.
Tu kuleję, bo zawsze zakładam, że etapy robi się szybko. Ale to najprostsza generalnie część, choć bardzo istotna. Dopracowanie mechaniki elementów gry jest dość ważne i wpływa na etapy.
Tak to wygląda aktualnie. Do pełnego zakończenia projektu zostały zatem głównie etapy oraz niektóre pozostałe elementy gry. Planuję dodać też kilka dźwięków.
2. Z pomocy skorzystam po zakończeniu projektu.
Mam nadzieję, że to demko pokazuje postęp. W zasadzie możecie się przekonać, jak będzie wyglądała pełna gra - bo ta będzie mieć przede wszystkim więcej gotowych etapów. Ale wygląd i sposób działania pozostaną podobne.
Ja pamiętam o oczekiwaniach i sugestiach kolegów, z góry przepraszam jeśli któraś z proponowanych atrakcji nie znajdzie się w grze. Postaram się dodać jak najwięcej, ale utrzymując umiar.
Oczekujcie kolejnego dema (nadal oczywiście zbieram opinie nt. aktualnego).
Napiszę może jaki jest stopień ukończenia poszczególnych elementów gry + komentarz. Mam nadzieję, że objąłem wszystkie ważne zagadnienia.
- Rodzaje kafelków oraz grafika kafelków - 90%.
Nie planuję wprowadzać więcej rodzajów kafelków. Planuję dwie scenerie, z inną grafiką, ale analogiczną funkcją kafli. W zasadzie mogę tę drugą scenerię wydać jako Data Disk.
- Mechanika - 80%.
To będzie troszkę usprawnione, wspomniane 4 kierunki bohatera oraz dwie warstwy podłogi. Nie planuję płynnego przejścia między kafelkami, ale może lekką animację.
- Dodatkowe elementy gry - 50%.
Obejmuje to punktację, tryby gry, intro itp. Generalnie jest teraz jeden tryb gry, ale postaram się by był jak najatrakcyjniejszy.
- Silnik - 90%
Pomijając kwestię mechaniki - zagadnienia silnika, czyli interaktywności elementów zostały dobrze dopracowane - co mam nadzieję widać w demie.
- Pozostała grafika - 80%.
Wykorzystam zapewne wcześniej narysowaną grafikę do panelu. Ale do narysowania jest jeszcze plansza tytułowa oraz ładniejsze przerywniki.
- Etapy - 20%.
Tu kuleję, bo zawsze zakładam, że etapy robi się szybko. Ale to najprostsza generalnie część, choć bardzo istotna. Dopracowanie mechaniki elementów gry jest dość ważne i wpływa na etapy.
Tak to wygląda aktualnie. Do pełnego zakończenia projektu zostały zatem głównie etapy oraz niektóre pozostałe elementy gry. Planuję dodać też kilka dźwięków.
2. Z pomocy skorzystam po zakończeniu projektu.
Mam nadzieję, że to demko pokazuje postęp. W zasadzie możecie się przekonać, jak będzie wyglądała pełna gra - bo ta będzie mieć przede wszystkim więcej gotowych etapów. Ale wygląd i sposób działania pozostaną podobne.
Ja pamiętam o oczekiwaniach i sugestiach kolegów, z góry przepraszam jeśli któraś z proponowanych atrakcji nie znajdzie się w grze. Postaram się dodać jak najwięcej, ale utrzymując umiar.
Oczekujcie kolejnego dema (nadal oczywiście zbieram opinie nt. aktualnego).
07.02.2020 18:50
[#517]
Re: Magazyn - informacje nt. nowopowstającej gry
@Hexmage960, post #499
Ja nie pisałem kodu od nowa, tylko podobnie jak z grafiką, powstało wiele wersji kodu gry. Zawsze sądziłem, że potrafię napisać jednak to przejrzyściej i lepiej.
Czyli zajmujesz się elementami najmniej ważnymi w danym momencie, zamiast tworzyć, potem porzadkować, ekperymentujesz z estetyką szczegółów jak perfekcjonista, to nie jest nic złego jako tako samo w sobie, jednak pomyśl sobie, ile czasu trwałoby stworzenie dla Ciebie czegokolwiek bardziej złożonego niż klon Sokobana, życia by Ci nie starczyło.
26.02.2020 23:50
[#518]
Re: Magazyn - informacje nt. nowopowstającej gry
@sanjyuubi, post #517
Ponieważ pewien kolega forumowy ciągle narzeka na amigowy chipset, warto pokazać też drugą stronę medalu, czyli AGA od strony pozytywnej.
Prace nad Magazynem idą do przodu. Aktualnie przygotowałem też oprócz estetycznego GUI w grze, okienko z ustawieniami graficznymi gry, które otwiera się na ekranie publicznym. Można w nim wybrać:
Dzięki temu gra będzie wygodna w konfiguracji i - mam nadzieję - kompatybilna z różnymi Amigami.
Program konfiguracji jest font-sensitive czyli dostosowuje GUI do czcionki.
Ostatnia aktualizacja: 26.02.2020 23:53:25 przez Hexmage960
Prace nad Magazynem idą do przodu. Aktualnie przygotowałem też oprócz estetycznego GUI w grze, okienko z ustawieniami graficznymi gry, które otwiera się na ekranie publicznym. Można w nim wybrać:
- Rozdzielczość, tryb ekranu oraz głębię barw,
- Włączyć, bądź wyłączyć korzystanie bezpośrednio z Blittera, co pozwoli na działanie m.in. na RTG albo szybsze działanie na OCS/AGA,
- Wybrać pomiędzy software chunky, a systemową biblioteką graphics.library, czyli akcelerację sprzętową jaka jest np. w Amidze CD32,
- Włączyć lub wyłączyć podwójne buforowanie ekranu (może np. zaoszczędzić pamięć),
- Wyświetla ilość kolorów w palecie - 12-bit lub 24-bit,
- Pozwala wybrać mało lub dużo efektów animowanych.
Dzięki temu gra będzie wygodna w konfiguracji i - mam nadzieję - kompatybilna z różnymi Amigami.
Program konfiguracji jest font-sensitive czyli dostosowuje GUI do czcionki.
Ostatnia aktualizacja: 26.02.2020 23:53:25 przez Hexmage960
28.02.2020 00:06
[#526]
Re: Magazyn - informacje nt. nowopowstającej gry
@Hexmage960, post #518
Chyba trochę przesadzasz z tym AGA od dobrej strony, bo akurat Magazyn nijak nie jest wyciskaczem siódmych potów i nie jest w stanie być, chyba, że zrobisz mnóstwo animacji rodem z japońskich produkcji, przez które gracz będzie co chwilę otwierał oczy coraz szerzej ze zdumienia.
A tak poza tym, widzę, że nabierasz w końcu rozpędu i mam szczerą nadzieję, że już nie da się tej machiny zatrzymać, ani nawet spowolnić.
Te kafelki trochę mi się kojarzą z grą Arabian Nights.
A tak poza tym, widzę, że nabierasz w końcu rozpędu i mam szczerą nadzieję, że już nie da się tej machiny zatrzymać, ani nawet spowolnić.
Te kafelki trochę mi się kojarzą z grą Arabian Nights.
28.02.2020 09:05
[#527]
Re: Magazyn - informacje nt. nowopowstającej gry
@sanjyuubi, post #526
Gra nie musi wyciskać siódmych potów, żeby pokazywać moc AGA. 
Zresztą grafika jest dla OCS (32 kolory).
Co chciałem pokazać to możliwości jakie daje - możliwość wyboru rozdzielczości, głębi kolorów itp. co jest z reguły atrybutem RTG.
Napisałem też na potrzeby Magazynu szybkie procedury Planar-to-Chunky oraz Chunky-to-Planar w języku C. Możecie zapoznać się z nimi tutaj:
http://coreprogramming.pl/Kod/ShowCode.php?file=ChunkyRoutines.c
Procedury są w języku C, ale GCC kompiluje je do pięknego kodu.
Są wygodne w użyciu, bez problemu można oprzeć o nie WriteChunkyPixels(). Z tego co sprawdzałem są też bardzo szybkie. Odczytują i zapisują całościowo 32 piksele w 4 bitplanach, bo tak jest najlepiej (ze względu na rejestry) - i wymaga to zaledwie 16 króciutkich operacji.
Wymagają tylko jednej maski: 0x88888888.
Myślę, że zainteresuje to kolegę Teh_KaiNa.
W mojej grze te procedury będą towarzyszyć normalnym Blitom - z biblioteki graphics lub z użyciem Blittera bezpośrednio. Dzięki nim mogę zrobić grę kompatybilną z RTG.
Jednakże dodam dodatkową opcję, by dało się wyłączyć operacje chunky. Wówczas będą wykorzystywane tylko funkcje blitujące z biblioteki graphics oraz Blitter bezpośrednio.
@DezIII
Dziękuję, czuję się ostatnio dobrze.
@Wszyscy
Dzięki za wsparcie. Postaram się nie zawieść i wydać grę w miarę szybko.
Ostatnia aktualizacja: 28.02.2020 09:22:09 przez Hexmage960
Zresztą grafika jest dla OCS (32 kolory).Co chciałem pokazać to możliwości jakie daje - możliwość wyboru rozdzielczości, głębi kolorów itp. co jest z reguły atrybutem RTG.
Napisałem też na potrzeby Magazynu szybkie procedury Planar-to-Chunky oraz Chunky-to-Planar w języku C. Możecie zapoznać się z nimi tutaj:
http://coreprogramming.pl/Kod/ShowCode.php?file=ChunkyRoutines.c
Procedury są w języku C, ale GCC kompiluje je do pięknego kodu.
Są wygodne w użyciu, bez problemu można oprzeć o nie WriteChunkyPixels(). Z tego co sprawdzałem są też bardzo szybkie. Odczytują i zapisują całościowo 32 piksele w 4 bitplanach, bo tak jest najlepiej (ze względu na rejestry) - i wymaga to zaledwie 16 króciutkich operacji.
Wymagają tylko jednej maski: 0x88888888.
Myślę, że zainteresuje to kolegę Teh_KaiNa.
W mojej grze te procedury będą towarzyszyć normalnym Blitom - z biblioteki graphics lub z użyciem Blittera bezpośrednio. Dzięki nim mogę zrobić grę kompatybilną z RTG.
Jednakże dodam dodatkową opcję, by dało się wyłączyć operacje chunky. Wówczas będą wykorzystywane tylko funkcje blitujące z biblioteki graphics oraz Blitter bezpośrednio.
@DezIII
Dziękuję, czuję się ostatnio dobrze.
@Wszyscy
Dzięki za wsparcie. Postaram się nie zawieść i wydać grę w miarę szybko.
Ostatnia aktualizacja: 28.02.2020 09:22:09 przez Hexmage960
28.02.2020 10:11
[#530]
Re: Magazyn - informacje nt. nowopowstającej gry
@Hexmage960, post #527
Owszem mnie to zainteresowało. W wolnej chwili je zbenczmarkuję ze swoimi, które są co najmniej tragiczne. Być może Twój kod ma szansę skrócić loadingi w openfire jak do niego kiedyś wrócę. ;)
W wolnej chwili, po skończeniu magazynu pomyśl o licencji swojego kodu. Może jakiś MIT, BSD, (mój ulubiony) MPL? A może domena publiczna czyli Unlicense lub WTFPL. Bo w tej chwili nie wiem na jakich warunkach mogę do swojego kodu zrobić ctrl+c ctrl+v tych procedur. Kod bez komentarza z licencją traktuje się przeważnie jako po prostu copyrightowany wymagający kontaktu z autorem. Zostawiając komentarz u góry ułatwiasz życie wszystkim zainteresowanym.
Ostatnia aktualizacja: 28.02.2020 10:15:57 przez teh_KaiN
W wolnej chwili, po skończeniu magazynu pomyśl o licencji swojego kodu. Może jakiś MIT, BSD, (mój ulubiony) MPL? A może domena publiczna czyli Unlicense lub WTFPL. Bo w tej chwili nie wiem na jakich warunkach mogę do swojego kodu zrobić ctrl+c ctrl+v tych procedur. Kod bez komentarza z licencją traktuje się przeważnie jako po prostu copyrightowany wymagający kontaktu z autorem. Zostawiając komentarz u góry ułatwiasz życie wszystkim zainteresowanym.
Ostatnia aktualizacja: 28.02.2020 10:15:57 przez teh_KaiN
29.02.2020 00:34
[#534]
Re: Magazyn - informacje nt. nowopowstającej gry
@teh_KaiN, post #530
Przyznam, że nie jestem za bardzo obeznany z licencjami, więc ten kod udostępniam jako domena publiczna. Możesz korzystać do woli bez restrykcji.
Zrobiłem łączenie par 4-bitowych pikseli w 8-bitowe przy odczycie, oraz w drugą stronę przy zapisie.
Zrobiłem też pewien manewr, który usprawnia czytanie bajtowych pikseli z długich słów. Otóż wiadomo że normalnie piksele są ułożone po 4 w rejestrze i to niekoniecznie w wygodnej kolejności, bo nawet 0, 1, 2, 3 - kolejność liniowa daje dostęp do piksela nr 3 w pierwszej kolejności (bo leży w najmłodszym bajcie).
Zrobiłem zatem tak, że definiuje się własną funkcję, która przy zapisie pikseli (Chunky-To-Planar) przyjmuje indeks piksela i musi zwrócić wartość piksela o tym indeksie. To wszystko o co musi zadbać program. Resztę załatwia konwerter.
Przy odczycie pikseli (Planar-to-Chunky) tej funkcji przekazywany jest indeks i wartość piksela, zaś funkcja nic nie zwraca.
Funkcja zostaje wywołana oddzielnie dla każdego z 32 pikseli. Piksele są buforowane i zapisywane.
Wewnętrznie program może manipulować tymi danymi do woli, tzn. mapować piksele, przestawiać je itd.
Tak więc teraz WriteChunkyPixels() w pełni zgodny z oryginałem jest całkiem łatwy do napisania za pomocą mojej procedury. Jeśli się nie mylę, to nawet przesuw pikseli będzie łatwo zrealizować - zwracając piksele z odpowiednio przesuniętych pozycji. (Początkowo chciałem by Blitter przesuwał dane planarne).
Jak tylko opakuję w WriteChunkyPixels() to będzie spokój z tym zagadnieniem.
Możesz korzystać do woli bez restrykcji.Zrobiłem łączenie par 4-bitowych pikseli w 8-bitowe przy odczycie, oraz w drugą stronę przy zapisie.
Zrobiłem też pewien manewr, który usprawnia czytanie bajtowych pikseli z długich słów. Otóż wiadomo że normalnie piksele są ułożone po 4 w rejestrze i to niekoniecznie w wygodnej kolejności, bo nawet 0, 1, 2, 3 - kolejność liniowa daje dostęp do piksela nr 3 w pierwszej kolejności (bo leży w najmłodszym bajcie).
Zrobiłem zatem tak, że definiuje się własną funkcję, która przy zapisie pikseli (Chunky-To-Planar) przyjmuje indeks piksela i musi zwrócić wartość piksela o tym indeksie. To wszystko o co musi zadbać program. Resztę załatwia konwerter.
Przy odczycie pikseli (Planar-to-Chunky) tej funkcji przekazywany jest indeks i wartość piksela, zaś funkcja nic nie zwraca.
Funkcja zostaje wywołana oddzielnie dla każdego z 32 pikseli. Piksele są buforowane i zapisywane.
Wewnętrznie program może manipulować tymi danymi do woli, tzn. mapować piksele, przestawiać je itd.
Tak więc teraz WriteChunkyPixels() w pełni zgodny z oryginałem jest całkiem łatwy do napisania za pomocą mojej procedury. Jeśli się nie mylę, to nawet przesuw pikseli będzie łatwo zrealizować - zwracając piksele z odpowiednio przesuniętych pozycji.
(Początkowo chciałem by Blitter przesuwał dane planarne).Jak tylko opakuję w WriteChunkyPixels() to będzie spokój z tym zagadnieniem.
29.02.2020 12:01
[#536]
Re: Magazyn - informacje nt. nowopowstającej gry
@amikoksu, post #535
Pomocy przy projektowaniu poziomów nie potrzebuję. Gra ma edytor (prezentowany m.in. w ostatnim demie), więc jeśli ktoś będzie chciał dorobić własne poziomy - będzie miał taką możliwość.
Dodam jeszcze w temacie grafiki Chunky, że pomysł okazał się dobry - opracowałem na podstawie mojej procedury, własną, rozszerzoną funkcję wklejania Chunky, która przyjmuje obiekt oraz tło (czyli rozszerzona wersja WriteChunkyPixels()).
Dzięki tej funkcji, która zwraca wartość piksela na danej pozycji zupełnie za darmo, bez kopiowania bajtów pamięci mogę zrobić takie operacje jak:
- przesuw obiektu,
- odbicie symetryczne w pionie lub poziomie,
- łączenie obiektu i tła.
I inne, jakie sobie wymyślimy.
Tak więc w Magazynie będzie raz rysowane tło, a następnie będą nanoszone obiekty za pomocą rozszerzonej WriteChunkyPixels(), które pobiera dwa kanały. Obiekty oraz tło cały czas rezydują w pamięci i nie są modyfikowane. Żeby np. przesunąć obiekt nie trzeba, tak jak wspomniałem, kopiować bajtów pamięci.
Procedura pobiera obiekt i tło, łączy i wkleja do pamięci graficznej. Oczywiście to, czy łączymy dwie warstwy, czy np. odbijamy symetrycznie pobierając piksele w odwrotnej kolejności - zależy od zaprojektowanej przez nas funkcji.
Ostatnia aktualizacja: 29.02.2020 12:12:24 przez Hexmage960
Gra ma edytor (prezentowany m.in. w ostatnim demie), więc jeśli ktoś będzie chciał dorobić własne poziomy - będzie miał taką możliwość.Dodam jeszcze w temacie grafiki Chunky, że pomysł okazał się dobry - opracowałem na podstawie mojej procedury, własną, rozszerzoną funkcję wklejania Chunky, która przyjmuje obiekt oraz tło (czyli rozszerzona wersja WriteChunkyPixels()).
Dzięki tej funkcji, która zwraca wartość piksela na danej pozycji zupełnie za darmo, bez kopiowania bajtów pamięci mogę zrobić takie operacje jak:
- przesuw obiektu,
- odbicie symetryczne w pionie lub poziomie,
- łączenie obiektu i tła.
I inne, jakie sobie wymyślimy.
Tak więc w Magazynie będzie raz rysowane tło, a następnie będą nanoszone obiekty za pomocą rozszerzonej WriteChunkyPixels(), które pobiera dwa kanały. Obiekty oraz tło cały czas rezydują w pamięci i nie są modyfikowane. Żeby np. przesunąć obiekt nie trzeba, tak jak wspomniałem, kopiować bajtów pamięci.
Procedura pobiera obiekt i tło, łączy i wkleja do pamięci graficznej. Oczywiście to, czy łączymy dwie warstwy, czy np. odbijamy symetrycznie pobierając piksele w odwrotnej kolejności - zależy od zaprojektowanej przez nas funkcji.
Ostatnia aktualizacja: 29.02.2020 12:12:24 przez Hexmage960
29.02.2020 12:20
[#537]
Re: Magazyn - informacje nt. nowopowstającej gry
@Hexmage960, post #536
Gra ma edytor (prezentowany m.in. w ostatnim demie), więc jeśli ktoś będzie chciał dorobić własne poziomy - będzie miał taką możliwość.
Edytor bardzo fajna opcja. Tylko lepiej byłoby na starcie dostać poziomy, których się nie zna. Odpalasz grę i grasz.
A tak to ktoś może przysiądzie na 10 minut, zrobi ze trzy poziomy, przejdzie je i o grze zapomni.
Zrobisz jak chcesz.
