[icecoldduke]

TON, on 05 April 2016 - 05:02 AM, said:

Icecoldduke are you using 32bit eduke32 or 64bit ?

64-bit.

[TON]

icecoldduke, on 05 April 2016 - 12:07 PM, said:

64-bit.

Ok, because 32-bit build is 30-35 fps more slow than 64-bit

[Hendricks266]

With proper optimization, there should not be as much of a gap between 32-bit and 64-bit builds.

[MusicallyInspired]

TON, on 05 April 2016 - 12:50 PM, said:

Ok, because 32-bit build is 30-35 fps more slow than 64-bit

Only on certain systems.

[icecoldduke]

TON, on 05 April 2016 - 12:50 PM, said:

Ok, because 32-bit build is 30-35 fps more slow than 64-bit

That shouldn't be the case. Regardless I have no plans on supporting 32-bit. I hope everyone on here can appreciate I don't have time to support a wide range of hardware. That being said I don't plan on doing anything that would case 32-bit builds to break. I don't plan on writing any assembly. On the XB1 we only have 1GB of ram to play with. There should be no reasons why the 32-bit build won't work, I just won't support it.

That means I have to implement texture streaming(virtual texturing) so we can meet ram requirements. More to come on this at a later time. I have a lot of work ahead and I hope people can appreciate why I won't be supporting things like 32-bit builds.

[Spiker]

I find it weird and funny that some people would like to play games where requirements would never change but they would want advanced features added. New games developed by plenty of people don't even bother. Especially when you can already play this game as classic or improved version as you like. In my opinion this should be as NG as possible. No prisoners taken.

[TON]

Are some of these problems solved in PolymerNG?

Plagman, on 31 May 2011 - 09:39 PM, said:

Fortunately what needs to be done isn't a mystery at all. The problem isn't that we need to brainstorm for optimization ideas, it's that I have to break everything and put it together in a different fashion. It's been known from the start; I've done it like that at first because it's always easier to get something that works right than something that works right and well. Too bad that only applies to the short term.

There are several different problems; one aspect a map is made of a lot of planes that are all drawn separately from front to back; materials are switched between each plane, and each time a red wall is crossed a "portal" is drawn to determine if the sector that follows needs to be queued for rendering or not. This constant material switching and drawing only one plane at a time isn't really efficient. The former causes a lot of state validation and thrashing, while the latter doesn't utilize the GPU in an efficient fashion. It's constantly submitting tiny pieces of work and reaping it, causing a lot of idle time waiting for the results. This also causes big maps with lots of red walls to be insanely complex to draw.

Another problem is that the multi-pass drawing approach uses a lot of fillrate as soon as a fairly big plane gets a few too many lights on it.

Things that needs to be done:
- Move the diffuse modulation from the material to the vertex attribute. That would cause the amount of different materials in a map to be all the different tiles used, instead of the more complex tile X shade.
- Move plane vertex attributes from several unique vertex buffers to a single storage or several depending on the staticness of the data.
- With a more reasonable material count and stuff sharing buffers, we can start batching planes together. To leverage that, throw planes into material buckets instead of rendering them right away. When we're done building index buffers for the buckets, submit them in one big go (one per material).
- Change the HSR walking to do a first pass before doing the actual shaded drawing. This means that in the event that occlusion queries have to be reaped, we can get the result a lot faster since we're pushing a lot less pixels using a passthrough fragment program.
- For rendering the shadow maps, we only need materials for sprite silhouettes. The rest can be batched in a single draw call after building the right index buffer, same as above. This will be a lot faster.

(Even) bigger projects:
- Defer the lighting model to shade from a fat buffer instead of inline. This eliminates two very expensive steps, light culling and multi-pass drawing.
- Instance models together.

[Micky C]

Polymer NG is an entirely different renderer written from scratch, so it never had those problems to begin with. It's probably not even advanced enough to the point yet where those can even be problems.

Having said that I hope that icecoldduke has learnt a lesson from polymer in that it is best to get it right the first time otherwise you risk creating a lot of tedious work in the future that will likely destroy your motivation.

[Hendricks266]

Micky C, on 08 April 2016 - 02:37 PM, said:

Having said that I hope that icecoldduke has learnt a lesson from polymer in that it is best to get it right the first time otherwise you risk creating a lot of tedious work in the future that will likely destroy your motivation.

It's about free time (from day job), not motivation.

[Mark]

Darn, I wish I would have seen that post from Plagman before. I could have had things optimized long ago with that info.

Attached thumbnail(s)

• 

[neoacix]

Hendricks266, on 08 April 2016 - 03:52 PM, said:

It's about free time (from day job), not motivation.

*cough* crowd funding *cough*

[Hendricks266]

neoacix, on 08 April 2016 - 05:03 PM, said:

*cough* crowd funding *cough*

That's not how salaried positions work.

[icecoldduke]

Micky C, on 08 April 2016 - 02:37 PM, said:

Having said that I hope that icecoldduke has learnt a lesson from polymer in that it is best to get it right the first time otherwise you risk creating a lot of tedious work in the future that will likely destroy your motivation.

I don't understand what lesson I would have learned, I didn't write Polymer, Plagman did. All I did was try and fix some of the performance issues with the renderer. To point though I design systems in such a way that I generally don't incur any code debt. Plagman did a great job on Polymer, he set out to accomplish a goal and he did just that. I'm leveraging parts of his work in the new renderer, specifically a lot of the build 3d conversion math logic. Hendricks was spot on, motivation isn't the issue. I need more hours in the day.

[icecoldduke]

Here is a progress update. Input and Audio have to be redone, I can get to the main menu.

[t800]

Propably silly thing to ask, but will PolymerNG support voxels?

[icecoldduke]

t800, on 10 April 2016 - 07:14 AM, said:

Propably silly thing to ask, but will PolymerNG support voxels?

Yea I'll support voxels. I don't know when I will get them in though. My first goal is to get everything back to a playable state. I want to be able to play through all of atomic edition without crashes on the XB1 without mods. At that point I will release a build for people to test out, including opening up the P4 server for everyone to get the source code. I want to make sure the core renderer/game works before adding all the fancy effects. So I know going forward we don't have any code debt.

After that I want to evaluate how much memory the HRP takes up. If we OOM with the HRP, the next goal is getting virtual texturing in there. That will prevent us for OOMing, then I will release another test for testing the HRP. Then at that point we will proceed with all the fancy effects.

[icecoldduke]

Fixed the game enough so I can get into a map. I've tried a few maps they all load. I had to reimplement huge parts of the albedo pass, but as you can see we can get in. Culling is disabled, and there is no occlusion testing so its rendering every sector right now. Sprites are also not rendering yet.

[icecoldduke]

Another progress update. The levels render pretty well now. This video shows E1L6 and E3L1. Sprites still don't render and dynamic sectors don't render properly yet. Input and Sound also don't work yet.

[Micky C]

Wow I had no idea that the ceiling there in E3L1 was lowered like that. Looks like someone hit the page down key by accident and didn't fix it.

What was that you said about the framerate?

[Spiker]

"Pretty awesome" but I guess that was the "easy part"

[icecoldduke]

Micky C, on 12 April 2016 - 10:31 PM, said:

Wow I had no idea that the ceiling there in E3L1 was lowered like that. Looks like someone hit the page down key by accident and didn't fix it.

What was that you said about the framerate?

E1L6 runs at around 40fps, E3L1 is under 30fps. Speed will go up when I get culling working, and do some other optimizations. I only measured performance in debug builds, haven't tried release yet. We should get huge performance gains in release.

Spiker, on 13 April 2016 - 02:39 AM, said:

"Pretty awesome" but I guess that was the "easy part"

Actually get the map to render is the hard part, everything else is "easier" .

[Spiker]

icecoldduke, on 13 April 2016 - 03:36 AM, said:

Actually get the map to render is the hard part, everything else is "easier" .

Cool, in that case I'm expecting daily updates

[TON]

I hope that the sound doesn't reduce the framerate

[icecoldduke]

TON, on 13 April 2016 - 05:21 AM, said:

I hope that the sound doesn't reduce the framerate

I doubt sound will hurt performance. Speaking of audio, I might be ditching jfaudio. In UWP Microsoft doesn't support the mmsystem library, which means I loose the midi synthesizer. I might be going with fmod instead, which also means I don't have to write a XAudio2 implementation. To get around the GPL issue with FMod, I would write the replacement audio stack in the build module, since build isn't gpl'ed, this would make fmod license ok I believe.

Can anyone see any issues with this?

[HiPolyBash]

Is there any chance at all for surround sound support?

[icecoldduke]

HiPolyBash, on 13 April 2016 - 06:04 AM, said:

Is there any chance at all for surround sound support?

FMOD comes with surround sound support.

[Kristian Joensen]

So is the intention still to do a PC version with Vulkan support?

[icecoldduke]

Kristian Joensen, on 13 April 2016 - 06:18 AM, said:

So is the intention still to do a PC version with Vulkan support?

Not at this time. The PC version will be DX11 only for right now. Even though I'll be focusing on the XB1, most of my testing is done on the PC. As of now I will be supporting Windows(DX11) and the XB1. Linux support will only extend to pushing the data over to the XB1.

Recommended PC specs will match that of that of the console version: 1gb of ram with a video card that also has at least 1gb of ram(probably a bit more since the OS takes a decent chunk on the PC), probably a Geforce 600 series or equivalent

[MusicallyInspired]

Thank you for leaving out the DX12-exclusiveness. Even though it doesn't really matter now as I'm on Win10...

[icecoldduke]

MusicallyInspired, on 13 April 2016 - 12:33 PM, said:

Thank you for leaving out the DX12-exclusiveness. Even though it doesn't really matter now as I'm on Win10...

At first the PC version will require Windows 8/10(since I exclusively have UWP projects at the moment), but I will create Win32 projects for those on Vista or Windows 7.