[2D_Refactor] Softpoly ignores status bar displacement

[Rachael]

When screenblocks <=11 the status bar is not calculated in the view plane.

[Graf Zahl]

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.

[Rachael]

Yeah it works fine in the master branch still.

[Graf Zahl]

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.

[dpJudas]

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?

[dpJudas]

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.

[Graf Zahl]

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.

[dpJudas]

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]

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.