Typo: Oryol will *not* require threading to hide blocking operations. Am Donnerstag, 10. April 2014 11:00:54 UTC+2 schrieb Floh: > > 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.
