[2D_Refactor] Softpoly ignores status bar displacement
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
[2D_Refactor] Softpoly ignores status bar displacement
When screenblocks <=11 the status bar is not calculated in the view plane.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [2D_Refactor] Softpoly ignores status bar displacement
This one's for dpJudas. Was this even working before? Since I tend to run the game without status bar it's something I never checked.
Re: [2D_Refactor] Softpoly ignores status bar displacement
Yeah it works fine in the master branch still.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [2D_Refactor] Softpoly ignores status bar displacement
Thanks to _mental_ for fixing the Linux/Mac backends.
So if this one gets fixed I'd like to prepare a first public beta with the new code, after fixing the broken wipes.
So if this one gets fixed I'd like to prepare a first public beta with the new code, after fixing the broken wipes.
Re: [2D_Refactor] Softpoly ignores status bar displacement
Fixed the displacement bug, but there's a second one that I'm a bit more puzzled about. The player sprite doesn't position itself correctly anymore.
Should the player sprite drawing be handled by the renderers at all? At the moment RenderPolyPlayerSprites is a copy paste of RenderPlayerSprites with some minor changes. But couldn't we just get rid of both and use the GL renderer's 2D drawing code?
Should the player sprite drawing be handled by the renderers at all? At the moment RenderPolyPlayerSprites is a copy paste of RenderPlayerSprites with some minor changes. But couldn't we just get rid of both and use the GL renderer's 2D drawing code?
Re: [2D_Refactor] Softpoly ignores status bar displacement
Pushed a fix for the player sprite bug.
I also removed the DFrameBuffer::GetCanvas function as it was always returning null now. This actually revealed a bug: the software renderer isn't using accelerated sprites at the moment.
I added a comment in the source code. If this is uncommented it adds the gun to AcceleratedSprites and then in RenderPlayerSprites::RenderRemaining it tries to draw it using the canvas. This fails for some reason - probably because DFrameBuffer::Draw2D() is never called.
I also removed the DFrameBuffer::GetCanvas function as it was always returning null now. This actually revealed a bug: the software renderer isn't using accelerated sprites at the moment.
I added a comment in the source code. If this is uncommented it adds the gun to AcceleratedSprites and then in RenderPlayerSprites::RenderRemaining it tries to draw it using the canvas. This fails for some reason - probably because DFrameBuffer::Draw2D() is never called.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [2D_Refactor] Softpoly ignores status bar displacement
I noticed that it wasn't using accelerated sprites. I'll have a look into the drawing code later. But I do not understand your Draw2D comment. That cannot be the cause, both the software rendered scene and the color blend are run through it and get drawn, and the weapon sprite lies right between those calls. If it doesn't work there must be some other problem.
Re: [2D_Refactor] Softpoly ignores status bar displacement
Hmm okay - I didn't take a closer look. The debugger did show it reach the line where it adds the texture in m2DDrawer, but I didn't examine if it was broken input.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [2D_Refactor] Softpoly ignores status bar displacement
The problem with the weapon was that it got an alpha of 0 in the light color. The old code didn't fall into that trap because it used another method to pass the colormap info to the drawer. Since all of that was quite redundant with existing features I removed it and used more generic fields to pass the info. But that activated the alpha in the light value. Working now.