Thoughts on the new Unity Port Update?

[Oldschoolgeek32]

The Unity Port is really in fact, a solid doom port for modern systems. In fact, I love all the ports because most of them have their own sets of preferences and options. I would find myself using this port when I want to play the classic versions of vanilla doom with a few minor options and tweaks. I would say its not the best way to play mods especially heavy doom mods, but it is in fact possible. I personally like this port although some minor improvements may be needed in order to enhance the experience                                                               3                          

[ChopBlock223]

I have some complaints, actually, regarding the release on PS4:

 

• The gamma slider doesn't have enough range, I can't set it low enough, the game still looks oddly bright and washed out on lowest. This may be fine for a small CRT display in 1993, but on a 4K TV in 2020, it leaves a lot to be desired, if they're accomodating for widescreen, why not this?
• The movement feels sluggish somehow, I can adjust the sensitivity for turning, but not for moving, which I suspect may be involved. Possibly, addressing this may cause conflict with .demo compatibility, but it's not like I can record .demo lumps on my PS4, and it'd make up for the lack of mouse turning.
• I cannot rebind my controls, why? I absolutely hate using the PS4's mushy shoulder buttons for firing and running, it feels entirely awful.
• The music sounds off, people say it's supposed to be pre-recorded SC-55 music, but it doesn't sound like it, in fact it sounds particularly different in TNT.wad, and makes me wonder why they couldn't implement proper .mus/.midi emulation, complete with a couple of options for soundfonts. I don't feel like this is asking for a lot, not with ZeniMax's and Microsoft's money, and it would dramatically reduce the filesizes of all the .wads

Having come off of the Nightdive port of Doom 64, it's like night and day, controls are far smoother there, on top of being configurable, and it looks great on the very same 4K widescreen TV.

Adding expansions and map packs is great and all, but there's room for improvement.

[Edward850]

1 hour ago, ChopBlock223 said:

The gamma slider doesn't have enough range, I can't set it low enough, the game still looks oddly bright and washed out on lowest. This may be fine for a small CRT display in 1993, but on a 4K TV in 2020, it leaves a lot to be desired, if they're accomodating for widescreen, why not this?

Hey @sponge, does the gamma control the software gamma palette or is it a hardware shader exposure? If it's a former then this is 100% not a bug on Doom's end, and more likely @ChopBlock223 has their video output range set to limited (16-235) on the PS4 itself* or their TV calibration needs serious readjusting.

* Remember, Doom was designed for traditional VGA RGB, crushing this into limited is going to produce poor results no matter what, and no amount of gamma-under correction is going to fix that, if not just make it worse.

1 hour ago, ChopBlock223 said:

The movement feels sluggish somehow, I can adjust the sensitivity for turning, but not for moving, which I suspect may be involved. Possibly, addressing this may cause conflict with .demo compatibility, but it's not like I can record .demo lumps on my PS4, and it'd make up for the lack of mouse turning.

If movement feels "sluggish" (whatever that means) and you want to speed it up, then by consequence you are playing Doom as it's designed and you're just not used to it somehow. Speeding up the player would be absolute nonsense as that would explicitly change the original gameplay, demo compatibility would be irrelevant in that, you'd just be arbitrarily changing the game for the sake of change.

1 hour ago, ChopBlock223 said:

The music sounds off, people say it's supposed to be pre-recorded SC-55 music, but it doesn't sound like it, in fact it sounds particularly different in TNT.wad, and makes me wonder why they couldn't implement proper .mus/.midi emulation, complete with a couple of options for soundfonts. I don't feel like this is asking for a lot, not with ZeniMax's and Microsoft's money, and it would dramatically reduce the filesizes of all the .wads

The music absolutely is recorded from actual SC-55 hardware (an SC-55 MKII specifically), that's 100% not up for dispute. However TNT doesn't use pre-recorded, it does actually uses a live synth. All mods just use this synth. By consequence this is "proper midi emulation" using a soundfont, it just so happens when you have limited options on what soundfonts you can use due to licensing (and no, not the kind of licensing that's simply a matter of spending more money), that's typically the best you can do. 

 

Also Microsoft do not own Bethesda yet.

Edited November 5, 2020 by Edward850

[ChopBlock223]

I meant sluggish as in slow in response, movement speed is fine. When I move, it somehow doesn't feel as smooth as the Doom 64 port, nor the different ports on PS3, incidentally, like it takes longer for my command to respond in the game.

 

I've played Doom on the 32X, and it didn't, feel like this, and that's without any analog input.

 

1 hour ago, Edward850 said:

If it's a former then this is 100% not a bug on Doom's end, and more likely @ChopBlock223 has their video output range set to limited (16-235) on the PS4 itself* or their TV calibration needs serious readjusting.

I'm at my brother's place, I guess I'll see what it's like on my own TV when I get back home.

 

1 hour ago, Edward850 said:

The music absolutely is recorded from actual SC-55 hardware (an SC-55 MKII specifically), that's 100% not up for dispute. However TNT doesn't use pre-recorded, it does actually uses a live synth. All mods just use this synth. By consequence this is "proper midi emulation" using a soundfont, it just so happens when you have limited options on what soundfonts you can use due to licensing (and no, not the kind of licensing that's simply a matter of spending more money), that's typically the best you can do. 

 

1 hour ago, Edward850 said:

Also Microsoft do not own Bethesda yet.

Well, one, what's the hold up, and two, since you seem to be versed in the technical side of things, when they do, would there be anything technical which would stop them from implementing the Microsoft 'Wavetable' thing (which is on by default in GzDoom), or an imitation?

I'm assuming it's not like assembling a port like it's made out of Lego, mind.

[Edward850]

25 minutes ago, ChopBlock223 said:

Well, one, what's the hold up

Microsoft only announced their intention to buy. Obviously when it comes to buying a business you can't just swipe a card through an eftpos machine, there's mountains of legal and financial work to be done in advance. It could be another 12 months until it finally goes through, and until it does and not a moment before, it is actually illegal to make any internal dealings as if they were. 

 

25 minutes ago, ChopBlock223 said:

would there be anything technical which would stop them from implementing the Microsoft 'Wavetable' thing (which is on by default in GzDoom), or an imitation?

Compatability would be the concern. Gzdoom by default uses a GPL program that is able to load the Windows DLS, whatever this port is using may only support SF2 or may just have loose audio samples (I'm not clear on what it does use, but that's usually how it ends up). But for now, it's litteraly because they can't simply copy it anyway. 

 

25 minutes ago, ChopBlock223 said:

I've played Doom on the 32X, and it didn't, feel like this, and that's without any analog input.

Careful when comparing to the original console ports (and Doom64), they have numerous changes that alter the movement characteristics, chief of which a different simulation speed, running at 30Hz rather than 35Hz. You can only draw direct comparisons to the original PC DOS (and by extension any port that's fully compatible with it, such as chocolate Doom), of which this version is a port of. This may seem odd but Doom's movement has an important aspect to it that makes it dependent on game speed; it only applies momentum, unlike their previous game Wolfenstein 3D. When you push forward for example, the value that player uses even when you push the maximum value isn't a value that sets their momentum but rather a value that adds momentum and then keeps adding more each frame, this gives you a ramp for when you start and stop moving. This allows for subtle movements at short bursts even with a full movement value (like what keyboard movement would always produce).

 

There is one slight difference between this and the original however and that's the move bob speed (except in demos, because surprise that does actually affect demo sync). It's 25% slower. This doesn't effect the movement in any way but it does make the camera and weapon bob slower.

Edited November 5, 2020 by Edward850

[ChopBlock223]

I see. Playing on PC, it's not this stiff either. Perhaps I'm imagining things, perhaps the lack of mouseturning trips me up more than I think.

 

I actually didn't figure doing all that paperwork could take that much time, I assumed they would get that done in a couple of months.

[Cantleylads]

12 hours ago, ChopBlock223 said:

I meant sluggish as in slow in response, movement speed is fine. When I move, it somehow doesn't feel as smooth as the Doom 64 port, nor the different ports on PS3, incidentally, like it takes longer for my command to respond in the game. 

 

Try disabling Vsync, if you haven't already. Removes the slight (but certainly impactful) input delay.

 

You will have screen tearing to contend with, but unless if you get some kind of motion sickness, it is far lesser of the the two evils, if you ask me.

 

The Vsync toggle is what got me hooked on these ports and their wads

[ChopBlock223]

I'll try that. I don't think any FPS has ever given me motion sickness (though the overhead camera in Hotline Miami did constantly cause me eyestrain, from swaying left and right non-stop).

 

EDIT: Turning off Vertical Sync definitely affects input latency, now I'm not limping my way through.

 

I still want rebindable keys though.

Edited November 5, 2020 by ChopBlock223

[Gez]

For reference, this is usually called "input lag".

[ChopBlock223]

Had a great time (except for TNT's Map08, God), the game felt like it should, like Doomguy wasn't suffering the effects of an undiscovered brain hemorrhage he had 10 years prior.

[Cantleylads]

1 hour ago, ChopBlock223 said:

Had a great time (except for TNT's Map08, God), the game felt like it should, like Doomguy wasn't suffering the effects of an undiscovered brain hemorrhage he had 10 years prior.

 

Ha, yeah I hear you man. It's such an important improvement for gameplay.

 

As for customisation, I'm more interested in a more responsive way to switch between weapons.

 

In the XBLA ports, for example, each time you press a shoulder button to cycle through weapons, it cancels/resets the animation, so you could easily press either button a number of times to skip right to the desired weapon, rather than cycling through them individually. I hope this makes sense.

 

I'd also love to see all of the weapons intergrated into the dpad weapon selector, alongside the animation cancelling. Currently to select the SG you have to first select the SSG as they are both bound to UP. With an animation cancel, you could press up twice in quick succession to select the SG much faster. Without the ability to skip undesired animations, it's quite cumbersome to select the SG as someone who mostly uses the dpad for weapon selection.

 

I say mostly, as the BFG isn't bound to the dpad, so the carousel is required just for that weapon, adding further delay compared to previous ports.

[Devalaous]

2 hours ago, Cantleylads said:

 

Ha, yeah I hear you man. It's such an important improvement for gameplay.

 

As for customisation, I'm more interested in a more responsive way to switch between weapons.

 

In the XBLA ports, for example, each time you press a shoulder button to cycle through weapons, it cancels/resets the animation, so you could easily press either button a number of times to skip right to the desired weapon, rather than cycling through them individually. I hope this makes sense.

 

I'd also love to see all of the weapons intergrated into the dpad weapon selector, alongside the animation cancelling. Currently to select the SG you have to first select the SSG as they are both bound to UP. With an animation cancel, you could press up twice in quick succession to select the SG much faster. Without the ability to skip undesired animations, it's quite cumbersome to select the SG as someone who mostly uses the dpad for weapon selection.

 

I say mostly, as the BFG isn't bound to the dpad, so the carousel is required just for that weapon, adding further delay compared to previous ports.

 

PS3 had it best with the D-pad. Each direction was bound to something. Shell ammo on one button, bullet ammo on one button, cell ammo on one button, the the last three were on the final button.

[Edward850]

2 hours ago, Devalaous said:

In the XBLA ports, for example, each time you press a shoulder button to cycle through weapons, it cancels/resets the animation, so you could easily press either button a number of times to skip right to the desired weapon, rather than cycling through them individually. I hope this makes sense.

This isn't true, you can't cancel the raise state. The Xbox360 weapon raise/lower behavior is identical to vanilla and by extension the 2020 port. A weapon raise must finish for A_WeaponReady to be called, and thus begin the lower state again to switch. The 360 version's next/previous behaviour also doesn't stack, it only picks the weapon based on the ready weapon (the weapon you visibly have on screen), not the pending one for both selection methods. 

 

This actually makes the 360 version the slowest in some instances if you, say, wanted to select shotgun which requires selecting pressing up on the dpad, waiting for present weapon to lower until the SSG is visible, waiting for the SSG to finish raising than lowering while pressing up again (remember you can't press up again until the SSG is the current weapon as the selection didn't check the pending weapon), then finally for the shotgun to appear. My understanding is the PS3 version is the same because the behaviour of weapon selection had not changed at all. 

 

Also the 360 port doesn't use the shoulder buttons for weapon selection, instead the Y/B buttons. Though that could just be my settings, but I certainly don't remember the controls being configurable.

 

Additional fun fact: Weapon raise cancelling would break demo sync, but pending stacking wouldn't as the player command can replace the pending weapon at any time (you can do this in DOS if you piano the numbers). I'm unsure why the XBLA port never bothered to do this in its command builder.

Edited November 6, 2020 by Edward850

[ChopBlock223]

7 hours ago, Cantleylads said:

As for customisation, I'm more interested in a more responsive way to switch between weapons.

 

In the XBLA ports, for example, each time you press a shoulder button to cycle through weapons, it cancels/resets the animation, so you could easily press either button a number of times to skip right to the desired weapon, rather than cycling through them individually. I hope this makes sense.

 

I'd also love to see all of the weapons intergrated into the dpad weapon selector, alongside the animation cancelling. Currently to select the SG you have to first select the SSG as they are both bound to UP. With an animation cancel, you could press up twice in quick succession to select the SG much faster. Without the ability to skip undesired animations, it's quite cumbersome to select the SG as someone who mostly uses the dpad for weapon selection.

 

I say mostly, as the BFG isn't bound to the dpad, so the carousel is required just for that weapon, adding further delay compared to previous ports.

Yeah, I get what you mean, I'm pretty sure Doom 64's new ports had that, also a fast switch like that I think was available in the PS4 and PS3 ports of Duke Nukem 3D.

 

For the BFG9000, I imagine that maybe it could be assigned to a diagonal input on the DPad.

 

EDIT: Well something felt a little faster anyway.

Edited November 6, 2020 by ChopBlock223

[Cantleylads]

9 hours ago, Edward850 said:

This isn't true, you can't cancel the raise state. The Xbox360 weapon raise/lower behavior is identical to vanilla and by extension the 2020 port. A weapon raise must finish for A_WeaponReady to be called, and thus begin the lower state again to switch. The 360 version's next/previous behaviour also doesn't stack, it only picks the weapon based on the ready weapon (the weapon you visibly have on screen), not the pending one for both selection methods. 

 

This actually makes the 360 version the slowest in some instances if you, say, wanted to select shotgun which requires selecting pressing up on the dpad, waiting for present weapon to lower until the SSG is visible, waiting for the SSG to finish raising than lowering while pressing up again (remember you can't press up again until the SSG is the current weapon as the selection didn't check the pending weapon), then finally for the shotgun to appear. My understanding is the PS3 version is the same because the behaviour of weapon selection had not changed at all. 

 

Also the 360 port doesn't use the shoulder buttons for weapon selection, instead the Y/B buttons. Though that could just be my settings, but I certainly don't remember the controls being configurable.

 

Additional fun fact: Weapon raise cancelling would break demo sync, but pending stacking wouldn't as the player command can replace the pending weapon at any time (you can do this in DOS if you piano the numbers). I'm unsure why the XBLA port never bothered to do this in its command builder.

Fair enough, my mistake. I haven't played those ports in many years.

 

I do remember being able to use the dpad to cycle through weapons by ammo type, without having to wait for each weapon to be drawn. Is this not the case?

 

Also with the current 2020 ports, the weapon carousel seems to add delay to selecting the next weapon, due to it waiting for you to complete your input, for lack of a better phrase.

 

Maybe it's my shoddy memory, but I do not remember experiencing any trouble in selecting weapons as I do in the 2020 ports - though I must add the readdition of dpad as a weapon selector has certainly helped.

 

I'd love to hear your thoughts on any of this,

 

Thanks

[Edward850]

1 hour ago, Cantleylads said:

I do remember being able to use the dpad to cycle through weapons by ammo type, without having to wait for each weapon to be drawn. Is this not the case?

 

Also with the current 2020 ports, the weapon carousel seems to add delay to selecting the next weapon, due to it waiting for you to complete your input, for lack of a better phrase.

The dpad is subject to the same rules as the next/previous selection, you had to wait for the first weapon to even be visible to start selecting the second on the dpad, and it can't interrupt the process just the same. 

 

There is indeed a delay on the carousel, but that's sort of the point. It allows for any weapon to be selected in the same overall time without having to wait for any previous weapon to finish. 

Certainly however the delay is still there however minor, oddly I find it more frustrating in deathmatch than anything else. It's actually why I opted to remix the idea for Strife on Switch, which has the carousel (because there's 11 guns) but uses the fire key to complete the selection, making it immediate. 

[Cantleylads]

3 hours ago, Edward850 said:

It's actually why I opted to remix the idea for Strife on Switch, which has the carousel (because there's 11 guns) but uses the fire key to complete the selection, making it immediate. 

 

Now that would be a superb adjustment!

 

Thanks for the info regarding the weapon switch mechanics.

[Edward850]

1 hour ago, MidnightMage said:

I would absolutely love to see the ability to add more than 1 wad and or deh. 

Dehacked can't really be stacked by concept, theoretically you could do it but it would never work out the way you'd think.

[Redneckerz]

3 hours ago, Edward850 said:

Dehacked can't really be stacked by concept, theoretically you could do it but it would never work out the way you'd think.

A ZDaemon user did coin (and implement, i believe) an idea that would make patches stackable using the include directive. The author's idea is a reutilization of an existing feature.

 

It never caught on, but i did post earlier this week about it in the DEHEXTRA thread (Because of the similar naming scheme). Mind you, no clue if that idea makes patches actually stackable. That's just the phrasing used by its author.

 

Post includes quoted implementation and link to example wad.

Edited November 8, 2020 by Redneckerz

[lapax_]

Calling it "unity doom" is not the right expression, cuz it isn't doom but re-made in Unity, is the og vanilla experience in a unity shell, like an emulation, since there are wads in there, but is a fast way to call it like this, cuz "new official way of playing Doom" was way too long LOL, but, a thing, i like that port but something that makes me go nuts is that there is only splitscreen and not online multiplayer, it would be cool playing it in online while i am going at school in bus, or playing in crossplay with your friend from console/smartphone while you play from pc, this would be really an improvement, and also, make a demo with DOOM1.wad because not everyone likes doom and wants to try it free before purchase would be great

 

Edited November 9, 2020 by lapax_

[Edward850]

20 minutes ago, lapax_ said:

like an emulation

"like an emulation" wouldn't be the right way to describe it either as it's native code. Emulation requires the virtualization of something, i.e a CPU instruction set or a graphics behaviour remade in software. This is just straight up normal C++ code using Unity as an I/O layer.

Edited November 9, 2020 by Edward850

[lapax_]

2 minutes ago, Edward850 said:

"like an emulation" wouldn't be the right way to describe it either as it's native code. Emulation requires the virtualization of something, i.e a CPU instruction set or a graphics behaviour remade in software. This is just straight up normal C++ code using Unity as an I/O layer.

yea, isnt proper emulation, but btw is a really good port

[Edward850]

20 hours ago, Redneckerz said:

A ZDaemon user did coin (and implement, i believe) an idea that would make patches stackable using the include directive. The author's idea is a reutilization of an existing feature.

I'm not really sure how else to put this, but ZDaemon is really not where I'd go for implementation ideas of port features. ZDaemon's modding is fairly alien at this point, I believe they are still somehow using DEHSUPP last I heard?

Edited November 9, 2020 by Edward850

[Gez]

23 hours ago, Redneckerz said:

A ZDaemon user did coin (and implement, i believe) an idea that would make patches stackable using the include directive. The author's idea is a reutilization of an existing feature.

It's apparently more about splitting a dehacked file into smaller chunks than about actually stacking different dehacked patches together. I suppose it can be used to create more easily some modularity ("load base.wad with one of optiona.wad, optionb.wad, or optionc.wad") but honestly nothing revolutionary about it.

[Redneckerz]

9 hours ago, Edward850 said:

I'm not really sure how else to put this, but ZDaemon is really not where I'd go for implementation ideas of port features.

Neither do i given their closed source nature, but this just happened to caught my eye, and it sounded both rather novel and universal (All you are doing is adding a definition).

9 hours ago, Edward850 said:

ZDaemon's modding is fairly alien at this point, I believe they are still somehow using DEHSUPP last I heard?

They extended that to a significant degree, same with ACS. My problem with ZDaemon is that whilst i can see the results of the author's labor that take advantage of these new features (In particular Aeyesi has done some rather superb work in that regard), it is rather difficult to find proper information upon.

On the outside ZDaemon just looks like a ZDoom Multiplayer port that's closed source. And that fooled me aswell. But behind that cloak does lie some impressive, if rather unknown (and undocumented!) stuff.

7 hours ago, Gez said:

It's apparently more about splitting a dehacked file into smaller chunks than about actually stacking different dehacked patches together. I suppose it can be used to create more easily some modularity ("load base.wad with one of optiona.wad, optionb.wad, or optionc.wad") but honestly nothing revolutionary about it.

I suppose it does work that way. The EXTRADEH definition is basicaly just used to load up another deh file alongside the active deh file. Which, depending on who you may ask, counts as stacking.

 

Nothing terribly revolutionary, but there is not too much effort required to enable this feature eitherway, and i assume it works across many ports.
@Doomkid as resident DeHacker of all things Zappa, what does thou say about ExtraDEH?

[A Nobody]

I'll stick with source ports.

[Edward850]

11 minutes ago, The Strife Commando said:

I'll stick with source ports.

You do know this is a source port, right?

Edited December 24, 2020 by Edward850

[Redneckerz]

8 minutes ago, Edward850 said:

You do know this is a source port, right?

I mean it literally hints at that in the title..

 

Spoiler

He knows.

 

[A Nobody]

1 hour ago, Edward850 said:

You do know this is a source port, right?

What is the source port called then?

 

1 hour ago, Redneckerz said:

I mean it literally hints at that in the title..

 

  Hide contents

He knows.

 

I've had enough of you.

[ZeroTheEro]

It's called Doom Classic Unity, https://doomwiki.org/wiki/Doom_Classic_Unity_port