Interesting! - Alon
On Thu, Apr 10, 2014 at 2:40 AM, Floh <[email protected]> wrote: > 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. > -- 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.
