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

    glBSP 2.05 Released


    mewse

    Over at the glBSP page you can download the new version of this nodes builder for OpenGL ports. Some of the significant changes include:

    - ported glbsp and glBSPX to MacOS X.
    - added new option "-quiet" for less cluttered output.
    - glbsp now handles multiple input WADs (GWA mode).
    - lumps in the output WAD are now aligned properly.
    - automatically removes dummy sectors from BSP tree.

    Mmm.. smaller wads. Tastes like victory.

    Sign in to follow this  


    User Feedback

    Recommended Comments



    what the... I seemed to have entered everything else, even though I clicked 'Doomworld News'

    Share this comment


    Link to comment

    a regular nodesbuilder leaves subsectors open and the points unordered. GL nodes close subsectors with minisegs (segs not attached to any line) that are ignored by the renderer for the most part and reorder the points so they are always counterclockwise. I'm sure there's more, but that's the most important stuff, imo :)

    Share this comment


    Link to comment
    timmie said:

    a regular nodesbuilder leaves subsectors open and the points unordered. GL nodes close subsectors with minisegs (segs not attached to any line) that are ignored by the renderer for the most part and reorder the points so they are always counterclockwise. I'm sure there's more, but that's the most important stuff, imo :)


    Ah, OK, thanks. :) Wouldn't that mean that nodebuilders like, for example, ZenNode could just be fixed to take care of those extra requirements for GL nodes, though?

    Share this comment


    Link to comment
    Schneelocke said:

    Ah, OK, thanks. :) Wouldn't that mean that nodebuilders like, for example, ZenNode could just be fixed to take care of those extra requirements for GL nodes, though?



    It's not a fix, it's an extension. Theoretically it should be possible to extend Zennode to create GL nodes but, frankly, of all the node builders I know of Zennode is the one which is hardest to reprogram. The code is rather convoluted and the data organization makes so many assumptions about data size relations that I for sure don't want to mess with it.

    Share this comment


    Link to comment
    sargebaldy said:

    This might just be the first news thread to get post helled :)


    No it wouldn't. AndrewB sent a news thread to Post Hell, which resulted in his Super Moderator status being removed, and, IIRC, he was banned for it too.

    Share this comment


    Link to comment
    BBG said:

    No it wouldn't. AndrewB sent a news thread to Post Hell, which resulted in his Super Moderator status being removed, and, IIRC, he was banned for it too.

    URL

    Share this comment


    Link to comment
    læmænt said:

    why, is post-helling news such a bad thing?

    The news comment threads are more or less a first-time visitor's gateway into the forum. What would they think if they were greeted with a yellow and orange forum along with the aural torture now present in Post Hell?

    Share this comment


    Link to comment
    Graf Zahl said:

    It's not a fix, it's an extension. Theoretically it should be possible to extend Zennode to create GL nodes but, frankly, of all the node builders I know of Zennode is the one which is hardest to reprogram. The code is rather convoluted and the data organization makes so many assumptions about data size relations that I for sure don't want to mess with it.

    Depends on your talent :) I looked at both of these critters. Not that hard bud.

    Solution: Just graft the GLBSP code into ZENNNODE - since there is already code in GLBSP to work with existing nodes. When I looked at both it became obvious that the problem is not that difficult - just a grunt coding drill.

    Quickest way is just to tack the GLBSP code at the end of ZENNODE. This preserves the indepedent coding models used. Although not quite as elegant as a tight integration, it works :)

    Share this comment


    Link to comment
    FireBastard said:

    Depends on your talent :) I looked at both of these critters. Not that hard bud.

    Solution: Just graft the GLBSP code into ZENNNODE - since there is already code in GLBSP to work with existing nodes. When I looked at both it became obvious that the problem is not that difficult - just a grunt coding drill.

    Quickest way is just to tack the GLBSP code at the end of ZENNODE. This preserves the indepedent coding models used. Although not quite as elegant as a tight integration, it works :)



    Sure but then you could always run Zennode first and GLBSP second, right. The result should be the same and a simple batch will do. ;-)

    Share this comment


    Link to comment
    Graf Zahl said:

    Sure but then you could always run Zennode first and GLBSP second, right. The result should be the same and a simple batch will do. ;-)

    Obviously that could be done. I don't think anyone here is that stupid yet. Not the same as having a nice tight package. Guess you missed the point I was making bud. You made it sound like it was very hard, it isn't. Helps to know how they both work.

    Btw, anyone who actually does this hack job will be prone to setting mistakes since the option keywords/stuff betweeen the 2 is not even close. Did you know that GLBSP will not work correctly unless you override certain options? Try it on ZDOOM and you will get some surprising results on certain combinations. Sure helps if you know the innards of both programs.

    Share this comment


    Link to comment
    FireBastard said:

    Did you know that GLBSP will not work correctly unless you override certain options?



    Frankly, unless there are overlapping linedefs I always use ZDBSP. It's by far the most reliable and most stable node builder available, not to mention the fastest. Its only problem is that it eliminates duplicate lines between identical vertices although sometimes this is used for texturing effects.
    GLBSP as a standalone is something I don't particularly like. I don't really think its node building algorithm is that good to begin with. It's good for adding GL nodes to existing nodes though.

    Share this comment


    Link to comment
    Bloodshedder said:

    The news comment threads are more or less a first-time visitor's gateway into the forum. What would they think if they were greeted with a yellow and orange forum along with the aural torture now present in Post Hell?


    Aural torture? I guess I'm missing something here...

    Share this comment


    Link to comment
    Schneelocke said:

    Aural torture? I guess I'm missing something here...

    on IE you have to listen to an annoying ass midi on post hell threads. serves people right for using IE :P

    Share this comment


    Link to comment
    sargebaldy said:

    on IE you have to listen to an annoying ass midi on post hell threads. serves people right for using IE :P


    Ah. :) It's almost a pity I never use IE, then... almost.

    Share this comment


    Link to comment
    Graf Zahl said:

    Frankly, unless there are overlapping linedefs I always use ZDBSP. It's by far the most reliable and most stable node builder available, not to mention the fastest. Its only problem is that it eliminates duplicate lines between identical vertices although sometimes this is used for texturing effects.
    GLBSP as a standalone is something I don't particularly like. I don't really think its node building algorithm is that good to begin with. It's good for adding GL nodes to existing nodes though.

    Don't think so bud. You again made a booboo here.

    Fastest depends on the level and setting. There are some levels where it's either deepbsp or zdbsp regards speed. Big aaahh .. stretch .. yawn .. aahhh since for the latest trick machines who really cares if it's 3.4 seconds or 3.8 seconds. Give it a rest.

    GLBSP sometimes can screw things up if you build from existing nodes - which you would know if you actually did this instead of guessing. IOW actual editing/level experience in this area helps before making these wild ass claims. Many would disagree with you anyway since this very much depends on the level.

    Here's something to broaden your experience. Run zdbsp with GL nodes turned on and then visit some GL enabled port, esp with skies, etc. Now do the same with GLBSP and use a factor 16 value and of course -normal. Damn, saw a level not too long ago with stairs into the sky and a sky on the floor too. Display went bezerk in ZDOOM. No mistakes in the level either.

    So one can always find levels that favor 1 node builder over the other or a port. Sure Randy compensated specifically in his code for his own quirks. Too bad it doesn't apply to other GL ports. Reliable tends to mean that the level displays as intended. Using that definition ZDBSP has some serious problems like falling through fake bridges - even in ZDOOM. Nothing to do with bridge object stuff - this is about "reliable" and zdbsp just doesn't cut it for many class act levels that exploit these tricks.

    Stable? Have no idea what you mean by stable - is that a place where you keep horses? :) glbsp nor deepbsp nor bsp nor warm crash given the right resources. zennode is good too, except it needs more than 1 sector and a bit more memory. Just about all the legacy guys use zennode. And please don't rant about legacy, that gets old. It's a very cool port too. All the ports have their strong points, just like node builders.

    Share this comment


    Link to comment
    FireBastard said:

    Don't think so bud. You again made a booboo here.

    Fastest depends on the level and setting. There are some levels where it's either deepbsp or zdbsp regards speed. Big aaahh .. stretch .. yawn .. aahhh since for the latest trick machines who really cares if it's 3.4 seconds or 3.8 seconds. Give it a rest.

    GLBSP sometimes can screw things up if you build from existing nodes - which you would know if you actually did this instead of guessing. IOW actual editing/level experience in this area helps before making these wild ass claims. Many would disagree with you anyway since this very much depends on the level.

    Here's something to broaden your experience. Run zdbsp with GL nodes turned on and then visit some GL enabled port, esp with skies, etc. Now do the same with GLBSP and use a factor 16 value and of course -normal. Damn, saw a level not too long ago with stairs into the sky and a sky on the floor too. Display went bezerk in ZDOOM. No mistakes in the level either.

    So one can always find levels that favor 1 node builder over the other or a port. Sure Randy compensated specifically in his code for his own quirks. Too bad it doesn't apply to other GL ports. Reliable tends to mean that the level displays as intended. Using that definition ZDBSP has some serious problems like falling through fake bridges - even in ZDOOM. Nothing to do with bridge object stuff - this is about "reliable" and zdbsp just doesn't cut it for many class act levels that exploit these tricks.

    Stable? Have no idea what you mean by stable - is that a place where you keep horses? :) glbsp nor deepbsp nor bsp nor warm crash given the right resources. zennode is good too, except it needs more than 1 sector and a bit more memory. Just about all the legacy guys use zennode. And please don't rant about legacy, that gets old. It's a very cool port too. All the ports have their strong points, just like node builders.



    My, my, are we in a bad mood today?
    I have tested all better known node builder on hundreds of levels to determine their quality. So please don't make any wild assumptions about what I know. My results were that Zennode is the one that screws up the most (but if it works it creates most likely the best result), ZDBSP has a few known problems but *overall* I experienced by far the least problems with it. DeePBSP may be nice but without any source it's hard to analyze its real quality. GLBSP simply has the problem of being based on very old code. Its main problem is that it is very slow and in relation to the speed doesn't even create particularly good nodes. The last node builder worth to mention is WARM. As long as there are no dirty 3D-effects in the level it works fine but it definitely has problems with open sectors - which, honestly, is always like a game of chance. If you are using constructs like this you have to be *extremely* careful not to be screwed by your node builder. You may be lucky or you may not but there might always be a hole you can fall into. But that's not caused by bad node builders. I call this sloppy mapping if you put your complete trust in it. What if somebody wants to use such a level with a source port that requires a node rebuild which screws up the effect?

    Share this comment


    Link to comment
    Graf Zahl said:

    .. stuff..

    Bad mood? Not a chance, just correcting you. Are you in a bad mood - seems like it? I've tested close to a 500 levels for that matter. Who give a flying f. about that. I bet some here have tested 1000's of levels.

    I'm not making any wild assumptions about you at all - can only read what you post here. You clearly have posted things as fact that are not fact, now 3 times: 1 for zennode mods, 2 for speed and now on source code and GLBSP.

    GLBSP, although it says it's based on BSP2.3 is not even remotely similar to BSP 2.3 code in any way. I think that was just some common courtesy displayed there nothing more. You would know that if you actually understood the code or actually looked at both of them. But whether it's "slow" or "old" is not the point. It's all about what works better with real OGL ports vs zdbsp or regular levels with tricks. Isn't that really what users are interested in? I think so.

    Can't see where anyone would need the source code to evaluate any of the "fast", "reliable" or "stable" comments. Using the source code is hardly possible anyway. Maybe you don't like the style, but you'd have to be an egomaniac to claim to be able to evaluate. Not even Lee K would make that claim. Meaning there isn't a person alive that could verify "stability" or "reliable" just by looking at the source code. Maybe one, but he's god or something like that.

    Anyway bud, it's the final results that count, nothing more. If you care to actually do some objective investigation there are algorithms to evaluate some basics. If memory serves me, seems there's one in warm or was that zennode or both (lol?). Anyway one of those. Seems there's another one in deepsea.

    But I did mention warm and the "holes" I'm talking about has nothing to do with sloppy mapping - think BOOM specials and those little lines floating out there to control things like thrust. Where have you been? All I'm only pointing out is that you can't make the claims you made - nothing to do with a bad mood. It really depends on the level and the port. JDOOM and LEGACY in particular are not happy with zdbsp. The world just got bigger.

    Share this comment


    Link to comment

    Hm, is there any difference between ZDBSP and glBSP? (Except that they are completely different heh)

    Share this comment


    Link to comment



    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

×