[0.6.0-485-g5330964a7a] Duke 3D door sound sync

Moderator: Raze Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
User avatar
mjr4077au
Posts: 719
Joined: Sun Jun 16, 2019 9:17 pm
Discord: mjr4077au#1027
Github ID: mjr4077au
Graphics Processor: nVidia with Vulkan support
Location: Gosford NSW, Australia

[0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by mjr4077au »

At least on doors that go up and down, if you open and close it rapidly the door's sound starts playing out of sync, then permanently stays out of sync with successive opens and closes. This is both on EDuke32 and RedNukem codebases.

Testing in EDuke32, opening and closing the door rapidly does cause a sync issue, but it seems to reset when the door once the door is fully open or closed.

Doors tested are the Yellow Key door and Red Key door in Duke 3D E1L2.

Edit: Clarified some text.
Last edited by mjr4077au on Tue Jun 09, 2020 2:41 pm, edited 1 time in total.
User avatar
sinisterseed
Posts: 1277
Joined: Tue Nov 05, 2019 6:48 am
Github ID: sinisterseed
Graphics Processor: nVidia with Vulkan support

Re: [0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by sinisterseed »

Can confirm.

Investigated both doors on E1L2 and their sound does indeed go noticeably out of sync, like, no sound playing when closing and starting once the door is actually closed, and so on. However, I've not had luck reproducing this in EDuke32 so far, they both manage to stay in sync for me. I've cross-checked with the 64-bit build from today.
Gammli
Posts: 45
Joined: Sat Mar 02, 2019 12:46 am

Re: [0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by Gammli »

I'm not sure I understand what "going out of sync" means in this context.

If it's meant that, instead of the sound playing when the door begins opening, and instead playing once it has fully opened, then that's a bug that has existed since the DOS version.
User avatar
sinisterseed
Posts: 1277
Joined: Tue Nov 05, 2019 6:48 am
Github ID: sinisterseed
Graphics Processor: nVidia with Vulkan support

Re: [0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by sinisterseed »

Gammli wrote:If it's meant that, instead of the sound playing when the door begins opening, and instead playing once it has fully opened, then that's a bug that has existed since the DOS version.
Yes, that's precisely what this is about.

However, I was not able to reproduce this in EDuke32 and Rednukem so far, whereas it's very apparent in Raze.
User avatar
Enjay
 
 
Posts: 26403
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: [0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by Enjay »

OK, I've just had a mess around with the DOS version, EDuke32 and Raze.

In DOS, if you stand in front of a door (I used the one in the porn shop with the 3 button code in E1L2) and mash the USE key, sooner of later you will be able to get it so that the door opens silently and then the moving sound happens later. However, if you then leave the door to shut and open it again, the sound should be back in sync (I think). Certainly, if after getting the de-sync if you allow the door to shut, open the door and then allow it to shut again under its own timing, the de-sync has gone (but you can recreate it by mashing USE again).

In EDuke, as far as I can tell, it's the same.

In Raze, once you get the de-sync, it is possible for the door to be stuck in de-sync mode. i.e. even if you leave it alone to close naturally, then re-open it and allow it to close again (as described for DOS), the sound may not re-synchronise.

[edit]Update to the above. If I have created a de-sync in Raze, then the door stays stuck as de-synchronised as long as I leave to door to wait/close under its own timing. If, however, I open the door, wait until it starts to close and them press USE to reverse the door direction again (i.e. I don't let it close fully before pressing USE), this seems to re-synchronise things. [/edit]
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47995
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by Graf Zahl »

I'm just wondering if this is still an issue. Since this report all of Duke's game logic was replaced and some issues with the soundFX controller sprite were fixed so it should be rechecked.
Gammli
Posts: 45
Joined: Sat Mar 02, 2019 12:46 am

Re: [0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by Gammli »

Behaves the same as in DOS. Desyncs if you press use on the door while it's opening/closing, but fixes itself after staying closed for a while.
User avatar
sinisterseed
Posts: 1277
Joined: Tue Nov 05, 2019 6:48 am
Github ID: sinisterseed
Graphics Processor: nVidia with Vulkan support

Re: [0.6.0-485-g5330964a7a] Duke 3D door sound sync

Post by sinisterseed »

Sounds like a vanilla bug in that case, and the way it's always been.

Return to “Closed Bugs”