Transport Tycoon Forums

Tiberius, what kind of file extension is that???

G4 wrote:Tiberius, what kind of file extension is that???

If you are talking about "opengl-080711_r13691.patch" then it's a file that contains the differences between the official source code of the game and the code that Tiberius is working on.
If you do not know how to compile a program (or if you do not know what compiling means), I could suggest this sticky:Howto apply a patch/diff file, or even better :
Our Wiki who would tell you a lot more than the above link

If it is not what you are asking for, you should maybe be more precise in your question

Possible bug found! Look at toolbar in the upper left corner, there's a horizontal red line when a vehicle 'disappears' behind the toolbar. And to reply to all earlier benchmarks: I don't have low FPS in my own games, the coop games are just very intensive probably .

EDIT: bug 2 found: when making buildings transparant, water doesn't get transparent. See screenshot 2.

Maybe it's just me, but it looks like the patch doesn't patch against SVN anymore.

I did my best to fix up the patch to work with a little more recent SVN revision. If any of you would like to test it, here it is.

If you find any display-related bugs that aren't hilighted in the first post, check to see if such a bug exists in a opengl-free build.

EDIT: Doesn't compile; try the one below.

actually ccfreak's patch doesn't work at all. This one halfway works for sdlgl and serves to demonstrate that opengl isn't a solution for the clipping problems in FS#119 ...

So what's the state of this patch? Has it been added to the trunk? Has it died?

GreatBunzinni wrote:So what's the state of this patch? Has it been added to the trunk? Has it died?

It has not been added to trunk. You can see that your self by looking on the change log or simply downloading last nightly. Also if it would have been added or close to being added I would expect much more activity about it on the forums and/or IRC.

The least you could expect if it was added to trunk is a notice in this thread that it has been added.

Zuu wrote: It has not been added to trunk. You can see that your self by looking on the change log or simply downloading last nightly. Also if it would have been added or close to being added I would expect much more activity about it on the forums and/or IRC.

The least you could expect if it was added to trunk is a notice in this thread that it has been added.

It seems a bit strange not do so. Wouldn't openttd benefit from the addition of a opengl blitter?

GreatBunzinni wrote:Wouldn't openttd benefit from the addition of a opengl blitter?

Would a Toyota Prius benefit from getting it's engine replaced by a Ferrari Formula 1 engine?

But OpenTTD developers have experimented with this F1 engine (http://wiki.openttd.org/wiki/index.php/Blitter) so what's the reason behind that? (Your reply seems to indicate that it's useless). Some sort of filtering on zoomed-out levels would make the game look nicer IMO (look at http://www.tt-forums.net/viewtopic.php? ... &sk=t&sd=a for instance, but this blitter 'hicks' when changing zoom-level). Also, wouldn't stepless zoom be an option with OpenGL? Not really necessary but 'nice to have'. Oh well, I understand that other things have priority but one can dream .

bokkie wrote:But OpenTTD developers have experimented with this F1 engine (http://wiki.openttd.org/wiki/index.php/Blitter) so what's the reason behind that? (Your reply seems to indicate that it's useless).

I was merely pointing out that making assumptions that all and any patches are beneficial for OpenTTD is strange if not stupid. Yes, there's an opengl blitter and it might be useful. But until there is a properly functioning blitter without added artefacts there is absolutely no way of saying whether it would be faster or better than the current blitters; it's often the corner cases that take the most time.

Furthermore previous attempts to do the actual blitting have shown that the really blitting doesn't take much CPU; it's a few percent faster on multi[thread|core] CPUs and more than it is faster percent slower on single core/thread CPUs. Meaning that the blitter doesn't give most people an instant performance increase of significant magnitudes. This analysis has been made on a quite populated, but not 100% CPU game, however... one can always make their statistics meet their expectations by e.g. using an unpopulated map with a few moving industries and max-zoom-out on fast-forward, but is that a realistic scenario?

Furthermore previous attempts to do the actual blitting have shown that the really blitting doesn't take much CPU; it's a few percent faster on multi[thread|core] CPUs and more than it is faster percent slower on single core/thread CPUs. Meaning that the blitter doesn't give most people an instant performance increase of significant magnitudes. This analysis has been made on a quite populated, but not 100% CPU game, however... one can always make their statistics meet their expectations by e.g. using an unpopulated map with a few moving industries and max-zoom-out on fast-forward, but is that a realistic scenario?

I dare to say that these are heavily populated maps with a lot of rails, trains etc, that suffer most from blitter performance. If I load such game on my machine, performance in paused mode is quite similiar to that in unpaused mode.

CommanderZ wrote:

Furthermore previous attempts to do the actual blitting have shown that the really blitting doesn't take much CPU; it's a few percent faster on multi[thread|core] CPUs and more than it is faster percent slower on single core/thread CPUs. Meaning that the blitter doesn't give most people an instant performance increase of significant magnitudes. This analysis has been made on a quite populated, but not 100% CPU game, however... one can always make their statistics meet their expectations by e.g. using an unpopulated map with a few moving industries and max-zoom-out on fast-forward, but is that a realistic scenario?

I dare to say that these are heavily populated maps with a lot of rails, trains etc, that suffer most from blitter performance. If I load such game on my machine, performance in paused mode is quite similiar to that in unpaused mode.

Why are you so sure that is due to blitter performance? Have you profiled openttd with the result of the blitter taking most of the cpu time or is it just a guess? In the latter case my guess is that the problem is not because of the blitter, but due to the pahtfinders, tile loop, etc.

Yexo wrote:

CommanderZ wrote:I dare to say that these are heavily populated maps with a lot of rails, trains etc, that suffer most from blitter performance. If I load such game on my machine, performance in paused mode is quite similiar to that in unpaused mode.

Why are you so sure that is due to blitter performance? Have you profiled openttd with the result of the blitter taking most of the cpu time or is it just a guess? In the latter case my guess is that the problem is not because of the blitter, but due to the pahtfinders, tile loop, etc.

If the pathfinders are causing slowdown in paused mode then openttd has bigger problems.

Thief^ wrote:If the pathfinders are causing slowdown in paused mode then openttd has bigger problems.

Indeed. I should read better next time

I am trying to modify this patch correspond to SVN r15680 ,but it doesn't go well.

any progress?

Nobody is working on this as there is simply no point. OpenGL doesn't really lend itself well to partial screen updates and "non-powers of 2" sized sprites.

petern wrote:..."non-powers of 2" sized sprites.

Wouldn't GL_ARB_texture_non_power_of_two help (if of course the partial updates were sorted)?