Ultimate Doom Builder

[Tormentor667]

Playing around with the editor since yesterday. The performance is so much better than before, great work on that ZZYZX

[ZZYZX]

Playing around with the editor since yesterday. The performance is so much better than before, great work on that ZZYZX

Not me! That's mainly dp's renderer rewrite.

[dpJudas]

About the build process, I personally don't have any issues with msbuild

What we need is a solution to these things:

1) Only run post build scripts when building on Windows (.bat files naturally errors out on Linux)
2) Only include certain source files when building on Windows (think it was the scintilla scripting code I had to disable for Linux)
3) On Windows, only run the post build scripts when doing a (final) release as they keep changing various files that's part of the repository. This makes it a pain to commit because every time I have to explicitly uncheck source files that TortoiseGit wants to include. Or remove those files from the repository - why are they committed anyway?

Technically those things can be done, but it requires xml config file insanity at a level that makes me personally think msbuild is unfit for larger (complex) professional projects. Duplicating all the project files like I did is a truly shitty solution - I really hope that C# developers don't do this for real. This is the issue I have with msbuild.

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

This happens because RenderDevice.SetPixels doesn't immediately upload the texture. This is an artifact from the early days of the porting and can be removed by issuing the glTexImage2D call directly at that point instead of when its first used.

[ZZYZX]

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

This happens because RenderDevice.SetPixels doesn't immediately upload the texture. This is an artifact from the early days of the porting and can be removed by issuing the glTexImage2D call directly at that point instead of when its first used.

Will this not cause issues with threaded loading? Since right now, setting texture pixels does not require a GL context...


About the build...

Postbuild: I just think we need to make a crossplatform version of the scripts (use bash and require cygwin to compile? I personally have cygwin and actually use it for Git, SSH...)
Though honestly I think the real issue here is Mono which does not provide .cmd support even though that's the only supported format (historically) and all commands are expected to be Windows-style in the project (e.g. copy instead of cp). Just like Windows version of Make provides bash and minimal commands, because clearly commands from the makefile will be using it.

Excluding certain code in certain platforms: is it possible to check platform during runtime and disable some parts of the code?

Changing files: all files changed by postbuild should be added to gitignore (because usually they are either generated during build or copied from elsewhere). I already did this for few files (vpo.dll, updater, DevIL).
For AssemblyInfo.cs (which contains revision information) we need to setup a proper build process in a read-only environment which simply does not commit AssemblyInfo.cs to the repository.
As a temporary solution (I'd like to move away from manual builds anyway) it's possible to create a temporary Git state with the modified AssemblyInfo, then restore to whatever it was.

[dpJudas]

If I read the source code correctly, the threaded loading first loads it into an Image. Then it issues a SendMessage call to finish the work on the UI thread. When the UI thread processes the message it completes the work by calling RenderDevice.SetPixels. So it has an OpenGL context at that point.

[ZZYZX]

Tried to do that. Memory usage indeed dropped even below DirectX version, all works for me. Pushed a build, not sure if it will work as intended on all AMDs though...

[Redneckerz]

UDB is now on ZDoom Wiki and (Pending) on DoomWiki.

[ZZYZX]

Btw, at some point (but definitely after the first merge) I deleted some postbuild script which referenced vsvars32.bat (it was setting some weird flag on the updater executable, which is not needed since x86 updater cannot be used with x64 anyway). Was it the one that prevented Mono build?

I think all other build scripts are just copying stuff around and can be made compatible. Not sure though (not at PC right now)

Redneckerz: ty!

[DavidN]

Thanks to all for keeping this going - love the new name, and it's great to see this being continued! I will get back to my own contributions as well at some point

[kaleb.]

well after seeing it has Linux compatiblity now i got really happy, but it gives me this error when i try to actually try to open/start making a map
https://i.imgur.com/i7srFHT.png

[ZZYZX]

I believe this is a result of recent pull request being merged which replaced Microsoft Sans Serif with Arial. I'm going to try to fix this by shipping some free font within the editor or using the application one...
Since, hard dependency on any system font in crossplatform software is not quite a good thing.

edit: fixed in R3271 (607ac77) / R3272 (if you already updated)

[Bauul]

Having a play with this, and so far it's running very nicely!

I have run into a small error though. When trying to copy and paste dynamic lights around in a UDMF environment, some walls stopped showing up as Highlighted in 3D mode. Then I got an error that said "BuilderModes: Object reference not set to an instance of an object". And then all the dynamic lights in the 3D view became super overexposed, like this:



I'm not sure what's directly related in the above or whether it was just coincidence it all happened together. Restarting UDB fixed it, but I could easily replicate the error by going through the same steps.

Edit: Did some more experimenting, now it happens just by dropping in and out of 3D mode causes the error without changing anything. I'll try deleting the .dbs and see if it makes any difference.

Edit 2: Ok so it's not related to the dyn lights, I think it is just the 3D mode. I've recorded a video as that seemed easier than describing the issue. I hop in, out, and back into 3D mode to show the highlighting disappearing, and then update the view (by changing the offset of a linedef up and down repeatedly) to show the over-saturation:

https://streamable.com/xdoi2

[ZZYZX]

I reverted this: https://github.com/jewalky/UltimateDoom ... 431e2f5bee
In theory it could be retained and fixed, but since we essentially have git builds as production (which automatically deploys), it's not very great to wait until it's fixed...
As for the exact cause, it seems UDB handles sidedefs rather freely and possibly regenerates them every frame/every time 3D mode initializes, which results in complete loss of data. I did look at it in the debugger, object received in AddGeometry and object received in GetSidedefGeometry are different, though they have the same hash (which is why dict works).

Linedefs should be working again.

[dpJudas]

It is a shame the code dealing with VisualXX objects is this brain dead. Doing a hash lookup on every single wall every single frame is very expensive when a long draw distance means that might be 20k lookups or more.

[ZZYZX]

Another guess is that going out of 3D mode could cause deallocation of visual geometry (and thus it resets to null), though not sure why it doesn't get added back...