Skocz do zawartości

Czołg Krymski

Użytkownicy
  • Zawartość

    823
  • Rejestracja

  • Ostatnia wizyta

  • Wygrane w rankingu

    5

Ostatnia wygrana Czołg Krymski w Rankingu w dniu 5 Wrzesień

Czołg Krymski posiada najczęściej lubianą zawartość!

Reputacja

33 Mała Cegła Społeczności

3 obserwujących

O Czołg Krymski

  • Tytuł
    Mistrz żenującego żartu
  • Urodziny 31.10.1998

Contact Methods

  • Website URL
    http://

Previous Fields

  • Nagrody
    Najlepszy przykład (CA 2015)
  • Użytkownik GameMaker Studio 2
    Nie
  • Użytkownik GameMaker Studio
    Nie
  • Użytkownik GameMaker 8
    Nie
  • Użytkownik GameMaker 7 i wcześniejszych wersji
    Nie
  • Użytkownik Unity
    Nie
  • Uytkownik Godot
    Nie

Profile Fields

  • Skąd
    Szczecin
  • Płeć
    Male

Ostatnie wizyty

20745 wyświetleń profilu
  1. Nad czym aktualnie pracujesz?

    @I am Lord hmm, zawsze używam proporcji 1 pixel sprita = 1 pixel w grze, także nie wiem gdzie tu jest dysproporcja. Chociaż w sumie tylko odległe i duże obiekty czasem rysuję w znacznie mniejszej rozdziałce, żeby nie zgubiły tej pixelowatości np chmury i słońce. Ale i tak prawda jest taka, że pixel art w 3D aż tak nie musi dbać o proporcjonalność tekstur, bo perspektywa potrafi i tak łatwo burzyć spójność. Gdzie widzisz jakiś brak proporcji? @Ignatus a dziękuję bardzo serdecznie. Szczerze to daję takie mocne 80%, bo pierwszy raz rozpisałem scenariusz na 5 stron i pierwszy raz mój projekt od środka trzyma się organizacyjnie kupy. Co prawda za 5 dni się studia zaczynają, także mniej czasu będzie. Tak btw. mówiłem o ASP łódzkim parę miechów temu, ale w ostateczności stwierdziłem, że wzornictwo na Politechnice Łódzkiej będzie bardziej w mój smak, bo chcę się rozwijać dizajnersko i artystycznie, ale warto i zadbać o pierwiastek nauk ścisłych. I nie wiem czemu uparłem się na Łódź, pewnie ostro tego pożałuję, bo jednak jedno z najbrzydszych miast. I mam 8 chłopaków na roku, także nie wiem czy się cieszyć, czy płakać
  2. Nad czym aktualnie pracujesz?

    dobra, zdecydowałem się jednak na mgłę. Trochę ciężki orzech dla mnie z tą grafiką i nadal nie wiem, czy jestem z niej zadowolony, czy też mnie obrzydza. Raczej już kwestia gustu, a z minimalizmem ciężko jest trafić do wszystkich, ale działam dalej. Tutaj parę nowych screenów z wieżyczką obserwacyjną i automatycznym oddaleniem kamery, małym wodospadem i krzywymi powiewającymi flagami (jakoś lubię je estetycznie) http://imgur.com/a/IbwcV Poza tym eksperymentuję z muzyką i myślę nad losowym jej generowaniem jeżeli już mam tak garściami się Proteusem inspirować. To pozwala na mniejszy nakład pracy i większą interakcję z otoczeniem tj. mogą dochodzić kolejne instrumenty pojawiając się w różnych lokacjach, co się świetnie komponuje. Tutaj jest jej aktualny stan - http://gmclan.org/uploader/7193/muzyka_proba.mp3
  3. jeżeli chodzi o samo symulowanie trójwymiaru to tak jak Threef powiedział wszystko ogranicza się do split screenu i dwóch kamer. Problemem jest po prostu sterowanie. Na pewno da się napisać jakiś DLL co by dekodował sygnał z akcelerometru/żyroskopu z Oculusa, ale chyba nikt czegoś takiego jeszcze nie zrobił, dlatego trzeba by było po prostu ograniczyć sterowanie do samej myszki jak w normalnym fpsie. Tutaj jest jakiś prosty przykład z neta http://www.mediafire.com/file/dbgtdvon94077jk/GM+VR+custom+HMD.gmk Tak czy inaczej może pytanie trochę infantylne, ale jak chcesz coś takiego zrobić, to nikt Ci nie broni Jakieś gogle VR masz ogólnie, by móc sobie to testować? Jak masz np tylko takie na komórkę, to i tak nie ma większego problemu, by streamować obraz z komputera na ekran smartphona.
  4. Nad czym aktualnie pracujesz?

    W sumie to nic wielkiego. Używam po prostu na swoją korzyść tego jak bardzo draw_set_alpha jest w D3D spartaczona przez depth Więc po prostu rysuję głęboko pod wszystkim dwuwymiarową animowaną płaszczyznę, a przezroczysty obiekt 3D o ile ma depth większy od reszty obiektów, przepuszcza przez siebie tylko tę animowaną warstwę co daje taki efekt. A teraz sprawa ma się tak, powoli dalej to pielęgnuję, wszystko się kupy trzyma, ale zastanawia mnie czy dodanie mgły jest dobrym rozwiązaniem. Dzięki niej niby łatwiej jest widzieć ukształtowanie terenu i pod niektórymi względami ma swoje walory estetyczne, ale nie wiem czy nie gryzie się z ostrością palety barw. Która wersja lepsza? No i jeszcze tam altankę dodałem, która służy do przemieszczania się między roomami
  5. Animacje postaci

    @SimianVirus7 no to trzym tutaj http://www.host-a.net/u/zacnie/animacja.rar ogólnie przyznam, że gdy zrozumiesz naturę sinusów i cosinusów to całkowicie zmieni się twoje spojrzenie na gamemakerowanie. Szczerze to nie ma chyba żadnego aspektu przy tworzeniu gry, gdzie nie można byłoby ich wykorzystać. Orbitowanie obiektów, ruch wody, cykl dnia i nocy, symulowanie fizyki (np sprężystość podłoża). Do tego umiejętnie używając sinusa przy pitchu jakiegoś dźwięku można uzyskać świetne vibrato. Są też sytuacje, gdy chcąc przemieszczać obiekt w różne kierunki zamiast direction i speed można również posłużyć się trygonometrią, przez co ma się lepszy wgląd w to jak ten ruch naprawdę się odbywa i łatwiej wtedy łączyć dwa ruchy ze sobą (wypadkowy wektor). No i na zakończenie taka moja rada - jak możesz gdzieś użyć sinusa, to go użyj
  6. heightmap po zmianie roomu

    dobra @I am vader, zwracam całkowicie honor i chylę czoła. Twój przykład co przesłałeś mi nie działał należycie, ale analogicznie używając surface'ów i screen_refresh() u siebie w projekcie wszystko zaczęło jednak śmigać I do tego wszystko jest diabelnie idealne teraz. Wcześniej gdy mi chwilę działało po prostu dbałem też o to, by w czasie tworzenia terraina nic innego się nie rysowało i dlatego wyświetlała się heightmapa na chwile w rogu. A teraz nawet mając zawalone całe gui i bez wyłączania D3D wszystko działa. Ciężko mi nadal ogarnąć czemu ten terrain_create() był tak na wszystko czuły i wybredny, ale naprawdę serce się raduje, że w końcu mam to z głowy. Więc panowie @I am vader i @I am Lord jestem wam wdzięczny całym sobą i dzięki, że ten temat nie umarł bez rozwiązania. A co do przeniesienia projektu do gms - oczywiście próbowałem, ale w studio tekstury są zupełnie inaczej przetwarzane. Ja lecę tradycyjnie, tekstury o wymiarach w potęgach dwójki, więc każdy sprite składający się na model gracza jest w tych samych wymiarach, ale po prostu jest dużo pustki. Może mało to wydajne, ale to i tak wciąż parę pixeli i bardzo ułatwia pracę. W Studio ta pusta przestrzeń w ogóle nie jest brana pod uwagę i automatycznie "wycina" ją z tych sprajtów, przez co wszystko się kiełbasi. Poza tym alpha w 3D też już trochę inaczej chyba działa, a do udźwiękowienia używam DLLa, których też inaczej się używa w gms. Ogólnie trzeba by było przepisać wszystko na nowo i nie wiem czy gra warta świeczki, bo po rozwiązaniu teraz tego problemu z heightmapą, ósemka powinna mi już całkowicie wystarczyć. Zbyt się przyzwyczaiłem do niej. Żałuję tego, ale co zrobić
  7. Kolizje 3d

    Jezeli uzywasz tylko scian do siebie prostopadpych, to mozesz po prostu w kolizji ze scianą dlugą w Y zostawic samo x=xprevious i analogicznie dla sciany dlugiej w X
  8. Animacje postaci

    nie no, jeżeli naprawdę jesteś rocznik 97, to siłą rzeczy musiałeś trochę tej wiedzy na matmie zgłębić. Szczerze mówiąc co jak co, ale podstawowa licealna matematyka jest jak najbardziej na miejscu jeżeli chodzi o tworzenie gier. Ale jedynie starczy ci szczątkowa znajomość właśnie trygonometrii i układu kartezjańskiego. To całkowicie starcza, by sprawnie się game makerem posługiwać na moje oko. Jeżeli rozumiesz naturę sinusoidy i masz przestrzenne wyobrażenie jak można ją przekształcać to nie miałbyś z tym najmniejszego problemu. A animowanie przy jej użyciu jest naprawdę proste. Przykładowo jeżeli do poruszania postaci wykorzystujesz zmienną speed, to starczy stworzyć jakąś nową zmienną od animowania np. tułowia postaci (anim=0;). Później w stepie starczy wpisać coś pokroju anim+=speed, a później rysując tułów w draw wystarczy do współrzędnej Y dodać coś w ten deseń: draw_sprite(tulow_spr,0,x,y+sin(anim/20)*20). I teraz sprawa wygląda tak - dziedzina sinusoidy jest zawsze w radianach, czyli jednostkach opartych na pi. Pełen okres sinusoidy wynosi 2 pi, czyli około 6,28. Teraz na chłopski rozum jeżeli speed gracza wynosi mniej więcej 3, to wyciągając sinus z anim ta sinusoida wykona pełen okres w ciągu zaledwie około dwóch stepów (2 pi/3), więc zdecydowanie za szybko. Dlatego trzeba zwykle podzielić to anim na jakąś sensowną liczbę, w tym przypadku 20. Wtedy zakładając, że prędkość rooma to 60, teraz sinusoida wykona jeden okres po mniej więcej właśnie 60 stepach, czyli sekundzie. Do tego starczy pamiętać, że amplituda sinusoidy wynosi 1 (czyli przyjmuje wartości od -1 do 1), więc jeżeli chcesz, by w tej animacji tułów wychylał się np na 20 pixeli, to mnożysz tego sinusa razy dwadzieścia. I to naprawdę wszystko, jeżeli coś pamiętasz ze szkoły to spokojnie szybko to łykniesz i będziesz się tymi sinusami posługiwał biegle. Do tego strasznie to satysfakcjonująca rzecz moim zdaniem :). Wielkim plusem takiego rozwiązania jest też to, że prędkość animacji jest już wtedy automatycznie uzależniona od prędkości gracza, a dodatkowo jeżeli gracz porusza się do tyłu (speed<0), to animacja również automatycznie się odwraca. Dobra, nie mam daru tłumacza, ale mogę szybko wykonać jakiś prosty przykład w game makerze 8.0. animacja.gmk
  9. heightmap po zmianie roomu

    nie, użyłem tylko tego screen_refresh. Ale i tak już nieważne, bo znowu przestało działać i chuj wie kompletnie czemu. Daję już sobie spokój, nie mam nerwów.
  10. Animacje postaci

    wszystko w animacji jest względne. GM:S wspiera animowanie w Spine, także to zawsze jest jakaś droga. Ale jednak animowanie szkieletowe wymaga sporo zaangażowania, żeby nie trąciło jakąś tanią flashówką. Pixel art to wiadomo animowanie klatka po klatce i również są do tego dobre softwary, ale często edytor spritów w GM starcza do wielu zadań. Z własnej autopsji jednak pokochałem animacyjny minimalizm powiedzmy i uwielbiam animować przy pomocy trygonometrii. Starczą dwa osobne sprity na nogi i jeden na tułów i przekształcając wartość speed przy pomocy sinusów i uzależniając od tego np image_angle sprita można zdziałać bardzo przyzwoite rzeczy. Bo jednak animacja nie wymaga kunsztu, ale wymaga naturalności, gładkich zmian prędkości, a naprawdę ciężko jest wyeliminować taką koślawość przy animacji szkieletowej albo poklatkowej. Funkcje trygonometryczne nadają się więc do tego perfekcyjnie, a samo zaprogramowanie animacji można zamknąć w 10-20 linijkach i paru zmiennych. Bardzo polecam tę drogę
  11. heightmap po zmianie roomu

    MAM TO SKURWESYNY tzn tak połowicznie. Kluczem okazał się być screen_refresh() połączony z wyłączeniem d3d przy room end. Haczyk jest w tym, że przez to przez około sekundę w lewym górnym rogu pojawia się sprite heightmapy w czasie gdy room się ładuje, ale pokombinuję i może da radę to zatuszować. A nawet jeśli nie to koło dupy mi to lata, bo w końcu mogę ruszyć ten projekt do przodu. Chylę wam czoła koledzy, byliście bardzo pomocni. Całuję sygnety
  12. heightmap po zmianie roomu

    @I am Lord rzeczywiście są funkcje screen_redraw i screen_refresh i może są kluczem do tego wszystkiego. Ale cholera nie ma nigdzie już w dokumentacji o tym i nie wiem jak się tych funkcji używa. Jak proponujesz to w kodzie umieścić? I czym się te funkcje właściwie od siebie różnią?
  13. heightmap po zmianie roomu

    no niestety już sam gmk Twój mi nie działa poprawnie. Może też wina leży w innych wersjach GM. Robiłeś to w ósemce?
  14. heightmap po zmianie roomu

    @I am vader @I am Lord naprawdę dzięki wielkie za pomoc, ale jednak mijają dni, ciągle próbuję coś tu wskórać i nijak nie idzie tego rozwiązać. Chyba muszę dać sobie spokój i kombinować jakoś inaczej ukształtowanie terenu. Strasznie pluję sobie w brodę, że nie zacząłem tego projektu w Studio, bo już nawet chyba nie ma co próbować go przenieść do gmz. Mimo wszystko jeżeli może znacie jakieś inne sposoby na rysowanie terraina byłbym bardzo wdzięczny, bo jednak żal trochę pozbawiać gry tego elementu. Co prawda można próbować renderować po prostu modele .gmmod, ale to strasznie czasochłonne i problematyczne przy znajdowaniu wysokości w danym punkcie mapy, więc ten pomysł raczej odpada. Jeżeli macie jakieś pomysły to jestem w pełni otwarty
×