게임 리뷰

[리뷰] 라이프 이즈 스트레인지

플레이 자체는 나온지 얼마 되지 않았던 당시에 했었지만 최근에 라이프 이즈 스트레인지 비포 더 스톰을 플레이했어서 얘부터 리뷰.

bhmJM6m0

시간을 되돌릴 수 있는 능력이 생긴 맥스 콜필드가 주인공이다. 시간을 되돌리는 것이 가능한 주인공이라는 컨셉은 돈노드 엔터테인먼트의 전작인 리멤버 미와 같지만 리멤버 미가 액션 게임이라면 라이프 이즈 스트레인지는 어드벤처에 가깝다.

시간 회귀를 이용한 퍼즐 맞추기를 제외하면 사실 텔테일 게임즈의 게임들과 큰 차이를 보이진 않는다. 결국 큰 틀은 이미 다 짜맞춰져있고 선택지에 따라 소소하게만 바뀌며, 마지막에 엔딩 선택지에 따라서만 엔딩이 달라지는 정도. 그럼에도 불구하고 이 게임을 해보라고 주변에 권유하고 있는데, 다음과 같은 이유다.

첫 번째로, 흥미로운 스토리라인. 주인공에게 시간 회귀 능력이 생긴 것에 대한 떡밥은 제대로 풀리지 않을지언정 높낮이가 있는 스토리는 게임을 흥미롭게 플레이할 수 있는 원동력이 되어준다.

두 번째로, 게임에서 몇 안 되는 성적대상화 되지 않은 청소년 여성 주인공이라는 점. 거기에 퀴어이기까지 하다. 이런 주인공이 더 많아져야 세상에 다양성을 인정하는 사람들이 많아질테지. 이런 주인공이 많아지려면 이런 게임을 플레이하는 사람도 많아져야 하고.

두 번째 이유가 별로 내키지 않는 사람이라고 하더라도 게임은 재밌게 즐길 수 있을 걸. 애초에 저런 정치적 올바름을 싫어하는 ㄹㄹㅇ 회원들도 강추하고 다니던걸.

기기 리뷰

[리뷰] AMD Radeon RX 5700 XT

최근에 하는 게임들에서 144FPS가 유지가 잘 안 돼서 RX 480에서 넘어갈 때가 됐다고 생각했다. AMD쪽에서는 RX 480을 능가하는 성능은 RX Vega 아니면 Radeon 7 정도 뿐이었는데, 둘 다 내가 원하는 전성비와 쿨링 소음 수준을 달성하진 못했다. 그래서 굳이 불매하는 NVIDIA쪽을 가야 하나 아니면 Navi 그래픽카드 출시를 기다릴까 하다가 Navi를 기다렸고 5월 달에 드디어 공개를 하고 7월에 출시를 했다. 애매하게 5700을 가느니 아예 5700 XT를 가서 5년 정도 쓰는 것도 나쁘지 않겠다 싶어서 메인스트림 최상위급인 5700 XT로 갔다. 물론 아직 비 레퍼런스 카드는 나오지 않았으므로 레퍼런스 카드로.

237107-rx5700xt-gpu-gallery2-1260x709

블로워팬의 악명인 소음은 없다. 걱정 좀 하면서 차라리 비 레퍼런스 카드를 기다릴까도 생각했는데 그냥 생일 맞이로 구매했는데 발열은 풀로드 기준 80도 내외 정도로 좀 높은 편이지만 소음은 들리지 않을 정도. 최대 팬속이 저점으로 고정되어 있어서 그렇고 팬속을 높이면 소음이 나긴 할 듯.

성능은 굉장히 만족스러운게, 레인보우식스 시즈를 최대 프레임 165프레임으로 고정시켜놓고 HEVC 인코딩을 돌리면서 게임을 해도 110프레임 미만으로 떨어지는 일이 거의 없다는 점. 그정도로 성능 수치가 높은 편이라 만족스럽다.

문제가 있다면 드라이버의 불안정성. 기존 RX 480 쓸 때 설정했던 향상된 동기화를 RX 5700 XT에서도 켜뒀다가 그래픽카드 문제인 줄 알고 식겁했더니 드라이버 문제였다. 또한 향상된 동기화를 꺼놨어도 가끔 생기는 불안정한 모습 때문에 아직은 게임에서 경쟁전/랭킹전을 돌리기엔 지켜봐야 할 상태.

안티-랙과 라데온 이미지 샤프닝은 아직 잘 모르겠다. 체감이 크게 느껴지진 않는 상태. 그래도 스터터링이 안 켤 때보다 줄어든 걸 보면 안티-랙 홍보 영상에서 말하는 CPU의 일을 최대한 주기적으로 하도록 해주는 건 맞는 것 같다. 다만 이게 인풋랙도 줄여주는지는 체감이… 애초에 핑이 프레임률보다 낮으면 체감이 확실히 될텐데 요즘 하는 게임인 레식은 프레임률보다 핑이 높기 때문에…

쨌든 레퍼런스 카드를 구매하는 것도 나쁘지 않은 선택이지만 온도를 더 확실하게 잡아서 여름을 잘 나기 위해서는 비 레퍼런스 카드가 좀 더 나은 선택이라고 보이고, 레퍼런스 카드를 구매하더라도 게이밍에 있어서 불만은 몇몇 게임에서 오류를 겪는 초기 드라이버 외에는 크게 있진 않을 듯. 플루이드 모션이 더 이상 지원되지 않는 것 때문에 불만인 사람도 많던데 애초에 여태 플루이드 모션 안 썼던 엔비디아 카드 이용자는 다른 방법으로 썼을테고, 플루이드 모션 썼던 라데온 카드 이용자도 뭐 굳이 플루이드 모션만 쓸 필요 없잖아?

미분류

GifLib 더러운 API로 용케도 여태 살아남았나

이번에 GifLib으로 GIF 디코딩 인코딩을 하게 됐는데 라이브러리가 정말 엉성한데다 문서도 부실해서 일단 대충 얼기설기 엮어서 몇가지 샘플로만 정상 동작 확인하고 끝냈다.

고수준 함수도 없고, 예제도 없으며, 그렇다고 저수준 함수가 친절한 구성으로 돼있느냐면 그것도 아니라서 예제 코드를 찾아보려고 검색해봤는데 그것도 안 나오고.

용케도 이런 상태로 여태 살아남았구나 싶을 정도. 어차피 MP4(H.264)랑 WebP로 대체되는 느낌인데 그래도 GIF가 살아남긴 할테니 전체적으로 개선됐으면 좋겠다 싶다.

잡담

[2019. 06. 19.] 근황

11월 이전까지 기초 3D 수학/물리랑 3D 애니메이션 공부해야 하는데 간단한 엔진 만들다가 라이브러리 관리가 너무 안 돼서(꼴에 원하는 건 많아서 라이브러리가 많음) 일단 이미지 인코딩/디코딩 라이브러리와 오디오 인코딩/디코딩 라이브러리를 분할하기로. 엔진이 분화되니까 덩달아서 세부 엔진도 분화되어서 일단 코어 부분을 분화하고 그걸 이용해서 서너개의 세부 라이브러리를 더 작성해서 엔진을 합치는 방식으로 갈까 하는 생각.

일단 코어인 libseed와 이미지 코덱인 libmorisot은 대충 틀이 잡혔다. libseed에서 참조카운터 오브젝트, 벡터/행렬 연산기, 2D/3D 위치 및 크기 저장용 구조체, 시간 관련 함수 등 여러가지를 구현해놓고 libmorisot에서 이 라이브러리를 이용해 이미지 인코딩, 디코딩, 픽셀 변환 기능을 구현했다.

일단 지금까지 사용한 라이브러리는 zlib, libpng, mozjpeg, openjpeg, libwebp, libtiff, xz, libsquish, etc1_utils, giflib, zopfli 정도고, TGA, DDS, PKM 파일은 직접 구현했다. 현재는 KTX 파일 구현 중.

KTX 파일이랑 PVR 파일만 구현되면 이미지 라이브러리 대충 마무리 해두고 오디오 라이브러리 구현 예정. 이미 하나 구현해놓은게 있긴 한데 libseed에 맞춰서 재구성 해두려고.

잡담

CMake 사용기

여태 엔진 만들던거 Visual Studio C++ 프로젝트로 생성해서 쓰고 있었는데 다른 플랫폼용으로도 쉽게 개발하려면 Makefile이 좀 더 낫지 않을까 싶어서 VS프로젝트를 벗어나볼까 싶어졌다. 하지만 Makefile을 그대로 쓰면 귀찮기 때문에 CMake를 쓰기로.

개발은 그대로 Visual Studio로 하지만 폴더를 읽어오면 CMake를 쓸 수 있고 리눅스나 맥에 가서는 Visual Studio Code 같은 걸로도 개발할 수 있으니까 더 낫다는 생각도 들고.

문제는 cpp 파일 하나 하나 추가할 때마다 CMakeLists.txt 파일을 수정해줘야 된다는 점인데 이거 어떻게 와일드카드 쓸 수 없나 싶기도 하고.

그간 Visual Studio 컴파일러 설정이 얼마나 쉬웠는지 깨닫게 되는 부분이… CMake 쓰니까 각 컴파일러마다 설정 직접 다 지정해줘야 돼서 귀찮아 :Q…

잡담

libWebP와 mozjpeg, Zopfli 삽질기

오랜만의 프로그래밍 일기. 요즘엔 이미지를 압축하는 프로그램을 만들어보고 있다. 프로그램 이름은 Degra. 열화 또는 저하를 뜻하는 degrade에서 따온 이름이다. 그러니까, 손실 압축 위주로 압축하는 프로그램.

UWP를 타겟으로 만들기 시작했는데, GUI 프레임워크 중에 쓸만하다고 생각하는건 XAML+C# 조합이고 x86, x64, ARM, ARM64 모두 동시 빌드해서 배포 가능한 플랫폼은 Win32 데스크톱보다는 UWP니까.

그런데 막상 UWP 앱으로 개발하려고 보니까 mozjpeg가 NASM이나 YASM을 써야 빌드가 되는 구조라 이걸 어쩌지 싶었다. 그래서 일단 libWebP부터 붙여서 webp 파일으로 압축하는 기능부터 구현.

멀티스레드 인코딩 기능이 분명 있는데 아무리 돌려도 WebP 인코딩에 싱글코어만  쓰는 문제가 있어서 아니 도대체 왜 이러는 걸까 했는데 릴리즈 모드로 빌드해보니 정상 작동. 아무래도 디버그 편의성을 위해서 디버그 모드에서는 싱글코어만 쓰는 걸로 추정된다. 어쨌든 WebP 인코딩 기능은 의외로 매우 편했다.

WebP 인코딩 기능 붙여놓고는 다시 mozjpeg를 붙이는 작업으로 돌아왔다. 일단 CMake로 Visual C++ 프로젝트 생성해놓고 빌드 결과물인 정적 라이브러리 파일을 UWP에 붙여보니 생각과 달리 잘 붙었다. x64로 테스트를 했었으니 나머지 x86, ARM, ARM64도 프로젝트 생성해서 붙이려고 하니 윈도우용 ARM과 ARM64를 mozjpeg에서 지원하지 않는 또다른 문제점이 있었다. 찾아보니 이슈는 만들어져 있는데 테스트 기기가 없어서 이슈가 닫혀있었다. 나도 뭐 딱히 테스트할 기기는 없고 해서 일단은 x64와 x86용만 붙여놨다. 인코딩 기능 인터페이스 자체는 libjpeg-turbo의 것을 사용하면 해결.

PNG 압축은 좀 고민을 더 했다. 8비트 인덱스 픽셀 포맷으로 만드는 기능은 추가가 이미 돼 있었고 인코딩은 Windows Imaging Codec(WIC)을 이용했는데 생각보다 압축률이 엄청 낮지는 않았음. 찾아보니 OptiPNG, pngquant, ZopfliPNG 등이 있어서 적용을 시도.

OptiPNG는 벤치마크 자료를 찾아보니 ZopfliPNG보다 성능이 딸리는데다 벤치마크 자료 찾아보기 전에 빌드 시도할 때 난황이 있었어서 포기. pngquant는 GPLv3 라이센스라 가져다 쓰기 좀 그랬는데 심지어 찾아보니 그냥 8비트 인덱스 픽셀 포맷으로 만들어주는 기능(+디더링, 미디언컷)만 있는 것 같길래 일단은 도입 포기. Zopfli만 적용하기로 했다.

드라마틱하게 압축률을 높여주진 않아서 실망했다. ZopfliPNG도 결국은 개선된 Deflate 알고리즘을 쓰는터라. Inflate에 들어가는 시간이 그냥 단순 WIC만 쓰는 것보다 많이 길어서 일단은 옵션으로만 남겨뒀다. 여러 인자를 좀 더 만져봐도 속도는 느려지는데 압축률은 고만고만 하더라. fast_zlib을 써서 libpng를 바로 적용해보는 것도 고민 중.

그래서 일단은 WebP, JPEG, PNG의 압축 기능은 구현이 됐다. 앱에서 GIF, TIFF 등의 그 외 포맷도 압축 기능을 지원할 지는 테스트 좀 더 해보고. UWP 파일 접근 권한 문제 때문에 안 그래도 골치아파.

기기 리뷰

[리뷰] JONSBO C3 PLUS

책상을 좀 더 넓게 쓰려고 최대한 깊이가 작은 미니타워 케이스를 찾아다녔고 특히나 방 창문쪽에 딱 붙여서 쓰고 싶어서 오른쪽 전면측 면에 바람 구멍이 있는 케이스를 찾다가 딱 마음에 드는 케이스를 찾았다.

BRAVOTECJONSBOC3PLUSSilverMain04

일단 미니타워 주제에 깊이가 360mm라서 다른 미니타워보다 작다. 너비가 200mm로 다른 케이스들에 비해 좀 펑퍼짐한 느낌이지만 나쁘지 않다.

3.5인치 하드디스크 2개, 2.5인치 하드디스크 3개?4개?를 달 수 있다. 각 하드디스크용 고정나사 자체가 모양은 비슷한데 다르니 남는 나사는 달리 보관하는 것이 좋을 듯. 메인보드, 파워, 그래픽카드까지 다 단 후에 하드디스크 고정을 메인보드, 파워서플라이를 장착하기 전에 해야 되는 줄 알고 멘붕했는데 다행히 그건 아니었다. 하드디스크에 나사를 고정하는건 고무 고정대 때문이고 이 고무 고정대를 구멍에 끼워서 밀어넣는 방식. 작은 케이스에 최대한 조립을 쉽게 할 수 있도록 나름 배려한 디자인이다.

에어홀도 다섯 개로, 전면 두 개, 상단 한 개(140mm 팬 기본 제공), 후면 한 개, 하단 한 개이다. 하단 팬이 있어서 그래픽카드 발열 해소에도 나쁘지 않은 듯. 단점이 있다면 팬 소음을 못 잡는다. 전에 쓰던 케이스에 달았던 ARCTIC F12 팬 다섯 개 중 네 개를 이쪽에 옮겨 달았는데 전보다 소음이 심해진 걸 보면 풍절음을 못 잡는 구조가 아닐까 싶다. 전보다 케이스 무게가 무거워진 만큼 진동음은 아닌거 같으니까. 여름까지 써보고 여름에 이 소음에 발열을 제대로 못 잡는다면 그냥 쓰고 발열 잘 잡으면 저항 써서 팬속을 좀 낮춰볼까 함.

문제점이 있다면 겉면은 날카롭지 않은데 안쪽이 살짝 날카로운 부분이 있다. 조립하면서 케이스를 움직일 때 손을 베지 않도록 주의해야 한다. 엄청 날카로운건 아니고 잘못 만지면 베일 거 같은 날카로움이라 안쪽에 손 대고 세게 누르면서 왔다갔다만 안 하면 될 것 같기도.

또 다른 문제점은 선 정리가 어렵다는 점. 하단에서 위쪽으로 올리는 에어홀이 있는데 이 부분이 파워서플라이 케이블들을 밀어넣으면 바람이 잘 안 올라오는 문제가 있어서 선 정리를 빡세게 해야 하는데 내가 보기엔 파워서플라이를 모듈러 방식으로 해서 안 쓰는 선을 최대한 없애야 하지 않을까 싶다. 파워의 SATA 전원 케이블도 ㄱ자 방식은 하드디스크에 장착하기 어렵다는 점.

뒷판 닫기도 좀 어려웠다. 뒷판쪽에 선정리를 하는 것이기 때문에 세워놓은 상태로 닫는건 말도 안 되고 눕혀놓고 꽉 누른 채로 나사를 조여야 한다.

단점이 많아보이지만 디자인이 다 커버하니까 괜춘. 원래는 좀 더 멋있는 블랙 모델을 사고 싶었는데 78,000원에 구매하긴 어렵고 브라보텍 공홈에서 실버 리퍼가 5만원에 나와서 갬맥스400 리퍼랑 같이 산거라… 솔직히 알루미늄 실버는 뭐랄까 대충 만든 느낌? 요즘 왜인지 모르게 유행하는 공사 하다 만 것 같은 카페 같은 느낌?이 들어서.

기기 리뷰

[리뷰] 한성컴퓨터 ULTRON 2559G

그동안 살까말까 고민해왔던 FHD 해상도의 144Hz 모니터를 구매했다. 끊임없이 아 굳이 144Hz 모니터를 사야하나 고민해왔었는데 기존에 쓰던 AOC 2477의 전면 편광필터 프레임이 살짝 뜨길래 홧김에 사버리고 기존 모니터는 동생 줌. 물론 정상 동작하고 있으니 동생도 한동안은 더 쓸 수 있겠지.

6516081_1

그동안 144Hz를 살까 고민하다가도 결국 포기했던 이유는 굳이 144Hz를 써가면서까지 게임을 해야 하나 하는 생각이었는데, 이 모니터를 구매하고 체감하면서 알았다. 게임을 하고 있지 않더라도 눈이 더 편해진다는 점을.

마우스의 움직임은 물론이고 웹 페이지의 스크롤, 애니메이션 등이 더 자연스럽게 보인다. 게임은 말할 것도 없다. 물론 144Hz를 쓴다고 해서 60Hz 대비 게임 실력이 더 늘진 않는다. 실시간 액션 게임이라면 상대방보다 좀 더 빠르게 볼 순 있겠지만 겨우 10ms 더 빨리 본다고 더 빨리 쏠 수 있을까? 라는 생각을 해본다면…

프리싱크도 켜놓긴 했지만 딱히 체감이 되진 않는게, NVIDIA GeForce GTX 970 쓸 때는 오버워치에서 테어링을 자주 경험했는데 AMD Radeon RX 480을 쓰고 부터는 테어링을 본 적이 없어서… 언젠간 체감할 수 있게 되지 않을까 싶긴 하지만 지금은 딱히 체감되진 않는다.

2559G는 TN 패널을 쓰고 있는데, 내가 굳이 더 저렴한 VA 패널 144Hz 모니터를 구매하지 않은 이유는 내 눈이 VA 패널의 잔상을 인식하기 때문이다. 서브 모니터로 쓰고 있는 BenQ GW2470HL이 VA 패널인데 60Hz에서도 잔상이 심해서 이 모니터로는 게임을 못 하고 있기 때문에 VA 144를 구매하지 않고 TN 144를  구매했다.

문제는 TN 패널의 색감이 IPS 패널에 비해 별로라는 점인데, 2559G에서 사용하는 TN 패널은 내가 예전에 써봤던 TN 패널 모니터에 비해 더 쨍한 느낌을 준다. 물론 이 더 쨍한 느낌은 게임에서 색의 대비를 더 잘 느끼게 해주기 때문에 게이밍용으로는 더 좋다고 보인다.

패널 문제와는 별개로 OSD 버튼에 불만이 좀 많다. 버튼 크기가 작은데다가 모니터를 끄기 위해서는 전원 버튼을 두 번 눌러야 하기 때문. 버튼이 작기 때문에 버튼이 어디 있는지 더듬더듬 하기도 쉽지 않다.

가성비 자체는 좋다. FHD 144Hz 모니터가 무결점 기준 25만원. 4년 전에 FHD 60Hz 모니터가 24만원 내외였다는 것을 생각한다면 좋은 가격대라고 보인다. 물론 한성컴퓨터의 A/S를 생각해본다면 제에에발 고장 안 나길 빌어야 한다는 점이 마이너스 요소겠지만 양품만 뽑는다면 전체적으로 좋은 선택이지 않을까.

잡담

[2018. 11. 25.] 근황

MonoGame을 이용해서 Entity Component System(ECS) 기반으로 2008년에 만들었던 SK-VM 게임을 리메이크 하는 중.

ECS 구조로 만들고 있는 가장 큰 장점은 개발하면서 생각한건데 관리되는 언어에서 사용하기 가장 효율적인 구조 같다는 점. 엔진에 ECS 만들어놓고 거기에 오브젝트 풀까지 적용해놓으니까 가비지 관리에 매우 용이해서 만족스럽다. 다만 아쉬운 점은 MonoGame이 멀티스레드 렌더링을 지원을 아직도 안 해서 엔진 자체는 멀티스레드 업데이트 -> 싱글스레드 렌더링을 하도록 해놨다. 물론 부동소수점 연산도 안 되고 램 용량도 2MB밖에 안 되던 피쳐폰 시스템에서 돌던 게임을 리메이크하는거라 뭘 어떻게 구현하든 2600X에서 CPU 사용량이 2%밖에 안 된다. 해상도가 176*178이라 GPU 사용량도 낮다.

다만 리메이크하는 게임이 완성본이 아니라 한창 개발 중이었던 소스+기획서 밖에 안 남아서 완성은 못하고 기본적인 시스템이랑 초반 맵만 구현 가능할 듯. 이렇게 된 이유가 2008년 당시에 친구가 노트북 포맷한다고 백업하게 외장하드 빌려갔다가 내 외장하드를 포맷해버려서… 그나마 개발 중이었던 소스는 학교에서 백업해놔서 그걸 받아와서 가지고 있던거고…

Unity로 리메이크하던 Shooting Hero는 오브젝트 풀 구현해야 되는데 너무 귀찮아서 보류. 새 리소스를 처음 사용하는 경우에 발생하는 스터터링도 해결해야 하는데 진짜 너무 귀찮아.

미분류

지금 사고 싶은 것들

1. NVMe SSD(최소 500GB)

250GB + 480GB SSD를 하나로 통합하고 싶고 2.5인치 저장매체로 되어있는걸 메인보드에다 안 보이게 꽂아두고 싶음

아마존에서 블랙프라이데이 딜로 1테라 M.2 SATA SSD 샀고 한국 날아오는 중. 스탠다드 배송인건 친구랑 같은데 친구는 더 일찍 출발해서 이미 저번주에 택배사로 전달됐는데 난 이제 비행기 타고 오고 있다.

2. 2.5인치 3TB 외장하드디스크

지금 쓰고 있는 3.5인치 4TB 하드디스크에 불량 섹터가 생기는 중. 한 달 안에는 반드시 사야 될 거 같은데 일단 블랙프라이데이 세일 기다리는 중.

옥션에서 그냥 샀다. 마침 빅스마일데이 할인 기간이라 2만원 싸게 샀음. 문화상품권 쓰면 만원 더 깎을 수 있었을텐데 귀찮기도 하고 해서.

3. FHD 144Hz 모니터

게임 144Hz로 쓰고 싶음

+ (2019. 03. 02.) 결국 샀다. FHD 144Hz 모니터. 리뷰 예정.

4. 맥미니(2018)

오랜만에 Xcode로 오브젝티브-C나 스위프트 프로그래밍 하고 싶다