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

dsda-doom source port [v0.24.3]

Recommended Posts

Just now, omalefico32x said:

thing is vsync sucks with 60hz monitors because it makes your aim weird since you are still controling doom guy at 35 fps it works perfectly but using uncapped you need more then 60hz for it to feel right (yea i know there are people who are acostumed to it but still)

if there was a option to cap frames to 70 it would already be a huge improvement in my book since i wouldint need to play at 35 or make my laptop so loud that i cant play while listening to something else

i think you can cap the FPS of any game using nvidia control panel

Share this post


Link to post
Just now, El juancho said:

i think you can cap the FPS of any game using nvidia control panel

i use intel and while its possible to do it on linux using intel its not really a straight forward process 

Share this post


Link to post
15 minutes ago, omalefico32x said:

thing is vsync sucks with 60hz monitors because it makes your aim weird since you are still controling doom guy at 35 fps it works perfectly but using uncapped you need more then 60hz for it to feel right (yea i know there are people who are acostumed to it but still)

if there was a option to cap frames to 70 it would already be a huge improvement in my book since i wouldint need to play at 35 or make my laptop so loud that i cant play while listening to something else

That's a good point about the fps factor. I have 144Hz, which is quite close to 4x35, so maybe that's why it didn't do much. I can take another crack at that.

Share this post


Link to post
19 hours ago, Catoptromancy said:

I remember when Freedoom first implemented Final Doom support there would be desyncs if the iwad was changed even though a pwad was recorded. Freedoom was being recognized as Doom2, and pwad was for plutonia. I think it was a complevel issue, due to recording a different port that was emulating complevel 2, while pr+ was using complevel 4.

Maybe this can be helpful since I did not record that with the heretic iwad.

 

I will rerun that demo using 1.2 vanilla to see what happens. 

Your desync is caused by pausing. I have to find out exactly why, because it only happens for one of them, but in the meantime don't pause in the middle of heretic demos :^) (you can't pause the way you do for speedruns anyway, although maybe you are just using this for casual demos)

Share this post


Link to post
2 minutes ago, kraflab said:

That's a good point about the fps factor. I have 144Hz, which is quite close to 4x35, so maybe that's why it didn't do much. I can take another crack at that.

thanks i wished more source port devs cared about this i think the reason why so many people say they see no difference in gameplay with vsync is because they have high refresh rate monitors

Share this post


Link to post
17 minutes ago, kraflab said:

in the meantime don't pause in the middle of heretic demos

Fixed for the next release.

Share this post


Link to post

I dont speedrun. I go for quantity over quality.

 

Since I can remember, the pause key in pr+ kept the demo recording. Hitting the menu key stops the demo recording. If I am going to be afk more than a minute, I will pause then hit menu key to display where I took a break, had to go work. But for that demo I probably menu paused a few times, and pause+menu right near the end.

 

I long awhile ago I found pausing during intermission caused a desync, with demo itself.

Edited by Catoptromancy

Share this post


Link to post
19 minutes ago, Catoptromancy said:

I dont speedrun. I go for quantity over quality.

 

Since I can remember, the pause key in pr+ kept the demo recording. Hitting the menu key stops the demo recording. If I am going to be afk more than a minute, I will pause then hit menu key to display where I took a break, had to go work. But for that demo I probably menu paused a few times, and pause+menu right near the end.

If you just go to the menu to pause the game, then there won't be a desync in the current version. It's specifically when you press the pause key - fyi.

Share this post


Link to post

I've actually been experimenting with vsync and at least on my hardware configuration, I see no benefit in enabling vsync in software mode at all. My screen doesn't tear and movement feels incredibly snappy without it. Opengl is very much the same although fullscreen can introduce tearing. Fullscreen exclusive introduces tearing for both rendering modes however. 

 

I have an experimental fork where I'm currently toying around with a smart vsync option where vsync is disabled in situations where tearing shouldn't be an issue and enabling it when tearing would be present. I made sure to add a hard cap of 500 to my fork as opengl uncapped runs at 1000+ fps which is massively overkill. I need to look into a better implementation however as sdl ms timings using integer leads to rounding error innacuracies. 

Share this post


Link to post

I play in exclusive screen mode because i got more fps and less input lag, i have a 144hz monitor and is really hard to notice screen tearing.

Share this post


Link to post
2 minutes ago, El juancho said:

I play in exclusive screen mode because i got more fps and less input lag, i have a 144hz monitor and is really hard to notice screen tearing.

For exclusive fullscreen or opengl fullscreen vsync is forced, so that wouldn't be a problem in that use case. Uncapping is far more useful for 60hz screens like the ones I use. 

Share this post


Link to post
18 minutes ago, Charlie Love said:

For exclusive fullscreen or opengl fullscreen vsync is forced, so that wouldn't be a problem in that use case. Uncapping is far more useful for 60hz screens like the ones I use. 

Are you sure? I have tearing while playing in exclusive screen and in opengl mode.

Share this post


Link to post
9 minutes ago, El juancho said:

Are you sure? I have tearing while playing in exclusive screen and in opengl mode.

You still have to enable smart vsync to get any vsync in my fork. If you're using standard dsda you should continue getting vsync regardless. I don't use open gl or exclusive fullscreen, so I might have missed something but I believe it should work. 

 

Also, exclusive fullscreen does nothing unless fullscreen is also enabled.

Edited by Charlie Love

Share this post


Link to post

Can we have an option to choose different types of (openGL) fuzz like in prboom+um please? I don't really like the default one.

 

And random question, is -longtics legal for submitting demos to DSDA?

Edited by El juancho

Share this post


Link to post
35 minutes ago, El juancho said:

And random question, is -longtics legal for submitting demos to DSDA?

from DSDA-Doom port page //

 

-longtics - this causes the demo to use higher precision for turning. This should not be used for the original games, but is allowed for custom maps. Generally, many tricks are harder with this setting. This does not work with complevel 9.

Share this post


Link to post

-longtics is allowed, but frowned upon and will probably result in your demo having a "Uses longtics" note under it on DSDA.

Share this post


Link to post
1 minute ago, Andromeda said:

-longtics is allowed, but frowned upon and will probably result in your demo having a "Uses longtics" note under it on DSDA.

 

Why is it frowned upon for newer maps? Seems unnecessarily elitist.

Share this post


Link to post

I think I might've discovered a minor bug related to UMAPINFO.  I'd put together a UMAPINFO file for Eviternity and figured out that by using the "enterpic" field for each map, I could have the map's special graphic (which is of type Graphic (Doom) than a Graphic (Flat)) display as it loaded rather than melting from a black screen.  However, when I watched someone streaming Eviternity finish the game while using my file, after the stats screen for Map 30 disappeared, it briefly showed the graphic for Map 31 before melting to the ending story screen.  Is there something that can be done to not load the next numeric level's enterpic value if the level just completed has one of the endgame fields specified (my Map 30 entry has endcast = true)?

eviternity_um.zip

Edited by Bytefyre : Attached WAD file containing UMAPINFO for testing

Share this post


Link to post
2 hours ago, El juancho said:

Can we have an option to choose different types of (openGL) fuzz like in prboom+um please? I don't really like the default one.

 

And random question, is -longtics legal for submitting demos to DSDA?

Probably not an option, but we will be tweaking fuzz for 0.21 so that it is less fucked up :^)

Share this post


Link to post
1 hour ago, maxmanium said:

 

Why is it frowned upon for newer maps? Seems unnecessarily elitist.

It's not frowned upon for newer maps. Only for the iwads really.

Share this post


Link to post

Hexen save issue fix coming in 0.21, as well as a fix for a performance issue introduced in 0.20 🧐

Share this post


Link to post

Well, one issue with -longtics is that it is no longer a vanilla-compatible demo. The major ports all support it, but it is not a standard.

Share this post


Link to post

Worth noting that -longtics only works on certain complevels while recording; notably, -complevel 9 does not support longtics. MBF21 (-complevel 21) does support longtics, which is just one reason I'm looking forward to more wads built for the standard.

Share this post


Link to post

i understand people wanting longtics but it really is not necessary. its funny because when i go back to longtics (sometimes i load up zdoom or prboom+ without recording a demo) and it feels so strange!

Share this post


Link to post
6 minutes ago, rehelekretep said:

i understand people wanting longtics but it really is not necessary. its funny because when i go back to longtics (sometimes i load up zdoom or prboom+ without recording a demo) and it feels so strange!

Well, there are tricks that only work with longtics, so it does have speedrunning applications (and for instance this would be a case where your demo would potentially go into other)

Share this post


Link to post

Some switch presses will be easier with longtics, and some only possible with longtics - you have fixed angles to work with, it's entirely possible for a switch to not be pressable from any shorttic angle. There are void glides that require longtics (or maybe are just easier?). Guided glides in the wrong direction would be another case where it may be easier with longtics (probably depends on the exact situation). You could have a situation where you can only sequence break a shoot trigger with longtics (this is just an extension of the switch press point). Etc

Share this post


Link to post
Guest
This topic is now closed to further replies.
×