Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Graf Zahl

Important GLNodes V3 question

Recommended Posts

The new V3 GL nodes format extends the amount of vertices and subsectors to 32 Bit. So far, so good.

What confuses me is that the 'children' field in the nodes structure has not been extended to 32 Bit. Since this field links to both nodes and subsectors it can still only reference 32767 subsectors. Am I missing something here or is the format still limited? (I don't know whether this limit can be exceeded but I wouldn't rule it out completely.)

Share this post


Link to post

The new V3 nodes doesn't extend the limit on subsectors or nodes, only the limit on segs and vertices from seg splits. Segs are the first thing that overflows (e.g. DeusVult MAP05, 10sector MAP26).

Overflowing the subsector/node limits is possible (DeusVult is getting close with 20000 subsectors). But I doubt that removing this limit is worthwhile (after all the original wad limits like 65535 sidedefs will always be there).

Share this post


Link to post
Ajapted said:

The new V3 nodes doesn't extend the limit on subsectors or nodes, only the limit on segs and vertices from seg splits. Segs are the first thing that overflows (e.g. DeusVult MAP05, 10sector MAP26).

Overflowing the subsector/node limits is possible (DeusVult is getting close with 20000 subsectors). But I doubt that removing this limit is worthwhile (after all the original wad limits like 65535 sidedefs will always be there).



I was asking because the biggest map I tested so far (RTC-3057 Map02) produced >28000 subsectors/nodes and there is still significant room for more without overflowing some hard limit (the map contains 53310 sidedefs.)

(Of course you could resort to ZDoom's compressed node format if it still overflows...)

Share this post


Link to post
Ajapted said:

The new V3 nodes doesn't extend the limit on subsectors or nodes, only the limit on segs and vertices from seg splits. Segs are the first thing that overflows (e.g. DeusVult MAP05, 10sector MAP26).

Overflowing the subsector/node limits is possible (DeusVult is getting close with 20000 subsectors). But I doubt that removing this limit is worthwhile (after all the original wad limits like 65535 sidedefs will always be there).

I was trying to get a hold of you a long time ago with no success so we could collaborate on a new spec that addresses the questions that would come up with V3. The main issue is that the regular nodes were not expanded, just the GL ones. Sidedefs can be packed, so technically you can have over 64k sidedefs and thus you can exceed 32k nodes/segs.

Other obvious details handle the question posed here. If you are interested in V4 nodes, please contact me and I'll send you the specs. This will consolidate the changes and present a unified solution for all the ports. The changes are relatively simple to implement (as is V3) for both GL aware ports and regular ports.

There are some other points that also should be discussed such as the "magic" number so there is no confusion as to the format present.

This is a good time to address the changes since no port that I know of supports V3, although V4 nodes are supported by RISEN3D.

FYI, I asked all the port authors which sort of format they preferred: the ZDOOM zip stuff or an easy to decode way as you and I have done and all preferred the simpler method.

Share this post


Link to post
deep said:

If you are interested in V4 nodes, please contact me and I'll send you the specs. This will consolidate the changes and present a unified solution for all the ports. The changes are relatively simple to implement (as is V3) for both GL aware ports and regular ports.

Please email the V4 specs to: ajapted@users.sourceforge.net. I'm happy to discuss it either here or via email.


FYI, I asked all the port authors which sort of format they preferred: the ZDOOM zip stuff or an easy to decode way as you and I have done and all preferred the simpler method.

Yes, I noticed the ZDoom compressed format and thought the compression was overkill (and didn't like the idea of yet another library to link with).

Share this post


Link to post
Ajapted said:

Yes, I noticed the ZDoom compressed format and thought the compression was overkill (and didn't like the idea of yet another library to link with).



The compression sure is overkill - if you think about the distribution size.
But GL nodes can become quite large so if you have a lot of large maps on your HD it can make a significant difference.

But since they are only of use to ZDoomGL and ZDoomGL is able to handle 'normal' GL nodes as well there really isn't any need for support here. The only problem with traditional GL nodes is that they limit the map name to 5 characters.

Still, I'd support compressed nodes if I could.

Share this post


Link to post
Ajapted said:

Please email the V4 specs to: ajapted@users.sourceforge.net. I'm happy to discuss it either here or via email.

Yes, I noticed the ZDoom compressed format and thought the compression was overkill (and didn't like the idea of yet another library to link with).

Ok will do. I'm taking care of my father-in-law and am at his house at ATM.

I think the txt file of the specs I was working on is pretty complete - for you should be no problem to figure out even if I did overlook something:)

In a world of 200gig drives at around $145, that's a heck of a lot of PWADS (even large ones), hence that's why the zipped stuff didn't make much sense to the rest of us, esp since the expanded formats are so easy for ports to incorporate.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×