ver 3.9 fps poor

[flysouth]

Hi

Apart from 3.9 colors being a bit strange compared to 3.8 the other thing I have noticed is that in an empty desert map with graphics card settings done using auto I get +- 200fps on 3.8 and only 150fps on 3.9.

It is an oldish PC and it is running win7 32 bit - Intel Core2 Quad @ 2.66 GHz. and 4Gb ram. The graphics card is a AMD Radeon HD5800 with 2 Gb ram

[Duion]

Make sure you use the exact same scene at the exact same position with the exact same graphics options, otherwise the data is not really useful.

From the tests I made I could not notice significant differences.

Here it is: http://forums.torque3d.org/viewtopic.php?f=9&t=758&p=6286#p6286

As you can see I made sure to use the exact same location to make the screenshot, to have an accurate comparison.

[flysouth]

I just used a default spawn position in a default 'full' desert map

[Duion]

3.9 has terrain backfaces, maybe this decreases performance since the terrain has to be rendered doublesided. This may be especially relevant in a map that has only a terrain.

[flysouth]

3.9 has terrain backfaces

Does it not just render what is visible?

I have now compared same empty mission with player just looking at sun in sky..

3.8 170 fps and 3.9 115 fps

If I change 3.9 to DX11 then the same test drops to 100 fps

Aiming at horizon in 'empty room' mission.

1024 x 768.

3.8 190 fps and 3.9 154 fps.

1920 x 1080

3.8 210 fps and 3.9 154 fps

So in 3.8 it got faster when I set it to the 1920 x 1080 (default resolution for my monitor)

[Duion]

So it is not the terrain? Since the empty room has no terrain.

Makes me wonder, since I could not notice any significant difference in performance.

[flysouth]

Perhaps the build?

[Duion]

I did not really test with the stock Torque3D, since I just ported the changes to my game and test with that. Version 3.9 is very bugged at the moment and unuseable, I would wait till everything is fixed so it is ready to use again and then test again, since some issues may eat performance here and there.

[Johxz]

Version 3.9 is very bugged at the moment and unuseable, I would wait till everything is fixed so it is ready to use again and then test again, since some issues may eat performance here and there.

 

For that reason you need to test the development branch before the new version is released, not after :| remember the big changes that are introducing...

[flysouth]

I tried setBasicLighting() to see how much difference that made and my sea turned red. Everthing else looks OK

How do I reset it back to whatever it was?

Okay found it setAdvancedLighting :)

Now looks like this.

Edited August 21, 2016 by flysouth

[Duion]

I was building the next release for Uebergame, so I had to get that done before, I cannot cram in development code for testing inbetween, since it would mess everything up.

So I only upgrade to supposedtly stable releases.

But what I could do is, is testing precompiled builds that work standalone, if someone provides them.

[Johxz]

But what I could do is, is testing precompiled builds that work standalone, if someone provides them.

 

Yeah :D I already provide precompile builds of development branch...

Last development commit binary, just double click a run

- http://forums.torque3d.org/viewtopic.php?f=2&t=665&p=5508#p5508

- https://github.com/John3/Torque3D_Unofficial/tags

Tutorial: How to compile the new version of Torque3D v3.9

- http://forums.torque3d.org/viewtopic.php?f=12&t=713

T3D 3.9 engine/script reference:

- http://forums.torque3d.org/viewtopic.php?f=25&t=751

Regards

J

[JeffR]

Part of the performance difference - especially on older hardware - is that compared to the prepass lighting of prior versions, deferred shading has a much 'fatter' g-buffer, which holds the information about the scene for rendering/post effects.

So while the workload is somewhat lessened from prepass lighting(less duplication of geometry rendering, for example) the amount of data passed in a big chunk is higher, depending on how heavy the g-buffer is. On modern hardware, this really isn't a problem, but on older or weaker hardware, such as integrated chips, the extra bandwidth load hits it harder than just crunching pure geometry would.

That said, while tracking down the oddities that Duion and some of the others noted with deferred/linear changes that went into 3.9 we noted several spots where the texture format is higher than it needs to be for most cases. So we're looking at trimming down those spots, which will make the gbuffer a good deal leaner, and thus make a solid improvement to performance, especially on older or weaker hardware. Right now the high precision targets being used help things look good, but at the cost of performance, so striking a balance, or letting it be controlled by preferences for those that need/want speed over looks have that option.

[flysouth]

Thaks @JeffR for that detailed explanation :)