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] <javascript:>>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] <javascript:>. >> 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.
