Comments 18
Вот в заключении очень бы хотелось перечисления более удачных фреймворков. Кокос на хабре уже упоминался неоднократно, остальные как-то то ли редко, то ли вскользь. Кто какие щупал, отпишитесь, сэкономите другим начинающим гейдвелоперам время.
А игру покажете?
А я сейчас рассматриваю возможность использования cocos2d-x поверх marmelade для следующего проекта (для замены самопального фреймворка). Кто-нибудь может про него чего нибудь хорошего/плохого сказать?
Фреймворк достаточно хороший. Используем его для игр и интерактивных книг. Но в больших проектах нужно хорошо разбираться как он устроен внутри, т.к. есть и баги, и не совсем очевидные места.
А зачем вам при работе с cocos2d-x нужен marmelade?
А зачем вам при работе с cocos2d-x нужен marmelade?
Чистый cocos2d-x в отличии от мармелада оборачивает только графику и ввод, и то не полностью. Потом мармелад позволяет полностью абстрагироваться от конкретной платформы. Например, с ним я разработал, оттестил и выпустил iOS приложение на PC с Windows. Понятно, что тестилось все на настоящем железе, но возможность в один клик откомпилировать приложение для десятка платформ — очень ценная вещь для разработки кроссплатформенных игр. Но мармелад — это низкоуровневая платформа, в графике немногим выше чистого OpenGL, по этому и присматриваюсь, чего бы поверх запустить, а то поддержка своего фреймворка занимает слишком много времени, а качество и гибкость оставляет желать лучшего (писалось под конкретную задачу, а потом пришлось выдумывать костыли, чтобы поддерживать более широкий спектр задач).
Для меня главное преимущество мармелада — это абстрагирование от графической системы (может использовать как opengl es, так и soft-рендеринг). Но cocos2d-x не использует графическую библиотеку мармелада, а всегда вызывает opengl es 1.2. Поэтому преимущество теряется.
Какие еще полезные для игр абстракции дает мармелад?
Свои приложения мы тоже разрабатываем и отлаживаем на PC с Windows под Visual C++.
Какие еще полезные для игр абстракции дает мармелад?
Свои приложения мы тоже разрабатываем и отлаживаем на PC с Windows под Visual C++.
Я так понял, что сцену можно представить себе как View Controller, а слой как View. Не знаю насколько такая модель точна, но я думаю примерно так. Слои содержать вроде как индекс, это значит их можно накладывать один на другой.
Если движок не дружит с коллектором, то вообще нет смысла его использовать. Кто захочет рубиться в игрушку с простоянными тормозами
Похоже вы плохо понимаете различие между Objective-C и Java.
>> Поле _rotate или любое другое поле класса.
В ObjC есть свойства, в Java их нет. Когда в ObjC вы пишите
это на самом деле превращается в вызов сеттера:
Т.к. в java свойств нет — все обращения к ним нужно менять вызовы геттеров и сеттеров.
>> Слой не отображается на экране. В практике использования данного фреймворка существует такая схема создания сцены
В ObjC в статических методах переменная self указывает на класс (в вашем случае MainScene). В коде метода node объект этого класса и создается ([[self alloc] init]).
В Java нельзя узнать в статическом методе класс для которого он был вызван. Поэтому код в методе node (return new Layer()) создает всегда объект класса Layer, хотя и был вызван для MainScene.
Нужно или переопределять статический метод node() для всех ваших наследников от Layer, или не использовать его, а всегда пользоваться конструкторами.
>> Поле _rotate или любое другое поле класса.
В ObjC есть свойства, в Java их нет. Когда в ObjC вы пишите
node.rotate = 10это на самом деле превращается в вызов сеттера:
[node setRotate:10]Т.к. в java свойств нет — все обращения к ним нужно менять вызовы геттеров и сеттеров.
>> Слой не отображается на экране. В практике использования данного фреймворка существует такая схема создания сцены
В ObjC в статических методах переменная self указывает на класс (в вашем случае MainScene). В коде метода node объект этого класса и создается ([[self alloc] init]).
В Java нельзя узнать в статическом методе класс для которого он был вызван. Поэтому код в методе node (return new Layer()) создает всегда объект класса Layer, хотя и был вызван для MainScene.
Нужно или переопределять статический метод node() для всех ваших наследников от Layer, или не использовать его, а всегда пользоваться конструкторами.
Различия я прекрасно понимаю. Было много времени узнать тонкости этого чудо языка. Нужно было портировать максимально похоже(задача такая стояла) — я портировал, а когда были какие-то траблы — разбирался почему и как. И собственно описал их здесь, в топике.
Если капнуть в теорию, то статический метод не может иметь доступ к экземпляру. А в обж-си self — просто паттерн, используемый повсеместно. То бишь смысл вашего заключения мне не ясен, так как именно конструктором я и пользовался.
Если капнуть в теорию, то статический метод не может иметь доступ к экземпляру. А в обж-си self — просто паттерн, используемый повсеместно. То бишь смысл вашего заключения мне не ясен, так как именно конструктором я и пользовался.
А исходная игра какой фреймворк использовала?
Sign up to leave a comment.
Сказ о Cocos2d-android