Closed StrikerMan780 closed 9 years ago
Thank you for the feedback.
I am unable to reproduce the primitive corruption issue using today's git on GT620 using driver 304.117. What driver version are you using? If your install is correct perhaps I can shift to that version and reproduce the issue.
What time-frame do these screen shots cover? Months/Weeks/Days?
Are there any interesting (red) errors in the log.html? You can ignore the "cannot load font" exception; that is a benign error caused by JavaMOD.
In the past week a lot of work has been put into getting Radeon support back up, which, due to discrepancies between brands as far as OpenGL implementations go, can result in one card's support breaking in the process of fixing another. The changes to the rendering chain lately have been significant.
I confirm it is slow as far as framerate goes, depending on resolution. 20ish at fullscreen on my end. It seems to run faster on Radeon HD at the same price point, even 3 years older. Not sure yet why this is but it may have something to do with the use of VEC4s in the engine's root memory which are optimized with most Radeon HD's 128-bit bus in mind.
There are optimizations and removal of old framebuffer usage coming up later this week. Depending on whether or not these performance issues are bandwidth and framebuffer-related this may or may not result in a noticeable improvement.
The timeframe is about a month and a half.
My driver version is 337.88.
I get the exact issue that WDLMaster gets in the video above.
Yuck.
This appears to be serendipitously fixed in commit 02d00ee73671dc4dbea82430ee75a819f04456c7 while optimizing texel fetches.
Xorg-edgers "crack pusher" PPA lacks 337 but it apparently had it at one time. Interesting that they removed it. Was able to install 346.22, 343.36, 340.65, fixed some GLSL issues in the sound shader and the corruption didn't manifest until checking out prior to the above commit.
Explanation: One or more of the involved fetches was subject to mip-mapping but the data being retrieved is not for visual use. Apparently one of nVIDIA's newer revisions resulted in GL behavior assuming mip-mapping was intended. This caused the data retrieval to become corrupt. TextureLod forces this off and behavior is as intended.
Can you pull latest and confirm fix? (expect ambient light and sky color issues)
Testing in the past 6 weeks would have been a bit pointless anyway as I was fixing Radeon support which made the nVIDIA side of things go bonkers for a while.
Just confirmed the hang on startup on my machine and am analyzing thread dumps now. Not quite clear if the crash at the end was an unexpected crash or a crash resulting in the fact that player death behavior hasn't been implemented yet. (:
After the last few commits, things are starting to return to normal. Most of the graphical glitches are gone, but the lighting seems wonky still, and explosions have the tendency to turn green + have crazy depth issues. The framerate is slightly better too, but still a ways to go.
Today's git is expected to fix all but the explosion/billboard errors.
I confirm an aggressive drop in framerate when a large number of billboards are present.
The framerate drop during briefing mode is fascinating because it doesn't go away even when the window is made very small. It features a lot of billboards since each text char is a billboard.
During regular gameplay I observe a 10FPS improvement when shrinking the window but it maxes out around 50fps and goes no further. This implies a bottleneck earlier in the pipe, possibly at object/vertex level or java. It is somewhat good to see as there are just a few more things that can be done to the deferred stage before flexibility laid out for version-2 features have to be conceded.
The method implemented in the engine for displaying billboards is known to be inefficient (93% triangle discardment per object) and there is a lot of potential to improve. Points technically aren't supported in the engine yet - each flat is an object like any other and has a similarly heavy matrix. This could be dramatically improved with point support.
This wasn't as much of a problem before as the CPU was calculating camera matrices and the GPU was hardware-culling invalid primitives early, a feature which should be put back into the engine.
A rough FPS figure can be observed in Debug->Debug States->org->jtrfp->trcl-> core -> Renderer ->FPS. It may be wise to wait for level loading to finish as it will annoyingly explode other parts of the tree as things update.
Is it normal that explosions are often showing up as green squares, or as nothing at all?
Yes, expected but not desired.
I take it a fix is in the works.
Yes
I'm getting insanely corrupted and flickering visuals, and slow performance. It's progressively been getting worse with each build.
Here's how it started a few builds back:
Then now:
I'm running Windows 7 x64, with an Intel Core i5 4670k, and an NVidia GeForce GTX 560.