Nugget Doom 3.0.0 (updated March 17th, '24)

[Alaux]

On 9/11/2023 at 11:32 PM, nickxcom said:

Is there any way to pick a soundfont/midi player on Linux? I get a "fluid synth" missing pop up on launch. I guess I am also curious where the local files/config are saved on Linux, if anyone can help there :)

I'm afraid I can't help with that. Maybe you can, @rfomin?

[plums]

On 9/12/2023 at 2:32 AM, nickxcom said:

Super excited to see an AppImage for ease of use on Steam Deck! Is there any way to pick a soundfont/midi player on Linux? I get a "fluid synth" missing pop up on launch. I guess I am also curious where the local files/config are saved on Linux, if anyone can help there :)

To answer both your questions: edit ~/.local/share/nugget-doom/nugget-doom.cfg, search for soundfont_dir, and change it to a directory that has one or more .sf2 files.

 

(This is for a non-AppImage build, hopefully you can figure it out if it's not the same for the AppImage)

[Lila Feuer]

Since you can disable berserk tint and invul colormap will there be one to turn off the radsuit tint? I'm using powerup timers which is honestly a great idea, I also take a lot of screenshots but typically avoid any screen tinting effects because they don't make for particularly good scenes.

[Alaux]

14 minutes ago, Lila Feuer said:

Since you can disable berserk tint and invul colormap will there be one to turn off the radsuit tint? I'm using powerup timers which is honestly a great idea, I also take a lot of screenshots but typically avoid any screen tinting effects because they don't make for particularly good scenes.

I think the radsuit effect is the only palette/colormap effect without a dedicated toggle, so I could very well just give it one and get rid of the general "no palette changes" toggle.

 

That said, maybe there could also be a setting to disable palette effects when taking screenshots, affecting normal or clean screenshots or both depending on its value. What do you think, @fabian?

[fabian]

Yes sure, sounds like a good idea. I even think it should affect clean screenshots by default, but not apply to regular ones. 

[fabian]

Et voila

https://github.com/fabiangreffrath/woof/commit/3de298f8947e684d0c4d54f96a50db7726b14b63

[Alaux]

On 9/14/2023 at 4:24 AM, Lila Feuer said:

Since you can disable berserk tint and invul colormap will there be one to turn off the radsuit tint?

Done. I also implemented that screenshot palette effects setting I mentioned, so you won't have to disable the radsuit effect permanently for the sake of not having it in screenshots.

[nickxcom]

On 9/13/2023 at 7:51 PM, plums said:

To answer both your questions: edit ~/.local/share/nugget-doom/nugget-doom.cfg, search for soundfont_dir, and change it to a directory that has one or more .sf2 files.

 

(This is for a non-AppImage build, hopefully you can figure it out if it's not the same for the AppImage)

Thank you so much!! Updated my directory and it works fine now ❤️

[SoDOOManiac]

Is the spectre fuzz effect scaled with 4x and 8x resolution in Nugget Doom?

I received a suggestion for So Doom that with 4x resolution the fuzz effect is too fine-grained, and the fuzz pixels should be at least doubled.

I'd like to suggest this feature for Nugget Doom if it's not implemented or ask for permission to use it in So Doom if it's already a thing.

[Alaux]

3 minutes ago, SoDOOManiac said:

Is the spectre fuzz effect scaled with 4x and 8x resolution in Nugget Doom?

I received a suggestion for So Doom that with 4x resolution the fuzz effect is too fine-grained, and the fuzz pixels should be at least doubled.

I'd like to suggest this feature for Nugget Doom if it's not implemented or ask for permission to use it in So Doom if it's already a thing.

The effect is only scaled if Blocky Spectre Drawing ("fuzzcolumn_mode" in the config file) is enabled. It results in fuzz being scaled as if you were in 1X resolution -- blocky indeed.

 

Not sure if that's what you want, but if it is, I believe you should ask @ceski for permission if you insist.

[SoDOOManiac]

2 hours ago, Alaux said:

The effect is only scaled if Blocky Spectre Drawing ("fuzzcolumn_mode" in the config file) is enabled. It results in fuzz being scaled as if you were in 1X resolution -- blocky indeed.

 

Not sure if that's what you want, but if it is, I believe you should ask @ceski for permission if you insist.

 

Thanks a lot!

[ceski]

6 hours ago, SoDOOManiac said:

Is the spectre fuzz effect scaled with 4x and 8x resolution in Nugget Doom?

I received a suggestion for So Doom that with 4x resolution the fuzz effect is too fine-grained, and the fuzz pixels should be at least doubled.

I'd like to suggest this feature for Nugget Doom if it's not implemented or ask for permission to use it in So Doom if it's already a thing.

 

Both Nugget Doom and So Doom are GPLv2 so you're good to go. The usual practice I see for crediting others is to leave the copyright block intact when you're copying entire files or, if it's only a few lines of code, add a comment above it that gives credit. I've also seen projects include a list of credits in the README.md or CREDITS.md. The way Woof and Nugget do it seems reasonable to me. Have fun.

[Lila Feuer]

The track on MAP17 of Plutonia 2 hung after 16 minutes of play, I feel like this issue is as old as Woof! itself and I don't know if it's ever been solved or if it's worth reporting at this point. It could just be VirtualMidiSynth being retarded, but I thought I'd mention it anyway. It's as easy as saving the game and quitting and going back in and things are fine. This is the only time a track has hung during this entire playthough, so it is quite rare.

[Alaux]

10 minutes ago, Lila Feuer said:

The track on MAP17 of Plutonia 2 hung after 16 minutes of play, I feel like this issue is as old as Woof! itself and I don't know if it's ever been solved or if it's worth reporting at this point. It could just be VirtualMidiSynth being retarded, but I thought I'd mention it anyway. It's as easy as saving the game and quitting and going back in and things are fine. This is the only time a track has hung during this entire playthough, so it is quite rare.

I use VMS too, and I can confirm that I've been running into the exact same issue for quite a while. I've no idea of what's up, I never bothered with it because it's not too common.

[fabian]

15 hours ago, Lila Feuer said:

The track on MAP17 of Plutonia 2 hung after 16 minutes of play, I feel like this issue is as old as Woof! itself and I don't know if it's ever been solved or if it's worth reporting at this point. It could just be VirtualMidiSynth being retarded, but I thought I'd mention it anyway. It's as easy as saving the game and quitting and going back in and things are fine. This is the only time a track has hung during this entire playthough, so it is quite rare.

 

@ceski any idea what's happening here? 

[Alaux]

2 minutes ago, fabian said:

 

@ceski any idea what's happening here? 

I later realized that I wasn't using the latest version of VMS, and my dependencies are probably outdated too (I use my own builds). Not sure about @Lila Feuer's case, though.

[ceski]

1 hour ago, fabian said:

 

@ceski any idea what's happening here? 

I can't reproduce it. There's been a year of improvements to MIDI for Woof, all inherited by Nugget. I reported a serious bug to the VMS author during that time and it was fixed in a recent release. So with that in mind, please provide some basic info @Lila Feuer: Did this happen recently? Does it happen every time, at 16 minutes, on the same map and wad? What version of Nugget, or was it Woof? 32/64-bit? What version of VMS? What soundfont? What OS? 32/64-bit? Any other details? e.g. Did you notice any errors printed in the Nugget/Woof console? Do you have the same issue with other ports?

[Lila Feuer]

@ceski Completely random, and yes this is the first time it's happened since switching to Nugget. I'm having a continuous playthrough so it was on my first attempt, never died, just needed to save and quit after 16 minutes in. Was on the map for another 18 minutes or so before finishing it and it never happened again. I should mention this is the first PWAD I've tried with custom music with Nugget, I went through Doom II ritualistically and none of the tracks hung in that. 64-bit latest Nugget, my VMS is probably one update behind so maybe that's the catalyst? I'm using the OPL3 FM 128MB soundfont for its "authenticity" of what most people were probably hearing. 64-bit Windows 10. Wasn't aware Nugget had a console! I've only had this hangup in Woof! btw.

[Alaux]

1 hour ago, Lila Feuer said:

Wasn't aware Nugget had a console!

We're not referring to a console like ZDoom's, but rather output to the OS console/terminal. My terminology might be wrong, but I hope you get the idea.

[Lila Feuer]

It's such a relief knowing that you got all of something with the message announcements in this port, considering that is when I save my game the vast majority of the time. I also can't get over the satisfaction of SSG gibbing popcorn enemies and even the chainsaw.

[Alaux]

Nugget Doom 2.2.0 has been released!

 

To begin with, changes from Woof! 12.0.0 have been merged, meaning that we've gotten stuff like 3D Audio, PC Speaker emulation, obituaries and a fix for a pesky crash when loading savegames.

 

As for Nugget's own changes, just a few highlights:

• Setting to Organize Saves by IWAD
• Explosion Shake Effect
• Improved fuzz effects, by @ceski
• Autoload folder for all games
• Fixed powerup pickup sound not playing sometimes
• Fixed some buggy cheat key bindings

 

DIRECT DOWNLOADS:

Windows 32-bit Standalone

Windows 64-bit Standalone

Linux AppImage

 

See the GitHub release for all details. Have fun!

[Lila Feuer]

The best fork gets better!

[namsan]

yay, new version of Nugget Doom

[Alaux]

Nugget Doom 2.2.1 has been released!

 

Only one change: to put it simply, a critical bug has been fixed. I'm surprised to have received a single report of it, considering how easy to trigger it was.

 

DIRECT DOWNLOADS:

Windows 32-bit Standalone

Windows 64-bit Standalone

Linux AppImage

 

See the GitHub release for further details. Have fun!

[liPillON]

hey @Alaux I've noticed you're back on adding features to NUGHUD

 

AmmoIcon & ArmorIcon are very nice additions, but I have a feature request regarding them: 

would it be possibile to make the engine fallback to stock patches, if the necessary "fonts" are not present in the pwad?

 

it would be ideal having NHAMMO0 initialized with "CLIPA0", NHAMMO1 with "SHELA0", NHAMMO2 with "CELLA0" and NHAMMO3 with "ROCKA0"  

this way the same NUGHUD pwad could be used also with mapsets that replace those patches

 

(the same goes for NHARMOR1/NHARMOR2 which would fall back to ARM1A0/ARM2A0)

 

 

thank you for the time you're dedicating to this project!

 

[Alaux]

6 hours ago, liPillON said:

would it be possibile to make the engine fallback to stock patches, if the necessary "fonts" are not present in the pwad?

I was thinking of simply making each patch customizable by specifying a lump name, just like you do with static patches (i.e. patch1 to patch8), so the Icons change accordingly if you load PWADs that replace the pickup sprites.

 

What I'm unsure about with that approach is what the defaults should be: I could easily make them be NHAMMO# and NHARMOR# to maintain backwards compatibility, but that would require future HUDs to change those values to achieve the expected behavior (i.e. to have the Icons working from the get-go).

 

If I did it the way you propose, the issue with defaults would be gone as the NH fonts would indeed only be used if present, falling back to vanilla sprites otherwise, but what if the "small" pickups are used by default and someone wants to use the "big" ones? It'd require using NH, so we lose the dynamic changing.

 

For this once, it may be worth to break existing HUDs for the sake of moving forward; that is, going with my approach and making the vanilla pickups the defaults.

 

EDIT: Actually, I could go for your approach and implement a toggle to change between big and small pickups. Sure, it doesn't give you the possibility of using any other sprites dynamically, but are there really any other vanilla sprites you'd rather use for it?

Edited October 24, 2023 by Alaux

[liPillON]

hey I forgot to reply sorry

It all seems perfectly reasonable, the only constraint being backward-compatibility as you said

 

tbh I think the the most flexible approach would be forgetting about special lumps (NHAMMO# and NHARMOR#) and let people specify the patch name freely

this might also result in simpler engine logic, right?

[Alaux]

24 minutes ago, liPillON said:

tbh I think the most flexible approach would be forgetting about special lumps (NHAMMO# and NHARMOR#) and let people specify the patch name freely

this might also result in simpler engine logic, right?

Engine logic is not a concern at the moment. In any case, using exclusive graphics means that I don't have to cache them multiple times just in case they're purged at some point.

 

With that out of the way, although free selection would be more flexible, it would complicate things for the user (cue uncle Ben's quote): I'm trying to figure out how to handle patch offsets, and the current approach maintains backward compatibility at the expense of making static Patches and Icons not as easy to use right away.

 

You see, Patches and Icon graphics don't ignore the offsets of the patch being drawn, so instead of having to move the widget itself around, you can simply give offsets to the graphic you're using, which ought to be simpler since SLADE gives you a visual preview. That's not an issue if you use exclusive graphics that are fully under your control (e.g. NHARMOR#), but it could get troublesome if you use IWAD stuff, which is prone to vary in size and offsets across PWADs (thinking about your experimental HUD with those ammo counts).

 

If the offsets were ignored, you'd get greater control over IWAD assets through positioning of the widget and alignment (not offsets) of the patch, but existing HUDs could break as a result.

 

I'm thinking of taking your original idea involving fallbacks, ignoring offsets only if using them, and adding a toggle to ignore offsets for static Patches. That should keep existing HUDs intact while making Icons easier to use from the get-go and giving the option to handle Patches differently. It doesn't give the user much freedom to choose graphics for the Icons, but I ask again: what else would you use if not the pickup sprites (e.g. CLIPA0)?

[liPillON]

yay (wip) zdoom-style hud!

 

Spoiler

 

 

this is using

nughud_ignore_offsets 1

nughud_ammoicon_align 0

 

you probably noticed that the rocket ends up being partially off-screen

I guess that this is because ammoicon Y coordinate refers to the top border of the patch

 

unfortunately there are right now only two ways to compensate for this:

- don't ignore offsets => this however leads to inconsistent horizontal alignment 

- decrease the Y coordinate value => this has the side effect of shifting up all the other ammo types

 

 

[Alaux]

4 hours ago, liPillON said:

you probably noticed that the rocket ends up being partially off-screen

I guess that this is because ammoicon Y coordinate refers to the top border of the patch

I'm aware of this, and I'm trying to implement vertical alignment for Patches and Icons.