Rum and Raisin Doom - Haha software render go BRRRRR! (0.3.1-pre.8 bugfix release - I'm back! FOV sliders ahoy! STILL works with KDiKDiZD!)

[Codename_Delta]

2 minutes ago, GooberMan said:

The only thing I can think of that would cause a quit like that is if multiple threads are throwing an error. Launch Rum and Raisin with the -options parameter, go in to the Screen tab, and set Running Threads to 1. That will at least keep the message box up to let you know what's going on.

(And it looks to be about time I addressed that error handler, it's another thing that hasn't changed from Chocolate)

nothing even appears, it just crashes before it can get past the loading screen, when I click either Play! or launcher.

[Turin Turambar]

16 hours ago, GooberMan said:

ConSigNo had a crash in the same place earlier, gave me a GDB callstack indicating there's a crash in the TITLEPIC texture extraction/loading. Not sure what WAD triggers it yet, but knowing the cause means there'll certainly be a fix coming soon.

 

I'll also do a 0.3.1 release within the next week, including bug fixes and the file browser dialog (currently in a fairly ghetto state, and you can't select another drive on Windows yet because the C++ standards board didn't think std:: filesystem needed such frivolities so I need to do some platform specific special code to handle all that).

 

Don't feel obligated to put the file browser for my comment, it was more an observation than a complaint. I am well capable of copying my doom2.wad to the root folder :P

[GooberMan]

52 minutes ago, Codename_Delta said:

nothing even appears, it just crashes before it can get past the loading screen, when I click either Play! or launcher.

Alright, I'll prepare another release with new error handling code so that I can get causes and callstacks and not just exit the program.

[viti95]

1 hour ago, Codename_Delta said:

nothing even appears, it just crashes before it can get past the loading screen, when I click either Play! or launcher.

 

I had to remove the all the stored settings in order to execute properly the newest code, it was giving me Segmentation faults. Maybe that fixes the problem.

[Codename_Delta]

20 minutes ago, viti95 said:

 

I had to remove the all the stored settings in order to execute properly the newest code, it was giving me Segmentation faults. Maybe that fixes the problem.

stored settings?

like keybinds?

[GooberMan]

Copy %UserProfile%\Saved Games in to an explorer instance and delete the Rum and Raisin Doom folder found within. This will delete everything that Rum and Raisin stores on your system, allowing a fresh start.

[Codename_Delta]

19 minutes ago, GooberMan said:

Copy %UserProfile%\Saved Games in to an explorer instance and delete the Rum and Raisin Doom folder found within. This will delete everything that Rum and Raisin stores on your system, allowing a fresh start.

didn't work sadly, still crashes D:

 

wait, I'm stupid

 

nop doesn't work

Edited November 22, 2022 by Codename_Delta

[GooberMan]

If deleting the data did work, then that would narrow the cause down to something stupid I accidentally did with the music path setting. ConSigNo also got that one the other day, and a fix was applied not long after and made it in to that patch release.

 

I'll have to keep an eye out for such things in the future, they should basically not happen once I move over to a JSON configuration file but it's definitely worth thinking about. Crashes are fun for precisely no one 

[Codename_Delta]

1 minute ago, GooberMan said:

If deleting the data did work, then that would narrow the cause down to something stupid I accidentally did with the music path setting. ConSigNo also got that one the other day, and a fix was applied not long after and made it in to that patch release.

 

I'll have to keep an eye out for such things in the future, they should basically not happen once I move over to a JSON configuration file but it's definitely worth thinking about. Crashes are fun for precisely no one 

true, the port looks really cool too, could I use the most recent pre-3.0 version for now?

[GooberMan]

0.3.1-pre.1 should be good with fresh settings, yeah.

 

Of course, it's all "works for me" at the moment so be sure to report any more crashes/bugs/etc you get.

[Codename_Delta]

1 minute ago, GooberMan said:

0.3.1-pre.1 should be good with fresh settings, yeah.

 

Of course, it's all "works for me" at the moment so be sure to report any more crashes/bugs/etc you get.

will have to use 0.2.3 bc y'know both 0.3 vers crash 

[GooberMan]

On 11/22/2022 at 2:13 PM, viti95 said:

Also still waiting for the keyboard movement fix

 

Since I just pushed a fix for toggling strafe while using mouse movement, I will take a moment to talk about the hidden best feature of Rum and Raisin, and why the keyboard fix is taking its sweet-arsed time coming.

 

The feature? Zero mouse input lag.

 

Interpolation is an old trick. Any multiplayer game where the server runs at a lower update rate than the client's display monitor uses interpolation (and in some cases extrapolation) to put any dynamic object in the world at a place where you'd expect it to be instead of its actual current physical location. It's been in Doom source ports for a while, and it looks great but actually playing the game is another matter. If the game interpolates the player's previous and current rotations for its view frame, that introduces input lag. I've found prBoom and DSDA-Doom to be the worst offenders for this, they feel very wrong to me.

 

Rum and Raisin Doom aims to detach the human's viewpoint entirely from the playsim. With this, it can then run ahead of the playsim.

 

There's two things it needs to handle there: view rotation; and physical movement. View rotation is the easier of the two, and it is the one that is currently implemented for mouse only. Handling mouse rotation is fairly easy, and isn't handled in a fussy manner by the input code. Take the values from the input events, use them. So that's all I do. I peek at the input events for the next simulation frame and apply mouse rotation to the current rendering frame's viewpoint.

Keyboard and joystick are a little bit trickier because of everything beginning with this code:

if ( joyxmove < 0
	|| joyxmove > 0
	|| GameKeyDown( key_right )
	|| GameKeyDown( key_left ) )
{
	turnheld += ticdup;
}
else
{
	turnheld = 0;
}

It applies acceleration based on how many tics you've held the turn keys down for (or have been holding a joystick direction). And the tricky part is that this is a binary operation for any game tic. An example: you're running at 240 frames per second. This means you get about 7 render frames for every tick. Now, let's say you've tapped the turn button and managed to have the key down and key up event in between ticks. This will mean no turning for the tick - but if you try to do the same kind of interpolation as the mouse for keyboard inputs, you get an erroneous turn for <x> amount of ticks in the interpolator. Your view will jitter slightly.

 

So, I can go ahead and rewrite that input routine. Try to preserve the vanilla turning methods while allowing inter-frame rotations to occur. It'll still be 100% vanilla compatible though since the actual values used for movement and turning are separate from input events. Which means you can still record valid demos with it.

 

That's exactly where I take pause and need to consult with the community about it.

 

Here's the thing. If you play in ultrawide (let's say 32:9) at 120FPS and use the mouse, that's three technological advantages you have over vanilla doom. You can see more of the playfield, see it more often to the point where it starts approaching real-life information delivery times, and react to it before the next frame ticks. Now that's technically already possible with modern ports, but as I said Rum and Raisin will be allowing the player to play ahead of the playsim (the mouse rotation already lets you do that). That's potentially a disruptive change for speedrunning.

 

So. Am I overthinking things, or is this cause for concern? I'm going to go ahead with my plan anyway, but the question now is whether I implement some stuff in R&R that limits resolutions to 4:3 and negates this style of input for demo recording.

[Turin Turambar]

Given human reaction times, I think you are overthinking it? Just because technically the app allows for the player react before the next frame tick doesn't mean it is possible by real humans. We don't have reaction times that fast. Maybe you are a robot, dunno :P

[GooberMan]

I started noticing it when playing Call of Duty: Vanguard last year at 120Hz. It feels almost intangibly different to 60Hz, but I was noticing myself playing better than I had been. And yeah, it's just simple mathematics. CoD's multithreaded renderer means it takes one frame to simulate and one frame to render, ie you're seeing results two frames after input is read. At 60Hz, that's 33 milliseconds. And at 120Hz, that's 16 milliseconds. Rum and Raisin doesn't do that style of multithreaded rendering (yet - it will be an option) so that brings it down to 8 milliseconds at 120Hz. Or to put that in terms of the average human response time (150 milliseconds), it's gone from 22% of the time at 60Hz CoD, to 11% of the time at 120Hz CoD, to ~5% of the time in 120Hz R&R. It's way closer to real-life information delivery and response times, and it absolutely does make a difference. They don't call them "twitch shooters" for nothing.

I've got word that DSDA-Doom already does do something like what I've described, so it'll be the built-in prBoom lag that's making that port feel off for me.

Edited November 23, 2022 by GooberMan

[magicsofa]

9 minutes ago, Turin Turambar said:

Given human reaction times, I think you are overthinking it? Just because technically the app allows for the player react before the next frame tick doesn't mean it is possible by real humans. We don't have reaction times that fast. Maybe you are a robot, dunno :P

 

A good point, but speedrunning isn't all reaction time. A lot of it is actually practiced maneuvers that are being executed through muscle memory. In which case the faster response could make things easier... but then again, it might made things harder (at least initially) to a player who has practiced with more latency.

[GooberMan]

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.2

 

The file browser is in. It's only accessible from the "Change Selected Files" plus signs. Need to work out how to handle IWAD adding correctly, but at least if you select one from there it will actually update the IWAD list and choose that IWAD.

 

More importantly though: The error handler will try to catch every kind of exception and give you a callstack so I know where to go looking for the problem. For example:

 

 

Oh, yeah, I bluescreen on error now too. You'll see this sitting beneath the callstack dialog box:

 

[Turin Turambar]

Doomcute!

[viti95]

8 hours ago, GooberMan said:

Oh, yeah, I bluescreen on error now too. You'll see this sitting beneath the callstack dialog box: 

 

 

I absolutely love this idea!! Maybe I'll do something similar for FastDoom

[Danfun64]

On 11/17/2022 at 5:53 PM, GooberMan said:

 

Let's talk about the Shareware IWAD though. Because uploading the .WAD by itself is a violation of the shareware release's "distribute without modification" clause. And Bethesda doesn't like you violating its clauses. Wat do? Well, the following:

1. Download the shareware zip
2. Extract the shareware zip
3. Look for a .DAT file to ensure you've got a ye-olde DeICE installer package
4. Recombine the .1/.2/.etc files in to one to make a valid DOS-executable self-extracting zip
5. Strip the zip file from the executable in to a separate file (actually an unnecessary step)
6. Extract that zip somewhere
7. Now you have a DOOM1.WAD ready to use

I've written ZIP handlers before, but that was in 2010. I totally forgot that the table of contents being at the end of the file means you don't even need to do step 6. Any unzipper code can handle it from there. This didn't click until after I'd written a DOS executable header reader, extracted the contents from the data segment, and patched up the table of contents' sizes to exclude the original executable data. Oh well. At least it's a ZIP that has no chance of running as code once I'm done with it.

 

I will look in to splitting that code in to a separate Github repository and making a utility out of it. I'm sure it'll come in handy for anyone trying to get data from original disks without resorting to DOSBox to run a full install.

The Doom95 distribution on idgames comes with doom1.wad IIRC

[GooberMan]

Yeah, but Heretic doesn't have the same treatment for example. So I decided on solving that problem before I got there.

[Codename_Delta]

apparently it's an unhandled exception causing the crashes

[Codename_Delta]

okay, I can run it without trying to access the launcher, but the sounds sound nothing like even choco for example, idk they sound really lq to me.

[Edward850]

Can you record a comparison?

[Codename_Delta]

9 minutes ago, Edward850 said:

Can you record a comparison?

laptop doesn't like recording too much, but when I click launcher from the options thing, it crashes from an unhandled exception, and when I click play, it launches normally.

 

now it won't stop

Edited November 25, 2022 by Codename_Delta

[GooberMan]

1 hour ago, Codename_Delta said:

the sounds sound nothing like even choco for example, idk they sound really lq to me.

If you use libsamplerate in Choco, you will get the same sounds.

 

I'm in the middle of setting up the sound options so that you can change the resample quality on the fly. Right now, it's not using the highest quality resample because it significantly affects load time. I will also cache the results once you've selected them so that it's not necessary to recompute them every time you use them but it does mean working out the correct path to cache the results to, ie tracking which WAD it the sound sample comes from and caching based on that filename.

 

I've got a callstack from someone else for the unhandled exception, so I should be closer to tracking that down.

[Codename_Delta]

It turns out that the level stat tracker resets if you load a save, you might want to fix that.

[Floowand]

In the last git i still get the crash at the "updating wad dictionary"

[Codename_Delta]

8 hours ago, Floowand said:

In the last git i still get the crash at the "updating wad dictionary"

Yeah, click play instead of launcher, use a mod loader too

[Floowand]

Well, i used a mod loader and this time the "play!" option appeared but then proceed to crash when loading the iwad.

I think this source port just doesn't like me.

[GooberMan]

5 hours ago, Floowand said:

I think this source port just doesn't like me.

It's more like this source port is encountering a WAD that gives it unexpected data, and I have zero information on what WAD it is so it keeps crashing. It's probably some ZDoom targeted WAD though, I did find some issues trying to load NUTS3.WAD (which is completely playable in Rum and Raisin).

To that end though, there's a new pre-release version that has extra error checking in where I think the crash might be. If this gives good information, then copy/paste the error. Screenshot or follow the CTRL+C to copy instructions, either way will give me the information I need.

 

On 11/26/2022 at 3:10 PM, Codename_Delta said:

It turns out that the level stat tracker resets if you load a save, you might want to fix that.

Also "fixed" in the new pre-release. And the quote marks there need some explaining.

Rum and Raisin Doom's saved games are 100% vanilla compatible. You can load them up in Chocolate or DOS Doom and they'll work. Now, this is a minor problem for stat trackers. Doom's gamesim operates destructively on sectors - walk in to a secret sector and it unsets the secret special. And it's that special type that gets pushed in to save games. Load a game, the only way you'd know if it was ever a secret is to keep track of that in between loading the map and loading the savegame.

 

I've taken the approach of just dumping extended information at the end of the save game file.

 

There's more than just sector secret states that I track - I also dump monster resurrection counts. This is important for when the stat readout designer gets implemented, allowing people to customise the readout if they just want to know how many monsters count towards the killcount.

 

The extended savegame lump has had versioning since the start, so you can load old save games and they'll work but they'll still have bad stats. New save games will have the correct stats.