[oasiz]

I think stuff like this should be behind an automatic downloader instead. Similar to how openRA or such handle downloading further assets as required.

[Phredreeke]

Yeah, I don't think EDuke32 should have soundfonts bundled. It doesn't bundle widescreen sprites, skyboxes or voxels.

[NightFright]

Well, you can make a download folder with recommended soundfonts maybe. In the end, we already have an OPL3 synth on board as fallback.

Anyway, I am currently working on a MIDI guide for GZDoom which will also include a download compilation with soundfonts. It can be useful for EDuke32 as well.

[TerminX]

I appreciate the soundfonts you've posted; some of the defects fixed in TinySoundFont were non-obvious until trying some of these random .sf2s.

[NightFright]

Is there some kind of TinySoundfont-specific changelog of what has been adjusted since the last 1-2 weeks? I'm curious in what way EDuke32 contributed to making the synth better in general, and how.

[TerminX]

Yeah, https://github.com/s.../commits/master

[NightFright]

I see. After just one commit last year, already five in 2020. Not bad. Maybe we'll even still see reverb/chorus implementation. Anyway, the solution as it stands now is already quite OK. I can't tell how TSF is doing compared to FluidSynth or BassMIDI, but for ingame purposes where you also have game sounds playing at the same time it should do fine.

[TerminX]

Yeah, that's about how I feel about it. For someone hardcore into MIDI synth who has specific soundfonts they want to sound identical across everything that uses MIDI, the standalone solutions are better. Otherwise, it's pretty nice to have things that Just Work out of the box.

I don't know if chorus and reverb are coming to TinySoundFont any time soon. I've been kind of thinking about how a cheap fake reverb implementation like the sound system itself uses would work in a library like that though. The operation of the ASS reverb is shit simple... instead of mixing into a blank buffer, it decays the bits already present and mixes on top of them. If something like that was done on a per .sf2 "voice" basis, it might work well enough. The actual .sf2 spec doesn't say how the effect is supposed to be implemented.

[NightFright]

With most of the soundfonts I posted, reverb/chorus won't matter that much, actually. Sure, they still make the instruments sound less dry and create a more homogeneous sound pattern, but you won't miss them that much if you have no comparison.

The EAWPats soundfont however needs it more, for two reasons: 1) The Timidity patches use it a lot and it contributes considerably to the characteristics of the instruments. 2) The soundfont was made drier in general which is hard to compensate by any synth, so if it's missing, you really notice it. Hopefully Bashe will create that vanilla-like version at some point still to undo some of the liberties he took with the conversion.

I don't claim to be an expert in this area, by no means. But as someone who has been experimenting with soundfonts in GZDoom and EDuke32 since many years, I gained some insights into what certain tracks should sound like. You don't need soundfonts with hundreds of megs since there are really good ones out there in the range of 8-30 MB which do just fine. The synth itself can also make a difference, but I think that anyone claiming they can hear a difference between e.g. Fluidsynth or BassMidi ingame is exaggerating. For the average user it's definitely negligible.

I appreciate that you guys still try to squeeze more out of TSF in the future. It's already almost everything I wished for. Small detail still: I tried and it seems I can't set up dirs outside of the EDuke32 folder, unless I am making some mistakes with the slashes or something.

[TerminX]

Found this pile of .sf2 files on archive.org: https://archive.org/...nts-sf2-2019-04

[NightFright]

Holy crap, that's the motherload. There are some I don't even know yet. I am mostly interested in the smaller files between 8 and 32 MB. Bigger than that doesn't automatically mean better.

However, I doubt there's anything that beats my personal favorites (8MBGM Enhanced, Masquerade55, EAWPats or the Yamaha S-YXG50 VSTi). With soundfonts it's also a matter of habit. Once you get used to a certain type of sound, anything different from that doesn't seem right to your ears.

[NightFright]

In the I see there's still an open issue with custom modulators which affects the Aureal soundfont. Is that the only one from those I posted here? It appears the author doesn't intend to fix this issue, so there will be soundfonts we cannot recommend for EDuke32 usage. Even though that kinda sucks tbh.

[LeoD]

[Feature request]
Mapster32 should log its command line parameters, like EDuke32 does. Patch attached.

Attached File(s)

•  build-8761-8791.cpp.patch.zip (382bytes)
  Number of downloads: 342

[MusicallyInspired]

Ah RealFont is there. Fond memories of using that one for playback and composing years back when I didn't have anything else to rely on.

[Nuke.YKT]

Have been working on a really cool feature for the build engine: Sloped sprites. This feature works in a similar way to sloped floors/ceilings and makes a lot more complex geometry possible. Here's what oasiz came up with using sloped sprites.

[oasiz]

It just works. Plus collision too!
Just point at a floor aligned sprite and start sloping away.

[Micky C]

This would be so goddamn epic if it's real.

I'll believe it when I see it in my mapster In the remote possibility that it's real, is there an ETA on when we can use it?

[High Treason]

Oh, cool.

Spoiler

Shame the white moonrock wall at the top of the monolith when it falls over kinda ruins the joke a little.

[Forge]

even if it were real, it'd probably break everything prior to 2019 & the joke would be on us anyway

[DavoX]

It's real.

[NightFright]

3D sprites next, please. (Still not sure if this is a joke or not, but it's cool either way.)

[Radar]

If sprites can be sloped, then does this imply that voxels can be sloped as well?

[DavoX]

For now only floor and ceiling alligned sprites can be sloped. Not wall alligned ones. BUT HEY!

[Micky C]

 oasiz, on 02 April 2020 - 01:27 AM, said:

For time savers, I wish to some time do a proper re-write on the scripts I did for fury so that they can be more modular and useful outside of fury as well.
I've added a dozen on time savers from things like "paste slope" to things like "hide all sector effectors". There is an insane amount of quick wins in the editor that never have been addressed before.

Continuing on from the sloped sprite thread.


What I'd like to see in mapster is better support for terrain dealing with quadrilaterals and triangles. It'd be nice if there was a function that automatically aligned the slopes of quadrilaterals to the wall connected to that opposite the first wall. Same for triangles. If I could set up some geometry of rectangles and triangles, make sure the first walls are correct, then hit a button to automatically align everything, that would be a massive timesaver indeed.

On a related note, the auto-align (alt + [ or ]) doesn't seem to be working well triangles when trying to align to adjacent or opposite sectors.

[oasiz]

Sounds like this would require dragging wallpoints and 3D calculation, not something I can really help with.
I do have a tooltip that displays the angle of a wall so you could make sure that firstwalls are at least turned the same amount of units.

Auto-sloping... I could maybe have some ideas to enhance the current one in mapster but not sure.

[Micky C]

Vertices wouldn't have to be moved around for what I have in mind. A simple 'automatically align quadrilaterals and triangles to the opposite wall' batch effect would suffice. Perhaps it's something that could be added to mapster itself through the special function menu as opposed to a mapster script?

For mappers who are reading, some quick geometry tips are:
Quadrilaterals will align perfectly between any two flat heights if the upper and lower wall are parallel.
Two triangles will connect any two flat heights regardless of sector shape.
An additional triangle is needed at the upper or lower end if either surface is not flat.

Something that would be really cool if if the designated sectors were continuously auto-aligning, so that you can drag vertices around manually and see the results in real time.

[oasiz]

I would hold up my hopes for new mapster functionality at the moment, scripts are your best bet. This was the reason why I started simply just writing these

Are you thinking of a situation where you have a flat surface with slopes around it and being able to raise it up/down like a wave fx kind of would and have the slopes "work" against it ?
I guess I could create a loop that goes through all walls that touch the main sector and somehow figure out how to make the sloping match.

[Darkus]

Maybe I'm too late, but I just discovered that you can rotate wall textures...

[oasiz]

Yup, this was added a bit over a year ago by TX

Really should do some blog posts that highlight some of these features, so easy to miss!

[Micky C]

oasiz, on 02 April 2020 - 04:29 AM, said:

I would hold up my hopes for new mapster functionality at the moment, scripts are your best bet. This was the reason why I started simply just writing these

Are you thinking of a situation where you have a flat surface with slopes around it and being able to raise it up/down like a wave fx kind of would and have the slopes "work" against it ?
I guess I could create a loop that goes through all walls that touch the main sector and somehow figure out how to make the sloping match.

Yeah like that. Although even a simple once-off batch effect would be a big help.

On the topic of the current auto-slope alt + [ ], it's really not working well at all for me lately. Is anyone else getting this?