저는 저에게 가장 중요한 두 가지가 획과 원이있는 기하학적 원시를위한 알고리즘을 연구했습니다. 오라클은 페인팅을 위해 이러한 모양을 생성하는 정확한 정보를 제공하지 않는 것 같습니다. 내가 이것을 원했던 이유는 그림에서 영향을받은 픽셀을 게임 충돌 감지를 위해 texturePaint []에 저장해야하기 때문입니다. 나는 bufferedImages를 사용하기 때문에 RAM의 문제로 인해 게임 맵을 얼마나 크게 만들 수 있었는지에 대한 전문가의 의견을 주로 원했습니다. 그것은 배열을 통해 반복에서 내 그림 프로세스를 상당한 속도로 느리게합니까 또는 자바 모양을 그리기 위해 그림에 대한 각 픽셀을 통해 반복합니까?기하학적 원시를위한 Java 알고리즘
속도면에서 보면 writeableraster을 사용하면 이미지를 매우 빠르게 변경할 수 있습니다. 또한 fork/join과 같은 도구를 사용하여 필요한 경우 빠르게 처리 할 수 있습니다.
충돌 감지의 측면에서 볼 때, 저는 자신의 수작업 수학 기능에 의존해야 할 것 같습니다. 여기에 an example입니다.
편집 :
I의 부호화의 종류를 수행 하였다, 난 writeableraster에 setPixels 메소드를 사용하여 훨씬 빨리 그러한 도형 그리기 같이 paintComponent에 접근 방식에 의존보다 것을 발견했다. 보다 확실하게 느끼기를 원한다면, 10000 번 작업을 반복하여 각 접근법을 테스트하는 몇 가지 기능을 작성하고 어떤 접근법이 더 빨리 완료되는지 확인할 수 있습니다.
멀티 스레딩 외에도 자바의 double buffering 및 BufferStrategy 도구를 사용하여 필요하기 전에 다음 래스터를 준비 할 수 있습니다. 이 방식으로 각 연속 래스터는 이미 버퍼에서 미리 렌더링 되었기 때문에 차례가 올 때 단순히 "켜기"만됩니다.
이러한 추가 링크가 도움이되기를 바랍니다.
그래도 그림을 그리는 동안 도형을 만드는 데 사용되는 기하학적 알고리즘을 사용하여 포크를 만들고 결합하면 화면에 동시에 페인팅하는 동안 배열에 영향을주는 픽셀을 모두 추가 할 수있을만큼 빠르게 반복 할 수 있습니까? 또한 쓰기 가능한 래스터에서 setPixels 메서드를 사용하여 영역으로 영향을받는 픽셀을 저장하고 모양으로 그리는 것보다 빠릅니까? – StoneAgeCoder
@ StoneAgeCoder +1 계속 배우려고합니다. 방금 질문에 답변하기 위해 원래의 대답을 편집했습니다. 이 질문에 대한 대답이 있습니까? – CodeMed
조언 해 주셔서 감사합니다. 두 기사를 읽고 BufferedImage에서 setPixels 메서드를 테스트했습니다. 불행하게도 쓰기 가능한 래스터에 getData() 메서드를 사용하면 올바르게 그려지지 않습니다. 그러나 getAlphaRaster()를 사용했을 때 제대로 작동했지만 실제로 원하는 회색 음영 버전을 반환했습니다. 이 후 난 setRGB() 메서드를 시도하고 그것은 작동하는 것 및 paintComponent() 메서드를 사용하여 픽셀로 사각형 픽셀을 채우는 것보다 약 100 배 빠르게 화면을 그립니다. 또한 실제로 여러 개의 버퍼를 코드 형식으로 준비하려면 무엇이 필요합니까? – StoneAgeCoder