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.
Re: Ultimate Doom Builder
It's a bug. both the horizontal and vertical scales get rounded, but the vertical one then gets converted from a double precision floating point number("double") to a single precision floating point ("float"). And in that process it loses some accuracy. It's probably a remnant from when UDB was moved from using floats to doubles.
Re: Ultimate Doom Builder
Well, that would explain it. Thanks for the answer.
Re: Ultimate Doom Builder
A question about texture alignment - in a specific circumstance.
I noticed when making a map that has 3D floors and railings along the edge of the 3D floors, that letting UDB align the railings (Y direction) can unalign the railings instead, if there is a ceiling height difference. So, I was wondering if there is a way around this?
To explain.
The highlighted midbars have been aligned manually to sit on the 3D floor (to look like railings along the edge). You can also see that there is a ceiling height difference in the sectors. If I press Shift-A to align the railings vertically, what will happen is what you can see in the background: the railing in the lower-height sector will remain at the correct height but the ones in the taller sector go up to the ceiling. It only seems to happen on the outer edge of the 3D walkway. The sidedefs facing inwards remain aligned. It also doesn't happen when there is no 3D floor - just railings hanging in the air. So, I'm guessing that UDB is having problems with the 3D floor edge versus the railing and figuring out what to align (though, as you can see, I have selected the railing textures, and not the side of the 3D floor). So, I'm guessing it's not a bug as such, merely a limitation, but is there a way to stop this happening? Several times I have accidentally unaligned my railings (in far more complicated maps than this) and had to re-align everything manually again.
Map is attached. The southern bridge has the bars manually aligned. The northern bridge was manually aligned, but then I used UDB's Y-align and the outer railings became unaligned.
The railings in the map are non-blocking to allow easy walking on/off the bridges.
Edit: I think I have a workaround/solution. If I press Tab in 3D mode to remove GZDoom features, the 3D floors disappear and the railings can be aligned how I want by pressing shift-A. I can then press Tab again top bring the 3D floors back. I'm not sure if that's the intended way, but it seems to work.
I noticed when making a map that has 3D floors and railings along the edge of the 3D floors, that letting UDB align the railings (Y direction) can unalign the railings instead, if there is a ceiling height difference. So, I was wondering if there is a way around this?
To explain.
The highlighted midbars have been aligned manually to sit on the 3D floor (to look like railings along the edge). You can also see that there is a ceiling height difference in the sectors. If I press Shift-A to align the railings vertically, what will happen is what you can see in the background: the railing in the lower-height sector will remain at the correct height but the ones in the taller sector go up to the ceiling. It only seems to happen on the outer edge of the 3D walkway. The sidedefs facing inwards remain aligned. It also doesn't happen when there is no 3D floor - just railings hanging in the air. So, I'm guessing that UDB is having problems with the 3D floor edge versus the railing and figuring out what to align (though, as you can see, I have selected the railing textures, and not the side of the 3D floor). So, I'm guessing it's not a bug as such, merely a limitation, but is there a way to stop this happening? Several times I have accidentally unaligned my railings (in far more complicated maps than this) and had to re-align everything manually again.
Map is attached. The southern bridge has the bars manually aligned. The northern bridge was manually aligned, but then I used UDB's Y-align and the outer railings became unaligned.
The railings in the map are non-blocking to allow easy walking on/off the bridges.
Edit: I think I have a workaround/solution. If I press Tab in 3D mode to remove GZDoom features, the 3D floors disappear and the railings can be aligned how I want by pressing shift-A. I can then press Tab again top bring the 3D floors back. I'm not sure if that's the intended way, but it seems to work.
- Attachments
-
Alignment.zip- (2.05 KiB) Downloaded 18 times
Re: Ultimate Doom Builder
Should be fixed, and maybe I didn't break anything in the process.
Re: Ultimate Doom Builder
So far so good anyway and, as ever, your efforts are appreciated.
Re: Ultimate Doom Builder
This crashing bug haunts me. 
It happens when I try to type the name of a texture.
It happens when I try to type the name of a texture.
Re: Ultimate Doom Builder
Known problem. Never happened to me, and in fact it should be impossible to happen. So I can't fix it.
Re: Ultimate Doom Builder
It is probably due to a race condition. Many years ago I tried to fix the threaded loading of images in UDB which was done completely wrong. The code basically didn't lock access to shared variables and it created win32 objects (such as System.Drawing.Bitmap) on worker threads while the win32 GDI object model is built on the apartment thread model. I guess I must have missed a spot since its still happening.
The image loading code in UDB is some of the worst code I've ever seen, so don't expect anyone to fix this. Only way to really do it would be to rewrite most of it to be perfectly honest.
The image loading code in UDB is some of the worst code I've ever seen, so don't expect anyone to fix this. Only way to really do it would be to rewrite most of it to be perfectly honest.
Re: Ultimate Doom Builder
In all the reports it's the "UnknownImage", not some random texture. And the UnknownImage is loaded when a map is created/loaded, and not when it is needed, like textures. And the weird thing is that it seems to happen to some people regularly, and never to others.
Re: Ultimate Doom Builder
The key question here is whether "new Bitmap(loadbitmap)" is thread safe or not, since it might be both the UI thread and the background loader thread could be calling it. Not even sure if using Properties.Resources.UnknownImage directly instead would be safer. The way Microsoft implemented their GDI integration in .NET is really a guide in Don't Do That for how to manage resources in a garbage collected language. I suppose one could try throw a lock(loadbitmap) into LocalLoadImage and GetPreview to see if it fixes the problem or not.