Jump to content

ver 3.9 fps poor


flysouth

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

beach1.jpg.0ef2fc6bb1f114f3a77cad088b6e53ed.jpg

beach.jpg.14cdd0e4210317b6ee14bc9b5844c311.jpg

Edited by flysouth
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...