게임 개발을 효율적으로 진행하기 위해서 개발 기반 시스템은 어떤 것이 있어야 하는지 창업 15년째를 맞이한 주식회사 사이바컨넥트2의 케이스에 대해서 동사의 기술개발 치프 우사미 코우스케씨, 시세무우씨, 카타기리예 유타카씨가 말하였다.

세션 회장은 개시 전부터 초만원. 동사의 마츠야마 히로시 사장이 스스로 관계자석에서 청강생을 안내하는 만큼 그 주목도의 높이가 엿보여졌다. 또한 본 세션은 동사 내에서 이용되고 있는 직종명을 이용해 진행되었다. 동사에서는 북미에서 사용하는 호칭을 사용하는데 예를 들어 다른 메이커에서는 플래너, 기획으로 불리는 직종이 「게임 디자이너」로, 디자이너로 불리는 직종이 「아티스트」가 된다.

 

 

■ 15년간의 도정

동사의 개발 기반 시스템에는 3개의 세대가 있다고 하며 각각 PS 시대, PS2 시대, PS3 시대라고 도 말할 수도 있다.

1세대는 기반이 되는 시스템이 없었던 시대. SCE로부터 제공되는 것을 이용하고 있었다. 당시는 프로그래머가 효과, 파티클의 표현, 컷 씬의 연출까지 담당하여 부담이 매우 컸다고 한다. 데이터 관리도 수작업으로 인간의 실수가 많았다고 카타기리씨는 되돌아 본다.

2세대에서는 개발 기반 시스템 CCS를 개발. 이것에 의해 효과나 컷 씬의 연출은 아티스트의 작업이 되었다. 또 보조 툴로 데이터 관리 등을 실시하는 것으로 개발의 효율화가 진행되었다고 한다.

CCS는 후에 이식. 다양한 버전이 파생. 타이틀 마다 독자 커스텀마이즈를 실시하고 있어 디른 타이틀에서 만든 기능을 도입해 간다. 이렇게 해서 타이틀에 특화한 튜닝을 실시할 수 있게 되었지만 후에 머지(통합) 작업이 다른 작업을 압박. 문제가 누적해도 수정 하기 어려운 상황이 되어 있었다고 한다.

 

 

그리고 제 3세대에. 여기서 비대화 한 기반 시스템을 일단 버리고 새롭게 NUCC 라이브러리를 개발. 이것은 주식회사 반다이남코게임스가 개발한 NU 라이브러리를 베이스로 CCS의 기능을 추가한 것.

 

이 제 3세대에 개발 기반 시스템은 큰 변모를 이루었지만 개발 툴이나 워크플로우는 전생대로부터 거의 변함없다고 한다. 또 이 때의 이행에서는 코스트가 적었지만 아직도 재검토가 되어 있지 않다고 하는 현상도 있다.

 

이렇게 해서 동사의 개발 기반 시스템은 효율화가 전혀 되어 있지 않았던 제 1세대부터, 2세대에서 효율화. 그 사상을 계승해 제 3세대에 들어간 것.

 

 

2세대에 효율화에 성공한 배경에는 다음과 같은 기능이 있었다고 카타기리씨는 말한다.

「스트리밍 씬 재생」 「3ds Max」 위에 표시된 씬을 실기상에서도 재생할 수 있기 때문에 개발 초기 단계에서의 프리젠테이션 등에 이용할 수 있어 게임 본체의 개발이 진행되지 않아도 선행하여 무비를 작성할 수 있었다고 한다.

 

「씬 베이스의 애니메이션 표시」 이것은 종래 모델에 애니메이션을 할당하여 효과를 거듭한다고 하는 작업을 실시하고 있던 것을 모두 조합한 상태로 표시하는 기능. 캐릭터+효과의 씬에서도 프로그래머의 작업이 발생하지 않고, 부담이 경감되었다. 또 아티스트도 모델과 효과를 조합한 채로 개발할 수 있게 되었다고 한다.

 

「레이어 기능」 어디를 우선하여 렌더링 할지를 관리하기 위해 레이어를 준비. 이것을 아티스트가 관리하여 어느 오브젝트를 어느 레이어에 둘까 결정. 3세대의 개발 기반 시스템에서는 복수의 패스를 사용하는 쉐이더 관리에도 이용되고 있다고 한다. 필요에 따라서 레이어에 기능을 추가할 수 있기 때문에 예를 들어 메뉴 화면을 추가하고 싶을 때에는 그 레이어를 지정하면 끝난다라는 것.

그 외 미스를 줄이기 위해 하나의 원시 파일에 대해 출력하는 파일은 하나로 한다. 데이터 내에 데이터 소스의 파일 패스를 넣는다. 메모리의 확보 사이즈를 알 수 있도록 포맷을 만든다 라고 하는 데이터 관리상의 궁리가 이루어지고 있다고 한다.

 

 

넘어야 할 문제

그러나 제 3세대의 개발 기반은 제 2세대를 기초로 한 것이기 때문에 내재 하고 있던 결점까지 계승하는 결과가 되었다고 한다.

 

3세대에 현저하게 된 것은 데이터 포맷의 문제. 2세대에 고정의 포맷을 사용하고 있었기 때문에 유연성이 없고, 새로운 데이터를 추가할 때에 시간이 든다고 한다. 또 프로젝트 마다 확장 데이터가 필요하게 되지만 결국은 각 담당자가 독자 포맷을 만드는 편이 빨라서 쓸데 없는 작업이 많아졌다고 한다.

거기에 부수 하여 쉐이더 대응의 문제가 있다. 쉐이더 프로그래밍 내용에 의해서 입력되는 데이터가 바뀌자만 본래라면 범용성이 있는 데이터 포맷이 있어야 한다고 한다. 그러나 동사에서는 시간적인 제약으로부터 구현이 계속 미루어져 「이후 보디 블로우와 같은 효과가 있어 왔다」라고 한다.

 

개발 툴에 대해서도 담당자 마다 완성도의 불균일이 있고, 프로젝트가 우선되어 점검이 소홀히 되는 문제가 있다고 한다. 결과 담당자가 바뀌면 같은 툴의 다시 만드는 문제가 발생하고 있다라는 것.

 

예를 들어 동사에서는 디버그를 위한 자원 에디터를 게임 어플리케이션 측에서 만들고 있다. 이것은 유효하게 기능했지만 패드 조작이 하기 어려운 다른 콘솔로의 이행이 어렵다고 하는 약점이 있다고 한다.

이러한 문제의 대부분이 툴 관련의 것만으로 프로젝트가 대규모로 됨에 따라 툴의 필요성과 확장성이 요구되어 온다라는 것.

 

이러한 문제의 원인은 프로젝트로의 의존이 강해진 것과 게임이 복잡화 하고 있는 것에 있다. 프로젝트 의존이란 개발 기반 시스템의 완성도가 프로젝트의 동향으로 영향을 받는 것으로 구현 우선을 위해서 메뉴얼이 정비되지 않는다고 하는 문제 등이 일어난다 .또 게임이 복잡화 비대화 하는 것으로써 내제 툴의 수 자체가 증가하여 그 점검에 쫓기게 된다는 것.

 

이러한 악순환을 끊기 위해서는--.

 

 

작은 한 걸음으로부터

여기에서는 문제에 대해 어떻게 대처해 나갈까에 대해서 이야기가 진행.

 

하나는 프로젝트 의존으로부터의 탈각. 회사의 체제를 재검토하여 프로젝트로부터 독립한 부문의 설립이 필요하다고 우사미씨는 생각. 게임의 복잡화에 대해서는 시장의 요구에 응한 것인 이상 「~에서는 게임 내용을 간단하게」라고 할 수는 없다 거기에 부수 하는 문제에 대처해 나가려는 이야기가 되었다고 한다.

 

동사에서는 2년 전에 개발 지원실을 설립. 프로젝트로부터의 독립한 형태로 게임 개발을 위한 기반 정리를 실시하고 있다. 설립 당초는 일손부족으로부터 프로젝트의 헬프에 들어가는 것이 많이 있었지만 명확한 목표를 세워 사내에 어필. 상사를 설득하는 것으로 부서의 존재 의의를 호소했다고 한다.

개발 지원실의 최종적인 목표는 내제 게임 엔진을 만드는 것에 있다고 한다. 그 때문에 우선 작은 구현으로부터 도입하여 그것이 잘 되면 프레임워크 개발로 그리고 엔진 개발에 착수한다고 하는 단계적인 목표를 설정했다고 한다.

직면한 내제 툴(인하우스 툴)의 개발 환경을 정비할 필요가 있다. 툴 작성의 순서를 공통화하거나 인터페이스를 공통화하거나 하는 것으로 툴의 증대에 대처하고 싶다는 것. , Excel」과의 상호 기능을 충실히 하여 일단 출력한 데이터를 다시 쓸 수 있도록 하고 싶다고 한다.

 

공통 데이터 포맷에 대해서는 제 3세대에 구현한 GUI Toolkit을 콘솔 측이 아니고 Windows 측에 가져온 것. 비주얼 프로그래밍에 대해서는 향후 아티스트가 툴을 사용할 기회가 증가하는 것이 예상되기 때문에 제어 플로우를 시각화. 게다가 이러한 라이브러리를 활용 받기 위해 게임 본체로부터 떼어내 게임 데이터 에디터를 준비하여 범용성을 높이고 싶다고 한다.

 

동사의 게임 데이터 에디터는 다음과 같은 구성이 될 예정.

 

우선 「게임 구조 에디터」 이것은 클래스 설계를 하는 툴로 데이터의 구조를 규정. 그리고 「데이터 에디터」로 데이터의 편집을 실시하여 「데이터 최적화」를 포함시키는 것으로 디버그 시의 정보를 삭제.

데이터 편집 구조에 대해서는 게임으로부터 독립시키면 리얼타임으로 편집이 하기 어려워진다고 게임에 넣으면 게임이 무거워진다고 하는 문제가 있다.

 

거기서 게임 데이터 에디터는 게임으로부터 독립하고 게다가 동기가 잡히는 통신 동기형을 뽑고 싶다고 한다. 거기에 따라 콘솔 의존을 경감시켜 타겟이 바뀌어도 개발을 계속되도록 하고 싶다는 것.

 

그 앞의 전망으로서 「렌더링 파이프라인 에디터를 만들고 싶다」라고 우사미씨. 다른 하드에 이식할 때 렌더링 파이프라인을 커스텀마이즈 할 수 있는 편이 편리하다고 한다. 이것에는 방금 전 기술된 레이어 기능을 응용한다라는 것.

 

또 그는 게임 플로우 에디터의 준비도 생각하고 있다.
동사에서는 게임 디자이너가 적다고 하는 사정이 있어서 게임의 전체상이 보여 오는 것이 늦고, 「구현해 보면 사양이 부족하다」라고 하는 일이 있다고 한다. 이것을 해결하기 위해서 미리 게임 플로우를 시각화한다는 것.

그것에 의해 「지금까지 이미지로부터 들어가는 아티스트 드리븐이었던 게임 개발을 게임을 디자인하는 측으로부터 제작하는 디자이너 드리븐으로 이행을 하고 싶다」라고 한다.

「중소 개발사에서는 미들웨어를 사용하는 것이 좋다고 생각될지도 모른다」라고 우사미씨. 「그것도 선택사항의 하나이지만 프로젝트나 장르에 의해서 맞지 않는 것도 있다. 어쨌든 회사 독자적인 것이 필요하게 된다」라고 한다.

우선은 회사의 프레임워크를 재검토 하여 문제점을 밝혀낸다. 작은 일로부터 시작해 가면 중소 개발사라도 개발의 효율화는 할 수 있을 것이라고 같은 고민을 하는 동업자들을 격려했다.

 

 

출처 : http://www.gamebusiness.jp/article.php?id=2143

 

저작자 표시
신고
by 흥배 2010.10.18 09:00

시간 계산 어떻게 하시나요?

여러 가지 방법이 있겠지만 SYSTEMTIME을 사용하여 계산하는 경우라면 COleDateTimeCOleDateTimeSpan을 사용하여 계산하면 쉽게 할 수 있습니다.

COleDateTimeCOleDateTimeSpan ATL에 있는 라이브러리입니다.

 

 

COleDateTimeCOleDateTimeSpan을 사용하기 위한 조건

필요한 파일 : ATLComTime.h

 

 

예제

아래 예제는 지정된 시간에서 을 더한 시간을 계산합니다.

void UpdateTime( SYSTEMTIME& stPatchTime, INT32 wMinute )

{

COleDateTime PatchTime( stPatchTime.wYear, stPatchTime.wMonth, stPatchTime.wDay, stPatchTime.wHour, stPatchTime.wMinute, stPatchTime.wSecond );

 

COleDateTimeSpan SpendTime;

SpendTime.SetDateTimeSpan( 0, 0, wMinute, 0 );

PatchTime += SpendTime;

          

stPatchTime.wYear = PatchTime.GetYear();

stPatchTime.wMonth = PatchTime.GetMonth();

stPatchTime.wDay = PatchTime.GetDay();

stPatchTime.wHour = PatchTime.GetHour();

stPatchTime.wMinute = PatchTime.GetMinute();

}


 

COleDateTime은 생성자에서 SYSTEMTIME을 인자로 사용할 수 있습니다. 그러나 인자로 사용할 SYSTEMTIME의 값이 올바른 값인 경우만 사용할 수 있습니다. 예를 들어 아래와 같은 것을 인자로 넘기면 디버그 모드에서는 경고가 발생합니다.

SYSTEMTIME stTime;

stTime.wYear = 2010;

stTime.wMonth = 10;

stTime.wDay = 11;

 

COleDateTime CurTime( stTime );

// 이후 이것을 계산에 사용할 때 에러발생

 

 

저작자 표시
신고
by 흥배 2010.10.15 09:00

새로운 게임을 만들려면 「게임×??」의 「??」의 부분이 중요하다고 한다.

 

주식회사 게임리퍼블릭의 야나세 요헤씨는 「무엇을 배웠는지」 보다 「배운 것을 어떻게 살릴까?」라고 제목을 단 강연을 실시. 게임 업계를 목표로 하는 학생에게 향한 「게임의 일 fair」의 일환이며 프로의 발상법의 일단을 엿볼 수 있는 흥미로운 내용이 되었다.

 

그는 게임이라는 것은 「인터랙티브로 재미있는 것」이라고 정의.

게임의 프로세스라는 것은 「정보를 얻는다」「문제를 인식한다」「문제 해결에 관해서 정보 수집」「가설을 세운다」「가설이 올바른가 나타내 보인다」「보수를 얻는다」라고 하는 것이며 이것은 일상생활과 같다라고 말한다.

 

의문을 풀기 위해서 정보를 얻거나 조사를 하거나 가설을 세우거나···라고 하는 일상생활의 프로세스 그 자체가 게임과 같은 것이며 「게임을 만들게 되어 조사하는 것으로의 즐거움이 태어났다」라고 말한다.

 

그는 현대의 게임 크리에이터의 일을 「컴퓨터 안에 장소를 만들어 체험을 가르치는 것」이라고 합니다. 게임과 무엇인가를 곱하는 것으로 새로운 게임이 태어나기 때문에 게임×문학, 게임×생물학···등 「게임×??」의 「??」의 부분이 중요하게 되어 간다고 한다. 그 위에 타인과 다른 지향은 최고의 물건을 만드는데 무기가 되지만 게임×게임에서는 기존 게임의 구멍을 막을 수 없다 라고 지적.

그는 「과거의 명작을 낳은 크리에이터들은 그 작품 그 자체를 만들고 싶었던 것은 아니다」라고 비전의 중요함을 말한다.

 

예를 들어 「포켓몬스터」라도 크리에이터의 머릿속에는 궁극의 「포켓몬스터」가 있었을 것으로 그것을 현행 하드의 한계에 맞추어 내린 것이 상품으로서 출세한 것. 이 상품의 부분만을 보고 있던 것은 크리에이터를 따라 잡을 수 없다···라고 하는 것이 그의 생각.

 

새로운 하드가 나오고 나서 무엇을 할지 생각하는 것이 아니고, 그 전부터 실현하고 싶은 비전을 가지고 그것을 현실에 맞추어 내려 가면 쭉 앞까지 게임을 만들 수 있다」라고 평소부터 비전을 가지는 것의 중요함을 말한다.

그러기 위해서는 게임 이외도 배우는 것, 의문을 계속 가지는 것이 소중하고 「그 때에 이해할 수 없어도이것은 안 된다라고 생각하지 말고 쭉 머릿속에 놓아 두면 언젠가 도움이 될지도 모른다」라고 어드바이스를 주었다.

 

출처 : http://www.gamebusiness.jp/article.php?id=2055

저작자 표시
신고
by 흥배 2010.10.14 09:00

Visual C++에서 프로젝트에 외부 라이브러리를 추가할 때 해당 라이브러리의 헤더 파일이 있는 디렉토리를 프로젝트 설정에서 추가 포함 디렉토리에 추가만한 후 빌드를 하면 보통 미리 컴파일된 헤더‘LNK2019’ 문제가 발생합니다.

 

미리 컴파일된 헤더

가장 쉽게는 솔루션에서 추가한 라이브러리의 cpp 소스 파일 속성에서 미리 컴파일된 헤더 사용 안함으로 선택합니다.

 

LNK2019 빌드 에러

프로젝트에 추가된 라이브러리의 소스 파일이 추가되어 있지 않았기 때문입니다. 솔루션에서 해당 파일들을 추가하면 됩니다.

저작자 표시
신고
by 흥배 2010.10.12 16:57

「최근 「기획이 통하지 않는다」 「어떤 게임을 만들어야 좋은지 모르겠다」라고 하는 걱정하는 목소리가 들린다. Soratorobo~그리고 CODA」는 쭉 만들고 싶다고 바라면서, 구상 10년 개발에 3년을 걸친 타이틀이다. DS에서 3년이라고 하는 기간은 이례적이다. 그렇지만 만들고 싶은 것은 궁리하면 만들 수 있다. 그 모든 것을 밝히겠습니다.」 마츠야마씨는 모두 이와 같이 말한다. 트레일러가 상영. 장대한 세계관, 일러스트 점수, 만들기, 어떤 것이라도 대작으로서 적당한 것.

 

그러나 그러한 게임 만들기가 되어있는 것은 아무것도 특별한 일은 아니라고 마츠야마씨는 말한다. 「반다이남코게임즈와 굉장히 사이가 좋아도 「NARUTO」나 「.hack」가 득을 보고 있기 때문에,  시간이 걸려 결과적으로 대작이 된 것도 아닙니다」

일의 시작은 1996년의 사이버컨넥트 설립으로 거슬러 올라간다. 첫작은 반다이로부터 플레이 스테이션으로 발매된 「테일콘체르트」이다. 마츠야마씨는 그래픽 디자이너로서 참가한 첫 작품은 그때의 조류를 반영한 풀 폴리곤의 모형정원 액션 게임. 반다이 사내에서도 큰 평가를 받았지만 판매 갯수적으로는 손익분기점을 넘는 정도 밖에 되지 않아 「기대 이하」라고 하는 평가를 받았다.

 

그 후도 반다이와의 양호한 관계는 계속 되어 「.hack」이나 「NARUTO」를 개발하지만 사내에서는 「테일콘체르트」의 속편을 만들고 싶다고 하는 소리가 있었다고 한다. 사내에서 개최되고 있는 게임 아이디어 콘테스트에서는 2003년과 2004년에 속편의 기획이 1위가 되었다. 그 기획을 1999년에 가져 갔지만 「눈앞에서 기획서를 쓰레기통으로 버려진다」라는 취급을 받았다고 한다(덧붙여서 그 반다이의 프로듀서는 우치야마 다이스케씨).

단념을 못한 마츠야마씨, 이소베 타카유키씨, 하촌구츠카사씨의 3명은 「테일콘체르트」가 실패한 이유의 원인 분석으로부터 시작 하여 다른 게임을 개발하는 업무와 병행하여 신작의 시나리오나2000매 이상에 달하는 세계관 자료를 제작 하였다고 한다. 속편에서는 기획이 통과할 전망은 없기 때문에 「Soratorobo~그리고 CODA」라고 하는 신작으로 다시 태어난다.

 

만들어진 방대한 자료를 가지고 남코와 합병한 반다이남코게임즈에 가져간다. 여기서 사이버컨넥트류의 프리젠테이션으로서 통상의 기획서 뿐만이 아니라 설정 자료집도 제대로 제본하여 제출 했다고 한다. 제본된 것은 매우 훌륭한 것. 프로듀서는 바쁩니다. 프로모션이나 영업과의 협의도 있고, 제안도 많이 받고 있습니다. 그 중에 눈에 띄려면 전략이 필요합니다. 단순한 기획서는 파일로 끝나져 버릴지도 모릅니다만 훌륭한 자료집을 건네주는 것으로 잊지 않고 책상에 놓여질 수 있습니다. 그러면 볼 기회도 증가하고 동료에게도 "이런"이라고 생각해 줄 수 있습니다

 

기획서를 복수의 회사에 타진하는 한편, 계약이 정해지기 전부터 주간 패미통에 신작 게임의 구인 광고를 게재. 이것도 진심을 보이기 위한 작전의 하나였다고 한다.

 

이러한 노력의 결과 「Soratorobo~그리고 CODA」에서는 당초는 반다이남코 이외의 회사가 흥미를 보이고 있었다고 하지만 부사장에게 「우리가 했으면 좋겠다」라고 하는 전화가 있어 계약이 결정되었다고 한다.

 

이렇게 하여 계약은 결정하지만 다음은 3년에 걸치는 개발 기간으로 계속 된다. 이 개발 기간은 당초부터 상정되고 있던 것이라고 한다.

 

3년이 필요한 이유로서 큰 것은 저명한 크리에이터를 기용했다고 하는 것이라고 한다. 캐릭터 디자인의 유우키신 아키라씨, 메카닉 일러스트는 타니구치흔 타카시씨, OP애니메이션은 매드 하우스가 담당. 모두 인기인으로 납품까지는 시간이 걸리는 것이 기본. 거기서 3년간이라고 하는 기간이 만들어진다.

 

긴 기간이라고는 해도 체제는 소인원수로 단계에 따라 증감시키면서 개발. 3명으로 시작하여 최대에서도 16명 체제. 현재 디버그에 들어가 있지만 불과 3명이라고 한다.

 

마지막으로 긴 개발 기간을 보람 있게 쓰고, 도중 도중에 모니터 회를 실시. 아이들에게 개발중의ROM을 플레이 받고, 컨셉이나 방향성의 확인, 문제점의 발견, 밸런스 조정에 활용하고 있다고 한다. 지금까지 8회 실시.

 

그렇게 해서 완성한 「Soratorobo~그리고 CODA」는 대작으로서 더할 나위 없는 충실의 내용이 되고 있다. 마츠야마 사장은 마지막 말로 「하고 싶은 것이 있고, 만들고 싶은 것이 있다면 각오와 작전이 필요」하다고 말한다. 사이버컨넥트는 아무것도 숨길 생각은 없고, 오히려 라이벌을 기르려고 생각한다」라고 회장을 향해 성원을 보냈다.

 

 

출처 : http://www.gamebusiness.jp/article.php?id=2120

 

저작자 표시
신고
by 흥배 2010.10.12 09:00

CEDEC 첫날에 개최된 쇼트 세션 「북미 기업, 유럽 기업과의 공동 개발」에서는 스퀘어에닉스의 마스나가 테츠야씨가 「파이널 환타지 XI」의 독일어와 프랑스어 판의 제작 프로젝트의 체험을 기초로 공동 개발의 벽이 되는 요소에 대해 구체적으로 말했다.

 

그는 우선 커뮤니케이션의 문제를 낳은 요소로서 「거리」, 「시차」, 「휴일」, 「언어」 4개를 들어 각각 대해 실례를 섞어 설명.

 

 

「거리」의 불편한 점으로는 실기를 공유할 수 없는 것이나, 인식의 공유 수단이 복잡하게 되는 것(메일, BBS, 전화, 텔레폰 컨퍼런스)가 있다고 설명한 다음, 결과적으로 「공통 인식의 질과 양이 저하」한다고 말했다.

 

「시차」가 가져오는 영향에 대해서는 서두에는 「시차가 크면 동시 근무 시간이 줄어 든다」라 들며 다음 동시 근무 시간 밖에 진행할 수 밖에 없는 업무로 딜레이가 생기는 것을 지적. 예를 들면 텔레폰 컨퍼런스나 인테그레이션 테스트라고 하는 업무는 양자가 모이지 않으면 진행하지 못하고, 「시차가 없으면 1일에 끝나는 일도 날짜를 걸치지 않으면 끝내 수 없기 때문에 결과적으로 4,5일 걸린다」 라는 것이 있다고 한다.

 

 

다음으로 거론된 것이 「휴일」. 일본은 경축일이 매우 많은 대신에 유급이 사용되지 않지만 해외는 반대로 경축일이 적고 유급을 취하는 스탭이 많은 것을 소개. 또 연휴 시즌에 대해서도 일본에서는 매우 큰 의미를 가지는 정월도 해외에서는 그렇지도 않은 점이나 일본에서는 익숙하지 않지만 캐나다와 미국에서는 메이저한 축일인 감사제(Thanks Giving) 등을 예시한 다음 「이러한 휴일의 엇갈림이 한층 더 동시 근무 시간을 압박한다」라고 말했다.

 

또 「언어」에 대해서는 영어를 사용했다고 소개. 영어를 할 수 없는 일본인 스탭에게는 중개하는 스탭이 필요하게 된다고 말한 다음, 중개역의 「통역자」와 「바이링걸 스탭」에게는 각각 장점과 단점이 있다고 지적. 그씨가 담당한 프로젝트의 경우 「통역자」는 대체로 「(게임 고유/특유의 정보 등) 전문성은 낮지만 정보로 일그러짐이 생기지 않았던 인상」으로 「바이링걸 스탭」은 「전문성은 높지만 정보가 비뚤어지기 쉬운 것처럼 생각된다」라고 소개.

 

언어가 특히 문제가 되는 것은 미팅 시간으로 통역을 개입시켜 실시하는 회의에서는 「일본어로의 회의와 비교해서 같은 시간을 들여도 1/2~1/3의 정보 밖에 전해지지 않는다」라고 느꼈다고 한다.또 이러한 자리에서는 높은 전문성을 가지는 바이링걸 스탭을 동반하고 있을 때 쪽이 전문성이 낮은 통역자보다 이야기가 빠르다(일본어 회의:바이링걸:통역자/1:2배이상:3배 이상)라고 말한다.

 

 

문제의 구체적인 예에 대해서는 커뮤니케이션 면에서는 「매니지먼트 담당자가 이쪽과 저쪽의 양쪽 모두에 놓여지기 때문에 의지의 통일이 곤란하게 된다」, 「공통 인식을 잡지 못하고 타이틀의 방향성이 어긋나 간다」, 「해외 스탭 한사람 한사람의 개성이 보이기 어려워진다(전원이 하나의 인격과 같이 생각되어 온다)」라고 하는 문제가 있고 코스트나 생산성 면에서는 「(매니지먼트 담당자나 통역자가 증가하는 것에 의한) 인원 코스트의 증가」, 「본래의 업무는 아니고 커뮤니케이션(거리 시차 언어)으로의 대응에 시간이 걸려진다」라고 하는 문제가 있다고 한다.

 

 

그는 다음으로 상기와 같은 여러 가지 문제가 있는 것을 인식한 다음 「바람직한 공동 개발」이란 무엇인가를 묻고, 어떠한 업무가 해외와 공동으로 행하기 쉬운가를 설명.

동일 거점이 바람직한 업무에는 「프로그램 요소와 사양 결정」등의 공통 인식의 구축이 중요한 업무를, 다른 곳에서의 개발이 가능한 업무로서는 「무비」나 「UI 이외의 그래픽 데이터」를 예시했다.

 

계속 되어 「다른 곳에서 개발 가능」한 일을 어떻게 판별 할까의 기준으로서 「아웃 소스 하기 쉬운 업무는 해외에 내기 쉽다」라고 표현. 애니메이션을 예로 들어 「색을 바르는 것만 아웃 소스 하는 사례가 있습니다. 저것도 독립화 시키기 쉬운 작업이지 않을까요?」라고 말한다. 스퀘어에닉스사의 경우에는 「해외판 QA」나 「게임 마스터」라는 업무가 이것에 해당된다고 한다.

 

 

「바람직한 공동 개발」 세션의 마지막에는 북미 유럽보다 동남아시아나 오스트레일리아 쪽이 좋은 것은 아닌지?라고도 그는 말한다. 이 그 밖에 든 요소도 「거점 마다 통역과 바이링걸 바이링걸 스탭을」, 「매니지먼트 스탭은 정기적으로 출장을」, 「동일 거점에서의 개발」, 「해외제 엔진보다 국내제 엔진이 커뮤니케이션이 취하기 쉽다」 등 지금까지 들어 온 문제 요소를 해결, 회피하기 위한 내용이 계속 되었다.

 

그씨는 「개발자 매니지먼트를 할 수 있을 것」이라고 제목을 붙인 마지막 슬라이드에서 「유럽 북미와의 공동 개발의 필요성을 재검토」하는 것과 「영어 공부」 2개를 들면서 세션을 끝냈다. 세션을 통해서 나타난 것이기도 하지만, 이것은 「해외 기업과 함께 개발을 하는 것을 목적으로 공동 개발한다」것은 아니고, 「공동 개발하는 이유」를 명확하게 하고 나서 시작하자 라고도 바꾸어 말할 수 있을 것이다.

 

출처 : http://www.gamebusiness.jp/article.php?id=2049

저작자 표시
신고
by 흥배 2010.10.11 09:00

VC++ 10 C++0x나 병렬 프로그래밍 라이브러리 이외에도 툴적인 측면에서도 여러 좋은 기능들이 추가 되었습니다. 알고 있으면 작업할 때 편리한데 시간이 부족하여 제가 아직 자세하게 찾아보지 못해서 소개하지 못한 것이 많이 아쉽습니다. 그래서 짥은 것이라도 틈틈이 시간나면 소개하려고 합니다.

 

VC++ 10에서는 디버깅 모드에서도 역어셈블리 코드를 볼 수 있습니다.

 

메뉴에서 “Debug” -> “Windows” -> “Disassembly”를 선택합니다.

 

아래와 같이 역어셈블리 코드 창이 나타납니다.

 

 

그러나 위 화면을 보면 코드 바이트는 표시되지 않고 있습니다.

코드 바이트를 보고 싶다면 위 화면 왼쪽 상단의 “Viewing Option”을 클릭합니다.

 

 

위와 같이 옵션을 선택할 수 있습니다. 이 중 “Show code bytes”를 선택합니다.

그러면 아래와 같이 코드 바이트가 표시됩니다.

 

 

참고

http://d.hatena.ne.jp/kkamegawa/20100130/p1

 

저작자 표시
신고
by 흥배 2010.10.11 09:00

CEDEC의 「게임의 일 업계 연구 페어」의 강연으로서 스퀘어·에닉스에서 사운드 그룹 기술 최고 책임자를 맡는 츠치다선기씨가 "게임 프로그래머라고 하는 삶의 방법"이라고 제목을 붙인 강연을 실시했다.

 

 

내용은 게임 프로그래머로서 살아 온 반생의 모습을 되돌아보고 「어째서 여기에 내가 선택되었는지 모를 문제아입니다」라고 시원하게 말하는 토크 연발의 「이것은 개인적인 견해입니다」라고 하는 강연이 되었다.

 

그런 츠치다씨와 프로그램의 만남은 고교시절. 입학 축하에서 받은 PC에 들어가 있던 「N88BASIC」로 오로지 프로그램에 몰두. 정말 좋아했던 게임을 만들고 있었다고 한다. 이것저것 하고 있으면 명문 사립 중학에 다녀 70이던 편차치는, 고등학교를 졸업하는 무렵에는 40이라고 하는 훌륭한 낙오로. 물론 대학에도 가지 못하고, 부모에게 예비학교에 넣어지지만 3일간으로 그만두고 바로 소프트 메이커에 취직해 버렸다고 한다. 당시는 버블 경기로 프로그래머는 초 판매자 시장. 어디에서도 취직할 수 있었다고 하지만, 3K(힘든, 더러운, 급료 싸다)라고 말해진 게임 업계는 피했다고 한다.

 

실력은 확실한 츠치다씨. 그 후 몇 사나 소프트 메이커를 전전하고, 프리가 되어 22세에 사장이 되었지만, 버블이 종료 함과 동시에 회사도 종료. 신문 배달원이 되어 땀을 흘리는 날들이 된다.그 때 23. 「신문 배달은 서서히 나눠주는 신문이 줄어 들어 가는 달성감이 있는 즐거운 일이었다」하지만, 재차 인생을 응시했을 때 「정말로 하고 싶은 것을 하자」라고 결의를 결정했다고 한다.

 

츠치다씨는 게임 회사를 1사 경과하고, 25세에 당시의 스퀘어에 입사. 「파이널 환타지 택티스」나  「베이그란트 스토리」 등에서 주로 렌더링 계의 프로그램을 담당. , FFG」로 불리는 플레이 온라인 전용의 개발 중지가 된 타이틀도 다루었다. 내제의 게임 엔진 Crystal Tools에 종사했다. 후에 전문 분야가 다른 사운드 프로그램으로 이동이 되어, 팀을 나누는 입장으로. 의외롭게도 지금까지 제일 충실.

 

그런 츠치다씨가 토픽마다 업계를 말해서 간다.

 

우선은 「게임 업계는 손해인가 이득인가」라고 하는 논의.

마이너스 이미지도 플러스 이미지도 「그 나름 의미가 있지만」라고 하는 것이지만, 하고 싶지 않은 일을 정시에 마치고 퇴근하여 개인 생황을 즐기는 것보다, 하고 싶은 일을 다소 길게 하고, 그래서 돈도 받을 수 있는 것이 행복이라고 말합다. 츠치다씨 자신, 당초는 제일 좋아했던 게임 업계를 피해 소프트 메이커로 프로그램을 만들고 있었지만, 「지금 정말로 행복합니다. 뭐라고 해서라도 게임 업계에 들어가야 한다」라고 이야기하고 있었다.

그 다음에 「어떻게 하면 업계에 들어갈 수 있을까」라고 하는 의문.

제대로 취직한다고 가정하면 작은 회사에서도 좋기 때문에 우선은 들어가는 것이 선결이라고 말한다. 「실력이 인정되면 어디에서라도 전직할 수 있다. 전직은 마이너스가 되지 않고, 올해 졸업자는 플러스가 되지 않는 업계」라는 것. 「취직이 힘들다고 하고 있는 사람에게 물으면 가고 싶은  회사가 닌텐도, 소니, 스퀘어에닉스라고 한다」라고 대기업만 시야에 넣는 달콤함을 경고하고 있었다. 대기업의 배율은 천배~수 만배가 흔함, 그런 곳에 올해 졸업자로 들어가는 것은 「기적」이라고 지적하고 있다.

 

그럼 「프로그래머로서 필요한 스킬은」이라고 하는 문제.

그러나 츠치다씨는 「무엇이 가능한 사람이 필요한가는 회사에 따라서 다르고, 시기에 따라서 다르다」라고 지적. 몇이나 슬라이드로 기술을 들었지만 「전부 할 수 있을 필요는 없지만, 어느 것도 할 수 없는 사람은 안 된다」이라고 하고 있었다. 보편적인 스킬을 하나 드는 것은 어렵다고 하는 것이었지만, 「필요한 스킬은 시대에 의해서 자꾸자꾸 바뀝니다. 그 변화를 즐길 수 있는 성격이 소중한 것이 아닐까요?.츠치다씨는 「이미 무슨 언어 쓸 수 있는지 모른다」라고.

업계에서 일하고 있는 「크레이지」라고도 말할 수 있는, 장난 중(스님)만이라고 한다. 말하자면 「절도 있는 자유」로, 「암 플라스틱은 보통이고, 애니메이션이나 성우의 CD는 데굴데굴. 걸으면 점프에 채인다」라고. 이전 있던 사무용 소프트웨어의 업계와 비교하면 모두 「좋은 얼굴을 하고 있다. 이상에 불타고 꿈에 불타 쨍쨍한 얼굴로 일을 하고 있다」 한다.

 

15연간 게임 프로그래머를 봐 온 감상으로서는 「안되는 놈은 무엇을 해도 안 된다, 바쁜 사람은 보다 한층 바빠진다」라고 다른 업계와 다르지 않는 것 같다. , 장래에 성장하는 사람은 들어왔을 때부터 이채를 발한다」라고. 자신과 같이 「자신의 캐리어는 스스로 결정할 수 없다」 것  「인간 만사 새옹지마」로서 지금은 행복한 일이 되어있다라는 것. 덧붙여서 「여성 프로그래머는 생각보다는 미인이 많다」라고.

 

덧붙여서 츠치다씨가 3K라고 생각한 게임 업계이지만 「서서히 개선 되고 있다」라고. 당초는 철야 등은 흔하였다고 하지만 「리스크 컨트롤이 잘 되어, 마스터 업 전도 철야는 줄어 들고 있다」라고.

 

「오늘 이 이야기를 듣고, 괜찮다고 생각한 사람은 게임 프로그래머에 적합합니다. 그렇게 생각한 분은 꼭 함께 열심히 갑시다」라고 성원을 보내고 있었다.

 

출처 : http://www.gamebusiness.jp/article.php?id=2086

 

 

저작자 표시
신고
by 흥배 2010.10.08 09:00

「매년 릴리스 하는 것이 숙명 이었던 타이틀」이라고 말해지는 「용과 같이」시리즈.

「매년」이라고는 말해도 실질적인 개발 기간은 10개월. 게다가 퀄리티는 유지하기는 커녕 새로운 향상이 요구.

그러한 가혹한 상황 하에서 어떻게 타이틀을 세상에 내보낼까? 그 내막이 밝혀졌다

 

본 세션은 「개발 환경편」 「기초 기술 라이브러리편」 「디버그편」의 3부로 완성되며 다루어지는 내용은 2008년 이후에 발매되었던 PS3 타이틀에 관한 것.

 

 

PC에서의 대체 개발이 자랑」개발 환경편

「개발 환경의 개선은 얼마나 시간을 줄일까에 있다」라고 한다. 그 때문에 포인트가 되는 것은 자원 관리의 고속화, 빌드 시간의 단축, PC에서의 대체 개발, 그리고 코딩 하기 쉬운 환경 만들기의 4개라고 한다.

 

「용과 같이」의 개발에서는 수 100GB의 방대한 자원이 LAN을 통해서 움직인다. 그 대응으로는 고성능 서버나 서버 네트워크가 도입되고 있다. 코스트를 아까워하지 않고, 신뢰성 높은 것을 선택하는 것에 의해서 결과적으로 시간이 단축.

 

, 독자적인 자원 관리 툴 「TiVersion」를 작성. 이것은 최대 5 노드와 P2P 접속을 실시하는 것으로 서버의 부하를 경감. 직종에 따라 필요한 파일이 다르기 때문에 이 툴에서는 필요한 파일만을 선택적으로 복사하는 기능도 있다라는 것. 다만 백업 등은 서버로 관리하기 때문에 버젼 관리에 대해서는 기본적인 기능 밖에 없다고 한다.

 

「용과 같이 4」에서는 소스 코드가 약 120만행 있었다고 한다. 거기서 빌드 시간의 단축이 중요하게 되는데 이것에 대해서는 빠른 단계로부터 분산 빌드 시스템을 도입하고 있다고 한다. 결과 빌드 시간이 10분의 1로 단축되었다고 한다. 그리고 64bit OS를 도입하는 것으로 링크 시간도 단축되었다는 것.

 

3번째의 「PC로의 대체 개발이 자랑거리」라는 카쿠씨. PS3 개발기의 기동에는 수십초 걸리고 이것이 쌓이고 쌓이면 방대한 시간이 된다. 또 섬세하게 디버그를 하고 싶다고 하려는 의도와 원래 개발기 자체의 코스트가 비싸지 않으므로 PC로의 대체 개발을 추진하고 있다라는 것.

그리고 코딩 하기 쉬운 환경 만들기. 「용과 같이」개발 팀에서는 프로그래머에게 부과되는 코딩의 룰은 매우 느슨하다고 한다. 일정 기준 내이면 자유롭게 코딩 할 수 있는 것으로 개인의 실력을 발휘할 수 있는 것과 동시에 모티베이션의 유지가 되어 있다고도 말한다.

, 팀 내의 커뮤니케이션과 육성에도 배려하고 있다. 「용과 같이」에 관련되는 프로그래머는 35. 위로는 경력 23년차으로부터 아래는 신인까지 있다. 거기서 당구나 다트라고 하는 게임 중의 「플레이 스포트」부분을 신인에게 맡기는 것으로 신입을 육성하였다. 파티션을 만들지 않고 잡담하기 쉬운 환경인 것도 중요하고, 질문 보고를 부담 없이 실시할 수 있다고 한다.

 

 


PC에서 PS3 게임을 개발하기 위해서」 기초 기술 라이브러리편

개발용 멀티 플랫폼 라이브러리에 관한 것. 여기서 말하는 「개발용」이란 제품의 릴리스를 목적으로 한 것이 아니고, 어디까지나 개발 향상을 목적으로 한 것임을 의미하고 있다. PC에서 PS3의 개발을 행하기 위한 라이브러리」라고 바꾸어 말할 수도 있다.

 

이러한 라이브러리에 요구되는 요건으로서는 PC·PS3 공통의 소스 기술을 할 수 있는 공통의 메모리 사용량이다. 거동이 같고 바이너리 데이터도 동일한 것을 사용할 수 있다. Directx9에서도 동작하는이라는 것이 있다.

소스 기술에 대해서는 공통의 형태를 준비. 플랫폼이나 컴파일러에 의존하지 않고 같은 형태는 같은 것으로서 취급할 수 있도록 한다. 특징적 것은 vf128이라고 하는 벡터 플로트형의 변수로 이 형태를 계승한 반환 값으로 사용하는 것으로 효과를 얻을 수 있다고 한다.

 

, 컴파일러 의존의 기술은 매크로로 흡수한다. 예를 들어 강제 인 라인으로 쓰는 방법은PC(Visual C++)PS3(DCC)에서 서로 다르며 데이터 정렬에서는 정의의 앞에 쓰는 것과 뒤로 쓴다고 하는 차이가 있다. 이러한 차이를 매크로로 대응한다는 것.

 

게다가 내부 클래스의 메모리 사용량을 맞추는 궁리가 이루어지고 있다. 메모리 사용량의 큰 플랫폼에 맞추어 어플리케이션 사용 메모리를 동일하게 취급할 수 있게 되어 있다.

 

API나 하드의 차이를 흡수하여 PC 위에서의 거동을 PS3으로 동등하게 하기 위한 예로서는 실제의 원시 코드가 스크린상에 비추어져 PC 위에서도 PS3에서 같은 렌더링 패스를 실행할 수 있는 것이 표시되었다. 「고속이라고 하기에는 미묘하지만 같은 거동을 실현하고 있다」라고 한다.

 

「용과 같이」의 팀에서는 쉐이더 작성을 프로그래머가 한다. 쉐이더의 총수가 너무 증가하는 것 을 억제하려는 의도와 장황한 쉐이더를 사전에 배제하려는 목적이 있다고 한다. 쉐이더 소스 코드 자체는 공통으로 쓸 수 있게 되어 있어 PC,PS3에 가세해 DCC 툴용의 쉐이더도 같은 원시 코드로 움직인다라는 것. 쉐이더의 컴파일러는 컴파일러의 차이를 흡수하는 프론트 엔드를 준비. Visual Studio로부터 PC용의 fxc.exePS3sce-cgc.exe 각각의 커멘드 라인 호출을 실시할 수 있다고 한다.

 

, 그 쉐이더가 무엇을 하고 있는지 이름으로부터 판단할 수 있도록 룰화 된 이름으로 취급하도록 하고 있다. 당초는 디자이너로부터 저항이 있을 지도 모르는 생각했지만 곧바로 익숙해질 수 있었다고 한다. 「애매한 말투로 발주가 오지 않게 되었으므로 작업의 효율화가 진행되었다」라고 하는 이점도 있다.

 

최적화에 대해서는 PC와 멀티 플랫폼 환경은 유지하는 게임 개발자에게는 가능한 한 부담을 주지 않는, 효과 큰 최적화를 작업한다라는 이 3개의 지침에 따라 진행되었다.

 

「용과 같이」에서는 잡다한 길거리를 표현하기 위해서 오브젝트 수나 매테리얼 수가 많아져, 장면에 따라서는 렌더링 커멘드의 발행 회수가 12000회에 달한다. 그대로는 GPU 렌더링 전에, PPU셋업 처리가 늦어지기 때문에 시간이 걸리는 PPU의 처리를 SPU로 했다고 한다. 실제로 SPU로 옮긴 처리의 예로서 모션 처리, 씬의 컬링 처리, 정점 쉐어더 셋, 프라그먼트 쉐이더의 정수 패치 등을 들 수 있다.

 

 

 

「프로젝트 운용을 지원하는 기술」 디버그편

「용과 같이」의 디버그 환경에 관한 이야기. 「용과 같이」에는 디버그를 위한 주된 기능으로서 시점을 변경하는 디버그 카메라, 실행 페이즈를 일시 정지하는 디버그 스톱, 각종 파라미터를 변경하는 디버그 윈도우, 시나리오를 선택하는 시나리오 셀렉터, 어디에서라도 세이브·로드, 스크린 무비 캡쳐-가 갖춰지고 있다고 한다.

 

그 중에서도 잘 사용되는 것이 딥 스위치로 불리는 기능으로 온 마을을 걷고 있는 인물 캐릭터의 패스를 표시하는 것 등을 할 수 있다. 「용과 같이」는 자원 량이 많아, 한 번에 가져 로딩 할 수 없기 때문에 지역 마다 가지고 있다. 지금 어느 지역의 자원을 읽고 있는지, 또는 읽어들이려 하고 있는 것인가? 그러한 정보도 분류 해서 표시.

디버그에 할당할 수 있었던 기간은 개발 후기와 겹치고 있고, 짧은 것. 거기서 삽질을 없애는 것과 동시에 비 디버그 기간의 유효 활용, 휴일 심야 시간의 유효 활용을 유의할 수 있고 있다고 한다.

 

구체적인 예로서는 게임 어플리케이션의 데일리 릴리스를 들 수 있다. 개발의 초기 단계부터 하루에 1, 최신 버전이 개발 팀에 릴리스 된다.

아침 10시까지의 중간 데이터를 컨버터, 에러가 나온 것에 대해서는 환송. 문제가 없으면 실기 데이터와 프로그램 소스를 빌드 하여 체크. 여기에서도 문제가 발견되지 않으면 실행 파일을 릴리스 한다고 하는 순서.

 

2중 체크를 하는 것으로 문제가 있는 데이터를 프로젝트 전체에 전파 시키는 것을 막을 수 있는 한편, 규칙적인 스케줄로 움직일 수 있다고 하는 메리트도 있다라는 것.

「프로그래머의 지각은 없다」라고 말한다.

또 특징적인 디버그 수법으로서 오토 테스트가 있다. 이것은 「디버그 기능의 집대성」이라고 하는 것으로 게임 패드의 입력을 랜덤으로 실시하는 것으로 프로그램 상의 이상 점을 찾아내는 툴.

이것을 휴일 ·심야에 실행하는 것으로 일손을 걸치지 않고 디버그를 실시할 수 있다.

 

오토 테스트에는 서버로부터 무슨 테스트를 실시할지의 파일을 취득, 최신판에 업 데이터 한 후 실행. 에러 발생 시에는 자동적으로 메일이 송신된다고 하는 기능이 갖춰지고 있다. 개발 팀의 멤버는 퇴근 시에 이것을 움직이고 출근하면 종료시킨다. 이것에 의해 약 80침대의 개발 PC에서 자동 디버그가 실현되었다.

 

 

 

「사전 준비로 가능한 한 고속화합시다」라고.

「멤버가 일하기 쉬운 환경을 정돈하여 프로젝트를 안정화 시키는 노력을 하는 것도 소중합니다」라고 세션을 매듭지었다.

 

출처 : http://www.gamebusiness.jp/article.php?id=2116

 

저작자 표시
신고
by 흥배 2010.10.07 09:00

프로그램에서 현재 실행 중이 컴퓨터의 CPU에 대한 정보를 알아야 할 때가 있습니다.


예를들면

1. CPU 32비트인지 64비트인지

2. 코어가 몇 개 있는지

등등...


이런 정보를 알고 싶을 때는 Windows 2000 때까지는 GetSystemInfo를 사용했습니다.

그러나 GetSystemInfo 64비트 Windows에서 이 API를 사용하는 프로그램은 32비트 프로그램이라면 잘못된 정보를 가져옵니다. 그래서 32비트나 64비트 환경에 상관 없이 정확한 정보를 얻기 위해서는 GetNativeSystemInfo를 사용해야 합니다.

GetNativeSystemInfo 64비트 환경에서는 내부적으로 GetSystemInfo를 호출합니다.

 

 

 

 

GetNativeSystemInfo를 사용하기 위한 조건

 

OS : Windows XP 이상

필요한 파일 : windows.h

필요한 라이브러리 : kernel32.lib

필요한 dll : kernel32.dll

 

API를 사용할 때 헤더파일에 _WIN32_WINNT 선언이 0x0501 이상이어야 합니다.

#define _WIN32_WINNT 0x0501

 

 

예제

#include <iostream>

#include <windows.h>

 

int main()

{

           SYSTEM_INFO sInfo;

           GetNativeSystemInfo(&sInfo);

                    

           std::cout << "CPU 개수 : " << sInfo.dwNumberOfProcessors << std::endl;

           std::cout << "프로세스 아키텍처 : " << sInfo.wProcessorArchitecture << std::endl;

          

           getchar();

           return 0;

}


결과


저작자 표시
신고
by 흥배 2010.10.06 09:00

티스토리 툴바