Re: Patch speed problems, was: Alpine climate, speed problems
Josef Drexler <[email protected]> Tue, 17 Jan 2006 11:22:15 -0500
| Newsgroups | gmane.games.ttdpatch.general |
|---|---|
| Message-ID | <[email protected]> |
Michael Blunck wrote: > Uwe Domaratius wrote: > >>>>[Slowdown with train windows open] > > [...] > >>I finally did some more testing on this matter, and at least for me it >>helped to turn off the new sprite sorter (miscmods.nonewspritesorter >>on). Maybe some patch dev could take a look into this, more info >>(savegame and config) can be provided if necessary. What kind of CPU do you have? The new sprite sorter shouldn't cause a significant slowdown I think. Do you have "showspeed on"? Possibly that requires updating the window more often (due to changing speed or TE) that it might make the small difference with the new sprite sorter more pronounced. > That´s interesting. However, those sprite sorter issues are delicate, to > say the least. I doubt that any patch developer would like to plunge > voluntarily into that again, although ATM we don´t have a fully > functioning sprite sorter at all. Well, it's not in principle possible to write a sprite sorter that always works correctly in all situations. In fact, there are situations, possibly even in TTD, for which it's impossible to determine a "correct" ordering, see for example http://joesbox.cjb.net/~jdrexler/order.png This could be two trains, one on top of a bridge and one below, plus an elrails pylon or a bridge pillar or a semaphore signal. It might be possible to tweak the sprites so that it still looks mostly right, but then you need to adjust the bounding boxes too. The "correct" way would of course be to split one of the sprites in two or more pieces, but that generally can't be done with TTD sprites without redrawing them. > In fact, we seem to need two of them: the new one is required for > shorter vehicles support and the old one would be required for correct > bridges and other buildings clipping stuff. Well, the new sprite sorter is only used when there are overlapping 3D bounding boxes, in which case TTD's sorter fails to do any sorting. Otherwise the code is the same as TTD's sorter. The problem with bridges (and perhaps some buildings; I'm not sure) is that TTD uses fake bounding boxes for the support pillars, giving them a negative width. That confuses the new sorter and it probably thinks that the bounding boxes overlap, thus occasionally mis-sorting sprites when bridges are involved. It might be possible to fix the problem by using better b-boxes for bridges, but I haven't had the patience to work them out. It'd a tedious trial-and-error process... -- Josef Drexler -- TTDPatch mailing list. To unsubscribe from the list, send an email to [email protected] with the body (not the subject) of the email containing only the word "unsubscribe" (without the quotes). For more info please see http://www.ttdpatch.net/maillist.html