날이 더워지니 작업이 점점 더뎌진다. 그래도 꾸역꾸역 작업을 진행시켜나가고 있다. 처음엔 10cm길이의 정방형 복셀만을 사용해서 파괴 가능한 조밀한 지형지물에만 사용하려 했다. 그렇지만..음 역시 이 데모-혹은 게임을 완성했을때 2명 이상이 동시에 접속해서 pvp를 즐길거라고는 전혀 생각이 들지 않는다. 그래서 마인크래프트처럼 뭔가 만들 수 있는 기능을 우선 넣기로 했다. 그러자면 10cm짜리 복셀은 뭔가를 만들어내기 위한 블럭으로 사용하기엔 … More Game Dev – 다양한 사이즈의 복셀 지원 및 컬러 팔레트 구현
DX12에서 CPU에서 처리하는 시간을 줄인건 명백한 사실이다. 그런데 DX12로 짜면 GPU큐를 꽉 채우기가 진짜 힘들다. DX12로 포팅한 게임이 성능이 안나오는건 GPU와 게임이 DX12를 제대로 지원을 안해서가 아니고 GPU가 놀게 되는게 문제다. 궁금한 사람들은 GPU-Z라도 띄워서 DX12용 게임을 플레이할때 GPU점유율이 몇%나 나오는지 확인해보라. DX11과 비슷하거나 성능이 조금 더 안나오는 게임이라면 GPU점유율이 11에 비해서 12일때 더 떨어진다. … More DX11과 DX12의 성능차에 대한 잡설
기존 win32 Crypto API로 작성했던 계정이랑 패스워드 암호화 코드땜에 UWP버전의 네트워크 처리가 계속 지연되고 있었다. UWP아니 WinRT의 AsymmetricKeyAlgorithmProvider 를 이용해서 Desktop과 UWP공용 암호/복호화 코드를 짰다. 일부 WInRT(UWP) API들은 데스크탑 어플리케이션에서도 사용할 수 있는데 다행히도 AsymmetricKeyAlgorithmProvider는 Windows 8데스크탑부터 사용할 수 있다. 각각 win32 DLL과 UWP DLL로 만들어서 DLL로 만들어서 서버(Windows Server 2012R2) , win32 클라이언트(Windows 10) … More GameDev – win32버전과 UWP버전의 네트워크 플레이
예전에도 포스팅한적이 있는데 나는 지금껏 작업해온 엔진을 UWP용으로도 유지하고 있었다. 아니 정확히는 유지는 잘 못했다. 작년 12월 이후로는 유지보수를 못하고 있었다. 데스크탑 버전의 경우 12월부터 지금까지 DX12를 지원하는데 대부분의 시간을 보냈다. 그런데 DX12를 지원하면서 DX11버전도 사실 많이 바뀌었다. DX12와 인터페이스를 맞춰야하다보니 그리 된것도 있고 이번 게임데모 프로젝트를 위해서 렌더러 외의 모듈에도 기능추가가 있었기 때문에 많은 … More GameDev-UWP와 Desktop버전 동시 지원
th2빌드는 현재 Windows 10의 공식 빌드이다. Redstone은 7월 릴리즈가 예정된 Windows 10의 베타 빌드이다. 개발중인 D3D12 엔진을 Redsone과 th2에서 돌려보면 조금 다르게 돌아간다. 렌더링이 다른게 아니고 에러 발생 여부가 다르다. 대부분 ResourceBarrier관련인데 th2와 Redstone 모두 렌더링은 정상적으로 되고 있던 것들이다. th2빌드에선 에러가 나지 않았는데 Redstone에선 에러가 발생하고 DX Control Panel에서 에러 발생시 브레이크를 걸도록 하면 … More Windows 10 Redstone빌드와 th2빌드의 DirectX 12 차이점
옵티머스,엔듀로 이런게 평소에는 내장 gpu를 사용하다가 필요할때 dGPU를 쓰는 기술이다. 엔듀로는 요새 많이 안쓰는거 같고 요새 나오는 GPU특화된 대부분의 노트북들은 옵티머스 기술이 적용되어있다. 이 빌.어.먹.을 옵티머스가 DirectX 9/11세대에서도 많은 문제를 일으켜왔는데 DirectX 12에선 진짜 꽤 치명적인 문제를 안고 있고 아직 해결되지 않고 있다. 우선 Windows 10의 현재 정식빌드인 th2(10586)에서 Present()를 호출하면 간헐적으로 에러를 발생시킨다. 옵티머스 … More D3D12 – 옵티머스 장비에서의 문제점
미리 말해둔다. D3D12 렌더러 작업을 시작하기 전, 그러니까 지금 D3D12렌더러의 원형이었던 D3D11렌더러는 Single-Thread기반이었다. 게임엔진 자체는 여기저기서 멀티스레드를 사용하고 있지만 렌더링-그래픽 API사용 계층은 싱글 스레드로만 동작했다. 이전 포스트에서도 언급했듯이 그럼에도 불구하고 GPU 점유율 90%이상의 괜찮은 성능을 보여주었다. 그런데 D3D12렌더러를 만들면서 이전의 작동방식은 GPU를 펑펑 놀게 하는 결과를 가져왔다. 그래서 별로 내키지는 않지만 렌더러를 멀티스레드 체계로 바꿨다. … More D3D12엔진개발 – Multi-Thread 렌더링, Wait줄이기
똑같은 상황에서 메모리 사용 현황 DX11 – System: 579,608 KB , GPU Dedicated: 279,536 KB DX12 – System: 598,608 KB , GPU Dedicated: 553,136 KB 그리고 VS2015 Graphics Debugger에서 프레임을 캡쳐해서 현재 D3D 오브젝트들이 사용하는 메모리 사이즈를 다 합산해봄. 202665770 Bytes -> 193MB 1. 시스템 메모리 사용량은 D3D11, D3D12엔진 모두 비슷. GPU Dedicated메모리 사용량은 DX12가 … More D3D12엔진에서 GPU Dedicated 메모리를 쳐묵쳐묵하고 있는 건에 대해서.
D3D12 그래픽칩별 이런저런 현상 <intel HD520> 이전 드라이버에선 GPU메모리 사용랑이 1GB넘어가면 드라이버가 hang되어버렸음. 현재 최신 베타드라이버에선 돌아는 감. 심.각.하게 느림. GPU 에서 땡겨갈 수 있는 데디케이트 메모리가 부족해서 시스템 메모리로 스왑이 자주 일어나는게 원인일거라고 추측함. 참고로 같은 사이즈의 리소스를 사용할때 D3D12는 데디케이트 메모리를 3배쯤 쳐먹음. D3D12에선 리소스 -> 리소스 전송도 Command List를 사용하는데 이 부분도 … More D3D12엔진 개발 – 현재까지 발견한 GPU별 특징
며칠전 개발중인 D3D12렌더러에 Compute Shader를 이용한 Hi-Z Occlusion Culling을 만들어넣었었다. 물론 Occlusion Culling에 걸리는 시간으로만 보면 Hi-Z Occlusion Culling이 훨씬 빠르다. 그러나 Hi-Z Culling은 Bounding Sphere를 가지고 테스트 하기 때문에 정확도가 많이 떨어진다. 보이지 않는 오브젝트도 보인다고 판정할 확률이 높다. 그래서 이전 D3D11렌더러에서도 Hi-Z Culling이후에 D3DQUERY를 이용한 Occlusion Culling을 사용했다. D3DQUERY Occlusion Culling을 추가로 사용하면 … More D3D12엔진개발 – D3DQUERY를 이용한 Occlusion Culling
댓글을 달려면 로그인해야 합니다.