CodeFest 2013. Белый И. — Marmalade SDK. Что под капотом?
•Download as PPTX, PDF•
0 likes•1,049 views
Recommended
Recommended
More Related Content
Similar to CodeFest 2013. Белый И. — Marmalade SDK. Что под капотом?
Similar to CodeFest 2013. Белый И. — Marmalade SDK. Что под капотом? (20)
More from CodeFest
More from CodeFest (20)
CodeFest 2013. Белый И. — Marmalade SDK. Что под капотом?
- 1. Marmalade SDK Что под капотом?
- 2. Marmalade SDK открытый и гибкий Черный ящик Альтернативные движки Доступны плагины с закрытым кодом Marmalade System Marmalade Доступны плагины с открытым кодом Модули Marmalade Модули с открытым кодом
- 3. Программный стек Marmalade: Устройства Типичное место, откуда обычно разработчик без Marmalade SDK начинает строить приложение Все устрйства/ОС разные и требуют от разработчика редизайна приложения для каждой конкретной платформы ОСДрайверыOpenGL ESУстройство
- 4. Marmalade Система Быстрый и эффективный доступ к API ОС, управление памятью и графической подсистемой устройства. Одинаковый набор API на всех поддерживаемых платформах Графика Кросс платформ. API Marmalade Система ОСДрайверыOpenGL ESУстройство
- 5. Стандартные C/C++ библиотеки Подавляющее большинство существующего С/С++ кода портируется сразу, с минимальными изменениями или без них вообще C/C++ стандартные библиотеки Графика Кросс платформ. API ОСДрайверыOpenGL ESУстройство Графика Кросс платформ. API Marmalade Система
- 6. Модули Marmalade Studio Marmalade Studio предоставляет стандартный набор модулей для быстрой разработки приложений “Marmalade Studio” C/C++ стандартные библиотеки ОСДрайверыOpenGL ESУстройство Графика Кросс платформ. API Marmalade Система
- 7. Интеграция модулей Выбирайте среди разнообразия сторонних модулей которые работают с Marmalade прямо «из коробки» Другие модули“Marmalade Studio” C/C++ стандартные библиотеки ОСДрайверыOpenGL ESУстройство Графика Кросс платформ. API Marmalade Система
- 8. Расширения Получайте доступ к платформенно зависимым функциям и коду, используя расширения Marmalade Выбирайте из набора предустановленных расширений или создавайте свои собственные используя EDK Платформ. расширения Другие модули“Marmalade Studio” C/C++ стандартные библиотеки ОСДрайверыOpenGL ESУстройство Графика Кросс платформ. API Marmalade Система
- 9. Ваше приложение Использовать модули Marmalade Studio, API партнерских проектов или получить доступ к низкоуровневым APIs напрямую – ваш выбор Платформ. расширения Код вашего приложения Другие модули“Marmalade Studio” C/C++ стандартные библиотеки ОСДрайверыOpenGL ESУстройство Графика Кросс платформ. API Marmalade Система
- 10. Концепции Marmalade: загрузчик ГрафикаЗагрузчик Кросс-платформенные API Платформенно зависимый загрузчик который компонуется с вашим приложением во время упаковки, чтобы создать платформенно зависимый установочный пакет Хранит платформенно зависимые реализации системы Marmalade для стандартного набора низкоуровневых API Приложения получают доступ к API напрямую или через набор высокоуровневых модулей Совсем крошечный дополнительный объем к вашему приложению, обычно около 400kb
- 11. Концепции Marmalade: бинарник приложения Кросс-платформенный, ОС-независимый пакет Содержит ваш код и дополнительные модули Компилируется в нативные инструкции CPU Неиспользуемый функционал выбрасывается. Приложение зря не раздувается Подтверждает, что 97% кода приложения – это идентичные инструкции CPU на всех устройствах Компонуется с платформенно зависимым загрузчиком на этапе упаковки для создания готового пакета приложения Marmalade поддерживает сборку под ARM, x86 или MIPS Бинарник приложения (s3e/s86 файл) Код вашего приложения Другие модули“Marmalade Studio” C/C++ std lib
- 12. Концепции Marmalade: Упаковка Нативное приложение(.ipa .apk .bar etc.) Ваши ресурсы Используйте инструмент упаковки чтобы скомпоновать бинарник вашего приложения, ресурсы и платформенно зависимый загрузчик для каждой из целевых платформ Бинарник приложения (s3e/s86 файл) Код вашего приложения Другие модули“Marmalade Studio” C/C++ std lib Платформ. расширенияГрафика Кросс платформ. API Marmalade Система
- 13. Упаковка проекта в Marmalade SDK iOS Loader iOS App GCC .mkb проект бинарник SCons Android App Android Loader Симулятор BlackBerry App Загрузчик BlackBerr y Инструмент упаковки MKB IDE MKB – Файл проекта Marmalade Система MKB – генерирует рабочий проект для IDE из MKB файлов IDE – Visual Studio или Xcode Scons – система сборки проектов без участия IDE GCC – Типичный компилятор для сборки под ARM, другие компиляторы используются для прочих архитектур Бинарник – собранное приложение, может запускаться в симуляторе или упаковываться для устройства
- 14. Ваше приложение: структура Операционная система Платформенная реализация Стандартные API Код приложения
- 15. C++ библиотеки LoadImage(const char* path) libpng Platform fopen LoadImage(const char* path) libpng Custom fopen Platform fopen Проблема: путь к файлу должен меняться в зависимости от платформы
- 16. Подмена функция в std lib LoadImage App Code fopen newlib _open glue fopen OS Поддержка 19 системных вызовов _exit close environ execve fork fstat getpid isatty kill link lseek open read sbrk stat times unlink wait write Ошибка линковщика: символ ‘fopen’ определен несколько раз
- 17. Прелинковка библиотек Перемещаемая линковка • ld –r Контроль видимости символов • -B reduce Вторая линковка к системным библиотекам prelink link Исполнимый файл Код приложения libpng newlib Библиотеки приложения Платформенные библиотеки Системные бибилотеки
- 18. Отделяем бинарник • Бинарник приложения полностью платформенно независим • Подключается к плаформенным библиотекам на этапе выполнения • Виртуальное окружение без дополнительных затрат производительности Загрузчик Динамическая подгрузка кода Библиотека приложения
- 19. Динамическая загрузка кода Бинарник формата ELF (Executable and Linkable Format) Global offset table Procedure linkage table .dysym .dynstr
- 20. Richer apps are Marmalade 200 St. John Street, London, EC1V 4RN United Kingdom e: bizdev@marmalademail.com www.madewithmarmalade.com
Editor's Notes
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- We’ve seen what Marmalade can do, and from a high level how it does it, but what is the Marmalade SDK?***At the very bottom we find the device specific layer, OS, device drivers, graphics capabilities. This is where a developer would normally start, and this is where the cross platform difficulties arise, each device has it’s own specific flavour for this layer.***“Marmalade System” – one of the two main components of Marmalade sits on top of this.Abstracts the low level functionality.C runtimeMemory managementDevice accessAccelerometer and other device featuresCameraStorageGraphics subsystems such as OpenGL ESCommon functionality is built against this low level API, this is where you can leverage existing code, internal or external. Because Marmalade offers a seamless layer on top of the common functionality, porting to it is an exercise in simplicity, many times the vast majority of existing C/C++ code ports directly with little to no changes. Marmalade takes care of making sure that when you call malloc or new, it’s actually the Marmalade System implementation that gets called. Typical modules that get ported at this level for use in multiple titles include….***Physics libraries***Scripting languages***Many others, databases, image processing, etc.Scaleform for integrated Flash support.***Github also hosts many, already ported open source libraries, ready for you to include into your projects.***“Marmalade Studio” – the second main component of Marmalade sits on top of this. Studio provides a common set of modules for rapidly developing high quality games.***2D and 3D gfx, networking, text and font handling, UI (native and custom), resource management etc. All the things you need to get started. All carefully crafted to provide common API’s that apply across platforms, providing much of the common code needed to get moving quickly.It’s worth noting that Studio is not a game engine, but rather the ingredients necessary for you to build your game engine in a cross platform way, or, as is often the case, port an existing game engine.Using Studio functionality abstracts implementation details at a higher level than System. For example, IwGX, the graphics module, allows you to perform common graphics functionality without consideration for the capabilities of the platform, does it have GLES, is it GLES1 or 2, do you need to fall back to a software renderer? All this is handled by the module, you just right the game.***On top of this you build your application.It’s important to realise that it’s you who decides which parts of Marmalade you use. You can choose to sidestep Studio altogether, and develop directly against the lower level System API that’s fine, you still get all the cross platform benefits.But…what if you need to go lower, what if you need access to some device functionality Marmalade doesn’t provide? As an example, suppose a device provider introduced a new API for in app purchase, not supported by Marmalade out of the box, and different for each platform, but you need it for your game, how do you do that?***
- Each layer talks to next layer down. Layers below need no knowledge of layers aboveOnce these layers are separated, they can be compiled independently.VM based languages use platform independent Byte code. VM provides common API.
- For C++, traditionally, can be done with libraries which are linked together.Using a standard library like libpng.We want intercept fopen because otherwise would have to vary “path” by platform(Or add profiling. Or add custom memory allocation routine for malloc).Don’t want to have to replace fopen() with my_fopen()How do we use custom fopen() ?
- Replacing fopen means changing our C standard library used by our compilerWhen using gcc or llvm we can use newlib as our C standard library (libc.a & libm.a & …)http://wiki.osdev.org/Porting_NewlibNewlibcan be compiled „stand alone” –meaningwithoutany platform specificcde.Thisiscommonlydone for „bare-metal” / „bareboard” targetsAll you need to support a set of 19 system calls that act as ‘glue’ between newlib and the OS
- Problem is we now have two libraries containing fopen – newlib & platforms – how to get the right one?Prelink application to newlib. This technique is commonly used to remove dependencies on 3rd party libraries by combining these dependencies into a single conglomerate libraryIt pulls in as many symbol definitions as it can (but doesn’t complain about undefined symbols)In XCode this is known as “Single-Object Prelink of static libraries”. Prelink is very fucking intimate thing for every particular platformWant to hide most symbols (such as our custom fopen) within library.Some symbols need to remain visible – such as the entry point for the applicationWe run “ld” again passing prelinked application library and platform library (loader).Platforms used this for are Sony PSP, Nintendo DS, LG TV (Linux based), etc.
- Linking at runtime we can reuse a single application binary. No need to rebuild for new platform.Bugs in application library are platform independent (can be debugged on any system).Moving to new platform, new bugs can only be in platform layer.We’re effectively creating a virtual environment for our application.We can take complete control of memory heaps, file system & add profiling metrics.
- Unlike many proprietary executable file formats, ELF is flexible and extensible, and it is not bound to any particular processor or architecture. This has allowed it to be adopted by many different operating systems on many different platforms. Such as Linux, BeOS, Symbian, Bada, PlayStation 2&3, Wii,The ELF file format is also used as a generic object and executable format for binary images used.The Windows analogue is PE – Portable Executable. Darwin it's Mach-OPosition Independent CodePosition independent code can be copied to any memory location without modification and then executed, unlike relocatable code which requires special processing by a runtime linker to make it suitable for execution at a given location.Global offset TableELF linkers support position independent code (PIC) through the GOT in each shared library. The GOT contains absolute addresses to all of the static data referenced in the program. The address of the GOT is normally stored in a register (EBX on x86 / r9 on ARM) which is a relative address from the code that references it.Procedure Linkage Table (PLT)Similar to how the GOT redirects any position-independent address calculations to absolute locations, the PLT redirects position-independent function calls to absolute locations.Apart from these two tables, the linker also refers to .dynsym, which contains all of the file's imported and exported symbols, .dynstr, which contains name strings for the symbols.http://www.symantec.com/connect/articles/dynamic-linking-linux-and-windows-part-one