attila wrote:
MistaED wrote:
Very nice attila! Are you using any of my code changes or is it entirely independent?
Thanks!
It is independent but I used your ES_Test branch as a reference(PVR texture loading/uploading,...).
I used a slightly different approach : I'm using macros to handle the differences between the OpenGL and OpenGL ES. It is a bit ugly, but I hope it will be easy to synchronize with the main branch.
I just now see that you have a new version at
https://bitbucket.org/boberfly/horde3d-es2. Great work!
So you have to make different versions for 4 cpp/h. It's great much of the GLish code is in egRendererBase and utOpenGL now, but egRenderer still has some gl code mainly for setting rasterizer and blend states. We should move it somehow into egRendererBase. It would make a D3D11(or any other nonGL) port much more easier.
MistaED wrote:
Are they the same shadowmaps generated in Horde3D mainline or are they modified to work fast on iOS? It also looks like you're using something similar to the HDRI pipeline too, impressive!
I'm using horde3d's shadowmap, but modified the generation to support directional light. It is not optimized except that it is not pcf, only one sample per pixel.
The pipeline is not really HDR. The rendertarget is rgba8, only the envmaps are hdr (encoded into a rgba8 texture) and there is a simplified version of the bloom posteffect in the pipeline.
Nice to see it being used, hehe. I took your macro approach somewhat now and stuffed it into utOpenGL.h as well as a recent gl2ext.h (one example the blitting is interesting, the EXT version of it takes a bazillion function attributes while the APPLE one doesn't take any, so that is macro'd away). I've got KTX and preliminary CRN support on there, they might help if you want to support DXTC/ETC1 on android but I haven't tested the CRN code fully yet with mipmaps, and PowerVR's SDK doesn't output 100% compliant KTX files so I needed to comment out a few things to make them work but it seems to be the best container for everything, it uses the enums from GL headers to tell what format it is as opposed to storing what the format is in the FOURCC like dds or has it's own enum list like pvr (it already supports PVRTCv2, now it just needs a driver and hardware to support it!). I've been playing with google's ANGLE lib recently and that seems to work from some tests I've made in preparation for an eventual NaCl port.
I do agree that egRenderer needs all ties with GL to be removed, I think there's only one or two lines changed between desktop GL2 and GLESv2 at the moment. DX11 or even moving to OpenGL 3.x+GL4 extensions is exciting, and perhaps a utOpenCL.cpp/h and an egCompute.cpp/h would be really cool, perhaps for accelerating deferred lighting/shading and skinning/morphs for starters, and GLESv3 will most likely support this sort of stuff as well. Need to talk to Marciano/Volker on what they've got planned.
Login
Wiki
FAQ
Search
