GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
Locked
User avatar
Enjay
 
 
Posts: 26516
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

That does look pretty amazing and potentially very useful. :thumb:



It's a shame that GZDoom can't (yet?) support texture skewing because that particular construct would be a perfect candidate for the middle section to have its vertical side texture skewed to the angle of the slope.

User avatar
TheMafla
Posts: 18
Joined: Wed Jun 20, 2018 8:28 am
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by TheMafla »

Enjay wrote:That does look pretty amazing and potentially very useful. :thumb:



It's a shame that GZDoom can't (yet?) support texture skewing because that particular construct would be a perfect candidate for the middle section to have its vertical side texture skewed to the angle of the slope.

I am almost certain that I have read a long time ago that the "skew textures" feature was possible, but I am talking about a post from 2018, maybe it is not so easy to add that feature natively to GZDoom so they have simply left it in the forgetfulness.

I admit that I would also like an option like that, as well as rotating textures on walls, but unfortunately if you want to do something like that you have to skew or rotate the textures by a program like Photoshop or GIMP.
User avatar
Sandro
Posts: 173
Joined: Sat Oct 05, 2013 8:03 am
Location: Erathia

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Sandro »

Is there a way to optimize GZDB so my brand-new Nvidia GPU can finally display 3D mode without any lag ?

By testing it right now I feel it's as laggy as my previous 8 years old computer and its integrated graphic card. I know my maps are resources-demanding but I should feel a hupe gap between those two, shouldn't I ?
Every time I move the camera direction, I experience a tiny "twitch" which is really annoying, as if my computer was too slow to render things properly... Any advices ?
User avatar
axredneck
Posts: 354
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
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by axredneck »

Sandro wrote:Any advices ?
Hide bottom panel
User avatar
Kappes Buur
 
 
Posts: 4114
Joined: Thu Jul 17, 2003 12:19 am
Graphics Processor: nVidia (Legacy GZDoom)
Location: British Columbia, Canada
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Kappes Buur »

Sandro wrote:Is there a way to optimize GZDB so my brand-new Nvidia GPU can finally display 3D mode without any lag ?
A smooth movement in the 3D View Mode depends greatly on
1. the size of the map
2. how many actors are visible
3. the viewdistance set in F5

With my old GTX660, movement is, in a fairly large map with a diagonal of ca 24000, quite smooth with viewdistance set to 9000. But going over a map size of ca 30000 and a fair number of 3D floors, movement is noticeably jerky.

However, boris made some optimizations in GZDBBF to that code in the editor, plus the viewdistance can now be set up to 64000.
R3088 | 4b86f545 | biwa | 19.10.2019, 16:52
--------------------------------------------------------------------------------
- Increased max view distance from 9000 to 64000 map units. Step size increased
from 200 to 500 map units
@ Improved performance of VisualBlockMap.GetFrustumRange so that high view
distances is actually usable. This does not do anything to the rendering speed,
so that's still slow
Give that a try and see how it will work for you.
User avatar
Enjay
 
 
Posts: 26516
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

Is there a way in GZDB to ask a texture to be scaled to fit a line's length but do so by tiling as often as needed to fill the line and only scale to take account of the remainder?

Hmmm... that probably doesn't make sense.

OK, if I have a line that's 258 long and a texture that's 128 wide, without scaling the texture will repeat so that it is used twice, but there will be two stray pixels of texture left over at the end. What I'm asking is, is there a way to make the two instances of the texture behave as if they were 258 wide instead of 256?

Equally, it could go the other way. If the line was 254 long, the normally 256 wide double instance would scale down to behave as if it was 254 as well.

At the moment, all I can find is the ctrl-alt-a combination that stretches a texture to the length of the line (so in my first example, a single instance of the 128 texture would be stretched to 258 wide - looking very stretched) or to try to fit it manually myself. The ctrl-alt-a function is very useful, but sometimes I need what I'm describing instead.

So, does this exist as a feature?

If not, is it something that would be easy to add?
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Isn't that exactly what the "Texture Repeating" options in the "Fit Texture" dialog do?
User avatar
Enjay
 
 
Posts: 26516
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Enjay »

Well that description certainly sounds like it would do what I'm asking about. I'll have to check when I get home from work. Don't know why I didn't spot it. I was looking and didn't see anything but, apparently, there it was - right in front of me. :oops:

Thanks once again.

[edit]
And, yes, that's exactly what I was looking for - and it's even more flexible than I hoped. I don't know how many times I've had that dialogue open but I simply hadn't realised what that bit of it was doing. I guess every time that I tried it, it was in a situation where the effects weren't obvious.

Brilliant stuff. :thumb:
[/edit]
User avatar
Pedro vc
Posts: 164
Joined: Fri Oct 10, 2008 4:56 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Pedro vc »

This code gives me an "ZSCRIPT error in "test\zscript\misc.txt", line 92. Expected comma or ;, got <Token.Semicolon (;)>."

Code: Select all

class Stuff : Actor  // at the file, this is line 97
{
	Default
	{
  		Mass 9999999999;   //commenting this line solves the bug
	}
}
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

That number is too big to fit into a signed 32 bit int. GZDoom doesn't parse that number correctly, either. See https://zdoom.org/wiki/Actor_properties#Mass if you need to give it a large mass.

This could obviously handled better by GZDB-BF, the question is how. I see two options:
  • Still abort parsing, but report a sensible error message
  • Do not abort parsing, report a warning, and set the value to the min/max value of the data type. But I'm not sure if that has any downsides, as this would apply to any parsed number
User avatar
Curunir
Posts: 1037
Joined: Sun Nov 02, 2003 11:24 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Curunir »

I tried running GZDB BF on a PC that is not my usual one and it won't start.

Win 10 64 bit, i3 CPU with an Intel HD 630 integrated GPU, I already have up-to-date DX and .NET.

Is that the GPU choking things up?

Edit: Figured it out - it NEEDS SlimDX Runtime. Had to grab it from a Google Code archive.
User avatar
Pedro vc
Posts: 164
Joined: Fri Oct 10, 2008 4:56 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Pedro vc »

boris wrote:That number is too big to fit into a signed 32 bit int. GZDoom doesn't parse that number correctly, either. See https://zdoom.org/wiki/Actor_properties#Mass if you need to give it a large mass.

This could obviously handled better by GZDB-BF, the question is how. I see two options:
  • Still abort parsing, but report a sensible error message
  • Do not abort parsing, report a warning, and set the value to the min/max value of the data type. But I'm not sure if that has any downsides, as this would apply to any parsed number
GzDoom doesn't give any warnings and I never noticed anything unusual with the actor in-game. I think GZDB and GzDoom may handle large ints differently
boris
Posts: 736
Joined: Tue Jul 15, 2003 3:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by boris »

Pedro vc wrote:GzDoom doesn't give any warnings and I never noticed anything unusual with the actor in-game. I think GZDB and GzDoom may handle large ints differently
Yes, GZDoom doesn't print any warning, but it you print your mass to console you'll see that it's a completely different value.

Anyway, I commited the change that clamps the values and print a warning.
User avatar
Pedro vc
Posts: 164
Joined: Fri Oct 10, 2008 4:56 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Pedro vc »

boris wrote:
Pedro vc wrote:GzDoom doesn't give any warnings and I never noticed anything unusual with the actor in-game. I think GZDB and GzDoom may handle large ints differently
Yes, GZDoom doesn't print any warning, but it you print your mass to console you'll see that it's a completely different value.

Anyway, I commited the change that clamps the values and print a warning.
I see, thanks
User avatar
Kappes Buur
 
 
Posts: 4114
Joined: Thu Jul 17, 2003 12:19 am
Graphics Processor: nVidia (Legacy GZDoom)
Location: British Columbia, Canada
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Kappes Buur »

Xmas came early :D
thank you boris

season's greetings to all
Locked

Return to “Abandoned/Dead Projects”