Extended nodes

[randomlag]

Since the topic was "locked" due to typical unease in discussing alternate ideas, let me say that the extended nodes that I suggested have been discussed in detail with both other port authors and Andrew Apted (author of GLBSP). The alternatives were given. Everyone had a choice since I wasn't about to do something that nobody wanted

After a bit of surprise that I made an extended GL spec (since V3 was a bit short of what was required for today's level sizes), he agreed to adopt my spec. The only thing that got added back in for GL nodes were the partner segs. I removed those in V4 since nobody was using them, however, ZDOOMGL just started using them, so V5 is basically V4 + partner segs.

In addition, we added some more optional info to the specs that allows a port to check that the nodes for a level match the level. IOW, that a user didn't change the level and forgot to build nodes. This is a fairly common problem - although my main idea was that selective node builds could be done on PWADs with multiple levels (vs all the levels).

So although we argued back and forth, nobody got pissed off nor resorted to personal attacks. We thought about what the other person was saying and combined our ideas and got something better. That's how it should be done

[Graf Zahl]

Yawn!

[randomlag]

Yawn!

What no rant - I'm surprised you could hold it in

FYI this format can handle > 64k vertices which is actually possible with sidedef compression + a node build. Sidedef compression is now instanteneous making this a real and practical possibility.

[PS: I'm still amazed that you can't see how your personal comments apply mainly to yourself. Don't be so defensive. It's not a personal attack when someone gives an alternate idea. That goes for the update check stuff too. Basically a good idea and not very hard to to.]

[Nmn]

Yawn --> ! <--

Is it me or do Germans scream a lot?

[Bio Hazard]

I like it when he (graf) writes "NO!" in big red caps. Just like Mighty Duck X-Treme used to do.

It reminds me of the good-ol' days

[Chilvence]

There seems to be something I've missed... what exactly is the spec?

[timmie]

Andrew hasn't put it up on the glBSP site yet.

[Risen]

Why must you continue?

[randomlag]

There seems to be something I've missed... what exactly is the spec?

Well it's this http://www.sbsoftware.com/files/DeePBSPV4specs.txt V5 is these specs with the partners added back in. That was done and implemented back in August 2004. RISEN3D and R3Dedit support this format now. Pretty easy for GL ports to adopt since it's basically a brainless cut/paste of the GL2 code

The other details are in the GL_LEVEL header (text data identifying whatever a node builder wants to add, including date/time and stuff like that). GL_LEVEL is a generic header that is used when a level name does not fit "GL_MAPxx" or GL_ExMx" naming conventions [iow it replaces that name]. The level name will be stored in this header. This is required for GL ports so they can find the correct matching GL nodes if they are stored in GWA files. Inside a PWAD when stored with the level, it's not really required.

The control stuff will be added to the LINEDEFS lump. Need to get back to Andrew since I've since realized that there's a bit simpler way to do this (going back to my original date idea).

[Chilvence]

Aha, clarity!

Well anyway, if this is that easy to add then I don't see why it shouldn't be. What's the fuss about?

[randomlag]

Aha, clarity!

Well anyway, if this is that easy to add then I don't see why it shouldn't be. What's the fuss about?

Exactly - should be no fuss at all. It's very easy to add to any port. That was the main focus - establishing a standardized format that everyone would adopt. Very easy to code and test. Took me about 10 minutes in RISEN3D

The raw node size is larger vs a zipped format, but zipped they are more or less exactly the same size (zipping zipped stuff goes in reverse in terms of file size). IOW file download size is really the only relevant area for today's disk drives.

[Chilvence]

In all fairness, it was not your answer in particular that I was seeking

[Risen]

The raw node size is larger vs a zipped format, but zipped they are more or less exactly the same size (zipping zipped stuff goes in reverse in terms of file size). IOW file download size is really the only relevant area for today's disk drives.

That doesn't sound like a very good argument. Zipping the whole WAD is still necessary - but now instead of compressing the nodes that were inside it, that area will grow in size? You're not making your download size any smaller. You're saying that the size-on-disk is the same but the transfer size will be larger.

[Enjay]

I read that to say that when zipped they are much the same size as the previous format, but unzipped they are larger. So, download size - which is important - in basically unaffected but on disk size - which is not important - is bigger. Yes?

36

[Graf Zahl]

Exactly. But ZDoom's compressed nodes are still smaller because they store less data (for example, they store only one vertex for GL segs because a subsector has to be closed with GL nodes and the segs are in order so you can trivially get the second vertex without storing it in the file.)


But saying that HD space doesn't matter probably means that one hasn't yet managed to completely fill a 200 GB HD.

Anyway, if I built GL nodes for all the levels I have decided to keep in my collection the size difference on HD is ca. 1GB between ZDoom's compressed GL nodes and the uncompressed ones (V2 or V3 depending on the size of the level.)