GZDoom 3.7.2 modern vs Zandronum 3.0
-
- Posts: 571
- Joined: Sat Sep 23, 2017 8:42 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
So I conducted another crazy experiment. The map was converted to MD3 and placed as a 3d model into an empty squarish map. It's significantly faster than its WAD counterpart. The lowest framerate I had was 90.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
That's not surprising. Unfortunately it's not of much use in that form.
-
- Posts: 571
- Joined: Sat Sep 23, 2017 8:42 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Yeah, can be used for skybox though. More on that, I tried a new experimental K8Vavoom with the map and it was even slower with lots of 3d floors just absent.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Vavoom is probably the slowest Doom port around, thankfully ketmar is working on speeding it up as much as possible but that's going to take a pretty long time.Darkcrafter wrote:Yeah, can be used for skybox though. More on that, I tried a new experimental K8Vavoom with the map and it was even slower with lots of 3d floors just absent.
I think the model runs faster because it's a LOT less drawcalls, in fact, i think it's just one drawcall instead of one per line like in regular maps. As Graf said, it's entirely useless because if you were to map the collision using regular map geometry, you would basically make the game even slower because it still has to render the map version and the model version at the same time.
Maybe mapping it with bridge things could help? Just make custom actors that are very fat (as fat as the wall needs to be) and same height too, and use them to map the collision in your map. I was doing this with a Super Mario 64 map but i'm very lazy so i stopped.
-
- Posts: 2119
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
The problem here isn't the drawcalls themselves that much, it's traversing the BSP and reuploading all the geometry to the GPU every frame. BSP traversal and geometry uploading are extremely slow. Models have no BSP to traverse, and they only have to be uploaded once.TDRR wrote:I think the model runs faster because it's a LOT less drawcalls, in fact, i think it's just one drawcall instead of one per line like in regular maps. As Graf said, it's entirely useless because if you were to map the collision using regular map geometry, you would basically make the game even slower because it still has to render the map version and the model version at the same time.
I also very much doubt it's one drawcall per line. That would be absurdly bad coding. You'd put several lines in a VBO and draw them all at once with a single drawcall.
-
- Posts: 823
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Well don't know about that, i'm not really a coder but Graf once said it was one drawcall per line (or something similar), but that was quite some time ago so don't know if that's still true.phantombeta wrote:That would be absurdly bad coding. You'd put several lines in a VBO and draw them all at once with a single drawcall.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Models are one drawcall per surface group, i.e. everything that uses the same properties and is grouped together in the model definition.phantombeta wrote: I also very much doubt it's one drawcall per line. That would be absurdly bad coding. You'd put several lines in a VBO and draw them all at once with a single drawcall.
No. The slowest port by a wide margin is Doomsday, it has been for more than 15 years and never got optimized - it only got useless clutter added over time.TDRR wrote: Vavoom is probably the slowest Doom port around, thankfully ketmar is working on speeding it up as much as possible but that's going to take a pretty long time.
-
- Posts: 571
- Joined: Sat Sep 23, 2017 8:42 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Is there any option to load map geometry just once and do every moving part by MD3 models with scripts?
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
-
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Most "can't you just do X?" solutions fall apart fairly quickly once you consider that any given sector of the map can be arbitrarily manipulated using ACS or ZScript. It's not like post-Doom games where there's a static world with distinct dynamic objects for doors - every part of a GZDoom map can technically be a dynamic object!Darkcrafter wrote:Is there any option to load map geometry just once and do every moving part by MD3 models with scripts?
There's been some mumbling about ways to improve the situation in the past, but it's not a trivial issue to tackle and there have been other, far more fun challenges for the coders to take on recently.
-
- Posts: 571
- Joined: Sat Sep 23, 2017 8:42 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
-
- Posts: 6634
- Joined: Mon Jul 26, 2004 12:59 pm
- Location: Growing from mycelium near you.
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Got a related question. What's the CPU requirement for GZDoom? I have a HP Omen laptop with a i7-8750H 2.2 GHz (4.1 GHz turbo) Hexcore and it struggles to load Hell-Forged with even with Software rendering compared to my Desktop with a i7 6700k 4.0 GHz (4.2 GHz turbo) Quadcore. Both have a GTX 1070, and the laptop actually has double my Desktop's RAM (32 GB vs 16 gbs). Both running the game at 1080p. The laptop would take like 2-3 minutes just to load one of Hell-Forge's maps, with tons of in-game stuttering. But the Desktop loads immediately and runs at like 3-400 FPS. Putting it in FSW mode helps with the laptop a bit, but it still stutters a lot.
A second question is how is the Multiplayer capabilities with modern GZDoom vs. Zandronum? I'm assuming Zand has all of the old Skulltag stuff and more ontop by now? Can GZDoom do that yet?
A second question is how is the Multiplayer capabilities with modern GZDoom vs. Zandronum? I'm assuming Zand has all of the old Skulltag stuff and more ontop by now? Can GZDoom do that yet?
-
- Posts: 1906
- Joined: Wed Oct 11, 2006 10:39 am
- Location: at home.. Status: lazy like hell
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
With laptops, thermal throttling and power saving options in the OS can be the bane of performance. There's more to it but I found those two to be main culprits after simply having a weaker chip altogether. Also don't forget about overhead from things like active file protection software (ie Avast!)
As far as I know Zandronum has stripped away a lot of the old Skulltag bloat but it is still built on top of it. I'd also like to learn more about the current state of Client-Server networking in GZDoom, I know there have been experiments and that there's a command line argument to use it but I believe it is not ready for mass use yet.
As far as I know Zandronum has stripped away a lot of the old Skulltag bloat but it is still built on top of it. I'd also like to learn more about the current state of Client-Server networking in GZDoom, I know there have been experiments and that there's a command line argument to use it but I believe it is not ready for mass use yet.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
It depends on the maps you want to play, so there is no perfect answer.Amuscaria wrote:Got a related question. What's the CPU requirement for GZDoom?
This sounds like a hard drive performance problem. Also, if the laptop only has a GTX 1070M, those M versions of a GPU have significantly lower performance tha n´the real deal, but that's not the issue here.Amuscaria wrote:Both have a GTX 1070, and the laptop actually has double my Desktop's RAM (32 GB vs 16 gbs). Both running the game at 1080p. The laptop would take like 2-3 minutes just to load one of Hell-Forge's maps, with tons of in-game stuttering. But the Desktop loads immediately and runs at like 3-400 FPS. Putting it in FSW mode helps with the laptop a bit, but it still stutters a lot.
-
- Posts: 571
- Joined: Sat Sep 23, 2017 8:42 am
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
Re: GZDoom 3.7.2 modern vs Zandronum 3.0
Well I ended up making an "optimized" version of the map. It has now lots of visual portals and 3d floor based silent teleports that I managed to trim down using dummy control chambers so they are now kind of limited in height but all this stuff for sure has its own bad consequences like things disappear behind a portal, and noticeable seam during the passage but thanks to less 3d floors concentration in one area taken it's now playable on nvidia 840m card at 25 to 144 fps depending on a case at 720p. Add a dynamic skybox with 3d mountains models in it (about 50k faces in overall) it's blazing fast compared to the non-optimized map counterpart.
Actually I think GZDoom is still the best engine regarding optimization, all the rest just don't render the things GZDoom does and yet GZDoom works just as fast if not faster.
Actually I think GZDoom is still the best engine regarding optimization, all the rest just don't render the things GZDoom does and yet GZDoom works just as fast if not faster.
Spoiler: