Cocos2d-x 3.16 업데이트

마일스톤을 보면 9/30일에 릴리즈 예정입니다.

이번 업데이트에는 어떤 변경점이 있는지 궁금하네요.
요즘에는 큰 변경사항은 없고 엔진 안정성을 올리는 것으로 진행되었습니다.
3.15버전에서 액션 버그, Label 버그 등등이 있었는데 수정되었는지 지켜봐야겠습니다.

해결된 이슈리스트만 봐도 어느정도 해결은 된 것으로 보이지만
릴리즈된 결과물을 확인해봐야 알수있겠죠.

2일이 지났지만 아직 릴리즈는 안됐습니다.
앞으로 업데이트될 내용을 한번 확인해보겠습니다. (3.16 브랜치에 있는 릴리즈노트를 확인)
2017/10/1 - [v3.16 브랜치] 릴리즈노트

Highlights

• better support creator_to_cocos2dx creator plugin
• add LayerRadiaGradientLayer
• update to support Android Studio 2.3.3
• fix the issue that lua projects will crash on iOS simulator with Xcode 8.0+
• revert CocosStudio reader and flatbuffer
• fix compling error with iOS 11
• use prebuit bullet to improve compiling speed
• remove supporting of Windows 10 metro, Windows Phones and Tizen
• update to Spine v3.5.35 and support skeleton batching in web engine

위의 하이라이트를 보면 가장 큰 업데이트라고 볼 수 있는
Cocos Creator에서 만든 것을 C++로 가져올 수 있다는 점과
prebuilt를 사용해서 bullet 빌드하는 컴파일 속도를 올렸다는 점을 볼 수 있을 것 같습니다.
(윈도우 10, 윈도우 폰, 타이젠 지원 중지도 크다면 큰 변경사항이네요.)

아직 공식 업데이트가 되지 않아서 변경될 수 있지만 하이라이트 사항은 큰 변경은 없을 것으로 보입니다.

전체 릴리즈 노트는
아직 올라오지 않았네요... 정식 릴리즈 때 업데이트 하겠습니다.
그럼 글 마치겠습니다. :)

# 업데이트
10월 9일 오전 10시 30분 쯤에 3.16버전 업데이트되었습니다.
https://github.com/cocos2d/cocos2d-x/releases/tag/cocos2d-x-3.16

Cocos2d 커뮤니티에서 일어나고 있는 이야기들

제가 요즘 관심있게 보고 있는 토픽입니다. 

내가 사용하는 엔진이 미래가 있는가.

앱을 개발하기 시작해서부터 연속적으로 사용하지 않았지만, 

지금까지 써온 게임 엔진은 Cocos2d-x 입니다. (한 4년정도..?)

최근에 Cocos2d-x 엔진은 어떤 로드맵을 가지고 개발을 하고 있지?
내가 하는 프로젝트, 회사에서 쓰는 프로젝트가 cocos2d-x를 사용하는데 

같이 성장할 수 있는 엔진일까? 하는 생각이 들었습니다.

그러다가 블로그에 정리하면서 커뮤니티에 올라오는 글들을 보고 있는데 

이런 고민들이 전 부터 있었다는 걸 알 수 있었습니다.

맨 처음에는 이 글을 보았습니다. (엔진 vs 에디터)
http://discuss.cocos2d-x.org/t/we-need-a-friendly-eng…/33651

투표를 하면서 이야기를 하지만 C++이 짱이야! 하는 사람때문에 모두가 힘들어했던 쓰레드와
http://discuss.cocos2d-x.org/t/vote-cocos2d-x-future-…/38364

나중에는 Cocos2d-x Founder, walzer가 답변한 것 까지
http://discuss.cocos2d-x.org/t/answering-the-question…/38665

논의가 많이 길고 영어 글이라서 추석동안 한번 어떻게 돌아가는지 알아봐야겠습니다.
(사실 영어 글을 읽고 있으니 저게 진짜 트롤링인지 아닌지 한참을 봐야 알수 있었습니다. ㅠㅠ)

지금도 위의 3개 쓰레드를 보고 글을 작성하고 있는데 논의되는 내용이 많아서 천천히 써봐야겠습니다.

Cocos2d의 역사

한눈에 볼 수 있는 Cocos2d의 역사
(The history of Cocos2d in a glimpse)

원글: https://retro.moe/2017/04/16/cocos2d-in-a-glimpse/

Cocos2d 만든 Ricardo Quesada의 Cocos2d의 역사에 대한 블로그를 번역했습니다.

2008년 2월, 아르헨티나 코르도바의 Los Cocos에서 우리는 "Los Cocos" Python 게임 엔진을 시작했습니다.
나중에 Cocos2d로 이름을 변경했습니다. 아이디어는 우리가 PyWeek 용으로 게임을 만들기 위한 게임 엔진을 만드는 것이었습니다. 

PyCamp 2008. Centro Allen Gardiner, Los Cocos, Córdoba, Argentina

Alejandro Cura와 PyAr의 다른 멤버들의 도움을 받아 Lucio Torre, Daniel Moisset, Rayentray Tappa 그리고 제가 게임 엔진 개발을 시작했습니다.
2008년 3월, 우리는 PyCon Chicago에서 라이트닝 토크에서 발표한 베타 버전(또는 알파 버전?)을 발표했습니다.

PyCon March 2008, Chicago. We announced Cocos2d in a lightning talk.

2008년 7월, Lucio와 저는 Euro Python에서 Cocos2d를 발표했습니다. (v0.3 버전?) 

With Lucio Torre at Euro Python 2008 presenting Cocos2d.Vilnius, Lithuania, July 2008

또한 Lucio와 저는 PyCon Ar 2008 및 2009에서 Cocos2d를 발표했습니다.
2010년에는 Claudio Canepa가 새로운 Cocos2d 개발자/관리자가 되었습니다.

Cocos2d-iPhone 

2008년 초쯤에, 애플은 아이폰에 스토어가 있다고 발표했습니다. (앱스토어)
애플은 수익의 30%만을 가져갔습니다. (그 당시에는 통신사가 약 90 %를 차지하고 있었습니다).
게다가 아이폰은 OpenGL ES에 의해 구동되었고, OS는 유닉스 기반이었습니다.

이 무렵, 저는 돈을 벌 수 있는 앱을 만들고 싶었습니다.
저는 이전의 웹(플래시) 및 피처 폰(J2ME)을 가능한 시장으로 봤습니다.
하지만 애플의 발표 이후, 아이폰 전용 게임을 개발하기로 결정했습니다.

저의 iPhone 게임을 만들기 위해 게임 엔진이 필요했기 때문에 Objective-C로 Cocos2d를 다시 작성했습니다.
높은 수준의 디자인은 동일하게 유지되었지만 iPhone에서 동작하도록 실질적인 변화를 만들어야 했습니다. 이것이 바로 "cocos2d-iphone"이 탄생한 입니다.
첫 번째 cocos2d-iphone 버전 (v0.1)은 2008년 6월에 출시되었습니다.

2008년 3월, 저는 iPhone 개발자 라이센스를 얻기 위해 라이센스를 신청했으며,
마침내 2008년 7월에 라이센스를 받았습니다. (지금은 몇 분 안에 얻을 수 있는 반면, 저는 4개월이 걸렸습니다.)
라이센스없이 iPhone 앱에 게임을 게시하는 것은 불가능했습니다.
라이센스를 기다리는 동안 계약 업무도 하고, cocos2d-iphone을 사용하여 써드 파티를 위한 게임을 개발하였습니다.

제 iPhone 개발자 라이센스를 받으면서 저의 첫 번째 게임인 아이폰 용 Sapus Tongue를 만들었습니다.
그러나 상업용 게임을 만드는 것이 저에게는 그다지 재미있지 않다고 생각했습니다. 어느 누구도 쉽게 찾을 수 없었습니다.
cocos2d-iphone이 이미 유명해졌기 때문에, 저는 이 엔진에 풀타임으로 일하기로 결정했습니다.
제가 이렇게 결정할 수 있는 이유는 제가 실제로 cocos2d-iphone을 위한 두 개의 상업적 도구인
LevelSVG(cocos2d 상위에 있는 에디터 + 물리엔진)와 Sapus Tongue 소스 코드를 판매함으로써 실제로 생계를 꾸려 나가고 있기 때문입니다.

2009년 초에는 이미 cocos2d-iphone을 사용하여 개발된 앱이 100개 이상 있었습니다.
iPhone App Store에서 1등에 도달한 첫 번째 앱은 Stick Wars입니다. 

Stick Wars: The first cocos2d-iphone game to reach #1 at the iPhone App Store

그 후 많은 cocos2d-iphone 게임이 1위를 차지했습니다.
그리고 대부분의 시간 동안 Top 10에는 적어도 하나의 cocos2d-iphone 게임이 있었습니다.
저는 이것이 2009년부터 2011년 말까지의 사례라고 생각합니다.

cocos2d-iphone은 게임은 뿐만 아니라 애니메이션 책, 사진 응용 프로그램 등을 만들 수 있었습니다.
일부 cocos2d-iphone 게임과 응용 프로그램은 WWDC 2010에서 선보였습니다.
Apple이 자랑스럽게 "Apple 라이브러리를 사용하여 제작한" 게임이라고 설명했으며, 실제로도 cocos2d-iphone으로 제작되었습니다. 

WWDC 2010. Steve Jobs presenting Elements, a cocos2d-iphone application

많은 cocos2d-iphone forks/ports/bindings도 생성되었습니다.
* 적어도 2개의 자바로 포팅된 프로젝트: cocos2d-android and cocos2d-android-1
* C++로 포팅된 프로젝트 : Cocos2d-x
* 2개의 자바스크립트로 포팅된 프로젝트: Cocos2d-HTML5 and Cocos2d-JavaScript
* C#으로 포팅된 프로젝트: CocosNet, Cocos2d-XNA, CocosSharp
* Go로 포팅된 프로젝트: Gocos2d
* Python로 바인딩, 포팅된 프로젝트
* Ruby로 바인딩된 프로젝트: ShinyCocos and support for RubyMotion

2011년 7월, cocos2d-iphone을 3년 이상 사용해본 것과 커뮤니티의 도움을 받아 cocos2d-iphone v1.0을 출시했습니다.
통계 : ~140명의 컨트리뷰터, ~2600개의 커밋 및 63개의 내부 릴리즈.

cocos2d-iphone v1.0 was released in July 2011

많은 사람들이 서로 돕고, 버그 보고서를 열며, Pull Request를 보내고, 기능을 제안하는 등 커뮤니티는 매우 건강했습니다.
cocos2d-iphone을 둘러싼 생태계도 매우 건강했습니다. 많은 cocos2d-iphone 서적이 출판되었고,
많은 편집자 / 도구 (상업용 및 무료 / 오픈 소스 모두)가 cocos2d-iphone을 지원했습니다.
많은 회사가 cocos2d-iphone 개발자를 찾고 있었습니다.

2011년 5월 저는 Zynga에 입사했습니다. Zynga의 일부 iOS 게임에는 cocos2d-iphone을 사용했습니다.
그들을 Android로 이식하기 위해 AndEngine을 사용하여 일부를 다시 작성하고
다른 것들은 AppPortable의 Objective-C/UIKit 스택을 사용하여 이식했습니다.


2012년에 Android는 이미 강세였습니다. 저는 안드로이드를 기본적으로 지원하고 싶었습니다.
(그리고 다른 플랫폼에서도), 3가지 옵션이 있었는데,
1. cocos2d-iphone 개발을 중단하고 Cocos2d-x (the C++ fork) 개발.
2. cocos2d-iphone을 계속 개발하고 Android 용 Cocos2d-iphone을 포팅할 수 있도록 타사 상용  Objective-C 스택 (StellaSDK, NoodleCake 또는 AppPortable 등)을 사용.
3. cocos2d-iphone을 계속 개발하고 cocos2d-iphone을 Android에 포팅하는 오픈 소스 Objective-C 스택을 개발.

저는 써드파티 상용 툴에 의존하기를 원하지 않았고, Objective-C 스택을 작성할 시간이 없었습니다.
Cocos2d-x는 이미 인기가 있었습니다. 그래서 Cocos2d-x 팀을 돕기로 결정했습니다.
우리는 Zynga에서 Cocos2d-x를 사용하기 시작했습니다. 

2012, at Zynga. With Rolando Abarca and Zhe Wang discussing Cocos2d-x’s and cocos2d-iphone’s roadmaps.

Zynga에서 Cocos2d-x 팀의 도움을 받아 우리는 매우 매력적인 툴링 개발했습니다.:
* Cocos2d-x 및 cocos2d-iphone은 기능 호환이 가능합니다. API는 거의 동일했습니다 (물론 C++과 Objective-C 중 하나)
* Viktor Lidholt가 만든 CocosBuilder에는 Scene 에디터, 키 프레임 애니메이션 에디터, JavaScript 스크립팅 등 많은 유용한 기능이 포함되어 있습니다.
* CocosBuilder에서 내보낸 Scene은 cocos2d-iphone과 Cocos2d-x에서 모두 사용할 수 있습니다.

CocosBuilder editor

유일한 단점은 Cocos2d-x와 cocos2d-iphone 간에 기능 호환을 유지하는 것이 비용이 많이 들었기 때문에
이를 해결하기 위해 기능을 두 번 작성해야 한다는 것입니다.
또한 CocosBuilder는 cocos2d-iphone을 기반으로 만들어졌기 때문에 Mac 용 (Windows 버전 없음)에서만 사용할 수 있었으며
이것도 기능을 두 번 작성해야했습니다. Windows 지원은 많은 Cocos2d-x 사용자에게 중요했습니다.

저는 2013년 6월까지 cocos2d-iphone을 계속 개발했고,
그다음에 Lars Birkemose (2016년에 Andrei Volodin에게 다시 전달)에 그 성화를 전달했습니다.
2013년 8월에 나는 Chukong에 입사했습니다.

Cocos2d-x 

Note: Cocos2d-x와 Cocos Studio 뒤에 있는 Chukong은 베이징에 본사를 두고 있는 중국 회사입니다.
Cocos Studio는 베이징에서 개발되었습니다.
Cocos2d-x는 Xiamen (중국 남부)에서 개발 중입니다.
우리는 모든 것을 다했기 때문에 캘리포니아 사무실에 합류했습니다.

Cocos2d-x는 2010년 7월 Zhe Wang에 의해 시작되었습니다.
이것은 cocos2d-iphone의 복제본이었지만 Objective-C 대신 C++로 코딩되었습니다.
그의 목표는 cocos2d-iphone 게임을 uPhone (나중에 취소된 phone 프로젝트)으로 포팅하는 것을 용이하게 하는 SDK를 만드는것이 었습니다.
이식을 용이하게 하기 위해 Cocos2d-x에는 cocos2d-iphone에서 발견된 모든 Objective-C 패턴이 포함되었습니다. 2012년쯤에 (또는 2011 년) Cocos2d-x팀이 Chukong에 합류했습니다.
Chukong은 Cocos2d-x를 세계적 수준의 게임 엔진 / tooling으로 만드는 자원, 의지 및 위치를 확보했습니다.
2013년 Cocos2d-x는 중국 시장 점유율의 약 70%~80%를 차지했습니다.

Chukong에서 우리는 코드에서 Objective-C 패턴 제거, 최신 C++ API 사용, 렌더러 업데이트 (Nite), 3D 기능 추가 (Tony 및 Harrison) 등
Cocos2d-x v3을 설계하고 프로그래머 가이드 문서 작성 (Jason)을 했습니다.

그러나 가장 중요한 것은 에디터였습니다. 우리에게는 에디터가 필요했습니다. Chukong은 Cocos Studio에 많은 리소스를 투자했습니다.
그것은 많은 특징을 가지고 있었지만 UX는 미국/서구 시장에 호소력이 없었으며 Windows에만 있었습니다.

그래서 미국 지사에서 Justin, Nite, Kai는 Cocos2d-x 편집기를 처음부터 개발 시작하여 중국 및 미국/서양 시장을 목표로 했습니다.
(CocosBuilder와 유사하지만 Cocos2d-x 및 Windows 및 Mac과 호환되는 Qt가 이 용도로 사용되었습니다.)

At Beijing, with Hao Wu, Shun Lin, Harrison, Zhe Wang, Nite Luo, Justin Graham.

불행히도 새 에디터는 취소되었습니다. 우리가 Cocos Studio의 UX를 향상 시키려고 노력했지만, 미국/서구 시장을 유치하지 못했습니다. 

Mac version of Cocos Studio with an improved UX

Cocos2d-HTML5 v4, Cocos2d-x v4 렌더러 + HAL, Cocos2d-x 런처, Cocos IDE와 같은 다른 프로젝트도 취소되었습니다.
Cocos Studio조차 취소되었습니다. 

At Xiamen, with Zhe Wang, Ibon Tolosana and Kai Zhao. November 2014

특히 프로젝트가 거의 완료되어가는 중에 프로젝트가 취소되면 실망할 수 있습니다. 그러나 우리의 주요 과제는 훌륭한 비즈니스 모델을 찾는 것이었습니다.
우리는 다른 것을 시도했지만 좋은 것을 찾지 못했습니다.

뒤늦은 시야에서, 이것들은 우리가 해야 한다고 생각한 것들입니다.
* 하나의 에디터에서 작업하세요: Qt 에디터는 Cocos Studio를 대체해야합니다.
* 데이터 내에서 SDKBOX 및 기타 서비스를 제공해야 합니다.
* Focus : 캐주얼/미드 코어 기능 (VR 또는 기타 산만 기능 제외)에서만 동작합니다. 그 범주에서 가장 좋은 것이 되도록 노력해야 합니다.

Cocos2d에서 9년을 일한 후 최근 사건이 발발하여 다른 일을 할 시간이 되었습니다.
다음에 저는 무엇을 해야 할까요? 어떤 사람들은 미래가 IoT라고 말하고 또 다른 사람들은 기계 학습이라고 말하고 나머지는 VR/AR이라고 말합니다. 그들은 모두 잘못되었습니다. 미래는 Commodore 64입니다. See you soon.

Cocos2d-x, Xcode 9에서 빌드시 에러

이번에 Xcode가 버전 업데이트 되면서 Cocos2d-x 빌드할 때 에러가 발생합니다.
에러의 내용은 다음과 같습니다.

platform/CCFileUtils.cpp, line 1429: Call to unavailable function 'system': not available on iOS

이 에러를 처음 접하고나서 저게 무슨 에러인데? 하고 바로 검색해보았죠.
그럼 누군가가 먼저 이슈를 만들어 놓았는데 이 이슈입니다.
GitHub Issue: https://github.com/cocos2d/cocos2d-x/issues/17907

그리고 나서 금방 고쳐졌죠. 하지만 3.15.1 버전에는 포함되어 있지 않은 상태에서
에러가 생기는 바람에 GitHub에 있는 PR을 보고 수정해야합니다.

PR: https://github.com/cocos2d/cocos2d-x/pull/17921

간단하게 CCFileUtils.cpp 파일만 수정해주면 됩니다. 약 30줄 정도 수정해주면 됩니다.

파일보기: https://github.com/cocos2d/cocos2d-x/pull/17921/files
수정된 부분을 잘 추가해주시면 빌드가 잘 되는 것을 볼 수 있습니다.

3.16 버전에는 수정되서 업데이트될 예정인데요.
3.16 버전은 9월 30일이라고 합니다. 이번 업데이트는 어떤 내용이 있을지 릴리즈 노트 나오기전에
한번 훑어봐야겠습니다.

그럼 이만 마치겠습니다.
Thanks.

Cocos2d-x의 개발방향, 현재 상태, 적합성 등에 대한 분석

제가 앱을 개발하는데에 사용하는 Cocos2d-x에 대해 그동안 생각해보지 못한게 있었고,
그부분을 정리하고자 글을 적어봅니다.
플랫폼, 엔진 등을 프로젝트 개발에 사용하기위해 고려되어야하는 부분이 몇 가지 있다고 생각합니다.

- 참고할 자료가 많은가 (책, 커뮤니티)
- 업데이트가 주기적으로 되는가 (살아있는 프로젝트인가)
- 사용하고자 하는 플랫폼, 엔진에 대한 기본적인 이해 (적어도 도메인 지식에 대한 이해)
- 만들고자하는 프로젝트에 적당한 엔진인가 (2D, 3D, 게임 종류 등등에 대한 고려)
- 개발 방향, 로드맵은 어떻게되는가

크게는 이렇게 보고 Cocos2d-x 는 어떻게 프로젝트를 진행하고 있는지, 내가 만드는 앱에 적합한지를
확인해보고자 합니다.

참고할 자료가 많은가

프로젝트를 개발하면서 정보를 얻을 일이 많습니다. 예를 들면, 내가 개발한 코드에 문제가 생긴 상황에서 보통 구글에 검색을 하죠.
하지만 검색해도 결과가 안나온다면? 혼자 삽질을 많이 하게 되겠죠.
그래서 참고할 자료가 웹 상에 많은지, 커뮤니티가 있는지,
커뮤니티가 있더라도 그 안에 정보 업데이트가 잘 되는지를 봐야합니다. (질문을 했는데 답이 없으면 커뮤니티가 있더라도 소용 없으니까요.)

구글에서는 Cocos2d-x 로 검색하면 많은 결과를 얻을 수 있습니다.
물론 좀 생소한 이슈를 검색하면 중국어 OR 일본어 자료를 볼 수 있습니다. 이 부분은 번역기로 극복..!

Cocos2d-x 는 커뮤니티가 있습니다. (다행히)
http://discuss.cocos2d-x.org/ 이 커뮤니티는 영어지만.. 번역기를 잘 돌려서 질문만 한다면 어느정도
원하는 답변을 얻을 수 있습니다. (영어 잘 하시는분은 그냥 질문을..!)
어느정도 답변을 해주는 편이기도 해서 일단은 자료를 얻을 수 있어서 다행입니다.

우리나라 커뮤니티는 네이버 카페 Cocos2d-x 사용자모임(http://cafe.naver.com/cocos2dxusers)
최근에 글이 올라오지 않는 것으로 보아 우리나라에서는 Cocos2d-x 사용자는 점점 줄어드는 것으로
보입니다. (추측이지만 Unity로 넘어가는 것으로 보입니다.)

그 외에 스택오버플로우에서 많은 문제를 확인할 수 있으며
엔진의 버그도 Cocos2d-x GitHub 이슈나 PR에서 확인할 수 있어서
자료(정보)에 대한 걱정은 덜어도 괜찮을 것 같네요.

Youtube에는 Sonar Systems 강좌도 있습니다.
https://www.youtube.com/playlist?list=PLRtjMdoYXLf4od_bOKN3WjAPr7snPXzoe

문제는 영어...

아, 추가적으로 책도 몇 권 있습니다.
- 시작하세요! Cocos2d-x 프로그래밍
- Cocos2d-x 3 모바일 게임 프로그래밍
- 등등..
최신 업데이트 사항은 포함되어 있지 않지만 한글 자료도 많습니다.

업데이트가 주기적으로 되는가

Cocos2d-x 는 업데이트가 보통 3-4개월 또는 급한 업데이트는 버그 픽스 버전업으로 올라옵니다.
최근 버전은 3.15.1 버전으로 3.15 버전 업데이트 후 버그가 있어 업데이트한 버전 입니다.



릴리즈 업데이트 말고 다른 지표들을 보겠습니다.





'코드의 변화도', '한 달동안 머지된 PR', '이슈들이 어떻게 처리되고 있는가'에 대한 이미지입니다.
중간에 코드 변화도가 크게 올라가 있는데 이 부분은 v2 -> v3 으로 메이저 버전업이 있었을 때
코드의 변화가 컸기 때문입니다.
2016년 이후로는 큰 변화 없이 개발되고 있습니다. 주로 버그 수정 및 로드맵에 따라 개발되고 있는데,
밑에서 Cocos2d-x는 어떤 로드맵으로 개발되고 있는지 더 살펴보겠습니다.
(사실 어떤 로드맵으로 개발되고 있는지 잘 모르겠어요...)

사용하고자 하는 플랫폼, 엔진에 대한 기본적인 이해

기본적으로 Cocos2d-x로 C++, Lua, Javascript 3가지 언어로 게임을 개발할 수 있습니다.
처음에는 C++, Lua로 개발할 수 있었는데, 웹으로도 만들 수 있게 Javascript도 지원하기 시작한지
1년 정도된 것 같습니다.
Cocos2d-x 는 맨 처음 Cocos2d로 시작된 프로젝트인데 크로스플랫폼 엔진 프로젝트로 전환,
지금까지 진행되어 왔습니다.


[Cocos2D - Objective C로 개발하던 프로젝트]

글쓰면서 찾게된 python으로 개발할 수 있는 Cocos2d 도 있네요.
http://python.cocos2d.org/index.html

이야기를 하다보니 Cocos2d 의 히스토리를 살짝 훑어보고 가도 될 것 같지만
일단 본론으로 돌아가겠습니다. (나중에 한번 정리해서 다른 포스트로..!)

https://en.wikipedia.org/wiki/Cocos2d 위키를 보면 세 종류의 프로젝트가 있는데
제가 사용하고 있는 것은 Cocos2d-x, 크로스 플랫폼을 위한 프로젝트입니다.

Cocos2d-x 엔진에 대해 알 수 있는 문서들이 많이 있어서 정리해보겠습니다.
- 기본 개념 문서: http://cocos2d-x.org/docs/programmers-guide/basic_concepts/
- API 문서: http://cocos2d-x.org/docs/api-ref/index.html
- PDF 문서: http://www.cocos2d-x.org/docs/ProgrammersGuide.pdf

그 외에 알 수 있는 내용은 많지만 전체적으로는 C++ 개념이 크게 작용한 엔진입니다.
(+Objective C 개념)

만들고자하는 프로젝트에 적당한 엔진인가

저는 주로 Cocos2d-x를 2D 게임 만드는데에 사용하고 있습니다.
3D 게임에는 그다지 맞지 않는 느낌이 들지만 기능으로는 지원하고 있습니다.
(앞으로도 계속 개발해서 지원하려는 움직임이 보이기도 합니다.)

Sprite라는 개념을 사용하고 2D 게임으로 가볍게 개발할 수 있는 엔진으로
고성능의 게임도 개발할 수 있겠지만 개인적으로는 2D, 2.5D 수준으로 끝낼 수 있는 프로젝트가 적당하다고 생각합니다.

3D는 언리얼이나 유니티가 다 잡고 있기에 그렇기도 하구요.
언리얼이나 유니티보다 기본적으로 가볍고 쉽게 만들 수 있다는게 비교적 장점인 것 같습니다.
(C++이 쉽지 않은게 단점)

개발 방향, 로드맵은 어떻게되는가

추가적으로 Cocos2d-x의 개발 로드맵은 어떤지 한번 확인해봤습니다.
https://trello.com/b/Np6obnuE/cocos2d-x-roadmap



최종 수정일이... 2017년 2월 15일이네요.
업데이트가 되고 있지 않습니다. (지금 개발 버전은 3.16 버전인데 그에 대한 내용도 없네요)

최근에는 Cocos Creator를 밀고 있는 것 같습니다.
유니티처럼 에디터에서 개발할 수 있게 툴을 만들고 있는데, C++은 지원하지 않고
Javascript만 지원하고 있습니다. (CoffeeScript도...)

음... 다른 프로젝트는 로드맵이 있는지부터 확인을 해봐야겠습니다.
유니티 프로젝트는 어떤지 한번 보겠습니다.
https://unity3d.com/kr/unity/roadmap

유니티는 각 기능(이슈) 별로 리스트를 만들고 관리를 하고 있네요.
2017 버전이 나오면서 어떤게 업데이트가 되었는지, 앞으로 어떤 업데이트가 있는지는
찾아보고 있지만 찾기 힘드네요.

음... 일단은 비교는 했습니다만 Cocos2d-x 로드맵이 관리가 안되고 있다가 결론이네요.
현재는 잘 사용하고 있지만 Cocos2d 그룹에서 어떻게 개발이 진행되고 있는지,
로드맵은 어떤지에 대해 이야기해봐야겠습니다.
(현재 상태가 나쁘지는 않지만 어떤 방향으로 개발하고 있는지 잘 모르겠네요.)

이상 개인적인 분석글이었습니다.
긴 글 읽어주셔서 고맙습니다 :)

PS. 틀린부분이 있다면 가감없이 이야기해주세요. 수정하겠습니다.

책 리뷰, 핵심 C++ 표준 라이브러리

핵심 C++ 표준 라이브러리

라이너 그림 저 / 류광 역

“전문 C++ 프로그래머라면 알아야 할 C++ 표준 라이브러리의 핵심을 담은 책”

『핵심 C++ 표준 라이브러리』는 독자가 C++ 표준 라이브러리의 주요 구성요소를 간결하게 훑어보고 참조할 수 있는 요약 참고서이다. C++ 자체에 익숙한 독자라면 이 책의 장점을 최대로 누릴 수 있을 것이다. C++에 익숙하지 않은 독자라면 먼저 C++ 언어의 핵심 내용에 관한 책을 충분히 익힌 후, 이 책을 통해서 한층 더 높은 수준으로 발돋움할 수 있을 것이다. 이 책은 독자의 학습 편의를 위해 이론과 실제를 연결해 주는 짧...

평소에 C++에 관심도 많고 C++ 이용한 프로젝트들도 많이해서 살까 싶었던 책이었습니다.
최근에 리뷰어 이벤트를 하길래 신청했는데 당첨되어서 즐겁게 읽고 있지요 ㅎㅎ
(전에 샀던 책 중에 Effective Modern C++ 이라는 책이 있는데 그 책도 류광님이 번역한 책이더군요.)

이 책에서 다루는 내용은 C++ 표준 라이브러리에는 무엇이 있는가 입니다.
C++ 11, C++ 14 에서 표준으로 사용되는 라이브러리를 다루고 있는데
책을 읽으면서 저는 "아, 내가 학교에서 배우고 지금 사용하고 있는 스타일을 보면 C++11 보다는 낮은 스타일을 사용하고 있구나"하고 느꼈습니다.

책의 내용을 나눠서 보자면,
1. C++11, C++14 표준 라이브러리 소개 및 팁.
2. C++17 표준 라이브러리 소개.

표준 라이브러리 소개 및 팁에서는
- 각 기능의 사용법.
- 이런 기능을 사용할 때의 주의점과 팁.
- 그리고 성능.

C++17 표준 라이브러리 소개는 부록에 있는데,
이 내용은 원서에는 없는 내용이다. 번역서에만 있는 내용이라고 하네요.
C++17은 현재 draft 상태지만 올해 3월에 동결되었다고 하며 옮긴이의 정리글입니다.
주로 소개하고 있는 내용은 아래와 같습니다.

• 문자열에 대한 비소유 참조, std::string_view
• 없을 수도 있는 값을 나타내는 std::optional
• 아무 형식이나 담을 수 있는 std::any
• 형식에 안전한 공용체, std::variant
• 파일 시스템 라이브러리,
• 알고리즘의 병렬화
• 새로 추가된 알고리즘, for_each_n, sample, reduce, transform_reduce, ...
• 기타 변경 사항

책을 다보고 내용을 다 머릿속에 넣을 수는 없었지만 책장에 두고 개발하면서 꺼내볼만한 책입니다.
주로 사용하는 vector나 string, list, map 말고 다른 기능들을 알 수 있어서 좋았습니다.
중간중간 사용해볼만한 라이브러리를 기억해두고 나중에 쓰기위해 포스트잇을 붙여뒀는데
이렇게 해두면 나중에 잘 찾아볼수 있겠죠?!

C++ 표준 라이브러리는 뭐가 있는지, 어떻게 사용해야할지 모르겠다면 한번 살펴보면 좋을 책입니다!

책 리뷰, 글로벌 소프트웨어를 꿈꾸다

글로벌 소프트웨어를 꿈꾸다

김익환 저

이 책은 실리콘밸리의 소프트웨어 회사와 국내 소프트웨어 회사의 차이점이 무엇인지 살펴보고, 그 차이점을 일으키는 것이 무엇인가에 대하여 이야기 하고 있다. 저자는 그것이 지식과 기술보다는 바로 '개발문화, 기업문화'에 있다고 말한다. 이 책에서는 세계 수준에 근접한 기술과 기법은 그에 걸맞은 균형 잡힌 사고와 문화 수준이 어우러질 때 극대화될 수 있다는 것을 극명하게 보여주고 있다. 따라서 이 책에서는 우리나라의 소프트웨어 회사가 어떻게 소프트웨어 회사로 성장할 수 있을 것인지 그 필요한 사항들을 세심히 짚어준다. 이 책은 특히...

"글로벌 소프트웨어를 말하다. 지혜" 편과 시리즈는 아니지만 그전에 나온 책입니다.
소프트웨어 회사에서 개발문화, 기업문화가 중요하다는 이야기, 개발자들도 어떤 방식으로 일을 해야하는가에 대해 접근합니다. 개발문화는 어떻게 생각하고 만들어가야하는가에 대한 생각을 정리할때 좋은 책입니다.

개인적인 감상은 조금 답답한 책이었습니다.
그 답답함의 이유는 책이 답답하다는 것이 아닌 상황을 바꾸기 힘든 요소들을 어떻게 고쳐나갈 것인가,
어떻게 좋은 개발문화, 기업문화를 만들 것 인가에 대한 답답함이었습니다.
정론을 말해주고 있지만 그 정론에 도달하기위해서는 많은 노력이 필요하고 끊임없이 닦아내야 할 것을 알기 때문일지도 모르겠습니다.

두고두고 보면서 개발문화의 방향을 생각해볼 수 있는 책입니다.

책 리뷰, 글로벌 소프트웨어를 말하다.

글로벌 소프트웨어를 말하다, 지혜

김익환 저

기후와 토양에 따라 귤이 되기도 하고, 탱자가 되기도 하듯이 지혜에 따라 글로벌 소프트웨어가 되기도 하고, 국내 소프트웨어로 머물기도 한다. 소프트웨어에 대한 근본적인 이해, 통찰력, 그것이 바로 지혜다. 국내를 넘어선, 글로벌 소프트웨어를 향한 지혜의 세계로 여러분을 안내한다.

주 내용
이 책은 제목에서 말하듯이 글로벌 소프트웨어를 만들고자 한다면 어떤 생각을 가지고
어떻게 개발해나가야 하는가에 대해 이야기한다.
우리나라에서 개발환경과 실리콘밸리에서의 개발환경의 차이점을 이야기하면서
우리나라에서 개발하기 힘든점 등을 이야기하고 이를 극복하기위해서 이렇게 해야한다 라는
방향성을 말하고 있다.

개인적으로는 이 책에서 하는 말이 다 맞는 말이라는 걸 알면서도 고치기 힘들어서 다시 그 길을 걸어가는게 어쩔 수 없다는 생각을 했다.
예를 들면 작은 소프트웨어들을 만드는 작은 회사에서 제품상세문서, 이슈 트래킹, 코드 리뷰 등을 다 할 수 없는 것 같지만 이 부분도 필자는 알고 있는 것 같다.
(하지만 이 문제는 글로벌 소프트웨어를 만들고 싶다면 꼭 해야한다는 점을 공감한다.)

개발자가 어떻게 생각하고 개발해야하는가 할 때 읽어보면 좋은 책이다.
개발 프로세스를 어떻게 잡아야하는지에 대한 자세한 내용은 없지만 어떤 방향으로,
어떻게 생각해서 개발해야한다는 알 수 있는 책이다.

개인적인 Gradle 공부

요즘 Gradle을 많이 보고 다룰 일이 생겨서 개인적으로 공부해보기로 했습니다.

Gradle, 그래들이라고 불리는 이건 뭘까요?
위키에는 뭐라고 써있는지 보겠습니다.

Gradle은 Groovy를 이용한 빌드 시스템이다. Groovy와 유사한 도메인 언어를 채용하였으며, 현재 안드로이드 앱을 만드는데 필요한 안드로이드 스튜디오의 공식 빌드 시스템이기도 하다. Java, C/C++, Python 등과 같은 여러 가지 언어를 지원한다.

한국 위키는 설명이 좀 부실하네요. 영문 위키가 더 자세히 잘 설명되어있습니다.
https://en.wikipedia.org/wiki/Gradle

그래들이 그루비를 이용한 빌드 시스템이라고 하는데 그럼 그루비는?
https://ko.wikipedia.org/wiki/%EA%B7%B8%EB%A3%A8%EB%B9%84

설명이 꽤나 길군요. 요약해보자면,

자바에 파이썬, 루비, 스몰토크 등의 특징을 더한 

동적 객체 지향 프로그래밍 언어

그래들은 이러한 특징을 가진 그루비를 기반으로 하는 언어를 사용한다고 합니다.
그리고 자바뿐만 아니라 다른 언어를 빌드하는데에도 많이 사용된다고 합니다만,
저는 안드로이드 빌드 때문에 Gradle을 공부하고 싶기때문에
안드로이드 빌드를 중심으로 보겠습니다.

제가 참고한 곳은 안드로이드 개발자 홈페이지 입니다.
https://developer.android.com/studio/build/index.html#detailed-build

빌드의 일반적인 흐름은 다음과 같습니다.

그래들은 이런 빌드 과정을 설정하고 자동화할 수 있도록 해줍니다.
종속성을 어떻게 관리할 것인지, 빌드를 하고 나서 어떻게 처리를 할 것인지,
배포 빌드, 테스트 빌드 등 설정을 할 수가 있습니다.

빌드 구성 파일의 구조는 아래와 같습니다.

제일 위에 있는 build.gradle은 프로젝트의 모든 모듈의 빌드 세팅을 정의합니다.

/**
 * The buildscript {} block is where you configure the repositories and
 * dependencies for Gradle itself--meaning, you should not include dependencies
 * for your modules here. For example, this block includes the Android plugin for
 * Gradle as a dependency because it provides the additional instructions Gradle
 * needs to build Android app modules.
 */

buildscript {

    /**
     * The repositories {} block configures the repositories Gradle uses to
     * search or download the dependencies. Gradle pre-configures support for remote
     * repositories such as JCenter, Maven Central, and Ivy. You can also use local
     * repositories or define your own remote repositories. The code below defines
     * JCenter as the repository Gradle should use to look for its dependencies.
     */

    repositories {
        jcenter()
    }

    /**
     * The dependencies {} block configures the dependencies Gradle needs to use
     * to build your project. The following line adds Android Plugin for Gradle
     * version 2.3.2 as a classpath dependency.
     */

    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.2'
    }
}
/**
 * The allprojects {} block is where you configure the repositories and
 * dependencies used by all modules in your project, such as third-party plugins
 * or libraries. Dependencies that are not required by all the modules in the
 * project should be configured in module-level build.gradle files. For new
 * projects, Android Studio configures JCenter as the default repository, but it
 * does not configure any dependencies.
 */

allprojects {
   repositories {
       jcenter()
   }
}

최상위 build.gradle은 프로젝트의 모든 모듈에 공통되는 gradle 저장소와 종속성을 정의하기 위해 buildscript {} 블록을 사용합니다.

모듈 레벨 빌드파일도 한번 보겠습니다. 보통의 안드로이드 앱 프로젝트라면,
project/app/build.gradle 파일을 말합니다.

/**
 * The first line in the build configuration applies the Android plugin for
 * Gradle to this build and makes the android {} block available to specify
 * Android-specific build options.
 */

apply plugin: 'com.android.application'
/**
 * The android {} block is where you configure all your Android-specific
 * build options.
 */

android {

  /**
   * compileSdkVersion specifies the Android API level Gradle should use to
   * compile your app. This means your app can use the API features included in
   * this API level and lower.
   *
   * buildToolsVersion specifies the version of the SDK build tools, command-line
   * utilities, and compiler that Gradle should use to build your app. You need to
   * download the build tools using the SDK Manager.
   */

  compileSdkVersion 25
  buildToolsVersion "25.0.3"

  /**
   * The defaultConfig {} block encapsulates default settings and entries for all
   * build variants, and can override some attributes in main/AndroidManifest.xml
   * dynamically from the build system. You can configure product flavors to override
   * these values for different versions of your app.
   */

  defaultConfig {

    /**
     * applicationId uniquely identifies the package for publishing.
     * However, your source code should still reference the package name
     * defined by the package attribute in the main/AndroidManifest.xml file.
     */

    applicationId 'com.example.myapp'

    // Defines the minimum API level required to run the app.
    minSdkVersion 15

    // Specifies the API level used to test the app.
    targetSdkVersion 25

    // Defines the version number of your app.
    versionCode 1

    // Defines a user-friendly version name for your app.
    versionName "1.0"
  }

  /**
   * The buildTypes {} block is where you can configure multiple build types.
   * By default, the build system defines two build types: debug and release. The
   * debug build type is not explicitly shown in the default build configuration,
   * but it includes debugging tools and is signed with the debug key. The release
   * build type applies Proguard settings and is not signed by default.
   */

  buildTypes {

    /**
     * By default, Android Studio configures the release build type to enable code
     * shrinking, using minifyEnabled, and specifies the Proguard settings file.
     */

    release {
        minifyEnabled true // Enables code shrinking for the release build type.
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
  }

  /**
   * The productFlavors {} block is where you can configure multiple product
   * flavors. This allows you to create different versions of your app that can
   * override defaultConfig {} with their own settings. Product flavors are
   * optional, and the build system does not create them by default. This example
   * creates a free and paid product flavor. Each product flavor then specifies
   * its own application ID, so that they can exist on the Google Play Store, or
   * an Android device, simultaneously.
   */

  productFlavors {
    free {
      applicationId 'com.example.myapp.free'
    }

    paid {
      applicationId 'com.example.myapp.paid'
    }
  }

  /**
   * The splits {} block is where you can configure different APK builds that
   * each contain only code and resources for a supported screen density or
   * ABI. You'll also need to configure your build so that each APK has a
   * different versionCode.
   */

  splits {
    // Screen density split settings
    density {

      // Enable or disable the density split mechanism
      enable false

      // Exclude these densities from splits
      exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi"
    }
  }
}
/**
 * The dependencies {} block in the module-level build configuration file
 * only specifies dependencies required to build the module itself.
 */

dependencies {
    compile project(":lib")
    compile 'com.android.support:appcompat-v7:25.3.1'
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

제가 보통 보는 블록은 defaultConfig, buildType, dependencies 정도인 것 같네요.

splits나 productFlavors를 잘 사용하면 무료, 유료 앱 따로 빌드하기나 

화면 해상도에 따른 빌드 설정을 각각해줄 수 있을 것 같네요.

그리고 추가적으로, 빌드할 때 필요한 설정을 가지고 있는 파일들이 있습니다.

- gradle.properties: 프로젝트 범위의 그래들 설정을 함. 예, gradle daemon 힙 크기 설정

- local.properties: 빌드 시스템의 로컬 환경을 구성. 예, sdk, ndk 경로 설정

뭔가 간단한 앱을 만들때는 build.gradle 파일을 많이 수정할 일이 없었는데

모듈을 만들어서 붙이고, 다른 플러그인도 같이 사용하게되면

종속성이나 여러가지 신경써야할 포인트가 많은 것 같습니다.

이 포스트를 시작으로 책도 좀 보고 더 깊게 공부해봐야겠습니다.

Gradle의 GitHub 주소를 남기고 글 마치겠습니다.

https://github.com/gradle/gradle

Google Analytics Update!

https://analytics.googleblog.com/2017/04/effortless-analytics-new-google.html

OpenGL ES 버전 2.0과 3.0 차이(1)

Cocos2d-x 버전 차이에 대해서 공부하던 중에 그 기반이 되는 OpenGL ES의 버전에도
큰 차이가 있지 않을까하여 공부해봤습니다.

우선 OpenGL ES란, (Wikipedia-ko)

OpenGL ES (임베디드 단말을 위한 OpenGL)는 크로노스 그룹이 정의한 3차원 컴퓨터 그래픽스 API인 OpenGL의 서브셋으로, 휴대전화, PDA 등과 같은 임베디드 단말을 위한 API이다.

한글로 작성된 위키는 짧군요.
영어로 작성된 위키를 더 보겠습니다. (Wikipedia-en)

OpenGL for Embedded Systems (OpenGL ES or GLES) is a subset^[2] of the OpenGL computer graphics rendering application programming interface (API) for rendering 2D and 3D computer graphics such as those used by video games, typically hardware-accelerated using a graphics processing unit (GPU). It is designed for embedded systems like smartphones, computer tablets, video game consoles and PDAs. OpenGL ES is the "most widely deployed 3D graphics API in history".^[3]The API is cross-language and multi-platform. The libraries GLUT and GLU are not available for OpenGL ES. OpenGL ES is managed by the non-profit technology consortium Khronos Group. Vulkan, a next-generation API from Khronos, is made for simpler high performance drivers for mobile and desktop devices.^[4]

설명에 큰 차이는 없지만, API에 대한 설명에는 크로스 랭귀지, 멀티 플랫폼이 들어가있습니다.
OpenGL에서 사용할 수 있는 GLUT, GLU는 OpenGL ES에서는 사용할 수 없다. 정도네요.

각 버전별 설명도 잘 나와있는 영문 위키를 보면,

OpenGL ES 2.0
OpenGL ES 2.0 was publicly released in March 2007.^[6] It is based roughly on OpenGL 2.0, but it eliminates most of the fixed-function rendering pipeline in favor of a programmable one in a move similar to transition from OpenGL 3.0 to 3.1.^[7] Control flow in shaders is generally limited to forward branching and to loops where the maximum number of iterations can easily be determined at compile time.^[8] Almost all rendering features of the transform and lighting stage, such as the specification of materials and light parameters formerly specified by the fixed-function API, are replaced by shaders written by the graphics programmer. As a result, OpenGL ES 2.0 is not backward compatible with OpenGL ES 1.1. Some incompatibilities between the desktop version of OpenGL and OpenGL ES 2.0 persisted until OpenGL 4.1, which added the GL_ARB_ES2_compatibility extension.^[9]

OpenGL ES 3.0

The OpenGL ES 3.0 specification^[10] was publicly released in August 2012.^[11] OpenGL ES 3.0 is backwards compatible with OpenGL ES 2.0, enabling applications to incrementally add new visual features to applications. OpenGL 4.3 provides full compatibility with OpenGL ES 3.0. Version 3.0 is also base of WebGL 2.0.^[12]

New functionality in the OpenGL ES 3.0 specification includes:

• multiple enhancements to the rendering pipeline to enable acceleration of advanced visual effects including: occlusion queries, transform feedback, instanced rendering and support for four or more rendering targets,
• high quality ETC2 / EAC texture compression as a standard feature, eliminating the need for a different set of textures for each platform,
• a new version of the GLSL ES shading language^[13] with full support for integer and 32-bit floating point operations;
• greatly enhanced texturing functionality including guaranteed support for floating point textures, 3D textures, depth textures, vertex textures, NPOT textures, R/RG textures, immutable textures, 2D array textures, swizzles, LOD and mip level clamps, seamless cube maps and sampler objects,
• an extensive set of required, explicitly sized texture and render-buffer formats, reducing implementation variability and making it much easier to write portable applications.

(참고, http://www.informit.com/articles/article.aspx?p=2181697&seqNum=2)

음, 각각 살펴보고 정리해보겠습니다.

OpenGL ES 2.0을 먼저 살펴보면,
2007년 3월에 출시되었습니다. OpenGL 2.0을 기반으로 하지만 OpenGL 3.0에서 3.1로 업데이트 될 때와 비슷하게 고정 렌더링 파이프라인을 제거하였습니다. 셰이더의 제어 흐름은 컴파일할 때에 쉽게 결정할 수 있는 순방향 분기, 루프로 제한됩니다.
이전에 고정 함수 API에 의해 지정된 재질 및 조명 매개 변수와 같은 변형 및 조명 스테이지의 거의 모든 렌더링 기능은 그래픽 프로그래머가 작성한 쉐이더로 대체되었습니다. 따라서 OpenGL ES 2.0은 OpenGL ES 1.1과 호환되지 않습니다. OpenGL과 OpenGL ES 2.0 데스크톱 버전 간의 일부 비 호환성은 GL_ARB_ES2_compatibility 확장을 추가 한 OpenGL 4.1까지 지속됩니다.

OpenGL ES 3.0은 어떨까요.
OpenGL ES 3.0 사양은 2012년 8월에 공개되었습니다. OpenGL ES 3.0은 OpenGL ES 2.0과 하위 호환되므로 응용 프로그램이 응용 프로그램에 점진적으로 새로운 시각적 기능을 추가할 수 있습니다.
OpenGL 4.3은 OpenGL ES 3.0과 완벽한 호환성을 제공합니다.
버전 3.0은 WebGL 2.0의 기반이기도합니다.
새로운 기능은 아래와 같습니다.

• 오클루전 쿼리, 변환 피드백, 인스턴스 렌더링 및 4개 이상의 렌더링 대상에 대한 지원을 비롯하여 고급 시각 효과를 가속화 할 수 있도록 렌더링 파이프 라인에 대한 여러 가지 향상된 기능을 제공합니다.
• 고품질 ETC2/EAC 텍스처 압축을 표준 기능으로 지원하여 각 플랫폼에 다른 텍스처 세트가 필요하지 않습니다.
• 부동 소수점 텍스처, 3D 텍스처, 깊이 텍스처, 정점 텍스처, NPOT 텍스처, R/RG 텍스처, 불변 텍스처, 2D 배열 텍스처, 스위즐, LOD 및 밉 레벨 클램프, 매끄러운 큐브 맵 및 샘플러 객체에 대한 보장된 지원을 포함하여 크게 향상된 텍스처링 기능을 포함합니다.
• 명시적으로 크기가 필요한 텍스처 및 렌더링 버퍼 형식의 광범위한 세트로, 구현 변동성을 줄이고 모바일 앱을 훨씬 쉽게 개발할 수 있습니다.

구글 번역기의 도움을 받아 해석해봤는데, 전반적으로 기능, 성능향상이 있어보입니다.
퍼포먼스 테스트 자료가 있으면 좋겠는데.. 없네요. 한번 테스트를 해봐야겠습니다.

OpenGL ES 버전 차이가 어떤가에 대해 개괄적인 내용이었지만
렌더링 방식, 텍스처 처리방식, 버퍼 크기등에 대한 차이가 있었네요.
다음 글에서는 성능 차이에 대한 이야기를 해보겠습니다.