ZDoom

http://www.skulltag.com/forum/viewtopic ... 70&t=11530

I want this feature. I can't wait for DoomScript any longer.

Forget it. Too much work for too little gain.

Did you even take a look at Blzut's code?

Do Randy and Graf have accounts with access to the internal testing board at Skulltag? It seems not. In fact, it seems that Randy doesn't even have an account there. Because that code, as far as I know, exists only on Blzut's computer and as an attachment in a restricted-access thread.

I suppose they'll want to wait for it to be bugfixed a bit and included in ST, and then they'll backport it, if it works correctly and is adopted by the community. In the meantime, you can use Blzut's code.

Gez: It's CLEARLY OBVIOUS that Graf has access to Skulltag's code because he needs it to share code between the two and has ported over other features in the past, not to mention that Skulltag uses GZDoom's hardware renderer, which was part of the deal.

Porting it over would be what, copying a few files and calling it a day? I have it, and as an internal tester there's been discussion about it for a while now including on IRC. It's not nearly as bad as you think it is. Right now I can understand why not, but once a final version gets revised it shouldn't be a problem bringing it over.

You know, I really don't see anything wrong with using Blzut's implementation as long as it works. I mean, come on, it's already ridiculous waiting for DoomScript; I don't think I want to wait some more for the HUD code to be exported into DS (which I do recall being a low priority even if DS happens).

SnowKate709 wrote:Gez: It's CLEARLY OBVIOUS that Graf has access to Skulltag's code

Duh.

Yes. But Blzut's code is not in Skulltag's code. Not yet anyway. So it's not so clearly obvious Graf has access to Blzut's code. ST's code is not managed through the forum, so code-sharing between the ZDoom developers and the ST developers doesn't pass through forum access rights.

Gez wrote:Not yet anyway.

Mmm, I'll just re-iterate so everone can understand it. **tries not to blow a fuse**

When it gets implemented into Skulltag (which is pretty much a yes as far as I've seen), it can easily just be copied into zdoom with minimal changes. No need to immediately complain about "too much work" because there's virtually little if any work that needs to be done aside from doing the standard sanity checks. Everything has already been done. Implementing blzut's code has been discussed and should not be difficult at all.

That's all I'm saying.

This will result in needless work later.

The more code has to be made working with Doomscript, the harder it will get. And to be honest - I am very - VERY - reluctant do mess around with the status bar code before something real can be done with it.

DECORATE is already giving me the creeps due to the ways it can be abused and I really don't want more of that that has to be dealt with when Doomscript finally arrives.

(Oh, and BTW, I have full access to the Skulltag source and development forum but I rarely go there.)

I do not see how this would be more work? The SBARINFO is its own statusbar so the code is pretty much isolated from everything else (and if there is no SBARINFO lump it isn't even used at all). Couldn't there be a disclaimer saying that "SBARINFO and DoomScript stbars do not mix" or something?

Seriously, this is like, no work at all. Even I could port this in with my very limited programming knowledge.

DoomScript is still forever away, and this was already coded (and a lot of time spent on said coding, too). So, why not just put it in already? It does not interfere with anything that DOES NOT have SBARINFO in it, so the original zdoom behavior is untouched. This would only apply to wads with SBARINFO lump present, so what on earth could it possibly break?

Blzut3 wrote:I do not see how this would be more work? The SBARINFO is its own statusbar so the code is pretty much isolated from everything else (and if there is no SBARINFO lump it isn't even used at all). Couldn't there be a disclaimer saying that "SBARINFO and DoomScript stbars do not mix" or something?

I haven't had a look at the code itself yet. So you are saying this is a completely isolated module that is being used as a replacement for doom_sbar, heretic_sbar and so on and not integrated into the existing status bars?

You closed the topic before even taking a look at the code, and before Randy even said anything... :(

Graf Zahl wrote:I haven't had a look at the code itself yet. So you are saying this is a completely isolated module that is being used as a replacement for doom_sbar, heretic_sbar and so on and not integrated into the existing status bars?

That would be correct. If no SBARINFO is found it does nothing different than the standard zdoom startup (except if GAME_Any is set then it will load a blank SBARINFO and be no different anyways). All the drawing is done in the sbarinfo.cpp files witch contains an alternate statusbar class leaving the other _sbar.cpp files unaffected.

The only time it touches the old code is to init it in g_level.cpp (approx 15 lines) and to declare the function CreateCustomStatusBar() (or something like that) in sbar.h (1 line).