Truecolor software rendering

[dpJudas]

Thanks for testing, Edward-san. I've fixed the warnings/bugs you listed first in your post.

I think the black screen issue is related to the SDL target. Unfortunately when I try to build zdoom on my Linux Mint 17.2 I run into the problem that its gcc does not support C++14. That causes a number of errors in zcc_expr.cpp. Trying to see if I can figure out how to upgrade this Linux box now.

About the drawers using texture data after it got unloaded isn't entirely surprising to me. My worker threads assume that any buffer passed to the drawer functions will remain valid until the next R_FinishDrawerCommands call. I haven't gone closely through the code to verify this is actually always the case, although I haven't seen it crash in Windows with a callstack like you're showing. I'll add some checks that makes sure such a guarantee can be met.

[Edward-san]

The latest changes fixed the asan issues for me and also it's coming quite nicely

Now what you have to fix absolutely is the console background (black transparency lost) and the fonts (bad appearance in: console, options menu, status bar, intermission percentage and time reports, vid_fps text).

[dpJudas]

Ah, excellent! You gave it another spin! Yes, it is starting to look really good if I may say so myself.

The fonts stuff is easy to fix I'm sure. I just need to figure out which drawer function is responsible for drawing this part. The Windows port uses textures for drawing the HUD and menus, which is why it is working there.

[Graf Zahl]

Fonts, and any other 2D stuff go through DCanvas::DrawTextureParms which calls a few different column drawers. For fonts it should use the one for translations.
You can force this mode on by setting the vid_hw2d CVAR to false if you need to test on Windows.

[dpJudas]

Okay with the help of Edward-san I think my changes for this feature are pretty stable now. It doesn't do sloped sectors correctly, but I need a working palette version of that drawing code before I can implement it.

I've created a new branch for it (https://github.com/dpjudas/zdoom/tree/truecolor) that shouldn't change while I do other things on my master branch. Do you want me to create a pull request with what is in it? I'm assuming the original got closed because of all my commit spam. If there's another reason please let me know.

[Graf Zahl]

This will have to wait until Randi comes back to fix the rendering problems, but yes, for testing a clean pull request would be appreciated.

[rombust]

I just wanted to mention that this fork is really impressive. Great work

[Graf Zahl]

This will have to wait until Randi comes back to fix the rendering problems, but yes, for testing a clean pull request would be appreciated.

Since the worst problems have been fixed by now, how about that PR?

[dpJudas]

Okay, created the PR for it: https://github.com/rheit/zdoom/pull/750

Note that this patch is very large. This is mainly because all the drawer functions for palette mode also have a rgba version now (along with a SSE version). The large number of files affected is because it adds bgra8 support to textures and framebuffers. I could imagine that the texture part could share code with some part of gzdoom as it too wants 32 bit images.

There's one key change in it that definitely need discussion: wallscan. There's currently a buffer overrun present in master (http://forum.zdoom.org/viewtopic.php?f=2&t=50620) that was more severely affecting my branch as the out of bounds increased just enough to crash it more often. I rewrote the function as I couldn't make head and tails of its original implementation. So someone has to decide which function is best, and if its the old one then it needs to be fixed.

[Graf Zahl]

It's too much to review quickly, but there's a few things I immediately noticed:

1. Why is the sky drawing part of this? In your submission thread I already said that this has to wait for Randi's approval.

2. Was it really necessary to duplicate the true color texture generation code and then only do it incompletely? All the necessary worker code is already there in CopyTrueColorPixels, and even better, it is properly defined for all texture types, so you should use that. Currently the only textures that are done in true color are PNG and JPG, leaving out TGA, PCX, DDS and composites. CopyTrueColorPixels can already create a true color version for all of them so GetPixelsBGRA should use that and not be reimplemented for all texture types. If the current FBitmap class does not do what you need, you can define another one with a different pixel layout. I had to do that for GZDoom as well because it uses RGBA and not BGRA.

3. // Slopes are broken currently in master.
// Until R_DrawTiltedPlane is fixed we are just going to fill with a solid color.
That stuff is still in there, but the slope math has been fixed since then.

To sum it up: It still needs a bit of work.

[dpJudas]

1) Oops. Forgot about having merged that in. Will remove it again. Probably should close that other PR because, after seeing how gzdoom does its skies, it is clear to me that any changes to this part should be more fundamental. IMHO the code should be changed (for both pal and rgba) so that it uses specialized sky drawers that allow for the "fade to solid" effect and uses math that effectively renders a skydome.

2) Hmm yes, that's a better way of doing it. The only special thing about GetPixelsBgra is that it includes mipmaps (immediately following after the main image).

[Graf Zahl]

1) Oops. Forgot about having merged that in. Will remove it again. Probably should close that other PR because, after seeing how gzdoom does its skies, it is clear to me that any changes to this part should be more fundamental. IMHO the code should be changed (for both pal and rgba) so that it uses specialized sky drawers that allow for the "fade to solid" effect and uses math that effectively renders a skydome.

Agreed. But keep the old methods for the die-hard software rendering fans. But for looking up and down the method is just not good enough anymore. I had been asking about this several years ago but nothing came out of it.

One other interesting thing would be to have Q2-style skybox support in the software renderer to go along with the true color stuff, but that's not a pressing issue and certainly can wait.

2) Hmm yes, that's a better way of doing it. The only special thing about GetPixelsBgra is that it includes mipmaps (immediately following after the main image).

I also saw the premultiplied alpha, so it'll most likely require an FBitmap subclass, or a second pass over the data. The mipmaps shouldn't be a problem, you'll need the full image anyway to create them. Keep GetPixelsBgra and let it use CopyTrueColorPixels to do its job, I'd say.



I think if these 3 issues get addressed it should be ready to go.

[dpJudas]

I also saw the premultiplied alpha, so it'll most likely require an FBitmap subclass, or a second pass over the data. The mipmaps shouldn't be a problem, you'll need the full image anyway to create them. Keep GetPixelsBgra and let it use CopyTrueColorPixels to do its job, I'd say.

Yep, that sounds like the way to do it.

I'll do another post when I'm done with those changes. It might take a little while as the stuff I'm doing on gzdoom is more interesting at the moment.

[cortlong50]

i havent had a chance to try it, but i think the effort is very well done, very well put, and obviously very well thought out and looks reasonably implementable.

i love seeing people suggest something with an actual method of implementation.

it would be nice to get your software mode on in a real color system. i like it a lot.

[Graf Zahl]

I got one question. What's the point of premultiplied alpha? Does it really speed up the rendering process? The thing is, it causes one problem: If you put such a texture onto a one-sided wall, the alpha should be discarded and then the colors are all wrong.