게임쪽 모바일이라면 아이폰/안드로이드 를 배워야하고.. 뭐 유니티엔진을 사용한다면 3D 렌더링에 대한 기본 개념이나 c# 이나 java .. 서버연동해야한다면 네트워크에 웹이나 DB등 알아야할건 고구마줄기처럼 나오는데 아무리 개념만 익힌다고해도 전체 다 공부하는데 시간이 너무 많이 들거라고 생각합니다 만약 온라인 게임기획을 했는데 렌더링쪽만 기본적으로 공부했다 라고 하면 서버쪽 다른 분야에대해선 결국 ' 렌더링 할땐 이렇게 되는데 그게 왜 안돼?' 라는 생각이 들수밖에 없죠 그럼 거기서 실제 개발자와 마찰이 생기게 된다고 봅니다
전문적으로 현재 일을 그만두고 사업을 하신다면 게임개발쪽 공부를 두루두루 하시는게 분명히 좋은 방법이겠으나 그것이 아니라면 가장 잘할수있는것을 활용하여 본인의 아이디어를 실현해나가는게 좋지 않을까요?
아울러서 아무것도 안하고 오브젝트 출력하는것에 프레임은 스레딩으로 높이는건 의미가없습니다 100프레임은 1프레임당 10ms 만에 처리하는거지만 1000프레임은 1프레임당 1ms 만에 처리하는거죠.. 코드나 기타등등 최적화를 아무리 걸어도 유의미한 코드는 수행시간이 0 이 될순없기때문에
단순히 프레임 숫자에 연연할 필요는 없다고 생각합니다
가장 빠른 프로그램은 아무것도 하지 않는 프로그램이다 라는 말이있죠.. 의미있는 수준의 부하를 멀티스레드로 분산시킨다면 성능이 좋아지겠지요.. 개인적으로 의미있는 수준의 부하를 대충 5ms 이상 정도 걸리는 작업이라고 생각합니다 ( 그 이하의 작업을 멀티스레드로 뺀다한들.. 락거는 비용및 어쩔수없는 값복사가 일어날텐데 오버헤드가 더 심해지겠지요 )
일단 전체 구조가 안맞는것 같습니다.. 실제 게임쪽에서 멀티쓰레드 안쓰는 이유가 위와같이 로직과 렌더링 객체가 너무 밀접하기 때문인데요.. ( 렌더링하는 녀석의 좌표를 로직에서 자꾸 참조해야할일이 생기죠.. ) 그래서 사용자(.. 우리는 사용자죠. ) 입장에서 멀티스레드를 사용하기보단 더 로우레벨에서 멀티스레드를 지원합니다.. DX 나 OpenGL 쪽에서 멀티스레드를 지원하는 함수를 사용합니다.. 실제 렌더링은 호출 순서가 정해진데로 흘러야하고 ( 렌더링 순서에 따라 알파가 뒤섞이겠죠?) 객체의 값참조가 자주 일어나서 사용자단에서 멀티스레딩으로 렌더링을 걸면 오히려더 느리게 될수있습니다 본인 엔진에 멀티스레드 기능을 넣고싶다면 텍스쳐등 파일을로드하는 부분만 멀티스레드로 빼도 꽤큰 성능향상이 일어날것같네요
