http://bbs.ruliweb.com/game/4263/board/read/4762882
코룸 외전.
이전에 코룸 1,2,3이 있었고 나름 국산 액션 RPG 시리즈로 한 획을 그은 게임 시리즈였다. 외전은 턴제 RPG로서 이름만 코룸…이라는 느낌의 그런 게임이었다.
1999년에 회사 입사하고 처음 참여했던 게임이다.
대단한 일을 한건 아니었고 코룸외전 안에 들어가는 미니 게임 4종을 만들고 캐릭터 함수 짜고 자잘한 디버깅들, 자잘한 잡무들을 했다.
그 시절만 해도 24비트/32비트 화면모드를 게임에서 사용한다는건 말도 안되는 일이었고 저사양이면 8비트 256컬러, 중급 이상이면 16비트 65536컬러 모드를 사용했다.
16비트 모드는 1:5:5:5 모드 아니면 5:6:5모드로 구현됐는데 지금이야 16비트를 모드를 지원하지 않거나 아니면 아예 두가지 다 지원하지만 그땐 그래픽카드들이 둘중 하나만 지원했다.
그런데 코룸외전의 내부 스프라이트 처리 코드는 모든 이미지 데이터를 1:5:5:5 16비트 체계로 처리하고 있었고 최종 출력도 그렇게 하고 있었다. 지금은 1:5:5:5 모드 거의 찾기 힘든데 그 당시엔 5:6:5방식의 그래픽 카드가 더 드물었다. 회사에서 사용하던 퍼미디어2 그래픽 카드는 1:5:5:5방식이었고 내가 집에서 사용하던 부두밴쉬는 5:6:5 방식이었다.
입사하고 얼마 안되어 코드를 집에서 돌려봤는데(지금은 생각하기 어렵지만 그 시절은 다들 그랬다) 화면이 와장창 깨졌다.픽셀 출력 코드를 고쳐서 5:6:5모드로 변환시켰더니 정상출력되었다.
다음날 팀장한테 얘길 했더니 팀장은 5:6:5 존재 자체를 부정했다. 오전 내내 싸웠다.
결국 내부 코드는 못고친다는 결론이 나왔고 그래서 내부는 건드리지 않고 최종 출력할때(flipping하기 직전에) 한 픽셀씩 1:5:5:5 -> 5:6:5로 변환하는 코드를 만들어넣었다. 당연히 C로 짜면 느리니까(지금도 이런 코드는 그냥 c로 짜면 느리다) 이 부분 코드를 mmx 명령어를 이용해서 어셈블리로 작성했다. 동시에 4픽셀씩 변환했던걸로 기억한다. 그 당시 하이텔 게제동의 안영기님 자료를 보고 학습했다.어셈블리어도 그때 처음 학습했고.
메모리 왕창 새고 있었는데 게임 초기화하자마자 종료, 타이틀 화면 나오자마자 종료, 전투 한번 하고 종료,,뭐 이런식으로 잘개 쪼개서 내가 탐지했던 메모리릭은 다 잡았다.
첫 프로젝트였고, 비중있는 작업은 아니었지만 게임을 어떻게 만드는지 알게 해줬고, 이런저런 시도도 해볼 수 있었던 의미있는 프로젝트였다.
하지만 게임이 사실 너무 재미 없었다. 손발이 오그라드는 오프닝과 엔딩, 대사들. 괴센스에 솔직히 정말 재미없었다. 실제로도 코룸 팬들에게도 팬이 아닌 유저들에게도 외면받았고 평판은 안좋았다.
출시후 코룸외전 패키지를 받았지만 한번 열어보지도 않았다. 즉 집에선 한번도 플레이하지 않았다. 당당 버릴수는 없어서 패키지 꽃아놓은 책장의 공간이 아깝다고 생각했었다.
그땐 흑역사라고 생각했다. 음..뭐 지금도 그렇게 자랑스럽진 않지만. 그래서 누군가에게 그냥 패키지를 줘버렸던거 같은데 누군한테 줬는지 기억이 안나네.
언젠가부터인가 그 패키지를 남 줘버린게 꽤 후회가 된다. 그냥 갖고 있을걸. 내 청춘의 소중한 기록이었는데.
그립네.
yuchi's development 
js나 java를 이용해 웹,앱 쪽만 해오던 저에게 이 부분이 신기하게만 느껴지내요..
“당연히 C로 짜면 느리니까(지금도 이런 코드는 그냥 c로 짜면 느리다) 이 부분 코드를 mmx 명령어를 이용해서 어셈블리로 작성했다”
좋아요좋아요
픽셀 단위로 처리해야하니까요. 1000*1000사이즈만 되어도 1클럭 차이가 100만 클럭으로 벌어지니 1클럭도 크죠. 그리고 지금도 마찬가지인데 컴파일러가 SIMD명령을 제대로 이용해서 자동으로 최적화해주진 못해요.
좋아요좋아요
우선 이 글과 큰 연관이 없고, 제가 학생이라 어느정도 수준낮은 질문을 해서 양해부탁드립니다
저는 대학에서 C나 C++을 배워도 어셈을 한번도 배워본적이 없습니다. 시스템 프로그래밍이라는 수업에서 점프,무브,레지스터 명령어가 어떤거고 컴퓨터 내부의 레지스터구조와 동작원리 등에 대해 배웠던 것은 기억납니다.
근대 수업에서 보통 C가 가장 빠른 이유가 C를 컴파일하면 생성되는 어셈코드가 실제 어셈프로그래머가 작성한 코딩과 가장 유사하기 때문에 빠르다고 들었습니다. <- 이 부분이 맞는지도 궁금하고(결국 왜 C가 빠르다는 건가요, 모든 랭귀지(인터프리터 X)는 컴파일하면 어셈이 생성되고 목적파일이 생성되는데 그럼 결국 같은 머신코드로 실행되는거 아닌가요? (물론 각 엔진마다 생성되는 어셈과 머신코드의 결과차이는 있겟지만 이게 많이 차이가 나는건가요?), 머신러닝도 파이썬으로 많이 활용되는데, 그럼 머신러닝같이 피지컬이 중요한 부분에서도 왜 C를 안쓴다고 생각하시나요?)
그리고 지금도 어셈코딩이 많이 활용되는지 궁금합니다. 또한 게임에 초점이 맞쳐진 유니티는 왜 C#이랑 JS를 채택한건가요?
좋아요좋아요
C로 작성하면 프로그래머가 작성한 어셈코드와 유사하게 나옵니다. 그리고 요새 컴파일러는 프로그래머가 직접 작성한 어셈보다 대체로 더 효율적인 코드를 만들어줍니다.
그런데 왜 어셈을 쓰느냐…하면 제가 글에서 mmx를 거론했는데 mmx같은 simd명령어들은 여전히 자동으로 최적화된 코드를 만들어주지 못합니다. simd명령어를 사용해서 동시에 몇샘플 처리한다고 하는것이 일종의 퍼즐맞추기 비슷해서 기계적인 방법으로는 일반화시키기 어렵습니다. 그래서 지금도 simd명령을 활용할땐 어셈을 많이 사용합니다.
그리고 픽셀단위 처리처럼 1클럭이 중요한 코드에선 어셈으로 짜는것이 비교적 투명하게 작동과정을 확인할 수 있고 1-2클럭 단위로 유추해가며 최적화를 할 수 있습니다. 비트연산을 활용한 각종 트릭들을 구현하기에도 훨씬 직관적이고요. 군더더기 코드 붙을 소지는 아예 없고요.
두번째 질문은 컴파일되는 언어중에서 특별히 C가 빠를 이유가 있냐는 질문인것 같습니다.
원론적으론 C가 더 빠를 이유가 없는데 비교적 초기에 나온 언어이다보니 언어 자체가 어셈블리와 거의 1:1대응되는 느낌으로 만들어져있습니다. 플랫폼 독립적인 어셈블리어라 봐도 좋습니다. 실제 플랫폼 독립적인 어셈블리어로 많이 쓰였습니다. 고급언어하는 사람들은 그래서 ‘C는 되는게 없다’라고도 말하고요. 따라서 어떤 언어가 C처럼 ‘되는게 없는’ 언어로 설계되었다면 C만큼 빠를수 있겠죠.
전 머신러닝이나 파이썬을 모르므로 자세한 답변을 해드리기 어렵습니다만, 머신러닝에서 파이썬 많이 쓰는데 하부 라이브러리는 대부분 C로 짜여져있는걸로 알고 있습니다. 그리고 파이썬에서도 GPU많이 쓸텐데 그거 CUDA로 작성되어있고 CUDA는 C와 포트란으로 작성합니다. 그걸로 만든 라이브러리를 호출하는거죠.
유니티는 게임에 촛점이 맞춰져있지만 정확히는 ‘누구나’, ‘쉽게’ 게임을 만들게 한다는게 모토입니다.
여전히 pc/콘솔 업계에선 C/C++을 사용합니다.
역사적으로 모바일 게임업계와 PC/콘솔 업계는 시작부터가 꽤 다릅니다. 목표하는 바도 다르고요.
게임이라고 다 똑같은 게임이 아니고, 개발 방법도 상당한 차이가 있습니다.
C#, JS를 택한 이유는 개발에 필요한 기술수준의 허들을 낮추기 위함이지 성능이 잘 나와서 채택한게 아닙니다.
좋아요Liked by 1명
역시… 고수들의 답변은 명쾌하고 잘이해가되서 좋내요..
그리고 개인적으로 궁금한건대 보통 한국은 네이버 티스토리 미국은 미디어라는 블로그를 호스팅서비스를 많이 쓰는데 왜 워드프레스를 쓰시나요?? 워드프레스가 검색포털에 많이 노출이 안되는걸루 알고있습니다
영천님의 인지도에 비해 팔로우가 몇 없어서 놀랏습니다. 저라도 팔로우를 해야겠내요.
좋아요좋아요
2000년부터 개인 홈페이지가 있었고 이건 지금도 살려는두고 있습니다. 제방 홈서버에 vm에서 돌아갑니다. 자료 보존용이죠. ( http://yuchi.net )
그리고 네이버 블로그에 한동안 포스팅을 했는데 ( http://blog.naver.com/shovelmaster ) 네이버에서밖에 검색이 안되더군요. 네이버는 비개발자들이 연예인 가십거리나 보러 들어가는 포탈(검색서비스도 아닌)인지라 뛰쳐나왔습니다. 이후로 한국 서비스는 쓰지 않을 생각이었고요 그래서 워드프레스에 블로그를 옮겼습니다.
블로그도 노출을 위해서 하는게 아니고 기록을 보존하기 위해서 사용하고 있습니다. SNS에는 글을 길게 쓸 수 없기도 하고요. 보통은 블로그에 포스팅을 하고 sns에 링크를 걸어둡니다.
좋아요좋아요
안녕하세요, 궁금한게 있어 몇 가지 질문드립니다.
페북은 친추가안되면 댓글을 못남기내요 ㅜㅜ
페이스북에 debug build 팁에 관해 글을 남겨놓으셨는데,
2. 메모리의 총 사이즈가 아닌 heap block할당 개수를 확인하고 heap block개수를 줄인다. 즉 malloc(), new의 호출 회수를 줄여야한다.
3. 초기화 제외하고 런타입에 new, delete, new, malloc하는거 있는지 확인하고 최대한 줄인다. 특히 메인 루프에서 호출되는거 있으면 반드시 제거할것.
new와 malloc같은 메모리 할당 함수는 소스 상으로는 O(1)이지만 실제 내부 코드를 들여다보면 연산자체 비용이 많이 들어 빈번한 호출은 비효율적이라고 배웠습니다.
하지만 “메모리의 총 사이즈가 아닌 heap block할당 개수를 확인하고 heap block개수를 줄인다” 이 부분이 왜 효율적이라는건지 잘 이해가안됩니다 ㅜㅜ. 그리고 3번에서 왜 메인로푸에서는 new와 같은 연산을 제거해야하는건가요? 런타임이 아니라 초기화에서 풀을 만들어놓고 할당하라는 말씀인가요?
혹시 조금만 상세한 설명 가능할가요?? 초보를 위한 배려부탁드립니다.!!
좋아요좋아요
페북친추 하시고 메시지로 본인 신상을 밝혀주시면 어지간하면 다 추가해드립니다.
heap메모리는 큰 덩어리에서 요청한만큼의 사이즈를 떼어내서 반환해줍니다. 그런데 메모리를 해제할때는 병합을 해야하죠. 따라서 메모리 앞뒤로 head와 tail영역을 둡니다. 따라서 100MB를 할당하는것보다 1MB를 100개 할당하는 쪽이 메모리를 훨씬 더 소비합니다.
그런데 중요한건 메모리 소비보다 할당할때와 해제할때의 오버헤드입니다.
heap에서 메모리 블럭을 떼내면 남은 덩어리와 사이즈의 어드레스를 트리 또는 링크드 리스트 형태로 어딘가 자료구조에 저장해둬야 합니다. 그래야 메모리 할당 요청이 들어올때 가장 근접한 사이즈를 찾아서 할당할 수 있습니다. 때문에 할당하는건 작업은 느립니다. 그런데 해제는 더 느립니다. 해제를 하게 되면 반환된 메모리의 앞뒤 블럭을 찾아서 병합 가능한지 체크합니다. 병합 가능하지 않을 경우 반환된 메모리를 할당할때처럼 사이즈가 맞는 어딘가의 자료구조에 넣어둡니다. 병합 가능할 경우 병합한 앞뒤블럭을 자료구조에서 빼내고 현재 반환된 메모리와 합쳐서 다시 근접한 사이즈의 어딘가 자료구조에 넣어둡니다.
즉 할당할때의 오버헤드 + 병합 비용이 더 들어갑니다. 일반적으로 해제가 할당보다 2배쯤 느립니다.
debug빌드에선 할당이나 병합할때 디버깅을 위한 heap체크가 더 들어갑니다. 그래서 release때보다 훨씬 더 려집니다. 초기 로딩시 잡아먹는 시간의 상당량을 heap메모리 할당/해제에서 잡아먹습니다.
가변사이즈 할당이 필요없다면 포인터 테이블이나 링크드 리스트만, 혹은 옵셋 계산만으로도 메모리를 할당/해제할 수 있습니다. 이게 보토 말하는 커스텀 memory pool이고요. 당연히 new/malloc()보다 훨씬 빠릅니다.
메인루프에서 동적할당하지 말란 얘기는 게임에서 메인 루프는 60fps이상을 보장해야하기 때문입니다.
언급했듯이 new/delete, malloc()/free()는 느립니다. 엄청나게 느립니다. 전통적인 게임 프로그래밍에서 메인 루프에서는 절.대.로 동적할당을 하지 않습니다.
좋아요좋아요
추억 돋는 좋은 글이네요, 저도 98년 99년도가 그립네요. 제 기억에 MMX기술을 사용한 인텔 CPU를 TV광고로도 했었는데 그때는 MMX가 참 대단한 신기술로 느껴 졌었는데, 멀티미디어 세상이 온다고 했었죠. 대학의 전산과도 멀티미디어 학과 멀티미디어 공학 이런걸로 이름이 바뀌고 컴퓨터도 멀티미디어컴퓨터라고 하면 더 많이 팔리고 하던 시절이였는데, 멀티미디어라는 말을 요즘은 잘 안쓰는 거 같은데.. MMX라 추억 돋네요
좋아요좋아요
네. 멀티미디어가 너무 당연해져서 멀티미디어란 말을 안쓰게 된것 같네요. PC로 동영상을 보는게 신기하던 시절만 해도 멀티미디어란 말을 무진장 많이 했죠. 저 학부생때 깍두기로 들어가있던 대학원방도 멀티미디어연구실이었는데 주 연구분야는 mpeg이었습니다. pc에서 동영상 보는것 따위는 이제 아무것도 아니니 멀티미디어란 말을 쓸 필요도 없죠. 컴퓨터로 뭐든 다 하니까요.
좋아요좋아요