Opened 23 years ago
Closed 18 years ago
#215 closed defect (fixed)
FOA: Jerky movement in car chase
Reported by: | SF/jbergstrom | Owned by: | Kirben |
---|---|---|---|
Priority: | low | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Indiana Jones 4 |
Description
ver. 0.2.0 devel(042002) English CD-talkie, Win32
When Indy rides a camel the camel doesn't move very smoothly, but with noticeably long steps. The same happens in the Monte Carlo car chase.
Ticket imported from: #551715. Ticket imported from: bugs/215.
Attachments (2)
Change History (20)
comment:1 by , 23 years ago
comment:2 by , 23 years ago
OK, the camel might be intended to move in steps but the cars really should move smoothly. In my original they do, at least.
comment:3 by , 22 years ago
Summary: | Jerky movement in overhead view actions → FOA: Jerky movement in overhead view actions |
---|
comment:4 by , 22 years ago
Priority: | normal → low |
---|
comment:6 by , 22 years ago
If you provide me with a save game just before the car race, I'll try to look into it.
comment:8 by , 21 years ago
Just to clarify this: the camel ride is working perfectly fine. The scripts that control it only work on a very low resolution, and that's why the movement is jerky.
Sadly I can't load the car crash save game :-(
comment:9 by , 21 years ago
Summary: | FOA: Jerky movement in overhead view actions → FOA: Jerky movement in car chase |
---|
comment:10 by , 21 years ago
Sadly, that second savegame does *not* work for me. It dies with an assertion: scumm/script.cpp:1185: failed assertion `idx < 5'
comment:11 by , 21 years ago
At least in the CD version, the car chase is in room 70. What happens if you skip to there with the debugger?
comment:12 by , 21 years ago
That works quite well, thanks erik. Hm, the "walk speed" of the "indy car" is set to (10,5). Otherwise, the code looks pretty similiar to the desert chase (that is, there are some huge strings which essentially contain a description of the allowed paths for the car/camel, and the scripts parse those strings). It's a pity I can't use the original, it would be very nice to be able to exactly compare its behaviour to what we get.
comment:13 by , 21 years ago
This is getting on to be a two year old bug. Has anybody managed to confirm that there actually IS a problem here, yet? :P
comment:14 by , 21 years ago
Well, so far we mostly have what jbergstrom said. I have no way currently to check this with the original. So I dunno.
comment:15 by , 20 years ago
The problem still occurs, the cars are much more smoother in the original game. If you want to compare, use boot param 8888 in original game and ScummVM. To activate debug mode of original FOA: Skip introduction. Type 'shinymetal' without quotes Use 'CTRL d' to activate debug mode. Use 'CTRL l" to choose boot param. Enter 8888 Skip LA logo.
comment:16 by , 20 years ago
AH thanks Kirben, very useful! That information combined with dosbox allowed me to experience the scene with the original engine and compare it directly to ScummVM (although dosbox isn't quite running FOA at 100% on my machine, but it's good enough).
Looking at this, it seems to me that our actor movement is actually OK -- the original is just as jerky. Only that in ScummVm this is far more noticable. That is, after each movement phase, there is a relatively long "standing" phase; so we have a small pause between each step, causing the jerky look & feel.
Not sure what is causing this... maybe our timing code needs some tweaking. <shrug>
comment:17 by , 19 years ago
Another idea: Maybe a subtle difference with the walking code, in particular the _moving field and the waitForActor opcode is the cause.
Also, everything becomes smooth if I change the value "15" in ScummEngine::go to something a lot smaller. Of course then the rest of the game becomes faster (too fast; the 15 is an approximation for 1000/60, I think, turning jiffies/ticks, 1/60th of a second, into milliseconds).
Or if VAR_TIMER_NEXT had a smaller value (instead of the default 6) during the car chase scene, things would be smoother. But nothing in the scripts attempts such a thing.
comment:18 by , 18 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
This is as the original worked, AFAIR.