자유게시판



1. 서브 폴더를 만들지 말아라

- Graphics/Pictures/pic1/... 이런식으로 계속 서브폴더 여러게를 만들면 반드시 느려집니다.

   Graphics/Parallaxes를 Graphics/Parallaxes/p1로 만들어서 p1폴더에서 Parallaxe 불러오니 느려지더군요.

   아예 Graphics/Parallaxes로 하지말고 Graphics/로 하던가 Graphics폴더가 존재하는 같은 폴더에 픽쳐를 두면

   둘 수록 렉이 줄어듭니다. 

   Cache 모듈쪽으로 가 보면 

   def self.animation(filename, hue)

     load_bitmap("Graphics/Animations/", filename, hue)

   end

   이 있는데

   def self.animation(filename, hue)

     load_bitmap("Animations/", filename, hue)

   end

   이런식으로 Animations 폴더를 밖으로 빼라는 의미죠(사용 파일도 옮겨야 함). 확실히 렉이 줄어듭니다.





2. 동작이미지를 만들때는 세로로 연결하지 말고 가로로 연결하라.

- 왜 인지는 모르겠지만

움직이는 그림을 연결 할 때

동작1

동작2

동작3

.

.

이렇게 연결하는 것 보다

동작1 동작2 동작3 ....

으로 연결해서

스프라이트.비트맵.src_rect.set(i * 128, j * 128, 128, 128)

이런식으로 동작연결을 하는 게 렉이 더 줄어듭니다.





3. 불필요한 업데이트는 삼가라. 필요할때 업데이트를 적절하게 하라.

- 기본 Scene_Base 스크립트 내부를 보면 update_basic 부분에 update_all_windows가 보입니다.

  한 프레임마다 update_all_windows를 실행한다는 의미 입니다.

  이게 상당히 문제있는 부분 입니다. window같은 경우는 업데이트를 하게 되면 내용물 전체를 삭제하고 다시 내용을

  작성하는 식으로 코딩이 되 있기때문에 window내부에 쓴 것이 많거나 큰 비트맵이라도 불러온 경우라면 한 프레임

  마다 잡아먹는 렉은 가히.. 상상 이상으로 렉렉 거리게 되죠.

  저 update_all_windows 부분을 과감히 삭제할 필요가 있습니다. 그리고 해당 윈도우 내용을 업데이트 할 필요가 있

  을 경우만 (해당윈도우.update)를 해 주는게 좋습니다.

  비트맵 경우도 마찬가지로 신경쓰면서 스크립트를 작성하는게 중요합니다.





4. 가급적 이미지들을 연결하지 말고 개별적으로 만들어라

- 알만툴 렉을 줄이는데 핵심이라고 할수 있습니다. 불러오기 시간을 줄이는데 탁월합니다.

  동작 이미지들은 연결하지 않고 만들면 파일 개수가 많이지는 경우가 생길 수 있으니 연결을 하고 그도 그럴 것이

  동작 이미지는 한 이미지 파일을 딱 한 번 불러와서 이미지 부분의 인텍스만 변경하면서 보여주는 것이기에 문제가

  없지만, 그 이외의 아이템 이미지들이나 케릭터 얼굴 이미지들은 따로 만드는게 좋습니다.

  알만툴의 비트맵을 표시하는 방법이 표시하려는 이미지가 포함된 전체 이미지를 한번 불러오고 그 다음에 시각부분을

  설정하여 그 부분만 보여주는 방식 입니다. 그런데 연결된 이미지 파일 크기가 크면 처음 불러올 때 렉이 생깁니다.

  얼굴 이미지 같은 경우는 총 8개 얼굴 이미지가 같이 붙어있는데 윈도우에서 표시를 한다고 하면 윈도우를 업데이트

  시킬때마다 8개가 붙어있는 파일을 불러오게 되기때문에 그만큼 렉이 생깁니다. 하지만 96*96으로 각각의 얼굴파을을

  하나씩으로만 한다면 필요한 캐릭터의 얼굴파일을 불러올 때 8개가 붙어있는 이미지파일보다는 불러오는 렉이 줄어들게

  됩니다.

  그리고 아이템 이미지 하나의 크기가 24*24인데 IconSet 에 이런게 한 100줄 들어가 있다고 생각해보세요.

  24*24크기의 이미지를 한번 불러오려고 2400*2400의 이미지를 일단 불러오게되는 오나전 렉렉한 경우가 생갑니다.

  처음부터 24*24크기의 이미지들로만 저장하면 24*24만 불러오게되서 렉이 싹 사라집니다. 근데 아이템 이 경우는

  스크립트를 좀 손을 봐야합니다. 하지만 얼굴 이미지 같은 경우는 처음부터 96*96크기로 저장해도 되지요. 




5.사용하는 이미지는 게임 시작 전 다 불러오고 class를 나가게 될때 절대 이미지들을

   dispose 시키지 말아라.

- 이건 렉을 줄인다기 보다는 게임 중간중간 로딩시간을 없애는데 쓰입니다. 작은 이미지들을 상관이 없지만 만약 용량이 큰   이미지들을 불러오게 될 때에는 게임이 몇초간 멈추게 되죠. 그걸 막기 위한 방법입니다. 

  Scene_Title 부분의 start에

  temp =  Cache.picture("그림1")

  temp =  Cache.system("IconSet")

  .

  .

  .

  처럼 한 번씩 불러오고

  위 그림들이 사용되는 스크립트를 찾아가서 .bitmap.dispose 을 시행하는 부분을 삭제해버리는 겁니다.






6. 게임을 암호화 시키지 말아라

-  이부분은 확실치는 않습니다. 하지만 오디오 암호화 스크립트를 사용한 적이 있는데 음악을 불러올때마다 끊겼습니다.

  그리고 이미지가 큰 경우에도 암호화 시 끊김현상이 발생합니다.

  쾌적한 암호화 시스템을 구축하거나 하지 않으면, 기존 주어진 enterbrain 식의 암호화를 사용하면 렉이 발생하는 듯 합

  니다. 아니면 데이터 폴더만 압축하는 시스템을 만들던가, 암호화를 원하는 픽쳐 폴더 부분만 한다든지..

  사실 개인적으로 판매용 아니고서는 암호화 시키는 것을 별로 좋아하지 않게 생각해서 이런 것 일 수도 있겠지만..

  






ps.벌써 시간이 이렇게....


두서없이 막 쓰긴 썼는데...


더 있던 것 같지만 지금 생각나는 것이라고 이 정도네요.


확실히 3년간 알만툴 만지만서 습득한 실전 노하우 입니다.


이런 실전 노하우를 바탕으로 나름 쾌적한 60fps 알만툴을 사용중입니다.


또 다른 노하우나 그런거 있으면 공유합시다.



-77er

Comment '14'
  • profile
    뿌잉뿌잉쨔응 2013.09.26 11:05
    전투시렉은 스크립트문제말고 다른경우도있을까요?
  • profile
    77ER. 2013.09.26 13:25
    어떤 경우인지 정확히는 모르지만 제가 적은 경우중에 하나일 가능성이 클걸요.
    공격할 때 애니메이션 이미지의 파일이 커서 에니매이션 실행 시 이미지 불러오는 것 때문에 렉이 생기던가 update_all_windows때문에 불필요하게 윈도우를 계속 업데이트 하던가 아이템 이미지가 크던가 등등.
  • ?
    77ER.님 축하합니다.^^ 2013.09.26 13:25
    포인트 팡팡!에 당첨되셨습니다.
    77ER.님은 19포인트를 보너스로 받으셨습니다.
  • profile
    뿌잉뿌잉쨔응 2013.09.26 14:44
    1600줄짜리아이템 셋써서 그런보네요.. 지금 바꿀수도없고 후..
  • ?
    Roam 2013.09.26 13:34

    이렇게 좋은 글을 써주시다니 감개무량합니다.
    너무나도 감사합니다.
    VX ACE 프레임때문에 곤란을 겪고 있는 제게 가뭄단비같은 글입니다.

    하지만 제가 스크립트에 관해 무지하여 제대로 실현을 해내지 못하고 있어서
    적어주신 내용 중 1,3,5번에 관해 질문을 드리고 싶습니다.

    -------------------------------------------------------------------------------------------

    [1.서브 폴더를 만들지 말아라] 관련질문

    써주신대로 Graphics/Animations/을 비롯한 Graphics 내부의 폴더들을 모두 밖으로 뺀다음

    load_bitmap("Animations/", filename, hue)
    load_bitmap("Battlebacks1/", filename, hue)
    load_bitmap("Battlebacks2/", filename, hue)
    ...
    load_bitmap("Titles2/", filename, hue)

    [Cache]→[module Cache]의 내용들을 이렇게 전부 다 변경을 했습니다.

    그런데 테스트플레이를 실행하자마자
    「unable to find : Titles1/Sword」라고 뜨면서 바로 종료가 됩니다.
    아무래도 타이틀화면 그림파일을 못 찾는 거 같은데...
    (Sword인 이유는 VXA 샘플 타이틀화면 중에 칼그림이 나오는 타이틀을 사용중이라 그렇습니다.)

    혹시 [Cache]→[module Cache] 안에 있는 내용들 외에, 다른 내용도 변경을 해야할게 있나요?

    -------------------------------------------------------------------------------------------

    [3.불필요한 업데이트를 삼가라. 필요할 때 업데이트를 적절하게 하라.] 관련질문

    [Scene_Base]→[update_basic] 내부의 update_all_windows 한줄을 지워봤습니다.
    그리고 테스트플레이를 시작하니,
    타이틀화면의 메뉴 윈도우가 뜨지 않아 게임을 시작할 수가 없습니다.
    ([시작한다][불러오기][종료한다] 이 3개의 메뉴들 있는 윈도우 말씀드리는 겁니다.)

    전 지금 아주 커다란 크기의 맵을 사용중이라 렉 때문에 곤란을 겪고 있는데
    update_all_windows가 어떤 원리인지 먼저 알고 싶습니다.
    혹시 이것을 지우면 프레임단위로 업데이트가 되지 않으니,
    맵 안에 있는 NPC들은 제자리에 서서 움직이지 않게 되는 건가요?

    그리고 update_all_windows 한줄만 지워서는 위에 썼듯이 정상적인 테스트플레이를 할 수가 없는데
    다른 어떤 부분을 어떻게 손대야 update_all_windows를 지워서 효과를 볼 수 있는지
    자세히 설명해주시면 감사하겠습니다.

    -------------------------------------------------------------------------------------------

    [5.사용하는 이미지는 게임 시작 전 다 불러오고 class를 나가게 될때 절대 이미지들을
    dispose 시키지 말아라.] 관련질문


    [Scene_Title]→[start]에

    temp = temp = Cache.picture("그림1")을 추가하라고 적어주셨는데

    만약 Graphics/Picture 폴더 안의「그림.png」라는 그림파일을 시작시에 미리 읽으려면

    temp = temp = Cache.picture("그림.png")

    이렇게 적으면 되는건가요?
    Graphics/Picture라는 폴더명은 적을 필요가 없나요? 확장자(.png)는 적어야 하는게 맞나요?


    테스트플레이의 오류는 발생하지 않지만 눈에 들어오는 게 없다보니
    효과가 나타나고 있는건지도 확실히 잘 모르겠습니다.

    그리고 마지막으로 위 그림들이 사용되는 스크립트를 찾아가서「.bitmap.dispose」를 시행하는 부분을
    삭제하라고 하셨는데,
    정확히 위치가 어떻게 되나요?「bitmap.dispose」는 꽤 여러군데 위치하고 있어서 잘 모르겠습니다.
    저는 현재 그림을 전부 이벤트를 이용해 삽입/이동/삭제하고 있습니다.
    그러니 스크립트 안에「그림.png」가 적혀있는 부분이 있을리도 없고...
    「위 그림들이 사용되는 스크립트를 찾아가서 .bitmap.dispose 을 시행하는 부분을 삭제」한다는

    의미가 대체 어떤 의미인지 구체적으로 알고 싶습니다.


    그리고 이 렉 줄이기 방법은 [시작한다]가 아니라

    [불러오기]로 기존에 저장된 게임을 불러오는 경우에도 효과가 있나요?

    만약에 효과가 없다면 [불러오기]로 게임을 시작할 때도

    미리 그림파일을 읽는 방법이 있나요?

    -------------------------------------------------------------------------------------------

    질문이 너무 길어 죄송합니다 ^^; 답변해주시면 정말 감사하겠습니다.

  • profile
    77ER. 2013.09.26 17:43


    윽.. 질문이 많네요 ㅎㅎ

    최대한 설명을 잘 해보죠.

    혹시 [Cache]→[module Cache] 안에 있는 내용들 외에, 다른 내용도 변경을 해야할게 있나요?
    ->네 해당 Sword 그림파일을 밖으로 뺀 Title1폴더에 넣어주셔야죠.
    "Graphics/Animations/" 의 의미를 우리말로 풀어보면..
    "Graphics폴더 내부에 Animations 폴더 내부에..." 입니다.
    이걸 "Animations/" 로 바꾸셨으니,
    Animations 폴더 내부에..로 Graphics폴더를 거치지 않는 새로운 폴더로 줄어들죠
    그러니 그 줄어든 폴더에 Sword 그림파일이 있어야되는거죠. 기존 Sword 파일은
    Graphics/Animations/에 있었는데(RTP형식으로) Animations/폴더를 새로 만들었으니
    거기에 파일이 필요한 겁니다.
    만약 기존 주어진 RTP파일 외의 그림파일을 타이틀 화면이나 기타 소재관리툴에서
    보고 작성하시는 거라면 일단 기존의 폴더에도 넣고 새로 밖으로 빼낸 폴더에도
    그림파일을 넣어서 관리에서 지정 해 준다음 기존의 폴더를 지워버리면 됩니다.

    사실 복잡하시면 RTP에 적용되는 폴더는 건들지 마시고
    (기존 Graphics폴더에 존재하는 폴더들 예를들어 Title1, Animations 등등..)
    새로 Cache 부분에 만드시는 걸 추천합니다.
    def self.roam(filename)
    load_bitmap("Roam_Stuff/", filename)
    end
    이런식으로 Cache 모듈안에 생성하시고
    Graphics폴더가 존재하는 같은 폴더에 Roam_Stuff라는 폴더를 만드신 후
    Scene_Title 의 40번째 줄의
    @sprite1.bitmap = Cache.title1($data_system.title1_name) 를
    @sprite1.bitmap = Cache.roam($data_system.title1_name)으로 바꾸셔서
    원하는 타이틀 이미지를 Roam_Stuff에 넣어서 사용하시면 됩니다.
    Title2도 같은 방식으로 사용하시고 다른 부분도 이런식으로 사용함 됩니다.
    위에 예가 <1. 서브 폴더를 만들지 말아라>의 사용 예라고 할수 있겠네요.


    전 지금 아주 커다란 크기의 맵을 사용중이라 렉 때문에 곤란을 겪고 있는데
    -> 음 일단 저는 알만툴의 이밴트맵을 사용하고 있지 않아서 잘은 모르겠지만
    큰 이밴트 맵에서 렉이 생기는 이유는 지금 눈에 보이는 544*416 화면 외의
    부분 이밴트들도 실행이 되기 때문에 렉이 생긴다고 보여집니다.
    이것을 해결하는 스크립트들은 해외 스크립터가 anti lag 같은 걸로 해결 한듯
    보여집니다. 전 이밴트 맵을 다루지 않아서 모르겠군요.

    update_all_windows가 어떤 원리인지 먼저 알고 싶습니다.
    ->간단합니다. 말 그대로 해당 씬에 포함되 있는 모든 윈도우들을 1프레임 단위로
    업데이트 하는거죠.
    update_basic이란 함수안에 update_all_windows가 포함되 있습니다.
    또 잘 보시면 Graphics.update와 Input.update가 있지요?
    전자 Graphics.update는 프레임 자체를 1씩 업데이트하는 것으로 가장 중요하고
    후자 Input.update는 그 1프레임 당 키보드를 입력할때 받는 값을 업데이트 하는
    기능으로 둘째로 중요합니다. 이것들과 update_all_windows가 같이 실행이 된다는
    의미지요. 그리고 이 update_basic은 update라는 최상위 업데이트 함수에 포함 되
    있고 이 update라는 함수는 Scene_Base라는 화면 씬을 보여주는 기본이 되는 클레
    스에 포함이 되 있습니다.
    Scene_Base를 분석하면
    def main
    start
    post_start
    update until scene_changing? <- 요 부분!!!!
    pre_terminate
    terminate
    end
    해당 씬이 다른 씬으로 (예를 들어 메뉴 씬) 바뀌지 않는다면 update저 부분이
    반복되어 실행됩니다.
    그리고 Scene_Base는 모든 Scene_관련 클레스들의 부모
    클래스가 되기 때문에 Scene_Base에 포함된 update함수가 모든 Scene관련 클래스
    에서 실행이 됩니다. 그러니 update_all_windows를 지워버리게되면
    Scene_Menu 라던지 Scene_Item같은 다른 신에서 윈도우들이 실행이 되지 않는거죠.



    왜 update_all_windows 처럼 1프레임마다 계속 윈도우를 업데이트 하면 안 되느냐?
    ->그 이유를 설명 드리겠습니다.

    일단 윈도우창 업데이트 부분을 살펴보면
    contents.clear 부분이 눈에 들어옵니다. 1프레임마다 계속 작성했던 것들을 다 지우고
    다시 작성을 한다는 거죠.....정말 비효율적입니다. 윈도우창에 작성한게 많다면
    렉렉렉렉렉 거릴게 분명 합니다.

    커멘드 윈도우처럼 커서를 움직여서 지정을 해 줘야 하는 윈도우는 1프래임 실시간
    으로 업데이트를 해 주는 게 맞습니다.(그것도 그 윈도우를 사용 하고 있을때의 이야기)
    하지만 스테이터스 윈도우 창을 생각해 보죠. 그 윈도우 창에는 능력치와 장비품,
    그리고 캐릭터 얼굴 등 다양한 정보들이 표시됩니다. 하지만 딱 한 번 표시하면 될
    뿐이고 그 창을 닫을때만 닫는 업데이트 하면 되는거지, 그냥 정보를 띄어놓고 있는 와중
    에도 게속 업데이트를 한다고 생각을 하 보시죠.. 렉의 도시가 되는 겁니다.
    그래서 그런 정보 창은 반드시 필요한 때만 업데이트를 시켜줘야 한다는 거죠.
    예를들어 전투 정보창이 있다면 적에게 공격을 받아 데미지계산하고 완료하는 그 순간
    딱 한번만 업데이트를 시켜주고, 다음 데미지 계산때 딱 그 순간만 해주는 그런식이
    되야 한다는 거죠. 주구장창 계속 애니메이션이 실행되는 와중에도.. 아무것도 안 하고
    멍때리고 있는 상황에도 계속 update_all_windows가 반복된다고 생각하면....음..

    *기본적으로 알아두시면 편한 것.
    class Scene_Menu < Scene_MenuBase 의 의미는 Scene_MenuBase를 복사해서 그 복사한
    부분에 Scene_Menu를 에 덮어 씌우겠다는 의미 입니다.
    Scene_Menu를 만들때 Scene_MenuBase의 내용을 고스란히 가져오겠다는 의미죠.
    또 Scene_MenuBase를 잘 보시면 class Scene_MenuBase < Scene_Base 로 되어 있습니다.
    그러니 Scene_Base가 모든 Scene들의 부모 Scene이라고 생각하시면 됩니다.


    다른 어떤 부분을 어떻게 손대야 update_all_windows를 지워서 효과를 볼 수 있는지
    -> 이건 각각의 Scene에 찾아가서 (기본적으로 19개의 Scene이 있네요)
    그 Scene에서 사용되는 윈도우들을 각각의 상황에 맞게 업데이트를 시켜 줘야 합니다.
    이 부분은 다소 복작할 수 있습니다. 각각의 윈도우 작동 부분을 이해한 후 또 그에
    맞게 간단한 스크립트를 작성해 줄 필요가 있거든요.
    예를 들어 Scene_Title로 가 보시면 사용되는 윈도우는 단 1개 입니다.
    @command_window = Window_TitleCommand.new 이지요.
    저 @command_window를 업데이트를 시켜줘야 하는데 이 윈도우는 커맨트 윈도우기
    때문에 실시간으로 계속 업데이트를 시켜 줘야죠.
    그리니 Scene_Base에서 update_basic 함수 부분을 통째로 복사해서
    Scene_Title 내부에 넣습니다.
    def update_basic
    Graphics.update
    Input.update
    @command_window.update <-이걸 추가해 주면 되죠.(이 방식이 한 윈도우를)
    end
    @command_window.update 이렇게 해 주는 방식이 실정된 한개의 윈도우를 업데이트
    시켜주는 방식 입니다.
    Scene_Title은 사용되는 윈도우가 단 1개 이기 때문에 문제가 없지만
    Scene_Menu는 윈도우가 여러게가 됩니다.
    사용되는 총 윈도우가
    @command_window
    @gold_window
    @status_window
    @help_window
    로 총 4개의 윈도우가 사용되기때문에
    def update_basic
    Graphics.update
    Input.update
    @command_window.update
    @gold_window.update
    @status_window.update
    @help_window.update
    end
    로 해 봤자
    def update_basic
    Graphics.update
    Input.update
    update_all_windows
    end
    와 별반 다를 바 없는 상황이 연출되기에 문제가 있지요.
    하지만 해결방법이 있습니다.
    def start 함수 내부에 @phase = 0 이라고 만들어 주신 후
    def update_basic
    Graphics.update
    Input.update
    case @phase
    when 1
    @command_window.update
    when 2
    @status_window.update
    when 3
    @help_window.update
    when 4
    @gold_window.update
    end
    end
    로 만들어서 각각의 @phase 값에 따라 윈도우들이 실행되도록 만들면 되는 겁니다.
    바로 위에는 정확한 예시가 아니고 업데이트를 할 수 있는 방법들의 아이디어이기때문에
    그대로 따라한다고 시행되는 것은 아닙니다. 또 @phase 값을 바꿔줘야하는
    부분을 만들어야 하기 때문이죠.
    렉을 줄이기가 그렇게 호락 호락 쉽지는 않습니다. ㅎㅎ
    지금 Scene_Menu 포함 19개의 모든 씬을 보여드릴 수는 없고 하는 방법을 알려 드렸습니다.
    이 부분은 초보자분들에겐 상당히 어려울 수 있으니, 가급적이면 이미 존재하는 씬을
    건들기 보다는 새로운 씬을 만들때 적용하는 걸 추천 드립니다.


    만약 Graphics/Picture 폴더 안의「그림.png」라는 그림파일을 시작시에 미리 읽으려면
    temp = Cache.picture("그림.png")
    이렇게 적으면 되는건가요?

    -> 예 맞습니다.
    Cache.picture("그림.png")의 의미는 Cache내부의 picture함수를 실행하여 "그림"을
    불러 온다 입니다.
    앞서 설명한 Cache모듈에 가 보시면
    def self.picture(filename)
    load_bitmap("Graphics/Pictures/", filename)
    end
    이거있죠? 이걸 실행한다는 의미죠.


    Graphics/Picture라는 폴더명은 적을 필요가 없나요?
    ->네 이미 def self.picture 함수 내부에 명시가 되 있어요.

    확장자(.png)는 적어야 하는게 맞나요?
    ->적어도 되고 안 적어도 되고요



    테스트플레이의 오류는 발생하지 않지만 눈에 들어오는 게 없다보니
    효과가 나타나고 있는건지도 확실히 잘 모르겠습니다.

    -> 그러면 지금 아주아주 큰 이미지로 실험을 해보세요.
    스크립트적용을 안한 상태와 한 상태를 비교하면 아실꺼예요.
    제가 4600*3700크기의 픽쳐맵파일을 사용중인데, 그걸로 실험해보니
    아주 실감나게 체감이 되요 ㅎㅎ


    그리고 마지막으로 위 그림들이 사용되는 스크립트를 찾아가서「.bitmap.dispose」를 시행하는 부분을
    삭제하라

    -> 예를 들어

    Scene_Title에서
    temp = Cache.picture("그림1")

    @그림 = Sprite.new(@viewport)
    @그림.bitmap = Cache.picture("그림1")
    이라고 만들었다고 가정을 한다면

    보통
    def dispose
    @그림.bitmap.dispose
    @그림.dispose
    end
    라고 만든 뒤
    def terminate 함수 내부에
    이 dispose 함수를 불러오게 되죠
    저기서 @그림.bitmap.dispose를 없애라는 의미 입니다.
    def dispose
    @그림.dispose
    end
    이렇게 만들라는 거죠.
    이제 실제 스크립트에 함 적용해볼까요?
    전투배경 스크립트의 예를 들어보겠습니다.
    Spriteset_Battle 클래스 내부에
    36번째 줄을 보세요.
    @back1_sprite = Sprite.new(@viewport1)
    @back1_sprite.bitmap = battleback1_bitmap
    262번째 줄을 보세요.

    @back1_sprite.bitmap.dispose
    @back1_sprite.dispose
    이제 보이시죠?
    @back1_sprite.bitmap.dispose 걸 제거하면 됩니다.
    이밴트로 불러오는 픽쳐같은 경우는 bitmap.dispose부분이 기본 스크립트에
    없는 듯 합니다.
    그래서 MOG - ERASED PICTURE CORRECTION (V1.0) 라는 스크립트가 만들어 진 듯 하나..
    렉 관련해서 노하우가 쌓인 지금시점에서는 전혀 필요가 없는 스크립트 같습니다.
    생각해보니 엔터브레인에서 괜히 이밴트 픽쳐 부분의 bitmap.dispose를 작성하지 않은게
    아니더군요... 음... 아니다.. 엔터브레인이라면 모르고 빠뜨린 것일 수도 있겠죠...ㅎㅎㅎ


    그리고 Scene_Title 의 start부분에


    ...

    temp = Cache.picture("그림1")

    temp = Cache.picture("그림2")
    ...

    Graphics.freeze와 create_background 사이에 해 주는 게 좋습니다.



    여기에 로딩픽쳐를 띄워서 로딩하는 모습을 묘화해보는 것도 좋겠죠

    @viewport_loading = Viewport.new(0, 0, 544, 416)

    @viewport_loading.z = 10000

    @nowloading = Sprite.new(@viewport_loading)

    @nowloading.bitmap = Cache.system("NowLoading_1")

    perform_transition

    ...

    @nowloading.bitmap = Cache.system("NowLoading_2")

    temp = Cache.picture("그림1")

    @nowloading.bitmap = Cache.system("NowLoading_3")

    temp = Cache.picture("그림2")
    @nowloading.bitmap = Cache.system("NowLoading_4")

    ...

    Graphics.frame_reset

    Graphics.fadeout(20)

    @nowloading.bitmap.dispose

    @nowloading.dispose

    @viewport_loading.dispose

    Graphics.fadein(1)


    이러면 큰 픽쳐들을 불러오는 동안 로딩하는 듯하게 묘화도 가능하죠



    그리고 이 렉 줄이기 방법은 [시작한다]가 아니라
    [불러오기]로 기존에 저장된 게임을 불러오는 경우에도 효과가 있나요?
    만약에 효과가 없다면 [불러오기]로 게임을 시작할 때도
    미리 그림파일을 읽는 방법이 있나요?

    -> 당근이죠. [시작한다] [불러오기] 이전에 실행되는 것이기때문에
    문제가 없어 보입니다.

    [시작한다] [불러오기] 둘다 컴퓨터 메모리에 저장된 특정 값을 건드는게 아니라

    해당 스크립트의 몇몇 정보만 저장하고 불러오는 것이기때문에 불러온그림파일 적용을 둘다 동일합니다.
    temp = Cache.picture("그림.png")을 하면 메모리에 저장되 버리는 것 같더군요.



    으악...ㅎㅎ

    일단 완성은 했네요


    쭉 셨는데... 틀린부분 정은 안 했어요

    이해되셨음 하네요

  • ?
    Roam 2013.09.26 22:46
    ㅇㅏ....세상에.....이렇게까지 정성스럽게 답변을 달아주시다니 ㅜㅠ
    정말 너무 감사합니다!
    제가 할 수 있는 건 꼭 좋은 게임 만들어 77ER님을 스탭롤에 올려드리는 것 뿐입니다.
    반드시 좋은 게임 완성하여 이 은혜에 보답하겠습니다!
  • profile
    77ER. 2013.09.27 00:54
    저도 댓글달면서 공부하는거져 ㅎㅎ
    이렇게 한 번 쭉 쓰고나니깐
    한동안 손 놓아도 저 내용 안 잊어버릴 듯요
  • ?
    77ER.님 축하합니다.^^ 2013.09.27 00:54
    포인트 팡팡!에 당첨되셨습니다.
    77ER.님은 11포인트를 보너스로 받으셨습니다.
  • ?
    죽은노예 2013.09.26 15:25
    이미지를 디스포즈하지 않으면 다른 클래스에서 잠시동안이나 계속 스프라이트가 남아있는경우도 있던데요.(xp하고 vx는 다른지 잘은 모르겠지만은)
    나머진 정보감사합니다.제가 불필요하게 업데이트를 많이 입력했는데 스프라이트를 띄우고 이후에 딱히 처리할게 없는경우는 업뎃을없애야겠군요.
  • profile
    77ER. 2013.09.26 17:39

    스프라이트는 dispose시켜야죠.

    sprite.bitmap.dispose를 시키지 말란 의미였죠 ㅎㅎ

    전체적으로 불러온 이미지를 dispose 시킬때는

    sprite.bitmap.dispose
    sprite.dispose

    를 시행합니다.

    저기서 메모리에 저장되있는 bitmap까지 삭제하게 되면
    또다시 해당 그림을 불러와서 스프라이트를 만들때 메모리에
    bitmap을 불러오게되니, 그냥
    sprite.dispose
    만 해주라는 의미죠 ㅎㅎ



    네 불필요한 업뎃이 가장 큰 렉의 요인입니다.

  • ?
    죽은노예 2013.09.26 17:45
    제가 오해했었네요.죄송합니다..(_ _)
    저도 bitmap.dispose는 잘해주진 않습니다. 가끔가다 반드시넣어주어야할때가 나오긴한데 그렇지않으면 굳이 해줄필요성을 못느끼겠더군요.(제가 잘못알고있는거라면 태클받습니다.)
  • profile
    77ER. 2013.09.26 17:48
    죄송하긴요 무슨 ㅎㅎㅎ 태클은 무슨 ㅎㅎㅎ
    제가 이해못하게 썼을 수도 있죠
  • profile
    77ER. 2013.09.26 17:54

    저는 책보고 강의듣고 배운게 아니라 쌩으로 만지면서 습득한 지식이다보니

    정확하지 않을 수도 있는데 가끔 이렇게 댓글을 달면

    제 3자분이 정확한 정보를 주시는 분들이 있어서요.

    그래서 배움 차원에서 그런건 좋아합니다.


List of Articles
분류 제목 글쓴이 날짜 조회 수
공지 아방스 게시물 · 댓글 작성 규칙 (최근 수정일 2015.11.25) 17 file 완폐남™ 2012.07.17 40543
제작 일지 여성향 노말 미연시(역하렘-RPGvx)를 만들다가 도트에서 거대한 벽을 느낍니다. 11 file 진솔새옷 2014.02.22 2508
제작 일지 어찌저찌 오타쿠vs미소녀 2차체험판 냈습니다. 뱀신의교주 2014.03.16 2001
제작 일지 VX, VXA) 지금껏 경험적으로 습득한 알만툴 렉을 줄이는 방법들. 14 77ER. 2013.09.26 1888
제작 일지 우타호노타타리2 강제 한글화 결정 4 아방스만세~! 2016.01.26 1838
제작 일지 복잡한 시스템 구현에 성공하는 모든 분들은 존경받아 마땅합니다. 40 file 에뎀이 2014.02.23 1837
제작 일지 Dialog Extractor (?) 15 AltusZeon 2014.01.16 1622
제작 일지 요즘 제 상황이 18 file 파이어 2013.09.02 1581
제작 일지 유니티 3D 게임 제작 진행 상황... 5 소프트아이스크림 2012.05.24 1486
제작 일지 캐릭터 이미지 깨짐현상 수정 6 file Luv 2014.06.22 1471
제작 일지 버질입니다. 아니 토호타쿠라고 합니다. 9 토호타쿠 2014.03.23 1440
제작 일지 시스템 대부분 완성! 본격적인 제작 시작!? 5 file 중꿔사랑 2013.11.07 1414
제작 일지 일주일 넘게 게임을 못만들고 있어요 2 file 암희 2014.06.04 1387
제작 일지 dayz 2d 로 만들어볼 생각인데 여려분의 의견은요? 1 JinJin 2013.01.28 1350
제작 일지 오타쿠vs미소녀 3차 체험판 나왔습니다. 9 뱀신의교주 2014.05.31 1305
제작 일지 오타쿠 탈덕 게임 제목이 바뀌었습니다. 6 뱀신의교주 2014.02.23 1296
제작 일지 [이름 생성기]일단 기본 베이스는 완성했습니다. 8 file 맛난호빵 2014.02.27 1289
제작 일지 세라가 입을 복장은 아청법에 걸리나봐요. 6 라실비아 2013.09.02 1241
제작 일지 캐릭터칩 개편 4 file 구륨 2014.06.22 1239
제작 일지 확실히 사이툴이 기능이 좋군요 22 file 요야 2014.02.04 1236
제작 일지 RMXP 스크립트를 또닥여보면서 알게된 사실. 1 JACKY 2013.01.22 1227
목록
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ... 23 Next
/ 23