Niezalogowany (Zaloguj się)

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

Dude Story - historia Kolesia

Od 51 do 100 z 113

- 1: CommentAuthorgorgh
- CommentTime22 May 2020 22:05
pięknie, na pewno wymyślisz coś oryginalnego
- 2: CommentAuthorbruno_j
- CommentTime23 May 2020 00:05
Mq zapowiada się miodnie.
Taka mała sugestia, może warto by się udać w mało spenetrowany kierunek duchów softwarowych podbarwianych sprzętowymi?
Plusy:
więcej kolorów dla gracza, przeszkadzajek i jabłek
detekcja kolizji w gratisie

Minusy:
sporo mocy procka na to pójdzie.

Trzymam kciuki za projekt.
- 3:
  
  CommentAuthorMq
- CommentTime23 May 2020 02:05
Koleś jest już zbudowany z wszystkich czterech playerów i ma gotowy szybki silnik animacji, który jeszcze nadal mimo wszystko optymalizuję, żeby starczyło mocy na całą resztę.
Silnik kolizji też już działa i jest szybki (ale też optymalizuję dalej:-)).
Scrollingi zoptymalizowałem dziś mega mocno (nie widać tego w grze, ale zrobiłem sporo miejsca na kolejne mechanizmy).

Cała reszta jest już z góry od początku zaplanowana, zarówno pamięć, jak i rozłożenie mocy obliczeniowej jest układana pod obsługę wszystkiego naraz, włącznie z tym czego jeszcze nie ma.

Animowane elementy tła / przeszkadzajki / przeciwnicy / aktorzy / uczestnicy będą softwarowi, a missile będą wykorzystane do efektów specjalnych, których planuję kilka.

Kolorów jeszcze kilka będzie gdzieniegdzie, a w innych lokacjach będą zupełnie inne display listy i zmiany w dli.

Nie mogę wszystkiego w szczegółach zdradzać, bo ma być niespodzianka na koniec i gra ma być do odkrywania przez graczy i ma zaskakiwać w dalszych etapach.

Ale hej, na serio jeszcze Ci w tym mało jest kolorów co pokazałem do tej pory?:-) Na samym niebie masz 3, Koleś w 3, jabłka w 2, drzewa w 3, woda w osobnym, chmury w osobnym, no i czarny wszędzie możliwy do wykorzystywania. Musi Tobie tyle wystarczyć, więcej mój silnik nie udźwignie przy tych wszystkich rzeczach, na które zostawiłem miejsce jak to wszystko jeszcze dołożę:-)
- 4: CommentAuthornosty
- CommentTime23 May 2020 08:05
@Mq najpierw gratuluję Ci energii i entuzjazmu z jakim rozwijasz grę. Trzymam kciuki żebyś dowiózł ją do końca. Na Atari autorskich gier jest niestety bardzo mało.

A propos kolorów: ze mnie żaden grafik, ale imho nie masz problemu z ich ilością, tylko z ich dobraniem i spójnością.
Mam wrażenie, że pierwszy plan (platformy) są "pożyczone" z innej gry niż tło, a już z pewnością z kompletnie innej gry (a może i z innego komputera ;) ) pochodzi bohater w odcieniach błękitu. Gra w postaci takiej jak na screenach jest dla mnie po prostu brzydka. Ale to oczywiście tylko moja subiektywna opinia, być może osamotiona.
Kiepsko wyglądają też ostre odcięcia pni od koron drzew (choć wiem oczywiście z czego to wynika).

Tak czy inaczej trzymam kciuki i chętnie zagram jak tylko będzie to możliwe :)
- 5:
  
  CommentAuthorMq
- CommentTime23 May 2020 14:05
@nosty dzięki za słowa wsparcia - i te pozytywne i te krytyczne, bo takie też mogą coś pozytywnego wnieść.

Krótko odnośnie "zapożyczeń": cała grafika, postać, platformy itd. nie są znikąd "zapożyczone", wszystko to są moje autorskie rysunki i później pikselowania po nich.

Napiszę trochę o kolorach - temat mocno już przeze mnie w tej grze przedrążony, ale może ktoś coś dopowie jak opiszę więcej szczegółów doboru kolorów, który okazał się dość trudny.

Określenie "brzydka" oczywiście jest jak najbardziej możliwe, bo nie jest ładne to co ładne, tylko to co się komu podoba:-)
Chciałbym się tylko upewnić w kwestii tego o czym piszesz: jeżeli oglądałeś screeny wrzucone przeze mnie, lub opierasz się o gameplay z filmiku zbyla, lub też sam odpaliłeś grę na prawdziwym Atari lub na emulatorze, ale z paletą zbliżoną do Atari, to wszystko w porządku. Jeśli natomiast opierasz się w swojej opinii o faktycznie brzydki zrzut który zrobił astrofor (niestety ten sam zrzut jest w czołówce filmiku, ale sam gameplay już jest ok), lub np. o beznadziejną standardową paletę Altirry, to proszę zrewiduj jeszcze swoje poglądy - nie dlatego że chcę się spierać o to co się komu podoba, tylko dlatego, żeby mieć pewność, że rozmawiamy faktycznie o mojej grafice, a nie o grafice z podmienioną paletą na beznadziejną.
Piszę o tym, bo wspomniałeś o odcieniach błękitu w przypadku postaci, podczas gdy postać w ogóle nie ma nic błękitnego w sobie, bo zwyczajnie jest fioletowa:-)

Jeśli chodzi o dobór kolorów, to faktycznie jest to dość trudne, lub nawet bardzo trudne na Atari jeśli robimy grę kolorową, z kolorowym tłem i chcemy tych kolorów zrobić dość dużo. Problem polega na tym, że w Atari mamy paletę bardzo ograniczoną technicznymi możliwościami. Trzeba iść na wiele kompromisów. Zaczynają się one od tego, że żeby postać miała trzeci kolor, to dwa pierwsze trzeba dobrać dość odpowiednio. Te kolory muszą być w konkretnych dwóch jasnościach żeby wytworzyć sensowny trzeci kolor, a więc w zasadzie do wyboru zostanie nam ich już ilość policzalna na palcach, a to co dostajemy jest mocno od siebie nawzajem zależna. Postać miała być w innych kolorach niż tło, więc przy tym wyborze doszedłem do momentu, że Koleś mógł być tylko fioletowy lub w odcieniach czerwonego. Wybrałem fiolet.
Teraz tło: ponieważ jest z założenia kilka kolorów, na których tle pojawia się nasza postać, to każdy z tych kolorów musi mieć taki odcień, żeby każdy z kolorów postaci był w miarę na tym tle widoczny i czytelny. Wziąłem przy tym pod uwagę też fakt, żeby gra była w ogóle widoczna na monitorach monochromatycznych. Wtedy na każdym z kolorów tła będzie widoczna nasza postać, a jednocześnie wszystkie kolory tła mają odcienie różniące się między sobą na tyle, że tło nie będzie jednolite, tylko na monochromie nadal zobaczymy kontury poszczególnych planów i różne odcienie elementów rysowanych różnym kolorem. Atari ma 128 kolorów. Jak odrzucimy z nich najciemniejsze, które są bardzo mało wyraźne i najjaśniejsze, oraz fiolet, który wykorzystuje postać, a także np. różowy, z którego nie można przecież zrobić trawy czy korony drzewa, to w zasadzie nie mamy już z czego tych kolorów dobierać.
Ostatnia sprawa dot. kolorów, to fakt, o którym trzeba pamiętać, że to jest gra, w której nie mogę pozwolić sobie na to, żeby np. zmieniać kolory we wszystkich liniach ekranu, oraz nie mogę pozwolić sobie na dokładanie większej niż założona ilość znaków. Grafika musi być na poziomie, który jest kompromisem pomiędzy samą jakością tej grafiki, a potrzebami pozostawienia zasobów pamięci i czasu dla pociągnięcia gry, mechaniki, gameplay, scrollingów, animacji itd.
Tak to z grubsza wygląda, więc jeśli ktoś ma ochotę zaproponować zmiany kolorystyczne, to chętnie zobaczę na jakie i być może zastosuję się do propozycji jeśli faktycznie będzie dobra.

Popatrzcie na załączony obrazek. Kolor jasnozielony jest w tym samym odcieniu co tułów postaci. Wziąłem np. właśnie to pod uwagę i w tym kolorze jest stosunkowo mała ilość elementów tła na którym najczęściej występuje bohater. To tylko jeden z przykładów tego doboru kolorów.

Różnice między stylem platform i np. koron drzew wynikają z tego, że miałem taki zamysł, żeby elementy pierwszoplanowe rysować z czarnymi konturami jak w komiksach. Elementy drugoplanowe miały być trochę "rozmyte" bez tych konturów. Przy pniach drzew pierwszoplanowych, koronach drzew i chmurach natknąłem się na wątpliwość czy robić kontury czy nie i zrobiłem to bez nich. Następnie dodałem jednak trochę czarnych pikseli do brązowych pni drzew, bo faktycznie zbyt mocno odbiegały stylem od platform, a dodanie czerni do pni spowodowało trochę lepsze wtopienie platform w całokształt. Nadal rozważam dodanie niewielkiej ilości czerni również do konturów koron drzew i chmur, bo faktycznie też mi się to jeszcze nie do końca podoba, ale mam tu problem z kompromisami - znaki używane w koronach drzew i chmur są również używane w tle drugo- i trzecio- planowym, gdzie nie może być w ogóle czerni, wobec tego nie wszędzie mogę to zrobić w dowolny sposób.

Ostatnia skrytykowana rzecz: ostre odcięcie pni od koron drzew - tu się zgadzam w 100%, mnie też się to nie podoba. Już to trochę starałem się poprawić dodając powyżej i poniżej odcięcia znaki z jakimiś gryzmołami, ale jeszcze to zbyt mało. Popracuję nad tym i na pewno to poprawię jeszcze. Dotychczas starałem się to po prostu zrobić tutaj bez dodawania kolejnych znaków, ale chyba warto poświęcić jeszcze ze dwa-trzy znaki na tego typu miejsca, żeby tych odcięć nie było aż tak widać.
- monochrom.png
- 6: CommentAuthorAdam
- CommentTime23 May 2020 16:05
Mq:
Trzeba iść na wiele kompromisów. Zaczynają się one od tego, że żeby postać miała trzeci kolor, to dwa pierwsze trzeba dobrać dość odpowiednio. Te kolory muszą być w konkretnych dwóch jasnościach żeby wytworzyć sensowny trzeci kolor, a więc w zasadzie do wyboru zostanie nam ich już ilość policzalna na palcach, a to co dostajemy jest mocno od siebie nawzajem zależna.

Zgadza się, trzeba iść na wiele kompromisów, niestety część osób zupełnie tego nie rozumie (niekoniecznie dotyczy to Nosty'ego, na którego wpis odpowiadałeś :) ). Ostatnio podobne niezrozumienie było w dyskusji dotyczącej głównej postaci w grze LiteRally Gorgha.

Ale jest jeszcze inna opcja użycia 4 playerów, którą może rozważysz, a która pozwoliłaby na jednoczesne uzyskanie zarówno czarnej obwódki postaci, jak i 3 kolorów (ale przy dodatkowych ograniczeniach, które wymusiłyby konieczność przerysowania niektórych klatek postaci):
- czarną obwódkę + kontury robisz z dwóch playerów w standardowej rozdzielczości grafiki PMG
- pod nimi umieszczasz dwa playery, oba w podwójnej szerokości (z nich uzyskujesz 3 kolory tak jak dotychczas); aby nie było widać ich kanciastości, granice między kolorami można przysłaniać czarnymi pikselami, o których napisałem powyżej.

Życzę powodzenia i trzymam kciuki, jeszcze wiele przed Tobą :)

PS. Protestuję przeciwko określaniu palety Altirry jako beznadziejnej - o wiele gorsze można spotkać w innych emulatorach ;)
- 7:
  
  CommentAuthorMq
- CommentTime23 May 2020 19:05
Żeby nie było: ja odpowiedziałem na wpis nosty'ego, ale nie żeby się z nim spierać, tylko żeby opisać wszystko co wiem w temacie, częściowo rozważyć jego uwagi i być może dać do myślenia innym, którzy też się z tymi problemami zmierzą.

Ogólnie często zastanawiają się ludzie dlaczego większość gier na Atari ma czarne tło i deprecjonują te gry stwierdzeniami w stylu "jaaa, znowu czarne tło...". Natomiast prawda jest taka, że z racji palety i możliwości Atari, jak się zrobi kolorowe tło, to mega trudno jest dobrać kolory, żeby na tym tle było widać jeszcze akcję. Kwestia tych nieszczęsnych braków, gdzie nie mamy osobno nasycenia i jasności dla kolorów.

Taka anegdota: w dzieciństwie grałem w Preliminary Monty na czarno-białym monitorze i przez długi czas myślałem, że w grze są klucze jasne i ciemne, a dla utrudnienia nie wszystkie ciemne klucze pasują do nie wszystkich ciemnych drzwi, i że to jest celowo tak zrobione. Kiedy pierwszy raz zobaczyłem grę na kolorowym telewizorze u kumpla, to wielce mnie zdumiało, że te ciemne klucze są czerwone i niebieskie:-) To wiele wyjaśniło:-)

Pomijając jednak skrajny przypadek dopasowania kolorów w Dude Story do monitorów monochromatycznych, to powiem szczerze, że na początku robiąc te kolory okazało się, że nawet na kolorowym monitorze, z wyjściem porządnym kablem po s-video są różne kolory, które występując obok siebie robią różne dziwne efekty zlewając się ze sobą, rozmywając itp. Ta cała paleta, która jest dostępna pod emulatorem (już obojętnie która), na real Atari niekoniecznie da się wyświetlić w określonych kombinacjach ułożonych obok siebie pikseli tak, żeby dać wystarczający kontrast i nie zakłócać się wzajemnie. Jest walka:-) A jak się już uwalczy żeby w ogóle było coś widać, to jeszcze trzeba to skonfrontować z tym, że jednak chcemy żeby niebo było niebieskie, drzewa zielone, pnie brązowe, a jabłka czerwone. W palecie mamy tymczasem kilka kolorów bezużytecznych w lesie różowych itp. Słowem pole do popisu jest niewielkie.

Z pomocą przychodzi trochę koncepcja rysowania czarnych konturów. Początkowo ich w ogóle nie robiłem, to dopiero wszystko było mdłe i zlane w jeden wielki kleks. Kontury czarne wpływają bardzo mocno na czytelność i kontrast grafiki.
@Adam, znam technikę o której napisałeś i rozważałem zrobienie tego dokładnie w ten sposób. Natomiast jak zacząłem rysować postać i okazało się, że np. ręka musi mieć miejscami coś pomiędzy 1 a 2 piksele szerokości (w sensie od 1 do 2 cykli kolorów), to się okazało, że już czarna ramka się nie zmieści, a gdzie tu jeszcze jakieś podcieniowanie czy coś. Dlatego zrezygnowałem w przypadku Dude'a z tego pomysłu, dochodząc do wniosku, że kolor musi być aż do samej krawędzi postaci.
Druga rzecz, że rysowanie w ten sposób w jaki opisałeś jest trudniejsze niż to co mam teraz. Na ten moment poświęciłem na postać już tak dużo czasu i jestem na tyle zadowolony, że nie będę już zmieniał tutaj techniki. Może innym razem spróbuję zrobić to inaczej.

W porównaniu z Atari rysowanie grafiki tego typu na pececie czy nawet np. na Amidze wydaje się być trywialne:-) Kwadratowy piksel hi-res i przykładowo dwukrotnie większa rozdzielczość, a do tego niezależne ustawianie nasycenia barwy i jasności załatwia wszystko elegancko i można być artystą a nie wojownikiem pikselowania:-)
- 8:
  
  CommentAuthorDracon
- CommentTime23 May 2020 20:05
@Mq: rządzisz tymi opisami. Przed Tobą prawie żaden programista tutaj nie był skłonny do takich wyjaśnień i pokazywania toku myślenia i planowania. A chętnie dowiedziałbym się jeszcze jak powstawała taka gierka:
->link<-
;)
No i wielkie dzięki za część o TILED, na pewno może się przydać różnym osobom.
- 9: CommentAuthornosty
- CommentTime23 May 2020 21:05 zmieniony
"Problem polega na tym, że w Atari mamy paletę bardzo ograniczoną technicznymi możliwościami. Trzeba iść na wiele kompromisów."

Bluźnisz! Żaden komputer 8-bitowy nie ma takiej palety jak Atari. Na kompromisy to muszą iść spectrumiarze z paletą 16, albo amstradowcy z paletą 27 kolorów. Ty masz do wyboru co najmniej 128.

"Postać miała być w innych kolorach niż tło"
A po co? O tym własnie piszę. W odcieniach błękitu czy tam fioletu, wygląda jak ufoludek.
Masz dużą, ładnie animowaną postać na nieruchomym tle.
Aby postać była dobrze widoczna potrzebujesz jedynie konturu, a tego nie wykorzystałeś. Więcej: zużyłeś na nią 4 duszki, co potencjalnie pozwala Ci uzyskać co najmniej 6 kolorów, a Ty masz 3! Adam Ci napisał jak uzyskać 4-5 kolorów z dobrym konturem.
Kontury nie muszą być przecież czarne.

"Wziąłem przy tym pod uwagę też fakt, żeby gra była w ogóle widoczna na monitorach monochromatycznych."

A po co? Kto w XXI wieku używa zielonego Neptuna albo szarego Junosta? Jedynie masochiści. A ci się ucieszą, gdy dostaną dodatkową torturę w postaci nieczytelnej gry ;)
Ale znów - odpowiedzią na Twoje problemy jest magiczne słowo KONTUR.

Wg mnie masz wybór: nauczyć się szybko samemu w pixelart, albo namówić do współpracy dobrego grafika, który wszystko to, co próbujesz z takim trudem rozkminić ma w małym palcu. Jeśli pokażesz dobrze działający prototyp obiecującej gry, to z pewnością kogoś znajdziesz. Polecam takie rozwiązanie.

Jeśli wybierzesz pierwszą ścieżkę, to polecam analizę grafik z pierwszego gameboya. Tam są jednie 4 odcienie szarości i nic więcej! W rozdzielczości bardzo podobnej do Atar (niższej). I gry mają zarówno świetną grafikę jak i widoczne na tle postaci.
- 10:
  
  CommentAuthorMq
- CommentTime23 May 2020 22:05
@nosty, zapewniam Cię, że czytam na chłodno Twoje komentarze, co więcej staram się nawet wyobrazić każdą z Twoich uwag jako poradę i rozważam dodatkowe przetestowanie niektórych podpowiedzi.
Jednak obawiam się po kilku Twoich odpowiedziach, że się mocno nie rozumiemy, a w szczególności Ty nie rozumiesz niektórych z moich działań i błędnie interpretujesz założenia:-)

Już tłumaczę co mam na myśli.

"Postać miała być w innych kolorach niż tło"
A po co? O tym własnie piszę. W odcieniach błękitu czy tam fioletu, wygląda jak ufoludek.

A jak ma wyglądać? Czy to projekt Twojej postaci, czy mojej? Czy wiesz kim jest Koleś? Skąd się wziął? Jaka jest fabuła? Scenariusz? Gdzie dzieje się akcja całej opowieści? Pytam retorycznie ;-)

"Wziąłem przy tym pod uwagę też fakt, żeby gra była w ogóle widoczna na monitorach monochromatycznych."

A po co? Kto w XXI wieku używa zielonego Neptuna albo szarego Junosta?

A kto w XXI wieku używa Atari?:-) Bawię się retro sprzętem, wracam do czasów Atari, robię grę jaka mogła by powstać w tamtych czasach i dla tamtych użytkowników. Biorę pod rozwagę dostosowanie się do techniki z tamtych lat. Zabawa polega na grzebaniu w retro, a nie na robieniu gry samej w sobie. Zawsze można napisać grę na androida zamiast na Atari.

Wg mnie masz wybór: nauczyć się szybko samemu w pixelart, albo namówić do współpracy dobrego grafika, który wszystko to, co próbujesz z takim trudem rozkminić ma w małym palcu. Jeśli pokażesz dobrze działający prototyp obiecującej gry, to z pewnością kogoś znajdziesz. Polecam takie rozwiązanie.

A dlaczego miałbym się musieć szybko uczyć czegokolwiek? Dlaczego miał bym szukać dobrego grafika? Skąd pomysł i narzucanie, że mam pokazać dobrze działający prototyp obiecującej gry? Normalnie poczułem się jak bym był w robocie, a Ty jako mój szef mówisz mi, że albo tak zrobię albo wylatuję z roboty:-) W dodatku szybko:-)

nosty, z całym szacunkiem, ale Ty albo o nim zapomniałeś, albo nie przeczytałeś wątku. Od początku pisałem, że piszę sobie grę, że robię wszystko sam, że jest to realizacja moich marzeń z dawnych lat o zrobieniu takiej gry. Wspominałem też, że nie jestem grafikiem i że robię wszystko o wiele dłużej niż zapewne zrobił by to grafik, ale że mi to sprawia dużą frajdę i to jest dla mnie najważniejsze, bo grę robię dla zabawy w ramach hobby. A tu nagle jakby zapomina się o tym wszystkim i wrzuca w standardowy nurt: chciało by się powiedzieć znajdź grafika, znajdź kodera, idź do domu:-) Koderem na Atari jestem gorszym niż grafikiem, a grafikiem nie jestem wcale:-)

Cała reszta Twoich komentarzy jest merytoryczna, nie mam zastrzeżeń, spróbuję też skorzystać z porad, i być może poprawię to i owo w oparciu o nie. Dziękuję.

@Dracon: cieszę się, że się podobają opisy. W ramach retro zabawy lubię sobie czasem poopisywać to co robię, podzielić się spostrzeżeniami, czy opowiedzieć jakieś historie związane z naszym hobby. Wiem, że są osoby, które lubią sobie zwyczajnie poczytać takie historie, sam lubię, stąd jak mam teraz akurat o czym, to produkuję trochę tego tekstu chwilowo.
- 11: CommentAuthoranimaion
- CommentTime23 May 2020 23:05
Dołączam się do podziękowań. Bardzo fajnie się czyta i ogląda.
Dobrej zabawy!
Moja mała sugestia poniżej.
- monochrom2.png
- 12: CommentAuthorAdam
- CommentTime24 May 2020 00:05
animaion:
Moja mała sugestia poniżej.

Tuż nad Twoim wpisem jest dyskusja o tym, że istnieją pewne ograniczenia dotyczące kolorów na Atari, w szczególności dotyczy to uzyskiwania trzeciego koloru przy łączeniu dwóch duszków. Mimo to przedstawiasz propozycję, której nie da się w ten sposób zrealizować (czerń i biel jednocześnie oznaczają, że nie ma miejsca na trzeci kolor).

Jak chcesz więc uzyskać ciemnoniebieski na tej postaci, która, zgodnie z założeniami autora, ma być zrealizowana wyłącznie na grafice PMG i mieć szerokość do 16 pikseli?
- 13:
  
  CommentAuthorMq
- CommentTime24 May 2020 02:05
Dzięki Adam za szczegółową analizę. Bardzo mi się podoba Twoja odpowiedź, rzadko się zdarza, że ktoś wnikliwie czyta wszystkie szczegóły i odpowiada aż tak bardzo ze zrozumieniem i w kontekście:-)

Adam, rozważę jeszcze to co napisałeś wcześniej o technice z dwoma playerami czarnymi na wierzchu i dwoma rozszerzonymi kolorowymi pod spodem. Nie wiem jednak czy uda mi się w taki sposób narysować wszystkie klatki, ale spróbuję dla testu, tylko to sporo roboty, więc muszę znaleźć na to czas... Muszę też przemyśleć tematy, do których chciałem użyć missile, czy mi to nie będzie teraz kolidowało z koncepcją, ale może się okazać, że nawet było by to lepiej. Zobaczę. Ale widać warto trochę czasem burzy mózgów zrobić, bo rodzą się nowe koncepcje, uwagi, i być może uda się polepszyć jeszcze trochę niektóre pomysły.

Widziałem w Gramy na Gazie, że chłopaki tam zapuścili na chwilkę mojego Kolesia. Mieli kłopot ze wskakiwaniem na malutkie platformy, które są na pniach drzew. Ja to celowo tak zrobiłem, żeby się po tym łatwo biegać nie dało, bo na drzewa po pniach wchodzi się trudniej niż po platformach:-) Tam po prostu nie należy skakać na ukos, tylko ustawić się odpowiednio i skakać pionowo w górę. To bardzo łatwe:-)
- 14: CommentAuthornosty
- CommentTime24 May 2020 08:05
@Mq - masz całkowitą rację: to Twoja i tylko Twoja gra i nikomu nic do tego jak będzie wyglądał bohater. Asertywność to ważna rzecz dla twórcy. Tyle, że jak zacząłeś publicznie i szczegółowo dzielić się procesem twórczym, konsultować i pytać o zdanie, to po prostu wyraziłem swoje. Możesz je uwzględnić albo nie i tyle.

Mój post absolutnie nie miał być w zamyśle atakujący czy narzucający cokolwiek! Zdanie o tym, że "musisz" nauczyć się "szybko" pixelartu, albo znaleźć dobrego grafika, też było oczywiście figurą retoryczną, za którą przepraszam, jeśli wydała się zbyt "offence". Pisałem raczej o tym co ja bym zrobił na Twoim miejscu, chcąc poprawić wygląd gry.

Oczywiście Ty nic nie musisz, ani szybko ani wolno. Nie musisz nawet zrobić ładnej graficznie gry, jeśli wolisz zrobić grę brzydką ;)

Ja od zawsze mam taką wadę, że gdy ktoś tu opisuje, że zaczął właśnie robić nową grę na Atari, to nie przyłączam się do ogólnego chóru osób dopingujących i dziękujących autorowi, że w ogóle raczył zacząć robić cokolwiek na nasz komputer. Ja wskazuję co mi się nie podoba i co można poprawić, żeby gra była lepsza, bo nie zadowalam się "czymkolwiek na Atari". Jak już się poświęca czas i energię to lepiej zrobić grę lepszą niż gorszą.

PS. Co do wyglądu gry na monitorach cz-b to masz całkowitą rację, a ja walnąłem bez sensu. Faktycznie robiąc grę na Atari nie jest niczym niezwykłym ani przesadnym zadbanie by dobrze wyglądała na archaicznym monitorze.
- 15: CommentAuthorAdam
- CommentTime24 May 2020 17:05
Mq:
Dzięki Adam za szczegółową analizę.

Po prostu większość napotykanych przez Ciebie dylematów graficznych mam za sobą, w ostatnich latach mocno analizowałem możliwe warianty rozwiązań problemu kolorów duszków ;)

Moim zdaniem Twoja postać w obecnej formie jest wystarczająco dobra. Nie ma wyrazistego konturu, ale starałeś się, aby kolorystycznie wyróżniała się na ekranie. Na pewno poświęciłeś już na nią dużo czasu.

Natomiast faktem jest, że im bardziej pójdziesz w kierunku rozdzielania planów tła na: bliski obramowany czernią oraz daleki w pastelowych kolorach bez czerni, tym mniej postać będzie pasowała do pierwszego planu.

Podsunąłem Ci opcję innego użycia playerów, bo nie wiedziałem, czy ją rozważałeś. Ma ona swoje wady: zmniejsza się precyzja rysunku, trudno jest w niej zrobić rozsądny antyaliasing - postać co prawda stałaby się kontrastowa i wyrazista, ale za to bardziej kanciasta i niektóre szczegółowe fragmenty (np. głowa) trudno byłoby "skonwertować" wprost, bez istotnych zmian.

Pamiętaj, że nigdy wszystkim nie dogodzisz, takie życie - teraz Nosty'emu nie pasuje brak konturu, ale jak dodasz kontur kosztem precyzji, to na pewno inny atarowiec powie, że poprzednio było lepiej... :D
- 16: CommentAuthorAdam
- CommentTime24 May 2020 18:05 zmieniony
Tak więc obecnie jest OK, ale... jeśli jednak jesteś zainteresowany poświęceniem swego czasu na sprawdzenie, czy nie da się lepiej, to istnieje kilka dodatkowych opcji do rozważenia :) Szczególnie JEŚLI nie zaplanowałeś jeszcze użycia missile'i (i np. postać nie ma rzucać jakimś kamieniem złożonym z pocisków):

Opcja A - tradycyjne użycie playerów + czarny kontur z pocisków:

Zostawiasz oryginalny pomysł użycia 4 playerów standardowej szerokości, natomiast zmieniasz rozłożenie kolorów w rejestrach tak, aby to czerń była przypisana do piątego koloru na planszy (tego w inwersie), ustawiasz opcję przypisania pociskom tego piątego koloru oraz GPRIOR bodajże na 1, tak aby pociski były pod playerami, a nad pikselami pola. Zostawiasz klatki animacji prawie bez zmian, jednak dokładasz czarne pociski jako obwódka/ czarne tło.

Oczywiście nie pokryjesz precyzyjnie 16 pikseli szerokości ośmioma pikselami pocisków, a fazy mają zmienną szerokość, dlatego rozsądne wydaje się przyjęcie założenia typu: czerń kładziemy pod głowę postaci oraz na jej cały przód w kierunku, w którym idzie. Im współrzędna X czarnego pocisku jest bliżej środka ciała, tym łatwiej jest użyć podwójnej szerokości (mniej widać jej kanciastość), natomiast na krańcach lewym czy prawym zwykle lepiej wygląda standardowa szerokość.

cdn.
- 17:
  
  CommentAuthorMq
- CommentTime24 May 2020 23:05
Adam, to co mówisz, że postać jest dobra, to chyba postawię sobie jednak za punkt wyjścia. Całą przygodę z pisaniem tej gry rozpocząłem właśnie od postaci. Zacząłem ją rysować w listopadzie 2019, a skończyłem pikselować animację chodu i stojącego Dude'a jakiś miesiąc temu. Obecnie mam już prawie skończone animacje skoków. Poświęciłem na to na prawdę masę godzin, pewnie zawodowiec ogarnął by to szybciej, ale nieskromnie powiem, że takiej postaci z tak rozbudowaną animacją jak moja na Atari jeszcze chyba nie było i taki miałem cel.

Teraz chciałem wziąć pod uwagę Wasze rady, które na pewno są dobre, ale już kilka osób odradziło mi wprowadzanie zmian w postaci, a wszystko sprowadziło się do powiedzenia, że "lepsze jest wrogiem dobrego". W grze jest kilka innych rzeczy, które można ulepszyć, i chyba jednak zostawię tą postać tak jak jest. Zacząłem sobie rysować jedną klatkę w koncepcji czarnego na wierzchu i rozszerzonych dwóch playerów kolorowych pod spodem, ale przy każdym pikselu, którego trzeba zmienić przypominam sobie jak godzinami siedziałem i przesuwałem każdy taki piksel w tę i z powrotem, żeby uzyskać ładny efekt naturalnego ruchu i widzę przy takiej próbie konwersji same problemy. Jednak odpuszczę tą drogę.

Opisana przez Ciebie opcja A też ma swoje istotne wady i rodzi kolejne problemy. Pomijając fakt, że missile planuję już użyć do czegoś innego, to z tym kolorem czarnym jako piąty nie jest tak prosto. Czarny jest mi potrzebny w bardzo wielu znakach w połączeniu ze wszystkimi pozostałymi kolorami, bo on robi kontury w całej grafice. Użycie go jako piątego wykluczyło by go z całej pierwszej połowy charsetu. A ja używam tych samych znaków z pierwszej i drugiej połowy, bo prawie wszystkie są mi potrzebne zarówno w wersji podstawowej, jak i w inwersie.

Nosty, Adam: z tą asertywnością, to też nie jest tak, że opieram się przed radami na zasadzie "nie bo nie". Po prostu kolejne koncepcje rodzą kolejne problemy. Zdaję sobie sprawę, że niektóre rzeczy można by zrobić inaczej, czy lepiej, ale zabrnąłem już na tyle daleko i tak wiele rzeczy jest gotowych, że teraz niektóre z tych zmian za mocno by mi wywróciły wszystko do góry nogami. W szczególności nie chciał bym np. przerysowywać całego charsetu znaków od nowa, albo przeprojektowywać wszystkich klatek animacji postaci. Teraz sobie jeszcze tak pomyślałem, że nawet zmiana koncepcji użycia graczy jako np. rozciągniętych, to było by masę roboty chociażby z tego względu, że zrobiłem sobie różne narzędzia "pomostowe" pomiędzy animacją rysowaną w Gale, a wygenerowanym ciągiem bajtów dla Mad Pascala. Musiał bym również te narzędzia robić od nowa. Ogólnie muszę chyba trzymać się pierwotnego planu, co nie wyklucza faktu, że coś tam jestem w stanie poprawić.

Zastanawiałem się na czym polega niespójność, na którą zwrócił uwagę Nosty, że postać sobie, platformy sobie, plan pierwszy i dalszy też sobie. Oglądałem długo to swoje dzieło myśląc i kombinując, i dopiero po tym co napisał Adam załapałem o co chodzi:
Natomiast faktem jest, że im bardziej pójdziesz w kierunku rozdzielania planów tła na: bliski obramowany czernią oraz daleki w pastelowych kolorach bez czerni, tym mniej postać będzie pasowała do pierwszego planu.

Wcześniej myślałem, że trzeba poprawić korony drzew i chmury, dodać czerni jeszcze do konturów tych rzeczy. Ale teraz myślę sobie że racja jest w tym co napisał Adam.
Muszę jakoś z tego wybrnąć i wziąć to pod uwagę przy dalszym rysowaniu, żeby uzyskać większą spójność. Tutaj dziękuję obu Panom za naprowadzenie mnie na to. Zobaczymy co da się zrobić.

Adam, jeżeli masz ochotę napisać cd. dot. dalszych opcji poza A, to chętnie poczytam, a też opisy tego typu przydadzą się na pewno innym osobom, które to czytają. Właściwie w tym wypadku prawdopodobnie nie będę jednak zmieniał znacząco swojej postaci, ale warto przeanalizować temat na przyszłość. Tak sobie myślę, że nawet traktując moje zabawy z grafiką jako niegrafika w kategorii błędów jakie być może popełniam, warto taką szkółkę informacji dla potomnych z tego pozostawić.
Nie upieram się przy postawie, że to wszystko co robię jest perfekcyjne, wręcz przeciwnie, chętnie dowiaduję się co myślą osoby znające się na temacie, jednak nie jestem w stanie na tym etapie wszystkiego wywracać do góry nogami, stąd wiele rzeczy i tak musi zostać tak jak jest, nawet jeśli wiem, że np. popełniłem jakieś tam błędy.
- 18: CommentAuthorAdam
- CommentTime24 May 2020 23:05
Druga opcja, na razie więcej nie będzie :)

Opcja B - alternatywne użycie playerów i pocisków ze zmienną szerokością

Stosujemy wariant podobny do tego, o którym pisałem wczoraj, jednak szerokość pikseli dostosowujemy do szerokości danej fazy ruchu (danej klatki animacji) - bo tylko część z nich rzeczywiście wymaga pełnej szerokości 16. Stojąca postać jest wąska i można ją narysować z większą precyzją, a podczas ruchu chwilowa mniejsza precyzja najszerszych faz nie będzie tak rzucała się w oczy.

Pociski w tym wariancie miałyby kolory odpowiadające playerom. Czyli "na górze" umieszczona jest stale ciemna obwódka (kontur) o poziomie jasności 0 lub 2 i szerokości maksymalnie 20, złożona z umieszczonych jeden po drugim P0, P1, M0, M1 (w przypadku Twojej postaci nie musisz użyć wszystkich), pod nią wyświetlamy resztę dostępnych sprajtów w trybie multikolorowości (P2+P3, M2+M3).

Jeśli szerokość postaci w danej fazie (bez obwódki) wynosi:
- do 10 pikseli: stosujemy P2+P3 standardowej szerokości, M2+M3 standardowej szerokości
- do 12 pikseli: P2+P3 standardowe, M2+M3 podwójne (albo jeden z pocisków standardowy, a drugi podwójny)
- do 16 pikseli: P2+P3 podwójne, do szczegółów któregoś z fragmentów wewnątrz szerokości 2 pikseli można użyć M2+M3 standardowej szerokości
- do 18 pikseli: P2+P3 podwójne, M2+M3 standardowe
- do 20 pikseli: podwójna szerokość P2+P3, M2+M3

Wymienionych wyżej wariantów jest dużo, ale w Twoim przypadku wystarczy, że podzielisz fazy ruchu swojego bohatera na dwie grupy: te nie przekraczające szerokością bez obwódki 12 pikseli oraz te pomiędzy 13 a 16.
- dla tych pierwszych P2 i P3 byłyby standardowej szerokości (a brakujące piksele w poziomie musiałyby być jakoś opędzone pociskami M2+M3)
- dla tych drugich P2 i P3 byłyby podwójnej szerokości, a jeśli jakiś detal jest kluczowy i nie powinien się zmienić podczas ruchu (twarz?), to wstawisz tam M2+M3 w zwykłej szerokości.

Tak czy siak: dużo roboty, nie wiem czy realnie jest sens poświęcać czas na kolejne próby - to już sam musisz ocenić.
- 19: CommentAuthorAdam
- CommentTime24 May 2020 23:05 zmieniony
@Mq: teraz dopiero przeczytałem Twój ostatni wpis (jak go publikowałeś, to byłem w trakcie pisania swojego) - tak, rzeczywiście w sytuacji, gdy chcesz użyć czarnego koloru w obrębie pełnego zestawu znaków, powyższa opcja A traci rację bytu. A jeśli masz już przewidziane inne zastosowanie dla missile'i, to w zasadzie obie opcje A i B są nieprzydatne...

Ale nie szkodzi - tak jak napisałeś: może coś się z tej dyskusji komuś przyda w przyszłości przy innym projekcie :)
- 20:
  
  CommentAuthorMq
- CommentTime25 May 2020 01:05
Adam, dziękuję za opis. To wszystko są bardzo dobre przykłady jak można kombinować z obiektami PMG. Zanim zacząłem projektować i tworzyć tą grę, też się zastanawiałem nad różnymi tego typu podobnymi wariantami. W pierwszej kolejności zanim zacząłem projektować postać, chciałem skomplikować to wszystko żeby wycisnąć więcej kolorów z PMG i miałem takie myślenie, żeby zrobić coś takiego, żeby ludzie zastanawiali się jak to w ogóle jest zrobione i jak to jest możliwe. Zagłębiałem się w tego typu warianty i wymyślałem coraz bardziej rozbudowane koncepcje.

Szybko jednak okazało się, że jak się tak mocno skomplikuje temat PMG, to mega trudno jest później projektować pod to animacje i przerabiać ją później do kodu programu. Animacja chodu Kolesia ma 10 klatek w prawo, drugie tyle w lewo, a przecież symetryczne odwrócenie postaci nie jest takie trywialne, bo jak jest wszystko odwrotnie, to są zupełnie inne liczby opisujące bajty, więc pomimo, że jest to taka sama z wyglądu klatka, to trzeba wszystko powyliczać na nowo. Animacje stojącego Kolesia, to kolejne 4 klatki w lewo i 4 w prawo. Skok 5 klatek w lewo i 5 w prawo. Będą też jeszcze inne ruchy. Łącznie do narysowania (wypikselowania) mam kilkadziesiąt klatek animacji. Wszystko to trzeba podzielić na playery, dodawać do siebie kolory itd. Jest trochę roboty.
Pomijając pracę przy rysowaniu, jak się skomplikuje PMG tak, że zmienia się w trakcie ruchu układ graczy i pocisków, to głowa się robi mała, żeby się w tym wszystkim połapać. Z kolei oprogramowanie tego ruchu zabiera też więcej cykli w przerwaniach na przełączanie tych klatek. Dalej idąc mam już procedury sprawdzające na czym postać stoi i jakich znaków dotyka, żeby ogarnąć kolizje. Przy stałych rozmiarach PMG procedury działają szybko, a przy zmiennych obliczenia znów się komplikują.
Z tych wszystkich powodów zdecydowałem się na połączenie bardzo proste wszystkich czterech graczy, nadanie im takich samych kolorów i już.
Na pewno da się to zrobić lepiej, ale przecież nie robię tutaj gry ostatecznej i jedynej, która miała by sprawić, że wszystkie inne gry na Atari już nie będą ważne, bo ta jedna zawrze w sobie wszystko co człowiek był w stanie wymyślić na Atari:-)
Poza tym jeszcze jedno istotne: zaczynając pisać tą grę, zastanawiałem się czy w ogóle będę w stanie wystarczająco szybko wyświetlić tło i PMG, żeby w ogóle móc myśleć o spełnianiu mojego marzenia o robieniu gry i czy to w ogóle będzie możliwe:-)

A w międzyczasie pochyliłem się trochę nad kwestią odcięcia pni drzew od koron na co zwróciliście uwagę. Poprawiłem to wykorzystując istniejące znaki i nie dokładając żadnego nowego. Wygląda to teraz tak jak na załączonych zrzutach. Jeszcze będę robił na pewno poprawki, ale taki jest kierunek tych zmian.
- drzewa.png
- 21:
  
  CommentAuthorpirx
- CommentTime25 May 2020 03:05
drzewa supcio
- 22: CommentAuthorkski
- CommentTime25 May 2020 06:05
Świetna animacja(!) i grafika. Kolory postaci rzeczywiście wyglądają “blado” na tle reszty, ale to typowe dla gier na Atari wykorzystujących trzy kolory na dwóch spritach (czasem zastanawiałem się czemu tak jest, dzięki dyskusji powyżej to do mnie dotarło).
Podejście aby nie przesadzać z komplikacjami ale dzięki temu skończyć grę w skończonym czasie prawidłowe. Sam jestem “kombinatorem”, niestety potem projekty się bardzo przeciągają a pary zużytej na grafice brakuje gdzie indziej.
Jeżeli gra będzie ciekawa to wszyscy zapomną o kolorach postaci. Jeżeli nie to żadna postać nie pomoże.
To normalne że ludzie komentują skoro opisujesz wszystko na forum, porady bywają cenne warto przeczytać ale jednocześnie to Twoja gra wszystkim nigdy nie dogodzisz.
- 23: CommentAuthorrosomak
- CommentTime25 May 2020 07:05
A wg mnie koleś wygląda jak typowy koleś, wszystko pasuje, bardzo się wyróżnia na plus, i generalnie animacja jest świetna, z grafiką nieco gorzej, ale to nic skończonego i powyżej są wyjaśnione powody, ja bym robił to na 128 kB ale to Twoja gra Mq. Powodzenia
- 24: CommentAuthorgorgh
- CommentTime25 May 2020 10:05
ja mam taką uwagę w kwestii legalności...wiadomo, że postać może postać, ale czy chodzenie postaci jest legalne? Ja bym to sprawdził, zanim wypuściłbym grę
- 25:
  
  CommentAuthormav
- CommentTime25 May 2020 10:05
gorgh - może wystarczy maseczka?
- 26:
  
  CommentAuthorMq
- CommentTime25 May 2020 11:05
Na razie chodzi po lesie, a w lesie nie trzeba maseczki:-) Poza tym nie spotyka się też na razie z nikim, tak że dystans społeczny zachowuje. Szerokość mapy wynosi 255 znaków, więc zalecam odpalać grę na wystarczająco dużym monitorze, na którym znak ma 0,8cm, żeby zachować dystans dwóch metrów w razie czego i nie chodzić maksymalnie na lewo ani na prawo:-)

Ponieważ mam sygnały, że część ludzi korzysta chętnie z moich opisów jako wiedzy z pola walki, którą ponoć nie dzieli się wielu twórców gier, to napiszę dla tych którzy nie wiedzą, na czym polega uzyskanie trzeciego koloru w sprite'ach i dlaczego jest to aż tak bardzo ograniczone.

W trybie 4 Antica, z którego korzysta większość gier (moja również), kolor opisany jest w rejestrach na 7 bitach, z czego 4 bity określają barwę, a 3 określają jasność. Ta sama zasada dotyczy koloru duszków. Duszek w całości ma zawsze jeden kolor, więc żeby uzyskać dwukolorową postać, to trzeba użyć dwóch duszków. Jest jeszcze możliwość uzyskania trzeciego koloru, poprzez nakładanie się na siebie pikseli dwóch duszków w dwóch różnych kolorach. Z tym że wpływ na ten trzeci uzyskany kolor jest bardzo ograniczony, ponieważ koloru tego nie możemy sobie bezpośrednio wybrać, a jest on tworzony operacją OR wykonaną na bitach dwóch kolorów nakładanych na siebie duszków. Dla uproszczenia pokażę jak wygląda dobór jasności kolorów i wynikowy kolor trzeci na tej podstawie. Z barwą jest to analogiczne.
Jak napisałem wcześniej jasność opisują tylko trzy bity.
Wykonując operację OR na bitach wynik mamy taki, że jeżeli jeden lub drugi lub oba z bitów mają wartość 1, to wynik jest 1. Natomiast 0 jest wynikiem tylko jeśli oba OR-owane bity mają wartość 0. Z tego wynika fakt, że jeśli jeden z kolorów będzie miał trzy jedynki, to bez względu na to jaki byśmy zrobili drugi kolor, to trzeci będzie miał też trzy jedynki. Z kolei jeśli jeden z kolorów będzie miał trzy zera, to kolor trzeci będzie identyczny jak kolor drugi. Poniżej takie przykłady, w których nie otrzymamy trzeciego koloru:

kolor1 111 000
kolor2 000 101
=
kolor3 111 101

Żeby trzeci kolor powstał, to bity dwóch pierwszych kolorów muszą się między sobą różnić. Dodatkowo, żeby wszystkie trzy kolory różniły się w sposób znaczący, to różnica między tymi jasnościami musi też być jak najbardziej znacząca.
Przykładowo jeśli zrobimy tak:

kolor1 110
kolor2 001
=
kolor3 111

To kolor pierwszy będzie miał jasność 6, kolor drugi jasność 1, a kolor trzeci jasność 7, więc będzie bardzo zbliżony do koloru pierwszego i w zależności od barwy i/lub monitora może ta różnica być praktycznie niezauważalna.

Podobna sytuacja jeśli zrobimy np. tak:
kolor1 001
kolor2 010
=
kolor3 011

Kolory uzyskają jasności 1,2,3 i wszystkie trzy będą bardzo ciemne, a różnicy między nimi nie będzie praktycznie widać.

W praktyce robi się tak, żeby kolor trzeci miał jasność maksymalną, czyli 7, a kolory pierwszy i drugi były maksymalnie od siebie oddalone. Czyli:

kolor1 010
kolor2 101
=
kolor3 111

Wówczas mamy jasności 2,5,7 i jest to najkorzystniejsza sytuacja jaką możemy osiągnąć, bo kontrast między trzema kolorami jest największy. Dodatkowo przy tej największej jasności kolor 111 jest praktycznie biały, więc zyskuje się wrażenie, że mamy inny kolor od pozostałych dwóch.
Można jeszcze zrobić tak:

kolor1 010
kolor2 100
=
kolor3 110

Wtedy uzyskamy jasności 2,4,6 jednak jasność 6 jest sporo ciemniejsza od 7, więc cała postać zrobi się ciemniejsza, kolory mniej kontrastowe. Tak wyglądają te wszystkie postaci z polskich gier lat 90-tych, gdzie mamy wszystko zielone, albo brązowe.

Jeśli chodzi natomiast o mieszanie bitów barw, to niestety jest tak, że wybierając którąś z "ładnych" barw, jeśli weźmiemy dwie różne, to trzecia wychodzi nam zwykle kompletnie nie pasująca, w kolorach sraczkowatych, albo zielonkawo-niebieskawych. Z tego powodu często postacie mają jeden kolor a manipuluje się tylko bitami jasności. Tak też ja zrobiłem wybierając odcienie fioletu, żeby zróżnicować postać od tła.
- 27:
  
  CommentAuthorMq
- CommentTime25 May 2020 12:05
@rosomak: oszczędności, które robię nie są bez powodu. Ograniczenie do zestawu znaków na typ lokacji (np. las) narzuciłem sobie dlatego, że świat ma być duży, na pewno powyżej 100 ekranów, a las jest tylko jednym z typów lokacji, których z kompletnie różną grafiką będzie około 7. To co widać w tech-demo, to jest tylko jedna z lokacji lasu, a będzie ich kilka. Taka z grubsza jest zakładana budowa świata gry.

Dodatkowo w każdym typie lokacji będzie inna muzyka, to co gra, to są tylko zapętlone dwa patterny zrobione dla testu wydajności silnika, ale muzyka będzie dłuższa, w granicach normalnych utworów kilkuminutowych zapętlonych.

Na razie mam jeszcze masę wolnej pamięci, ale od początku cisnę najmocniej jak mogę, żeby oszczędzać. Nie zakładam, że wszystko ma się na 100% zmieścić na raz w stockowym sprzęcie, ale chciałbym, żeby docelowo grę dało się odpalić jak największej ilości użytkowników. Mniej-więcej wiem ile co zajmie, ale dokładnie nie, bo gra się rozwija jeszcze w trakcie tworzenia.
Dlatego na razie jak najdłużej chcę robić pod stock Atari, a jak się miejsce skończy i jak będę już dokładnie widział co ile zajmuje, to podejmę decyzję jakie wersje ostateczne powstaną. Na pewno będę chciał zrobić wersję plikową udostępnioną w całości za darmo. Ta wersja prawdopodobnie będzie wymagała rozszerzonej pamięci, a do ilu kB, to zobaczymy ile będzie zawartości. Na pewno też będę chciał zrobić wersję kartridżową, która ma działać na stockowym Atari z 64kB RAM. Rozważałem też wersję z doczytywaniem z dyskietki, ale mam tu na razie mieszane uczucia, bo rozważam całkowite wyłączenie OS-u i olanie DOS-a, co uprości mi wiele spraw z zasobami pamięci i da więcej przestrzeni oraz oszczędzi pisanie procedur obsługi dyskietek, obsługi błędów przy doczytywaniach itd. itp.
- 28: CommentAuthorxxl
- CommentTime25 May 2020 12:05
mozesz tez rozwazyc skompresowane dane w pamieci. z grafika ( a dzwiekiem jeszcze bardziej) mozesz skrocic dane nawet o 50% przy czym szybkosc dekompresji z pamieci jest moim zdaniem calkiem ok.

same procedury dekompresji sa bardzo krotkie (mozna je jeszcze skrocic lub przyspieszyc w zaleznosci od potrzeb) te dekompresuja z pliku ale ponizej masz procedure ktora nalezy zamienic i bedzie dekompresja z pamieci:

->link<-
->link<-
- 29: CommentAuthorzbyti
- CommentTime25 May 2020 12:05 zmieniony
@Mq dzięki za wykład, jestem jedną z tych osób, które się zastanawiały jak to działa, więc Twój wpis jest dla mnie "jak znalazł" :]
- 30: CommentAuthorxxl
- CommentTime25 May 2020 12:05 zmieniony
1.
Na pewno będę chciał zrobić wersję plikową udostępnioną w całości za darmo. Ta wersja prawdopodobnie będzie wymagała rozszerzonej pamięci

2.
Na pewno też będę chciał zrobić wersję kartridżową

3.
Rozważałem też wersję z doczytywaniem z dyskietki

wlasciwie to moze byc jedna i ta sama wersja: (1) - plik, ktory zaladuje do bankow pamieci ramdysk z juz zapisanymi plikami (zwkly atr zaladowan do ext ram), wszelkie operacje I/O z ramdyskiem. (2) - atr zapisany na kardrydzu - byly juz tak preparowane komercyjne wydania. (3) - wersja wyjsciowa.
- 31:
  
  CommentAuthorMq
- CommentTime25 May 2020 13:05 zmieniony
Dzięki xxl za podpowiedzi. Rozważam kompresję danych, ale na razie wygodnie pracuje mi się na bezpośrednich danych niekompresowanych, bo szybko można podmieniać np. grafikę i testować. Niemniej faktycznie krótkie są te procedury dekompresji, a danych będę miał bardzo dużo, więc na pewno udało by się sporo zaoszczędzić. Dodatkowo może to pomóc w wygodnym bankowaniu danych w pamięci rozszerzonej lub na kartridżu, bo nieskompresowana mapa maksymalna jaką założyłem zajmuje 255x24= 6kB plus charset 1kB. Możliwe, że po skompresowaniu udało by się mapę z charsetem zmieścić zawsze w banku 4kB, co (tak sobie myślę) dało by dużą wygodę w grupowaniu i przechowywaniu danych na kartridżu i doczytywaniu takich lokacji w całości zawsze w ten sam sposób. Zakładam użycie kartridża z bankowaniem po 4kB, bo mam taki kartridż już opracowany swojej własnej konstrukcji i tak też rozplanowuję już od początku mapę pamięci, żeby mi pod niego pasowało wszystko.
No chyba, że jednak będę doczytywał z plików, wtedy powyższe nie ma znaczenia, a zainteresował mnie patent z wczytaniem do pamięci rozszerzonej RAM-dysku całego gotowego z plikami. Rozważam też użycie xbiosa, bo wtedy bardzo możliwe, że załatwił bym jednym ruchem trzy tematy:
- jedna wersja dla dyskietki/kartridża/ramdysku
- kompresja/dekompresja w locie
- więcej RAM-u bez OS-a i DOS-a
To wszystko na razie rozważania, wszystko zależy jak się rozwinie gra i co będzie ile zajmowało oraz jaka ostatecznie będzie mapa pamięci, a to wszystko wychodzi mi w praniu.
- 32: CommentAuthorxxl
- CommentTime25 May 2020 14:05
w zalaczniku kompresor - sproboj nim skompresowac jakis przykladowy blok danych. nie bedziesz sie musial zastanawiac czy to wlasciwy kierunek...
- apultra.exe
- 33:
  
  CommentAuthorMq
- CommentTime25 May 2020 15:05
Dzięki, przetestowałem ten kompresor. Wyniki są obiecujące.
- fonty, których używam kompresują się około o połowę
- muzyka rmt kompresuje się też około o połowę
- mapa grafiki lasu też około połowę
- teksty trochę słabiej, ale o 1/3 to też sporo

Krótko mówiąc wszystkie dane każdej lokacji powinny się skompresować zawsze mniej-więcej o połowę, a więc wygląda to faktycznie bardzo dobrze.
- 34: CommentAuthorCharlieChaplin
- CommentTime25 May 2020 17:05
What's the requirement for apultra.exe ?!? A PC with 64Bit OS ?

(Windows XP 32Bit reported that this is not a 32Bit application, did not test with Win 7 32Bit nor under 8Bit or 16Bit OS. Alas, I don't have 64Bit OS...)

35: CommentAuthorzbyti
CommentTime25 May 2020 17:05 zmieniony

@CharlieChaplin

apultra command-line tool v1.0.8 by Emmanuel Marty and spke
usage: apultra.exe [-c] [-d] [-v] [-r] <infile> <outfile>
        -c: check resulting stream after compressing
        -d: decompress (default: compress)
   -cbench: benchmark in-memory compression
   -dbench: benchmark in-memory decompression
     -test: run full automated self-tests
-quicktest: run quick automated self-tests
    -stats: show compressed data stats
        -v: be verbose

Screenshot_2020-05-25_17-45-20.png

- 36:
  
  CommentAuthorDracon
- CommentTime8 Jun 2020 00:06
@Mg
Raz jeszcze dziękuję za info o TILED'zie. :)
Faktycznie jest to dość intuicyjny edytor.

Mam jeszcze pytanie jak to jest z mapami w ramach jednego poziomu gry (np. kilka ekranów-map).

Czy można powiązać je jakoś ze sobą w tym programie - trzymając razem i przełączając?
Czy raczej za każdym razem trzeba zamknąć poprzednią mapę i zacząć nową (rozszerzenie .tmx) choć korzysta ona z tych samych "kafelków" co poprzednia mapa? :o
- 37:
  
  CommentAuthorjhusak
- CommentTime8 Jun 2020 07:06 zmieniony
Bajty postaci przy chodzeniu w drugą stronę odwraca się w locie 256 bajtową tablicą. Stary bajt do x, a nowy lda tab, x i już.
- 38:
  
  CommentAuthorMq
- CommentTime8 Jun 2020 09:06
Dracon, nie wiem tego czy da się wiązać jakoś mapy. Szczerze mówiąc ja na razie cały czas rysowałem tylko jedną mapę, więc się nad tym nie zastanawiałem. Planowałem przy rysowaniu kolejnej mapy z takimi samymi tilesami po prostu skopiować plik .tmx żeby mieć od razu gotowe wszystko, i tylko wyczyścić zawartość mapy i rysować kolejną w kolejnym skopiowanym pliku i już.
Całość projektu zapisana jest tylko w dwóch plikach: tmx oraz tsx, w którym jest opisany plik graficzny (np. png) z tilesami. Dla wszystkich map można mieć jeden i ten sam tsx, a powielać tylko tmx sobie dla kolejnych map.

Kuba! Dzięki za hint! Takie proste, a ja na to nie wpadłem:-) Kombinowałem jak to zrobić "skomplikowaną" matematyką, ale nijak nie mogłem wymyślić i odpuściłem poświęcając pamięć na symetryczne klatki postaci kosztem zyskania na szybkości i prostocie działania. Pomysł z tablicą symetrycznych odpowiedników wszystkich kombinacji bajtów jest super:-) Przy dużej ilości klatek animacji, to będzie bardzo duża oszczędność. Będę musiał jednak bardzo mocno przerobić wszystkie procedury w Mad Pascalu na potrzeby tego, ale myślę, że będzie warto. Dzięki raz jeszcze.
- 39:
  
  CommentAuthorCOR/ira4
- CommentTime8 Jun 2020 11:06
Kuba to spec,zna się na problemach,kiedyś nawet Jasiowi pomógł ... :D...
... a nie,zaraz ! to nas czyli graczy wkręcił w Jasiową pomoc !
;) :).
- 40:
  
  CommentAuthorMq
- CommentTime9 Jun 2020 13:06
Kuba, Twoja podpowiedź, to jest najlepsza rzecz optymalizacyjna jaka mogła mi się przydarzyć w tej mojej produkcji:-)

Popracowałem nad tym kilka godzin i efekty są piorunujące:-)
Dołożenie tablicy 256 bajtów dla mirrorów to jedyna inwestycja pamięci, natomiast odpowiednia rozbudowa procedur żeby obsłużyć obracanie grafiki skompensowała się z kolei ze skróceniem procedur obsługi joysticka i ruchu postaci, bo kierunki obsługiwane są jedną procedurą, a tylko zapis zmiennej odpowiadającej za mirror (boolean) odpowiada za to czy ruchy są w prawo czy w lewo.
Wyrzucając podwójne klatki animacji bohatera już zyskałem na tym jakieś 3,5kB. W grze nie mam jeszcze narysowanych wszystkich klatek animacji, więc jak dołożę kolejne, to zysk jest niebagatelny. Dodatkowo z tej samej metody i tej samej tablicy skorzystam na dalszym etapie prac, robiąc przeszkadzajki i inne elementy graficzne, więc zrobiło mi się mnóstwo dodatkowego miejsca na dalszą pracę.
Super optymalizacja:-) Jest moc, dzięki raz jeszcze:-)
- 41:
  
  CommentAuthorjhusak
- CommentTime9 Jun 2020 13:06 zmieniony
Kliknij pomógł :D
W Amaurote tak robili bracia Pickford, ja z kolei odwracałem z powrotem, aby przyspieszyć, bo zbyt dużo było ruchomych elementów na ekranie na raz.
Z ciekawostek jeszcze w LastNinja2 była kompresja postaci, typu. 0xxxxxxx - przepisz następne xxxxxxx bajtów, 1xxxxxxx, skopiuj xxxxxxx razy następny bajt. To skróciło dane postaci o połowę, ale w przypadku pamiętania bitmapy postaci i wypisywaniu pionowo.

@irata4 :D
- 42:
  
  CommentAuthorMq
- CommentTime9 Jun 2020 16:06
Fakt jest taki, że ta symetria przez tablicę trochę spowalnia całość, bo jednak dla każdego bajtu trzeba wykonać dodatkowy rozkaz lub dwa, więc razy ilość bajtów playera (u mnie 64 wraz z maskowaniem przesunięcia w pionie) i razy 4 playerów, to się robi sporo instrukcji/cykli. Jednak przekalkulowałem, że przynajmniej główną postać warto mi w ten sposób robić, bo animuję ją tylko raz na trzy ramki, więc nawet jak zajmie mi to cały czas przerwania VBL, to i tak wolę tak kosztem zaoszczędzonej pamięci.

Na tą chwilę mieszczę się w przerwaniu VBL tak że zdążam przed wyświetlaniem kolejnej ramki.
Wymyśliłem sobie jednak, żeby zrobić tak, żeby był bufor z gotową narysowaną aktualną klatką animacji. Już taki bufor zrobiłem i przetestuję czy to się opłaca. Pomysł jest taki, że ponieważ animacja postaci jest co trzy ramki, to mam trzy ramki na przygotowanie gotowej klatki animacji. Może być warto podzielić przygotowywanie aktualnej klatki i robić to sobie po kawałku przez dwie ramki odwracając np. pierwszych dwóch playerów w pierwszej ramce, drugich dwóch w drugiej ramce, a w trzeciej wyświetlić już gotowy bufor. Takie podejście zrównoważy mi obciążenie w poszczególnych ramkach, więc spokojniej będzie z dokładaniem później dalszych funkcjonalności.

Muszę też od tej pory pamiętać, że chodzenie w prawo zajmuje mniej czasu procesora niż chodzenie w lewo, więc jakieś przyszłe funkcjonalności być może da się dołożyć żeby wykonywały się tylko podczas chodzenia w prawo:-)
- 43:
  
  CommentAuthorshanti77
- CommentTime9 Jun 2020 16:06
Możesz mieć 2 duszki odwrócone a 2 nie, wtedy przy rysowaniu ruchu w lewo lub prawo obracasz zawsze tylko w duszki i zajmie to w obu kierunkach tyle samo czasu.
- 44:
  
  CommentAuthorMq
- CommentTime9 Jun 2020 19:06
@shanti77 ten pomysł ze zrobieniem dwóch duszków odwróconych jest też bardzo dobry.

Nasunęło mi to jeszcze dalszy pomysł, żeby dodatkowo zamieniać duszki miejscami przy zmianie kierunku, bo dotychczas miałem tak, że wszystkie duszki są ułożone zawsze tak samo, a ja zamieniam miejsce przerzucania danych. Zamiana duszków spowodowała by, że zawsze te same dane trafiały by do tych samych duszków, tylko odwrócone lub nie. Muszę jednak posprawdzać jak to się będzie miało do wszystkich innych procedur związanych z liczeniem pozycji na mapie, kolizji itp.
- 45:
  
  CommentAuthorDracon
- CommentTime14 Sep 2020 23:09
@Mq
To ja znowu pytam o TILED. :)

Bawię się nim od czasu do czasu i niestety mam
zamieszanie z przenoszeniem/trzymaniem plików danego projektu (układu map z odpowiadającym im fontem). :(
Chodzi dokładnie o to, że programista dostaje ode mnie plik(i), którego nie może potem prawidłowo załadować.

Próbuję wszystko trzymać w 1 folderze, zapisywać
w roboczym formacie (np. "nowytest.tiled-project") ale nadal druga osoba nie może tego otworzyć i oglądać. :(
Jak sobie z tym radzisz/radziłbyś?

TILED mam w najnowszej, aktualnej wersji tj. 1.4.2.
- 46:
  
  CommentAuthorMq
- CommentTime15 Sep 2020 18:09 zmieniony
Dracon, obawiam się, że niewiele pomogę. Ja używam Tiled tylko sam i nie przenoszę nigdzie plików. Jednak dziwię się, że masz problemy, bo w sumie to te pliki są bardzo proste, skonstruowane w xml i wystarczy zajrzeć do środka choćby notatnikiem i można sobie w takim xml ręcznie wszystko sprawdzić, czy wyedytować. Może masz tam jakieś ścieżki pełne podane i stąd problem z otwarciem na innym kompie?
Jedyne co, to ja u siebie przenosiłem kiedyś w obrębie kompa cały projekt w zupełnie inne miejsce, ale z tego co pamiętam, to przeniosłem po prostu cały folder z zawartością i chyba działało bez żadnych kombinacji.
Ja też muszę zaznaczyć, że ja nie korzystam w jakiś zaawansowany sposób z Tiled. Ja tylko robię sobie zwykłym Paintem plik png z Atarowym zestawem znaków i w obrębie projektu Tiled rysuję tylko pojedynczą mapę tym jednym zestawem znaków w jednym pliku png.
- 47:
  
  CommentAuthorsun
- CommentTime15 Sep 2020 20:09
W nawiązaniu do tego co pisze Mq - trop ścieżek itd.
Jak ktoś używa windowsa, to jest takie coś jak junction (https://docs.microsoft.com/en-us/sysinternals/downloads/junction - ogólnie cały pakiet toolsów jest ciekawy), co jest czymś na kształt unixowych symlinków. Jak mam jakieś zawirowania ze ścieżkami w projektach, to robię sobie symlinki i zawsze działa.
Ale czy to remedium na ten przypadek?
- 48:
  
  CommentAuthorMq
- CommentTime15 Sep 2020 23:09
Sprawdziłem jeszcze teraz na kompie jak to u mnie wygląda.

Cały mój projekt składa się tylko z trzech plików:

1. pliku png, w którym mam swoje tilesy (odpowiednio narysowany font dla Atari)

2. pliku tsx, który zawiera informacje o tilesecie, więc w nim jest ścieżka do tego pliku png - ale u siebie mam tu tylko nazwę pliku bez ścieżki, bo wszystko jest w lokalnym tym samym folderze

3. plik tmx, w którym jest rysowana mapa i tutaj z kolei jest podana ścieżka do powyższego pliku tsx, u mnie jest to też sam plik bez ścieżki, bo trzymam te trzy pliki wspólnie w jednym folderze

I teraz te trzy pliki z tak wprowadzonymi ścieżkami (czyli w sensie że nie ma ścieżek) mogę sobie przenosić w dowolne miejsce i zawsze wszystko działa dobrze. Projekt otwieram po prostu kilkając dwa razy w plik tmx i on się otwiera w Tiled.

Zrobiłem jeszcze test: skopiowałem sobie te trzy pliki do nowego folderu i zmieniłem im wszystkim nazwy na dupa.png, dupa.tsx i dupa.tmx. Następnie w plikach tsx i tmx poprawiłem notatnikiem ścieżki na odpowiednie pliki dupa.png i dupa.tsx. Odpaliłem projekt dupa.tmx i wszystko działa poprawnie. Ja tak robię ze światami do Kolesia, bo zmienia się grafika, czyli font, ale każdy świat ma takie same gabaryty, więc po prostu zamiast robić nowy projekt w Tiled, to kopiuję sobie stary i podmieniam tylko font, kasuję wszystko i rysuję od nowa.

Dla uściślenia światy w Kolesiu nie mają identycznych rozmiarów, ale rozmiar maksymalny jest identyczny, więc jak robię mniejszy świat, to po prostu zmniejszam tylko np. szerokość już w samym projekcie. W kodzie Kolesia zrobiłem sobie tak, że mogę podawać światy o różnych rozmiarach, a procedury same sobie dopasowują pole gry odpowiednio do świata, żeby np. Koleś nie wychodził poza jego granice.

Jak już o grze mowa, to prace idą do przodu, ale sama gra na razie niezbyt mocno: zrobiłem masę optymalizacji kodu pod kątem zarówno szybkości działania, jak i miejsca w pamięci Atari, zrobiłem trochę poprawek graficznych, dodałem animacje brakujących klatek Kolesia i popracowałem mocno nad skokami i sterowaniem, tak że teraz bohater skacze trochę wyżej i dalej, a skok jest o wiele lepiej sterowalny. Mam już też zrobione mechanizmy zbierania przedmiotów, animowane elementy tła, zaczęte też animowane przeszkadzajki. Dorysowałem kolejne elementy świata w grze i powiększyłem go. Rozpracowałem też używanie efektów dźwiękowych w trakcie gry i zrobiłem testy z dźwiękami.
Nie będę tego wszystkiego na razie pokazywał, plan jest taki, że chcę dokończyć całą mechanikę gry i zrobić kawałek świata w formie takiej już w pełni gotowej z gotową muzyką i efektami dźwiękowymi. Będzie to w pełni działający i kompletny fragment gotowej gry, który chcę udostępnić jako taki grywalny trailer. Mam nadzieję trailer udostępnić jeszcze w tym roku, natomiast gotową grę chciałbym ukończyć w roku 2021, ale kiedy dokładnie, to jeszcze nie wiadomo, bo roboty z tym wszystkim jest jeszcze sporo...
- 49:
  
  CommentAuthorDracon
- CommentTime19 Sep 2020 22:09 zmieniony
@Mq, Sun:
Dzięki Panowie, przyjrzę się temu, rozważę sugestie i podpowiedzi.

Trochę szkoda, że w TILED autor nie zrobił takiego formatu spakowanego (jak ma bodajże commodorowski CHARPAD), aby nie męczyć się z linkami.
Faktycznie miałem takie "twarde" linki do katalogów na twardysku i one się "magicznie" nie aktualizowały u drugiej osoby, niestety. :|

@Mq: tak, dobrze się domyśliłeś, pytanie o stan deweloperski DUDE'a był też tak przy okazji, dzięki. :)
- 50:
  
  CommentAuthorsun
- CommentTime20 Sep 2020 12:09
Generalnie taki edytorek powinien mieć linki, jak to się mówi, względne w ramach katalogu z projektem. Trzeba albo zgłosić ficzer rikłest albo zrobić brancza, poprawić i zgłosić do merdża.

Od 51 do 100 z 113