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!)

[Eric Claus]

3 minutes ago, GooberMan said:

Stuff

 

Hey makes perfect sense and I can understand how you feel on that as it would take continued commitment to keep a source port going, and even if I was a coder myself I don't think I could do it to be honest.  Thank you for your hard work nonetheless and I am glad to hear that others are running with your work!

[Redneckerz]

10 hours ago, GooberMan said:

Oh, nah, sorry mate. Context, I guess.

 

Short story is that I am bipolar, so sooner or later I'll just flat out lose interest in this. The fact that people like Altazimuth are waiting on my results and that it will subsequently benefit a large part of the community means that my focus will stay for far longer than it did for, say, BSP2DOOM. Which I couldn't get enough people proper interested in. Code still exists, theory is still about the same even after digging deep in to the renderer, but no real incentive to continue the work. And also my Demon Workers Unite! mapset, which I had grand plans of being an industry-wide relaxation effort but no one (outside of Kaiser for an intro map) seemed interested in.

Funny that you mentions these things as i just started to dig around your history to find well, what you have made (including Calamity) and bring them once more to attention to the public (Like your tech demo wads) but also earlier stuff the early 00's,

 

Why? Because, besides reading interesting tech drama between two pro coders, its often people like you (coders/programmers ailke) that come up with the most original things. Original things worth archiving and preserving because the chance of someone else coming up with the same idea/solution for an oddly obscure problem is close to zero.

 

And also because they deserve preservation in the first place.

 

That's just me though. Im no scripting nut, no resident expert programmer or even a mapper - I am (somewhat?) capable of tracking down histories, retrieving obscure source code, and documenting it. But everyone has his expertise - Yours is just being great at code and scripts.

 

Keep up your thing with Rum & Raisin, regardless if it remains a significant optimization step for the Doom renderer or a full blown port. For sakes of sanity (given you also work professionally on games) prefer the former: As long as those optimizations are a good learning school for others to be inspired by.

 

I hold no significance in this place here, but i thank you for all the efforts you have been doing - And like i mentioned above, if you ever need your work preserved or documented or given attention to, just holla up. Its the least i can do.

 

[GooberMan]

Just leaving some 21:9 shots.
 

 

 

 

 

And also:
 

 

I'll use this scene as a guidepost to see if my visplane lookup code is working as intended. At 21:9 and 4 render contexts, the middle 2 overlap the normal HUD. And the other two hit blocking walls fairly quickly, hence their disproportionately small times. Fixing the render load balancing code to not be a colossal fustercluck will also help spread the cost, but as I always say in a professional environment: Threading is not a silver bullet, your slow code is still slow on another thread.

[GooberMan]

https://github.com/GooberMan/rum-and-raisin-doom/wiki/Rendering-Visplanes-by-Column

 

New article. Attempts to give a ground up understanding of all the concepts involved with rendering visplanes by column.

[GooberMan]

Well, it was inevitable. But real life has gotten in the way of progress over the last couple of weeks.

 

Next thing to come will be an article on the threading. And before I go any further with features, I think I'll need to re-architect a few things so that I don't lose some vanilla compatibility I want to keep.

[Redneckerz]

22 minutes ago, GooberMan said:

Well, it was inevitable. But real life has gotten in the way of progress over the last couple of weeks.

 

Next thing to come will be an article on the threading. And before I go any further with features, I think I'll need to re-architect a few things so that I don't lose some vanilla compatibility I want to keep.

IF we could just get rid of Real Life, then you would have had more time.

 

Kidding, but all the best. I love reading your progress and getting it out to as many as possible, it deserves it.

[VGA]

Here are some demanding vanilla format maps, like Breach and Frozen Time (except some highres textures and the translucency effect not working, it is a super-benchmark)

 

[GooberMan]

Update on this: There is no update. Why? So I stepped up to Technical Director a few months ago at Housemarque. My focus right now is on shipping the game. I don't expect to get back to R&R Doom until late May at the earliest.

Edited February 12, 2021 by GooberMan

[Bauul]

3 minutes ago, GooberMan said:

Update on this: There is no update. Why? So I stepped up to Technical Director a few months ago at Housemarque. My focus right now is on shipping the fucker. I don't expect to get back to R&R Doom until late May at the earliest.

 

Congrats on the new position! Returnal has been looking interesting since the first trailer, so good luck on getting it out the door!

 

No rush on R&R Doom, obviously real life comes first, but know we are eagerly awaiting your return!

[Turin Turambar]

22 hours ago, GooberMan said:

Update on this: There is no update. Why? So I stepped up to Technical Director a few months ago at Housemarque. My focus right now is on shipping the game. I don't expect to get back to R&R Doom until late May at the earliest.

 

I hope Returnal comes to PC eventually!

[parlortricks]

GooberMan, is there a way to compile this source without choco-heretic and choco-strife. Seems to compile choco-doom fine, but bombs out on the other two (you did mention they were a problem), i just don't see an option to only compile doom?

 

Love reading everything about what you have done, it's great!

[tengv]

I'm trying to compile this source following the chocolate doom build process here: https://www.chocolate-doom.org/wiki/index.php/Building_Chocolate_Doom_on_Windows but I get stuck at the step "./autogen.sh --host=i686-w64-mingw32." Does anyone have an idea about what I'm doing wrong? I'd appreciate any help... :/

[parlortricks]

On 6/4/2021 at 12:34 PM, parlortricks said:

GooberMan, is there a way to compile this source without choco-heretic and choco-strife. Seems to compile choco-doom fine, but bombs out on the other two (you did mention they were a problem), i just don't see an option to only compile doom?

 

Love reading everything about what you have done, it's great!

 

Did some digging and found the executable in './rum-and-raisin-doom/src' and ran it inside my debian VM, excellent!

[liPillON]

hey sorry to dig this out of the grave, but I just came across this topic when searching info about the sw renderer on google

 

now I'm wondering: did any of these optimizations find its way into any publicly available source port?

 

 

 

 

 

 

[Redneckerz]

3 hours ago, Delfino Furioso said:

hey sorry to dig this out of the grave, but I just came across this topic when searching info about the sw renderer on google

 

now I'm wondering: did any of these optimizations find its way into any publicly available source port?

No. 

Gibbon took a look at compiling but it is rather tricky.

[Gibbon]

21 minutes ago, Redneckerz said:

No. 

Gibbon took a look at compiling but it is rather tricky.

I’ll take another look next week though, does seem interesting but the amount of code and libraries used for the multithreaded renderer would make it pretty hard for other ports to accommodate.

[dpJudas]

GZDoom has an implementation of some of the optimizations. In particular the one that splits the scene into multiple slices for the BSP.

Edited March 13, 2022 by dpJudas

[GooberMan]

I generated a MSVC project way back when I started working on this for use in Windows. Have not looked at the Windows compilation chain outside of that at all. Linux works fine (ignore Heretic/Hexen/Strife not compiling, Doom will generate binaries), autogen then make - if you're looking for a quick Windows compilation chain, I'd hijack that somehow. OSX also was working using the Chocolate Doom steps, but I've not compiled it myself. Maybe I'll look in to a Windows Package Manager chain for it.

 

The rendering code also uses zero libraries. It writes direct to memory, so as long as you can pass it an 8-bit transposed backbuffer it'll go off and do its thing. The library additions are purely for the UI (accessible via ~ by default); and OpenGL wrappers for some future work I'll be doing.

 

Also. O hai.

 

I heard people like programming videos.

 

(Still processing HD at the time of posting)

It was meant to be a livestream, but the account I've posted it to won't allow me to do that until some time tomorrow. So whatever. Short story: After adding automap colour customisation because I was sick of missing monsters, I decided to reenable the colour pulsing code that was written but never used. It was a bit of a hack in the first place though, so I made it not-hacky as I went.

Edited May 17, 2022 by GooberMan

[Gibbon]

Can we get binaries for this?  Last time I tried on Windows, compiling it was a real pain plus it uses some now deprecated imgui api calls that aren’t in the latest GitHub versions.

[GooberMan]

9 hours ago, Gibbon said:

it uses some now deprecated imgui api calls that aren’t in the latest GitHub versions.

 

There's your first problem. The instructions on the Github tell you how to do a correct submodule initialisation. The additional libraries I include are all source drops that don't require additional packages to be located and installed, and the code that isn't explicitly submitted to my Github are explicitly linked as submodules to the correct versions required.

 

Attempting to compile with latest version of a library for just about any software will get you these kinds of troubles.

 

9 hours ago, Gibbon said:

Can we get binaries for this?

 

I see you're doing a source port archive, which is commendable. But I'm going to stick with what I said in the first post:

 

On 10/12/2020 at 12:43 AM, GooberMan said:

This is source-only for now, exact same build steps as Chocolate Doom. I have no time to provide to support for anyone (so don't ask); and the code certainly isn't in release quality yet. Until that changes you can consider this project to be academic in nature, with real and testable results.

 

There will come a time when I think this source port can stand on its own as a usable purist+resolution style of port (let alone the additional features I have in mind). At that point in time, it will see a proper supported release. Until then, I don't really want to provide binaries on the logic that as-is source code is a higher barrier of entry to as-is binaries and thus raises the barrier for people that will ask me about the code.

[GooberMan]

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.1.0

 

So I decided to finish the basic options menu and make a binary release.

 

Windows 32-bit only, and 100% unsupported.

[Redneckerz]

18 hours ago, GooberMan said:

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.1.0

 

So I decided to finish the basic options menu and make a binary release.

 

Windows 32-bit only, and 100% unsupported.

Just wanted to give a heads up and thank you for providing this release and having people toy around with your improvements - Knowing your work and craft at Housemarque, time is of the utmost essence. With this binary release, people can have a taste at what you are at.

 

Thank you.

[GooberMan]

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.1.1

 

Quote

The one everyone will be interested in is the -removelimits command line. Rum and Raisin Doom is now a limit-removing port. The original vanilla limits are enforced by default. Using this command line, standard Doom maps treat many unsigned short fields as signed; and DeepBSP support is in progress.

 

Tested maps:

• Hellbound MAP29 is completable
• Planisphere 2 loads, but immediately crashes when you try to move

The fullscreen code has also had a minor rejig after SDL changed behaviors on me, the fullscreen borderless presentation is now handled manually. Exclusive fullscreen might come back if I feel like it (read: if VRR needs it when I get around to it).

 

Of note on the source side: Inside the msvc folder is working projects for Visual Studio 2022. Load it up with the rum-and-raisin-doom.sln file in the root folder. Change the include-sdl.props property sheet to point to your SDL installation.

 

The new C++ code is also C++20 minimum. The map loading code has been cleaned up quite significantly, and is full of template code now.

 

[GooberMan]

So I'm working on the load balancing code finally.

 

 

You can brute force Hellbound MAP29 to a playable state in the current 0.1.1 release by throwing more threads at it (use the -numrendercontexts command line). But that's silly. This code is meant to also run on a power-limited platform like a Switch or a Raspberry Pi 4. This means that each thread should do an equal amount of work, which isn't going to happen if you split the screen once for each thread and be done with it.

 

So tl;dr I'm trying to distribute the work correctly across cores. There will be spikes, it's not easy to predict in Doom when a scene is about to get heavy. So it is leading to some ideas for a more sophisticated approach.

[Redneckerz]

Love that you found the time to work on this @GooberMan. All the effort that goes into this is also a good test bed for other people to look and see how to SIMD the renderer of Doom.

[Jaccident]

I just discovered this sourceport and I have to say I'm in awe of what you're doing here. Awesome work, I hope someday I'll be able to do anything even half as complex as this. I'm also absolutely loving reading through your explanations of features of your new software renderer.

[Noiser]

I'm very excited with this! I tried with some of my maps and it works like a charm

Edited May 31, 2022 by Noiser

[Andromeda]

Fascinating!

[GooberMan]

Up and running on Raspberry Pi Ubuntu 22. My Ubuntu 20 card got corrupted somehow, 7 flashes of the green LED means no bootable image. Took the chance to upgrade and perform a bit of maintenance while I was there.

 

Fullscreen goes wonky, will have to patch that up. Might need to roll back to that previous code for non-Windows platforms in fact.

 

[GooberMan]

Having issues with the blockmap on Planisphere 2. So I disabled it and went around the map for a looksee and

 

 

Yeah. So there's a lot going on here. The huge size of the map at a minimum means that 16.16 fixed for the renderer isn't going to cut it.

 

I'm in the process of converting large chunks of code over to C++. I don't think I'll be able to make progress on the rendering for Planisphere until I've converted the renderer over - at which point I can consider using alternative fixed point formats. For vanilla accuracy I'll probably still keep it to <x>.16, but it's certainly going to need a larger integral space to handle all the transformations and scalings that go on.

 

(Video might take a little while to get away from potato quality from time of posting, turns out that someone has put copyright claims up for Duke Nukem 3D tracks so I clicked the "mute section" option. One minute out of 10, despite the track playing on the entire video. But that's enough to make YouTube take its sweet motherloving time to process.)