Extended nodes

Moderator: GZDoom Developers

User avatar
randomlag
Posts: 405
Joined: Thu Jul 17, 2003 10:10 pm

Extended nodes

Post by 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 :wink:
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48043
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Yawn!
User avatar
randomlag
Posts: 405
Joined: Thu Jul 17, 2003 10:10 pm

Post by randomlag »

Graf Zahl wrote:Yawn!
What no rant - I'm surprised you could hold it in :lol:

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.]
User avatar
Nmn
Posts: 4608
Joined: Fri Apr 16, 2004 1:41 pm

Post by Nmn »

Graf Zahl wrote:Yawn --> ! <--
Is it me or do Germans scream a lot? ;)
User avatar
Bio Hazard
Posts: 4019
Joined: Fri Aug 15, 2003 8:15 pm
Location: ferret ~/C/ZDL $

Post by 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 :)
Last edited by Bio Hazard on Sun Apr 10, 2005 6:14 pm, edited 1 time in total.
User avatar
Chilvence
Posts: 1647
Joined: Mon Aug 11, 2003 6:36 pm

Post by Chilvence »

There seems to be something I've missed... what exactly is the spec?
User avatar
timmie
Posts: 199
Joined: Tue Jul 15, 2003 3:44 pm
Location: Vancouver, BC

Post by timmie »

Andrew hasn't put it up on the glBSP site yet.
User avatar
Risen
Posts: 5263
Joined: Thu Jan 08, 2004 1:02 pm
Location: N44°30' W073°05'

Post by Risen »

Why must you continue?
User avatar
randomlag
Posts: 405
Joined: Thu Jul 17, 2003 10:10 pm

Post by randomlag »

Chilvence wrote: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).
User avatar
Chilvence
Posts: 1647
Joined: Mon Aug 11, 2003 6:36 pm

Post by 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?
User avatar
randomlag
Posts: 405
Joined: Thu Jul 17, 2003 10:10 pm

Post by randomlag »

Chilvence wrote: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 :idea:

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.
User avatar
Chilvence
Posts: 1647
Joined: Mon Aug 11, 2003 6:36 pm

Post by Chilvence »

In all fairness, it was not your answer in particular that I was seeking ;)
User avatar
Risen
Posts: 5263
Joined: Thu Jan 08, 2004 1:02 pm
Location: N44°30' W073°05'

Post by Risen »

randomlag wrote: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.
User avatar
Enjay
 
 
Posts: 26418
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Post by 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
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48043
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by 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.)

Return to “Closed Feature Suggestions”