by dpJudas » Thu Jul 25, 2019 1:29 pm
GRAU wrote:i dont understand people with position "new is nice, old is not nice". If an old one version had nice performance with nice picture - why new versions of gz has no that performance with the same picture? the only problem of qz for me is wrong angle of objects and dynligfhts rendered in the mirror. i had no special settings, tried to delete inis, and set 1024x768 (no poligonal no truecolor) in both ports, then 800x600 in both qz and gz g3. no. gs has problems on both pentioum dual core and on pentium 4.
The drawers and backend of QZDoom/GZDoom has gone through many iterations since the first QZDoom release. There are technical reasons why that happened that does not allow us to go back. For example, one version of QZDoom relied heavily on llvm and that library turned out to be a nightmare to link up against.
Another change is that Direct3D was dropped, which at the time seemed not a big deal but we've since discovered OpenGL drivers perform significantly worse for the usage pattern of the software renderer.
Last there's the fact that the software renderer's performance is usually profiled on my computer, which is not using a Pentium 4. It used be an Intel i7 haswell, and now it is an AMD Threadripper 32C/64T CPU. Simply put, my CPU is over 32 times as powerful as your Pentium 4, so I might not notice if an inefficiency is introduced in a drawer. On my computer the bottleneck is elsewhere in the renderer at this point.
Long story short, your hardware is simply too old compared to mine. The operating system, Windows XP, is also too old for Microsoft, which means our future code changes might not even compile on a compiler for such a dated operating system. None of us are intentionally trying to make newer GZDoom run poorly on your computer, but that's inevitable consequence of the big changes to hardware since then. That said, the polybackend branch does try to address the Direct3D performance drop we introduced, so at least there it should improve a little bit when that one day gets merged into master.
As for the color problem with the voxels, I believe that's a bug and should be reported with a minimal test example pk3.
[quote="GRAU"]i dont understand people with position "new is nice, old is not nice". If an old one version had nice performance with nice picture - why new versions of gz has no that performance with the same picture? the only problem of qz for me is wrong angle of objects and dynligfhts rendered in the mirror. i had no special settings, tried to delete inis, and set 1024x768 (no poligonal no truecolor) in both ports, then 800x600 in both qz and gz g3. no. gs has problems on both pentioum dual core and on pentium 4.[/quote]
The drawers and backend of QZDoom/GZDoom has gone through many iterations since the first QZDoom release. There are technical reasons why that happened that does not allow us to go back. For example, one version of QZDoom relied heavily on llvm and that library turned out to be a nightmare to link up against.
Another change is that Direct3D was dropped, which at the time seemed not a big deal but we've since discovered OpenGL drivers perform significantly worse for the usage pattern of the software renderer.
Last there's the fact that the software renderer's performance is usually profiled on my computer, which is not using a Pentium 4. It used be an Intel i7 haswell, and now it is an AMD Threadripper 32C/64T CPU. Simply put, my CPU is over 32 times as powerful as your Pentium 4, so I might not notice if an inefficiency is introduced in a drawer. On my computer the bottleneck is elsewhere in the renderer at this point.
Long story short, your hardware is simply too old compared to mine. The operating system, Windows XP, is also too old for Microsoft, which means our future code changes might not even compile on a compiler for such a dated operating system. None of us are intentionally trying to make newer GZDoom run poorly on your computer, but that's inevitable consequence of the big changes to hardware since then. That said, the polybackend branch does try to address the Direct3D performance drop we introduced, so at least there it should improve a little bit when that one day gets merged into master.
As for the color problem with the voxels, I believe that's a bug and should be reported with a minimal test example pk3.