hobomaster22

It’s been a while since I’ve look at how CRTs work internally but I’m pretty sure it’s not any different than an LCD in this respect. It has an internal mesh that determines the pixel resolution. In the OS you could select different resolutions but it had a maximum native resolution. Anything under the maximum was just being upscaled to the native resolution. The native resolution you want to emulate would determine the number of rows/columns for your filter.

Technically the output from the source port practically doesn’t matter. To be accurate depends on the resolution of the monitor you are trying to emulate. CRT monitors could have been 1024x768 or 1600x1200 for example. I believe most of my CRT doom experience was with a 1600x1200 19” Dell.

Helion doesn't handle it at all. I see why and will have it fixed soon. Thanks for reporting! I also didn't know it worked with secrets so I learned something today :)

Thanks, I see what the problem is. If a wad has a dehacked patch then Helion overwrites the flags to support dehacked pickups since Doom based them on sprite. This doesn't carry over the dropped flag being set resulting in twice the ammo being picked up. Will be fixed for the next release.

The original smoothdoom being for GZDoom would require a lot of investment in GZDoom features that we do not have any intention at implementing currently. The focus is on everything through MBF21. Supporting Voxels is certainly something Helion will do in the future.

Also if you are using a port that saves screenshots using print screen will automatically import the image to Doom Launcher.

Sorry, not in the next release. More bug fixes and features :)

Thanks for checking into this. I will have to see if anything comes up. The next release for Helion actually has some big changes for map loading so that it can display loading screens. I will try to create a new Linux build tomorrow if you would like to try it. If the problem still persists then I can investigate further.

Currently it is only a Doom port and has no plans for supporting the others. There is a lot to do, and I personally do not have interest in the other games as I only had Doom itself when I was young. This could change in the future, but for now Helion will be Doom only.

Helion had a hidden feature for debugging special activations and triggers. I have cleaned this feature up and made it more user friendly. This previously came in handy when I thought I encountered a bug. It's also great for determining how to advance in a map and secret hunting. This works in both directions. You can press use on a sector and it will mark the activation, and pressing/bumping a use line will show what that line activates. A huge pain point was debugging boom maps that relied on complex triggers with voodoo doll closets on scrolling floors. Helion is now capable of detecting voodoo doll closets and will traverse them to show the trigger chains both in game and in the automap. An example of this trigger chain is at the 30 second mark in the video below. I have also implemented animated skies that were not previously supported and this map happens to showcase this feature as well.

I forgot crouch was in the key binding configuration. As far as I know crouch was never implemented, so that might explain why it's broken :P

Didn't see this until now, probably because it was an edit. Helion should be fine on a USB drive, I just tested it on my laptop. It's hard to say what the problem might be. I've tested on other 4GB systems, which is the lowest memory size tested and it works on those. If it has the the roughly 100MB of space available might be worth trying running it on the drive directly.

It would be more useful as a credit screen. I don't think any of the multiplayer ports support enddoom. Could have it for both.

I will have to add a check for setting the mouse wheel. It looks like the way the keys are being cleared in the config makes the initialization function think it needs to update the config with defaults. I can fix this for the next release. The config needs the keys set to nothing to know that is a user configuration setting and not that it was part of an update like this: Left = [""] Right = [""] As for the mouse wheel up/down are they possibly bound to multiple functions? Whichever one it hits first will eat it so the next command will not be able to execute on it. For example, if you have MouseWheelUp set to NextWeapon and also Use it will get eaten by the NextWeapon command. The key binding menu checks for this and will unbind the old one.

Helion 0.9.2.3 This release fixes many bugs that have been found through testing various wads. Thanks @Shepardus @Darkcrafter07 and @TruthInFiction for the reports and anyone else I may have missed. Special thanks to @faad3e for play testing and finding bugs making this release even stronger.

That's interesting. It seems to be crashing printing the OpenAL extensions, and according to their documentation this shouldn't be null. Could you try removing that line and also the code from this function that uses the same call? If that works I can put in a fix for it.

Thanks, I did some digging and the calculation for explosion damage is incorrect. Doom used this approximate distance calculation, but the explosion damage calculation doesn't use this function and just picks the larger difference. Looks like I assumed it was the approximate distance calculation function so I will have to code out the same thing.

It's not the maximum it can reach, but it's pretty close given the implementation Helion is using right now. Implementing real frustum culling might help, but since the calculations per sprite are very minimal it could actually end up being more expensive than just calculating the vertex anyway. To get more speed we would have to do a drastic implementation change, and would likely require features from OpenGL 4.x. Since everything is absurdly fast by comparison, the path for now will be to fix bugs and work on more QOL features.

Thanks, will get this fixed for the next release.

Hmm the chainsaw appears to be pulling towards the enemy for me. The barrels respect the OLDRADIUSDMG flag and use Doom's original jank distance calculation. There is also an integration test for this, which I believe is the barrel chain from TNT. Did you find a specific scenario that wasn't working?

Did you run the build with or without the runtime? Edit: I just went and verified them both from Github and for some reason the one without the runtime was smaller than the one in my publish folder and indeed does not work. I uploaded the build again and verified it works from Github now. Not sure what happened with that, but it should be good now.

Yeah, it appears our internal definition only has NOBLOCKMAP set but not NOSECTOR so that will need to be fixed. I still need to check if modifying the TNT1 sprite should result in rendering the sprite, kind of strange a case and it doesn't appear to be an intentional thing in the dehacked.

Looks like the dehacked file is modifying S_TNT1 (for no reason?) and it's breaking the do not render check so the teleport landings are rendering the shotgun sprite. Frame 967 Sprite number = 1

For the damage calculation, the modulus and multiplication values of 5 and 3 were swapped. I went over all the damage functions since the chainsaw damage was found to be off. This one wasn't noticeable because with the randomization it works out to be 10 points of damage on average instead of the 9 using Doom's calculation. Ambient occlusion is not against the principle of Helion. I have actually thought about AO and I can see it being an option in the future. We just have to prioritize with the other QOL and features that Helion needs.

Going to Options -> Render -> VSync and setting to on/adaptive will limit the CPU usage.