GZDoom Builder 1.14

[Siberian_Tiger]

Doom Builder 2 is written in C# (which is a programming language developed by Microsoft) and uses DirectX for 3D rendering (which happens to be also developed by Microsoft). I know about Mono, but I don't think porting Doom Builder 2 to Mono + OpenGL will be an easy task (waaay to many differences).

You are correct, but there is always possibilities!

[MaxED]

You are correct, but there is always possibilities!

Surely there are. But it will require complete UI rewrite, among other things, because Mono UI components are based on GTK, and they can't be easily swapped with C# ones (and there's A LOT of UI classes in Doom Builder 2). And I don't have Mac OS or Linux and never used them. And I definitely don't want to maintain two quite different branches of GZDB.

In short words: it's doable, just not by me.

[smoke_th]

You are correct, but there is always possibilities!

Surely there are. But it will require complete UI rewrite, among other things, because Mono UI components are based on GTK, and they can't be easily swapped with C# ones (and there's A LOT of UI classes in Doom Builder 2). And I don't have Mac OS or Linux and never used them. And I definitely don't want to maintain two quite different branches of GZDB.

In short words: it's doable, just not by me.

Or, you can just move it onto mono and opengl+gtk and start maintaining as it is basically Creating yourself 1 different branch of ZDB which multiplatform and ready to be launched on any system which can maintain gtk+mono+opengl. Detaching it onto cross-platform libraries will pay off, if you'll start taking donations to example.
But hey - its freeware from what i care, so technically its only your altruism fueling this good project at the moment.
I just wish you'll keep it up.

[Nash]

I'd rather MXD just do what he does best and that is just maintaing whatever it is that's available now (GZDB for Windows), than forcing him to work on something he's not familiar with and risk him getting frustrated... :D

[Siberian_Tiger]

Surely there are. But it will require complete UI rewrite, among other things, because Mono UI components are based on GTK, and they can't be easily swapped with C# ones (and there's A LOT of UI classes in Doom Builder 2).

I can't deny that this wont be an easy task.

And I don't have Mac OS or Linux and never used them. And I definitely don't want to maintain two quite different branches of GZDB.

In short words: it's doable, just not by me.

I've never really said that you should build the new branch project; but, if someone is willing to get their hands dirty and get KDiCode - then great! I didn't really want my original comment to be a debate on who specifically should make this overhaul task, but merely a wish that someone would. I can't really stress this enough, Doom Builder 2 and even GZDoom Builder is one of the most powerful and frequently used level editors! It would be great to expand these powerful tools on multiple platforms instead of just one platform.

[Nash]

Oh, if that is the case, then it's alright. I imagine it's not an easy fix?

Fixed in 1.12e.

This also fixed a bug where I used to not be able to align 3-d floor textures with my arrow keys... now I could do it easily. THANK YOU!!!

[Jimmy]

This basically my map editor of choice now. I'm using as many of the GZDoom features as I can with this thing and I'm loving it.

I'm also using it for Boom mapping, though - and a problem arises when trying to align sidedef textures. All linedefs are inevitably set to [0, 0] because this GZDB2 aligns textures by the offsets in their UDMF fields, which of course don't exist in Boom format.

Any chance this could be addressed?

[MaxED]

I'm also using it for Boom mapping, though - and a problem arises when trying to align sidedef textures. All linedefs are inevitably set to [0, 0] because this GZDB2 aligns textures by the offsets in their UDMF fields, which of course don't exist in Boom format.

Any chance this could be addressed?

Align them in Visual mode (W key by default), not in GZDoom Visual Mode (Q key by default)

[Jimmy]

Oh. That makes sense. (I've been using GZDoom visual mode for everything.)

Thanks.

[NeuralStunner]

Just checking in on the current state of TEXTURES support. I'm glad /Textures are now valid as patches! Unfortunately TEXTURES composites are not yet usable as patches.

Just to check, will GZDB display \HiRes replacements? Another consideration.

Also, full TEXTURES feature support might be tricky, but it would be very appreciated. In particular: Patch translucency (additive too), translation, rotation/flipping, and color blending.

[Sergeant_Mark_IV]

I'm having some random crashes in Linedef editing mode in my map. Sometimes after I draw something, the program just stops responding, and I am obligated to close it. After I open the map again, I can do the same function that crashed it previously without any problems, but after 5 minutes, it causes another random crash. Never happens on Visual Mode or Thing Editing mode.


Using 1.12 version.

My System specs:
Intel i3 2120, 4GB RAM DDR3.

Map Statistics:
Vertices 11167
Linedefs 13330
Sidedefs 24762
Sectors 2325
Things 1763

Map Analysis Mode returns no errors.

[MaxED]

Does this also happen in Doom Builder 2? And if it doesn't, can you send me your map for testing?..

[Sergeant_Mark_IV]

No. The crash doesn't happens in DB2. I'm sending the map for you via PM.

[Kappes Buur]

I would like to request a feature (button or hotkey) which allows the editing window, once it is set, to be locked in place, so that it cannot be resized or paned.

[MaxED]

Can you describe a situation, when such feature will be usefull?