태어나서 처음으로 특허가 등록되었습니다.
회사 업무로 작년에 작업한...
가상스튜디오 관련 프로그램에 도입된 기술을
특허 신청 했었는데요... (회사 연구소장님과 공동명의로)
이게 특허 등록에 성공했습니다.

쩝.

해당 프로젝트는 접힌지 오래인데.
어따 써먹지.

Posted by moonyeom

2012/07/19 11:11 2012/07/19 11:11
, ,
Response
100 Trackbacks , No Comment
RSS :
http://www.arcshock.com/kr/rss/response/77

잘가요, 잡스...

사용자 삽입 이미지
잡스옹이 돌아가셨네요.
한 시대가 저물어가나봐요.
저 또한 그 시대에 속해있기에
마음이 더욱 아련합니다.
고인의 명복을 빕니다.

이미지 출처 : www.apple.com

Posted by moonyeom

2011/10/06 15:35 2011/10/06 15:35
, ,
Response
8 Trackbacks , No Comment
RSS :
http://www.arcshock.com/kr/rss/response/68

SandCastle 을 아이폰용으로 개발하기로 계획한 이후
맥북도 사고 iSO 개발자 프로그램도 사고(이걸 마치 물건처럼 구매해야 함... 거참...)
그리고 며칠 걸려서... 이런저런 이유로 어렵다는 iSO 개발자 등록을 마쳤습니다.

한국쪽 개발자 등록 요청이 많아서 애플이 고생한다는 소문이 있더니만
결국 한국쪽을 전담하는 팀이 생겼네요. (얼마 안되어서 따끈따끈한 상황인 듯)
080-860-9797 번으로 전화하면 친절상담 해주십니다...
진짜 친절함.
막힌 액티베이션 코드도 풀어주고요...
전에는 이런거 풀려면 애플에 이멜로 구구절절 사연 보내고 항의하고 며칠 걸려야 했던 것이
이제는 전화 한통으로 끝남... 움홧홧.

그러나...
연 10만원이 넘는 비용이 나간다는거...
욱... (ㅡ,.ㅡ);

암튼, 폰에서 프로그램을 돌려볼 수 있게 되었으니,
이제 아이패드2만 사면 되는건가... (아 ~~~ 애플은 이렇게 또 돈을 벌고...)

Posted by moonyeom

2011/08/03 10:05 2011/08/03 10:05
, , ,
Response
A trackback , 2 Comments
RSS :
http://www.arcshock.com/kr/rss/response/67

저희 ArcShock 팀은 3명으로 구성되어있습니다.

moonyeom : 기획, 프로그래밍, 음악 담당
komagi : 기획, 그래픽 담당
kuna : 일정지연, 업무방해 담당

그중 가장 막내 kuna 가 며칠 전에 24개월을 넘어섰습니다.
두돌이죠.

지금까지는 게임이라곤 "지치지 않고 울며 떼쓰기" 정도였던 녀석이
어느틈에 (무려) 30 조각 그림 퍼즐을 혼자 맞추는 단계까지 발전했습니다.
물론, 지가 좋아하는 토마스와 친구들 퍼즐이어야 합니다만.

퍼즐 한조각을 맞추고선, 그 짜릿한 흥분을 못 이기고 방바닥을 뒹굴며 좋아라하는걸 보니
앞으로 꼭 좋은 게임을 만들어내고야 말 인물인 것 같습니다.

엄마 아빠, 아니... 팀의 선배들을 꼭 넘어서다오.

Posted by moonyeom

2011/06/30 22:37 2011/06/30 22:37
, , , ,
Response
No Trackback , No Comment
RSS :
http://www.arcshock.com/kr/rss/response/64

한 5년정도 전부터 만들어서 업글해나가고 있는 3D 엔진을 쓰고 있습니다.
근데 어제, 어이없는 버그가 발견되었어요.

DirectX 의 Device 를 Reset 할때마다 GDI 가 한개씩 증가하는 문제였어요.
이게 눈에 잘 띄지 않는 문제라 지금까지 문제없이 사용해온 것인데요,
실시간으로 계속 Reset 을 해야 하는 상황에서 이 문제가 불거진거죠.
GDI 가 계속 증가... 나중에 리소스 부족으로 꽥.

결국 버그를 찾아냈는데요,
창모드에서 DX 를 초기화할때 화면의 BPP(Bit per pixel)가 필요한데
(요즘은 다들 32비트로 쓰지만, 예전에는 16비트 화면도 많이들 썼지요...)
이걸 얻기 위해서 화면의 Handle을 얻어와야 했어요.
Handle을 얻고 나서 그걸 이용하는 코드가 다 수행된 다음에는
Handle을 다시 Release 해줘야 하는데, 그걸 안했던거죠.

보통때에는 DX 초기화를 여러번 할 일이 거의 없지만,
이번 경우에는 초당 수십번씩 초기화가 일어나는 상황이었어요.
(이게 필요할 일이 있겠냐 싶지만, 회사 프로젝트에서 꼭 필요한 순간이 있었다는....-.-)
암튼, 결국 회사 프로젝트에 엮이는 바람에 발견된 버그랍니다.

일단 발견되고 나니 워낙 초보적인 실수라 금방 해결했지만요.
오래도록 사용하고 있는 엔진도 이렇게 버그가 남아있다는 것과,
별것 아닌 문제가 경우에 따라선 큰 에러를 일으킬 수도 있다는 것.
그리고, 항상 겸손해야겠다는 것을 새삼 느끼게 되었습니다.

P.S.
오늘은 잠도 많이 부족하고 배도 고프고 해서 영 일에 집중을 못하겠네요.
하루종일 트윗질 하다 잠시 쉬려고 블로그질... (^-^)>

Posted by moonyeom

2010/10/21 11:45 2010/10/21 11:45
, , , , ,
Response
No Trackback , No Comment
RSS :
http://www.arcshock.com/kr/rss/response/60

[잡담] 더위와 개발...

더위는 개발에도 영향을 미치는데요...
특히 저처럼 더위에 매우 취약한 개발자일 경우에는 아주 치명적입니다.

최근 한달정도 무쟈게 더웠습니다.
지구온난화 때문인지 라니냐 탓인지 지자기역전인지
아니면 안드로메다 은하의 접근 때문인지는 모르겠습니다만,
앞으로의 여름은 전처럼 견딜만하지 않을 것 같습니다.

개발 일정을 계획할 때에 더위에 대한 고려를 한 적은 지금까지 한번도 없었습니다만,
올해 여름을 겪고 나니, 앞으로는 여름철 더위를 일정에 영향을 주는
중요한 변수로 인정해야만 하겠다는 생각이 듭니다,.

모래성 진도가 안나가는 것에 대해 변명하려고 이 글을 쓰는 것은 결단코 아니라는.

Posted by moonyeom

2010/08/21 18:35 2010/08/21 18:35

// 게임 개발시에 깜빡하기 쉬운 것들을 이곳에 적어두려고 합니다.
// 틈틈히 생각나는게 추가되면 요기다 업뎃할꺼고요...
// 근데, 이 모든 사실을 깜빡하면...?

01. 중복실행 방지
게임이 중복실행(두개 이상의 프로세스가 실행되어버리는 것)되면 뭔가 좀 어설퍼보입니다.
(얼마 전 데모를 플레이해본 Gyromancer, 실수로 더블클릭을 두번 한 결과, 무려 전체화면 게임이 두개 뜸 !)
이거 참 당황스럽고, 좀 묘한 의미에서 게임이 어설퍼보이게 됩니다.
또한, 데이타 저장 등에서 두 프로세스가 상호 충돌할 수 있으니...
특별한 이유가 없다면 무조건 중복실행은 막아두는게 좋겠습니다.

02. Radeon 카드 테스트
취향상 GeForce 카드를 사용하는지라,
간혹 프로그램 배포시에 Radeon 카드에서 예상 못한 문제가 발생하곤 합니다.
GeForce 계열의 GPU 에 비해 Radeon 계열의 GPU 는 훨씬 꼬장꼬장하기 때문에,
사소한 Render State 오류로도 먹통 화면을 나타내기도 하고요,
렌더링이 부분적으로 누락되는 문제가 생기기도 합니다.
가능하다면 GeForce 와 Radeon 두가지 개발 시스템을 갖추고 개발하는 것이 좋겠습니다만,
맛좋은 할리스 커피를 일주일에 다섯번밖에 먹지 못하는 가난한 개발자라면(그래서 가난해지는거쟎아 !!!)
일단 갖춰진 시스템에서 개발하고, 배포 전에 여러 지인들을 통해 테스트를 부탁하는 것이 좋겠습니다.

03. Mouse click scan
경우에 따라 DInput 을 쓰지 않고 그냥 마우스 값을 스캔해서 사용하는 때도 많은데요...
이때, 프로그램의 포커스가 다른 곳으로 옮겨갔을 경우에는 마우스 스캔을 하지 않도록 하는걸 깜빡하면
프로그램의 포커스가 옮겨갔을 경우에 대한 문제가 생깁니다.
당연한건데도 종종 까먹곤 하지요...

04. Lockable
D3D 의 디바이스를 Lockable 로 해놓는 경우가 종종 있어요.
임시로 DC 텍스트를 출력하기 위해서인데, 이건 정말 임시로 쓰는 경우에 해당하는데...
절대로, 절대로 글자출력을 Lockable Surface + GetDC 조합으로 해서는 안됩니다.
근데, 걍 테스트 코드로 그렇게 해둘 때가 있죠.
그리고 테스트 코드를 지운 후에...
Lockable 설정을 했던 것은 까맣게 있어버리는 경우가 있습니다...-.-;

05. MP3
BGM 으로 MP3 를 무심결에 사용할 뻔 하는 경우가 있습니다.
얼마전 광님께서도 말씀해주셨습니다만, MP3 는 파일포맷 자체에 라이센스가 있기때문에
게임의 배경음악으로 사용할 경우 문제가 발생할 수 있지요...
관련 사이트 : http://www.mp3licensing.com/royalty
암튼, 안전하게 OGG 정도로 갈아끼우는 것을 잊지 말아야 하겠습니다.


06. 전체화면과 관련된 이상한 오류
드물게 나타나는 오류인데,
전체화면과 창모드를 오갈때에 발생하기도 하고
그냥 전체화면 모드로 실행할때 발생하기도 합니다.
코드상의 문제인지 DX 와 윈도우즈 사이의 미묘한 문제인지 모르겠으나, 암튼 증상은 이렇습니다.
전체모드에서 프로그램의 캡션바가 떨어져나가지 않습니다.
하지만 화면상에는 캡션바가 없는 것으로 나오고요, 화면 해상도도 설정한 그대로인 상태가 됩니다.
추측으로는, 640*480 같은 저해상도에서 목격되는 것 같네요.
암튼, 이때문에 클라이언트 영역만 남아있다고 생각하고 프로그래밍할 경우에는
좌표를 얻어올때 문제가 될 수 있습니다.
일단 이 문제의 해결을 위해서 전체모드/창모드 설정시에
폼의 캡션바를 붙이거나 떼는 등의 작업을 손수 해주는 것이 안전할 것 같습니다만,
일단 이건 임시방편이고... 근본적으론 원인을 파악하는게 좋겠죠.

07. DirectSound 의 MainVolume 관련 오류
On-Board 형 사운드카드의 드라이버들 중에서
DirectSound 를 지원하긴 하는데 좀 이상하게 동작하는 카드가 종종 있는 모양입니다.
예를 들어, 게임이 실행되면 이상하게 윈도우 볼륨이 변한다는 분들이 종종 있는데요,
바로 이런 이유가 아닌가 합니다.
그런 증상을 디버깅해본 결과,
DirectSound 의 표준적인 코드에서도 오동작이 확인되었습니다.
DirectSound 의 PrimaryBuffer Volume 을 변경하면
윈도우의 WaveVolume 이 함께 변경되는 문제였는데요,
DirectSound 를 초기화 할때 다양한 방법을 사용해보았습니다만,
증상은 개선되지 않았습니다.
당장은 우회하는 방법으로...
PrimaryBuffer 의 볼륨은 건드리지 않고 효과음 각각의 볼륨만 조절하는 것으로
해결해두었습니다만...
뭔가 찝찝합니다.

08. (또) Radeon 문제
사실은 Texture 규격에 대한 문제입니다.
노트북용 Radeon 칩에서 DXT 압축 텍스쳐에 문제가 발생했습니다.
2의n승 규격에 맞지 않는 DXT 텍스쳐를 만들지 못하는 문제였는데요,
엔진에서 해당 상황을 체크하고 있었습니다만
요즘 카드는 웬만하면 다 되다보니 간과하고 있었습니다.
(나온지 몇년 된 온보드 인텔칩에서도 처리되는 문젠데 이건...)
암튼, 해당 상황에서는 DXT 압축을 풀어서 텍스쳐를 올리도록 수정하여 해결했습니다.
수많은 DirectX 상태 플래그를 다 점검하는 수고를 하지 않으면
사소한 문제를 간과하기 쉽습니다만...
그렇다고 그 많은 상태값을 다 처리하자니 너무 하위기종까지 신경쓰는 것 같기도 하고...
그래서 어느정도까지만 선택하여 체크하기로 하였습니다.
예를 들어, 텍스쳐의 가로세로 크기가 같아야만 한다는 규정따위는...
부두카드를 지원할게 아니라면 그냥 무시하자...는 식이죠.
(너무 귀챠니즘에 빠진건 아닐까...)

09. Reserved...
10. Reserved...

Posted by moonyeom

2010/04/13 23:15 2010/04/13 23:15
, , , ,
Response
A trackback , 5 Comments
RSS :
http://www.arcshock.com/kr/rss/response/4

이건 현업(한국의 온라인게임 개발사)에서 일하면서 느끼는 점입니다.
또한, 일반론이 아닌 개인 견해이며, 옳을 수도 있지만 틀릴 수도 있습니다.

저는 모 게임개발사에서 엔진개발을 하고 있습니다.
늘 신기술을 염두에 두고 개발을 하고요,
남들은 갖지 않은 독특한 기술을 개발하는데에도 늘 관심을 기울이고 있습니다.
특히 Outdoor 엔진부품을 개발하는데에 관심이 많아서
매우 넓은 면적을 소화할 수 있는 Terrain 이라든가,
풀이나 나무를 자동으로 배치하고 관리하는 기술이라든가,
수면 렌더링을 좀 더 저렴(CPU, GPU 시간을 아낀다는 의미)하게 구현하는 방법이라든가...
해안선을 알아서 그려주는 방법이라든가...
이런 주제들을 가지고 연구 개발을 해왔습니다.
이런 기술을 직접 개발하는 것은 결코 쉬운 일은 아니었습니다만,
노력한 만큼의 결과를 얻을 수 있었습니다.

게임 개발사에서는 이런 기술을 개발하는것이 무척 환영받을줄 알았습니다.
하지만, 2년반 정도 일을 하면서 느낀 점은...
처참함이었습니다.

기술개발은 당장 돈이 되지 않습니다.
때문에, 개발사들은 대부분 기술을 개발하는데 인력과 비용, 시간을 쓰기보다는
그냥 고급 엔진을 비싼 돈 주고 사오는 것으로 만족하려 합니다.
당연히, 회사 자체기술은 쌓이지 않고 버전별로 상용 엔진만 쌓이게 됩니다.

"그냥 사도 되는데 왜 만듭니까 ? 하지 마세요."
이런 이야기를 2년간 들어왔습니다.
열심히 일을 하는데도 문제제기를 받아야 하고, 또 그런 의견에 대항하여 팀의 존재가치를 증명해야 하는...
이런 지리하고도 아무 남는것 없는 싸움을 1년이 넘게 해왔습니다.
이제 너무 지쳤고, 자존심도 상하고, 또 한국의 온라인게임계를 떠나고 싶은 마음까지 갖게 됩니다.

그렇다고 해서 엔진을 사서 잘 해결이 되는가 하면, 그렇지도 않습니다.
엔진에 없거나 불편한 기능은 직접 만들어서 해결해야 하는데...
기술개발을 박대한 회사가 이런 순간에 힘을 발휘할리가 없지요.
결국 삽질의 연속, 괜히 엔진만 갈아치우고 개발자들만 떠나고 새로뽑고를 반복합니다.
이것이 한국 온라인 게임 개발사 대부분이 갖고있는 연속 삽질 스킬입니다.

상용엔진으로 게임을 개발하는 것 역시 훌륭한 일이고, 어려운 일입니다.
하지만, 그것만으로 만족한다면 개발사는 영원히 엔진 종속적인 게임 개발에 머물러야 합니다.
엔진이 지원하지 않는 기술은 한뼘도 욕심낼 수 없게 되고요,
게임의 기획도 엔진 스펙에 맞추어서 해야만 합니다.
이것은 말 그대로 "종속"입니다.
참신한 무언가를 기대할 수 없는 환경인 것입니다.

또한, 엔진의 가격이 올라가도 어쩔 수 없이 사야 하고,
기술지원도 외국에 메일을 보내 어렵게 받아야 합니다.
마음에 쏙 드는 답을 받기도 어렵습니다.
(언리얼이나 크라이텍 쪽은 한국 지사를 만든다고 하니, 이런 어려움이 얼마간 해소될지도 모르겠습니다.)
또한, 엔진을 구입한 후 그것을 게임에 적용하기 위해 개발자들의 숙련도를 올리는 시간은
그만한 기술을 개발하는 시간에 비해 그닥 짧지도, 비용이 더 저렴하지도 않습니다.
보통 1~2년 정도를 엔진 만지작거리는 시간으로 소비합니다.
기술을 직접 개발하여 소유할 수 있는 시간과 비용, 인력을
상용 엔진을 구입하고 그 사용법을 익히는데에 다 쏟아붇는 것입니다.

이제 상용엔진의 성능을 따라갈 엔진을 직접 만드는 것은 불가능하다...
이것이 대부분의 게임 회사나 개발자들이 하는 이야기입니다.
어느정도 일리 있는 이야기입니다.
십수년의 역사를 가진 대형 상용엔진을
몇년만에, 그것도 절반의 절반도 안되는 개발인력으로 똑같이 만들어내는 것이 가능하다면 그건 사기죠.

하지만, 그것만이 진실은 아닙니다.
상용엔진을 구입한 개발사가 사용하는 엔진 기능은 전체 기능의 아주 작은 일부에 불과한 것이 대부분입니다.
통합엔진의 문제점은 바로 이것에 있습니다.
오만가지 기능이 다 들어가 있지만,
따로 떼어 부분부분 구입할 수 없기 때문에 거액을 들여 구입해야 하는 것입니다.

그 대안이 바로 콤포넌트형 미들웨어 엔진입니다.
하늘, 땅바닥, 캐릭터, 이펙트, UI 등등을 미들웨어로 따로 개발하거나 구입하고
그것을 조립하여 게임을 만들게 되면
비용도 절감될 뿐 아니라 기술축적에도 더 도움이 됩니다.

외국의 모 게임 개발자가 모 컨퍼런스를 통해 한 말이 있습니다.
"게임엔진의 미래는 콤포넌트 엔진이다"
이미 텍스쳐 전담 엔진, 길찾기 전담 엔진, 나무 전용 엔진, 애니메이션 블렌딩 전용 엔진, 컬링 엔진 등...
게임의 특정한 기능만을 위한 미들웨어 엔진들이 상용으로 판매되고 있습니다.

제가 추구하는 것은 바로 이런 콤포넌트형 미들웨어 엔진 개발입니다.
이렇게 되면 대형 상용엔진과 직접 박치기를 하지 않고도
그들의 급소만을 공격하는 방식으로 경쟁할 수 있게 됩니다.
게임 개발에 꼭 필요한 부분만 따로 만들고,
그중 몇몇 특정 기능을 강화하여 더 나은 게임 개발이 가능하게 하는 것입니다.

하지만, 국내에서 이런 방식의 엔진 개발을 하기 위해서는
많은 벽과 싸워야 합니다.
회사에서 뭔가 결정권을 가진 사람들이 모두 하나하나의 벽처럼 느껴지곤 합니다.
그 벽을 다 넘기가 참으로 어렵습니다.

제 방법론이 잘못된 것일지도 모르죠.
하지만, 해답일지도 모릅니다.
결국, 진위를 가리기 위해서는 개발을 해서 게임에 도입해보는 과정이 필요한데
한국의 온라인 게임 개발환경은 그러기에는 너무나 단단한 벽과 같습니다.
저는 지금도 투쟁중입니다.

답답함에 한번 끄적여봤습니다.

Posted by moonyeom

2009/12/18 11:48 2009/12/18 11:48
, ,
Response
No Trackback , 9 Comments
RSS :
http://www.arcshock.com/kr/rss/response/8

인디게임과 Delphi(델파이)

게임도 어플리케이션이니, 그것을 개발하기 위해서는 어플리케이션 개발도구가 필요합니다.
이런것을 흔히 컴파일러라고 부르기도 합니다만,
엄밀히 얘기하면 컴파일러를 탑재한 어플리케이션 개발도구 또는 개발환경이라고 하는 것이 적합하겠습니다...
...만, 너무 기니깐 그냥 개발툴이라고 부르도록 하죠.

요즘은 인디게임 개발자를 위한 상용엔진의 인디버전(무료)도 나오고 있습니다만,
이런 것은 아무래도 사용법이 복잡하거나 엔진의 덩치가 너무 크거나
혹은 제한된 툴 사용법을 따라야 하기 때문에 유연함이 떨어지거나 적응기간이 오래 걸리는 등의
잠재적 문제가 있을 수 있습니다.

플래쉬 액션스크립트만을 이용해서도 충분히 훌륭한 인디게임 개발이 가능하다고 생각됩니다.
최근엔 플래쉬용 3D 엔진 개발사도 여러군데 되는 것으로 알고 있습니다.
하지만, 플래쉬로 3D 까지 소화하기엔 아직은 좀 무거운 듯 합니다.

그래서, 가능하다면 직접 프로그래밍을 해서 게임을 개발하는 것을 권하고 싶습니다.
어떤 도구를 쓰든 개발은 가능하겠지만,
깊숙한 부분까지 건드릴 수 있는 도구를 사용한다면, 표현의 자유가 더 커질 것이기 때문입니다.
물론, 그런 프로그래밍 능력을 확보하는 것은 쉬운 일만은 아닙니다.
이런건 각자 능력껏 해결하셔야 되겠습니다...

게임 개발에 가장 많이 사용되는 개발툴은 MS VisualC/C++ 일 것입니다.
뭐, 워낙 많이 사용되고 그 편리함과 강력함에 두말할 나위가 없다는데에 이견이 없을 것입니다.
하지만, 오늘은 조금 다른 개발툴을 이야기하려고 합니다.
바로 Delphi(델파이)입니다.

Delphi 는 C/C++ 과는 조금 다른, Pascal 이라는 언어로 되어있는 개발툴입니다.
예전에 유명했던 볼랜드C/C++ 을 만들었던 개발사의 작품이죠...(지금은 다른 회사로 넘어갔습니다만...)

흔히 C/C++ 이나 JAVA 프로그래머의 수가 많아 상대적으로 Delphi 개발자는 적어보입니다만
그 절대적인 수로만 본다면 국내에만도 무시할 수 없을만큼 많은 Delphi 개발자가 있습니다.
주로 공공기관이나 금융, 대기업의 사내 솔루션 등에서 많이 사용되고 있습니다.

하지만 최근의 다수 개발자들에게 Delphi 는 죽어가는 개발툴로, 혹은 DB 전용 개발툴로 인식되고 있습니다.
Delphi 가 Bisual Basic 정도의 개발툴로 인식되기도 합니다.
이런 점은 상당한 오해입니다.
저는 회사 업무로 3D게임엔진을 Delphi 로 개발하고 있구요,
그 품질이나 성능면에서 만족스런 결과를 내고 있습니다.

이제 결론을 꺼내보겠습니다.

Delphi 는 인디게임 개발에 매우 적합한 개발툴입니다.
일단, 일반적인 개발툴들 중에서 컴파일/빌드 속도가 가장 빠릅니다.
어지간한 규모의 프로젝트에선 컴파일 시간을 느끼기 어려울 정도죠.
소스코드를 조금씩 수정하고 빨리 결과를 보고 싶어하는 조급한 프로그래머들에게
최상의 개발환경을 제공하는 셈이 됩니다.
이런 신속한 컴파일은, Visual C/C++ 에선 기대할 수 없는 점입니다.

또한, Delphi 는 개발환경이 복잡하지 않고 RAD Tool 의 외형을 지니고 있기 때문에
프로그래밍을 하면서 개발툴의 모습을 함께 볼 수 있는 "가시적 개발환경"을 마련해줍니다.
이런 장점때문에 작고 간단한 게임이나 게임툴 개발시에 개발속도가 비약적으로 향상될 수 있습니다.
실제로, 제가 Delphi 를 이용해 이런 저런 Tool 을 개발하는 것을 지켜보는 많은 C/C++ 개발자들은
자주 그 개발속도의 비밀을 궁금해하곤 합니다.

적은 시간에 프로그래밍을 조금이라도 더 해야 하는 짬짬이 인디 개발자들이라면,
이런 신속한 개발에 특화된 Delphi 는 많은 시간과 노력을 절약해줄 것입니다.

Posted by moonyeom

2009/12/17 18:43 2009/12/17 18:43
,
Response
2 Trackbacks , No Comment
RSS :
http://www.arcshock.com/kr/rss/response/7


블로그 이미지

너무 큰 기대만 없다면, 뭘 하든 의미는 있다.

- moonyeom

Notices

Archives

Calendar

«   2017/05   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Site Stats

Total hits:
260163
Today:
12
Yesterday:
35