제가 알기로 게임이나 그래픽 animation에서 보통 안정적인 drawing 기본은 timer를 사용한 일정한 tic time 구현으로 알고 있습니다.
주기적인 tic time event 발생시 현재 drawing중이거나 drawing이 필요없는 경우 drawing 루틴 호출을 무시하는 구조로 되있던 경우로 알고 있습니다.
tic time 없이 단지 loop로 돌고 중간에 sleep이 들어가는 경우라면 cpu부하와 drawing 일관성에 문제가 있지 않을까요?
drawing 시간이 고정적이지 않을 때, 기존 drawing 시간이 지난 후 timer가 호출된다면 중간 갭 없이 너무 빡빡하게 호출이 되서 부하가 많이 걸릴 것 같습니다.
더우기 미묘하게 drawing 작업 종료 전에 다시 drawing event가 걸린다면 실제 drawing작업을 하지 않더라도 새 event 무시같은 미묘한 문제가 생길 것도 같습니다.
C#이나 게임은 구경 해본적이 없습니다. 그냥 혹시나 해서 쓴 것이니 이해를 ^^;
예전 자바에서
dobule buffering이 가능하도록 보이지 않는 버퍼 drawing을 지원했던 기억이 납니다.
혹시 C#에서도 double buffering이 가능하지 않을까요?
특별히 계산량이 많이 않다면 double buffering만으로도 만족할만한 결과가 나옵니다.
double buffering 기능은 이미 쓰고 있습니다....
form에서 기본적으로 제공하고 있더군요..
게임이기 때문에 당연히 true로 체크 했습니다.
주요 계산량으로는.. 밑의 함수를 한 화면에서 약 20~40번을 호출합니다.
화면의 배경으로 이미지파일도 하나 그려줍니다.
한번 그릴 때마다 1 밀리초씩 쉬었습니다.
(Thread.sleep(0)으로 하니 메모리를 100% 차지하더군요 --; 노트북 사용자분들이 싫어할것 같아서)
C#에선 정말 쉽게 dobule buffering이 쉽군요.
C#에서 어떻게 지원되나 살펴보니 정말 쉽군요.
단지 속성 3가지만 설정하면 된다니..
그런데 drawing timing이 고정적인 간격이 아니라 반복적으로 loop를 도는 건가요?
drawing timing
update 함수와 draw 함수를
가능한 한 자주 호출하면서 가장 최근에 update함수가 호출된 시점부터 소요된 시간을 parameter로 넣었습니다.
공자 앞에서 문자쓰는 격이 될까 두렵습니다.
제가 알기로 게임이나 그래픽 animation에서 보통 안정적인 drawing 기본은 timer를 사용한 일정한 tic time 구현으로 알고 있습니다.
주기적인 tic time event 발생시 현재 drawing중이거나 drawing이 필요없는 경우 drawing 루틴 호출을 무시하는 구조로 되있던 경우로 알고 있습니다.
tic time 없이 단지 loop로 돌고 중간에 sleep이 들어가는 경우라면 cpu부하와 drawing 일관성에 문제가 있지 않을까요?
drawing 시간이 고정적이지 않을 때, 기존 drawing 시간이 지난 후 timer가 호출된다면 중간 갭 없이 너무 빡빡하게 호출이 되서 부하가 많이 걸릴 것 같습니다.
더우기 미묘하게 drawing 작업 종료 전에 다시 drawing event가 걸린다면 실제 drawing작업을 하지 않더라도 새 event 무시같은 미묘한 문제가 생길 것도 같습니다.
C#이나 게임은 구경 해본적이 없습니다. 그냥 혹시나 해서 쓴 것이니 이해를 ^^;
저도 잘 모릅니다만..
제 경우는
한 XNA 게임 프로젝트의 소스를 보고 비슷하게 구현봤던 겁니다..
댓글 달기