Skocz do zawartości

Threef

Moderatorzy
  • Postów

    2 911
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    14

Treść opublikowana przez Threef

  1. Przy dużej liczbie przypadków to co zrobiłeś wystarcza, ale w pewnym momencie czas jaki procesor spędza na dezaktywację obiektów jest dłuższy niż ich zwykłe istnienie. Albo zbyt często aktywowane i dezaktywowane są obiekty które nie powinny zmienić swojego stanu, bo na przykład i tak są poza view. Używanie dezaktywacji obiektów na ślepo nie jest dobrym rozwiązaniem. To jak stosowanie penicyliny na wszystkie choroby. Czasami powinno się dezaktywować poszczególne sektory room i aktywować tylko to co w zasięgu gracza. Czasami gdy poza view muszą być inne aktywne obiekty które np mają kolizje to nie wolno wcale dezaktywować. Musisz odpalić profiler i sprawdzić co tak spowalnia twoją grę. Dopiero wtedy myśleć co z tym zrobić. Ja sam chyba od 4 lat nie użyłem dezaktywacji. Zawsze zawczasu zapobiegam wąskim gardłom. Wiem że tworzenie 400 particle na raz jest gorsze od zrobienia jednego obiektu który rysuje te 400 particle w pętli. Wiem że najwolniejsze jest rysowanie sprite więc gdy nie potrzebuję wyświetlać jakiegoś obiektu a jest mi on dalej potrzbny to po prostu czynię go niewidocznym.
  2. Dezaktywacja i aktywacja obiektów co step nie jest wcale optymalizacją. Odpal profiler w debugerze i wtedy próbuj zrobić coś z najbardziej zasobożernymi akcjami. A twój problem pewnie bierze się z tego że instance_activate_all() aktywuje obiekty dopiero na końcu pętli gry, nie od razu. Mógłbyś zrobić w ten sposób że aktywowałbyś wszystkie obiekty i ustawiał alarm na 1. A w tym alarmie wykonywał swoje eventy. Ale to jest łatanie wadliwego podejścia.
  3. Z jakiegoś powodu wydaje mi się że szukasz zwyczajnego: x = sin(i)*r y = -cos(i)*r
  4. Ale tu przykładu nie trzeba. Masz idealnie opisane kroki. Shaderów też nie trzeba bo można to samo zrobić z blend modes.
  5. Threef

    Filmy

    No nowy Łowca Androidów bardzo dobry. Rewelacyjne kino. Bałem się że będzie tylko chciał próbować ciągnąć to co zostało stworzone w oryginale ale zostałem pozytywnie zaskoczony. 3 godziny seansu były idealne. To było świetne tempo dla tego filmu detektywistycznego. Widz był prowadzony za nos i wiedział więcej od bohaterów, a i tak zwroty fabularne były rewelacyjne. A i tak najważniejsza była dla mnie gra kolorów. Błekity, pomarańcze i... jedna scena w innym kolorze.
  6. Nie, nie chcesz poprzedniej pozycji. Szukasz czegoś innego. Poprzednia pozycja to: x = xprevious y = yprevious
  7. @kaszan88 już na forum nie zachodzi ale podoba mi się że to nie był koniec jego przygody z grami. Właśnie skończyłem oglądać let's play jednej z jego gier u mojego ulubionego jutubera. Bardzo fajnie.
  8. haha no to zrobiło twoje złamanie linii. No ale plik ini zapisuje klucze i wartości w jednej linii więc masz błąd składni. Możesz dokonywać serializacji jak pisał Psichix albo porzucić pliki ini. Plus radził bym i tak jakoś zabezpieczać swoje dane.
  9. Po pierwsze pytanie które muszę zadać: Czemu plik INI? Po drugie znakiem nowej linii w GM jest # Po trzecie upewnij się jakie znaki są wsadzane do zmiennej ze schowka. Od tego jest funkcja ord()
  10. show_message() to funkcja debugowa. Nie powinno się jej używać do niczego innego bo wygląda ohydnie. Jeżeli chcesz wyświetlać jakieś komunikaty to musisz stworzyć własne okienka. Jeżeli chodzi o wyświetlanie polskich znaków to musisz upewnić się 2 rzeczy. Jeden, to to czy twoja wybrana czcionka w ogóle ma polskie znaki, a druga rzecz to to co napisał Uzjel. Musisz dodać character range polskich znaków. Najlepiej spróbuj użyć przycisku Add from code
  11. Tak to jest bug. Wcześniej można było tak importować. Teraz po prostu dodaje się wpis do *.project.gmx ale nie kopiują się pliki.
  12. Nie działa dodawanie kilku skryptów na raz. Musisz robić to pojedynczo. Usuń wszystkie które stwarzają błędy i dodaj je ręcznie
  13. Ale już ostatnio pisałem że to robię. Ale duże i fajne samo z siebie się nie bierze i to trzeba po prostu zrobić. I robię. Już zbyt długo
  14. A wrzucę cokolwiek bo dawno nie robiłem nic co by wyglądało fajnie. Zrobione na Komiks Game Jamie. Solo w jakie 8 godzin.
  15. Zmień temp directory i cache directory GM a na coś krótkiego
  16. Tak. Jakby ktoś nie potrafił wejść w piątek na imprezę to ma dzwonić. W końcu to moja firma tę imprezę organizuje.
  17. Ale tutaj już mamy kogoś kto mówi że tym się zajmie. Mnie. A jeżeli chodzi o PGA to trzeba już się ogarniać. Już widzę że nie będę mieć czasu na spotkanie.
  18. s="" for(string_lenght(string)) { s+="*" } draw_text(x,y,s) ?
  19. Jeżeli kategorii nie ma zbytu dużo to możesz je zapisywać w formie potęgi 2 a kategorię z podkategoriami trzymać jako jeden int. Potem wykonywać operacje binarne. Czyli kategorie wyglądałby tak: id | name 1 Komputery 2 Laptopy 4 PC 8 Telefony 16 Android 32 Windows Phone 64 iOS Wtedy telefon z androidem miałby kategorię 24. A komputer PC 5 Ale pierw poczytaj o postaci normalnej w bazach danych
  20. Dlaczego nie? Wystarczy odpowiednio rysować 2 kamery na ekranie,czyli tak jak wszystko w 3D w gm trzeba to robić ręcznie
  21. No i co wy tam w Warszawie macie do zaoferowania? Kto to będzie organizować? W Szczecinie mamy wszystko.
  22. W teorii teraz jedynie wyłączasz rysowanie. Dzięki temu kolizje dalej zachodzą poza ekranem, więc unikniesz dzięki temu sytuacji że np jakiś NPC utknie w drzewie gdy zbliżysz się. Ale jeżeli nie potrzebujesz sprawdzać kolizji to możesz równie dobrze dezaktywować obiekty. Jeżeli dezaktywujesz to lepiej wrzucić ten kod do drzew. Ale jeżeli nie to ja bym zrobił jeden obiekt który zarządzałby tym rysowaniem. Może to też robić gracz. No i 200 drzew to... ok. Ja przy tej technice w GM miałem 200000 obiektów w 30FPS na Pentium 4
  23. Jeżeli dobrze przyjrzysz się temu jak się obraca kamera to zauważysz ze lewy górny punkt zostaje w miejscu ale pozostałe rogi się obracają dookoła punktu w lewym górnym rogu. Jeżeli obrócisz kamerę o 90 stopni to zamienią się osie. W górę będziesz mieć x a w prawo y. Wtedy szerokość ekranu która wynosiła np 1280 jest w przeciwną stronę. To co jest najbezpieczniej robić to w twoim wypadku operować na promieniu względem środka ekranu. var r = max(view_wview[0],view_hview[0])+margines var px = view_xview[0]+view_wview[0]/2 var py = view_yview[0]+view_hview[0]/2 with (drzewo) { if(point_distance(x,y,px,py)>r) { visible=false } else { visible=true } } Edit: A nie, bo właśnie w tym chyba problem. Musiałbyś wymnażać to przez sin i -cos z view_angle[0] żeby dawało ci dobrą pozycję środka kamery... Chyba. Nie jestem już w stanie odpowiedzieć. Z dużo wypiłem. :|
  24. Ja mam jeden obiekt na całą grę którzy potrafi kolejkować okna i każde z g przyjmuje parametry jaka ma być treść, ile przycisków i co mają robić. Rysuje także ten obiekt
  25. @Ignatus Drugie rozwiązanie, ale musisz uwzględnić rozmiar drzew. Niestety ale prawdopodobnie rysujesz tego za dużo. Poza tym nie rób if(rectangle_in_rectangle()){draw_sprite()} Rób w step: if(point_in_rectangle()) {visible =true} else {visible=false} W ten sposób całkiem wyłączasz event draw. To o wiele bardziej przyśpiesza bo dany obiekt wcale nie wykonuje eventu draw. Sprawdzenie punktu też jest szybsze niż prostokąta. Dobież tylko marginesy w rozmiarach sprite.
×
×
  • Dodaj nową pozycję...