Closed GoogleCodeExporter closed 8 years ago
NOTE: This issue will only happen in the case that the main framebuffer has
been requested to be multisampled. When using post processing, the user will
typically set the number of samples in the FrameBuffer itself, which would
properly be clamped to prevent a crash in the renderer. Most users reporting
this issue set the "x16" option unwittingly in jME3's built-in settings dialog,
then rush to the forum to report the crash.
Possible solution: Create new method in LwjglContext
int determineMaxSamples() which would create a pbuffer context and then query
the max number of samples by using GL_EXT_framebuffer_multisample and
GL_MAX_SAMPLES.
Unfortunately, this extension was released quite recently and therefore might
not be supported in older GPUs. The only solution is to test each number of
samples, starting at AppSettings.getSamples() and dividing by 2 each time, e.g.
16, 8, 4, 2, 1, until the pbuffer creation no longer throws an exception.
However, the GPU may not support pbuffer creation, adding an additional
handicap to this method. If pbuffers are not supported, then we have two
options, either return 1, indicating that multisampling is not available, or
return MAX_INT, indicating any value is acceptable and let the user take the
risk of an exception. Since jMonkeyPlatform utilizes pbuffers extensively, we
can conclude that this method will succeed in the majority of cases given there
were no reports of jMP failing to load due to lack of pbuffer support.
Original comment by ShadowIs...@gmail.com
on 4 Aug 2012 at 4:55
Original comment by ShadowIs...@gmail.com
on 4 Aug 2012 at 9:52
Original issue reported on code.google.com by
ShadowIs...@gmail.com
on 9 Jun 2012 at 8:59