Minko - Flash Conference #5
2 likes17,185 views
The document discusses updates to the Minko 3D game engine, including new editor features, framework features, and community features. It provides details on a new game released using Minko called IronForce, and outlines Minko's goals for targeting new platforms like iOS, Android, and HTML5 while increasing performance. Technological choices like C++, Emscripten, ANGLE, and Premake are presented. Implementation details cover areas like components, GLSL, effects, and a cross-compilation workflow.
Minko - Flash Conference #5
- 1. Flash Online Conference #5 Targeting mobiles, WebGL and Stage3D... with a single app! @Minko3D http://minko.io
- 2. LATEST ADDITIONS Available today on minko.io
- 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. New Framework Features Support for 4096 textures Context-loss handling Compatibility with 2D frameworks (Starling…) Minor bug fixes…
- 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. 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. New Game Released: IronForce
- 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. MINKO 3 Codename « Normandie »
- 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. 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. 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. 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…)
- 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. 53% WebGL 96% Flash WebGL VS Stage3D - Penetration Rate Firefox 4+, Chrome 9+ Any browser with Flash 11+ Source: Statcounter
- 17. ? WebGL 96% Flash WebGL VS Stage3D – HW Compatibility * * 2006 and newer hardware, software fallback otherwise
- 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. 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. 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. 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. 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. 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. 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. IMPLEMENTATION
- 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. 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. 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. NEW FEATURES
- 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. 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. 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. 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. 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. 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. 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!
- 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. Linkage Minko Plugins Static Libraries Physics Particles JPEG Parser PNG Parser MK Parser Core framework static library App. object file application.js
- 40. Optimization Run the closure compiler on the generated Javascript code application.js application_optimized.js
- 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
- 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. 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. 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. 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. MERCI ! Don’t forget to check http://minko.io !