해상도 조정

우리가 지정한 해상도로 바꿔줄 것인데

이게 지금 타이틀 창, 메뉴바 다 포함한 것이다.

윈도우 버젼에 따라서 크기가 달라진다.

코드는 같아도.

윈도우 버젼마다 스타일이 다른데 어떻게 다 대응함?

이것을 적응 시켜주는 크기를 잡아주는 함수가 있음.

비트 연산

WS_OVERLAPPENDWINDOW라는 함수를 보면

이전에 비트 연산을 통해서 뭐는 키고 끄고 한다고했었었는데

이게 지금 자주쓰는애들 비트연산해서 묶어놓은 매크로이다.

이런 비트 자리 차지하는 애들을 매크로로 묶어놓은거임.

또 자주 쓰니가 메크로로 묶은거임.

다시 해상도 조정

현재 프로그램 실행하면 메뉴바가 있으니까 true로 넣어주도록 하자.

참조값 받아가서 그대로 수정한다.

return 값이 없다.

rt가 만약 엄청 큰 사이즈의 경우 성능 저하가 일어날 수 있기 때문에.

그래서 26에서 미리 적응될 윈도우 크기 계산한다음에

좌상단 100, 100기준으로 가로 세로 잡아주면은

실제 내가 예상하는 '작업 영역'해상도를 얻었으니까 거기의 윈도우 크기를 셋팅해준다.

해상도 그려보기

이게 진짜 500, 500맞노?

=> 그려보면 된다.

싹다 정리하고

그리면

이렇게 끝에 딱 걸림.

우리는 무조건 adjustwindow를 통해서 얻어진 값 가져와서 사용해야한다 ❗

나머지는 Window OS가 버젼에 맞춰서 조절 해줌.

메세지 처리 기반이 아님.

그래서 여기서 그림그리기를 해 줄 것이다.

progress에서.

DC

그림을 그릴라면 'DC'가 필요함.

Device Context -> 커널 오브젝트임.

Beginpaoin랑 EndPoint랑 짝이다.

그런데 BeginPaint는 '메세지 처리'에서만 사용할 수 있는 전용함수이다.

이렇게 해주면 내부적으로 DC가 하나 만들어져서 그것을 얻어다가

이제 저 DC를 활용해서 그림을 그리면 -> 우리 윈도우에 그림을 그릴것이다.

이녀석을 다썻다면 커널 오브젝트이기 때문에 해제해달라고 요청해야됨.

'소멸자'에다가.

이렇게 요청해준다.

우리는 그림을 계속 그린다.

게임에서는 어떤 변경점이 있을때 마다 그리는 방식은 불리하다.

비효율적이다.

발톱의 때만큼이라도 움직여도 다 지우고 다시 그림.

과정

그려오는 과정을 못보게 하는것도 하나의 숙제이다.

변경점이 있든 없든 컴퓨터는 엄창난 속도로 다시 다 지우고 다시 다 그린다.

이게 '렌더링'이다.

변경점이 있건 없건 계속 그릴 것이다.

init

전역변수 _obj초기값 셋팅 ㄱㄱ.

core의 progress를 두단계로 나눌 것이다.

ㅇㅇ.. 이렇게.

render, update

여기서 그리고

update는 물체들의 변경점을 체크를 할 것이다.

여기서 물체들의 좌표나 그런점들 체크. => fixed => render();

입력받기

입력받고 메세지가 뭔지에따라서 움직일게 아니라

입력받자마자 바로 움직일 것이다.

이때 사용하는 것이 => 코드가 실행되는 순간에 뭐가 눌렸냐를 바로 따질 것이다.

'비동기 키 입출력함수'이다.

그런데,

코드가 수행되는 순간에 바로 체크를 하기 때문에

우리의 '윈도우'가 포커싱 됬는지 안됬는지 여부를 따질 수 없고

백그라운드여도 항상 수행될 것이다.

=> 이런 문제가 발생할 수 있어서 신경 써야한다.

왼쪽키

return 값에서 지금 이순간에 '뭐 눌렸는지만 확인하고 싶다면'

'0x8000' 이 "키보드로 뭔가를 눌렀냐?" 를 나타내는 16진수 값이다.

이거 비트 연산으로 '&' 해주면 0 아니면 1나옴. => 당연히.

1이라면 누른거잖아.

이렇게 해주고

이동하면 이래 되는데 이런 현상이 발생함.

왜?? => 처리 속도가 너무 빨라서...

확인 ❗❗

이게 지금

1초에 4만번을 호출하니까

이런식으로 누적되서 찌이익 그어진거처럼 보이는 것이다.

우쨰 해결할래??