Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

Crispy Doom 5.6.3 (Update: Oct 04, 2019)

Recommended Posts

 On the HUD it's not that easy, you'd need to move the mugshot somewhere else like i did in LZDoom. But hey that was very easy to do there, nothing to do with this problem.

Share this post


Link to post

Thanks for your amazing response fabian! And thanks to everyone else for supporting the idea, it's good to hear I'm not the only one!

11 hours ago, fabian said:

Re status bar face: How about adding the colored multiplayer background to the face widget so that it doesn't blend with the weapon sprite?

Yes, that's what I had in mind to begin with and it sounds very nice! We might have to play around with it a bit since maybe that could make the face a bit too intrusive but maybe if the multiplayer background was already a little bit transparent to begin with, it could work even better? But if the background is transparent to begin with in the Crispy HUD, would the transparent face + the transparent background look strange? I did a quick mockup and I'm hoping for something like this:

GREEN_OPAQUE.png.2649ae4ad19ecfa920270024a2673555.pngGREEN_TRANS.png.0fb57cd835e0738805ff157dc90a953d.png

So the left would be the default opaque HUD while the background would be slightly transparent already. On the right would be the transparent version ideally, the blending being preserved. However, if we get this (the background and the face being transparent separately):

GREEN_ERROR.png.22ad21185447e67103e38707800a2caa.png

The face could get all muddied and it might look ugly especially if it gets run through the Doom palette. It might be hard to see, but the green  along with other colors would be showing through the face which gives the face a sickly green color, and it can "fog up" the face with the grey background.

 

And for the reason for the frame rate limiter, yeah, pretty much what @seed said. And it's nice to hear that the high resolution is already planned. I wish I could be able to learn to code and hopefully help you out. Maybe one day. That would be amazing!

Share this post


Link to post
On 10/25/2019 at 10:06 PM, UndeadRyker said:

And a bug I noticed using the Vanilla Doom smooth weapons dehacked file by fraggle:

  • The chainsaw jerks around a lot when you walk with it. This doesn't happen in Chocolate Doom.

 

So, I just tried to reproduce this, but with the latest version of the vsmooth mod that I downloaded the chainsaw animated just fine in its idle state. Would you please test again with the most recent release?

Share this post


Link to post
16 hours ago, MaXelL said:

@fabianI don't know if it goes against Crispy/Choco Doom principles, but could something like the HXRTC HUD be implemented in Crispy Doom?

 

Sorry, but this is far off, no chance.

Share this post


Link to post
1 hour ago, fabian said:

Would you please test again with the most recent release?

Whoops, everything looks like it's working as intended. I thought Chocolate Doom was slightly smoother when the chainsaw bobbed, but when I took a video of the two as a demonstration, they both looked perfectly identical when I put them up side-by-side. Well, everything looks great then! I must've expected the smooth chainsaw weapon to have the same smooth movement animation as the default crispy vanilla chainsaw. Sorry!

Share this post


Link to post
On 10/28/2019 at 10:25 PM, drfrag said:

There i did the same as fabian (again) for other limits to show the count and removed the overflow guards and calls to the emulation function.

Which 'other limits' do you mean?

Share this post


Link to post

 Other (all?) removed limits, that code is the same as in Crispy to show how the limit increases but unfortunately there's no working console in Choco to show the messages and i find that a serious issue. I compile RUDE as both a GUI and console application and a simple console works, of course it would be much cooler to have a better console with the colored banner. The next version is a major overhaul but RUDE is still stuck on SDL 1.2 and i compile with Code::Blocks.

 Performance will actually be worse as the intercepts now will need to be calculated but it's very hard to increase the limit in practice and else you wouldn't be able to shoot anything beyond the intercepts. As i've said fabian explained it in the issue i linked earlier.

Share this post


Link to post

Requesting couple extremely useful features, not found in any source port yet:

1. In-game demo restart key (takes you back to the beginning of the level with a new demo file being recorded into, so different LMP file).

2. Perfect quick start :-)

 

Those two are the most important and biggest features missing currently from all of the source ports (when thinking of speedrunning). I guess the quick start is very complicated to fix though.

Edited by Looper

Share this post


Link to post

What is parfect quick start? I write BAT-files with -skill N -warp M (followed by -record if recording a demo) to get into the game with just a double-click.

Share this post


Link to post
18 hours ago, Looper said:

1. In-game demo restart key (takes you back to the beginning of the level with a new demo file being recorded into, so different LMP file).

 

Very interesting request! As there is already shortcut key for "Restart Current Level" I think this will be pretty straightforward.

 

18 hours ago, Looper said:

2. Perfect quick start :-)

 

I consider this as something that should be implemented in Chocolate Doom first. And, as you have requested this before, there is already an issue filed for that: https://github.com/chocolate-doom/chocolate-doom/issues/1105

 

Share this post


Link to post

Should work by default if you left your mouse wheel assigned to weapon changing. 

Share this post


Link to post
On 11/7/2019 at 3:38 PM, Looper said:

1. In-game demo restart key (takes you back to the beginning of the level with a new demo file being recorded into, so different LMP file).

 

I have just committed this feature [1], so it should be available in tomorrow's daily build: http://latest.chocolate-doom.org/

 

You may want to bind the "Reload current level" key in crispy-doom-setup, although it should also work with the "Go to next level" key and even with IDCLEV.

 

It has so far been successfully tested with MAP01. Please test extensively especially on maps with Revenants, because their projectiles being homing or not originally depends on the gametic variable (which will be different each time a new demo is recorded). It *should* work, but you never know...

 

[1] https://github.com/fabiangreffrath/crispy-doom/commit/2b214e313f409ee153941d749ba2604e281e265d

Share this post


Link to post
On 10/25/2019 at 10:06 PM, UndeadRyker said:

This might be too much: A way to change movement bobbing intensity that would be visual-only (while still remaining demo compatible). Motion sickness really sucks sometimes especially if you want to pass the time when you're sick. Maybe we can enter a value or choose from several options. The 25% reduction in movement bobbing straight out of the BFG Edition Doom Engine would be a welcome addition, and then the option of no view bobbing at all.

 

Please note that player view bobbing and weapon sprite bobbing are directly connected to each other by the player->bob value. Especially in the BFG Edition, both the view bobbing and the weapon sprite bobbing are reduced to 75%. If you entirely disable player view bobbing, you will also disable weapon sprite bobbing, so welcome back to Wolf3d. ;)

Share this post


Link to post
On 11/11/2019 at 5:11 AM, fabian said:

Please note that player view bobbing and weapon sprite bobbing are directly connected to each other by the player->bob value. Especially in the BFG Edition, both the view bobbing and the weapon sprite bobbing are reduced to 75%. If you entirely disable player view bobbing, you will also disable weapon sprite bobbing, so welcome back to Wolf3d. ;)

 

Actually that's just what I was hoping for! I can't wait! I'm loving the new STBAR face in the Crispy HUD by the way, it's a wonderful addition. Thanks for adding it!

Spoiler

GOOBERS could probably make use of that disabled view-bobbing, don't you think? :P

 

Also, a little suggestion that could be added to Misc Sound Fixes. I think I've both seen and have a feeling that the DSSWTCHX sound lump is supposed to be the sound of a switch texture turning off. Currently the DSSWTCHN sound is played twice regardless. If you need a spot to test this, E1M4 is a good spot to test this, as the repeatable switch in MAP01 of DOOM2.wad only plays once and there wasn't any switches that I could remember off the top of my head that plays as often as E1M4.

DOOM0000.png.1cf23f0e1e019a8476002312fe16d724.png

 

I would assume that the intended behavior is that the DSSWTCHN plays first, and then DSSWTCHX plays after when the switch resumes back to its normal state regardless of whether it was already turned on or off depending on its switch texture.

 

But why stop there when you can probably do a lot more with that particular sound fix and get even more specific? Why not modify the sound of the switch being played depending on the prefix of the texture name and which switch texture goes to another switch texture? SW1* is the prefix of all of the 'off' switches and SW2* is all of the 'on' switch textures. You could add one additional sound feature/fix:

  • The inverse switch sounds. When the player presses use on a linedef with an SW2* (on/lit) switch texture, it would play DSSWTCHX (switch OFF) when the texture changes to an SW1* (off/unlit) texture, and if it goes back on (if it's a repeatable line action), then DSSWTCHN (switch ON) would play when it goes back to its original SW2* (on/lit) texture.

Just another idea off the top of my head. :)

 

Edit: Here's a test level replacement for DOOM2 MAP01 for testing most switch types and functions that I quickly did. RSWS.zip

Edited by UndeadRyker : added test level for testing switch sounds

Share this post


Link to post

As far as I can tell from P_ChangeSwitchTexture(), the swtchx sound was originally only meant for exit switches. 

Share this post


Link to post
On 11/12/2019 at 2:33 PM, UndeadRyker said:

Actually that's just what I was hoping for!

 

Just merged in the changes, they will be available in tomorrow's daily build. Phew, took quite some more time than expected. ;)

Share this post


Link to post

Yeah, you're probably right about the switch sounds. Anyway, playing around with the new view-bobbing options is great and it really helps motion sickness not be as severe! I couldn't wait for tomorrow's daily build so I had to finally compile it myself and I actually got it working after some experimenting with Git. :P

 

Just noticed a small little bug but I found the issue tracker so I filed it in and I will continue to do so for any other bugs if I notice more in the future. Thanks again for all the love you put in your source port, it really is great to customize and tailor your Doom experience while keeping it demo compatible. :)

Share this post


Link to post

I don't know if this is actually a bug or not, but I noticed that with view-bobbing disabled, switching weapons still briefly updates the weapon sprite position to where it would be during the view-bob before snapping back to center. Try holding down fire while swapping weapons and then stopping once switched.

 

Screenshots:

 

Spoiler

 

DOOM0001.png.90371fda79ab1f2d016ff44e774fa81d.png

 

DOOM0002.png.49b4a22bcb39d4ba7410b72e4b436475.png

 

 

EDIT: This also affects the rocket launcher and BFG with view-bobbing set to full, due to their safety locks. Bobbing does not resume until fire is released which does not happen in Chocolate.

Edited by maxmanium

Share this post


Link to post
14 hours ago, maxmanium said:

I don't know if this is actually a bug or not, but I noticed that with view-bobbing disabled, switching weapons still briefly updates the weapon sprite position to where it would be during the view-bob before snapping back to center.

 

I wouldn't call it a bug, but an implementation detail - a look behind the scenes. Actually, changing weapons is the critical part of this feature, because the vertical position of the weapon sprite determines how long it takes to lower the weapon and thus how many tics the weapon changes takes. So, the weapon sprites get rendered at their original coordinates during these phases.

 

14 hours ago, maxmanium said:

EDIT: This also affects the rocket launcher and BFG with view-bobbing set to full, due to their safety locks. Bobbing does not resume until fire is released which does not happen in Chocolate.

 

Ah, this is because I check for the attack key being held down instead of the weapon being in its actual attacking state. Will probably have to change this, thanks!

Share this post


Link to post
4 minutes ago, fabian said:

 

I wouldn't call it a bug, but an implementation detail - a look behind the scenes. Actually, changing weapons is the critical part of this feature, because the vertical position of the weapon sprite determines how long it takes to lower the weapon and thus how many tics the weapon changes takes. So, the weapon sprites get rendered at their original coordinates during these phases.

 

Wow, I had no idea that the time to change weapons wasn't constant.

Share this post


Link to post
On 10/20/2019 at 5:37 PM, seed said:

Well, one thing's for sure, it kinda has one apparently, but I don't know if the exact time can be figured, all I know is that it shows up as "SUCKS" on the real hardware, according to the video I posted above, rather than :00.

 

Done: https://github.com/chocolate-doom/chocolate-doom/commit/00d2024fec6136457981680e0b0422acf0eb1850

 

@UndeadRyker @maxmanium Could you confirm the issues you have previously seen with reduced bobbing are all fixed now?

Share this post


Link to post
On 9/3/2019 at 10:41 PM, 2mg said:

 

That's, uh, unfortunate. Is Crispy using two different tickers for engine and rendering when framerate is uncapped?

 

 

For reference, I couldn't notice it in Doom3BFG/Classic RBDOOM with Vsync aka swap_interval for OpenGL (although it's hard to notice since those are locked to 35hz), and neither in GZDoom with frame interpolation.


@2mg I experience the exact same issue as you. The input lag in Crispy with uncapped + vsync on, but perfectly smooth in GZDoom. It's such as a shame as I would like to use Crispy, but I don't like the 35FPS experience.

For me, the input lag goes away if I use uncapped + vsync off, but then the screen starts 'warping' when I turn with the mouse.

Btw, I also experience the exact same thing with Doom Retro. It's possible to play for a bit and get used to the lag, but it's so much nicer without it, which is why I end up going back to GZDoom.

 

edit: Using different settings for VSync in the NVIDIA Control Panel and turning vsync off in Crispy produces different results depending on the setting. Some settings can make the input lag go away, but I still get left with the 'warping'.

Edited by jacderida

Share this post


Link to post

Any chance of adding an option to only show the ENDOOM screen when it's been modified? It's a little annoying having to close it every time I quit, but I enjoy seeing it when wads modify the ENDOOM screen.

Share this post


Link to post

Okay, so far the in-game demo restart button has been working perfectly. There's just one thing about it:

 

If going for a movie run, so you start from map01, you die in map03, you hit the restart key, it restarts map03. Even though it should restart from map01, of course. So it should remember the map## where you started, if demo recording is on.

 

Of course the same thing is a problem, when you actually finish the level, but not just fast enough, so you wanna keep on restarting the level.

 

Also, this in-game restart is awesome as it fixes the quick start, too. It is a bit more trickier to get correct, as you don't get to buffer the inputs into the first frame, but to the second frame. I think it is because of the order of the commands given to the game. The first frame will have the inputs from the frame you hit the restart button. Which means, you better be turning extremely fast, if you need to turn fast at the beginning of the demo. I am not sure if that is a problem though, but just something to think about. And the best part about this kind of quick start is that it is CONSISTENT. I always get what I expected to get from the keys I press. No missed frames, nothing. It is extremely close to perfect.

Share this post


Link to post

And now as I have tested it for a longer period of time... the 2nd frame started to have one wait frame there, no idea why D: I press the keys the same way as I used to. At least managed to tie the doom2 map01 nomonsters record (5.09) while it lasted !

Share this post


Link to post

Ohhh!! I fixed it! It was based on the amount of demos in the folder! The moment when the demo amount exceeded 64 files, it went inconsistent.

 

no01-.lmp

no01--00000.lmp

no01--00001.lmp

...

no01--00061.lmp (still working)

no01--00062.lmp (now broken quick start)

no01--00063.lmp (broken quick start)

 

 

OH YEAH! I can make 63 perfect quick starts in a row now, consistently. Just have to keep cutting and pasting those 64 demos to another folder, lol.

 

 

I mean only those no01-.lmp 's matter, not some randomly name like demo.lmp, asd.lmp and such do NOT count for the 64.

Edited by Looper : Clarification

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×