renderPrePassMgr.cpp related:
A) shifting .addFeature( MFT_XYZ); calls from ProcessedShaderMaterial::_determineFeatures to ProcessedPrePassMaterial::_determineFeatures
B) mimicking the "// set the XXX if different" entries from RenderMeshMgr::render in RenderPrePassMgr::render
C) fleshing out ProcessedPrePassMaterial::getNumStages() so that it shares a 1:1 correlation with ProcessedShaderMaterial::getNumStages()
D) causing inline void Swizzle<T, mapLength>::ToBuffer( void *destination, const void *source, const dsize_t size ) to silently fail rather than fatally assert if a source or destination buffer is not yet ready to be filled. (support for #customTarget scripted render targets)
Reflections:
A) removing reflectRenderState.disableAdvancedLightingBins(true); entries. this would otherwise early out from prepass and provide no color data whatsoever.
B) removing the fd.features.addFeature( MFT_ForwardShading ); entry forcing all materials to be forward lit when reflected.
C) 2 things best described bluntly as working hacks:
C1) when reflected, a scattersky is rotated PI along it's z then x axis in order to draw properly.
C2) along similar lines, in terraincellmaterial, we shut off culling if it's a prepass material.
Skies: scattersky is given a pair of rotations for reflection purposes, all sky objects are given a z value for depth testing.
I got this from looking at the code from the glew utility 'glewinfo' on my system it reported the following for GL_ARB_geometry_shader4: OK [MISSING]. This lead me to believe that there are two different ways of determining extensions. The first 'OK' seems to refer to the entrypoint existing while the second one seems to refer to the extension being available.
The difference is this:
The first OK comes from : GLEW_ARB_geometry_shader4 the global whereas the second 'MISSING' comes from glewGetExtension("GL_ARB_geometry_shader4"). By replacing the gglHasExtension I got the desired result.
We may want to implement some caching if we want to keep using GLEW perhaps?
Anyway I suggest this merely as a test, I'm not sure if this is a viable long-term solution.
* Explicitly request a GL 3.2 context
* Enable 'experimental' extensions on glew (This appears necessary to get glew to work with explictly set GL versions)
A lot of instances where some function args are not actually modified in any way, meaning that it is better for performance to convert them into const references. This prevents an additional copy, which can help performance.
Many places utilize post-incrementation with iterators, but it's better performance to use pre-incrementation.
Resolved by changing the iter++ instances to ++iter;
Many instances of a function or expression being used repeatedly, which can lower performance.
Fixed it in these cases by creating on local var, reference or pointer that's used instead.
- Updated to work with 0.5.x SDK
- Uses Oculus Rendering rather than PostFX
- Stereo rendering refactored so more rendering info is grabbed from the DisplayDevice
- Implements an Offscreen Canvas for in-game gui with oculus
- Message dialogs and metrics display can now go to the OffScreen Canvas (if oculus demo is setup correctly)
A snippet of example code:
UTF16 pszFilter[1024];
...
convertUTF8toUTF16((UTF8 *)mData.mFilters, pszFilter, sizeof(pszFilter));
Since the conversion function is expecting the third parameter to be the
length in 16-bit characters, *not* bytes, this results in the function
writing outside the bounds of the output array.
To make this less likely to happen in the future (I hope), I've provided a
template function that infers the correct size of a static array, so it's
no longer necessary to pass the size in most cases. The sized function has
been renamed with an "N" suffix to hopefully encourage this use.
This bug was caught due to a warning from MSVC about stack corruption
occurring in codeBlock::exec(), after opening a file open dialog twice in
succession. After some hunting, I found that this was due to
FileDialog::Execute() passing incorrect buffer sizes to the conversion
function, which resulted in the function writing a null terminator into
some memory that happened to be in the stack frame of codeBlock::exec()!
