IrrNaCl - Irrlicht port for Google Native Client

[codetiger]

Success !!!

After 15 days of tough work, IrrLicht finally proved it again. Even someone who's new to IrrLicht and with no experience in a completely new platform, he can port it to run with less than 30 lines of code change. 15 days looks too much but it look me that long mostly to understand NaCl and IrrLicht's drivers.



I didn't setup a debugging system coz it wasn't easy on windows, and this was my first proof of work. Not even a printf worked without setting up a complicated debugging setup.

[Nadro]

This is great info. I have some delay with an iOS support, but when I done it I'll want merge Your code with an official Irrlicht branch, but I have one question . Is Your code compatible with Irrlicht license?

[codetiger]

@Nadro
I am yet to finish Filesystem changes for Irrlicht to load resources from the server. It might take a couple of days to complete. I am first planning to make Sydney wave her hands, then I've to clean my code before you can merge all together. My code which is much less than 0.1% is my contribution to Irrlicht. I am not considering it as separate project or license. Earlier, me and my team were contributing to iSGL3D game engine for iOS and now we moved to IrrLicht to go cross-platform. Now our contributions will go to IrrLicht.

[hybrid]

Looks like your last changes changed the line breaks or something. At least github now shows everything changed, I couldn't see the small diffs anymore.
For changes to the Filesystems it might be a good idea to factor those things out and derive a new filesystem for special purposes in case the changes are not simply adaption of the POSIX methods. Otherwise we get too many ifdefs in all those files.

[codetiger]

Oh, I didn't notice that out of enthusiasm. I was very eager to share my work. But to summarize the changes:
1. COGLES2Driver: I've removed any glcontext initialization and egl functions. Now, the PPAPI wrappers for gl contexts are initialized in the nacl main file. So there is obsolutely no big difference in driver.
2. Shader loading: I've embedded all shader file data into the source as char* just to avoid passing the shaders everytime through NaCl file servers.
3. Filesystem: I'll stick to similar idea of creating CNaClBundleReader which was done by pervious NaCl Port.

[link3rn3l]

excellent progress .. is possible that you include a beginners pack similar to
ogre nacl pack .. to compile examples in a simple .bat including .lib .so dependencies..


thx again..!!!!

[codetiger]

Thanks for the support. Am just back from a couple of days vacation and starting on the development work today. Right now, am starting on the filesystem support, once that is ready, the project will be usable. Once the project is usable I'll try to maintain a beginners pack.

[link3rn3l]

progress?? XD XD XD

[codetiger]

I am bit busy with some deliverable, and planning to start on the file system part again in a week. Am sure, it should not take more than a day to fix it.

And am just back from health problems. So, my progress is pretty slow.

[link3rn3l]

i hope you feel better soon.

[codetiger]

Thanks for your kind words.

Progress Update:
1) Like I said before, I was working on Pepper_18 version until now. However, people from the NaCL discussion forum, have instructed me to move to the latest versions 20 or 21 for better support.
2) I was working on implementing "Quake NaCL port" style filesystem earlier, but the team has now recommended to use NaCL-Mount based filesystem released in the newer versions.

So guys, its real pain in adding file system support. And I'll be a bit late.

Other than file system, the rest seems to be working perfect. I just tested getting mouse events, keyboards events etc.

[Nadro]

Thanks for still working on it. This will be really nice addition for Irrlicht

[codetiger]

Am working on optimizing the Game loop for NaCL. NaCL has a tough restriction that, all Opengles calls should be made from the main thread. My previous versions was event based rendering, based on Tumbler example in NaCL SDK, then I realized IrrLicht requires live rendering.

Now, I've implemented a renderer, that works on the main thread. The problem I've is, the renderer works perfect on the first frame, then the sceneNodes disappear in the following frames. Am wondering if this is something related to swapbuffer call. Let me know if this problem sounds familiar for someone.

[codetiger]

Progress Update:
a) I've fixed the rendering loop problem. Am using a swapbuffer callback to create a rendering loop in main thread.
b) Am able to load files in posix file i/o calls. I've also modified creadfile.cpp to use posix style calls. I've to fix some bugs.
c) After long struggle I've found a way to read Debugging log using JavaScript
d) Like I said earlier, am using 4073 build Opengl ES branch. I've some problem in shaders. I tried loading shaders built-in, into the cpp (COGLES2SLMaterialRenderer.cpp) file as string. But am getting the following error.

Code: Select all

 
DEBUG_POSTMESSAGE:Irrlicht Engine version 1.8.0-alpha
DEBUG_POSTMESSAGE:GL_CHROMIUM_resource_safe GL_CHROMIUM_resize GL_CHROMIUM_strict_attribs GL_CHROMIUM_rate_limit_offscreen_context GL_CHROMIUM_set_visibility GL_CHROMIUM_discard_framebuffer GL_CHROMIUM_command_buffer_query GL_CHROMIUM_copy_texture GL_CHROMIUM_texture_mailbox GL_ANGLE_translated_shader_source GL_CHROMIUM_gpu_memory_manager GL_CHROMIUM_webglsl GL_EXT_texture_compression_dxt1 GL_CHROMIUM_texture_compression_dxt3 GL_CHROMIUM_texture_compression_dxt5 GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_EXT_read_format_bgra GL_OES_rgb8_rgba8 GL_OES_texture_npot GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_CHROMIUM_framebuffer_multisample GL_OES_standard_derivatives GL_CHROMIUM_stream_texture GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_usage GL_EXT_texture_storage GL_EXT_occlusion_query_boolean GL_ANGLE_instanced_arrays GL_CHROMIUM_swapbuffers_complete_callback GL_CHROMIUM_map_sub GL_CHROMIUM_flipy GL_CHROMIUM_consistent_uniform_locations testirrnacl.html:23
DEBUG_POSTMESSAGE: GL_EXT_unpack_subimage
DEBUG_POSTMESSAGE:Shader file Name: COGLES2FixedPipeline.vsh
DEBUG_POSTMESSAGE:Shader file Name: COGLES2FixedPipeline.fsh
DEBUG_POSTMESSAGE:Unable to find uniform : uhea]iDcn
DEBUG_POSTMESSAGE:Unable to find uniform : uhri0Ltet[uhpn]iCf]mnluhgaimnMrEs
DEBUG_POSTMESSAGE:Unable to find uniform : uhpn]iCf]mnluhgaimnMrEs
DEBUG_POSTMESSAGE:Unable to find uniform : uht[uiCriiueli
DEBUG_POSTMESSAGE:Unable to find uniform : uelcaih
DEBUG_POSTMESSAGE:Unable to find uniform : uelnCrelsxe
DEBUG_POSTMESSAGE:Shader file Name: COGLES2Renderer2D.vsh
DEBUG_POSTMESSAGE:Shader file Name: COGLES2Renderer2D.fsh
DEBUG_POSTMESSAGE:Shader file Name: COGLES2NormalMap.vsh
DEBUG_POSTMESSAGE:Shader file Name: COGLES2NormalMap.fsh
DEBUG_POSTMESSAGE:Shader file Name: COGLES2ParallaxMap.vsh
DEBUG_POSTMESSAGE:Shader file Name: COGLES2ParallaxMap.fsh
DEBUG_POSTMESSAGE:GLSL shader program failed to link
DEBUG_POSTMESSAGE:Fragment varying _varLightColor does not match any vertex varying
DEBUG_POSTMESSAGE:Error linking fixed pipeline shader program.
DEBUG_POSTMESSAGE:Error: Could not load built-in Font. Did you compile without the BMP loader?
 

[hybrid]

Well, the uniform names look rather suspicious. Seems like either the read back fails completely or the shader that was uploaded is somehow scrambled. You may need to insert more debug outputs and checks into the shader setup. We are checking rather many things there already (as it's a highly fragile process), but maybe not all things. No other idea, sorry, looks like a very dedicated problem for this combination of tools.