Forgot to push a merge

[Rachael]

... and did a pull with a rebase that had conflicts... I rebased against the remote HEAD (hopefully that's okay) and then pushed my changes.

I hope this didn't mess anything up with the repository.

Please let me know if it caused any problems.

[dpJudas]

I haven't noticed any problems. So I guess it's all good.

Btw., I removed the last remains of the SSE drawers. I'm planning to add LLVM versions of the palette drawers as well. This will allow the multithreaded backend to be used by both versions. Longer term it should make it easier to add new drawer types.

[Rachael]

Alrighty then.

And this sounds awesome! I've been mulling over the paletted drawers problem with the sprites, it seems like there's really only several of them to worry about - a pair for each renderstyle type. One for 1 column and one for 4. They might be a pain in the butt to replace, but my guess is they're not as hard as I originally made it out to be. XD

[dpJudas]

Ah, but I meant the palette output drawers. The column drawers reading 8 bit input textures I've ported over already (see the DrawColumnCodegen class), although they still use palette input unfortunately.

You're right about only a pair for each, but what makes them a little tricky to convert to fully true color is the way they do translation. The normal drawers exist in both normal and translated versions (as listed by my brand new DrawColumnVariant enum!), but the rt drawers only do normal drawing. This means R_DrawColumnHoriz_rgba can't just copy over the rgba texture data, because something might call rt_Translate4cols where it needs palette indices as input.

The good news is that my DrawColumnCodegen class can actually already generate the missing translated versions. I didn't plan this, but the way the new code shares code between all the variations of column drawers this came for free. Think I'll try see if can get this fixed first before the 8 bit output thing - it suddenly got a lot easier just thinking about it!

[Rachael]

Oh. >_> Well - learn something new every day!

I'll understand this monster sooner or later... Carmack's 24 year old code will not best me! lol

By the way I pushed some pk3 changes. The truecolor options now have their own menu (I left the linear sky in the main display menu though, since it affects the palette drawer).

I added r_multithreaded to the menu, for now. I will remove it once the code stops crashing when there's a thousand sprites on the screen. I still haven't figured out what's causing that, it seems to crash in different places. r_multithreaded definitely doesn't stop the crash, but turning it off seems to increase the tolerance before it does.

[dpJudas]

I'll understand this monster sooner or later... Carmack's 24 year old code will not best me! lol

Honestly, if you manage to understand just half of the software renderer that would be a major achievement! This code is some of the worst code I've ever seen when it comes to separation of concerns. Even with over 20 years of C++ experience and soon half a year toying with this code there are parts that I do not understand yet. Spaghetti code is too kind a word for what I think about the software renderer.

I added r_multithreaded to the menu, for now. I will remove it once the code stops crashing when there's a thousand sprites on the screen. I still haven't figured out what's causing that, it seems to crash in different places. r_multithreaded definitely doesn't stop the crash, but turning it off seems to increase the tolerance before it does.

I can add some asserts in the drawers that checks the ranges. Only thing is, first I'd have to replace dc_dest with some dc_dest_x and dc_dest_y variables so that the drawing position is actually known by the drawers.

[Rachael]

I've pulled worse code than that. >_> But nowhere near as complicated or on this scale, though. Let's just say - regardless of my lack of experience with C++, I do have experience with algorithms - and in fact, I think I actually learned how to draw 3D floors from the floor drawers in Doom's source code. But then - that was some 18 or so years ago and I merely stole the math from it.

As far as the asserts, if you think that's the best way to handle it, I trust your judgment. This issue is the biggest one that's stopped me from doing an official release. Are we able to change it back after we find the problem or would we leave it as-is? Mainly I ask, because I remember you said you wanted the TC drawers to look like the palette ones, and I agree with you, some consistency makes it a lot easier.

[dpJudas]

It is not that I haven't seen worse code, but usually what happens is that such code collapses under its own weight. Or the developers threaten to quit if it isn't refactored. Somehow, against all odds, the software renderer kept on going.

The asserts is the easiest way to try figure out if what you're seeing is due to a buffer overrun. As the drawers I added is doing nothing else than copying buffers, this is the easiest place to start. Might not amount to anything, but its relatively easy to add and might be effective for this kind of problem. I'm not sure how much a performance impact those assets will have - possibly little to none. Depending on that, if we can't measure the speed difference, I'd say we should keep them in.

[Rachael]

Well let's drop them in and see what happens, then. If it helps get to what is causing the crashes, then the cost would have been well worth it. We can assess the performance impact of it later.

[dpJudas]

Okay, will add that soon then. I'm a bit tired now. Just committed the switch to true color input for the column drawers. Seems to be working in E1M1 at least!

[Rachael]

Okay, will add that soon then. I'm a bit tired now. Just committed the switch to true color input for the column drawers. Seems to be working in E1M1 at least!

Yep, they seem to be working, too...

Screenshot_Doom_20161007_084415.png

Oh my god, I am so excited! Too bad I have to go out today.

[dpJudas]

Nice screenshot you got there. Very happy myself to have this part working - always annoyed me a bit that I didn't manage to get the whole thing to use true color textures.

[Rachael]

I've went through several attempts at what you did. And yet, you managed to do it yet again. XD

Well - I'm sure there is a lot of territory for me to conquer yet.

As far as the skyboxes go, I'm still working on a formula to get those working. Admittedly, I am having trouble with that - they really should cover Trigonometry for more than 2 weeks in high school. I don't even remember my College Algebra class even touching those functions at all. It kind of sucks - because while Trigonometry is hard, learning it is sooooo worth it.

[dpJudas]

This wasn't my first attempt at it.

About the skyboxes, I'd use the method specified in the OpenGL 4.5 specification, section 8.13 "Cube Map Texture Selection". It has the exact math required to find the right texture (table 8.19) and the texture coordinates (s,t) within that texture for a direction vector.

Totally agree that trigonometry and linear algebra should be covered much better in school. Not that it would have helped me that much as I only got through high school.

[Rachael]

Thank you for that. And thank you for everything else you've done, too. I'll read it tonight when I get home.