[icecoldduke]

Spiker, on 09 May 2016 - 10:09 AM, said:

Unless you are very afraid of having your precious data stolen it's good to save your very important projects into cloud folder. But you already know that and probably use it now.

For this project everything I have is under source control on assembla(Perforce allows me to shelve work without commiting it, so every night I shelve my progress so my current work is stored on the server) and I have a public version on github. This project is properly backed up .

Kathy, on 09 May 2016 - 11:22 AM, said:

If you're very afraid of your stuff being stolen you can always encrypt it, but not backing up your work is downright stupid.

Nope I was just stupid. No excuse. No spin. I was just a fucking idiot .

[Kathy]

MusicallyInspired, on 09 May 2016 - 12:12 PM, said:

I keep everything permanently backed up on an external hard drive with two partitions now and I disconnect it when I'm doing hardware or OS maintenance.

If it's always connected to computer then some power surge could also fry you external hdd. Also, home fire, burglary/theft or something related.

Quote

I'm not letting anything get lost again. I'm not ever putting anything up on the cloud, though. That works for source code, sure, but not music source files.

Use encryption then or some off the site storage(another external hdd in friend's apartment). It depends on seriousness of losing data, but I assume losing music files/notation would be quite a pain. Keeping everything in one place could be a problem.

Sorry for offtopic.

[MusicallyInspired]

It's not just theft concern, it's bandwidth. Music source files can go gigabytes in size. So no cloud.

[TerminX]

MusicallyInspired, on 09 May 2016 - 02:03 PM, said:

It's not just theft concern, it's bandwidth. Music source files can go gigabytes in size. So no cloud.

Eh, you can get a TB of space on Google Drive for $10 a month. 100 GB for $1.99.

[MusicallyInspired]

I'm talking about using up my monthly allotted bandwidth with uploading huge files. If I go over I pay huge fees.

[icecoldduke]

So everyone is aware, I will be probably playing Doom most of the weekend(if its any good), so I'll resume PolymerNG work next week. If I find Doom boring I'll work on PolymerNG this weekend, but I'm hoping its going to be fun .

[icecoldduke]

So I wanted to give people a update. I'm still working on a culling system for PolymerNG. This system will use the GPU but it will NOT use occlusion queries. Right now my working idea is to render all planes to a render target that is 1/8th the screen resolution. Each vertex has a sectorid attached to it. During this pass it will output the sector ID. Then I read back the "vis render target". Then I have a job go in a read each pixel in that texture and then I know what sectors are visible. Right now this this is a 2 channel image. In practice this should work well when its complete. I hopefully have some time this weekend to work on it. In the mean time, I bought a projector and took a picture of a 6ft Shadow Warrior gameplay image it looks awsome.

Some things to note in this image; There is NO culling enabled at all, and were holding 30fps on the Xbox One. The second counter below is how many planes in the map, its red because its rendering everything at the moment.

[Spiker]

Sounds complicated

[Micky C]

It's like you're actually in Lo Wang's Dojo of Death

[Tea Monster]

Is it rendering everything correctly?

[icecoldduke]

Tea Monster, on 20 May 2016 - 09:46 AM, said:

Is it rendering everything correctly?

Yes. The issue is now getting the culling system working(making sure we are only drawing whats visible). One issue with drawing EVERYTHING to the screen, is you start to overload the Render Output Processor units on the GPU. This is especially true if you render everything without frustum or hi-z testing . The idea is I want to maximize GPU usage. I want all of the wavefronts on the GPU to be chewing on work.

For each vertex:
Position
Texcoord
Tangent
Normal
SectorID.

It might seem odd to put the SectorID for each vertex, but the idea is I can then submit one call to draw the entire world during the vis pass. I don't have to reset the constant buffer for each sector so this makes the GPU able to parralize work VERY efficiently. Since the vis render target is 1/8th the device render target, the ROP units have 1/8th the work to do. Then when I read back the double buffered vis texture, a vis job just goes over each pixel and from there I know each sector that's currently visible.

[Plagman]

Are you sure that'll handle Tier Drops-style interpenetration? Besides aliasing problems because of the lower resolution, it seems like it would not; the red secret room in E1L1 is also a good example, since a chunk of the arcade room sticks within it.

[icecoldduke]

Plagman, on 20 May 2016 - 03:21 PM, said:

Are you sure that'll handle Tier Drops-style interpenetration? Besides aliasing problems because of the lower resolution, it seems like it would not; the red secret room in E1L1 is also a good example, since a chunk of the arcade room sticks within it.

I just got it working. One of the issues I've seen so far is if you have a crate and the top part of that sector is not visible, sprites in that sector won't draw, because the engine will only draw sprites in visible sectors(e.g. The crate you jump on to get to the ledge with the rocket launcher in E1L1). It seems like there should be a way to solve this; is that the type of thing that you are referring to? As far as aliasing goes, I haven't seen any issues I can attribute to aliasing in the vis buffer. A lot more testing is needed though, I can imagine issues with smaller sectors in view. Can you forsee anything else? Sorry that this is a quick response I'm about to head out.

REMOVED see a couple posts down.

[Spiker]

Not refering to this particular case but I've read many examples of how some major discoveries occured. Often the response to "how did you do that?" was "they forgot to tell me that it was impossible".

[icecoldduke]

I like this project because I can try things and not worry if it fails horribly. I might try doing occulusion queries with the smaller render target or copying the depth buffer back to the cpu and doing software occlusion queries agasint the hardware depth buffer I copied up.

[Danukem]

Plagman, on 20 May 2016 - 03:21 PM, said:

Are you sure that'll handle Tier Drops-style interpenetration?

icecoldduke, on 21 May 2016 - 10:32 AM, said:

I just got it working. One of the issues I've seen so far is if you have a crate and the top part of that sector is not visible, sprites in that sector won't draw, because the engine will only draw sprites in visible sectors(e.g. The crate you jump on to get to the ledge with the rocket launcher in E1L1). It seems like there should be a way to solve this; is that the type of thing that you are referring to?

I thought Plagman was referring to sector-over-sector. Tier Drops is E3L10.MAP

[Kyanos]

Yes, that's exactly what he was referencing, when two sectors are in the same space, but different rooms so you can never see one when in the other.

E1L1 arcade + secret room, it is sector over sector (SOS) with the floor of the secret red room being lower than the ceiling of the arcade.

[Robman]

They were talking about Shadow Warrior a few pages back - Make note that the HRP looks like shit, most of it. The grass and skies are pretty cool.

It was interesting to see the ST1 sprites get created in the video when the monsters were walking around. Gives you a hint of how the game was coded/created.

[icecoldduke]

SOS is a good point, I'll have to come up with a way to do that properly :/. Here is a video of the occlusion system in its current state on the XB1.

[Mark]

Robman, on 21 May 2016 - 11:52 AM, said:

They were talking about Shadow Warrior a few pages back - Make note that the HRP looks like shit, most of it. The grass and skies are pretty cool.

Sniff...Sniff... You hurt my feelings. Over 100 of those SW HRP textures were mine.

Keep up the good work ICD.

[Robman]

Mark., on 21 May 2016 - 02:06 PM, said:

Sniff...Sniff... You hurt my feelings. Over 100 of those SW HRP textures were mine.

Sorry Mark
The skies and grass get a thumbs up though! Not all of them are bad, don't get me wrong.
It has some elements to it that throw the greatness off, a few of the wood textures stand out and many of the enemy models.

[icecoldduke]

So I made some more fixes to the occlusion engine. In E1L1 we at 2-5ms through out the entire level, basically greater then 100fps. I made a video to this off, as well as the sector over sector issues that Plagman warned me about .



EDIT:
TerminX question about the wallvisible function. Does this function perform some kind of backface culling? I'm wondering how it makes certain mask walls not appear.

[Spiker]

4:58 of that video is a blast!

[Danukem]

I noticed in that video that enemy angles are displaying incorrectly. At times when the sprites should be displaying the 45 degrees away angle, they are displaying the 90 degrees away angle. It was true for both lizard troopers and pigcops.

[icecoldduke]

Trooper Dan, on 22 May 2016 - 01:36 AM, said:

I noticed in that video that enemy angles are displaying incorrectly. At times when the sprites should be displaying the 45 degrees away angle, they are displaying the 90 degrees away angle. It was true for both lizard troopers and pigcops.

Thanks for reminding me; There are cases were I need to flip the sprite textures, this is what needs to be done to fix the fail cases.

[icecoldduke]

TerminX or Hendricks how hard would it be to add spotlight support to mapster? Also in the original implementation of Polymer, were all lights forced to have shadows?

[Mark]

Its already there. However, stuff like flames and switches do not light up in Mapster.

[icecoldduke]

Fixed a couple bugs with the texture payloads files, so PolymerNG can now load Duke HRP textures. All of the Duke HRP textures reside in game_textures.payloads, which is only 298mb(DXT5/zlib compressed).

[Hendricks266]

The wood panels in the first shot need the xscale def token to be implemented.

The beauty of a lexed text format is extensibility.

[icecoldduke]

Hendricks266, on 23 May 2016 - 07:22 PM, said:

The wood panels in the first shot need the xscale def token to be implemented.

The beauty of a lexed text format is extensibility.

Text formats imo are awful. They effect load times in production and development. Since the def parsing isn't effecting load times that much(1019ms aka 1 second on startup), I think its ok to leave as is. In general though its always best to have memory ready formats. String compares eat up cycles fast. Ideally you have have a proper toolset for content guys to make content with. While artists are waiting for your text parser to parse all that data, they aren't doing work.

Is there any reason I can't apply all of those mod values at load time? It seems like I could implement xscale support during the geo generation pass. I think Polymer implemented those as shader inputs, but I can't see a good reason to do that off hand. Can these mod values change at runtime?