Ultimate Doom Builder

[guitardz]

Is there an option in UDB to get the shaded in thing boxes in visual mode like DB2 had? It was the main thing I missed moving from DB2 to GZDB. The wireframe box is just harder for me to see with my old eyes, the old shaded in one was a lot easier on me.

[Kappes Buur]

Is there an option in UDB to get the shaded in thing boxes in visual mode like DB2 had? It was the main thing I missed moving from DB2 to GZDB. The wireframe box is just harder for me to see with my old eyes, the old shaded in one was a lot easier on me.

What do you mean by shaded?
Can you give a full screenshot?

[guitardz]

What do you mean by shaded?
Can you give a full screenshot?

I found a video of some old DB2 turorial that has an example of what I'm talking about, here is a screenshot from it:

[dpJudas]

So with DX gone, will this become officially cross-platform, with Mac and Linux builds? (Or perhaps just Linux builds because Macs suck at OpenGL now and Apple is the worst.)

I don't feel like building Mono now or anytime in the next week.
Maybe sometime later when I get a proper Linux environment instead of headless VM we could have a native build. Theoretically that should be supported with mono versions of the projects (already existing, were added by Talon I believe?)

Actually, I created those mono projects and the initial Makefile. Talon improved the building a bit and did some tweaking on top of that. Right now the mono build doesn't work (at least according to Gutawer on Discord). Most likely due the project files being slightly out of sync and thus missing files.

The whole project could really use an improved build environment, but I don't know what is the best way of dealing with it. The Visual Studio C# build tools are absolutely horrible both in Windows and Linux. In Windows they overwrite files currently added to git and in Linux they need slightly different defines and post build scripts. I have no idea what larger C# projects do in this area - the basic built-in msbuild crap just doesn't seem to scale well.

Aside from that there's two huge outstanding issues with the mono build of UDB: 1) SendMessage is not implemented, 2) RawMouse is not implemented. In both cases I think the best solution is to do something else on the C# side if they are not available. For RawMouse just fall back to reading mouse events from winforms, and for SendMessage find a different way of executing custom actions on the UI thread.

[Mysterious Haruko]

what I noticed in this builder from bug side:

1. Linedefs contain artifacts, especially if those lines are coloured.
2. automap, sound propogation mode and node viewer are broken.

As for suggestions in the future - could we get more colour presets for automap view? Or even get function to customise it?

I'll add some pictures:

[boris]

I fixed the upside down drawing already (https://github.com/jewalky/UltimateDoom ... issues/325).

Looks like all lines have the artifacts, but it's only really visible if you have colored lines that are clashing with white.

[axredneck]

Required software:

• Microsoft .Net Framework 4.6.1: https://www.microsoft.com/en-us/downloa ... x?id=49982

edit: works without .NET with Mono under Wine, but anyway.
After "winetricks dotnet461":

[Enjay]

As for suggestions in the future - could we get more colour presets for automap view? Or even get function to customise it?

I suspect that this would be beyond what anyone wants to code, but reading custom automap colours from a gzdoom ini file would be a cool source for "this is what it actually looks like in game".

Or maybe, more realistically, the gzdoom default schemes could be included as well as the original Doom one. And, perhaps (less likely) a simulation of the textured automap.

Personally, I'm not that bothered. I just use automap mode to show me if I have hidden any lines that I want to hide and the colour doesn't really matter to me.

Being able to easily double check which floors have been hidden in textured mode would be nice. It's easy to miss those. It wouldn't have to be a full emulation of the textured map though; perhaps just some colour-coded thing a bit like the sound propagation mode simply showing visible versus hidden.

All "nice to have" things for the future (perhaps), but the basics seem to be working pretty well so far.

[axredneck]

You need to set __GL_MaxFramesAllowed=1 environment variable if You use UDB/GZDB under Linux+Wine on Nvidia GPU with proprietary driver. @ZZYZX, can You mention this somewhere?

[skdursh]

Can I just update my GZDB-bugfix or do I need to make a fresh install? Seems kind of silly if I can't just update it from GZDB-bugfix tbh seeing as it's essentially the same thing with a new name.

Edit: Nevermind. Somehow my eyes skipped over the new requirements for UDB that specifically says it can't be updated from GZDB-bugfix. Probably because I didn't read it before posting my message.

[YukiRaven]

I gave it a try with the map I'm currently working on, which is decent sized (3110 sectors, 8793 verts, 1020 things). It uses a 130mb pk3 texture pack right now, which puts the total number of textures to about 9062.

I used two separate prefixes, one for 32-bit and one for 64-bit. My machine: nvidia 1080 with 8GB of ram, driver 440.44, Slackware Linux 14.2 64-bit, 12gb system ram, Intel Core i7 2700K CPU, UDB r3252.

Wine 5.0rc2 with wine-staging and MS's .NET 4.7.2 with the 64-bit version of UDB:
3D mode runs a bit better than GZDB with SlimDX :D My FPS in 3D mode is between 15 and 60 FPS on my current map, depending on where I'm looking. 2D mode, however, is unbearably slow, with it taking 1-3 seconds to update anything except what I'm drawing. Both are slightly slower than the last UDB I tried, from just before it was named UDB.

UDB 32-bit version:
Runs about the same in 3D mode as the 64-bit version, but MUCH faster in 2D mode. Like, it's silky smooth in 2D. However... it crashes with an out-of-memory error whenever the texture browser is set to "All": https://i.imgur.com/wfxVFQM.png

Any surface with an F_SKY1 texture wants to default to "All" for some reason, so this makes it kind of frustrating :-P This crash doesn't happen with the old 32-bit SlimDX version of GZDB (same map, same wine/wine-staging/.NET, same machine).

I noticed that the old SlimDX version's memory usage grows about 500mb when I go to "All" on this map. In UDB, it grows about 1gb.

Wine + Wine's version of Mono:
Still takes a long time to load (I clocked it at 9 minutes to load my 130mb texture pk3), but once it does, it works about the same as with MS's .NET Framework. I also still get an out of memory error crash, albeit a slightly different one: https://i.imgur.com/mXqRwVY.png

Native Mono 6.0:
Crashes instantly as soon as I try to launch it:

You need to set __GL_MaxFramesAllowed=1 environment variable if You use UDB/GZDB under Linux+Wine on Nvidia GPU with proprietary driver. @ZZYZX, can You mention this somewhere?

Huh, I've never had to do this, and it's not set for me. Maybe it's only needed sometimes or with certain cards? I just tried with and without it and it doesn't seem to make a difference for me.

[ZZYZX]

Thanks for the detailed testing! I think this part is the most important, as it blocks 32bit mode which works for you:

I noticed that the old SlimDX version's memory usage grows about 500mb when I go to "All" on this map. In UDB, it grows about 1gb.

Looks like SlimDX didn't duplicate textures between GPU and CPU memory, I wonder if it's possible to put PBO into each texture so we can store the pixels once and read them back for displaying in GDI... after all GDI is slow enough on it's own and one more memory mapping shouldn't be very noticeable, if correct mode is used.

edit: Tested on Windows, memory usage in UDB is indeed larger. Will research the idea with storing pixels inside texture later.

[ZZYZX]

I found a video of some old DB2 turorial that has an example of what I'm talking about, here is a screenshot from it:

Please make a GitHub issue: https://github.com/jewalky/UltimateDoomBuilder/issues
Likely it will be forgotten/dropped if only voiced in this thread. This thread is more for urgent/one-time help or editing questions.

update: Fixed memory management issues. Please see if there are no missing textures.

[Enjay]

Just out of interest, I noticed that line colour presets don't transfer across Game Configurations and they have to be set up for each one.

I can understand this if the things the colour presets are looking for are different across different configurations (e.g. line colours based on line activation types in UDMF would be inappropriate to transfer across to traditional Doom).

However, I have created several UDMFconfigurations that I work with and they are all based on GZDoom in UDMF but, as far as I can tell, I have to set up all my colour presets each time for each configuration. I wonder, is there a quick/easy way to transfer presets between projects?

I've had a look in GZBuilder.cfg and I could probably copy/paste stuff in there but I just wondered if something a bit more convenient exists?

[ZZYZX]

The whole project could really use an improved build environment, but I don't know what is the best way of dealing with it. The Visual Studio C# build tools are absolutely horrible both in Windows and Linux. In Windows they overwrite files currently added to git and in Linux they need slightly different defines and post build scripts. I have no idea what larger C# projects do in this area - the basic built-in msbuild crap just doesn't seem to scale well.

About the build process, I personally don't have any issues with msbuild, HOWEVER the real issue is that I need to set up a separate machine (supposedly with a Windows docker?) that'd do the msbuild.
This way, as assembly information won't need to be changed on the developer's machine (with current manual builds) it wouldn't spam there.
Everything else that's replaced at build time should be added to gitignore.

Maybe it's possible to build UDB using CircleCI (and then somehow upload devbuilds to DRD — not sure what's the correct way to do this — I think it would have to be a script on Rachael's side). I need to research this.
More or less correct way for me would be having three branches:
1) master — all the code
2) update_dev — master is merged here to issue a new Git build with auto-update
3) update_stable — master is merged here to issue a new setup.exe (not necessary though)

Current way where developer has to manually build and upload every git build is atrocious. I can understand this flow for major release setups, for "nightly builds" though makes zero sense.
Especially now that there are free CI services...