[TerminX]

3D Master, on 24 December 2019 - 03:18 PM, said:

I noticed something really weird in my playthrough of the Launch Facility E1M6; episode one's secret level.

When you blow up the rocket, the rocket crashes into the ground instantaneously, the explosions continue to go off, but instead of seeing the rocket slowly come down, the rocket is already gone; except for the placed textures on the sides; the numbers, they come down at the right speed, and as such are just floating in mid air as they sink down into the ground.

It's like that in the DOS version.

[Fox]

Doom64hunter, on 23 December 2019 - 02:48 PM, said:

What's going on with the laser tripwire rendering? Very often I get situations where the laser is not visible at all, such as here:

duke0063.png

When it should look more like this:
duke0065.png

No idea why this happens, it doesn't seem to be consistent at all. Sometimes the lasers appear, other times they don't.

It's not a rendering problem

It's a problem with overlapping sectors

The tripbomb uses a setsprite function, which calls updatesector instead of updatesectorz

As a result, the LASERLINE sprites get inside of the ceiling in the sectors below

[3D Master]

TerminX, on 24 December 2019 - 04:39 PM, said:

It's like that in the DOS version.

No, it isn't.

[TerminX]

3D Master, on 24 December 2019 - 05:52 PM, said:

No, it isn't.

Damn, really? Someone had better tell CERN to knock it off with all of this Mandela Effect bullshit then, because now they've gone and edited all the videos taken with the DOS version on YouTube!

[Fox]

3D Master, on 24 December 2019 - 05:52 PM, said:

No, it isn't.

[Danukem]

I want to hide the polymer option on the startup screen, for obvious reasons, but I don't want to have to use a custom build. Is there any solution for this?

[oasiz]

New build is pretty smooth btw, also lots of clipping things changed.

I think many will like this and might be surprised: 64 | 32

[Danukem]

So the first thing I'm noticing with the new build is, my in-game mouse cursor code is broken by mouse aiming changes. I have been detecting the difference between the ang and oang in the player struct to determine how much to move the cursor left and rigfht for my menus. That doesn't work at all now, my cursor is just frozen on the x axis, even though the player is able to look around normally (which is also not supposed to happen). Likewise I have been using the difference between horiz and ohoriz to determine y axis cursor movement. That's also broken most of the time, and when it does it ignores the mouseflip setting.

Here is the code I have been using, pretty much for the last 10 years, to lock the player down while setting cursor position for my in game menus:

state in_menu
	setp[].knuckle_incs 0
	setp[].crack_time 0
	setp[].movement_lock 31
	seta[].htextra -1
	setp[].kickback_pic 0
	setp[].jumping_counter 0
	setp[].weapon_pos -9
	setp[].quick_kick 0
	getp[].ang temp
	getp[].oang tempb
	set cmode 0
	getincangle angvar temp tempb
	div angvar 3
	sub cursorx angvar
	setp[].ang player[].oang
	ifl cursorx 0 set cursorx 0
	ifg cursorx 320 set cursorx 320
	
	getp[].horiz temp
	getp[].ohoriz tempb
	sub temp tempb
	getuserdef[].mouseflip tempc
	ife tempc 0
	add cursory temp
	else
	sub cursory temp
	ifl cursory 0 set cursory 0
	ifg cursory 200 set cursory 200
	setp[].horiz 100
ends

A quick investigation shows that the player ang and oang are always the same now. .oang is supposed to be the player's ang from the previous tic. That explains why my cursor doesn't move. Likewise .horiz and .horiz are the same. It also explains why setting the player's .ang to .oang doesn't lock the angle in place. It seems that they are now instantly both updated to the same value.

[Mark]

One of the projects I'm involved with has similar problems with player.angvel
I was told its been reported and being looked into.

[axl]

I didn't exactly know where to post this, but is there a sort of overview of future plans ? I visit the forum from time to time (including discord), but a nice overview of upcoming plans (if possible with timeline or order) would be very helpful and interesting.

- I assume VoidSW and Deadly Kiss for Shadow Warrior;
- I've heard Nuke.YKT is planning to reverse engineer the new stuff from World Tour ? Is this correct ?
- What's the future of EDuke32 and the different ports ? NBlood, Rednukem, PCExhumed ? Will there be a merger in the future or will these ports continue to exist all together ?
- Will the upcoming Raze port have any influence on future development ? I assume not since Raze itself is based on EDuke32...

My apologies if these questions were already posted previously.

[Player Lin]

I can only answer what I know...

axl, on 14 February 2020 - 02:13 AM, said:

- I've heard Nuke.YKT is planning to reverse engineer the new stuff from World Tour ? Is this correct ?

True. Someone said Nuke.YKT was working on that and EDuke32 will get full WT supports.

axl, on 14 February 2020 - 02:13 AM, said:

- Will the upcoming Raze port have any influence on future development ? I assume not since Raze itself is based on EDuke32...

Raze's code may not all useful to EDuke32(as most of low level parts/assembly shit has been replaced or removed, Graf didn't want to deal with them so he had to take them out, also the OpenGL 1.1 related code too so ancient hardware will not working wit Raze) and right now it's aiming as possible to close as original DOS version of Build games(may rejected some recently EDuke32 "fixes" that broken things) with some enchanted EDuke32 things, but still too early to be stable. But who knows what will happens if future after it went stable...like Graf's plans for brand new polymer-like renderer which can using modern graphic cards' capability...but again it's still too early to say anything.

[TerminX]

Can some of you test the new .sf2 sound font support added to EDuke32? Just drop a .sf2 file into your EDuke32 directory and check the sound setup menu and it should be pretty self-explanatory.

[Player Lin]

I just throw the GZDoom.sf2, Scc1t2.sf2 and silverspring15.sf2 into the directory of my copy of latest EDuke32, and switch it to SF2 SYNTH...didn't found anything wrong...but I just feel they all sounds the same as OPL3...weird...maybe it's me... :\

[NightFright]

I can't believe you guys pulled that off after all these years. Nuke.YKT is a freakin' GENIUS! Finally I can retire VirtualMIDISynth. Thanks a ton for this truly amazing and more than welcome addition, guys!

I tried Bashe's eawpats.sf2 from a "soundfonts" subdir and it worked like a charm. Is there any way to go outside of the EDuke32 folder through the menu or do you have to edit the cfg for that? I actually store all my SF2s on a separate drive and would like the game to access that instead of having to copy the files into the game folder. In my case, the game is in D:\Duke3D and the soundfonts are in E:\Soundfonts.

[Newken]

IMHO, VirtualMIDISynth sounds better (richer).

Attached File(s)

•  EDuke32 + VirtualMIDISynth - GeneralUser GS v1.471.flac.zip (2.82MB)
  Number of downloads: 393
•  EDuke32 - GeneralUser GS v1.471.flac.zip (2.3MB)
  Number of downloads: 438

[Mark]

For that one song I like Virtual better but they both have issues. I would have to listen to a wide variety to make a choice.

[NightFright]

Which method does EDuke32 use for SF2? Fluidsynth? Maybe it's also a matter of presets like reverb or chorus which might still not be applied.

[TerminX]

NightFright, on 18 March 2020 - 08:15 AM, said:

Which method does EDuke32 use for SF2? Fluidsynth? Maybe it's also a matter of presets like reverb or chorus which might still not be applied.

We're using a library called TinySoundFont that we glued directly to the Apogee Sound System. TBH, you may still generally get a better result using more complex external solutions like VirtualMIDISynth, but the built-in support is still pretty nice to have--you can drop a .sf2 file into your directory and it will Just Work with no additional configuration of anything beyond selecting .sf2 support as your MIDI driver in the menu.

I don't think reverb and chorus are supported yet but we're going to be looking at that soon. My understanding (which could be wrong) is that the actual workings of the reverb and chorus effects aren't really fleshed out very thoroughly in the SoundFont format specs originally published by E-mu Systems, beyond specifying how much to attenuate the notes before sending them to whatever your specific synthesizer setup is using to process them and produce the effect, so the end result is kind of implementation-defined. I'm not sure yet what our implementation will be.

[NightFright]

Well, considering I basically only installed VMS because of EDuke32, I don't mind some loss of playback quality which I will not notice that much anyway if I can get rid of an otherwise needless app in return. And as you wrote, there's still potential to improve quality. I like how simple the implementation turned out to be from user side and it is pretty much what I had in mind when I asked for the feature some years ago.

I can still recommend one of these soundfonts to use with EDuke32 in general:
8MBGM Enhanced 1.8
Patch93's SC-55 Soundfont 2.2
EAWPats Soundfont

[TerminX]

Cool, thanks for the links--I will check all of those out.

[Player Lin]

NightFright, on 19 March 2020 - 04:05 AM, said:

I can still recommend one of these soundfonts to use with EDuke32 in general:
...
EAWPats Soundfont
...

Just ask...

I do have EAWPats on my system but not in SF2 format(directories with *.pat and some *.cfg files, since I used that for GZDooM's built-in Timidity++ and can be loaded), is that anything different between sf2 and pat format?(Since looks like EDuke32 can only load *.sf2)

[NightFright]

The soundfont sounds very similar to the Timidity patches, however since Bashe applied some adjustments, the SF2 will sound "drier" with less reverb in general. If you don't mind that, it's a quite accurate adaptation.

[Player Lin]

NightFright, on 20 March 2020 - 07:06 AM, said:

The soundfont sounds very similar to the Timidity patches, however since Bashe applied some adjustments, the SF2 will sound "drier" with less reverb in general. If you don't mind that, it's a quite accurate adaptation.

Understood, I would try that if I have some time, thanks your explanation.

[NightFright]

Bashe actually published a very neat comparison video presenting EAWPats patches vs soundfont side-by-side. Most of the time it's hard to tell the difference:

https://youtu.be/kv4lwVWkYlo

According to Bashe, volume and decay/release times of many instruments have been "optimized". Graf Zahl, who is a determined fan of the patches, considers this a sacrilege which ruins the general character of the package. Anyway, there is a slight chance Bashe will get back to working on the project and considers doing a vanilla version without any personal adjustments.

[Player Lin]

Well, "optimized" always tends be subjective, and I won't blame Graf didn't like Bashe's changes.

Listened the comparison video, the RotT music, soundfont version sounds a little off to me when I prefer patches version, other music...well, I'm not sure if I'm old or something but I found soundfont version was more clear but patches version was...very unique feel.

But, OPL3 still sounds better to me, at least for Duke3D music...(Yeah, I downloaded soundfont and tried that already.)

[NightFright]

Well, EDuke32 luckily gives you many choices right now, with OPL3 always being the fallback solution. The perfect solution for me would be if EDuke32 was able to natively use the Yamaha S-YXG50 VSTi plugin, but it's probably a bit exotic.

[TerminX]

Would you guys mind re-testing .sf2 support? I got in touch with the guy who wrote TinySoundFont and he managed to very quickly fix several problems with the library based on some bug reports I made. All of the .sf2 files linked in this thread sound better to me now.

[NightFright]

I did a fast comparison with r8770 and r8778 using the EAWPats soundfont and listening to grabbag.mid and stalker.mid ingame. There is indeed a noteworthy improvement in sound quality. Instruments appear clearer to my ears and some even seem to be "fleshed out" more. Music also seems to have more volume in general. I dunno about reverb since that soundfont is supposed to sound "dry" by default, but in general this comes a lot closer now to what I know from Fluidsynth in GZDoom.

BTW if you are looking for a small, compact and yet nice-sounding smallfont to ship with EDuke32, Synthoridity over at VOGONs made this nice conversion of a 5MB Turtle Beach soundfont, with some minor tweaks to make it sound better. Maybe not all instruments are top-notch, but for a soundfont of this size it's pretty well balanced and all instruments can be heard clearly. My personal favorite remains 8MBGM Enhanced, however. Was made for Descent and classic LucasArts adventures, but also performs admirably in Doom, Dark Forces and Duke3D.

[Newken]

Grabbag sounds like Devo or something with that 5MB Turtle Beach soundfont and TinySoundFont.

[NightFright]

Well, I never said it would sound overwhelming. You are better off with one of the choices I posted above. It's hard to find a convincing soundfont below a size of 30 MB.