Opened 15 years ago
Closed 15 years ago
#4542 closed defect (fixed)
PSP: T7G poor performance
| Reported by: | joostp | Owned by: | |
|---|---|---|---|
| Priority: | blocker | Component: | Engine: Groovie |
| Version: | Keywords: | ||
| Cc: | Game: | 7th Guest |
Description
With latest SVN (trunk and branch) performance in The 7th Guest on PSP is VERY poor, and much worse compared to 0.13.1
I haven't had a chance yet to find which revision introduced the slowness, Maybe one of the groovie engine developers has an idea.
As a sidenote, in 0.13.1 the performance of groovie wasn't great either, especially considering the original game ran better on my 386sx 25mhz than it does on a 222 or 333mhz PSP. Looks to me like there is room for optimization of the engine.
Ticket imported from: #2839528. Ticket imported from: bugs/4542.
Change History (12)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Could it be somehow related to palette updates? There was a similar issue with MADE, caused by very frequent palette updates - each palette update makes all the pixels on screen dirty, thus causing severe slowdown.
In VDXPlayer::getDelta(), I see this: // Apply the palette if (!_flagSeven) { //if (!_flagSix && !_flagSeven) { setPalette(_palBuf); }
This was introduced to fix the palette issues in the intro. I don't know a lot about the groovie engine, but perhaps the check for flag 6 is somehow related?
There is also this bit: //_flagSkipPalette = _flagSeven; _flagSkipPalette = false;
Which means that the palette updates will never be skipped, and will always be applied. If this means that the screen palette is updated in each frame, it will be terribly slow.
Again, I don't know much about the engine, this is all just speculation from a quick glance at the code
comment:3 by , 15 years ago
Performance suffers in the ce port as well. I'll have feedback on if such drastic slowdowns occur in branch 1-0-0 later today, but performance was lacking in 0.13.1 too.
comment:5 by , 15 years ago
| Priority: | normal → blocker |
|---|
comment:6 by , 15 years ago
Some more info; contrary to what I said earlier, audio (SFX / speech during the intro) DOES break up, the music, however, doesn't seem to.
Also, I looked at thebluegr's suggestion and even in the problematic bits there are only very few setPalette() calls, and even so, they shouldn't really be expensive on the PSP, so this is likely NOT to be the culprit.
I tried a few older revisions to try and track it down, and in some the Ouija board and Virgin/Trilobyte logos animate MUCH smoother (at perfect speed), the audio in the intro still breaks up sometimes, and the game also doesn't run very well... quite confusing!
comment:7 by , 15 years ago
OK, based on what I can see with the wince emulator, because I cannot test on a real device, I would say that there is little difference in performance between 0.13.1 and 1.0.0rc1.
Beware though, because the emulator is *not* a real device, not cycle exact, no nothing. But it is logical that it would expose any severe slowing down having occurred between these two versions.
FWIW, I see "nice" CPU load scaling: i.e. CPU is low when the menu is shown then scales up when there's video decoding going on.
The engine in both versions is not a light load to the CPU -- to the contrary.
If it means anything, the pitch of the "music" playing during the Ouija board is different between the two versions (like playing the sample on a different speed).
comment:8 by , 15 years ago
The big drop in performance on the ouija board in the PSP version was introduced with revision #43477 (the PSP standby/resume patch).
comment:9 by , 15 years ago
Thanks pix2, that's very valuable.
As of that revision, file reads are /slightly/ more expensive because of the extra locking involved, in most cases this isn't noticeable, but in the 7th guest, it appears ALL of the data is read in in 1-byte chunks, which causes tremendous slowdown that is now amplified by the extra overhead.
Doing some read ahead caching in the PSP file stream code would probably help this a great deal, but surely the engine can be much improved in this regard as well?!
comment:10 by , 15 years ago
Digging a bit deeper: By the time the Ouija board has finished showing there have been 327880 1 byte reads. Looking at the groovie engine code, it uses readByte() calls on a File(!) stream almost everywhere, if the engine were to load the relevant chunks of data from file and use a MemoryReadStream instead then it's quite likely this problem would dissappear.
comment:11 by , 15 years ago
r43671 fixes this problem by reading in a VXD frame chunk at a time, instead of bytewise. Thanks Scott_T!
We still should make the locking on PSP less expensive so it can benefit from the file reading caching the underlying implementation already provides.
comment:12 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I should add that the audio plays correctly and is never choppy, it's the graphics/animation/video that are.
Even the opening screen in which the ouija board appears is dreadfully slow.