Road vehicles check occupation by fractions of tiles

[jamespetts]

Currently, road vehicles will not enter a tile occupied by another road vehicle going in the same direction. However, road vehicles are often much smaller than tiles. It would improve the appearance of the game and make using roads easier and more intuitive, I think, if road vehicles could base their occupation detection of tiles on fractions of tile lengths rather than entire tile lengths. This would especially help in cases where a town is congested with private car traffic.

[Ters]

This would, more or less, involve making the tiles smaller. Or making tiles of tiles. The former would be beneficial in many ways. While pak128 has better graphics than pak64, I've never liked the big gaps between the tracks. Keeping the graphics, but reducing the tile size would make it much better IMHO. But then there's the old issue of multi-tile city buildings.

[jamespetts]

Hmm - this isn't strictly necessary, is it? There is already the concept of a tile step, which is used for vehicle movement. This can surely be extended to cover road vehicle occupation checks? It would not be necessary with rail based ways, as they use absolute block signalling in any event, and even moving block signalling on a railway would involve some level of imprecision.

[kierongreen]

But at present a vehicle, whether road or rail won't pass onto the next tile unless it is empty. Tile step is used for displaying a vehicle but checks are just based around whole tiles.  That's not to say it can't be done, but that it would add complexity to the code. It would be nice though...

[Ters]

To elaborate: Tile steps aren't things in the code. You can't look them up and see if there are any vehicles there.

[jamespetts]

But one could, presumably, check whether any vehicles are on the tile, then check each vehicle on the tile to see where on the tile that it is using tile steps, and compare that result to the position of the vehicle doing the checking?

[kierongreen]

Yes but that means you have to do the check every step rather than hop.

[jamespetts]

How much is that likely to impact upon performance?

[kierongreen]

Significantly. It means every (road) convoi has to perform that check whenever it's moving. You could easily be talking about an extra 10,000 checks a second in a well developed game. You have to check what vehicles are moving in the same direction as the current vehicle on the current tile, and then work out which one is closest in front, and then whether it is far enough away to keep moving.

[jamespetts]

Hmm - one would only have to perform the latter checks if there are, in fact, vehicles on the tile wouldn't one? It wouldn't be necessary in every case. And one needn't work out which vehicles are on front - one could just check all the vehicles until one found a vehicle that was too close. Whether these two things would make enough of a difference is another matter.

[kierongreen]

Well yes, you'd have to loop through all convois on a tile, first checking whether they were travelling in same direction, ignoring those travelling in the opposite direction, then that their tile step was greater than the current convoi, ignoring those behind, and finally checking whether their tile step minus their length was greater than the convoi position after stepping, and if it was closer then slowing/stopping.

[prissi]

Some thoughs: Yes it is possible, although citycars do not have a length yet, and many vehicles are not entered with their proper length in the paks (especially buses).

The check is relatively simple. You get anyway the vehicle from the routine. Now check a) diagonal b) straight dir to get steps (either 255 or 160 or maybe 128). Then get steps of front car, and add length*16. Until there you can go before the next check is needed. Then you would need to call a modified routine similar to hop_check().

A question remains: How to handle turning vehicle, which are not in front but for now block a vehicle to avoid a congested intersection?

Impact:
Another counter for vehicles (8Bit), might not be an issue.
Additional code to hop_check, negilible
Additional testing in fahre, might be a problem.

I have a developed game with 8000 convois, 90% Buses. There hop_check is over 25% of the time needed. Calling it twice will lead to 33-50%.

Another impact: When there is a long queue that starts moving turning on a intersection, it will be very difficult for another vehicle to get in, if they are following each other as closely as they can. It would make traffic lights mandatory.

[isidoro]

This topic reminds me of that very long mine one about real one-way two-lane roads.  One of the topics discussed there was to divide each road tile in four subtiles, only for occupation checks.

That has the additional advantage that one can separate lanes in those checks.  And, since road vehicles have a granularity of half a tile, that would solve the problem of separation of stopped vehicles without worrying about tile steps.

[TurfIt]

Another item on my eternally growing todo list... But an item I'd actually started on - got as far having vehicles come to a stop tight behind another on the same tile. Code is in no condition for public disclosure though. 

Quick description of what I did:
no_cars_blocking - currently returns as soon as it finds another vehicle in the way - modify to return the blocking vehicle that's closest to the edge.
ist_weg_frei - modify to return the number of steps free rather than true/false for the whole tile free. Takes the position and length of the vehicle returned by no_cars_blocking to calculate.
hop_check - modify to return the number of steps free - just passes along the value from weg_frei
fahre_basis - uses the steps free returned from hop_check to end the vehicles motion partway into the tile.
But, this is far from complete... maybe someday...

Performance wise, the extra loops in no_cars_blocking is really where the hit will come from. It's structured right now to do the minimum number of checks to return a go/nogo.

[jamespetts]

Thank you for the useful analysis, Prissi. Interesting thoughts. Isidoro's simplified idea is interesting - what sort of impact would that have on performance?