UltimaForum
Ogólna dyskusja - Silnik VX`a
Asantos - Wto 27 Lip, 2010 21:32
Temat postu: Silnik VX`a
Zwracam się z tym pytankiem do wtajemniczonych języka RUBY - chociaż odpowiedzieć może każdy. Czy pewne zabiegi "korekcyjne" w silniku VX`a (lub XP`eka) pozwoliłby na jego większe możliwości, np. mapy 500x500 z tysiącami eventów - jedna wielka mapa świata. Wiele osób skarży, że to wina pamięci podręcznej, jednak z pewnością nie w tym tkwi sekret. A spójrzmy na (powiedzmy) Gothica 3 - jedna ogromna mapa świata, brak lokacji, wszystko dzieje się w "jednym" miejscu, a jednak chodzi w płynnie (porównanie dość górnolotne :-> ). Czy tworzenie silnika gry odbywa się na zasadzie: "tysiąc linijek więcej, tysiąc eventów więcej" - może nie dosłownie - ? Czy w ogóle język RUBY jest na tyle władny, że osiągnąłby taką "moc", czy jest to może język zbyt słaby, by działać z nim takie cuda (chociaż to pewnie nieprawda, gdyż jest obiektowy)? Jako człowiek wiecznie ciekawy, niestrudzenie czekam na odpowiedź ;-)


Pozdrawiam, Asantos.
Rave - Wto 27 Lip, 2010 21:43
Przede wszystkim, to byś musiał pobawić się w edytorze skryptów klasami Interpreter, gdyż to one odpowiadają za sposób (i tym samym wydajność) poszczególnych komend zdarzeń, np. wydajność komendy Pokaż obrazek i inne. Z pewnością da się to zoptymalizować (choć i tak optymalizacja vX jest o wiele lepsza niż XP), ale trzeba mieć dobrą smykałkę do Ruby i przede wszystkim biblioteki RGSS(2) - dwójka w nawiasie, gdyż z pewnością da się podobne rzeczy zrobić w XP jeśli chodzi o poprawienie wydajności.

Ale tak jak napisałem trzeba się naprawdę na tym znać.
Asantos - Wto 27 Lip, 2010 21:54
Dla mnie właśnie dużą barierą tego języka była nauka biblioteki. Nie dosyć, ze nie obcy nam musi być język, to i komendy trzeba opanować. Jednakże dziękuję za odpowiedź. Może chociaż z ciekawości przejrzę fragment "Interpretet" - choć z pewnością nic nie zdziałam ;-) . Ale prawda jest taka, że gdyby silnik programu był taki jak mówię, to ten program by z pewnością tyle samo nie kosztował :->
radek02 - Sro 28 Lip, 2010 07:51
trochę to niemożliwe :-> , ale zawsze można spróbowac . chciałbym takie coś zobaczyc na moim starszym kompie ;-) hehe
Rave - Sro 28 Lip, 2010 08:26
Radek, nie ma rzeczy niemożliwych, jest tylko brak umiejętności. Co najwyżej to jest bardzo trudne (o czym zresztą napomknąłem). Asantos - musisz bardzo dobrze znać się na Ruby i RGSS-ie albo znaleźć osobę która się zna na tym, aby to wykonać. I nie zna się w sensie "O, umiem pokazać okienko z zegarkiem jak w PW TiTka", tylko robi jakieś skomplikowane rzeczy typu abs-y czy jakieś skrypty w rodzaju Mode7. Myślę, że jak byś pogadał z Mr. Mo, albo Dubealexem, to może by ci pomogli, bo na pewno wielu by się "przyspieszacz" przydał.
Asantos - Sro 28 Lip, 2010 14:04
Nie chcę optymalizować silnika. Nie mam na to najmniejszych umiejętności. Z resztą trochę się dziwię, że jeszcze nikt na to nie wpadł, aby go zoptymalizować (Yanfly, Modern Algebra, Worale i tych, których Ty wspomniałeś). Bo w sumie zamiast pisać (niebezpieczne) antylagi lepiej chyba przyspieszyć silnik - chociaż antylagi to zdecydowanie prostsze.

I tak dobrze, że w ogóle został stworzony program, gdyby to był tylko silnik, wszystko trzeba by było pisać skryptami :->
Sabikku - Sro 28 Lip, 2010 18:34
Nie. Nie da się.
Po pierwsze, ruby jest bardzo ograniczony. W porównaniu do twojego Gothica (c++) kilka(naście) razy wolniejszy - nie wspominając, że rpg maker działa na starej wersji ruby. Po drugie, wszystko to, co dałoby się naprawdę zoptymalizować, jest zakodowane w pliku .exe projektu rpg makera. Sposób wyświetlania grafiki, odtwarzania dźwięku, kodowania plików itd.
Jedyne co pozostaje do optymalizacji - zostało już napisane (antilag i takie tam). Można jeszcze nieco przyspieszyć usuwając niepotrzebne elementy (np. w platformówce nie potrzeba wszystkiego związanego z systemem walki itp), ale to przyspieszy może o kilka procent.
Nie sprawisz więc, by twoja supermapa działała płynnie. Moc obliczeniowa języka i zakodowana część programu uniemożliwiają takie projekty.

@up: Przy każdym (j)rpgu mieli tego typu edytory, różnica taka że ten jest postawiony na prostotę obsługi programu i modyfikacji kodu. Gdzieś czytałem, że twórcy RMa (2k/2k3) pracowali też przy którymś ze starych FF :).
Asantos - Czw 29 Lip, 2010 10:50
Wielkie dzięki Sabikku za odpowiedź. Sądziłem, że wszystko zależy od silnika, a tu się okazuje co innego. Co do nowszej wersji RUBY masz namyśli RUBY on Rails (o którym gdzieś tam słyszałem), czy może po prostu korzystanie ze starych metod i definicji, które wyszły z użycia i/lub zostały zastąpione przez nowsze?

Mówisz też, że (mniej więcej) każdy rpg ma swój edytor? Czy tylko o RM`ach mówisz? Myślałem kiedyś, że tak się właśnie robi gry. Pisze się edytor i tworzy, aż ktoś powiedział mi, że wszystko się pisze od razu językiem, bez "bawienia" się w edytory. Ale nie wiem na ile w tym prawdy.
Sabikku - Czw 29 Lip, 2010 11:55
Nadal zależy od silnika, ale nie da się zmodyfikować elementarnych struktur. Miałem na myśli starszą wersję języka, ^^ http://www.ruby-lang.org/pl/downloads/ . 'Obecna wersja stabilna to 1.9.1'. A RoR służy do obsługi baz danych i tworzenia aplikacji internetowych.

Z tego co mi wiadomo, przy każdym większym rpgu muszą tworzyć edytory. Ci odpowiedzialni za programowanie nie zawsze są jednocześnie odpowiedzialni za mapy itp. Poza tym nie ma wygodniejszego tworzenia map, niż przez odpowiedni edytor. Wyobrażasz sobie, choćby tworząc Pokemony, pisać mapy np. w notatniku? Tym bardziej, że nawet tam mapy mają dwie czy trzy warstwy - bez odpowiedniego edytora stworzenie gry trwałoby kilka razy dłużej. Twórcy nie udostępniają graczom swoich narzędzi developerskich, z małymi wyjątkami (TES, NVN itp).
No ale wszystko zależy od sposobu wyświetlania map i takich tam, w platformówkach czy grach z losowymi poziomami raczej nie potrzeba nikomu dodatkowych narzędzi.
Asantos - Czw 29 Lip, 2010 12:36
Ciekawe. Po części też trochę uważałem, że tworzenie edytora będzie trwało dłużej dopóki sam nie zobaczyłem takiego edytora ;-) (RM). Zespół tworzący jakąkolwiek aplikacje jest podzielony na grafików, programistów itp. Sądziłem, że to działa na zasadzie programowania w DirectX lub OpenGl przez grafika, który gotową funkcję (?) wyświetlającą skrzynię umieszcza w odpowiednim miejscu na mapie i tak dalej...

Jednak mimo wszystko edytor daje większe możliwości i prostszą obsługę. Daje to im takie same możliwości co nam pracując w RM`ie - no może oprócz pliku źródłowego programu, którego nie możemy ruszać :->
FilipsO - Czw 29 Lip, 2010 16:23
A ja mam pytanie niezwiązane z tematem (znaczy luźno związane).
Ja bym chciał napisać własny edytor od 0 i zna ktoś jakiś dobry język
programowania i mógłby dać linki do jakiś tutoriali?
Bardzo bym prosił o to.
FilipsO :-P
Sabikku - Czw 29 Lip, 2010 16:38
Dobra znajomość WinApi i C++. http://www.gamedev.pl/tut...=category&id=18
Zawsze też można pomęczyć się w ruby, jeno bez tutków - używając Gosu (bardzo proste i wygodne) czy WxRuby (które obsługuje prawie całe WinApi).
FilipsO - Czw 29 Lip, 2010 17:28
Wielki dzięki Sabikku. Dałbym pomógł ale nie jestem autorem tego tematu.
Jeszcze jedno pytanko Sabikku:
Lepsze jest WinApi czy C++?
Sabikku - Czw 29 Lip, 2010 17:30
Nie nie, WinApi to tylko zbiór funkcji i klas do zarządzania windowsowymi okienkami, a c++ to język w którym można to obsłużyć i wykorzystać ;-) .
FilipsO - Czw 29 Lip, 2010 17:31
A dzięki :-P Jestem taki zielony dlatego myślałem że to dwa języki programowania :-o
Asantos - Czw 29 Lip, 2010 17:38
Jeśli chcesz się naprawdę zająć programowaniem to kup porządne książki. Polecam Symfonię, do c++, mam ją i bardzo jestem zadowolony z zakupu. Jeśli nie chcesz to skorzystaj z tutoriali internetowych, ale są tego pewne minusy:
- poradniki są zazwyczaj dość trudne,
- poradniki nie są kompletne,
- bardzo mało przykładów funkcji i tym podobnych.
To moje doświadczenia z internetowych poradników.


Z wiedzy internetowej będziesz umiał co najwyżej pisać kalkulatory. Chociaż na początku chyba tylko to każdy potrafi zaprogramować :) Dopiero potem przychodzi ochota na coś większego.
FilipsO - Czw 29 Lip, 2010 19:31
Dzięki Asantos za rady.
A czy w C++ można napisać takiego "RMa"?
Asantos - Czw 29 Lip, 2010 20:22
W C++ możesz co najwyżej silnik. Sam edytor to najlepiej WinApi`m.
Rave - Pią 30 Lip, 2010 07:44
Hej... Ale RM JEST napisany w C++, a wersje 2000/2003 (nie wiem jak z 95) były napisane 2 Delphi (Pascal). Język akurat nie jest ważny. Ważne są tylko umiejętności jego użycia. Znasz już Pascal i umiesz pisać zaawansowane rzeczy w nim? Trzymaj się tego. Nie znasz żadnego? Na początku proponowałbym naukę prostego Pythona. Python w połączeniu z biblioteką pyGame dają całkiem ciekawe możliwości jeśli chodzi o gry. Potem czas przyjdzie na kompilowalne języki takie jak C++ czy Pascal (Python podobnie jak Ruby to tylko interpreter).

Co do silnika VX, to Sabikku się niestety myli. Jasne - starej wersji Ruby się nie przeskoczy (chyba, że komuś chce się bawić w dekompilację/deassemblerację), ale tak naprawdę w Game.exe jest tylko sam interpreter ruby. Sam proces obsługi komend zdarzeń znajduje się w klasach Interpreter w edytorze skryptu.

Podsumowując: Nie ma rzeczy niemożliwych, jest tylko brak umiejętności.
Asantos - Pią 30 Lip, 2010 09:16
Przecież WinApi już z nazwy służy do programowania okienek. Nie mam wiedzy na temat czy da się okienkowo napisać C++`em edytor. Chyba że o stronę graficzną zadbamy WinApi`m a komendy C++, tak to jak najbardziej. Chociaż komendy w silniku też muszą być zapisane - w programie jest tylko komenda ich wywołania.

Chyba że się gdzieś pomyliłem.
Rave - Pią 30 Lip, 2010 10:17
Nie, sposób wykonywania komend jest jak najbardziej zapisany w klasach Interpreter. Przykład z makera xp (specjalnie dla was musiałem instalnąć...)

Spoiler:

Kod:
 def command_101
 # ほかの文章が message_text に設定済みの場合
    if $game_temp.message_text != nil
      # 終了
      return false
    end
    # メッセージ終了待機中フラグおよびコールバックを設定
    @message_waiting = true
    $game_temp.message_proc = Proc.new { @message_waiting = false }
    # message_text に 1 行目を設定
    $game_temp.message_text = @list[@index].parameters[0] + "\n"
    line_count = 1
    # ループ
    loop do
      # 次のイベントコマンドが文章 2 行目以降の場合
      if @list[@index+1].code == 401
        # message_text に 2 行目以降を追加
        $game_temp.message_text += @list[@index+1].parameters[0] + "\n"
        line_count += 1
      # イベントコマンドが文章 2 行目以降ではない場合
      else
        # 次のイベントコマンドが選択肢の表示の場合
        if @list[@index+1].code == 102
          # 選択肢が画面に収まる場合
          if @list[@index+1].parameters[0].size <= 4 - line_count
            # &#12452;&#12531;&#12487;&#12483;&#12463;&#12473;&#12434;&#36914;&#12417;&#12427;
            @index += 1
            # &#36984;&#25246;&#32930;&#12398;&#12475;&#12483;&#12488;&#12450;&#12483;&#12503;
            $game_temp.choice_start = line_count
            setup_choices(@list[@index].parameters)
          end
        # &#27425;&#12398;&#12452;&#12505;&#12531;&#12488;&#12467;&#12510;&#12531;&#12489;&#12364;&#25968;&#20516;&#20837;&#21147;&#12398;&#20966;&#29702;&#12398;&#22580;&#21512;
        elsif @list[@index+1].code == 103
          # &#25968;&#20516;&#20837;&#21147;&#12454;&#12451;&#12531;&#12489;&#12454;&#12364;&#30011;&#38754;&#12395;&#21454;&#12414;&#12427;&#22580;&#21512;
          if line_count < 4
            # &#12452;&#12531;&#12487;&#12483;&#12463;&#12473;&#12434;&#36914;&#12417;&#12427;
            @index += 1
            # &#25968;&#20516;&#20837;&#21147;&#12398;&#12475;&#12483;&#12488;&#12450;&#12483;&#12503;
            $game_temp.num_input_start = line_count
            $game_temp.num_input_variable_id = @list[@index].parameters[0]
            $game_temp.num_input_digits_max = @list[@index].parameters[1]
          end
        end
        # &#32153;&#32154;
        return true
      end
      # &#12452;&#12531;&#12487;&#12483;&#12463;&#12473;&#12434;&#36914;&#12417;&#12427;
      @index += 1
    end
  end



Co robi ten przydługi kod? Ano, odpowiada za komendę "Pokaż wiadomość"/"Show Message". Można go jakoś przyspieszyć? Pewnie tak. Chociaż w tym akurat przypadku nie zauważylibyśmy różnicy. Bardziej trzeba by się zabrać do komend obsługujących grafikę typu pokaż obrazek, zmień pogodę czy przygotuj/wykonaj przejście (tak, KAŻDA komenda zdarzeń ma odpowiadającą procedurę w klasie Interpreter. Problem jest tylko taki, aby ją odnaleźć).
Sabikku - Pią 30 Lip, 2010 10:42
Cytat:
Co do silnika VX, to Sabikku się niestety myli. Jasne - starej wersji Ruby się nie przeskoczy (chyba, że komuś chce się bawić w dekompilację/deassemblerację), ale tak naprawdę w Game.exe jest tylko sam interpreter ruby. Sam proces obsługi komend zdarzeń znajduje się w klasach Interpreter w edytorze skryptu.

Eee, ani przez chwilę nie zaprzeczyłem, że interpreter w całości znajduje się w pliku scripts.rxdata, do edycji w edytorze skryptów. Jedyne co powiedziałem, to że to i tak nie ma znaczenia. Zajrzyj do helpa programu (rmxp/vx). Wszystkie elementarne klasy odpowiadające za odtwarzanie dźwięków, wyświetlanie i kontrolowanie grafiki (np. klasy Bitmap, Sprite, Window) są zakodowane (w .dllu). Dla przykładu 'Pokaż obrazek' z poziomu edytora skryptów to utworzenie obiektu klasy Sprite_Picture opartej na zakodowanej klasie Sprite, której nie da się zmodyfikować. Jedyne, co można edytować żeby przyspieszyć - to usunąć niepotrzebne właściwości programu. Nie przyspieszysz nic zachowując aktualne możliwości, bo jak mówiłem, do najważniejszego i tak nie ma dostępu.
Asantos - Pią 30 Lip, 2010 14:18
Rave, ja powiedziałem, że C++, według mojego poziomu wiedzy, nie używa się do tworzenia edytorów. Do tego wystarczy WinApi. Ale komendy w edytorze będą już pisane C++`em, a komendy te muszą być zasięgnięte z silnika. Chyba że chcemy mieć silnik scalony z edytorem...

Mój błąd :) Przecież WinApi to biblioteka C++. Ale tak czy inaczej tej biblioteki wykorzystuje się do okienek, a innych bibliotek najlepiej do silnika.

Powered by phpBB modified by Przemo © 2003 phpBB Group