hobomaster22

No problem! It is less bandwidth and from an implementation standpoint much simpler. I didn't mean to say p2p was better than having a client/server solution like Odamez/Zan/ZDaemon, but significantly simpler to implement so we should support it. It has it's own set of issues and limitations but a full client/server solution would become an entire project in itself.

Yes it's definitely on the list. We will likely be looking at it after this next release is completed.

I think for one it's because it was the way it has always been done. Every other source port was based off another at some point, and it's already there. It's difficult to take the existing code base and completely gut the fundamental rendering method. This was one of the main reasons we started from scratch. We didn't want to be burdened with a code base that was intertwined with the BSP for rendering. Starting from scratch is a massive undertaking in itself even if you use the BSP tree like we did from the start. Second, people didn't seem to think ditching the BSP could be done. I known I've seen posts saying it's not feasible in the past. It has been pretty difficult, given Doom's nature of everything is dynamic and you can't safely assume something will be static. Add this with it's rendering quirks and bugs that map makers rely on as features and trying to adopt a more modern approach to rendering starts to crumble. Sprite rendering is expensive, flood filling is expensive, and Boom's 242 transfer heights special is an absolute nightmare. While this method is the optimal route, it's really hard to get right. It's a lot easier to wipe the slate clean, traverse the BSP, and dump the data out. Any changes that may have happened since the last render will be reflected. For example light changes with this method are free. You just read whatever the light level happens to be. For Helion we have to do something with our state to deal with these changes. And up until the last release this was incredibly expensive to deal with. This is one of the main reasons React was created for web development. Manipulating the DOM in javascript made UI state management difficult and more problematic the more things were modified.

We would likely implement the lock step multiplayer that most ports have first. The improvement would really be the rendering improvements that Helion has. Coop would be playable on large maps with relatively slow hardware, whatever junk laptops you have lying around would likely be fine. We have been looking into what the bottlenecks slow GPUs have like the Radeon HD 8400 in our benchmarks. Without spoiling too much, in our testing we have increased the performance another 30-70% depending on the map thanks to two optimizations in our rendering techniques. Sunlust MAP28 and Frozen Time were already playable above 60fps on junk hardware anyway. But we really wanted to push Summer of Slaughter MAP32 into more playable territory on trash hardware. Most of Sunder is playable. Something exciting about pushing the limits this hard.

They are different, the naming is kind of dumb. The desktop one is basically the runtime for Windows dependencies that we still have hanging around. For the next release we are looking at nuking this entirely since .net7 finally lets us build an entire package without requiring the runtime. This requires removing the final windows dependencies once and for all (which needs to happen anyway).

Thank you, this means a lot. Funny enough, I finally played Frozen Time from start to finish last month since I could actually get the steady 200FPS with Helion. Had no idea about the whole clock ending sequence which was pretty cool. It also allowed me to slog through SoS MAP32, took quite a bit of time.

Helion 0.9.1.6 Benchmarks An exciting update. We have removed the lighting update bottleneck! This was a difficult problem to solve and was previously very expensive to deal with. Given Doom's nature of changing things at runtime in no predictable way and Boom maps that use scripted closets that change light levels all the time. Previously processing a sector light change involved touching all vertex data with the sector and uploading it back to the GPU. Maps like Micro Slaughter Community Project MAP02 @Bauul suffered huge FPS drops and would feel choppy because it would update roughly 6,000 sectors per game tick. Helion would spend about 20% of CPU time just calculating light updates on a Ryzen5900HS. With Helion 0.9.1.6 it now spends less than 0.5% CPU processing light updates, and the expensive uploads the GPU are gone. This is huge because it now brings even more maps into the playable FPS range on slower GPUs, and fast GPUs won't experience a choppy feeling even though the average FPS may be very high. The technical details with the light update: Each vertex gets mapped to a light index. We maintain an array of light values that get updated each tick and then upload that one array to the GPU. The shader will fetch that index to use as the render light level. With our benchmarking tests it is practically free (more on that below). We have done some benchmarking collecting average FPS values on various test systems with Helion 0.9.1.6, dsda-doom 0.26.2 and GZDoom 4.10.0. We wanted to get some hard numbers down to see where everything stands on various hardware. Each sheet is the test system and labeled by it's GPU. The slowest system is a laptop from 2013 running an AMD Radeon HD 8400. This updates puts two of the benchmark maps into the easily playable range (Micro Slaughter Community Project MAP02 at 122 FPS and Dance on the Water MAP01 at 74 FPS). One of the most interesting points we discovered is the Radeon 6700 suffers massively with dsda-doom and GZDoom using OpenGL. Most are aware of AMDs terrible OpenGL support. What was really surprising here is that Helion didn't appear to suffer any loss even though we are using OpenGL 3.3. Helion's numbers for the Radeon 6700 fall between the RTX 3070 Ti and Mobile RTX 3070 which is in line with the relative performance of the GPUs. Switching GZDoom to Vulkan increases it's performance on the 6700 and puts it line as well. Another interesting one is Occula RC MAP31. This maps seems to crush dsda-doom and GZDoom especially hard and I'm not sure why. It does have a significant number of visible sectors and lines but has half the line count of SoS Boom MAP32 which saw better performance. While both get high performance Helion the opposite is true where Occula Map31 performed significantly better than SoS Boom MAP32, which makes sense purely from a perspective of map complexity in terms of line/vertex counts.

Thanks, I have not heard of this one. Do you know if this is an intended feature or some side effect? Sounds very strange. I'm going to have to research the code to see exactly how/why this works.

There is not at the moment. Boom and MBF is fully supported except for colored sectors ad the door light special. The original intention was to fully support decorate but things have changed as the engine has been developed. Fully implementing decorate is too much and not on the table right now. The current goal is to support vanilla, Boom and MBF21 to the fullest extent that we can. Like I explained above, the best path would be to use DECOHack to write decorate like code that gets translated to dehacked. Using DECOHack would ensure the features being used are supported by Helion and would work in other MBF21 ports like dsda-doom.

It’s not compatible. Helion doesn’t support GZDoom features. It currently supports a subset of ZDoom features so that we have Boom and MBF21 compatibility.

Go to the IWAD tab and select Doom 2. Then click 'Select Individual Files' and make sure DOOM2.wad is selected.

You can just replace dsspisit with an empty file in your wad. This will override the sight sound for the spider mastermind and play nothing.

OpenGL 3.3 goes back to about 2009. Most GPUs from that period don’t have the pipelines to push high framerates in Helion anyway. OpenGL 2 is too limiting and supporting such ancient hardware would be pointless given the poor performance. I have a low end laptop from 09 and it gets about 100fps on E1M1. Sunder maps can get above 30fps but the high monster counts eat so much CPU time that the frame rate tanks when the monsters wake up. Even cheap hardware from around 2014 makes a huge difference, and that’s almost a decade old hardware. My wife’s old low end laptop from 2014 plays Eviternity MAP28 above 100 fps.

Doom Launcher saves backups of the database. If you are using the installed version it's installed in C:\Users\your_user_name\AppData\Roaming\DoomLauncher\Backup. Otherwise it would be in the Backup folder of your DoomLauncher folder. In the app folder rename the DoomLauncher.sqlite file to something like DoomLauncher_save.sql to be safe. Then copy the latest backup and rename it to DoomLauncher.sqlite.

There is R3Edit which you could launch directly with Deepsea that gave the 3D editing functionality. This is the only other 3D editing I can think of outside of Doom Builder.