These are exactly the same goals behind IMVU's new engine. :) We care a lot more about hardware compatibility, great performance, and reduced battery usage than we care about great visuals.
Sent from my iPhone > On Apr 10, 2014, at 2:00 AM, Floh <[email protected]> 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. > > -- > 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. -- 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.
