Alright the potential improvement i mentioned
The theory:
Bond's movement is influenced by a forward and a sideway value
The sideway value ranges from -1 to 1
The forward value however, has two ranges
At first, the forward speed range is -1.08 to 1.08
After holding forward for 180 frames, that range is expanded to -1.08 to 1.35
(sorry, doesn't work on backward motion :P)
Adding strafe to this:
the slow speed = sqrt(1*1 + 1.08*1.08) =~= 1.472
the fast speed = sqrt(1*1 + 1.35*1.35) =~= 1.68
a difference of (100*(1.68/1.472 - 1) =) 14.1%...
This means that every time bond starts running, we lose
180 * (1.68 - 1.472 =) 37 distance
which costs (37 / 1.68 =) 25.5 frames to make up at fast strafe!
Note that the speed values are not directly aplied to coordinates, but first scaled... however all calculations still apply
Now, how do we save time with this knowledge?
The game tracks for how long the player is holding the forward 'button' (the 180 frames)
The forward-holding-counter was intended to start when the play gains control over bond..
Normally, this means that first 180 frames of 'slow' movement is done
Due to the same programming error that causes the shoot-in-cinema... if forward motion is done by controller 2 in single player, the counter starts in the cinema!
Conclusion: use 2.4 instead of 2.3!!!
In practice:
Did a test in Dam A, right-strafe from spawnpoint, skipped first cinema, played full home-in-on-bond cinema
Measured distances from spawnpoint by taking bond's x and y position (sqrt(dx*dx+dy*dy))
With 2.4 no turning was done
With 2.3 only turned 1 frame to avoid hitting right-side wall (resulting in ~same direction as 2.4)
Not that the acceleration from 1.08 to 1.35 is needed in both 2.3 and 2.4... so it can be ignored
In 2.3 bond reaches full forward speed after 207 frames, at which moment a distance of 2261,986 units is covered
In 2.4, that same distance is covered after 188 frames
~ 207-188 = 19 frames faster with 2.4
Conclusion: Seems to work :)
ps. Not all in-game frames are available, e.g. maybe it should be 206 frames rather than 207
ps2. The forward-hold-counter is also reset when accessing the menu/watch... couldn't fid a way to preserve it through pauses.. :/
ps3. If you skip cinemas asap, the forward counter is at ~80-100 when you gain control over bond
ps4. I'm not sure if there's an advantage of 2.3 over 2.4... but both sideway and forward speeds can still be achieved simultaneously in 2.4
ps5. Here's some of the memory values used (Only work on Dam level in Mupen-rr-v8-avisplit!)
bond_x = MupenDLL + 0x005BFFA4 [Float/Single]
bond_y = MupenDLL + 0x005BFF9C [Float/Single]
framecount = MupenDLL + 0x005665D0 [ULong] (this one is not dependent on map)
forward-hold_framecount = MupenDLL + 0x005BFC8C [ULong]
forward_speed = MupenDLL + 0x005BFC84 [Float/Single]
sideway_speed = MupenDLL + 0x005BFC7C [Float/Single]
ps6. From the scaled coordinates (measured by bond_x and bond_y)... you can see that bond does not move in perfectly straight lines. Probably due to imprecisions in calculations... *Maybe* by using tiny turns each frame, bond's movement can be improved to be straighter and to have positive rounding errors? :D
ps7. An example of movement speed: 250 scaled-units distance in 20 ingame frames = 12.5 scaled-units/frame moved @ 1.35-stafe-speed (e.g. can be 4x12.5=60 units if an update is done after 3 lag frames). If you measure speed every frame... you'll notice it varies rather heavily (not sure yet if this is a pattern or a result of something (e.g. lag))
edit: changed 'UShort' to 'ULong' to match with my MHS/VS-C# settings.
[/URL]
[/URL]
this reminds me i should change my plan.... paying for something i don't need (or use, even) :/
