ZDoom

Version 5 of the GL-Nodes specification has been updated. Draft #2 makes the following changes:

1. The GL_SSECT structure has been changed to prevent possible problems with mis-alignment. The 'count' field is now 4-bytes long, as in V3. It was noted that some processors (Alpha, and SH-4 used in the Dreamcast) cannot handle mis-aligned longs, and some processors (x86-64) incur a large speed penalty.

2. The date and time format has been changed slightly to be compatible with the ISO standard. The '-' character is now used as the separator in the date (instead of '/'), and the fraction of a second is respresented with '.' followed by four digits (instead of ':' followed by two digits).

>> Example: 2005-04-30 15:49:40.1234

This is still a draft, and further suggestions and/or corrections are welcome. The full specifications can be found here:

http://glbsp.sourceforge.net/specs.php

Cheers,
Andrew Apted <ajapted@users.sourceforge.net>

Well all segs (in gl-nodes) have partners (except on 1-sided lines), adding a dummy seg means you either got its partner "floating around" to deal with, or you change the spec to make partners not always required.

I guess I just need to investigate glBSP's behaviour in more depth and see if anything can be done about these problem subsectors (could still be a bug lurking in there :wink:).

Create a second seg to close it?

[quote="randy"]I do have one suggestion: Because GL subsectors are required to be closed and ordered, storing the end point for a seg is redundant. You can save 4 bytes per seg if you omit it.[/quote]
Yes, I am considering dropping the redundant vertex. The only real concern I have is about subsectors that don't turn out correctly (typically from errors in the map), sometimes they only contain a single seg. I'm not sure what glBSP should do in cases like this.

ZDoom doesn't use GL nodes, so I don't plan to support these. I'm sure Timmie will add them to ZDoomGL, though.

I do have one suggestion: Because GL subsectors are required to be closed and ordered, storing the end point for a seg is redundant. You can save 4 bytes per seg if you omit it.

Hi, I'm Andrew Apted, author of glBSP.

(Creating a new topic since the previous one got, well, "bogged down" may be the politest way to put it).

A new version of the GL-Nodes specification has been prepared and can be found at the following URL:

http://glbsp.sourceforge.net/specs.php

This is a draft version, and I'm looking for feedback, like ways the specs could be improved, mistakes to fix, better ways to do things. Also feel free to ask any questions. I plan to freeze the specs after 3 weeks or so, and update glBSP to generate the new formats.

Summary of the changes:

- V5 GL-Nodes, which removes all the limits. V3 removed the segs and vertex limits, but V5
also prevents overflowing the number of nodes/subsectors. The other versions (V1, V3, V4) are now deprecated, only V2 and V5 need to be supported.

- support for storing information in the GL level marker lump (GL_MAP01 etc). The format is a text file with KEYWORD=VALUE pairs. Currently there are keywords for a timestamp, a level checksum, and the name of the node-builder.

- support for level names longer than 5 letters. When this happens, the GL level marker becomes "GL_LEVEL", and the name of the normal level is stored inside this lump using the "LEVEL" keyword.

- a standard way of creating Extension lumps.

You can email me at: <ajapted@users.sourceforge.net>