Extended nodes

[Chilvence]

Ah well, thats quite a sizeable difference then. I can sympathise with that, seeing as I basically have an /idgames mirror sitting on my hard drive...

[Risen]

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

I read size of compressed new nodes = size of uncompressed old nodes which would leave the old nodes room for compression.

[randomlag]

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

Well since the expanded format [either one] only kicks in if the level exceeds the old node format specs, can't see this happening (unless you forced it?)

And there are only a few levels ATM which exceed the old specs: Maybe 10-20 levels? But 1 GB is hardly anything today and in perspective to current games really pretty tiny compared to the very large number of levels you infer you have stored (as do I).

But the much more important issue is that ALL ports can play the level. So even if you did use the compressed format, none of the non GL ports will play that level and just generate GWA files and now you have even more disk space wasted That's really the issue here - crossport compatibility - not the size stuff. IOW this was never really about technical merit, but more about crossport compatibility.

And yes, I was merely talking about zipped sizes being roughly the same. In a PWAD, the sizes are considerably different, don't care Which is actually interesting, since you could store your data in "compressed" native storage form (as a part of the OS file system) and then we are back to square 1 on that issue. But I really don't care for this argument, nor does anyone else in the "other" world - since that is exactly the question I posed

[Graf Zahl]

But the much more important issue is that ALL ports can play the level. So even if you did use the compressed format, none of the non GL ports will play that level and just generate GWA files and now you have even more disk space wasted That's really the issue here - crossport compatibility - not the size stuff. IOW this was never really about technical merit, but more about crossport compatibility.

Well, since the 40 largest levels in that collection are ZDoom exclusive crossport compatibility is hardly important for them, isn't it?
It was merely a test of how large the nodes would get - and all levels that forced V3 nodes were only for ZDoom - with the exception of the full Deus Vult level.

GL nodes are one thing. What's much more important in my opinion is to have a general node format for normal nodes that stores more precise vertex coordinates. When I was testing the first version of Super Sonic Doom there were some places where the node inaccuracies played havoc with the level's geometry in places with a lot of overlapping lines. ZDoom's compressed nodes were the only means to solve this at the time of release.

[randomlag]

You blithely skipped over the crossport issue. Nothing you stated changes that problem. For 40 levels who cares. But I don't think 40 of them exceed the old node specs - otherwise the first zd level group project never would have claimed to be the biggest and that level actually stayed within the maximum. And 40 of them won't save you 1 gig as you claimed Graf. But all of this size and precision stuff avoids the main points I made.

The precision argument is really specious. You can always find exceptions and exceptions do not make for a valid viewpoint at all. I can find lot's of levels where ZDBSP won't work correctly (more precision included) and you know that also. Does that mean it shouldn't be used?

Another issue that you are probably not familiar with is that stuff ends up being tagged on the wrong side of a line. That's a node builder problem (often triggered by crap "mistakes") and again not a precision problem.

The much more serious (and relatively common problems) are level mistakes, either by accident or on purpose - not vertex precision (though GL nodes have that precision too - so by itself that's not a new idea either). The "mistakes" are much more apparent in ZDOOMGL and in fact any GL port and have nothing to do with "precision".

However, and this is most interesting, if all of this had been combined in a friendly and open discussion so that it wasn't such a pulling teeth experience - the "precision" could have been incorporated just to avoid any more discussion on that point. Actually not too late for normal nodes too. I'd have to pass that by some others to see if they'll do the slightly extra work required. Both DeePBSP and GLBSP are all set internally to do it either way - so not a technical problem. Nothing uses the extended normals yet, so that can work.

And along the same line, ZDBSP needs to revamp the spec so it can handle > 64k verts - this is as valid as precision since someday that will happen because it can happen (I have a test level with same to support this position).

That most important point is 100% port adoption and port acceptance - not the side issues. IOW it's NOT a technical issue per se (as I already stated above).

[as an aside, GLBSP builds a bit larger set of nodes vs DeePBSP, hence exceeds sooner. You should set the "factor" to 16 not the lower number that's now there. I suspect that was done to speed it up, but really don't know. I just know that it should be 16 ]

[Siggi]

heh, text

[David Ferstat]

I confess that I'm a bit confused here. Randomlag talks about "cross-port compatibility" as an important issue. I would have thought, however, that the differences between the various ports, such as Zdoom's advanced features (slopes, ACS support, support for new lumps like Decorate, etc) or Legacy and Edge's room-over-room (which may or may not work the same way) would mean that any map made to usea specific port's features would necessarily be incompatible with other the ports.

[Graf Zahl]

Of course it's an empty phrase. If you want 'cross-port compatibility' you'd have to

- only use stock Doom features
- not make your map exceed the old restrictions (there are still too many ports which can't handle it)

Face it, maps that are getting this large are rarely designed for multiple ports. Most people who want to invest the time and effort to make such large things want to do more with their maps, i.e. use ZDoom's features or those of their port of choice. And looking at the major ports the lowest common denominator that can be achieved is Boom - nothing more. The goals of the various port developers are too different.
Besides, so far I have seen only 2 released maps not made specifically for ZDoom which go above Doom's original limit of 32767 sidedefs.

As for the 'crap mistakes' that screw up ZDoomGL, that's only partially due to map bugs. Any GL source port in existence should be able to handle the trivial rendering tricks like self-referencing sectors or flooding flats due to missing wall textures. These cases are not that hard to detect and not exceedingly complex to handle inside the game. ZDoomGL doesn't do this at all and neither does Vavoom. Even Doomsday is only able to handle a very limited amount of these tricks.

But hopefully Polymost will render the whole issue a moot point. If a level can be displayed correctly in OpenGL without the use of GL nodes there'd be no more need to fill your HD with a shitload of bloated data.

[Enjay]

However, surely it would be a disadvantage, or at least a confusing issue, for different ports to all start having different node standards especially if there were no real advantages to port specific node types.

34

[Graf Zahl]

Too late for that! ZDoom already has its compressed node format and there are already maps which use it. It's the only Non-GL format with high precision vertices anway so for any map that needs it there is really no choice.

Frankly, I don't understand Randomlag's relentless campaigning against the format. It almost seems as if he has a personal issue to fight and makes it sound as if it would be a major hassle to support this format. It is not! I was able to write a converter that converts between regular GL nodes (V2 and V3) and ZDoom's compressed nodes in less than an hour. All that is needed is to add ZLib to the project but to support PNG graphics it is needed anyway so no additional waste here!

[randomlag]

Must you take everything on a personal level? Must be a hormone thing and is NOT the way to discuss alternate idea [a concept you might consider].

It's not a campaign against the format [ a totally negative pov that I just don't share ]. It is instead [ and it seems I have to keep repeating this forever till it sinks in] ONE step to simplify things in consideration of a broader perspective. It's as simple as Enjay stated.

IOW, I'm looking to the future, not the past. Don't care about the very few levels that use whatever - again a specious argument. Either you completely don't understand the points made or you are just being you.

And a level that uses BOOM features is much more common than a level specific to ZDOOM [contrary to your claim]. All you have to do is go to the various archives. Most authors would like to have their levels work with more than a single port.

As to "all that's required" argument, I have ASKED THE PORT AUTHORS what they want and asked Apted when I finally got a hold of him. Did you? Did Randy? We ALL agree that we would prefer not to have compressed nodes. It never was and never is about technical issues. It's about KISS and what OTHER port authors and coders affected would like. It's just a common courtesy thing that somehow is not understood.

It's never "too late" since there are very very few levels that use the compressed stuff. 40 is a pittance. Please don't subvert words. There is a choice for normal nodes -V4 nodes - the high precision is hardly ever required. Actually I had that in the original spec, but I had to get the GL stuff working so I took a quicker route since no port required the normal nodes (you can verify that in some DW posts last year I think in Eternity].

"Frankly", I don't understand your "relentless" refusal to accept simple statements and always attempt to contrive alternate meanings that were never stated anywhere. As to the"precision" argument please reread what I stated about ZDBSP. You know and I know that it doesn't do "bridges" correctly and also screws up on certain "tricks". No amount of precision will fix that

And you are quite off the track talking about GL rendering issues. It's NOT a trivial issue and is NOT easy to detect. 10sector is actually a good example of some tricky problems caused by "sharing" sectors and BLUDWRKS is the pits. The number of mistakes that software rendering hides is amazing. Expecting authors to be "perfect" hardly ever happens. So if a user sees a bunch of crap in a GL playing port, they never blame the author, just the port. Hence, it becomes a GL port's problem to fix.

To repeat though, all this technical BS missed the most important point: cross port standards. If you don't understand the point, fine, just be assured that others do understand.

As an aside:
1. It's too bad the coop effort fell flat on it's ass when TNT tried that, probably because of age/maturity issues?

2. ZDOOM will encounter this format in one form or another [Randy promised he'd support it when the first port came out that did so and that's been true for over 6 months]

3. DOOM is NOT DUKE. Hence I expect that polymost will not automatically fix the stuff that a DOOM level can produce via "tricks" or "mistakes".

[Graf Zahl]

Must you take everything on a personal level? Must be a hormone thing and is NOT the way to discuss alternate idea [a concept you might consider].

It's not a campaign against the format [ a totally negative pov that I just don't share ]. It is instead [ and it seems I have to keep repeating this forever till it sinks in] ONE step to simplify things in consideration of a broader perspective. It's as simple as Enjay stated.

Noooo! Of course not! So why do you position yourself as the crusader against it?

IOW, I'm looking to the future, not the past. Don't care about the very few levels that use whatever - again a specious argument. Either you completely don't understand the points made or you are just being you.

Your 'points' have as much merit as the utterings of many politicians, i.e. not much. You talk a lot but don't say much.

And a level that uses BOOM features is much more common than a level specific to ZDOOM [contrary to your claim]. All you have to do is go to the various archives. Most authors would like to have their levels work with more than a single port.

Give me a list. In the last 2 years there hasn't been much notable content which is Boom compatible (the major exception being Community Chest 2 but even there half the maps didn't really make much use of Boom.) The amount of new ZDoom projects was definitely higher.

As to "all that's required" argument, I have ASKED THE PORT AUTHORS what they want and asked Apted when I finally got a hold of him. Did you? Did Randy? We ALL agree that we would prefer not to have compressed nodes. It never was and never is about technical issues. It's about KISS and what OTHER port authors and coders affected would like. It's just a common courtesy thing that somehow is not understood.

No, you opened your statement with telling your negative opinion about ZDoom's compressed node format.
If it had been like 'Look, ZDoom has this. What do you think? Is it ok, or can we do something better?' it would be ok, but by starting the whole discussion by 'I don't think that is that good...' and pointing to the compression as a negative you were steering the whole matter into a directon you intended from the start. I don't call that getting objective opinions. In fact you were encuraging all others from the start to dissmiss it.

It's never "too late" since there are very very few levels that use the compressed stuff. 40 is a pittance. Please don't subvert words. There is a choice for normal nodes -V4 nodes - the high precision is hardly ever required. Actually I had that in the original spec, but I had to get the GL stuff working so I took a quicker route since no port required the normal nodes (you can verify that in some DW posts last year I think in Eternity].

I know of one project that required the compressed nodes to work: Super Sonic Doom. Anyway, why should the format be dumped - just because it goes against your beliefs? No thank you! As for the Eternity discussion you mention, I found the outcome really disappointing. I call that lack of vision.

"Frankly", I don't understand your "relentless" refusal to accept simple statements and always attempt to contrive alternate meanings that were never stated anywhere. As to the"precision" argument please reread what I stated about ZDBSP. You know and I know that it doesn't do "bridges" correctly and also screws up on certain "tricks". No amount of precision will fix that

If your 'statements' were simple and made sense I'd accept them. But instead I have to read through endless pointless ramblings with little content. I can't stand the speeches of politicians and this comes quite close.

And you are quite off the track talking about GL rendering issues. It's NOT a trivial issue and is NOT easy to detect. 10sector is actually a good example of some tricky problems caused by "sharing" sectors and BLUDWRKS is the pits. The number of mistakes that software rendering hides is amazing. Expecting authors to be "perfect" hardly ever happens. So if a user sees a bunch of crap in a GL playing port, they never blame the author, just the port. Hence, it becomes a GL port's problem to fix.

Remember, I said the SIMPLE cases! I know that they are rather easy to detect because I have written the code myself. It is obviously not as good as Risen3D but it can at least handle simple self referencing sectors which are the most common occurence of these crappy tricks.

To repeat though, all this technical BS missed the most important point: cross port standards. If you don't understand the point, fine, just be assured that others do understand.

There are no 'cross port standards'. When I look at the current state of development I see radically diverging development. With the exception of Vavoom (and maybe Legacy but I can't tell due to lack of information) none of the others appears to make any attempt to keep up with the others.

As an aside:
1. It's too bad the coop effort fell flat on it's ass when TNT tried that, probably because of age/maturity issues?

Agreed. But who knows where that would have ended. Some lowest common denominator I guess that nobody would have been happy with.

[quote}
2. ZDOOM will encounter this format in one form or another [Randy promised he'd support it when the first port came out that did so and that's been true for over 6 months]
[/quote]

ZDoom doesn't even support V2 GL nodes because it can't do much with them. I don't see why that would change any time soon.

3. DOOM is NOT DUKE. Hence I expect that polymost will not automatically fix the stuff that a DOOM level can produce via "tricks" or "mistakes".

From looking at Randy's pictures the rendering principles seem to be close enough to the software renderer. And at least Randy believes that it should work. We'll see.

[Chris]

There are no 'cross port standards'.

Isn't this what it's supposed to help? There is no cross-port standard right now, no.. but does that mean there shouldn't be? From what I can see, this is an attempt to get improved cross-port standards. You can't expect to go "If you want cross-port standards, make all ports ZDoom-compatible." and not get a bunch of "Fuck you"'s in return.

EDIT: WTF .. if you're going to censor the f-word, at least make it something that makes sense.

[Biff]

Hahahaaa! It makes sense now. This is great, sort of like "Pappa's got a brand new bag!"

[Graf Zahl]

There are no 'cross port standards'.

Isn't this what it's supposed to help?

Let's see.

In theory, yes. But keep in mind that Zdoom's compressed nodes format was the first attempt ever that tried to eliminate the problem. And what happens? Instead of accepting it and making it the standard - nooo! Randomlag comes around and starts a campaign to kill it from the start. His entire actions were geared to his personal goal not to let it be established as the standard. Instead he created his own one. How are we supposed to get standards if everything is refused due to such issues. How can I take any talk about standards seriously if it comes from someone who can't accept anything that doesn't fit his view of things?

There is no cross-port standard right now, no.. but does that mean there shouldn't be? From what I can see, this is an attempt to get improved cross-port standards.

Again, you can't get standards if everyone's petty personal issues get in the way. In my experience it is nearly impossible to get everything together in a way that works because there's too many people who have to do it their way. So far I don't know many port authors which are willing to add code from other ports to their own.

You can't expect to go "If you want cross-port standards, make all ports ZDoom-compatible." and not get a bunch of "sarkus sark you"'s in return.

Of course not. But you can't get it either by just dismissing any kind of solution just because you don't like it.

EDIT: WTF .. if you're going to censor the f-word, at least make it something that makes sense.

what the fuck?

EDIT: I see. Very funny!