PolymerNG - Xbox One and Windows 10
#1 Posted 18 April 2016 - 05:32 PM
Github(P4 rev 265) is at
https://github.com/j...PolymerNGPublic
This post has been edited by icecoldduke: 31 May 2016 - 06:59 PM
#2 Posted 19 April 2016 - 04:04 PM
icecoldduke, on 18 April 2016 - 05:32 PM, said:
Just an aside here, in BUILD there are no such things as "dynamic sectors". Unlike other engines any sector or wall point can be linked arbitrarily to another at any time, including being moved or deformed and placed directly overlapping another sector. In fact two non adjacent walls can be linked and the engine doesn't even blink, it just renders both sectors and a void between. Assuming you are in godmode you are able to cross the boundary into the void and reach the other sector.
It's possible to do this not only in CON but in Mapster. Nothing is ever truly static.
#5 Posted 19 April 2016 - 04:29 PM
Mblackwell, on 19 April 2016 - 04:04 PM, said:
It's possible to do this not only in CON but in Mapster. Nothing is ever truly static.
While every sector can move that doesn't mean every sector will move. If a sector doesn't move it will be faster to render from the static geo vertex buffer. The dynamic sectors(any sector that moves after the level loads) will use two different buffers(one for each SMP frame). There is no reason for both static and dynamic sectors to share the same buffers. This means a little more memory is wasted, but it will prevent pipeline stalls.
#6 Posted 19 April 2016 - 04:35 PM
Are you saying you'll build a list as things move?
#7 Posted 19 April 2016 - 04:59 PM
Mblackwell, on 19 April 2016 - 04:35 PM, said:
Are you saying you'll build a list as things move?
Yes. The fact is if you have every sector in the game moving at once, then this optimization won't help. I figure for most maps the majority of sectors won't move. Until a sector moves or deforms or whatever, it will continue to use the static geo buffers. Once the sectors moves it will, from then on out, use the dynamic sector geo buffers. This means you will see a performance hit the more dynamic sectors you have in your map. Polymer and Polymost don't have this optimization, so rendering sectors is just slower then it needs to be.
As content developers you have to ensure your map makes framerate.
This post has been edited by icecoldduke: 19 April 2016 - 05:07 PM
#8 Posted 19 April 2016 - 10:27 PM
Terminx/Hendricks(or someone else), so I'm at a loss on why the sprite picnum's are not getting updated, can you guys walk me through how sprite animations are done on the Duke side?
This post has been edited by icecoldduke: 19 April 2016 - 10:32 PM
#9 Posted 19 April 2016 - 11:02 PM
#10 Posted 20 April 2016 - 12:52 AM
icecoldduke, on 19 April 2016 - 04:59 PM, said:
Clearly you've never played any of my maps for the AMC TC
Seriously though it's good to hear you're making progress. I imagine it's not easy.
#11 Posted 20 April 2016 - 04:13 PM
Mblackwell, on 19 April 2016 - 11:02 PM, said:
EDIT: Found something.
This post has been edited by icecoldduke: 20 April 2016 - 04:21 PM
#12 Posted 22 April 2016 - 01:40 PM
This post has been edited by icecoldduke: 22 April 2016 - 01:46 PM
#14 Posted 22 April 2016 - 05:22 PM
Should note though that the hud is mis-scaled. Not sure why. Everything draws outside of screen boundaries and is stretched along the x axis.
#15 Posted 22 April 2016 - 07:37 PM
This post has been edited by icecoldduke: 22 April 2016 - 08:16 PM
#17 Posted 22 April 2016 - 09:10 PM
Spiker, on 22 April 2016 - 08:24 PM, said:
Yeah I hope I'm not over saturating things, I kinda like having a doc of my development of this project. Speaking of which I took a video with the sprite fix and I fixed the bug that caused the building in E1L2 to flicker and look weird. This is the video of the E1L2 building that falls down.
This post has been edited by icecoldduke: 22 April 2016 - 09:10 PM
#18 Posted 22 April 2016 - 09:27 PM
#19 Posted 22 April 2016 - 09:42 PM
Spiker, on 22 April 2016 - 09:27 PM, said:
This is where I was at on the 11th of this month.
That is the most the renderer could do at that point in time(and it was even bad at doing that). Took 11 days to go from that mess to:
There is more to do, but I want to take a second to really give credit to Plagman, Terminx, Helixhorned, and Hendricks. Without out there great work there would be no PolymerNG. You guys really can't understand how great it is to develop a port from a fantastic codebase.
This post has been edited by icecoldduke: 22 April 2016 - 09:59 PM
#21 Posted 22 April 2016 - 09:59 PM
Spiker, on 22 April 2016 - 09:52 PM, said:
Edited to include Helix . Also I committed code that will load all three expansions, I was able to get in and play all the expansions. I just need to add some kind of a frontend on startup for people to choose which expansion they want to use and that's done.
This post has been edited by icecoldduke: 22 April 2016 - 11:19 PM
#22 Posted 23 April 2016 - 10:44 AM
#23 Posted 23 April 2016 - 11:23 AM
TON, on 23 April 2016 - 10:44 AM, said:
Not part of the base game and isn't going to be
Also off topic.
#24 Posted 23 April 2016 - 04:30 PM
EDIT: Re-uploaded. I took out the initial monologue I did so if some this doesn't make sense initially thats why . When PolymerNG is complete IMO BloodCM is effectively Blood on the XB1.
REMOVED
This post has been edited by icecoldduke: 23 April 2016 - 06:43 PM
#25 Posted 23 April 2016 - 06:49 PM
This shows E1L1 in Duke Atomic is also fixed.
This post has been edited by icecoldduke: 23 April 2016 - 06:49 PM
#26 Posted 23 April 2016 - 09:07 PM
This post has been edited by icecoldduke: 23 April 2016 - 09:14 PM
#27 Posted 23 April 2016 - 09:12 PM
#28 Posted 23 April 2016 - 09:27 PM
Hendricks266, on 23 April 2016 - 09:12 PM, said:
That is correct I am using the same octagon code to draw skies as in Polymer.
To answer your question, I do have some ideas on how to get the "paper" sky to look just like it does in classic. It should be easy enough if its implemented as a screenspace effect, rendered before everything else without depth enabled. I plan on doing all of that in a later milestone, this milestone is just getting everything up and running.
Something else to know, another optimization I did was with Sprites. In Polymer Plagman was doing some parts of the final transform matrix on the CPU and uploading that data to the GPU. For sprites we don't do that. The sprite vertex buffer is 8 vertexes, 4 vertexes for horizontal sprites, and 4 vertexes for vertical sprites. Then the matrix transforms, transform those quads into the sprites you see on screen. It was a easy enough optimization, just took Plagman's code one step futher.
I'm mentioning that because everytime I look at the sky code I know we can just send down a 2 ints and a float, and not have to upload all the garbage every frame.
For those interested this is the sky code as seen in the above images. Basically the same code as in polymer just modified to work in the PolymerNG renderer.
// Renderer_Draw_ClassicSky.cpp // #include "Renderer.h" #include "build3d.h" #include "../PolymerNG_local.h" #include <mutex> const int numClassicSkyPlanes = 8; /* ===================== RendererDrawPassDrawClassicSky::Init ===================== */ void RendererDrawPassDrawClassicSky::Init() { float halfsqrt2 = 0.70710678f; artskydata[0] = -1.0f; artskydata[1] = 0.0f; // 0 artskydata[2] = -halfsqrt2; artskydata[3] = halfsqrt2; // 1 artskydata[4] = 0.0f; artskydata[5] = 1.0f; // 2 artskydata[6] = halfsqrt2; artskydata[7] = halfsqrt2; // 3 artskydata[8] = 1.0f; artskydata[9] = 0.0f; // 4 artskydata[10] = halfsqrt2; artskydata[11] = -halfsqrt2; // 5 artskydata[12] = 0.0f; artskydata[13] = -1.0f; // 6 artskydata[14] = -halfsqrt2; artskydata[15] = -halfsqrt2; // 7 classicSkyRHIMesh = rhi.AllocateRHIMesh(sizeof(Build3DVertex), numClassicSkyPlanes * 4, NULL, true); classicSkyConstantBuffer = rhi.AllocateRHIConstantBuffer(sizeof(VS_DRAWCLASSICSKY_BUFFER), &drawClassicSkyBuffer); } /* ===================== RendererDrawPassDrawClassicSky::Draw ===================== */ void RendererDrawPassDrawClassicSky::Draw(const BuildRenderCommand &command) { Build3DVertex classicSkyVertexes[8 * 4]; float height = 2.45f / 2.0f; // TODO: We don't need to update a vertex buffer here. Make me go away in the next milestone! for (int i = 0; i < numClassicSkyPlanes; i++) { int32_t p1 = i; int32_t p2 = (i + 1) & (numClassicSkyPlanes - 1); classicSkyVertexes[(i * 4) + 1].SetVertex(Build3DVector4(artskydata[(p1 * 2) + 1], height, artskydata[p1 * 2], 1.0f), Build3DVector4(0.0f, 0.0f, 0.0f, 0.0f)); classicSkyVertexes[(i * 4) + 0].SetVertex(Build3DVector4(artskydata[(p1 * 2) + 1], -height, artskydata[p1 * 2], 1.0f), Build3DVector4(0.0f, 1.0f, 0.0f, 0.0f)); classicSkyVertexes[(i * 4) + 2].SetVertex(Build3DVector4(artskydata[(p2 * 2) + 1], -height, artskydata[p2 * 2], 1.0f), Build3DVector4(1.0f, 1.0f, 0.0f, 0.0f)); classicSkyVertexes[(i * 4) + 3].SetVertex(Build3DVector4(artskydata[(p2 * 2) + 1], height, artskydata[p2 * 2], 1.0f), Build3DVector4(1.0f, 0.0f, 0.0f, 0.0f)); } rhi.UpdateRHIMesh(classicSkyRHIMesh, 0, sizeof(Build3DVertex), numClassicSkyPlanes * 4, classicSkyVertexes); BuildImage *image = static_cast<BuildImage *>(command.taskRenderWorld.skyImageHandle); drawClassicSkyBuffer.mWorldViewProj = command.taskRenderWorld.skyProjMatrix; //drawSpriteBuffer.modelMatrix = sprite->modelMatrix; classicSkyConstantBuffer->UpdateBuffer(&drawClassicSkyBuffer, sizeof(VS_DRAWCLASSICSKY_BUFFER), 0); rhi.SetConstantBuffer(0, classicSkyConstantBuffer); rhi.SetImageForContext(0, image->GetRHITexture()); rhi.SetImageForContext(1, polymerNG.GetPaletteImage()->GetRHITexture()); rhi.DrawUnoptimizedQuad(renderer.albedoSimpleProgram->GetRHIShader(), classicSkyRHIMesh, 0, numClassicSkyPlanes * 4); }
This post has been edited by icecoldduke: 23 April 2016 - 09:38 PM
#29 Posted 23 April 2016 - 11:40 PM
This post has been edited by icecoldduke: 23 April 2016 - 11:42 PM
#30 Posted 23 April 2016 - 11:54 PM
icecoldduke, on 23 April 2016 - 11:40 PM, said:
This post has been edited by Spiker: 23 April 2016 - 11:54 PM