[Closed] Truecolor software rendering

Moderators: Developers, ZDoom.org Team

Re: Truecolor software rendering

Postby dpJudas » Fri Jun 10, 2016 10:29 am

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.
dpJudas
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Edward-san » Fri Jun 10, 2016 6:06 pm

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

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).
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: Truecolor software rendering

Postby dpJudas » Fri Jun 10, 2016 7:42 pm

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

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.
dpJudas
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Graf Zahl » Sat Jun 11, 2016 2:57 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Truecolor software rendering

Postby dpJudas » Fri Jun 17, 2016 1:40 am

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. :)
dpJudas
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Graf Zahl » Fri Jun 17, 2016 2:59 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Truecolor software rendering

Postby rombust » Mon Jun 27, 2016 6:37 am

I just wanted to mention that this fork is really impressive. Great work :)
rombust
 
Joined: 27 Jun 2016

Re: Truecolor software rendering

Postby Graf Zahl » Thu Jul 28, 2016 1:52 am

Graf Zahl wrote: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?
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Truecolor software rendering

Postby dpJudas » Thu Jul 28, 2016 4:13 am

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.
dpJudas
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Graf Zahl » Thu Jul 28, 2016 4:48 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Truecolor software rendering

Postby dpJudas » Thu Jul 28, 2016 5:16 am

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).
dpJudas
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Graf Zahl » Thu Jul 28, 2016 5:24 am

dpJudas wrote: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.

dpJudas wrote: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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Truecolor software rendering

Postby dpJudas » Thu Jul 28, 2016 5:49 am

Graf Zahl wrote: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. :D
dpJudas
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby cortlong50 » Fri Jul 29, 2016 5:32 pm

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.
User avatar
cortlong50
im not the guy from that south park episode with the wrist brace
 
Joined: 24 Jun 2013
Location: bill murray. the city.

Re: Truecolor software rendering

Postby Graf Zahl » Sun Aug 07, 2016 2:39 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest