Making Zone Builder multiplatform -- is it possible?

eblu

in meme hell since 2001
I'm not entirely sure what forum I should ask this in so I'll just drop it here.
As a recent switcher to Linux, I was somewhat dismayed by Zone Builder's lack of support for anything other than Windows. Not only does it hiccup in WINE every time I try to load more than one map consecutively (I reported this issue on the GitLab, but haven't got any response on it), but it also depends on the "unholy trinity" of DirectX, WinForms, and .NET 3.5, all of which are Windows exclusive. My question is if it's theoretically possible to get Zone Builder to run on the other platforms that SRB2 supports, either through WINE or by making a native build. I'm somewhat aware that LJ did make some progress on an attempted port, but was held back by the hackiness and workarounds of the editor if I recall correctly.
I'd totally appreciate any input on this topic.
 
Does it even keep up to date with Doom Builder at this point? Does that get updated? If not, I really liked the idea of SRB2 Workbench and still prefer it as far as speed is concerned. We ought to make something in say, C++/Qt or GTK that just works everywhere.
 
Workbench has the best framework and UI functionality by far. If we were to do something like that, modeling it after DB2/ZB with a heavy emphasis on incorporating Workbench's features would give us the perfect map editor. By workbench's features, I mean the right-click context menus, FOF wizard, actual working srb2wiki browser launch functionality, and the most important, yet seemingly most overlooked feature, tag jumping.


Is workbench open source?
 
Zone Builder is a clone of GZDoom Builder with some fairly superficial edits for better SRB2 support. Being dependent on DirectX, WinForms and .NET is something it inherits from GZDB, and I have neither the time nor the knowledge to change this.

Recently, the people who were keeping GZDB maintained after its creator ragequit rebranded it as Ultimate Doom Builder. UDB claims to have better Linux compatibility, although I have no idea what that entails - I encourage you to try it out and report back on whether it fixes your issues. One thing that definitely makes Linux compatibility easier is that they switched from DirectX to OpenGL 3.3. This sounded great to me at first, and for a minute there I was considering rebasing ZB on UDB, but then I tried it out for myself. Turns out it crashes when I'm using my integrated Intel UHD 630 GPU. It seems to be specifically an issue with the UHD 630 (older Intel models seem to work fine) and neither me not the UDB maintainers have any idea what the problem is. Now, it does work when I switch to my dedicated Nvidia GPU, but I don't expect that every mapper in the SRB2 community has a dedicated GPU at their disposal. As long as these problems are not fixed, rebasing ZB on UDB is not an option.

Right now I'm not sure where the future for ZB lies. As some of you may know, I'm currently working with Nev3r on adding UDMF support to SRB2. UDMF will get rid of a lot of the map format hacks that required us to modify Doom Builder in the first place, but we will still need our own map editor for at least the following two reasons:
  • The linedef/sector/Thing properties windows are not designed for SRB2's needs. Some of the fields they list are not used by SRB2, and SRB2 adds some new ones that no other Doom source port uses. While there is a "Custom Fields" tab where you can add and edit any field you like, this is really cumbersome in the long run. Ultimately we will need to redesign those windows to fit our needs.
  • DB/GZDB/UDB needs some modifications to be able to display FOFs, slopes and various other graphical features in Visual Mode, because the way SRB2 implements them is different from how all the Doom source ports implement them.

My original plan was to slowly remake ZB using UDB as a basis while I was gradually implementing UDMF support in SRB2. Given the hardware issues I mentioned above, that's not an option right now. If they aren't fixed in time, I may have to base it on the last version of GZDB that still had DirectX support instead.

As for making an entirely new map editor, I strongly believe that we should not try to reinvent the wheel here. Making a map editor from scratch is an enormous amount of work - Oogaland worked on SRB2 Workbench for several years and it never got to a point where he felt comfortable making a public release. Doom Builder and its various offshoots may not always be as user-friendly or as fast as we'd like, but the Doom community (which is much larger than ours) has an interest in keeping them alive and maintained. When CodeImp stopped working on DB, MaxED picked it up and made GZDoom Builder out of it. When MaxED stopped working on GZDB, ZZYZX and various others banded together to keep it maintained, and eventually turned it into Ultimate Doom Builder. Compare that to what happened when Oogaland left - SRB2DB and Workbench were left to rot and nobody was willing or able to pick up the pieces. Then when 2.1 came out and redid the textures system, neither map editor was equipped to handle it. There was a period of almost two years where not a single map editor existed that was actually fully compatible with SRB2.

I'm not planning to go anywhere anytime soon, but if I suddenly up and left, I'd like to think the community could at least pick up the pieces as far as ZB is concerned. The code is on our public repo, and its edits to GZDB are superficial enough that, if necessary, they could be re-applied to whatever Doom map editor is the hot shit at that time. If we switched to a completely original map editor, we would become dependent on its creator sticking around. We made that mistake once before and we shouldn't make it again.

Is workbench open source?
It was, but the SVN repository where it lived is no longer online. If you're genuinely interested in messing with it or porting some of its features to ZB, I can send you the source code.
 
You make some good points about the pitfalls of a totally original editor. As a software engineer myself, I know the amount of work and time and energy even a relatively small change to a codebase requires, and while it sometimes is much more efficient to start from scratch than frankenstein in a bunch of changes, that point is usually only reached if the app in question is very small, the dev team is very big, or the app is very broken.

At any rate, though, that wasn't what I was actually suggesting. In an ideal world we would have our own original editor that was up to date and multiplatform, but I was mainly talking about adding certain features from WB to the current (or future) implementation of ZB.

Would .Net and winforms be gigantic hurdles in recreating the WB context menus or wiki web links? I wouldn't think so, but I haven't seen all that needs to be done just to get the window to pull up on the first right-click with all the correct info.


It was, but the SVN repository where it lived is no longer online. If you're genuinely interested in messing with it or porting some of its features to ZB, I can send you the source code.

That would be cool, actually. Yes, please do this. ^_^ But don't run around telling everyone that we're about to have bunches of new ZB features =P I'm really just curious.

That said, if I get time, I'd love to get the Ctrl-T tag jumping functionality from WB over to ZB. The vector arrows from linedef tags that show up when hovering over a sector and vice-versa are great, but quickly become just useless noise if they're jumping across the whole map to 30 different control sectors that are each only 0.5 square units wide. Currently I hit Ctrl+F, but I still have to type/copypasta the tag number, and the find window locks the rest of the UI from being clicked on.
 
The problem with doing our own map editor is that it would suffer the same fate SRB2 Workbench or SRB2 Doom Builder did, no one to maintain it and thus no longer being usable with the next version of SRB2.
 

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top