Yes I'm aware of Minko3 :) It's interesting how we're all converging around emscripten while coming from different directions (Minko from AS/Flash, us more traditional PC client games, and the big AAA engines from the console business...
Cheers, -Floh. Am Freitag, 11. April 2014 14:41:07 UTC+2 schrieb Warren Seine: > > Hey Andre, > > I'm sure you already know that, but it does sound a lot like Minko > 3<https://github.com/aerys/minko>:) I think you're especially right about (3) > and we should investigate how > to improve loading with pseudo-intelligent streaming. Big worlds are coming > with VR and this will make a difference. > > On Thursday, April 10, 2014 11:00:54 AM UTC+2, Floh wrote: >> >> Ok, couple of points that I have in mind: >> >> (1) Min-spec will have to be OpenGLES2 and WebGL (1), which is quite >> different from modern desktop GL or console graphics APIs. While GLES3 and >> WebGL2 will close the gap a bit, I think that it's still important to >> support GLES2 for a while. Of course I still want to be able to do the >> fancy desktop-level stuff, so I'm thinking about a material system and >> rendering pipeline which is flexible enough that one can switch between >> different renderers (like forward renderer for weak GPUs vs different kinds >> of deferred renderers) without having to rewrite all material shaders for >> instance (so the shader system will have to be modular, and separate >> between a renderer-backend-specific part and a material-specific-part - >> that's nothing really new of course). Such a flexible system will also make >> it easier to experiment with new rendering effects. >> >> (2) I want to keep the compiled client small at all cost (1..3 MByte >> compressed for real games at most), so it's important to have a build >> system which lets one pick-and-choose what features to use, and not >> compile-in unused features (for instance, N3 has a dynamic object system >> where objects can be created by a class-FourCC-code or string-class-name, >> it cannot know beforehand what objects will be instantiated at runtime, and >> thus must "cheat" the dead-code-elimination, and force code to be linked >> which may or may not be used at runtime. >> >> (3) IO system designed for "random-access" on-demand streaming through >> HTTP, I want to keep startup time as small as possible, besides keeping the >> client itself small, this also means not downloading big asset bundles >> upfront. Instead the engine must be able to stream all data on demand and >> be able to handle the case when the data is not yet available yet. >> >> (4) Different threading strategy: I formerly used threads for 2 use >> cases: to hide blocking (so a blocking operation would run in a thread), >> and to spread work over additional CPU cores. Oryol will require threads to >> hide a blocking operation, instead use completion-callbacks and/or >> completion-polling for asynchronous operations. To spread work to >> additional cores there will be a parallel-task system which can either work >> completely on the main-thread and do its work in little slices, or move the >> work over to a worker-thread, or use pthreads. >> >> (5) Mobile GL and WebGL (also NaCl) seem to have a much higher >> call-overhead into GL then a native desktop GL implementation: >> https://github.com/bkaradzic/bgfx#17-drawstress, this will have >> influence the rendering features that make sense for a WebGL/mobile engine. >> If something requires a massive amount of draw calls, it probably won't be >> implemented in Oryol. The dilemma ist that techniques to reduce GL calls >> are either only implemented in modern desktop GL, or in extensions which >> are often not available in GLES2, Angle and WebGL. >> >> That's all I can think of for now :) >> -Floh >> >> Am Mittwoch, 9. April 2014 23:06:14 UTC+2 schrieb Alon Zakai: >>> >>> I'm curious, what are the design considerations that make this >>> specifically targeted at web and mobile? That is, what is different here >>> than existing engines? >>> >>> - Alon >>> >>> >>> >>> On Wed, Apr 9, 2014 at 12:05 PM, Floh <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> just wanted to let you guys know that I started a new "weekend-engine" >>>> a couple months ago, mainly as a sort of experimentation testbed of what a >>>> small C++11 3D-engine mainly built for web and mobile could look like: >>>> https://github.com/floooh/oryol >>>> >>>> Progress will be slow since it's a spare-time project, but one thing >>>> that will be useful (IMHO) in the short term is a growing list of samples >>>> which demonstrate and test specific, isolated features: >>>> http://floooh.github.io/oryol/ >>>> >>>> I think these samples will be useful for reporting, testing and >>>> tracking regression bugs in various browsers in the future (I learned that >>>> this is a bit complicated with relatively big engine demos like the >>>> Nebula3 >>>> demos, because it's hard to create isolated test cases). >>>> >>>> Cheers, >>>> -Floh. >>>> >>> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
