Ultimate Doom Builder
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.
Please read the full rules for more details.
-
- Posts: 19
- Joined: Sat Jan 13, 2018 10:38 pm
- Graphics Processor: nVidia (Modern GZDoom)
- Location: USA
Re: Ultimate Doom Builder
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.
-
-
- Posts: 4149
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
Re: Ultimate Doom Builder
What do you mean by shaded?guitardz wrote: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.
Can you give a full screenshot?
-
- Posts: 19
- Joined: Sat Jan 13, 2018 10:38 pm
- Graphics Processor: nVidia (Modern GZDoom)
- Location: USA
Re: Ultimate Doom Builder
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:Kappes Buur wrote:What do you mean by shaded?
Can you give a full screenshot?
[imgur]https://i.imgur.com/hotjCDx[/imgur]
Last edited by guitardz on Tue Dec 24, 2019 7:09 pm, edited 5 times in total.
-
-
- Posts: 3134
- Joined: Sat May 28, 2016 1:01 pm
Re: Ultimate Doom Builder
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.ZZYZX wrote:I don't feel like building Mono now or anytime in the next week.Gez wrote: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.)
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?)
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.
-
- Posts: 12
- Joined: Fri Nov 25, 2016 5:36 pm
- Location: Purple Sky
Re: Ultimate Doom Builder
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:
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:
-
- Posts: 753
- Joined: Tue Jul 15, 2003 3:37 pm
Re: Ultimate Doom Builder
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.
Looks like all lines have the artifacts, but it's only really visible if you have colored lines that are clashing with white.
-
- Posts: 391
- Joined: Mon Dec 11, 2017 2:09 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Russia
Re: Ultimate Doom Builder
edit: works without .NET with Mono under Wine, but anyway.ZZYZX wrote: Required software:
- Microsoft .Net Framework 4.6.1: https://www.microsoft.com/en-us/downloa ... x?id=49982
After "winetricks dotnet461":
You do not have the required permissions to view the files attached to this post.
Last edited by axredneck on Tue Dec 24, 2019 7:36 pm, edited 5 times in total.
-
-
- Posts: 26571
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: Ultimate Doom Builder
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".Mysterious Haruko wrote:As for suggestions in the future - could we get more colour presets for automap view? Or even get function to customise it?
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.
-
- Posts: 391
- Joined: Mon Dec 11, 2017 2:09 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Russia
Re: Ultimate Doom Builder
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?
-
- Posts: 176
- Joined: Wed Jul 03, 2019 10:17 am
Re: Ultimate Doom Builder
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.
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.
-
- Posts: 43
- Joined: Mon Jul 09, 2018 11:13 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Colorado, United States
Re: Ultimate Doom Builder
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:
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:
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.axredneck wrote: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?
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: Ultimate Doom Builder
Thanks for the detailed testing! I think this part is the most important, as it blocks 32bit mode which works for you:
edit: Tested on Windows, memory usage in UDB is indeed larger. Will research the idea with storing pixels inside texture later.
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.YukiRaven wrote: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.
edit: Tested on Windows, memory usage in UDB is indeed larger. Will research the idea with storing pixels inside texture later.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: Ultimate Doom Builder
Please make a GitHub issue: https://github.com/jewalky/UltimateDoomBuilder/issuesguitardz wrote: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:
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.
-
-
- Posts: 26571
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: Ultimate Doom Builder
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?
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?
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: Ultimate Doom Builder
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.dpJudas wrote: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.
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...