창작에 관련된 질문이나 간단한 팁, 예제를 올리는 곳
글 수 185
흥크립트의 반전버그의 원인을 알았지만,
그게 간단한 문제가 아니라 거의 시스템을 다 엎어야 할 버그란 걸
깨달았습니다.
일단 흥크립트는 원본 그림은 그대로 둔 채
DuplicateSurface란 명령으로 그림을 복사해서 씁니다.
그런데 사실 복사라고 해서 그림을 하나 더 만들지만
사실상 메모리는 공유하기 때문에 메모리 소비가 거의 없습니다.
이런 효율적인 기능때문에 썼던 것인데...
이 DuplicateSurface로 생성한 그림에는 반전이 잘못 먹힐 때가 있다는 것!
...이 정답이었습니다.
그리고 이 명령이 각 집의 비디오 카드에 따라 되지 않는 곳도 있다는 것.
어쩌면 Vista 환경에서의 에러의 원인일지도 모른다고 생각하지만
확실하진 않고... 결론은 안정성이 떨어진다는 겁니다.
그렇다면 4가지 해결책이 있습니다.
1) 좌우반전을 막아 버린다.
가장 간단한 방법이면서 지금까지의 체계를 유지할 수 있으나
이런 퇴화적인 해결책은 절대 쓰고 싶진 않습니다.
2) 전부 CreateSurface로 생성한다.
이것은 그야 말로 메모리 낭비가 2배가 되는 방법.
이것 역시 쓰면 안 됩니다.
3) 한 장의 그림으로 하나의 Surface만 쓴다.
이것이 가장 기본적인 구조입니다.
지금까지의 게임도 이런 식으로 만들어서 문제가 없었습니다.
하지만 여기서 생기는 문제는 하나의 그림으로 2장의 그림을 나타낼 때입니다.
2장 모두 같은 속성이면 괜찮은데,
하나는 반투명이고, 하나는 불투명으로 출력.
...이게 안 되는 겁니다.
4) 한 장의 그림을 출력 방법을 바꿔가며 출력한다.
내부적으로 코드를 엄청나게 바꿔야 하지만,
가능한 손실없이 처리할 수 있는 방법입니다.
문제는 일단 수정 시간이 꽤 걸릴 듯 하다는 것과,
출력 정보를 가지고 있는 JPictureInfo라는 정보를
그림에 적용시키는 시간이 얼마나 드느냐입니다.
사실상 얼마 안 들겠지만, 출력할 때마다 이것을 적용시키면
그것 역시 속도 낭비라고 할 수 있습니다.
어쨌든 이 부분은 내부 문라이브를 많이 조사해 봐야 될 듯 싶습니다.
개인 적으로 찝찝하던 버그의 원인을 명쾌히 알았고,
오랫동안의 권태를 풀 재밌는 작업이 생겨서 좋습니다.
* 똥똥배님에 의해서 게시물 이동되었습니다 (2008-03-11 14:03)
그게 간단한 문제가 아니라 거의 시스템을 다 엎어야 할 버그란 걸
깨달았습니다.
일단 흥크립트는 원본 그림은 그대로 둔 채
DuplicateSurface란 명령으로 그림을 복사해서 씁니다.
그런데 사실 복사라고 해서 그림을 하나 더 만들지만
사실상 메모리는 공유하기 때문에 메모리 소비가 거의 없습니다.
이런 효율적인 기능때문에 썼던 것인데...
이 DuplicateSurface로 생성한 그림에는 반전이 잘못 먹힐 때가 있다는 것!
...이 정답이었습니다.
그리고 이 명령이 각 집의 비디오 카드에 따라 되지 않는 곳도 있다는 것.
어쩌면 Vista 환경에서의 에러의 원인일지도 모른다고 생각하지만
확실하진 않고... 결론은 안정성이 떨어진다는 겁니다.
그렇다면 4가지 해결책이 있습니다.
1) 좌우반전을 막아 버린다.
가장 간단한 방법이면서 지금까지의 체계를 유지할 수 있으나
이런 퇴화적인 해결책은 절대 쓰고 싶진 않습니다.
2) 전부 CreateSurface로 생성한다.
이것은 그야 말로 메모리 낭비가 2배가 되는 방법.
이것 역시 쓰면 안 됩니다.
3) 한 장의 그림으로 하나의 Surface만 쓴다.
이것이 가장 기본적인 구조입니다.
지금까지의 게임도 이런 식으로 만들어서 문제가 없었습니다.
하지만 여기서 생기는 문제는 하나의 그림으로 2장의 그림을 나타낼 때입니다.
2장 모두 같은 속성이면 괜찮은데,
하나는 반투명이고, 하나는 불투명으로 출력.
...이게 안 되는 겁니다.
4) 한 장의 그림을 출력 방법을 바꿔가며 출력한다.
내부적으로 코드를 엄청나게 바꿔야 하지만,
가능한 손실없이 처리할 수 있는 방법입니다.
문제는 일단 수정 시간이 꽤 걸릴 듯 하다는 것과,
출력 정보를 가지고 있는 JPictureInfo라는 정보를
그림에 적용시키는 시간이 얼마나 드느냐입니다.
사실상 얼마 안 들겠지만, 출력할 때마다 이것을 적용시키면
그것 역시 속도 낭비라고 할 수 있습니다.
어쨌든 이 부분은 내부 문라이브를 많이 조사해 봐야 될 듯 싶습니다.
개인 적으로 찝찝하던 버그의 원인을 명쾌히 알았고,
오랫동안의 권태를 풀 재밌는 작업이 생겨서 좋습니다.
* 똥똥배님에 의해서 게시물 이동되었습니다 (2008-03-11 14:03)