Menu
▾
▴
#6192 PUTTCIRCUS: Animation glitches (regression)
ScummVM 1.6.0git (Nov 27 2012 17:26:37)
Features compiled in: Vorbis FLAC MP3 RGB zLib Theora AAC FreeType2
Enter the scene with Francine, the high diving hippo the first time.
Talk to her, by clicking on her, let the animations roll.
When the closeup to Putt-Putt is shown the animations on him are borked.
After he talked his first sentence, his face gets erased, reappears, gets erased, reappears, gets erased and reappears again.
After that his face gets erased finally and the animation of the whole scene stalls (he was waving to Francine which stops)
I know this is a regression, but i cannot tell which commit broke it.
Putt-Putt 6: Joins the Circus (English)
AmigaOS4 - SDL - BE - PPC
gcc (GCC) 4.2.4 (adtools build 20090118)
Just click on Francine
Raziel^: Not many active developers have copies of Putt-Putt 6: Joins the Circus (English), so if you could do the basic regression bisection testing here, that would be very helpful.
Firstly, get older releases of ScummVM i.e. v1.4.1, v1.3.1, v1.2.1, v1.0.0 etc. and test each to see if this bug occurs.
Note that older versions of ScummVM may not load newer savegame versions, so you will need to:
a) Play through from a clean start (Best as no savegame data issues, but slow if the problem is some way into the game)
b) Use a Boot Param to jump to this point (But Putt-Putt 6 params are not listed, they may be present, but you will have to experiment to find the right one) : http://wiki.scummvm.org/index.php/Boot_Params
c) Play from start with say v1.0.0 and get a savegame, which should be loadable by all newer versions...
The idea is to find a "good" i.e. no bug followed by a "bad" i.e. bugged release version.
Once you have these post them here...
Once you have done this and found a good and bad revision, if you can, then do a "fine" bisection using git.
i.e. Get and compile the source code on your platform as per the instructions here: http://wiki.scummvm.org/index.php/Developer_Central#Getting_started
Then do a git bisection... Basically you will need to match the dates of the good and bad release to git commit ids, and then follow the basic idea from the tutorial here: http://webchick.net/node/99
Basically, do the bisection selection, compile, test and see if the bug occurs, if so "git bisect bad". If not, "git bisect good"... Keep repeating about 10 times and git will throw out the id of the commit where the bug was introduced.
Post that value here... and then we can get one of the SCUMM/HE engine team to look at why this is occuring.
Good: 1.5.0
Bad: 1.6.0git
It must have been introduced since the last release
I'll see if can make hg do a bisect, not sure though, sorry no git here
Raziel^: I'd suggest installing git if possible, but if you can't, then I know Mercurial (hg) can import from git repositories.
It can also do bisection, though you will need either Mercurial 1.0 or greater, or to install an extension for earlier revisions:
http://mercurial.selenic.com/wiki/BisectExtension
Git is not available.
I have Mercurial 1.9, bisect is an internal command.
Marking the newest checkout as bad is working, but as soon as i give the program ANY commit id it tells me
"abort: unknown revision 'revision-commit-id'!
I'm doing it by hand now...checking out revisions and check
What is puzzling me is that the release branch 1-5-0 does not have this glitch, but the main branch is going back to last year and still having the issue?
You wrote puttzoo in the title and had "Putt-Putt Saves the Zoo" as the group, but you described Putt-Putt Joins the Circus in the description (and even said the name there). I fixed it to say circus everywhere except your upload.
With much help of digitall we found that commit
49ab6d028984a582a9683e30d6e995c7efa3f804
introduced the glitch
https://github.com/scummvm/scummvm/commit/49ab6d028984a582a9683e30d6e995c7efa3f804
Raziel^: That is a very odd commit to find causing this issue, but possibly points to an issue with types.
Could you please test again with this and the previous commit, and after doing a "./configure" with each, attach the resultant config.h and config.mk to this bug marked with the commit please, if there is any difference?
They are completely the same i'm afraid :-(
Raziel^: No problem. We should have enough information now to try to work out the likely cause...
Raziel^: Two further questions:
1. Can you try replicating this issue on a x86 i.e. LE machine running Win32 or Linux as this could be an Big Endian only problem, which looks likely.. and report results here.
2. As I don't own a copy of this game, can you see if you can replicate the issue or a very similar one with one of the demos of this game available from here: https://sourceforge.net/projects/scummvm/files/demos/scumm/he/
This will also make debugging much easy as these are freely available to all...
1. I will try.
I can only try using a nightly build although i can only tell by cross checking with a nightly build on the Amiga
I can't build my own revisions on other machines, sorry
2. No, sorry, because the demo goes only as far as jumping on the train to the circus and then a spoiler roll starts telling the player in-spe what adventures awaits in the full game :-(
Raziel^:
1. Thanks for that. Just a quick test with the current Win32 nightly or similar would be fine. If it doesn't happen, that reinforces the likelyhood that this is a Endian issue in HE (There are a lot of endian conversion macros being used in HE, so this is likely but this is the major test).
2. Damn. There are a few demos for Win/Mac and various languages, but I assume they are all the same, so if this isn't very near the start of the game :/
1. Well, the glitch does not happen on Win32 with the daily build from today
Not sure, if this is so much of a help :-(
Raziel^: Well, it does tend to indicate that this is a BE issue within the SCUMM HE engine. I now have a copy of this game and I can test both LE native and BE using the QEMU PPC solution, so will try to track down why this is happening...
Hmm... I can replicate this with the current Git master on Linux x86_32, so this doesn't appear to just be a BE issue.
Valgrind shows no issues... It looks like a timing related redraw/priority(z-order) issue, and is repeatable.. but doesn't occur when running in Valgrind i.e. because it is so slow?
Adding screenshots showing output of "objects" and "scripts" debug commands at the point of error...
Screenshot at Bug #1
Screenshot at Bug #2
Screenshot at Bug #3