Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Minko - Flash Conference #5

16,962 views

Published on

Published in: Technology, Art & Photos
  • Be the first to comment

Minko - Flash Conference #5

  1. 1. Flash Online Conference #5 Targeting mobiles, WebGL and Stage3D... with a single app! @Minko3D http://minko.io
  2. 2. LATEST ADDITIONS Available today on minko.io
  3. 3. New Editor Features  Dynamic framerate  Multi-selection  First-person camera mode  New layer WYSIWYG interface  Integration of CrystalATF – 6 to 9x faster ATF conversion – Only for texture loading in the editor, not yet for publishing  Minor bug fixes…
  4. 4. New Framework Features  Support for 4096 textures  Context-loss handling  Compatibility with 2D frameworks (Starling…)  Minor bug fixes…
  5. 5. New Community Features  Better search engine for the forum  Already existing threads suggestions when your create a new one – Avoid asking questions that have already been answered  Discussions feed available directly from the blog’s right column
  6. 6. New Game Released: IronForce  Published by EA/Chillingo – http://www.chillingo.com/games/iron-force/  Tank MMORPG – Already available on iOS – Available soon on Android
  7. 7. New Game Released: IronForce
  8. 8. « We chose Minko to be the 3D engine in one of our new Flash-based games because we think it’s a highly professional Stage3D based solution in terms of development ecosystem and high performance. » André Weissflog, Head of Development at BigPoint
  9. 9. MINKO 3 Codename « Normandie »
  10. 10. Motivations  Target new platforms – Keep the « design once, deploy everywhere » workflow – Larger community  Increase performances, epecially CPU-wise – Multi-threading?  Leverage existing codebase
  11. 11. New Platforms Platform Status Target Languages iOS OK Native C/C++ Android OK Native C/C++ Flash (Stage3D) WIP X-Compilation C/C++, AS3 Windows (DirectX) WIP Native C/C++ Mac OK Native C/C++ Windows (OpenGL) OK Native C/C++ Linux OK Native C/C++ HTML5 (WebGL) OK X-Compilation C/C++, Javascript Windows Phone WIP Native C/C++ BlackBerry 10 NA Native C/C++ Firefox OS NA Native C/C++
  12. 12. Current status Feature Status Comments Signals 100% Scene Graph 90% Assets loading, scene manipulations, signals, layers Post-Processing 30% Effects/Shaders 100% Vertex/fragment shaders, effects parser, render to texture, multi-pass Über shaders 80% Init. OK, but won’t fork automatically afterward Dynamic lights 100% Ambient, directional, point and spot lights Dynamic shadows 50% Particles 90% Missing some modifiers Physics 90% Missing joints, triangle collider and heightmap collider MK files parser 80% Missing compression JPEG parser 100% PNG parser 100% Collada parser NA OBJ parser NA
  13. 13. About Collada and OBJ  Might be supported in the future as a plugin using the ASSIMP project  Still supported in the editor to be exported as MK – Smaller files – Faster to load – More features (physics, particles…)
  14. 14. TECHNOLOGICAL CHOICES
  15. 15. WebGL  In the browser implementation of the OpenGL API – Based on the specifications of OpenGL ES2 (like Stage3D!)  Supported by most modern browsers – Supported by IE11 next year!  Not as fast as Stage3D – But that’s another story…
  16. 16. 53% WebGL 96% Flash WebGL VS Stage3D - Penetration Rate Firefox 4+, Chrome 9+ Any browser with Flash 11+ Source: Statcounter
  17. 17. ? WebGL 96% Flash WebGL VS Stage3D – HW Compatibility * * 2006 and newer hardware, software fallback otherwise
  18. 18. WebGL => Flash Fallback!  Start working with standards today, but keep adressing the largest audience possible Is WebGL available ? Run WebGL/JS app. Run Flash app. no yes
  19. 19. C++ 2011  Standard, fast, well documented and supported by a vast community  Already fully supported by all major compilers (VS, GCC, LLVM…)  New additions make it closer to what we’re used to with AS3/Javascript – Closures/lambda functions – Type inference (instead of dynamic typing) – Shared pointers
  20. 20. FlasCC/Crossbridge http://adobe-flash.github.io/crossbridge/  Open source project driven by Adobe – Based on LLVM, which is supported by Google, Apple, Intel and many more  Cross-compiles C++ code to ActionScript 3.0 – No (stable) OpenGL bindings – Provides virtual file system – C++  AS3 bindings using SWIG  Leverages LLVM/C++ based optimizations – Strong typing – Low level memory management: no GC!  Still suffers from AS3/AVM2 performance issues
  21. 21. Emscripten https://github.com/kripken/emscripten  Open source project driven by Mozilla – Based on LLVM, which is supported by Google, Apple, Intel and many more  Cross-compile C++ code to Javascript code – Binds OpenGL to WebGL – Provide virtual file system – C++  Javascript bindings  Code optimizations – Closure compiler – asm.js (2x performances of native code!)  Code compression using LZMA
  22. 22. ANGLE https://code.google.com/p/angleproject/  Almost Native Graphics Layer Engine  Open source project driven by Google – Used by Chrome and Firefox WebGL implementations  OpenGL wrapper that will map OGL calls to the DirectX API – Provide better performances on Windows – Makes it possible to target DirectX with an OpenGL based implementation – Should provide Windows Phone 8 compatibility out of the box  Also converts GLSL shaders to HLSL – Completely transparent to the developer! – Write once, deploy everywhere
  23. 23. Premake http://industriousone.com/premake  Cross-platform build system – Windows, Mac and Linux – Reference in the video game industry – Well documented  Compatible with most IDEs/tools – gmake – Visual Studio – XCode  Easy to extend and customize – Based on LUA script configuration files – Adding support for emscripten was easy
  24. 24. Vagrant http://www.vagrantup.com/  Goal: easily cross-compile without installing/configuring complicated stuff  Virtualized build environment – Based on VirtualBox – Will install and bootstrap everything for you – Will auto-update itself to make sure you always use the latest stable toolchain  We provide the configuration file to compile to HTML5/WebGL in just a single command line! – Ubuntu virtual machine – Uses Premake4 + gmake – Will do the same for Flash/Crossbridge
  25. 25. IMPLEMENTATION
  26. 26. AbstractContext  Mimics flash.display3D.Context3D interface – Leverages Adobe’s work on wrapping DirectX/OpenGL – Mainly uses simple native types (int, float…) to make it easier to wrap/bind in multiple languages  Defines all you need to work with OpenGL ES 2-compliant APIs – Enforces compatibility – Can be extended to provide more « custom » capabilities if you want AbstractContext OpenGLES2Context WebGLContext
  27. 27. OpenGLES2Context  Extends AbstractContext  Implement all required methods using the OpenGL API  Actually uses OpenGL bindings, but limited only to what is actually available in OpenGL ES 2 – Should work out of the box with any OpenGL ES 2 compliant implementation – But also on any OpenGL implementation (ex: Windows, Mac and Linux) AbstractContext OpenGLES2Context WebGLContext
  28. 28. WebGLContext  Extends OpenGLES2Context – Actually inherits more than 95% of its code  Override a few methods to handle some minor WebGL qirks – Some methods do not work properly/exist and have to be wrapped using (simple) workarounds AbstractContext OpenGLES2Context WebGLContext
  29. 29. NEW FEATURES
  30. 30. Components  Goal: provide an extensible API to add behaviors to scene nodes with concepts shared by artists and developers  Replace « controllers » – Scene nodes just describe a hierarchy – Components add behaviors  One scene one can have multiple components – Ex: the scene node of a torchlight can have a component for the mesh and a component for the actual light source
  31. 31. Components – Ex: Directional Light  The Transform component is not mandatory – Scene nodes do not necessarily have a 3D transform: lighter and more customizable – Yet our directional light is pointless without a configurable direction…
  32. 32. Components – Ex: Camera  Our camera has 3 components: – Transform will make our Camera position/orientation customizable – PerspectiveCamera will provide actual camera related data to the rendering API – Renderer will do the actual DrawCall storage/frame rendering
  33. 33. GLSL  Support for GLSL 1 as defined by the OpenGL ES 2 standard – Vertex shaders – Fragment shaders  Implementation could easily support earlier/more powerful versions of GLSL – Gives you the ability to leverage extended hardware capabilities when available!  Vast codebase, tutorials and various documentation articles available on the web
  34. 34. Shader Optimizer  Open source project created by Unity – Used by default since Unity 3 – Based on Mesa’s GLSL compiler open source implementation  Provides significant performance boost on mobile GPUs – Compensate the lack of proper drivers on both iOS and Android  Completely transparent to the user: you don’t have to do anything – JIT optimizations  Not working with WebGL (yet!)
  35. 35. Effects  Data-driven API to create rendering effects – Everything defined in JSON data files – Loaded natively by the core framework – Interact seemlessly with the scene and the existing assets/effects  Create even the most complicated effects without a single line of C++ code – Only GLSL and some flags/properties to setup – Support every rendering states/properties you might need: blending, filtering, render target, etc… – Both rendering and post-processing – Techniques and fallbacks (WIP)  Dependencies injection to create libraries of re-usable GLSL shader functions – Ex: Phong.glsl gives you everything you need to implement Phong lighting
  36. 36. Effect Bindings  Goal: copy/paste existing GLSL code and « plug it » in the engine without a single shader code modification  Declare « links » between effect/shader « properties » and what is actually provided by components in the scene – Uniforms – Vertex Attributes – Macros  Makes it possible to have macros that will be defined only if some scene/component properties actually exist – Uber shaders!
  37. 37. CROSS-COMPILATION WORKFLOW
  38. 38. MinkoMinko Sources Compilation C++ app. code Plugins C++ Code Physics Particles JPEG Parser PNG Parser MK Parser Core framework C++ code Plugins Static Libraries Physics Particles JPEG Parser PNG Parser MK Parser Core framework static library App. object file ASM.js Javascript code C++ 2011 code
  39. 39. Linkage Minko Plugins Static Libraries Physics Particles JPEG Parser PNG Parser MK Parser Core framework static library App. object file application.js
  40. 40. Optimization  Run the closure compiler on the generated Javascript code application.js application_optimized.js
  41. 41. Workflow - Compression  Use LZMA compression – Emscripten will embed LZMA decompression code all by itself – Decompression can be watched when the app. runs application.js application_compressed.js
  42. 42. EXAMPLE: SPONZA HTML5! http://minko.io/showcase/sponza-html5
  43. 43. My Feedback – The Good Parts  Working with C++ 2011 is amazing – More complex but so much powerful/expressive than AS3/JS – Useful and reliable STL containers (list, maps, sets, etc…) – Shared pointers make memory management just as easy as with managed languages: not a single memory leak so far!  Visual Studio/XCode are very good IDEs  Minko 3’s implementation is much lighter and yet just as much powerful  Vagrant + Premake provides an efficient build system with cross-compilation
  44. 44. My Feedback – The Good Parts  Compatibility – The app runs on Windows, Mac, Linux and WebGL withouth a single modification! – Haven’t tested iOS/Android yet, but should work out of the box  Binary size – Closure compiler will make the binary 2 to 3x lighter – LZMA compression will make the binary 5 to 6x lighter – Combine both to get a final binary even lighter than the native one!  Speed – 2x speed of native code thanks to asm.js! – Possiblity much faster than an AS3 implementation  Integration – Emscripten « modules » system make it easy to generate a *.js file and run it in any web page
  45. 45. My Feedback – The Bad Parts  Workflow – Haven’t figured out how to make dynamic libraries for now  Speed – WebGL API is the bottleneck   Memory consumption – 256MB of required memory seems excessive (I haven’t make a comparison with AS3 so far though…)  I miss the Flash API – How do to a 2D UI using HTML5 comps? – URLRequest?
  46. 46. Conclusion  C++ 2011 is very efficient to build interactive and rich apps  Emscripten is mature enough to start working on large-scale applications  Using #ifdef for portability of C++ code is a bit cumbersome – But it can easily be fixed by wrapping the app. init  Minko 3 – Alpha in september – Beta in december – Final release in April 2014
  47. 47. MERCI ! Don’t forget to check http://minko.io !

×