Threef

Jeżeli użyjesz na końcu to jak znam życie zdąży się jeszcze wczytać. Zawsze używać na początku nowego. Każdy z wbudowanych rodzai particle jest na osobnym texturepage. Jak użyjesz gwiazdki i wybuchu to zostaną dodane 2 nowe texturepages. Dlatego YYG zaleca używanie zawsze własnych grafik do particle. Wtedy grafika jest pobierana z texturepage który już istnieje. YYG jako przykład podaje nawet że te podstawowe są zapisane w folderze GM i mozna sobie je dodać do projektu jako grafiki. W dokumentacji jest wszystko napisane.

Wystarczy że użyjesz raz w create jakiegoś obiektu. Upewnij się jednak czy ten obiekt występuje tylko raz. Ale problem jest taki że ta funkcja wcale Ci nie pomoże. Ona nie czyści pamięci. Ona jedynie zwalnia z pamięci poprzednio wczytane texturepages. Wszystkie. Po czym one zostają od razu wczytane ponownie. Samo wczytanie jest dość ciężką akcją więc nie powinno nigdy być używane co step. Tak więc użycie draw_texture_flush() pomoże TYLKO w wypadku gdy masz perfekcyjnie rozdzielone sprite na texturepages. Co przez to rozumiem? Masz np osobny do grafik z menu i osobny dla map. I żadna z grafik użytych na tym od menu nie jest nigdzie użyta w mapach. Wtedy ten pierwszy zostanie wyrzucony z pamięci, ale jeżeli odniesiesz się gdzieś do jakiejś grafiki z menu to znów zostanie on wczytany. Więcej optymizacji uzyskasz jeżeli spakujesz jak najwięcej grafik na jak najmniej texturepages.

GML show_debug_overlay(true)Pokaże ci się widok debugowy pokazujący np FPS. PIerwsza liczba w nawiasie to liczba texture swap, czyli ile razy na step zmieniane są texture pages. To Cię interesuje. Więcej możesz przeczytać w dokumentacji. Funkcja tworząca path, czyli mp_grid_path(), zwraca wartość true/false zależną od tego czy droga jest wytyczona czy nie. path zostaje utworzony nawet jak się nie uda, więc to ty musisz zareagować.

Zacznijmy od tego że muszę wytknąć Ci użycie plików ini. Nie z tego powodu że coś robisz nie tak, a z tego że jeżeli tego nie zrobię to przyjdzie ktoś i zwróci mi uwagę na to że nie zwróciłem uwagi tobie. Ogółem pliki ini służą do przechowywanie danych konfiguracyjnych i nie powinny być używane do niczego innego. Na razie masz sobie zamiar przechowywać w nich kolor gracza, co jest ok, ale nawet nie myśl sobie że będziesz mógł tak samo zapisać ilość złota, level, tabelę wyników albo inne "ważne dane". Pliki ini są formatem czytelnym i łatwym do edycji. W skrócie do ini zapisuj tylko te dane które oczekujesz że gracz sam może sobie zmienić. Na przykład: Rozdzielczość gry, głośność muzyki, imię postaci. Więc przejdźmy do problemu. Nie możesz używać TYLKO plików ini. One, jak każde inne pliki tekstowe służą tylko do przechowywania danych. Nie możesz na nich wykonywać obliczeń i zawsze musisz pilnować aby przypadkiem nie nadpisać sobie danych. Więc musisz najpierw odczytać dane do pamięci. Tu wybierz co chcesz. Zmienna, tablica, struktura danych. Na tych danych operujesz i wykonujesz obliczenia. Dopiero potem zapisujesz ponownie dane do pliku. Użycie zmiennych globalnych nie ma sensu, chyba że maja być globalne i różne obiekty będą z nich korzystać. Ale jako że to kolor gracza, to największy sens ma przechowywanie tego jako dane gracza w jego obiekcie. Tablic się nie da, ale już ds_list tak. ds_list_add(tab,2,5,4,7)

Oczywiście te wartości dla liczników powinieneś sobie samemu wybrać.

Stwórz 2 stany i odliczaj licznikiem. GML if(strzelam == true) { //kod strzelania licznik_czasu-- if(licznik_czasu<=0) { strzelam=false licznik_czasu=200 } } else { //Nie strzelam licznik_czasu-- if(licznik_czasu<=0) { strzelam=true licznik_czasu=400 } }

To jest GM:S.

Nazwy zasobów są stałymi kompilowanymi od nowa przy każdym uruchomieniu gry. Wskazują na ID zasobu w kategorii. Sprite na samej górze drzewka sprite będzie miało wartość 0, następny 1, etc. Ale każdy pierwszy obiekt, sound, timeline, room i nie wiem co jeszcze będzie miało ID 0. Przez to będzie dochodzić do błędów gdy sprite i obiekt mają tę samą nazwę. Nie wiem czemu GM nie zgłasza tego jako błąd kompilacji. Wydaje mi się wcześniej to robił. No, ale jest opcja w menu która pokarze wszystkie duplikaty nazw. No i kolejny raz, bo to fajny feature, przypomnę że są tego plusy. Jeżeli mamy 10 przeciwników (oEnemy1, oEnemy2, oEnemy3...) to nie musimy ich losować, a możemy zrobić oEnemy1+irandom(10).

Niech zgadnę. hud_item1 to obiekt?

Może przenieś do post draw GUI?

Tytuł: Warsaw Demonstrations Wcześniej jako "Marsz wolności!" Gatunek: Party Game Opis: Gra powstała na Game Jamie w Teatrze Polskim w Poznaniu. Tematem było "Wiara w pojednanie", temat ciążki do zinterpretowania dlatego powstało co powstało. Gra jest połączeniem Snake i Pac-mana. Dwie grupy ścierają się na ulicach Warszawy w pokojowych marszach. Atak od czoła jest najbardziej chaotyczny i nie zalecany. Wygrywa gracz sprytniejszy czyli ten który przecina grupę przeciwną od boku. Gra powstała w jedną noc. Sterowanie: Gracz 1 - A /D Gracz 2 - Strzałki lewo / prawo Ale gra była testowana na macie do tańczenia. 2 graczy stało naprzeciwko siebie i skręcało odpowiednimi przyciskami. Download Autorzy: Programowanie: Damian "Threef" Komorowski Fabuła: Tęcza z placu zbawiciela Grafika: Damian "Threef" Komorowski Muzyka: Yakety Sax Screeny:

Te fotki to photoszopka! Mamy już 2 dowody! Mnie nie było przy robieniu tych zdjęć i piwa nie było na parkiecie!

Co ja robię na tym zdjęciu? Czemu wyglądam dobrze? Nie mam pojęcia czemu macie puszki z piwami bo nikogo na parkiecie z piwem nie pamiętam. Nie pamiętam żadnych grupówek, poza tą z Anchelem i facetem z Ubisoftu na ściance, a wtedy już mocno się upiłem. Niestety 1:30 musiałem się zwijać na nocleg (i prelekcję rano o 11) ale mój sobowtór widzę został i bawił się z wami dalej. p.s.: Do poniedziałku bolało mnie dupsko jak przywaliłem tańcząc kankana. :lol2: Edit: Co do spotkań to zgadzam się całkowicie. Nie ma czasu dla nikogo. O Chellu całkiem zapomniałem i to on mnie zgarnął na korytarzu. Tak to bym nawet go nie zauważył. ANtY'emu tylko rękę podałem jak siedzieli z Tomkiem i poleciałem dalej. Maximala widziałem w niedzielę jak wychodziłem z walizkami. No i Ranmus do mnie na fejsie napisał czy jestem na targach gdy już byłem na dworcu. Edit2: YXE był chyba całą sobotę i tyle samo co ja w niedzielę. No to go też widziałem. :P

Wszystko o co pytasz jest. Eksporty działają praktycznie bez zarzutów. Da radę robić gry multiplayer host-host, i da się wysyłać zapytania HTTP więc możesz sobie napisać jakiś back-end który będzie się komunikował z bazą danych. Jeżeli masz zamiar w przyszłości myśleć o 3D to GM:S jest złym kierunkiem bo nigdy nie będzie w pełni wspierał 3D bo jest silnikiem 2D. Więc teraz 2 rady które mają wspólną część: Nie kupuj teraz. 1. Niedługo święta, a to oznacza że Master będzie przeceniony co najmniej o 10%. Jak ci się śpieszy to pewnie będzie też jakaś wyprzedaż na Halloween, ale zawsze te 2 wyprzedaże na wakacje i Boże Narodzenie są największe. 2. Może się okazać że GM:Studio przestanie Cię interesować. YoYoGames pracuje po cichu nad nową wersją. Nie wiemy kiedy ją zobaczymy, ale już wiemy że trzeba będzie go kupić od nowa. Więc jak okaże się że w marcu zacznie się sprzedaż to możesz żałować. Więc nie kupuj. Ogarnij teraz na wersji free, zobacz czy Ci pasuje i w sumie możesz zaczynać. Master możesz dokupić później.

physics_particle_create() i wszystkie w tej kategorii.

W GM:S już jest fizyka płynów z Box2D, ale skoro wciąż operujesz na klockach to jest to jak przeskoczenie z budowania zamków piaskowych do planowania instalacji cieplnej w domku jednorodzinnym. Pytania: Nie masz teraz nic? Sam pomysł jak powinno to działać? Nie próbowałeś tego już robić? Jak tak to pokaż co masz, może coś z tego już się nadaje na podstawę, bo jak nie to zaczynamy od nowa. W jaki sposób ten "płyn" ma się zachowywać? Każda jednostka płynu ma być wyrównanym do siatki blokiem 16x16px? Czy może zachowywać się w miarę naturalnie? Czy "płyn" ma poruszać się pomiędzy rurami które ustawisz?

Niby już doszedłem do siebie, ale nie potrafię w tych poprzednich postach znaleźć nic co można by opisać proceduralnym? Ty chyba chcesz zrobić predefiniowane pokoje które będą się losowo ustawiały. To nie jest generowanie proceduralne. Opisz wszystko jeszcze raz od początku. Pamiętaj, nie czytamy Ci w myślach więc nie zapomnij o szczegółach.

btw teraz Poznań siedzi w Teatrze Polskim. Mamy wódę i robimy gry.

Nie jestem pewien jak dokładnie działają tablice w GM. ds_list jest strukturą przechowującą zmienne. GM zajmuje się całym zarządzaniem nią. Sama funkcja create zapisuje w zmiennej adres struktury. Pod tym adresie GM rozpoznaje strukturę. Struktury są globalne ale zmienna w jakiej jest zapisany adres nie musi być. Różnica będzie raczej taka że array przechowuje w pamięci całą swoją zawartość nawet pustą, ds_list przechowuje zbiór zmiennych i adresy do nich. Więc w array jak dodasz array[99] to wszystkie pola będą zajęte. W ds_list jak dodasz coś na pozycji 99 to reszta będzie pusta. A jakbyś chciał zaokrąglić do jakiejś liczby po przecinku to musisz zrobić małą sztuczkę.GML a=3.1415 b=round(a*100)/100 //b = 3.14

Tak. Taki który będzie sprawdzał czy plik istnieje. Nie podam jaki bo dobrze Ci zrobi poszukanie tego na własną rękę.

Podczas wczytywania w żaden sposób nie zabezpieczasz się przed ewentualnością gdy nie ma pliku.

Nie umiem mega. Teraz powinno być dobrze.

Odkopałem paczkę z wszystkimi grami wiec udostępniam. Download

Tak da się łączyć. Od tego jest zakładka "PIP" czyli Picture In Picture. Ja swego czasu napisałem program w GM który daje lepsze możliwości, ale musiałbym go poprawić. Program miał nazwę kodową "Picture In Picture Automatisation".

Pewnie kod wykonuje się zanim w room pojawia się obj_control. Otwórz room i zobacz "instance creation order" ustaw odpowiednią kolejność. Kolejność w jakiej obiekty wykonują swój kod zależy od tego który był pierwszy postawiony w room. w GM:S dodano właśnie w edytorze listę która to pokazuje i umożliwia nam zmianę tej kolejności bez usuwania obiektów.