qweqioweuo123 Posted August 23, 2019 (edited) can the modern ryzen cpus run super complex maps with tons of enemies in smooth fps? maybe we can take advantage of new cpus to create insanely big maps with 1000000000000s of enemies i remember back then with my quadcore from 2008 i had problems with deus vult (the one which had to be split in 5 maps because it was too big) Edited August 23, 2019 by qweqioweuo123 0 Quote Share this post Link to post
Dark Pulse Posted August 23, 2019 Load NUTS.WAD. Fire. ??? Profit! 5 Quote Share this post Link to post
Andromeda Posted August 24, 2019 I recently had the chance to test Sunder MAP14 on a pretty much top of the line consumer PC (i7-9700K/RTX 2080 Ti/32GB DDR4 RAM/512GB PCIe SSD) using GLBoom+ 2.5.1.4 and surprisingly it failed to deliver a stable framerate when overlooking the background by the yellow key area. On the other hand, NUTS.WAD, which is frequently mentioned as a framerate killer, runs like butter on my low-end laptop (i3-5010U/920M/8GB DDR3 RAM/240GB SSD) using the same source-port. So, at least in the case of this source-port, the layout's complexity seems to be much more taxing on hardware than the number of enemies in a given level, from my perspective as a layman on the matter. 0 Quote Share this post Link to post
qweqioweuo123 Posted August 24, 2019 55 minutes ago, Andromeda said: I recently had the chance to test Sunder MAP14 on a pretty much top of the line consumer PC (i7-9700K/RTX 2080 Ti/32GB DDR4 RAM/512GB PCIe SSD) using GLBoom+ 2.5.1.4 and surprisingly it failed to deliver a stable framerate when overlooking the background by the yellow key area. On the other hand, NUTS.WAD, which is frequently mentioned as a framerate killer, runs like butter on my low-end laptop (i3-5010U/920M/8GB DDR3 RAM/240GB SSD) using the same source-port. So, at least in the case of this source-port, the layout's complexity seems to be much more taxing on hardware than the number of enemies in a given level, from my perspective as a layman on the matter. did you try gzdoom? 0 Quote Share this post Link to post
Magicana Posted August 24, 2019 I crashed my source port trying to run Nuts.wad with Brutal Doom... But that's more on Brutal Doom than anything else. 0 Quote Share this post Link to post
geo Posted August 24, 2019 3 hours ago, qweqioweuo123 said: can the modern ryzen cpus run super complex maps with tons of enemies in smooth fps? maybe we can take advantage of new cpus to create insanely big maps with 1000000000000s of enemies i remember back then with my quadcore from 2008 i had problems with deus vult (the one which had to be split in 5 maps because it was too big) That's Nuts! 0 Quote Share this post Link to post
ketmar Posted August 24, 2019 (edited) it doesn't really matter how much cores your CPU have: Doom playsim is strictly sequential, and cannot be parallelised with multithreading. another problem is GPU: Doom environment is highly dynamical, so it is very hard to upload the map onto GPU and forget about it. most of the time you have to re-upload parts of the geometry again and again, and this is not the use case for which modern GPUs were designed. also, modding support makes a HUGE difference here too. GZDoom, for example, executes most of the game logic with internal virtual machine, while PRBoom is using C, compiled to optimised machine code. sure, GZDoom is using JIT to make things faster, but this is still much slower than pure C. especially considering the fact that PRBoom doesn't have to call alot of modding hooks on its way. tl;dr: no, modern multicore CPUs doesn't help much. the whole engine should be designed from the ground up with parallel execution in mind, otherwise it will only use one core to do most of its work. Edited August 24, 2019 by ketmar 5 Quote Share this post Link to post
Get Phobo Posted September 3, 2019 (edited) On 8/24/2019 at 2:06 AM, Andromeda said: I recently had the chance to test Sunder MAP14 on a pretty much top of the line consumer PC (i7-9700K/RTX 2080 Ti/32GB DDR4 RAM/512GB PCIe SSD) using GLBoom+ 2.5.1.4 and surprisingly it failed to deliver a stable framerate when overlooking the background by the yellow key area. On the other hand, NUTS.WAD, which is frequently mentioned as a framerate killer, runs like butter on my low-end laptop (i3-5010U/920M/8GB DDR3 RAM/240GB SSD) using the same source-port. So, at least in the case of this source-port, the layout's complexity seems to be much more taxing on hardware than the number of enemies in a given level, from my perspective as a layman on the matter. Try map 15, it's even worse. All ports have difficulties with such large and complex maps. I tried it with Crispy Doom 5.6.1 (software), GLBoom+ 2.5.17 (OpenGL on Intel graphics), and GZDoom 4.2.0 (Vulkan on GTX), and they all fell way below 10 fps in the most demanding scenes, no matter the renderer and GPU used. Crispy got down to less than 6 fps and GLB and GZD to even less than 2 fps. EDIT: I also tried map 15 with Doom Retro 2.9.3 using the Direct3D API. I got 40+ fps in all places. However, noclipping through the walls got the game down to 2 fps as well. Edited September 3, 2019 by Get Phobo 1 Quote Share this post Link to post
Andromeda Posted September 3, 2019 6 hours ago, Get Phobo said: Try map 15, it's even worse. All ports have difficulties with such large and complex maps. I tried it with Crispy Doom 5.6.1 (software), GLBoom+ 2.5.17 (OpenGL on Intel graphics), and GZDoom 4.2.0 (Vulkan on GTX), and they all fell way below 10 fps in the most demanding scenes, no matter the renderer and GPU used. Crispy got down to less than 6 fps and GLB and GZD to even less than 2 fps. EDIT: I also tried map 15 with Doom Retro 2.9.3 using the Direct3D API. I got 40+ fps in all places. However, noclipping through the walls got the game down to 2 fps as well. It's a shame, the engine definitely doesn't scale well for these ultra high detail levels :/ 1 Quote Share this post Link to post
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.