Open GoogleCodeExporter opened 9 years ago
I humbly suggest as a kluge-y start, in
svn/trunk/src/jpcsp/graphics/VertexCache.java, line 134:
public synchronized void reset(IRenderingEngine re) {
Honestly, I'm not a java wizard, so it's possible that "synchronized" has
different implications than I think it does. But from the exception, issue
conditions, and code, it looks like VertexCache::reset is for-each-ing over its
values and deleting them without making sure some other component isn't trying
to draw or write them at the same time in another thread. Although, I don't
see any non-synchronized methods (by a quick visual scan) messing with the
cache property, and it's private, and it isn't returned by any public method,
so I don't know how it's being accessed from some other thread.
If that doesn't work, maybe it's returning references to the vertices and
something else is carelessly messing with them asynchronously, in which case
you could modify the VertexCache class to return copies, mutexed decorators
that implement the same interface, or force synchronization in whatever class
is already being returned.
Hope that helps!
Original comment by sqy...@gmail.com
on 26 Feb 2013 at 2:53
One more thing! In all cases in all games I've tried, checking the "Use vertex
cache" option after the game has started running causes an immediate crash.
And another! The above comment is intended as a temporary measure that could
allow my cache-clearing in-game kluge to be effective while maintaining a
playable fps (i.e. by using "enable save GE screen to texture instead of
memory" and not throwing an exception). This does not address the actual
problem, which is (in my uninformed estimation) gradual, snowballing corruption
of some GE data that affects the texture cache, whose accumulation is halted by
a side effect of clearing the vertex cache.
Sorry, one more! I have way too much free time! I'm peeling through
VideoEngine.java right now to ascertain the side effects of clearing the vertex
cache. Is there a way to set VideoEngine::useAsyncVertexCache = false without
setting VideoEngine::useVertexCache = false through the JPCSP GUI? This would
be a pretty good test of my theory.
Original comment by sqy...@gmail.com
on 26 Feb 2013 at 3:35
Thanks for the suggestion. The ConcurrentModificationException should now be
fixed in r2987.
Can someone else reproduce the basic problem you are reporting? E.g. with
another graphic card (to exclude driver bugs).
Original comment by gi...@web.de
on 26 Feb 2013 at 8:07
My kluge now restores the screen to normal nearly 100% of the time and never
crashes the game. When it doesn't, the clear texture cache step is what screws
it up, causing strobing that is an epilepsy hazard, or just permanently whiting
out the screen. This is really rare, though.
Regrettably, this update also broke a lot of the game that was working before.
This could easily be game specific, but I mention it here for diagnostic
purposes because there's a very specific set of changes that were applied. A
large number of scenes involving 2d stills with overlaid text & portraits with
no 3d present that previously worked now halt at a predetermined point in the
scene. In most cases, the halt can be terminated by skipping the scene - in
other words, the game is still processing input and can recover normally, it is
just waiting on something that JPCSP now cannot complete. Re-viewing the same
scenes, where possible, does not change the point at which the halt occurs.
This point coincides with the display of a new portrait and playing a sound
effect (unfortunately these are inseparable) - fade effects and translations of
graphic elements already on screen and sounds that have already started
complete as usual. The determinism and timing of these halts leads me to a
hunch that JPCSP now chomps on loading or decoding some image or audio file,
and the wait function on the IO or thread handle (assuming sync on PSP is like
on Windows) is refusing to time out, or isn't complaining loudly about the
failure. I'm about to roll back to an old version to verify that the scenes
that actually crash (silently) were working.
Original comment by sqy...@gmail.com
on 10 Mar 2013 at 4:51
Rolling back the version to the one I mentioned in the OP fixes the problem, so
one of the updates since then broke it.
In addition, I've found two cases of "now loading..." screens continuing
indefinitely. Both are fixed by rolling back the version. A debug-level log
is attached; it looks like all it's doing is managing audio sync, and there's
no audio playing, so I'm guessing one of the updates had something to do with
audio and is broken (at least situationally).
Original comment by sqy...@gmail.com
on 12 Mar 2013 at 10:48
Attachments:
Original issue reported on code.google.com by
sqy...@gmail.com
on 25 Feb 2013 at 7:51