Thunder Force VI massive framerate loss + rendering errors

[GoogleCodeExporter]

1) Did the game ever work correctly (i.e. not have this problem) on the
Official PCSX2 build or an earlier version of PCSX2 playground? 
(If so, please specify the latest pcsx2-playground or Official revision
that last worked.)

Not as far as I can tell, although a build from the latest official trunk
code does better than the current PP code in ways I will describe later. 

2) What steps will reproduce the problem?

For the first problem simply play the third level of the game (ocean stage)
until you reach the boss. For the second problem play until the fifth
level. Near the start of it a large ship will fly into the background and
fire at you, the problem is visible here.

3) What is the expected output? What do you see instead?

In the first problem, when the boss attacks it will fire 3D balls at you
that then explode. When it does this the frame rate plunges from 100fps+ to
around 15fps while these balls are on screen. These balls are not at all
geometrically complex which makes me wonder if something is going awry. In
addition, if the flush to zero and denormals to zero options are used the
balls are not rendered properly, as can be seen in the attached screen
shot, but there is a significant fps gain. The only tweak to significantly
alleviate this issue is to enable the EE/IOP speedhack (x3). This pretty
much improves the framerate to normal, but instead causes crippling (but
smooth) slowdown in game. The X2 EE speedhack does absolutely nothing.

The second problem is similar. As the ship attacks you, the destructible
parts of the ship will be rendered incorrectly and there is a loss of frame
rate. If flush to zero and denormals to zero are used for the VU then it
still maintains about 45 fps, and the parts incorrectly rendered will be
black. If they are not used, the frame rate is more like 15 fps, and the
parts are shown in their destroyed state (which you shouldn't even see as
they detatch from the ship when destroyed). Both errors are shown in the
accompanying screenshots. If any EE speedhack is used the frame rate
plunges even further.  

As you progress through the level and pass closer to the ship there are
minor framerate hiccups but everything is rendered correctly. The problem
only occurs when the large ship is further in the background, and happens
later in the level too.

4) What version of the product are you using? On what operating system?

pcsx2pp r420 on Windows Vista Ultimate 64-bit

5) Please provide any additional information below.

Using the official pcsx2 trunk code the ship in the second problem is
rendered correctly, with minimal framerate loss (although it may pause
before it appears) if the EE/IOP speedhack is turned off. The last screen
shot shows this. Also, with the first problem, if that speedhack is enabled
there is no loss of framerate during the boss, but there is slowdown (but
less than using the X3 speedhack in the pp build).

Original issue reported on code.google.com by Siland...@gmail.com on 12 Dec 2008 at 9:14

Attachments:

• gsdx_20081212202628.jpg
• gsdx_20081212205226.jpg
• gsdx_20081212205309.jpg
• gsdx_20081212210223.jpg

[GoogleCodeExporter]

Firstly, I'm pretty sure the shadow/lighting problems in the second screenshot 
are a
bug.  They mimic closely another bug we just had reported to us in a separate 
game. 
And yea, once the bug is fixed, the ship *should* render correctly in either 
mode
(denormals on or off), since it rendered correctly in the Official build (which 
runs
always with Denormals Are Zero hack enabled).

The first problem however, probably isn't a problem.  It might be resolved in 
the
future through general optimizations, but I wouldn't get my hopes up too high.  
I'll
explain:

Quoted:
>> The X2 EE speedhack does absolutely nothing.

This indicates that the slowness is a VU operation, since sync hacks do not 
affect
the operational speed of the VUs.  And the VU0 in particular can be used for 
many
things besides 3D geometry, so the lack of complexity of the geometry doesn't
necessarily mean that there is a problem.  In this particular case, there's an
excellent chance that the game is using the VU to calculate the AI/pathing of 
the
balls.  Other games have also exhibited similar slowdowns during certain AI
activities.  Eventually we might get the VUs running faster, but for now 
they're on
the back burner due to complexity and the ugliness of existing code (it's 
completely
unmaintainable right now).

Quoted:
>> This pretty much improves the framerate to normal, but instead causes 
crippling
(but smooth) slowdown in game.

This is a function of many games which is designed to do frame limiting on the 
PS2
during complicated scenes.  The X3 sync hack makes the game "think" that each 
frame
is taking a lot longer to render, because the sync hack works by increasing the 
cycle
counts of the cpu instructions (the speedup works by allowing the emulator to 
run
fewer instructions to reach counters updates, DMA/IRQ triggers, etc. since 
those are
all scheduled via CPU cycles, and the value gets incremented faster).  So the 
counter
the game uses to measure the framerate happens too soon, and it thinks it can't
finish the frame in time, and just slows itself down to compensate.

Since the game slows itself down, it runs 1/2th as many VU opts per frame, 
which is
why your emulation framerate increases under the X3 speedhack (but, of course, 
the
actual game's framerate is lower).

Original comment by Jake.Stine on 17 Dec 2008 at 5:24

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for taking a look at this and taking the time to reply, that was a very
interesting read.

Original comment by Siland...@gmail.com on 17 Dec 2008 at 7:06