[Why?] Extended nodes

Moderator: GZDoom Developers

Extended nodes

Postby randomlag » Sat Apr 09, 2005 10:28 am

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
randomlag
 
Joined: 17 Jul 2003

Postby Graf Zahl » Sat Apr 09, 2005 10:41 am

Yawn!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby randomlag » Sat Apr 09, 2005 10:43 am

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
randomlag
 
Joined: 17 Jul 2003

Postby Nmn » Sat Apr 09, 2005 3:12 pm

Graf Zahl wrote:Yawn --> ! <--

Is it me or do Germans scream a lot? ;)
User avatar
Nmn
 
Joined: 16 Apr 2004

Postby Bio Hazard » Sat Apr 09, 2005 4:31 pm

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
Bio Hazard
Lord of the Lord of Nitpicking.
 
Joined: 15 Aug 2003
Location: ferret ~/C/ZDL $

Postby Chilvence » Sun Apr 10, 2005 5:57 pm

There seems to be something I've missed... what exactly is the spec?
User avatar
Chilvence
I had been waiting for Doomscript....
 
Joined: 11 Aug 2003

Postby timmie » Mon Apr 11, 2005 10:26 am

Andrew hasn't put it up on the glBSP site yet.
User avatar
timmie
OH YEAH!
 
Joined: 15 Jul 2003
Location: Vancouver, BC

Postby Risen » Mon Apr 11, 2005 10:37 am

Why must you continue?
User avatar
Risen
 
Joined: 08 Jan 2004
Location: N44°30' W073°05'

Postby randomlag » Mon Apr 11, 2005 3:58 pm

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
randomlag
 
Joined: 17 Jul 2003

Postby Chilvence » Mon Apr 11, 2005 9:19 pm

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
Chilvence
I had been waiting for Doomscript....
 
Joined: 11 Aug 2003

Postby randomlag » Mon Apr 11, 2005 10:42 pm

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
randomlag
 
Joined: 17 Jul 2003

Postby Chilvence » Mon Apr 11, 2005 11:02 pm

In all fairness, it was not your answer in particular that I was seeking ;)
User avatar
Chilvence
I had been waiting for Doomscript....
 
Joined: 11 Aug 2003

Postby Risen » Tue Apr 12, 2005 10:35 am

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
Risen
 
Joined: 08 Jan 2004
Location: N44°30' W073°05'

Postby Enjay » Tue Apr 12, 2005 10:45 am

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
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby Graf Zahl » Tue Apr 12, 2005 12:08 pm

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.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests