Sense J의 잡다구리한 이야기들....

몇달전인가쯔음 클라우드 컴퓨팅을 이용한 게임스트리밍 서비스의 프로토모델을 본적이있다.
그 당시 정말 획기적이라고 생각을 했다.

그리고....오늘...나는 온 라이브라는 새로운 서비스에 대한 소개영상을 보았다.

그리고 어떤사람의 블로그에서 온라이브에 대한 부정적인 측면을 보았다.

기술적 측면 그리고 비지니스적인 측면이다.

블로그주소를 밝히진않겠지만 조목조목 내가 아는 지식으로 한번 태클을 걸어보자.

1. 기술적 측면..

   그 블로그에서는 기술적인 측면에 대해 이런 글을 써놓았다. 그래픽카드로 렌더링을 할텐데 그게 다중 칩셋이 되는가? 100명인분의 크라이시스를 서버가 그래픽카드 몇대로 처리하는것인가?? 이는 무식한 소리다....왜 렌더링은 그래픽카드로만 한다라고 생각을 하는가? 서버급 피씨 수십대...아니 수백대를 묶어서 cpu로 렌더링을 하고 그 결과를 스트리밍으로 처리를 해준다면 가능할거라는 생각은 왜 못하는것일까? 단적인 예로 크라이시스를 개발했을당시 그래픽카드 성능이 후달려서 슈퍼컴퓨터로 렌더링하고 게임을 돌리며 테스트했다는 일화도 있지않은가?  얄팍한 지식으로 사업을 논한다는건 부끄러운 일이라고생각한다..

엄청난 대수의 서버로 렌더링 연산을 하고 그 결과정보를 압축하여 영상스트리밍을 한다면 굳이 불가능할것도없다. 인풋역시 플래시를 통해서 넘겨받으면 되는것이니까 문제될것이 없다. 아이디어 한번 기똥차다라는 말밖엔 할말이없다. 이런녀석이 정말로 활성화되어 실용화가 된다면 사실상 값 비싼 PC, 비싼 콘솔이 없어도 하고싶은 게임을 즐길수도 있을것이다......기술적으론....?

2. 비지니스적인 측면

  또 위에서 언급한 그 블로그에서는 비지니스적인 측면에 대해 게임회사에서 과연 그렇게 하겠느냐라는 의견을 내놓았다. 고사양 게임을 저사양에서 그것도 저렴하게 즐길수있다면 오히려 양적증가로 인해 이득이 되지않을까하는 생각이 드는데 왜 저 블로거는 그런 의견을 놓는지 모르겠다. 값비싸고 사양이 좋은 유저들중 일부가 정품구매해서 하는 게임, 그리고 사양이 낮지만 즐길수 있게 된 많은 유저들이 정식으로 돈을주고 서비스받아서 하는 게임.....그 소득의 차이가 존재할까? 그리 크게 차이가 나지않을거라 생각한다.


내생각은 이러한 디바이스가 홈씨어터 시스템과 광대역 통신망을 통해 연결이 된다면, 그 어떤 콘솔 부럽지않은 훌륭한 게임디바이스가될것이라는 생각이든다. 그리고 그러한 것이 우리가 앞으로 추구해야할 엔터테인트 먼트가 아닐까싶다...   수많은 디바이스로 한개씩 즐길것인가? 아니면 적은 디바이스로 여러개를 다 즐길수 있을것인가?

이는 유저에 달렸지만 나는 후자쪽이 더 옳은것같다.....집안 인테리어도 그렇고 공간 차지도 그렇고 여러가지 장치를 주렁주렁 달아놓는것보다 티브이에 데크 하나면,  영화도 볼수있고, 게임도 할수있고 티비도 볼수있고, 인터넷도 할수있고 다 할수 있다면 이 얼마나 좋은것인가?

온라이브는 그러한 측면에서 바라본다면 굉장히 긍정적일거라 생각한다.......넷북에서 모니터 아웃시켜서 즐기는 크라이시스,.....콜오브듀티......환상적이지않은가? 하드웨어 플랫폼에 구애받지않고 다같이 즐길수있는 게임.....상상만으로도 멋진 것이라 생각한다....

현재 수많은 네티즌 들의 ActiveX에 대한 반대가 거쎄어지며 표준화가 이루어지려는 움직임이
예전보다 거세어지고있다.

이러한 움직임을 웹에서 뉴스를 통해 접하거나, 포럼을 통해 접한 수많은 학우들이 있을거라 생각한다. 1년전쯤 내가 과제로 ActiveX 방화벽을 만들때 즈음 누군가 이런말을 한적이 있다.

"사장되고있는 ActiveX를 해서 머하는지 이해가안된다. 보안성도 좋지못하고, 말도많고 탈도많은걸 왜 우리가 해봐야 하는거야??"

물론 틀린말은 아니다.

하지만 어떤점이 ActiveX가 그렇게 나쁘다는 생각을 가지게 했는지 상세히 아는지가 더 궁금하다.

백문이 불여일견이라고 했다. 직접 겪어보지않고는 와닿지 않고, 시야가 좁아진다라고 생각한다.

activeX로 단한번도 작성해본적이 없는 사람이 백날 보안이 어쩌니, 비표준이니 어쩌니 해봐야 전혀 설득력이 없다. 왜 그게 나쁜것인가, 무엇이 문제인지는 글로봐서 느낄수 있는것이 아니다.

남이 해놓은 결과만을 보지말고 직접 해보라.
남은 해놓은걸 본것을 자신이 해본것과 착각 하지마라.
남의 경험을 자신의 경험인것으로 착각하지 마라.
남의 생각을 자신의 생각인냥 말하지 마라....

이런말을 이 블로그에 들르는 사람들에게 해주고싶다.

초등학교 3학년때부터 혼자서 독학으로 프로그래밍 공부를 해왔던 학우로써 , 비록 실력은 형편없지만 적어도 내가 꺠달은 부분은 저런것들이기에 문득 이런글을 포스팅한다.

문득 다가올 텀프로젝트에 대비하여
C++의 펑션을 C에서 가져다 쓸 방법에 대해 고민하게 되었다.
그 이유는 벡터와 스택과 같은 매우 유용한 클래스 라이브러리를 사용하기 위함이다.

여러가지 방법이 있을수있지만
웹서핑과 실험이후 얻은 결론은 다음과 같다.
a.cpp , main.c
두개의 파일이 있다고 가정하자
a.cpp에는 클래스를 구현한후, wrapper 더미 펑션을 생성한다.
이유는 씨에서 호출하기 위함이다.
클래스를 래핑하여 건드릴 수 있는 더미 함수를 생성할떄 extern "C"로 생성하여
맹글링 문제가 생기지 않게 해주어야 한다.
함수의 다형성 문제로 컴파일러가 펑션  이름을 알아서 바꾸게 되는데 이를 저지하게 해주는
전처리문정도로 생각하면될듯하다.
이렇게하여
g++ -c a.cpp -o a.o
gcc -c main.c -o main.o

이후 오브젝트 코드가 생성되면 g++을 통해 링크해주면 된다
g++ main.o a.o -o a.out

이런식으로 하면 a.out이 생성되고 c코드에서 C++을 불러오는 경이로운(?)모습을 볼 수 있다.

수업시간에 교수님이 한번 해보라고 농담삼아 던지신 심플파서

S-> aS | bS | c '\n' 으로 끝나는 심플한 그래머를 만족하는
파서를 작성하는것.
의외로 간단하다....



#include <iostream>
#include <conio.h>

using namespace std;
 
// S->aS|hS|c'\n'

int S()
{
 char ch,temp;
 ch=getch();
 if(ch=='a' || ch=='h')
 {
  cout  << "valid Parse : " << ch << endl;
  return S();
 }
 else if(ch=='c')
 {
  temp=getch();      
  if(temp=='\0' || temp==13)
  {
   cout  << "valid Parse : " << ch << endl<<endl;
   cout << "Finished Parse : OK" << endl;
   return 0;
  }
  else
  {
   cout << endl << "invalid Parse : " << ch << endl;
   cout << "err" << endl;
   return -1;
  }
 }
 else
 {
  cout << endl << "invalid Parse : " << ch << endl;
  cout << "ERR" << endl;
  return -1;
 }
 return 0;
}

int main()
{
 // Start Parser
 S();
 return 0;
}