FS#2546 - Wrong var 45 value

Attached to Project: OpenTTD
Opened by George (George) - Friday, 16 January 2009, 13:09 GMT
Last edited by Remko Bijker (Rubidium) - Wednesday, 11 March 2009, 23:23 GMT
Type Bug
Category NewGRF
Status Closed
Assigned To No-one
Operating System Windows
Severity High
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



// front part
440 * 14 02 01 23 81 45 08 FF 01 00 00 01 02 13 00
441 * 14 02 01 25 81 45 08 FF 01 00 00 0E 0F 15 00
442 * 22 02 01 2F 81 9F 00 07 03
23 00 03 03
14 00 04 04
25 00 05 05
00 00

The code should draw the front part if the back part has the same direction (for directions 03 and 05), but it does not update (or calculates wrong) var 45 right after the turn, that makes one invisible state, where the back parts decides that front part starts to draw the vehicle, while the the front part does not start to do so.
This task depends upon

Closed by  Remko Bijker (Rubidium)
Wednesday, 11 March 2009, 23:23 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r15677.
Comment by George (George) - Friday, 16 January 2009, 13:19 GMT
and a version with front part report (report fail text for front part)
(application/octet-stream)    testw.grf (75.8 KiB)
Comment by frosch (frosch) - Friday, 16 January 2009, 13:35 GMT
v->cur_image is updated after each part has been moved.
To fix this, all images need updating after all parts have been moved.

Same applies to trains.
Comment by Remko Bijker (Rubidium) - Wednesday, 21 January 2009, 11:23 GMT
Wouldn't this NewGRF be horribly broken when the vehicle crashes and gets random orientations? It could be in basically any state, even 180 degrees between the parts.
Comment by George (George) - Thursday, 22 January 2009, 04:46 GMT
Rubidium: Yes, the degree can be 180, but it can happen and when RV turns around, for example. So, support for every degree between parts is planned.
Comment by Remko Bijker (Rubidium) - Tuesday, 10 March 2009, 22:26 GMT
We need to update cur_image while it's being moved as only one vehicle can be moved at a time. Unless we completely turn this behaviour around it won't be possible to update cur_image outside of the loop without glitches.

So fixing this would basically mean adding _old_vehicle_coords to the vehicle struct just to support this. I'm not sure whether that's worth the effort. Or is it cheaper to just mark the viewports before and after moving instead of keeping track of what needs to be marked and mark them at the same time?
Comment by Remko Bijker (Rubidium) - Wednesday, 11 March 2009, 11:59 GMT
Marking the viewports twice costs about 1.5 to 2% more CPU with ~500 trains.

Moveing the _old_vehicle_coords into the vehicle struct costs about 2 to 3% less CPU with ~500 trains (need to confirm this on other systems). The location where EndVehicleMove (and thus the viewport update) was called has not been changed.
Comment by frosch (frosch) - Wednesday, 11 March 2009, 22:13 GMT
just to add: if the position hash depends on the sprite size, that is also a desyncer, as sprites can be changed with static grfs resp. 32bpp
Comment by Remko Bijker (Rubidium) - Wednesday, 11 March 2009, 22:22 GMT
The position hash depends on the sprite size. However... the position hash is only used for adding vehicles to the viewport. The "new vehicle position hash" uses v->tile and is used by the game's internals.

So there's no chance of desyncs here.